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.

[Phillip9587]

Hi everyone, I'd like to bring this topic back into focus.

I propose that we consider archiving all clearly unmaintained repositories and deprecating the corresponding unmaintained packages on npm. This would make it much more transparent to users that certain packages or repos are no longer actively maintained, helping set the right expectations and reducing potential confusion for developers relying on the Express ecosystem.

Making this status explicit—rather than leaving it implied through inactivity—would benefit both maintainers and the wider community.

I've added the tc-agenda label, as I believe this is something only the TC can formally decide on. I'm also happy to help with this effort in any way I can.

Would love to hear thoughts on how we could move forward with this.

[jonathanong]

#134 (comment) all good on my side to archive these

[Phillip9587]

Related: expressjs/expressjs.com#1889

[Phillip9587]

In #337 (comment), @bjohansebas compiled a list of npm packages where the source code lives in one of the Express GitHub orgs, but the packages themselves are not published under the @expressjs organization on npm.

As @wesleytodd noted, most of these packages likely need to be deprecated. It would be helpful to review the list and decide which ones should be deprecated or possibly transferred.

[bjohansebas]

Yep, @Phillip9587 do you want to create that definitive list?

Also, add the badgeboard that @wesleytodd is captain, but now that the statusboard works, I’m not sure if it still makes sense to keep that repository here. What do you think @wesleytodd?

[Phillip9587]

I created a list for the expressjs org. I will edit this comment when i have the time to add the other orgs.

expressjs

Repo Name	URL	NPM URL	Archived	Deprecated on NPM
api-error-handler	https://github.com/expressjs/api-error-handler	https://www.npmjs.com/package/api-error-handler	Yes	No
badgeboard	https://github.com/expressjs/badgeboard		No
connect-markdown	https://github.com/expressjs/connect-markdown	https://www.npmjs.com/package/connect-markdown	No	No
connect-multiparty	https://github.com/expressjs/connect-multiparty	https://www.npmjs.com/package/connect-multiparty	No	No
connect-rid	https://github.com/expressjs/connect-rid	https://www.npmjs.com/package/connect-rid	No	No
csurf	https://github.com/expressjs/csurf	https://www.npmjs.com/package/csurf	Yes	Only the last version was deprecated.
domain-middleware	https://github.com/expressjs/domain-middleware	https://www.npmjs.com/package/domain-middleware	No	No
express-expose	https://github.com/expressjs/express-expose	https://www.npmjs.com/package/express-expose	No	No
express-namespace	https://github.com/expressjs/express-namespace	https://www.npmjs.com/package/express-namespace	No	No
express-paginate	https://github.com/expressjs/express-paginate	https://www.npmjs.com/package/express-paginate	No	No
expressjs.github.io	https://github.com/expressjs/expressjs.github.io		No
flash	https://github.com/expressjs/flash	https://www.npmjs.com/package/flash	No	No
mime-extended	https://github.com/expressjs/mime-extended		No
restful-router	https://github.com/expressjs/restful-router	https://www.npmjs.com/package/restful-router	No	No
routification	https://github.com/expressjs/routification	https://www.npmjs.com/package/routification	No	No
set-type	https://github.com/expressjs/set-type	https://www.npmjs.com/package/set-type	No	No
urlrouter	https://github.com/expressjs/urlrouter	https://www.npmjs.com/package/urlrouter	No	No
vhostess	https://github.com/expressjs/vhostess	https://www.npmjs.com/package/vhostess	No	No

pillarjs

Repo Name	URL	NPM URL	Archived	Deprecated on NPM
discussions	https://github.com/pillarjs/discussions		No
extend-proto	https://github.com/pillarjs/extend-proto	https://www.npmjs.com/package/extend-proto	No	No
node-frameworks	https://github.com/pillarjs/node-frameworks		No
path-match	https://github.com/pillarjs/path-match	https://www.npmjs.com/package/path-match	Yes	No
pillarjs.github.io	https://github.com/pillarjs/pillarjs.github.io		No
qs-strict	https://github.com/pillarjs/qs-strict	https://www.npmjs.com/package/qs-strict	No	No
routington	https://github.com/pillarjs/routington	https://npmjs.org/package/routington	No	No
ssl-redirect	https://github.com/pillarjs/ssl-redirect	https://www.npmjs.com/package/ssl-redirect	No	No
templation	https://github.com/pillarjs/templation	https://www.npmjs.com/package/templation	No	No
views	https://github.com/pillarjs/views		No

jshttp

Repo Name	URL	NPM URL	Archived	Deprecated on NPM
http-push	https://github.com/jshttp/http-push		Yes
http-utils	https://github.com/jshttp/http-utils	https://www.npmjs.com/package/http-utils	No	No
jshttp.github.io	https://github.com/jshttp/jshttp.github.io		No
spdy-push	https://github.com/jshttp/spdy-push	https://www.npmjs.com/package/spdy-push	Yes	No
style-guide	https://github.com/jshttp/style-guide		No

---

Just some observations:

1. I included the badgeboard-related repositories (e.g., expressjs/badgeboard, pillarjs/pillarjs.github.io, and jshttp/jshttp.github.io) since it looks like we're using the statusboard now instead.

2. A few repositories appear to contain no actual code—some are empty or only include an initial commit. These could likely be deleted to reduce clutter.

3. The jshttp/style-guide repo has some useful historical context, like the issue label usage guide. That content could be ported to a more actively maintained repo. Otherwise, the repo may be a good candidate for archiving or should be brought up to date with current practices.

[UlisesGascon]

When the list is completed and there is a formal agreement from the TC, I will do the clean up 👍

[Phillip9587]

@UlisesGascon I think the list is complete now.

[bjohansebas]

From jshttp/style-guide, the only important thing was knowing the meaning of each of the labels, well, the only one we didn’t know until recently was pr. And those meanings are now being moved to this repository (see #342), where the global documentation is being kept.