From e36faf40c05e1b129be6af14ac1f557abefc6fe5 Mon Sep 17 00:00:00 2001 From: Rod Vagg Date: Thu, 4 Dec 2014 20:48:43 +1100 Subject: [PATCH] policy: added contribution policy Policy originally by @isaacs and @othiym23, submitted by @mikeal, committed fresh by @rvagg because .. #22 is kind of a mess PR-URL: https://github.com/iojs/io.js/pull/22 Reviewed-By: Mikeal Rogers Reviewed-By: Fedor Indutny Reviewed-By: Rod Vagg --- CONTRIBUTING.md | 160 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 160 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 4f41eeb24a4a3c..2abf528fd1ef5d 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -165,3 +165,163 @@ not send out notifications when you add commits. [IRC]: http://webchat.freenode.net/?channels=node.js [project maintainers]: https://github.com/joyent/node/wiki/Project-Organization [node-forward discussion repository]: https://github.com/node-forward/discussions/issues + +# Contribution Policy + +Individuals making significant and valuable contributions are given +commit-access to the project. These individuals are identified by the +Technical Committee (TC) and discussed during the weekly TC meeting. + +If you make a significant contribution and are not considered for +commit-access log an issue and it will be brought up in the next TC +meeting. + +Internal pull-requests to solicit feedback are required for any other +non-trivial contribution but left to the discretion of the +contributor. + +Pull requests may be approved by any committer with sufficient +expertise to take full responsibility for the change, according to the +"Landing Patches" protocol described below. + +## Landing Patches + +- All bugfixes require a test case which demonstrates the defect. The + test should *fail* before the change, and *pass* after the change. +- Trivial changes (ie, those which fix bugs or improve performance + without affecting API or causing other wide-reaching impact) may be + landed immediately after review by a committer who did not write the + code, provided that no other committers object to the change. +- If you are unsure, or if you are the author, have someone else + review the change. +- For significant changes wait a full 48 hours (72 hours if it spans a + weekend) before merging so that active contributors who are + distributed throughout the world have a chance to weigh in. +- Controversial changes and **very** significant changes should not be + merged until they have been discussed by the TC which will make any + final decisions. +- Always include the `Reviewed-by: Your Name ` in the + commit message. +- In commit messages also include `Fixes:` that either includes the + **full url** (e.g. `https://github.com/iojs/io.js/issues/...`), + and/or the hash and commit message if the commit fixes a bug in a + previous commit. +- PR's should include their full `PR-URL:` so it's easy to trace a + commit back to the conversation that lead up to that change. +- Double check PR's to make sure the person's **full name** and email + address are correct before merging. +- Except when updating dependencies, all commits should be self + contained. Meaning, every commit should pass all tests. This makes + it much easier when bisecting to find a breaking change. + +# Governance + +This repository is jointly governed by a technical committee, commonly +referred to as the "TC." + +The TC has final authority over this project including: + +* Technical direction +* Project governance and process (including this policy) +* Contribution policy +* GitHub repository hosting +* Conduct guidelines + +## Membership + +Initial membership invitations to the TC were given to individuals who +had been active contributors to io.js, and who have significant +experience with the management of the io.js project. Membership is +expected to evolve over time according to the needs of the project. + +Current membership is: + +``` +Ben Noordhuis (@bnoordhuis) +Bert Belder (@piscisaureus) +Fedor Indutny (@indutny) +Isaac Z. Schlueter (@isaacs) +Nathan Rajlich (@TooTallNate) +TJ Fontaine (@tjfontaine) +Trevor Norris (@trevnorris) +``` + +TC seats are not time-limited. There is no fixed size of the TC. +However, the expected target is between 6 and 12, to ensure adequate +coverage of important areas of expertise, balanced with the ability to +make decisions efficiently. + +There is no specific set of requirements or qualifications for TC +membership beyond these rules. + +The TC may add contributors to the TC by unanimous consensus. + +A TC member may be removed from the TC by voluntary resignation, or by +unanimous consensus of all other TC members. + +Changes to TC membership should be posted in the agenda, and may be +suggested as any other agenda item (see "TC Meetings" below). + +If an addition or removal is proposed during a meeting, and the full +TC is not in attendance to participate, then the addition or removal +is added to the agenda for the subsequent meeting. This is to ensure +that all members are given the opportunity to participate in all +membership decisions. If a TC member is unable to attend a meeting +where a planned membership decision is being made, then their consent +is assumed. + +No more than 1/3 of the TC members may be affiliated with the same +employer. If removal or resignation of a TC member, or a change of +employment by a TC member, creates a situation where more than 1/3 of +the TC membership shares an employer, then the situation must be +immediately remedied by the resignation or removal of one or more TC +members affiliated with the over-represented employer(s). + +## TC Meetings + +The TC meets weekly on a Google hangout. The meeting is run by a +designated moderator, currently `Mikeal Rogers (@mikeal)`. Each +meeting should be published to Youtube. + +Items are added to the TC agenda which are considered contentious or +are modifications of governance, contribution policy, TC membership, +or release process. The intention of the agenda is not to approve or +review all patches, that should happen continuously on GitHub (see +"Contribution Policy"). + +Any community member or contributor can ask that something be added to +the next meeting's agenda by logging a GitHub Issue. Any TC member or +the moderator can add the item to the agenda by a simple +1. The +moderator and the TC cannot veto or remove items. + +Prior to each TC meeting the moderator will email the Agenda to the +TC. TC members can add any items they like to the agenda at the +beginning of each meeting. The moderator and the TC cannot veto or +remove items. + +TC may invite persons or representatives from certain projects to +participate in a non-voting capacity. These invitees currently are: + +* A representative from [build](https://github.com/node-forward/build) + chosen by that project. + +The moderator is responsible for summarizing the discussion of each +agenda item and send it as a pull request after the meeting. + +## Consensus Seeking Process + +The TC follows a [Consensus +Seeking](http://en.wikipedia.org/wiki/Consensus-seeking_decision-making) +decision making model. + +When an agenda item has appeared to reach a consensus the moderator +will ask "Does anyone object?" as a final call for dissent from the +consensus. + +If an agenda item cannot reach a consensus a TC member can call for +either a closing vote or a vote to table the issue to the next +meeting. The call for a vote must be seconded by a majority of the TC +or else the discussion will continue. Simple majority wins. + +Note that changes to TC membership require unanimous consensus. See +"Membership" above.