[
https://issues.apache.org/jira/browse/APEXCORE-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15196920#comment-15196920
]
ASF GitHub Bot commented on APEXCORE-321:
-----------------------------------------
Github user chinmaykolhatkar commented on a diff in the pull request:
https://github.com/apache/incubator-apex-site/pull/22#discussion_r56289791
--- Diff: src/md/bylaws.md ---
@@ -0,0 +1,381 @@
+#*** draft subject to top level project approval ***
+#Apache Apex Project Bylaws
+
+This document defines the bylaws under which the Apache Apex project
operates. It
+defines the roles and responsibilities of the project, who may vote, how
voting works,
+how conflicts are resolved, etc.
+
+Apex is a project of the <a class="externalLink" href=
+"http://www.apache.org/foundation/";>Apache Software Foundation</a>. The
Foundation
+holds the copyright on Apache code including the code in the Apex
codebase. The
+<a class="externalLink"
href="http://www.apache.org/foundation/faq.html";>Foundation
+FAQ</a> explains the operation and background of the foundation.
+
+Apex is typical of Apache projects in that it operates under a set of
principles,
+known collectively as the "Apache Way". If you are new to Apache
+development, please refer to the <a class="externalLink" href=
+"http://incubator.apache.org/";>Incubator project</a> for more information
on how Apache
+projects operate.
+
+##Roles and Responsibilities
+
+Apache projects define a <a class="externalLink" href=
+"http://www.apache.org/foundation/how-it-works.html#roles";>set of
roles</a> with
+associated rights and responsibilities. These roles govern what tasks an
individual
+may perform within the project. The roles are defined in the following
sections:
+
+###Users
+
+The most important participants in the project are people who use our
software.
+The majority of our developers start out as users and guide their
development
+efforts from the user’s perspective.
+
+Users contribute to the Apache projects by providing feedback to
developers in
+the form of bug reports and feature suggestions. As well, users
participate in the
+Apache community by helping other users on mailing lists and user support
+forums.
+
+###Contributors
+
+All of the volunteers who are contributing time, code, documentation, or
+resources to the Apex Project. A contributor that makes sustained, welcome
+contributions to the project may be invited to become a Committer, though
the exact
+timing of such invitations depends on many factors.
+
+###Committers
+
+The project’s Committers are responsible for the project’s
technical
+management. All committers have write access to the project’s source
+repositories. Committers may cast binding votes on any technical discussion
+regarding the project.
+
+Committer access is by invitation only and must be approved by lazy
consensus of
+the active PMC members. A Committer may request removal of their commit
privileges
+by their own declaration. A committer will be considered
+“emeritus/inactive” by not contributing in any form to the
project for
+over 1 year. An emeritus committer may request reinstatement of commit
access from
+the PMC. Such reinstatement is subject to lazy consensus of active PMC
members
+
+Commit access can be revoked by a unanimous vote of all the active PMC
members
+(except the committer in question if they are also a PMC member).
+
+All Apache committers are required to have a signed Contributor License
+Agreement (<a class="externalLink" href=
+"http://www.apache.org/licenses/icla.txt";>CLA</a>) on file with the Apache
Software
+Foundation. There is a <a class="externalLink" href=
+"http://www.apache.org/dev/committers.html";>Committer FAQ</a> which
provides more
+details on the requirements for Committers
+
+A committer who makes a sustained contribution to the project may be
invited to
+become a member of the PMC. The form of contribution is not limited to
code. It can
+also include code review, helping out users on the mailing lists,
documentation,
+etc.
+
+
+###Project Management Committee
+
+The Project Management Committee (PMC) for Apache Apex was created by a
+resolution of the board of the Apache Software Foundation on ***TBD***. The
+PMC is responsible to the board and the ASF for the management and
oversight of the
+Apache Apex codebase. The responsibilities of the PMC include:
+
+* Deciding what is distributed as products of the project. In particular
all releases must be approved by the PMC
+* Maintaining the project’s shared resources, including the codebase
repository, mailing lists, websites.
+* Speaking on behalf of the project
+* Resolving license disputes regarding products of the project
+* Nominating new PMC members and committers
+* Maintaining these bylaws and other guidelines of the project
+
+Membership of the PMC is by invitation only and must be approved by a lazy
+consensus of active PMC members. A PMC member is considered
+“emeritus/inactive” by not contributing in any form to the
project for
+over one year. An emeritus PMC member may request reinstatement to the
PMC. Such
+reinstatement is subject to lazy consensus of active PMC members. A PMC
member may
+resign their membership from the PMC by their own declaration. Membership
of the
+PMC can be revoked by an unanimous vote of all the active PMC members
other than
+the member in question.
+
+The chair of the PMC is appointed by the ASF board. The chair is an office
+holder of the Apache Software Foundation (Vice President, Apache Apex) and
has
+primary responsibility to the board for the management of the projects
within the
+scope of the Apex PMC. The chair reports to the board quarterly on
developments
+within the Apex project. The PMC may consider the position of PMC chair
annually,
+and if supported by a successful vote to change the PMC chair, may
recommend a new
+chair to the board. Ultimately, however, it is the board’s
responsibility who
+it chooses to appoint as the PMC chair.
+
+##Decision Making
+
+Within the Apex project, different types of decisions require different
forms of
+approval. For example, the previous section describes several decisions
which require
+“lazy consensus” approval. This section defines how voting is
performed,
+the types of approvals, and which types of decision require which type of
+approval.
+
+###Voting
+
+Decisions regarding the project are made by votes on the primary project
+development mailing list (<a class="externalLink" href=
+"mailto:[email protected])">[email protected])</a>. Where necessary,
PMC voting
+may take place on the private Apex PMC mailing list. Votes are clearly
indicated by
+subject line starting with [VOTE]. Votes may contain multiple items for
approval
+and these should be clearly separated. Voting is carried out by replying
to the
+vote mail. Voting may take four flavours:
+
+<table border="0" class="table table-striped">
+<tbody>
+ <tr class="a">
+ <td>+1</td>
+
+ <td>“Yes,” “Agree,” or “the action
should be
+ performed.” In general, this vote also indicates a willingness
on the
+ behalf of the voter in “making it happen”</td>
+ </tr>
+
+ <tr class="b">
+ <td>+0</td>
+
+ <td>This vote indicates a willingness for the action under
consideration to
+ go ahead. The voter, however will not be able to help.</td>
+ </tr>
+
+ <tr class="a">
+ <td>-0</td>
+
+ <td>This vote indicates that the voter does not, in general, agree
with the
+ proposed action but is not concerned enough to prevent the action going
+ ahead.</td>
+ </tr>
+
+ <tr class="b">
+ <td>-1</td>
+
+ <td>This is a negative vote. On issues where consensus is required,
this vote
+ counts as a veto. All vetoes must contain an explanation of why the
veto is
+ appropriate. Vetoes with no explanation are void. It may also be
appropriate
+ for a -1 vote to include an alternative course of action.</td>
+ </tr>
+</tbody>
+</table>
+
+All participants in the Apex project are encouraged to show their
agreement with
+or against a particular action by voting. For technical decisions, only
the votes
+of active committers are binding. Non binding votes are still useful for
those with
+binding votes to understand the perception of an action in the wider Apex
community.
+For PMC decisions, only the votes of PMC members are binding.
+
+Voting can also be applied to changes made to the Apex codebase. These
typically
+take the form of a veto (-1) in reply to the commit message sent when the
commit is
+made.
+
+###Approvals
+
+These are the types of approvals that can be sought. Different actions
require
+different types of approvals:
+
+<table border="0" class="table table-striped">
--- End diff --
Would it make more sense to order this table content from Strict to Relaxed
voting?
> Document voting rules
> ---------------------
>
> Key: APEXCORE-321
> URL: https://issues.apache.org/jira/browse/APEXCORE-321
> Project: Apache Apex Core
> Issue Type: Task
> Reporter: Chris Nauroth
> Assignee: Thomas Weise
> Labels: tlp
>
> CS30
> Documented voting rules are used to build consensus when discussion is not
> sufficient.
> I couldn't find any statement of this. Example:
> http://hadoop.apache.org/bylaws.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
