Base Contribution policy. #40
Conversation
|
LGTM |
|
Updated, I forgot what might be the most important part :) |
|
;-) yeah, that's pretty important lol |
|
|
||
| * Encourages new contributions. | ||
| * Encourages contributors to remain involved. | ||
| * Avoids unnecessary processes and beuracracy whenenver possible. |
|
Updated to fix Rich's issues. |
|
|
||
| This document describes a very simple process suitable for most projects | ||
| in the Node.js ecosystem. Projects are encouraged to adopt this whether they | ||
| are hosted in the Node.js or not. |
There was a problem hiding this comment.
hosted in the Node.js ... missing GitHub organization?
There was a problem hiding this comment.
That should say "Foundation" :) We host projects in the foundation that aren't in the github org.
|
Updated to reflect the latest round of feedback. Just a quick reminder, this won't be the contribution policy for any project or WG that has an existing contribution policy. This only applies to new projects entering the foundation without a policy and to any existing projects or WGs that never wrote this kind of thing down (but probably already operate informally like this anyway). All the additional things we have for Node Core (more formal sign-off process, longer review time) will remain and this won't effect them, this is meant to be a scaled down version of that. |
|
|
||
| # Becoming a Committer | ||
|
|
||
| All contributors who land a non-trivial contribution should be on-boarded in a timely manner, |
There was a problem hiding this comment.
land is confusing here. Technically they can't land a contribution until they are made committers. Can we just use make? That also captures non-trivial contributions in terms of issues, as suggested by @Fishrock123
There was a problem hiding this comment.
This idea seems to need a bigger introduction because it's likely going to be a surprising concept for a lot of people. perhaps a lead-in with some basic philosophy about being open and embracing of people willing to invest time in the project through code or other means. Language also needs to make it clear that this is only something that is offered, not automatically given. Being added to a repo just because you submitted a PR without being asked is not something we want to see going on.
There was a problem hiding this comment.
I'm struggling with this introduction. I find it hard to be simple without making a lot of assumptions about the readers prior experience with commit rights which I would like to avoid because I'd like this policy to appeal to as wide an audience of readers as possible.
Also, you can decline commit rights or an invitation to a team in GitHub. I'd rather projects that have no on-boarding simply add people that wait on some explicitly permission to add them when GitHub already does that for us (this is what the website WG does).
|
One last nit, otherwise LGTM. |
If there isn't already, maybe add something to the doc to make it explicit that projects and WGs can and do choose to deviate from it? Make a special point of mentioning nodejs/node as something that has substantial differences and link to the relevant doc in that repo? |
| pull requests. | ||
|
|
||
| No pull request can be merged without being reviewed. Committers should try to avoid merging | ||
| their own pull requests and allow other committers to accept and merge them. |
There was a problem hiding this comment.
It looks like this language has been softened as a result of input from @orangemocha and @jasnell but I still don't think it's right. We actually encourage committers to merge their changes into core and having someone else merge a committers changes is the exceptional case.
Maybe chop off that second sentence and merge the first one in front of the following paragraph.
There was a problem hiding this comment.
We're conflating two different things.
You can't review your own PR, but you can (and you are encouraged to) land it once sufficiently reviewed.
|
Comments inline, mostly the structure of this LGTM, it's a good starting point for new projects. What's missing is the absolute minimum requirements for governance to be acceptable under the foundation. I don't see that as essential work to be done here, probably in conjunction with #35 because a lot of the basic philosophy is in place there, or at least being discussed. Do some hypotheticals to imagine where a new project might go after being incubated, either through necessity (perhaps they burn down to a single contributor!) or evolution (devolution, manipulated or not). I propose that a BDFL governance model is not acceptable under the Foundation as we created it around open and inclusive governance that seeks to ensure that no single individual or company is able to be in a position of control. As I've said in my comments above, this has been a very strong theme for us and I believe it is an essential characteristic of the Foundation and will be thing that defines the Node.js Foundation as distinct from other technology Foundations even if we somehow expand far beyond core (or Node.js!). I don't think it needs to be onerous, and could probably even be achieved in a few lines that sum up basic values and tenets that are core to the Foundation with ultimate enforcement of those in the hands of the TSC—which again, is a last-resort enforcement and resolution body and it also follows a consensus seeking process and also has good representation of the projects in the Foundation. So there's plenty of reason to be confident that the process and boundaries for TLPs are not overbearing where the TSC is concerned. |
|
^ to be absolutely clear, I'm not suggesting that work should be a prerequisite for landing this, it probably is a prerequisite to taking on something any more complicated than libuv, however. |
| ## Vocabulary | ||
|
|
||
| * A **Contributor** is any individual creating or commenting on an issue or pull request. | ||
| * A **Committer** is a subset of contributors who have been given write access to the repository. |
There was a problem hiding this comment.
Suggest a change to "Collaborator"? (That is usually what we refer to it as. Technically, any person with a commit is a "Committer".)
There was a problem hiding this comment.
There is a reason here to diverge slightly from the exact GitHub terminology. For instance, GitHub notes that any user with write access is a "collaborator" in Issues. Those people aren't necessarily project committers that have been on-boarded and should be able to merge PRs, they could be org owners or members of another team that was added for some kind of administrative reason.
|
@rvagg We have the start of that minimum governance guide here that was put together by @jasnell for Working Groups. We also have language in the Project Lifecycle that requires all top level projects adhere to consensus seeking processes which precludes any BDFL situations at the top level, so we have sufficient protections in place. What we don't have yet is a "minimum viable governance document" similar to what this document does for contributing. I think that we might want to hold off on writing that until we work with a few other projects on building out governance that fits those projects. We have a little more experience right now adapting these values to repo level contribution policies than we do building new governance structures over them. |
|
Final call for comments before we bring it to the TSC meeting for final review. |
| Members can be added to the TC at any time. Any committer can nominate another committer | ||
| to the TC and the TC uses its standard consensus seeking process to evaluate whether or | ||
| not to add this new member. Members who do not participate consistently at the level of | ||
| a majority of the other members are expected to resign. |
There was a problem hiding this comment.
Members who do not participate consistently at the level of a majority of the other members are expected to resign
Is this really necessary? If the continued divergence is unhealthy, the TC could always move to remove the member from the TC. But could there not be healthy divergence? What if the group is consistently split into two camps, does the minority camp have to resign?
There was a problem hiding this comment.
I believe the intent here is level of activity, not disposition. If a particular member cannot (or won't) participate as much as the majority of other participants, then they should likely bow out.
I'm wondering, however, if this isn't too strong. Perhaps having a temporary "inactive" status would be better? If a particular member is in the inactive state for too long, they get dropped.
There was a problem hiding this comment.
I don't quite understand how there can be two camps of participation levels.
We need to set the expectation that people who fall of from contributing are expected to step down. This language is intentionally unspecific about what that participation level is, what the timeline is, or what happens if someone refuses to step down. That can be worked out by each TC.
There was a problem hiding this comment.
Ah, I had simply misunderstood the text, sorry. I thought it meant that people who consistently disagree with the majority are expected to resign. In terms of activity, it makes sense and I withdraw my objection.
There was a problem hiding this comment.
Perhaps having a temporary "inactive" status would be better? If a particular member is in the inactive state for too long, they get dropped.
That can be implemented by each TC to meet their particular participation levels. This is intentionally unprescriptive about how to achieve this because the modes of participation will vary from project to project. The langue isn't very strong and puts the onus on the person who is not participating, leaving open whatever process the TC wants to define to ask people to leave who don't do it themselves.
|
Merging per TSC meeting on February 11th 2016. |
Talking to @dougwilson in the express thread made me realize that we don't have a simple explanation of our preferred processes that is suitable for simple project.
Now that we're potentially admitting hundreds of individual repos that feed into a single TC I figured it was important to explain the flow of contributions and the governance in a much plainer way.
I also realized that this would make a good starting point for projects in the Node.js Community.