docs: update governance to allow long-term contributors to be nominated as committers and captains

[bjohansebas]

This is my attempt to make nominations more sustainable and to give Express a less bureaucratic and time-consuming process. For example, this could apply to jshttp packages or others with low activity, or cases where a package captain is somewhat inactive but another community member wants to help.

The rationale is that there are already people outside the TC who have been involved in the project for a long time (some are package captains, others are committers) and they’ve already demonstrated both their technical ability and their capacity to collaborate. This would help keep Express relevant, ensure packages continue to be maintained, and avoid everything falling on just a few TC members.

cc: @expressjs/express-tc

[ctcpip]

I think we should do something stronger than this, and create a new role that is a level above committer. "Collaborator" maybe?

Regardless of what we call it, the idea would be that collaborators would have write access across all repos.

I am less comfortable with the current language of the proposed change to be eligible for captain of a package. To have someone that has not contributed at all to a package suddenly become a captain seems somewhat odd to me. However, the approval is still gated by the TC, so perhaps is ok. I would also feel better about it if the approval requirement was strengthened, e.g. requiring actual TC consensus rather than it simply being gated on a PR. (This is something that maybe should change regardless.)

[bjohansebas]

I think we should do something stronger than this, and create a new role that is a level above committer. "Collaborator" maybe?

I like that, but I’ll handle it in another PR since it’s different from what I’m proposing.

To have someone that has not contributed at all to a package suddenly become a captain seems somewhat odd to me.

Would it also be considered odd if a TC member wanted to become a captain of a package they haven’t contributed to? For example, if I wanted to be a captain/committer of the router, would that be strange even though I’m a committer on the Express package and the router is directly tied to Express, so I naturally understand how it works?

I would also feel better about it if the approval requirement was strengthened, e.g. requiring actual TC consensus rather than it simply being gated on a PR

Doesn’t that already exist? If we wait to discuss it in a meeting, it’s going to take quite a while, we already wait at least two weeks. If after two weeks not everyone from the TC has been able to review it, but some members have and they’re okay with it, then why wait for the rest? Let’s avoid the bus factor and trust each other.

I understand that with all the supply chain attacks there’s concern about granting access to npm packages, but many people who are no longer in the TC already have access to important parts of the project, like the website or security reports.

[GroophyLifefor]

Hi dear @expressjs/express-tc, I wanted to remind that this discussion is top priority and it should be discussed at the meeting. If it was already discussed, could someone please add a summary/outcome here as a comment?

I'd especially like to highlight @bjohansebas's situation here, since he's living this exact problem firsthand: being a committer with the time and willingness to help, but with no clear path to act when a captain is inactive. This isn't a hypothetical, it's actively blocking progress across multiple repositories today.

Beyond this specific proposal, I think it also ties into a bigger visibility problem: with issues, PRs, and effort spread thin across Express, jshttp, and pillarjs, it's genuinely hard for contributors to know where to focus. A clearer roadmap and better prioritization (a well-maintained project board goes a long way here) would help reduce the backlog over time and make it easier for people like @bjohansebas to actually put their time to use.

Would really appreciate this getting concrete attention soon.

[bjohansebas]

I know many of us are involved in multiple projects—I am too—and there are a huge number of packages here. The goal is to help and also reduce everyone's workload, not to constantly rely on private messages saying, "Hey, could you review this?"

Instead, we should have more freedom to work together and allow the project to move forward more naturally instead of getting stuck.

As I've said in several places, the only thing I can really do today is guide people. For some packages, that makes perfect sense because I don't want to be the captain. But for others, I do want to be a captain so I can merge changes and cut releases, helping those projects continue to evolve.

I don't want us to end up with PRs sitting idle for months again. It's a bit ironic that we often say, "Hey, can someone help with this?" only for those very same PRs to remain stalled for months afterward. That can be really discouraging for contributors. For example, the Diagnostic Channel PR has been open for several months. I literally stepped away from the project for a few months, came back when I had free time, and it still hadn't moved at all.

When I returned, I reviewed it again and helped move the discussion forward, but now it feels like it's going to end up sitting in limbo again for who knows how long.

It's gotten to the point where people ask me, "Hey, where can I help?" and I honestly don't even know what to tell them anymore, because I don't know where they can help either.