Skip to content

Commit

Permalink
policy: added contribution policy
Browse files Browse the repository at this point in the history
Policy originally by @isaacs and @othiym23, submitted by @mikeal,
committed fresh by @rvagg because .. #22 is kind of a mess

PR-URL: #22
Reviewed-By: Mikeal Rogers <mikeal.rogers@gmail.com>
Reviewed-By: Fedor Indutny <fedor@indutny.com>
Reviewed-By: Rod Vagg <rod@vagg.org>
  • Loading branch information
rvagg committed Dec 4, 2014
1 parent 0fe7a0d commit 185d11c
Showing 1 changed file with 160 additions and 0 deletions.
160 changes: 160 additions & 0 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -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 <your-email>` 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.

0 comments on commit 185d11c

Please sign in to comment.