Clean up expressjs org

[dougwilson]

So while responding to #71 I also realized that there is something on the TC backlog that ideally should get done at some point: go through the repositories in the expressjs org (https://github.com/expressjs) and determine which ones are actually active and which ones need to be retired in some way. For example, a repository in the org that hasn't been touched since 2013 maybe should be archived or similar (there are several of these).

[gireeshpunathil]

just thinking aloud here - how do we know the user consumption stories of these repos? may be easy if it was published as an npm module, but if not, and if user has directly forked and been using it all these while? or are those internal supporting repos which do not carry code modules?

[dougwilson]

All good questions to determine the answers to, which will determine what to do with the given repos (for example delete repo, vs move the repo, vs archive the repo, etc.).

[gireeshpunathil]

listing the repos here based on the inactivity order.	repo	inactive since	action
domain-middleware	04/13
connect-markdown	12/13
urlrouter	12/13
routification	12/13
vhostess	12/13
connect-rid	01/14
set-type	05/14
mime-extended	05/14
expressjs.github.io	07/14
express-expose	11/14
restful-router	12/14
express-namespace	02/15

May be, we should pick one at a time, deliberate, decide, act on it, and iterate over all?

To start with: looks like express-namespace is straight forward archive candidate, based on the last commit (that the project is closed in lieu of router)?

[wesleytodd]

I think we should move all of those out. I don't see any continuing, and if someone complains we can just move it back.

[ghinks]

I think we should setup a simple process.

• raise a PR to the read stating that this is an inactive repo, include in the change the date that it was removed and reason why the decision was made.
• Is there a way to see if any module depends upon a github repo? If so inform module owners.

[wesleytodd]

I honestly do not think we need to put much effort into this. It is not destructive to move it, we can simply undo it if someone complains, then have the conversation. I doubt anyone will 😄

[gireeshpunathil]

I agree. Let us take that decision this in the upcoming TC meeting. If folks (who have been in this project for enough time) can make that assertion, I think can just shelf it.

[dougwilson]

Do we really need to wait for TC meetings to have these kinds of discussions or make these kinds of decisions? I would rather if we can have certain discussions or decisions made over github that we do them here, as it is both faster and more transparent. Waiting until the next meeting just seems like delaying, unless there is a good reason. Is there a particular reason this cannot make progress in this issue and needs to be done in the TC meeting?

[gireeshpunathil]

@dougwilson - I don't want to oppose fast progress. My reasoning for waiting till TC is that:

• this is a discussion about multiple repos, so have org wide scope
• waiting till TC has the benefit of wider views and insights

I am fine to act today itself, if @ghinks (who proposed a different plan) is also happy with it

[dougwilson]

this is a discussion about multiple repos, so have org wide scope

I mean, that is the purpose of this repo: to have org wide discussions. This repo is effectively the text version of TC meetings. So being that it is an org wide discussion is not a reason to need to wait for a TC meeting :) having it in this repo should be good enough for that. If it is not, we need to determine why not and determine where we should be having text based org wide conversations.

waiting till TC has the benefit of wider views and insights

I would assert it does the opposite of that, as in this repo in text, all can participate no matter their time zone or other obligations; the TC meeting would be limited to only the group who actually attended that particular meeting. If I am missing something on this, let me know as well, how having a discussion in this repo would result in narrower views and insights compared to the TC meetig.

[dougwilson]

I would suggest perhaps as a precursor to opening those pull requests, to attempt to engage the folks who have been committing to the repo to determine what the plans are for that repo. My thinking is that we are trying to get to the repo captain type of delegation, mainly because there are repos that were effectively acting in that way. Because of that, even the TC would not likely decided unilaterally to kill a repo in the org without that engagement first, as I believe that would set a bad precedent for the repo captain initiative.

There have been a few repos I moved out of the expressjs org in the past after I opened a dialogue with the most recent committer. If the most recent committer is non responsive, then we should see who has the publish rights to the corresponding npm package and enguage them. If we end up with no engagement on any of those fronts, I would say at that point the TC would have to make a decision.

[dougwilson]

To add to the above, my suggestion above is generic to clean up repos in the org; if there are particular repos where we think we should act differently than than, bring those up :) and if it's easier to talk about a specific repo in a separate issue to pair down the conversation, just open a new issue about that one in particular. I think we should be able to resolve having this particular conversation over github, as it is not a pressing issue, and perhaps is a good candidate to determine where our github discussions break down to address how we can make them more effective.

[dougwilson]

Sorry, one last thing 🤣 : I have no issues with this being one of the topics in the upcoming TC meeting if we want. I was I guess just hoping that we don't end up just waiting until the TC meeting to do something if we could just talk about it or whatever needs to be discussed in the github forum 😎

[gireeshpunathil]

@fengmk2, @vendethiel, @jonathanong, @Fishrock123, @tj, @niftylettuce: you have been identified as the last / most active committer to one or more of the repos in expressjs org that has been inactive for a while. This ping is to check with you to determine:

• whether do you have any specific maintainance plans with those repo(s)
• are you fine for those repo(s) to be archived
• do you believe if there is another stake holder / affected party who should know

@fengmk2 - https://github.com/expressjs/domain-middleware @fengmk2 - https://github.com/expressjs/connect-markdown @fengmk2 - https://github.com/expressjs/urlrouter @jonathanong, @vendethiel - https://github.com/expressjs/routification @jonathanong - https://github.com/expressjs/vhostess @fengmk2 - https://github.com/expressjs/connect-rid @Fishrock123, @jonathanong - https://github.com/expressjs/set-type @Fishrock123, @jonathanong - https://github.com/expressjs/mime-extended @jonathanong, @Fishrock123 - https://github.com/expressjs/expressjs.github.io @tj, @niftylettuce - https://github.com/expressjs/express-expose @fengmk2 - https://github.com/expressjs/restful-router @tj, @jonathanong - https://github.com/expressjs/express-namespace

thanks in advance!

[Fishrock123]

I do not plan to do more here, all of my http related open-source efforts are now on Tide/Surf (i.e. no longer in javascript).

Also it should be noted that my contributions to both set-type and mime-extended were only to deprecate them.

p.s. I'm unsubbing from this please don't mention me unless necessary. Thanks! 😅

[dougwilson]

@gireeshpunathil I would recommend trying to do this engagement as an issue in each repo, if possible. This ensures that you are reaching the appropriate current audiences. I would suggest only calling out specific folks if you are not getting an answer on a generic issue in the repository. You can always link to this issue for context.

[gireeshpunathil]

The repos in which I could not open issues are

• https://github.com/expressjs/set-type
• https://github.com/expressjs/mime-extended
• https://github.com/expressjs/express-namespace

as those repos do not have issue tracker enabled. Let us see if we get an answer from the above pings, and then take a call.

[vendethiel]

My only contribution to routification was fixing the README a bit, so I don't have anything to say here.

[gireeshpunathil]

thanks @vendethiel !

[ghinks]

PillarJS Repo Archive Investigation

I took the oldest repos with no activity for the Pillar JS org. Only routington is active. I gave notice where it was possible. For views no commits have ever taken place.

table showing investigation results

repo name	url	date	contributor	notice given to active user?	deprecate npm module?
views	https://github.com/pillarjs/views	none ever / empty repo	no action taken	notice not given	na
ssl-redirect	https://github.com/pillarjs/ssl-redirect	2014	@jonathanong	notice given	na
templation	https://github.com/pillarjs/templation	2014	@jonathanong	notice given	yes
routington	https://github.com/pillarjs/routington	2014	@jonathanong	still in use	no
qs-strict	https://github.com/pillarjs/qs-strict	2015	@jonathanong	notice given	yes
extend-proto	https://github.com/pillarjs/extend-proto	2016	@fishrock123	notice given	yes
node-frameworks	https://github.com/pillarjs/node-frameworks	2014	@jonathanong	notice given	no

I shall follow up on the jshttp before the next meeting

[matjaeck]

Seems like this repo can be added to that list too? It's kinda hard to understand what the state of the expressjs org / expressjs repo is, whether there is still a TC or collaborators. Is @dougwilson the only person left and has to maintain everything?

I know you, Doug, are a coder and not a writer so I'm just saying that I'd find it very interesting to learn about the state of expressjs (org) in 2024 and the plans for the future, the challenges and the needs but am confident that it is all in good hands and that good things need time.