New Contribution Policy

[mikeal]

This is very much still a work in progress.

Recently, I wrote up a new "Base Contribution Policy" that was approved by the TSC. While I was writing this up one of the use cases I was thinking about was Express.

The goal of the policy is to be a starting point. Projects are expected to make changes and adjustments to it for their own needs.

With that in mind I thought it best to begin this PR with the base policy so that the Express contributors can read it, ask questions, and suggest modifications or potentially just outright reject it if it's too far away from what people would like.

The old policy is still intact and was moved to a "Collaborator Guide" because there's still some great stuff in there. I'll leave it to this group to suggest how we best link to this guide in the Contributing file and to propose any modifications to that guide where it might be effected by this new Contributing file.

Also, keep in mind that the specific governance process is left out of this document intentionally. That can be defined in a separate "Governance" document once there is agreement on this document.

A few questions I have:

1. Is the best way for Express to operate at this time to create a unified list of committers and TC members across all 3 orgs?
2. If the answer to 1 is true then we need to do a good job of documenting the org structures for on-boarding and we may want to consider running any existing committers through that on-boarding since the scope of their access may be increased.

[mikeal]

The diff may be a little difficult to read as a whole. You can use https://github.com/nodejs/TSC/blob/master/BasePolicies/CONTRIBUTING.md for reference until we start making modifications.

[Knighton910]

LGTM @mikeal

The diff may be a little difficult to read as a whole. You can use https://github.com/nodejs/TSC/blob/master/BasePolicies/CONTRIBUTING.md for reference until we start making modifications.

[ritch]

The goal of the policy is to be a starting point.

This actually looks pretty good, even as more than a starting point. It would be nice to get @jasnell's comments on this though. He is actually getting married today, so perhaps we can hold of on landing this until he has a chance to read / comment?

My one comment is that the last paragraph in the "TC Process" section goes a bit beyond the scope of this document and might be better suited for the gov doc.

[dougwilson]

so perhaps we can hold of on landing this until he has a chance to read / comment?

@ritch, he is not a member of the TC or nor a contributor, only a mentor. It is up to the TC/contributors on what should be done, and the mentors are only here to guide the TC/contributors by helping, not by influencing the direction.

[ritch]

guide the TC/contributors by helping, not by influencing the direction.

All I'm saying is lets give him a chance to read this so he can help. I think thats pretty reasonable.

[dougwilson]

so he can help. I think thats pretty reasonable.

What I'm' asking with is help with what? Either the contributors agree on it or not. If not, they can reach out to the mentors with specific questions, ideally in comments on this pull request.

[ritch]

On these questions:

A few questions I have:

Is the best way for Express to operate at this time to create a unified list of committers and TC members across all 3 orgs?
If the answer to 1 is true then we need to do a good job of documenting the org structures for on-boarding and we may want to consider running any existing committers through that on-boarding since the scope of their access may be increased.

[mikeal]

@ritch the TC section limits itself to concerns regarding the process of contribution escalation and any related concerns. Specific processes like meetings, tags, etc, those are all project specific and are not covered but the document does enough to infer that such processes should exist and be defined elsewhere.

[dougwilson]

@ritch, those are questions for the contributors here, not for the mentors, AFAIK. It is up to the contributors/TC to decide what is best and ask the mentors for help. In this case, the mentors are simply asking the contributors what they want to do, what what @jasnell wants to do.

[mikeal]

This actually looks pretty good, even as more than a starting point. It would be nice to get @jasnell's comments on this though. He is actually getting married today, so perhaps we can hold of on landing this until he has a chance to read / comment?

There will be plenty of time for everyone to comment. @jasnell actually already commented quite a lot in the creation process and the eventually passing of this by the TSC so I expect his feedback is mostly already there.

[ritch]

There will be plenty of time for everyone to comment.

Sounds reasonable.

@jasnell actually already commented quite a lot in the creation process and the eventually passing of this by the TSC so I expect his feedback is mostly already there.

Ah I wasn't aware of this. I'm sure this isn't an issue then.

[dougwilson]

1.Is the best way for Express to operate at this time to create a unified list of committers and TC members across all 3 orgs?

So there are pros/cons here in regards to the bootstrapping into the foundation. As it stands, not doing this is an issue, because otherwise there would be only myself as the TC/contributor for all those, which doesn't make sense. Since there is so little to start with, I think we must have a unified TC and collaboration until such a time there are enough members to necessitate dividing them up.

In addition, this repo is currently destined to be devoid of all code, and split up amongst the orgs. This means that keeping it small will only hold Express back, because the collaborators will not have the necessary ability or even expertise to effectively guide contributions to the correct repos and make their contributions there. The is the entire reason everything joined the foundation together.

As for the document in the pull request, I don't have any immediate concerns.

[dougwilson]

The only things I can see operating independently right now are a couple middleware in the expressjs org that actually have an existing collaborator base.

[mikeal]

While I don't disagree with this policy... its actually pretty standard / reasonable... why are we including this in the contributing doc?

Contributing.md is special in that it gets referenced during new PR and Issues by GitHub. If you want something to be read by new contributors it's best to put it in that file.

[dougwilson]

I think a really good way to know if this is the most appropriate policy for Express is that the outlined rules should apply retroactively, as in all existing collaborators should meet the requirements outlined in this document to have actually become collaborators. If this is not the case, then we should change the document in order to meet this condition so we have a better place to iterate from and all of the community has the same opportunity to join as a collaborator that the current ones have had.

It also gives a good way to know if this is a good starting point, because we'll have a better understanding of the current policy to iterate towards the Node.js policy.

[Knighton910]

+1 @dougwilson

It also gives a good way to know if this is a good starting point, because we'll have a better understanding of the current policy to iterate towards the Node.js policy.

[dougwilson]

I also think that finally getting a contributor policy adopted, we can apply it to answer the questions I've brought up before which is "who is really on the collaborators and who is really on the TC?" There are a lot of users both in the new GitHub organizations and in the old GitHub organization, and it's hard to know exactly which users should be on the TC or collaborators.

@jasnell made a first pass at trying to create these groups, but we are left with various inactive members and even ones that still have not accepted the organization invite, since the existing members in the organization were largely historic in nature and not necessarily active.

We can take those existing lists and set them aside and apply a true, open contribution policy against the existing repositories and determine which users to invite as collaborators, committers, and TC members based on the basic tests laid out in the adopted policy here. An example would be that in this policy, a very low-bar requirement is "who land a non-trivial contribution", and so we could use a tool like the one used to generate the reports in Node.js (nodejs/node#3728) to gather the list of active committers across the three organizations and work from that list to determine this initial committer team.

[jasnell]

Appreciate it @ritch but as @mikeal indicated I'd already provided feedback on these bits previously when they were being drafted. I'm happy to see this moving forward.

[dougwilson]

There were no objections to the policy contained in here, and it was agreed to in the meeting (expressjs/discussions#1) and so I have merged at @mikeal's agreement :)! Welcome the first Express contributing guide on how to become a collaborator!