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 😎