Document and make official repo captains

[wesleytodd]

I think we need dedicated captains for some modules. We already have this in practice with @LinusU and multer and @blakeembrey with path-to-regexp. But all of the rest fall back to @dougwilson. I think this would load balance a bit better, and would empower people to really push those forward if we had others on some of the more important once. I see no reason why it should not be multiple people for each in the future, but for now we just need a better clear guideline on how to "own" a repo and what the expectations are. I think we need to document it and make it official as the process for the TC.

On a tactical note, there are some important and high priority things I would like to finish in generator and router and I would feel much more empowered to do them if I had some officially recognized capacity to do so (and obviously publish rights). If I feel this way, I am sure that many others who might step up their contribution game also would. I think this would also be one way to start opening up the publish rights across the org without getting too crazy.

Here is my proposed addition to the contribution guide or new charter document:

### Project Captains

The Express TC can designate captains for individual projects/repos in the
three organizations. These captains are responsible for being the primary
day-to-day maintainers of the repo on a technical and community front.
They will ensure that decisions which effect the Express project at large are
brought up with the TC (in meeting or over GitHub issues) but otherwise will
have the full authority in the direction of the individual project.  These captains
will be given full permissions on both the repo as well as the npm packages, and
will follow the community guidelines for publishing and maintaining support.

To become a captain for a project you will be expected to participate in that
project for at least 6 months prior to the request.  You should have helped with
code contributions as well as triaging issues.  You are also required to have 2FA
enabled on both your GitHub and npm accounts. When you want to request the
captain role, submit a PR to this doc with the project and your GitHub handle.  The
PR will require at least 2 approvals from TC members and 2 weeks hold time to
allow for dissent.  When the PR is merged, a TC member will add you to the proper
GitHub groups, as well as grant you npm publish rights.  

#### Current Project Captains

- `path-to-regexp`: @blakeembrey
- `multer`: @LinusU 
- `expressjs.com`: @crandmck 
- `generator`: @wesleytodd 
- `router`: @dougwilson & @wesleytodd 

Obviously @dougwilson is the defacto captain for everything else, so I am not sure if it is worth saying that explicitly. Maybe we could just say "the TC is in charge if no one is explicitly listed below"?

Thoughts on this? If we like it I can do one of three things:

• add it to the charter.md document PR
• open a new PR against the new charter.md
• open a new PR with it to the contributing.md

[mhdawson]

This seems to be in line with the use of Code owners in some other projects and a good way to capture what roles people can work towards in the project (and as a pattern for the Package-maintenance team to try to share with other projects as well)

[dougwilson]

I am very onboard with explicitly calling out "captains" of modules. I think that, though most would "fall back to me", there are some where I would definately want to be the captain, if that makes sense, and so those would probably make sense to list explicitly. Originally, back with the orgs were formed, that was that the "Maintainer" field was in the various badgeboards (https://pillarjs.github.io/ , etc.), if you were curious on a starting point. Those names are manually set there and not automatically pulled from anywhere, but if we want to keep the list somewhere central, the badgeboards can just pull from that list for display.

I'm curious about the suggestion of Code Owners. I have never used that feature in GitHub, but if that is something that can provide some kind of value, we could do that as well.

[mhdawson]

This is one implementation of Code Owners that I'm familiar with: https://help.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners as members of our team are the Code Owners for the Power and s390 directories for V8. (EDIT, just noticed its not the description I thought but still useful as it is for github)

[dougwilson]

Reading over the proposed wording here got me thinking a bit about the following wording:

They will ensure that decisions which effect the Express project at large are
brought up with the TC (in meeting or over GitHub issues) but otherwise will
have the full authority in the direction of the individual project.

So I assume that based on the latter part, since it doesn't say the existing repo captain (1) has to be one of the approvers or can (2) reject a new captain from a pull request, the wording needs to be clarified a bit here. For example, if a repo A has a captain Bob who has full authority over the project and then a member Tom starts to help with the repo and meets the time requirement, the text seems to indicate that Tom would be able to be added as a repo captain with only approval from the TC and not the existing repo captain.

I am not saying this is invalid, though I think it may be best to maybe dial back on the "full authority" wording for the repo captain, as it seems to indicate that the TC has the authority to add additional folks to a repo who will also have "full authority". My thought is it may be in our interest to better set expectations around it.

I'm also not sure if it is worth adding something around co-owner conduct or similar, as the proposal above seems to allow for co-owners, and I assume the implication is that they will work together, but we should probably outline what should be done if they have conflicts. Perhaps just wording around reaching out to the TC or something, not sure off-hand. I'm not sure if there is prior-art to this.

[wesleytodd]

indicate that Tom would be able to be added as a repo captain with only approval from the TC and not the existing repo captain.

I feel like if the repo captain is that involved they would probably also be a TC member, for the current projects that is true at least. Do you think there is a benefit from having the repo captians have a say separate from the TC on this?

dial back on the "full authority" wording for the repo captain

That makes sense. I just didn't want to make it seem like the captians have to check with the TC on decision making. Sort of like the chartered Node Working Groups.

I assume the implication is that they will work together, but we should probably outline what should be done if they have conflicts.
I'm not sure if there is prior-art to this.

I see basically all the work in Node is done by a group, not an individual. Our governance says we run a dissent model, so I would see the repo captain roles working the same. Does seem like a good idea to call out.

[dougwilson]

Do you think there is a benefit from having the repo captians have a say separate from the TC on this?

Not necessarily; I don't really have a well-formed opinion, haha. I was just thinking about cases, ultimately. To your point on being TC members, that is where we are today, but I think part of all of this is to likely move further away from that, which is mainly the line I was thinking down.

I just didn't want to make it seem like the captians have to check with the TC on decision making. Sort of like the chartered Node Working Groups.

Yep, definately. I did get where you were going with that, and I 100% agree there on that they should not be asking for permission to make change X, Y, Z, whatever. I guess my thought there is that, in my mind, there would still be some kind of overall direction / principals / whatever that is set by the TC. I can be wrong on this, though, so do not take that statement as fact, haha. But as a hypothetical example (hypothetical because we do not "officially" have this stance) is that the TC may unify the middleware projects around supporting version X & Y of Express and perhaps a Node.js version commitment to match. (again: hypothetical, for the sake of example, not to discuss this specific thing). Full authority on the project direction would seem to imply to me the project could not follow this TC direction / agreement / whatever. Maybe that is a good thing, maybe not, idk.

[gireeshpunathil]

How about from this:

The Express TC can designate captains for individual projects/repos in the
three organizations. These captains are responsible for being the primary
day-to-day maintainers of the repo on a technical and community front.
They will ensure that decisions which effect the Express project at large are
brought up with the TC (in meeting or over GitHub issues) but otherwise will
have the full authority in the direction of the individual project. These captains
will be given full permissions on both the repo as well as the npm packages, and
will follow the community guidelines for publishing and maintaining support.

to this:

The Express TC can designate captains for individual projects/repos in the
three organizations. These captains are responsible for being the primary
day-to-day maintainers of the repo on a technical and community front.
Repo captains are empowered with repo ownership and module publication rights.
When there are conflicts, especially on topics that effect the Express project
at large, captains are responsible to bring it up with the TC and drive
those conflicts to resolution. Captains are also responsible in making sure
community members follow the community guidelines, maintaining the repo
and the registry, as well as in providing user support.

?

only few tweaks, but they key ones are:

• removal of full authority word
• balancing between power and responsibility
• emphasis on importance of TC as well as community guidelines

please feel free to propose amendments, I am not good at documentation and grammar!

[gireeshpunathil]

I would like to know the list of existing repo owners and committers - is it documented somewhere?