Note: This is a working draft
document.
Discussion of this document is occuring on the uima-dev mailing list.
All
Contributors are encouraged to participate in
decisions, but the decision itself is made by those that have
Committer status in the Project. In other words, the
Project is a
"
Minimum Threshold Meritocracy". In addition, release voting
makes a distinction between binding votes and other votes - binding votes being
those made by official members of the PMC (Project Management Committee).
Voting
The act of voting carries certain obligations. Voting members are not only stating
their opinion, they are also agreeing to help do the work.
Any subscriber to the list may vote on any issue or action item. However, the only
binding votes are those cast by a Committer (non release votes),
or a PMC member (for release votes).
Any Contributor or Committer ("member") may call for an action-item vote on the
uima-dev 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 can be made in one of three flavors:
|
+1
|
"Yes," "Agree," or "the action should be
performed." On some issues this is only binding if the voter has tested the
action on their own system(s).
|
|
+/-0
|
"Abstain," "no opinion". An abstention may have
detrimental effects if too many people abstain. -0 can indicate lack of support,
but without any alternative being proposed.
|
|
-1
|
"No" On issues where consensus is required, this vote counts as a
veto. All vetos must contain an explanation of why the veto is
appropriate, and possibly, an alternative. Vetos with no explanation are void.
No veto can be overruled. If you disagree with the veto, you should lobby the
person who cast 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.
|
An action item may need one of two types of approval.
An action requiring consensus approval must receive at least
3 binding +1 votes and
no binding vetos.
An action requiring majority approval must receive at least
3 binding +1 votes and more
+1 votes than
-1 votes.
Except for a public release, All other 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 tacit 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. All action-item votes are lazy except for a public release vote.
Voting Caveats
- An abstention may have detrimental effects if too many people abstain.
- Vetos with no explanation are void. No veto can be overruled. If you disagree with
the veto, you should lobby the person who cast 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.
- 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.
Action Items
All decisions revolve around "
Action Items." Action Items consist of the following:
Long term plans are simply announcements that group members are working on
particular issues related to the Project. These are not voted on, but Committers who
do not agree with a particular plan, or think that an alternative plan would be better,
are obligated to inform the group of their feelings.
Short term plans are announcements that a volunteer is working on a particular set of
documentation or code files with the implication that other volunteers should avoid
them or try to coordinate their changes.
A release plan is used to keep all volunteers aware of when a release is desired, who
will be the release manager, when the repository will be frozen to create a release,
and other assorted information to keep volunteers from tripping over each other.
Lazy majority decides each issue in a release plan.
After a new release is built, it must be tested before being released to the public.
The Release Manager will announce that a release is ready for testing.
Once the Release Manager determines that testing is complete, and all showstoppers
for the release have been resolved, the Release Manager shall call for a vote on the
public release. Release voting is governed by the
ASF requirements on release voting.
Majority approval is required before the public release can be made.
Voters who approve a public release (vote +1) are expected to provide ongoing
support for that release while it is current. The Release Manager must summarize the
outcome of the vote before the public release becomes final.
Showstoppers are issues that require a fix be in place before the next public
release. They are listed in the project's JIRA tracking system, categorized as
"blockers" in order to focus special attention on
these problems. An issue becomes a showstopper when it is listed as such in the project's
JIRA tracking system and remains so by lazy consensus.
Changes to the software of the Project, including code and documentation, will
appear as action items in the project's JIRA tracking system. All software changes to the currently active
repository are subject to lazy consensus.
Decision Making