apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (APEXCORE-321) Document voting rules
Date Wed, 16 Mar 2016 07:00:38 GMT

    [ https://issues.apache.org/jira/browse/APEXCORE-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15196899#comment-15196899

ASF GitHub Bot commented on APEXCORE-321:

Github user chinmaykolhatkar commented on a diff in the pull request:

    --- 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>
    +associated rights and responsibilities. These roles govern what tasks an individual
    +may perform within the project. The roles are defined in the following sections:
    +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&rsquo;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
    +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.
    +The project&rsquo;s Committers are responsible for the project&rsquo;s technical
    +management. All committers have write access to the project&rsquo;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
    +&ldquo;emeritus/inactive&rdquo; by not contributing in any form to the project
    +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
    +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,
    +###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&rsquo;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
    +&ldquo;emeritus/inactive&rdquo; by not contributing in any form to the project
    +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&rsquo;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
    +&ldquo;lazy consensus&rdquo; approval. This section defines how voting is performed,
    +the types of approvals, and which types of decision require which type of
    +Decisions regarding the project are made by votes on the primary project
    +development mailing list (<a class="externalLink" href=
    +"mailto:dev@apex.apache.org)">dev@apex.apache.org)</a>. Where necessary, PMC
    +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">
    +  <tr class="a">
    +    <td>+1</td>
    +    <td>&ldquo;Yes,&rdquo; &ldquo;Agree,&rdquo; or &ldquo;the
action should be
    +    performed.&rdquo; In general, this vote also indicates a willingness on the
    +    behalf of the voter in &ldquo;making it happen&rdquo;</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>
    +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
    --- End diff --
    The sentence "For technical decisions..." highlights a different meaning of binding votes
in a certain context. Can this be made bold or highlighted in a certain way? (not sure bold
is appropriate in bylaws).

> 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

View raw message