xdocs/decisions.xml - uima-site - Git at Google

 <?xml version="1.0" encoding="ISO-8859-1"?>
 <!--
 Licensed to the Apache Software Foundation (ASF) under one
 or more contributor license agreements.  See the NOTICE file
 distributed with this work for additional information
 regarding copyright ownership.  The ASF licenses this file
 to you under the Apache License, Version 2.0 (the
 "License"); you may not use this file except in compliance
 with the License.  You may obtain a copy of the License at

 https://www.apache.org/licenses/LICENSE-2.0

 Unless required by applicable law or agreed to in writing,
 software distributed under the License is distributed on an
 "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 KIND, either express or implied.  See the License for the
 specific language governing permissions and limitations
 under the License.
 -->
 <document>

   <properties>
     <title>Apache UIMA&#0153; Project Guidelines</title>
     <author email="dev@uima.apache.org"> UIMA Documentation
       Team</author>
   </properties>

   <body>
     <section name="Decision Making">

       <h3 align="center"><font color="#FF0000"><b>Note: This is a working draft
         document.</b>
         </font></h3>
       <p align="center">Discussion of this document is occuring on the uima-dev mailing list.</p><br />

       <p> All
         <a href="roles.html">Contributors</a> are encouraged to participate in
         decisions, but the decision itself is made by those that have
         <a href="roles.html">Committer</a> status in the Project. In other words, the
         Project is a
         &quot;
         <em>Minimum Threshold Meritocracy</em>&quot;.  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).
       </p>

       <h2>Voting</h2>

       <p> The act of voting carries certain obligations. Voting members are not only stating
         their opinion, they are also agreeing to help do the work.
       </p>

       <p> 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).   <!--If the vote is about a change to the source code or
         documentation and the primary author is a Contributor and not a
         Committer, the primary author of what is being changed may also
         cast a binding vote on that issue. -->
       </p>

       <p> 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.
       </p>

       <p>Each vote can be made in one of three flavors:</p>

       <table>
         <tr>
           <td>
             <strong>+1</strong>
           </td>
           <td>
             &quot;Yes,&quot; &quot;Agree,&quot; or &quot;the action should be
             performed.&quot; On some issues this is only binding if the voter has tested the
             action on their own system(s).
           </td>
         </tr>

         <tr>
           <td>
             <strong>+/-0</strong>
           </td>
           <td>
             &quot;Abstain,&quot; &quot;no opinion&quot;. An abstention may have
             detrimental effects if too many people abstain. -0 can indicate lack of support,
             but without any alternative being proposed.
           </td>
         </tr>

         <tr>
           <td>
             <strong>-1</strong>
           </td>
           <td>
             &quot;No&quot; On issues where consensus is required, this vote counts as a
             <strong>veto</strong>. 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.
           </td>
         </tr>

       </table>

       <p>An action item may need one of two types of approval.</p>
       <blockquote>

         <p> An action requiring consensus approval must receive at least
           <strong>3 binding +1</strong> votes and
           <strong>no binding vetos</strong>.
         </p>
         <p> An action requiring majority approval must receive at least
           <strong>3 binding +1</strong> votes and more
           <strong>+1</strong> votes than
           <strong>-1</strong> votes.
         </p>

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

       <blockquote><p>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.
         </p></blockquote>

       <h3>Voting Caveats</h3>

       <ul>
         <!--
         <li>A +1 vote regarding product code is only can only be made binding
         if the voter has tested the action on their own system(s) equipment.</li>

         <li>A binding +1 vote on a public release means the (sub)project's Committer
         agrees to provide ongoing support for that release while it is current.</li>
         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.
         -->
         <li>An abstention may have detrimental effects if too many people abstain.</li>
         <li>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.</li>
         <!--
         <li>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.</li>
         <li>If a dispute over a veto becomes intractable, the PMC may consent to arbitrate
         the matter, and, if appropriate, rescind the veto with a 3/4
         majority vote of the PMC members.</li>
         -->
         <li>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.</li>
       </ul>

       <h2>Action Items</h2>

       <p> All decisions revolve around &quot;
         <em>Action Items.</em>&quot; Action Items consist of the following:
       </p>

       <ul>
         <li><a href="#long_term_plans">Long Term Plans</a></li>
         <li><a href="#short_term_plans">Short Term Plans</a></li>
         <li><a href="#release_plan">Release Plan</a></li>
         <li><a href="#release_testing">Release Testing</a></li>
         <li><a href="#public_testing">Public Release</a></li>
         <li><a href="#showstoppers">Showstoppers</a></li>
         <li><a href="#software_changes">Software Changes</a></li>
       </ul>

       <h3><a id="long_term_plans">Long Term Plans</a></h3>

       <p> 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.
       </p>

       <h3><a id="short_term_plans">Short Term Plans</a></h3>

       <p> 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.
       </p>

       <h3><a id="release_plan">Release Plan</a></h3>

       <p> 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.
       </p>

       <h3><a id="release_testing">Release Testing</a></h3>

       <p> 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.
       </p>

       <h3><a id="public_release">Public Release</a></h3>

       <p>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
         <a href="https://www.apache.org/dev/release.html#approving-a-release">ASF requirements on release voting.</a>

         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.
       </p>

       <h3><a id="showstoppers">Showstoppers</a></h3>

       <p> 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.
       </p>

       <h3><a id="software_changes">Software Changes</a></h3>

       <p> 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.
       </p>

     </section>

   </body>
 </document>
	<?xml version="1.0" encoding="ISO-8859-1"?>
	<!--
	Licensed to the Apache Software Foundation (ASF) under one
	or more contributor license agreements. See the NOTICE file
	distributed with this work for additional information
	regarding copyright ownership. The ASF licenses this file
	to you under the Apache License, Version 2.0 (the
	"License"); you may not use this file except in compliance
	with the License. You may obtain a copy of the License at

	https://www.apache.org/licenses/LICENSE-2.0

	Unless required by applicable law or agreed to in writing,
	software distributed under the License is distributed on an
	"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
	KIND, either express or implied. See the License for the
	specific language governing permissions and limitations
	under the License.
	-->
	<document>

	<properties>
	<title>Apache UIMA Project Guidelines</title>
	<author email="dev@uima.apache.org"> UIMA Documentation
	Team</author>
	</properties>

	<body>
	<section name="Decision Making">

	<h3 align="center"><font color="#FF0000"><b>Note: This is a working draft
	document.</b>
	</font></h3>
	<p align="center">Discussion of this document is occuring on the uima-dev mailing list.</p><br />

	<p> All
	<a href="roles.html">Contributors</a> are encouraged to participate in
	decisions, but the decision itself is made by those that have
	<a href="roles.html">Committer</a> status in the Project. In other words, the
	Project is a
	"
	<em>Minimum Threshold Meritocracy</em>". 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).
	</p>

	<h2>Voting</h2>

	<p> The act of voting carries certain obligations. Voting members are not only stating
	their opinion, they are also agreeing to help do the work.
	</p>

	<p> 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). <!--If the vote is about a change to the source code or
	documentation and the primary author is a Contributor and not a
	Committer, the primary author of what is being changed may also
	cast a binding vote on that issue. -->
	</p>

	<p> 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.
	</p>

	<p>Each vote can be made in one of three flavors:</p>

	<table>
	<tr>
	<td>
	<strong>+1</strong>
	</td>
	<td>
	"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).
	</td>
	</tr>

	<tr>
	<td>
	<strong>+/-0</strong>
	</td>
	<td>
	"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.
	</td>
	</tr>

	<tr>
	<td>
	<strong>-1</strong>
	</td>
	<td>
	"No" On issues where consensus is required, this vote counts as a
	<strong>veto</strong>. 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.
	</td>
	</tr>

	</table>

	<p>An action item may need one of two types of approval.</p>
	<blockquote>

	<p> An action requiring consensus approval must receive at least
	<strong>3 binding +1</strong> votes and
	<strong>no binding vetos</strong>.
	</p>
	<p> An action requiring majority approval must receive at least
	<strong>3 binding +1</strong> votes and more
	<strong>+1</strong> votes than
	<strong>-1</strong> votes.
	</p>

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

	<blockquote><p>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.
	</p></blockquote>

	<h3>Voting Caveats</h3>

	<ul>
	<!--
	<li>A +1 vote regarding product code is only can only be made binding
	if the voter has tested the action on their own system(s) equipment.</li>

	<li>A binding +1 vote on a public release means the (sub)project's Committer
	agrees to provide ongoing support for that release while it is current.</li>
	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.
	-->
	<li>An abstention may have detrimental effects if too many people abstain.</li>
	<li>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.</li>
	<!--
	<li>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.</li>
	<li>If a dispute over a veto becomes intractable, the PMC may consent to arbitrate
	the matter, and, if appropriate, rescind the veto with a 3/4
	majority vote of the PMC members.</li>
	-->
	<li>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.</li>
	</ul>

	<h2>Action Items</h2>

	<p> All decisions revolve around "
	<em>Action Items.</em>" Action Items consist of the following:
	</p>

	<ul>
	<li><a href="#long_term_plans">Long Term Plans</a></li>
	<li><a href="#short_term_plans">Short Term Plans</a></li>
	<li><a href="#release_plan">Release Plan</a></li>
	<li><a href="#release_testing">Release Testing</a></li>
	<li><a href="#public_testing">Public Release</a></li>
	<li><a href="#showstoppers">Showstoppers</a></li>
	<li><a href="#software_changes">Software Changes</a></li>
	</ul>

	<h3><a id="long_term_plans">Long Term Plans</a></h3>

	<p> 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.
	</p>

	<h3><a id="short_term_plans">Short Term Plans</a></h3>

	<p> 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.
	</p>

	<h3><a id="release_plan">Release Plan</a></h3>

	<p> 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.
	</p>

	<h3><a id="release_testing">Release Testing</a></h3>

	<p> 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.
	</p>

	<h3><a id="public_release">Public Release</a></h3>

	<p>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
	<a href="https://www.apache.org/dev/release.html#approving-a-release">ASF requirements on release voting.</a>

	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.
	</p>

	<h3><a id="showstoppers">Showstoppers</a></h3>

	<p> 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.
	</p>

	<h3><a id="software_changes">Software Changes</a></h3>

	<p> 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.
	</p>

	</section>

	</body>
	</document>