Github user chinmaykolhatkar commented on a diff in the pull request:
https://github.com/apache/incubator-apex-site/pull/22#discussion_r56288865
--- 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">
+<tbody>
+ <tr class="a">
+ <td>Consensus</td>
+
+ <td>For this to pass, all voters with binding votes must vote and
there can
+ be no binding vetoes (-1). Consensus votes are rarely required due to
the
+ impracticality of getting all eligible voters to cast a vote.</td>
+ </tr>
+
+ <tr class="b">
+ <td>Lazy Consensus</td>
+
+ <td>Lazy consensus requires 3 binding +1 votes and no binding
vetoes.</td>
+ </tr>
+
+ <tr class="a">
+ <td>Lazy Majority</td>
+
+ <td>A lazy majority vote requires 3 binding +1 votes and more binding
+1
+ votes that -1 votes.</td>
--- End diff --
Does this mean binding +1 should be > binding+non-binding -1?
So, if there are 4 binding +1 and 5 non-binding -1 votes, does that mean
the voting failed?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
