Cheiron

1. General
   1. News
   2. Blogs
   3. Mission
   4. Guidelines
2. Projects
   1. JSC
   2. Seven
   3. Utils
3. Participate
   1. Overview
   2. Repositories
   3. Mailing lists
   4. References
   5. Issue tracking
4. Misc
   1. License
   2. Credits
   3. Legal

Decision making

All developers are encouraged to participate in the process of decision making, but the decision itself is made by those that have committer status in a project.

All decisions revolve around "action items", most of these require a vote to be approved, either a majority or consensus vote. The votes of the committers are considered "binding".

Action Items

Everything in need for a decision is an action item, however we have only formalized the following ones:

Issues

Issues are bugs, feature requests or other tasks that needs to be tracked. Issues should be entered in the issue tracking system and in general are not voted on, except with regard to the "Priority" and "Fix Version/s" fields as these are related to to the release plan and showstoppers. In case developers who do not agree with a particular issue, or think that an alternative plan would be better, are obligated to inform the group of their feelings.

Release plan

A release plan is used to keep all developers aware of when a release is desired, who will be the release manager, when a version and release branch in the repository is created, and other assorted information to keep developers from tripping over each other. Majority decides each issue in a release plan, or consensus if the issue involves a product change.

Public release

Once the release manager determines testing is complete and all showstoppers for the release have been resolved, he/she shall call for a vote on the public release. Majority approval is required before the public release can be made. Committers who approve a public release (vote +1) are expected to provide ongoing support for that release while it is current.

Showstoppers

Showstoppers are issues that require a fix to be in place before the next (planned) public release, they are listed in the issue tracking system with a priority of "Blocker" and a Fix For version equal to the next release. The priority and release fields for an issue are subject to consensus vote.

Product changes

Changes to a product, including code, configuration and documentation, will appear as action items in the status file. All product changes to the main, version and release code lines are subject to consensus vote.

Voting on formalized action items

The act of voting on an action item carries certain obligations. Voting members are not only stating their opinion, they are also agreeing to help do some work[1].

Any developer or committer ("member") may call for an action item vote on a developer mailing list. It is preferred that a vote be preceded by a formal proposal offered for discussion purposes. The message announcing a vote should contain a Subject beginning with "[VOTE]", and a distinctive one-line summary corresponding to the action item for the vote.

Each vote on an action item can be made in one of four flavors:

There are two types of approval for an action item:

Majority approval

Must receive at least 3 binding +1 votes, more +1 votes than -1 votes and no super veto of the project leader.

Concensus approval

Must receive at least 3 binding +1 votes and no binding vetos.

Except for a public release, all action items are considered to have lazy approval until somebody votes -1, at which point the action item is converted to a formal consensus or majority vote, depending on the type of action item.

Note: 'lazy' means the action item has immediate tactic approval, and it is not necessary to tally the vote until a -1 reply is posted. Once a -1 reply is posted, the vote must be tallied and reported before the action item is considered approved.

Any member may vote on any action item or related issue. When voting on an action item, the project's committers may also include the word "binding" next to their vote, to simplify a tally if it is needed. All binding vetos must also contain an explanation of why the veto is appropriate.

In case the project leader wants to exercise his additional power, as explained in the description of his role, it must include "[INTERVENTION]" in the subject and provide a full explanation for making the formal approval process void.

[1] There is no exact definition of 'some work', it's a rather gray area. The main thing we want to prevent from happening is that people vote (express their opinion), leave the stage and come back when there is another decision to be made.

Voting caveat

• a binding +1 vote on a public release means the project's committer agrees to provide ongoing support for that release while it is current;
• an abstention may have detrimental effects if too many people abstain;
• vetos with no explanation are void. If you disagree with the veto, you should lobby the person who casted the veto. Voters intending to veto an action item should make their opinions known to the group immediately so that the problem can be remedied as early as possible;
• if a committer believes the explanation for a veto is invalid, an affirmation of the veto can be requested. If some other committer does not affirm that the explanation for the veto is valid, the veto shall be void;
• if a dispute over a veto becomes intractable, the project leader will decide on the outcome of the dispute;
• members who wish to discuss a vote before replying, may open another thread to help avoid premature vetos. Any +/-1's or +/-0's posted to an alternate thread, or any other thread not labeled "[VOTE]", are considered conversational, and do not qualify as an valid action-item vote. A "lazy item" remains subject to lazy approval until a valid -1 reply is posted to the "[VOTE]" thread.

Voting results

Most action items are subject to lazy approval, and do not require the posting of a formal result, the only exception is currently the public release action item.

However, any other majority item that receives any -1 reply (later rescinded or not) must be followed by a "[VOTE-RESULT]" message before the action item is considered approved. Likewise, any consensus item that receives any binding veto must post a "[VOTE-RESULT]" message summarizing the result, and show that each veto was rescinded, before it is considered approved. In either case, the member who requested the vote should also post the result within 120 hours (5 days).

Any question regarding the outcome of an action-item vote may be referred by a committer to the CMC for arbitration.

A public release is not considered approved until the release manager or its backup posts a followup message with the legend "[VOTE-RESULT]" summarizing the replies.

Proposal

Proposals are not a formal action item; however, the message offering a proposal should contain a Subject beginning with "[PROPOSAL]". It is strongly recommended that a proposal be circulated before calling for a formal vote. Often, once members have had the chance to critique a proposal, an updated copy of a proposal can be reposted as the vote document.

Often, a long-term plan will be made in the form of a "[PROPOSAL]". If appropriate, the proposed change or feature may then be entered to the project's status file.

Voting on other action items

There are other matters upon which members will vote that do not involve action items. The same general voting structure is used in these cases, except that the "flavors" are taken to mean:

Branching

In any software development project there is a natural tension between revolution and evolution. Many software development teams, open or closed, have a team leader who can declare whether the code base is in evolutionary or revolutionary mode. In a volunteer meritocracy, this type of decision is difficult to make and impossible to enforce. Our meritocracy is fueled by voluntary contributions, and so we must allow everyone to contribute, and then base our final product decisions on the contributions we actually receive. Accordingly, these principles are adopted:

• every committer has the right to revolution, they can establish a skunk branch in which to experiment with new code seperate from the main branch. The only responsibility a committer has when they do this is to announce their plans, and allow others who want to help to do so. Committers working on a revolutionary branch have the right to develop their approach free of interference;
• when a revolution is considered ready for prime time, the committer(s) shall propose a merge to the developers list. At that time, the overall community evaluates whether or not the code is ready to become part of, or to potentially replace, the main branch. Suggestions may be made, changes may be required. Once all issues have been taken care of and the merge is approved, the new code is integrated into the main branch;
• the main branch is the official code line of the project. All evolutionary minded people are welcome to work on it to improve it. Evolutionary work is important and should not stop as it is always unclear when any particular revolution will be ready for prime time or whether it will be officially accepted.