Clean up expressjs org

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).

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?

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.).

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)?

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.

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.

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 😄

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.

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?

@dougwilson

@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

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.

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.

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.

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 😎

@fengmk2

@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

thanks in advance!

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.

Current status: I just finished to archive all the repos with a nice message in the README.md. Also I closed all the issues, PRs and unpublished github pages 🥳

I will start to work on the npm part...

@fengmk2

Deprecation Summary

The following npm packages have been deprecated 🥳

Packages Requiring Ownership Transfer or Deprecation 🙏

These packages require support from the emeritus team as I currently lack the necessary npm permissions.

@fengmk2

Please transfer and/or deprecate the following packages:

@niftylettuce / @titanism

Please transfer and/or deprecate:

@tj

Please transfer and/or deprecate:

express-namespace

@jonathanong

Please transfer and/or deprecate:

@Fishrock123

Please transfer and/or deprecate:

extend-proto

Suggested Deprecation Command

npm deprecate my-pacjage@"*" "This package is archived and no longer maintained. For support, visit https://github.com/expressjs/express/discussions"

I can add npm ownership to those two packages, just let me know the full list I need to add on npm - also please ensure I am not removed nor is my alias account of niftylettuce. Both accounts have 2FA and strict security. I still maintain packages in the Koa userland - we use them here at @forwardemail (I'm the Founder).

I can transfer them - who would like to receive them?

@jonathanong

@jonathanong for both the github repos and the npm packages, if you bounce them to me i can get them added to the express org properly.

docs: reflect cleanup initiative changes

docs: update the team scope

feat: update OSSF Scorecard scope

@ljharb

Yes! Transfer the packages in npm to https://www.npmjs.com/~ljharb is the best option, as he can do all the team arrangement 👍

Just to clarify: @ljharb the GitHub repos are all under our org(s), so only the npm packages are missing

@ljharb

@ljharb sent! sorry for the delay, GitHub notifications are hard

Thanks! Those 4 packages are now in their own teams in the npm org, and i made 2FA required for publishing them (wes had to restore my admin access to do it, feel free to downgrade me again if needed at yalls leisure)

docs: reflect cleanup initiative changes

docs: reflect cleanup initiative changes (#379)

Navigation Menu

Repository navigation

Clean up expressjs org #134

17 remaining items

Deprecation Summary

Packages Requiring Ownership Transfer or Deprecation 🙏

@fengmk2

@niftylettuce / @titanism

@tj

@jonathanong

@Fishrock123

Suggested Deprecation Command

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Clean up expressjs org #134

Description

Activity

gireeshpunathil commented on Jul 1, 2020

dougwilson commented on Jul 1, 2020

gireeshpunathil commented on Jul 1, 2020

wesleytodd commented on Jul 1, 2020

ghinks commented on Jul 2, 2020

wesleytodd commented on Jul 2, 2020

gireeshpunathil commented on Jul 2, 2020

dougwilson commented on Jul 2, 2020

gireeshpunathil commented on Jul 2, 2020

dougwilson commented on Jul 2, 2020

dougwilson commented on Jul 2, 2020

dougwilson commented on Jul 2, 2020

dougwilson commented on Jul 2, 2020

gireeshpunathil commented on Jul 3, 2020

17 remaining items

bjohansebas commented on May 5, 2025

UlisesGascon commented on May 14, 2025

UlisesGascon commented on May 14, 2025

Deprecation Summary

Packages Requiring Ownership Transfer or Deprecation 🙏

@fengmk2

@niftylettuce / @titanism

@tj

@jonathanong

@Fishrock123

Suggested Deprecation Command

titanism commented on May 14, 2025

jonathanong commented on May 15, 2025

ljharb commented on May 15, 2025

UlisesGascon commented on May 15, 2025

jonathanong commented on May 20, 2025

ljharb commented on May 20, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions