You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@logging.apache.org by Curt Arnold <ca...@apache.org> on 2005/07/01 21:25:09 UTC
[DISCUSSION] Bylaw changes
There had been an earlier discussion on the PMC mailing list about
the desirability of modifications to the Logging Services bylaws that
would streamline some processes for the sub-projects other than log4j
which may encounter problems quorum issues on votes, particularly on
votes on release candidates.
The essence of my proposed remedy for the problem was to acknowledge
that since all the projects share a common heritage and domain, that
committers from other projects were competent to "pitch in" on
release candidate testing or other phases while not necessarily
maintaining an on-going development effort with the sub-project. For
example, if log4cxx needed some additional testers to pass a vote to
raise a release to the PMC for review, the vote of a motivated PMC
member from another sub-project should be considered of some merit.
The same goal could be accomplished by just granting cross-sub-
project committer rights, but it seems cleaner to modify the voting
rules to provide some means for these votes to become binding when
the subproject is short of a quorum. In any case, at least three
votes on the PMC would be needed to accept a release candidate, so if
there was ever any question about the viability of a release that had
extra help in the release candidate phase, it could be addressed there.
The following message contains comments on the diff of an draft to
the current bylaws. Based on comments on the PMC list, if we were to
move forward with that approach, I'd modify the sub-project level
votes so that PMC member votes are only binding when there are
insufficient votes for a quorum of sub-project committers.
However, it may be better to restart from either the Jakarta
Guidelines (http://jakarta.apache.org/site/guidelines.html) or a
proposed modifications to the Jakarta Guidelines (http://
jakarta.apache.org/site/proposal.html). The "proposal" indicates
that it is a working draft, but there appears to have been no work on
it in over two years. I've posted a message on
general@jakarta.apache.org (http://marc.theaimsgroup.com/?l=jakarta-
general&m=112020092726359&w=2) about the status of proposal, though
there has not been any response yet.
Based on a quick read, I think it might be better to start with the
Jakarta Guidelines Proposal and tweak it. The initial changes that
I'd propose is adding a PMC lazy approval/lazy consensus on new
committers which would preserve the PMC's responsibility for
controlling committer access but leaving the nomination and initial
vetting of committer candidates to the sub-project. In addition, I'd
add a clause that would allow the votes of PMC members to be
considered binding of sub-project votes that fall short of a quorum
otherwise.
If that seems like a good approach, I'd like to add the Jakarta
proposal in the logging-site module, then modify it for the LS web
site environment (changing links et al), then open it for changes,
iterate and then to come up with a proposal for a formal PMC vote.
Begin forwarded message:
> From: Curt Arnold <ca...@apache.org>
> Date: May 5, 2005 11:13:18 PM CDT
> To: Logging PMC <pm...@logging.apache.org>
> Subject: Bylaw proposal
>
>
> After rereading the bylaws so many times, I see that bylaws
> discussions could be held on general@logging.apache.org. I'll
> leave it to Mark's discretion to forward this message to
> general@logging.apache.org and move any discussion there.
>
> The following is an annotated diff for a bylaws.xml. The
> attachments contain a draft proposals for feedback in XML and HTML.
>
> ===================================================================
> RCS file: /home/cvs/logging-site/src/xdocs/site/bylaws.xml,v
> retrieving revision 1.7
> diff -r1.7 bylaws.xml
> 32c32
> < the <a href="http://incubator.apache.org">Incubator project</
> a> for
> ---
> > the <a href="http://www.apache.org/foundation/how-it-
> works.html">How the ASF Works</a> for
>
> The incubator project is probably not the best place to refer those
> unfamiliar with ASF. I've replaced the link with what I would
> assume is the normative introduction to the Apache process.
>
>
> 77c77
> < <p>All of the volunteers who are contributing time, code,
> ---
> > <p>Developers, also known as contributors, are volunteers
> contributing time, code,
>
> Not a complete sentence.
>
> 80,81c80
> < invited to become a Committer, though the exact timing of such
> < invitations depends on many factors.
> ---
> > nominated for election as a Committer, though the timing
> depends on many factors.
>
> Changed invited to nominated to be consistent with rest of document.
>
>
> 86,89c85,88
> < <p>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.
> ---
> > <p>Committers are responsible for a sub-project's
> > technical management. All sub-project committers have write
> access to the
> > sub-project's source repositories. Committers may cast
> binding votes
> > on any technical discussion regarding the sub-project.
>
>
> The second sentence in the original could be interpreted that any
> committer has commit rights to every LS source code repository.
>
>
> 92,93c91,93
> < <p>Committer access is by invitation only and must be
> approved by
> < lazy consensus of the active PMC members. A Committer is
> ---
> > <p>Committers are nominated by lazy consensus of the sub-
> project
> > active committers and PMC members and confirmed by a lazy
> consensus
> > of the active PMC members. A Committer is
>
> Since a committer may potential disrupt the sub-project or
> introduce tainted code, it is beneficial to have the PMC confirm
> the election and provides a forum for any discussion not suited for
> publication. Having the initial nomination in the public list
> should have brought clarified any issues regarding the committers
> qualifications or ability to work with the community.
>
>
>
> 95c95
> < contributing in any form to the project for over six months. An
> ---
> > contributing in any form to the sub-project for over six
> months. An
>
>
> Should working on log4j preserve my log4cxx commit rights?
>
>
> 227,229c227,229
> < 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
> ---
> > to express their opinion on a particular action by
> > voting, though for each type of action only certain classes
> of voters cast binding votes.
> > Non binding votes are still useful for
>
> Simplied the first sentence and avoided describing the class of
> binding votes since that varies.
>
>
> 231,232c231
> < in the wider Logging Services community. For PMC decisions, only
> < the votes of PMC members are binding.</p>
> ---
> > in the wider Logging Services community.</p>
>
> Last sentence is duplicates later information.
>
> 307a307
> > <th>Forum</th>
> 314,315c314
> < <td>A change made to the codebase of a sub-project and
> committed
> < by a committer. This includes source code, documentation,
> ---
> > <td>A proposed or committed change to the codebase of a sub-
> project including source code, documentation,
>
> Code modification votes can be held before modification and should
> be when the change is expected to be controversial.
>
>
> 317a317
> > <td>Public sub-project list</td>
>
> Added a forum column to the description of votes to describe where
> the discussion and votes should take place.
>
> 319c319
> < <td>Active committers of the relevant sub-project.</td>
> ---
> > <td>Sub-project active committers and active PMC members.</td>
>
> Shortened boilerplate phrasing for commiters. Added PMC members to
> classes of binding votes. This should have trivial potential
> effects for log4j and allows (but does not compell) an interested
> PMC member to assist reaching a quorum in a significant decisions
> without throwing the whole question to the PMC. A PMC member would
> be expected to use the privilege wisely and for the good of both
> the sub-project and the LS project.
>
>
> 324,325c324,325
> < <td>Defines the timetable and actions for a release. The
> plan also
> < nominates a Release Manager.</td>
> ---
> > <td>Defines the timetable, actions and release manager for
> a product release.</td>
> > <td>Public sub-project list</td>
>
> "Nominates a release manager" implied that someone other body would
> need to confirm.
>
>
>
> 327c327,335
> < <td>Active committers of the relevant sub-project</td>
> ---
> > <td>Sub-project active committers and active PMC members.</td>
> > </tr>
> >
> > <tr valign="top">
> > <td> <strong>Product Release Candidate</strong> </td>
> > <td>Submission of a product release candidate to the PMC.</td>
> > <td>Public sub-project list</td>
> > <td>Lazy majority</td>
> > <td>Sub-project active committers and active PMC members.</td>
>
> Added Product Release Candidate vote at the sub-project level
> before PMC consideration.
>
>
> 332,337c340,342
> < <td>When a release of one of the sub-project's products is
> < ready, a vote is required to accept the release as an official
> < release of the Logging Services project.
> <
> < <p>This step ensures the overall supervision by the Logging
> < Services PMC over its sub-projects.</p>
> ---
> > <td>Acceptance of a product release candidate as an official
> > release of the Logging Services project. This vote ensures
> overall supervision
> > of sub-projects by the Logging Services PMC.
> 338a344
> > <td>Public sub-project list</td>
>
> Stated that PMC acceptance vote of release candidate should occur
> on sub-project dev list. Any objections of a PMC member to a
> release should be public at the primary source for information
> about the project.
>
>
> 344,349c350,352
> < <td><strong>Adoption of New Codebase</strong></td>
> < <td>
> <
> < <p>When the codebase for an existing, released product is to
> < be replaced with an alternative codebase. If such a vote
> fails
> < to gain approval, the existing code base will continue.</p>
> ---
> > <td><strong>Sub-project Lifecycle</strong></td>
> > <td>Creation of sub-project, acceptance of a sub-project
> from another ASF project, replacement of existing, released product
> > with an alternative codebase, proposing sub-project as
> top-level ASF project, or terminating project.
> 351,352d353
> < <p>This also covers the creation of new sub-projects within
> < the project</p>
> 53a355
> > <td>Public general or Private PMC list</td>
>
> Expanded the class of actions.
>
>
> 360c362,363
> < <td>Modification of this document</td>
> ---
> > <td>Modification of this document.</td>
> > <td>Public general list</td>
> 366,373c369,378
> < <td><strong>New Committer</strong></td>
> < <td>When a new committer is proposed for a sub-project.
> <
> < <p>The PMC must be informed of the result of the
> < sub-project's vote.
> < </p>
> <
> < </td>
> ---
> > <td><strong>New Committer Nomination</strong></td>
> > <td>Nomination of a sub-project contributor to the PMC for
> advancement to sub-project committer.</td>
> > <td>Public sub-project list</td>
> > <td>Lazy consensus</td>
> > <td>Sub-project active committers and active PMC members.</td>
> > </tr>
> > <tr>
> > <td><strong>New Committer Confirmation</strong></td>
> > <td>Confirmation of nominated sub-project committer
> candidate.</td>
> > <td>Private PMC list</td>
> 375c380
> < <td>Active committers of the relevant sub-project</td>
> ---
> > <td>Active PMC members.</td>
> 379c384,385
> < <td>When a committer is proposed for the PMC</td>
> ---
> > <td>Election of a new PMC Member.</td>
> > <td>Private PMC list</td>
>
> Added two-step process, nomination at sub-project, confirmation at
> PMC.
>
>
> 386c392,393
> < <td> <p>When removal of commit privileges is sought.</p>
> ---
> > <td> <p>Revocation of commit privileges. Committer shall
> refrain from committing
> > during vote or commit privileges may be suspended until
> conclusion of vote.</p>
> 389a397
> > <td>Private PMC list</td>
> 397c405,406
> < <td><p>When removal of a PMC member is sought.</p>
> ---
> > <td><p>Removal of a PMC member. PMC member shall refrain
> from committing
> > during vote or commit privileges may be suspended until
> conclusion of vote.</p>
> 400a410
> > <td>Private PMC list</td>
>
> These drastic steps would only be contemplated in extreme
> situations and suspending the commit privileges until resolution
> would be prudent.
>
>
>
>
>
>
>
Re: [DISCUSSION] Bylaw changes
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 02 July 2005 03:25, Curt Arnold wrote:
> The same goal could be accomplished by just granting cross-sub-
> project committer rights, but it seems cleaner to modify the voting
> rules to provide some means for these votes to become binding when
> the subproject is short of a quorum.
Maybe I am mistaken, but isn't the Board seeking a long-term solution of TLPs
taking full responsibility of the entire codebase under its wings, and that
Jakarta is slowly going to be dismantled to this effect?
May take on that is that it is the intention that committers (which many
top-notch ASF member open says should be the same as the PMC members) of a
TLP should be responsible for the entire codebase, not only a particular
sub-project, which would then automatically solve this issue at LS simply by
adjusting committer authorization.
But again, I may have misunderstood something along the way. Perhaps a
clarification from the Board is in order.
Cheers
Niclas
Re: [DISCUSSION] Bylaw changes
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 1 Jul 2005, Curt Arnold <ca...@apache.org> wrote:
> For example, if log4cxx needed some additional testers to pass a
> vote to raise a release to the PMC for review, the vote of a
> motivated PMC member from another sub-project should be considered
> of some merit.
This sounds like a serious misconception of the PMC's and the
committer's responsibilites.
The PMC is responsible for all releases, so the PMC members and only
the PMC members have binding votes. It shouldn't matter whether a PMC
member is active on any codebase, the vote of that member not only
"has some merit", it is binding. Votes of non-PMC members are
advisory at best.
That's why many people will tell you that all committers should be PMC
members.
> The "proposal" indicates that it is a working draft, but there
> appears to have been no work on it in over two years. I've posted a
> message on general@jakarta.apache.org
> (http://marc.theaimsgroup.com/?l=jakarta-
> general&m=112020092726359&w=2) about the status of proposal, though
> there has not been any response yet.
I think it is seriously out of date anyway.
In Jakarta we've made sure that every subproject has at least three
PMC members by growing the PMC. That way we've ensured the quorum and
no "alien" PMC member is needed to make a release. Honestly, there
are some subprojects who are not represented, mainly for lack of
committers (ORO and regexp for example), and in those cases some PMC
members have "helped out" in the past. But if a subproject doesn't
manage to find three PMC members for a longer stretch of time, it is
in serious trouble anyway.
>> After rereading the bylaws so many times, I see that bylaws
>> discussions could be held on general@logging.apache.org. I'll
>> leave it to Mark's discretion to forward this message to
>> general@logging.apache.org and move any discussion there.
A general ASF policy is that most discussion should be on public lists
- all discussion in the case of development decisions. Private lists
should only ever by used for things that need to be private - like
security issues or discussions on people.
Stefan
RE: [DISCUSSION] Bylaw changes
Posted by Mark Womack <wo...@adobe.com>.
I'm sorry there hasn't been much movement on this. I still need to look at
the Jakarta bylaws myself. Does anyone else have an opinion on jut using
our current bylaws or the Jakarta bylaws as a starting point? Personally, I
would like to start with our own for now and just change what we need to
change regarding the voting stuff.
Would it be possible to generate an html page that shows the bylaws with the
changes applied within it (strike out, additions, etc)? I think that would
make it much easier for everyone to review.
We need to move on this in a timely manner, with appropriate review, so that
we can handle future voting the way we want to.
-Mark
> -----Original Message-----
> From: Curt Arnold [mailto:carnold@apache.org]
> Sent: Friday, July 01, 2005 12:25 PM
> To: Logging General
> Subject: [DISCUSSION] Bylaw changes
>
> There had been an earlier discussion on the PMC mailing list about
> the desirability of modifications to the Logging Services bylaws that
> would streamline some processes for the sub-projects other than log4j
> which may encounter problems quorum issues on votes, particularly on
> votes on release candidates.
>
> The essence of my proposed remedy for the problem was to acknowledge
> that since all the projects share a common heritage and domain, that
> committers from other projects were competent to "pitch in" on
> release candidate testing or other phases while not necessarily
> maintaining an on-going development effort with the sub-project. For
> example, if log4cxx needed some additional testers to pass a vote to
> raise a release to the PMC for review, the vote of a motivated PMC
> member from another sub-project should be considered of some merit.
> The same goal could be accomplished by just granting cross-sub-
> project committer rights, but it seems cleaner to modify the voting
> rules to provide some means for these votes to become binding when
> the subproject is short of a quorum. In any case, at least three
> votes on the PMC would be needed to accept a release candidate, so if
> there was ever any question about the viability of a release that had
> extra help in the release candidate phase, it could be addressed there.
>
> The following message contains comments on the diff of an draft to
> the current bylaws. Based on comments on the PMC list, if we were to
> move forward with that approach, I'd modify the sub-project level
> votes so that PMC member votes are only binding when there are
> insufficient votes for a quorum of sub-project committers.
>
> However, it may be better to restart from either the Jakarta
> Guidelines (http://jakarta.apache.org/site/guidelines.html) or a
> proposed modifications to the Jakarta Guidelines (http://
> jakarta.apache.org/site/proposal.html). The "proposal" indicates
> that it is a working draft, but there appears to have been no work on
> it in over two years. I've posted a message on
> general@jakarta.apache.org (http://marc.theaimsgroup.com/?l=jakarta-
> general&m=112020092726359&w=2) about the status of proposal, though
> there has not been any response yet.
>
> Based on a quick read, I think it might be better to start with the
> Jakarta Guidelines Proposal and tweak it. The initial changes that
> I'd propose is adding a PMC lazy approval/lazy consensus on new
> committers which would preserve the PMC's responsibility for
> controlling committer access but leaving the nomination and initial
> vetting of committer candidates to the sub-project. In addition, I'd
> add a clause that would allow the votes of PMC members to be
> considered binding of sub-project votes that fall short of a quorum
> otherwise.
>
> If that seems like a good approach, I'd like to add the Jakarta
> proposal in the logging-site module, then modify it for the LS web
> site environment (changing links et al), then open it for changes,
> iterate and then to come up with a proposal for a formal PMC vote.
>
>
> Begin forwarded message:
>
> > From: Curt Arnold <ca...@apache.org>
> > Date: May 5, 2005 11:13:18 PM CDT
> > To: Logging PMC <pm...@logging.apache.org>
> > Subject: Bylaw proposal
> >
> >
> > After rereading the bylaws so many times, I see that bylaws
> > discussions could be held on general@logging.apache.org. I'll
> > leave it to Mark's discretion to forward this message to
> > general@logging.apache.org and move any discussion there.
> >
> > The following is an annotated diff for a bylaws.xml. The
> > attachments contain a draft proposals for feedback in XML and HTML.
> >
> > ===================================================================
> > RCS file: /home/cvs/logging-site/src/xdocs/site/bylaws.xml,v
> > retrieving revision 1.7
> > diff -r1.7 bylaws.xml
> > 32c32
> > < the <a href="http://incubator.apache.org">Incubator project</
> > a> for
> > ---
> > > the <a href="http://www.apache.org/foundation/how-it-
> > works.html">How the ASF Works</a> for
> >
> > The incubator project is probably not the best place to refer those
> > unfamiliar with ASF. I've replaced the link with what I would
> > assume is the normative introduction to the Apache process.
> >
> >
> > 77c77
> > < <p>All of the volunteers who are contributing time, code,
> > ---
> > > <p>Developers, also known as contributors, are volunteers
> > contributing time, code,
> >
> > Not a complete sentence.
> >
> > 80,81c80
> > < invited to become a Committer, though the exact timing of such
> > < invitations depends on many factors.
> > ---
> > > nominated for election as a Committer, though the timing
> > depends on many factors.
> >
> > Changed invited to nominated to be consistent with rest of document.
> >
> >
> > 86,89c85,88
> > < <p>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.
> > ---
> > > <p>Committers are responsible for a sub-project's
> > > technical management. All sub-project committers have write
> > access to the
> > > sub-project's source repositories. Committers may cast
> > binding votes
> > > on any technical discussion regarding the sub-project.
> >
> >
> > The second sentence in the original could be interpreted that any
> > committer has commit rights to every LS source code repository.
> >
> >
> > 92,93c91,93
> > < <p>Committer access is by invitation only and must be
> > approved by
> > < lazy consensus of the active PMC members. A Committer is
> > ---
> > > <p>Committers are nominated by lazy consensus of the sub-
> > project
> > > active committers and PMC members and confirmed by a lazy
> > consensus
> > > of the active PMC members. A Committer is
> >
> > Since a committer may potential disrupt the sub-project or
> > introduce tainted code, it is beneficial to have the PMC confirm
> > the election and provides a forum for any discussion not suited for
> > publication. Having the initial nomination in the public list
> > should have brought clarified any issues regarding the committers
> > qualifications or ability to work with the community.
> >
> >
> >
> > 95c95
> > < contributing in any form to the project for over six months. An
> > ---
> > > contributing in any form to the sub-project for over six
> > months. An
> >
> >
> > Should working on log4j preserve my log4cxx commit rights?
> >
> >
> > 227,229c227,229
> > < 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
> > ---
> > > to express their opinion on a particular action by
> > > voting, though for each type of action only certain classes
> > of voters cast binding votes.
> > > Non binding votes are still useful for
> >
> > Simplied the first sentence and avoided describing the class of
> > binding votes since that varies.
> >
> >
> > 231,232c231
> > < in the wider Logging Services community. For PMC decisions, only
> > < the votes of PMC members are binding.</p>
> > ---
> > > in the wider Logging Services community.</p>
> >
> > Last sentence is duplicates later information.
> >
> > 307a307
> > > <th>Forum</th>
> > 314,315c314
> > < <td>A change made to the codebase of a sub-project and
> > committed
> > < by a committer. This includes source code, documentation,
> > ---
> > > <td>A proposed or committed change to the codebase of a sub-
> > project including source code, documentation,
> >
> > Code modification votes can be held before modification and should
> > be when the change is expected to be controversial.
> >
> >
> > 317a317
> > > <td>Public sub-project list</td>
> >
> > Added a forum column to the description of votes to describe where
> > the discussion and votes should take place.
> >
> > 319c319
> > < <td>Active committers of the relevant sub-project.</td>
> > ---
> > > <td>Sub-project active committers and active PMC members.</td>
> >
> > Shortened boilerplate phrasing for commiters. Added PMC members to
> > classes of binding votes. This should have trivial potential
> > effects for log4j and allows (but does not compell) an interested
> > PMC member to assist reaching a quorum in a significant decisions
> > without throwing the whole question to the PMC. A PMC member would
> > be expected to use the privilege wisely and for the good of both
> > the sub-project and the LS project.
> >
> >
> > 324,325c324,325
> > < <td>Defines the timetable and actions for a release. The
> > plan also
> > < nominates a Release Manager.</td>
> > ---
> > > <td>Defines the timetable, actions and release manager for
> > a product release.</td>
> > > <td>Public sub-project list</td>
> >
> > "Nominates a release manager" implied that someone other body would
> > need to confirm.
> >
> >
> >
> > 327c327,335
> > < <td>Active committers of the relevant sub-project</td>
> > ---
> > > <td>Sub-project active committers and active PMC members.</td>
> > > </tr>
> > >
> > > <tr valign="top">
> > > <td> <strong>Product Release Candidate</strong> </td>
> > > <td>Submission of a product release candidate to the PMC.</td>
> > > <td>Public sub-project list</td>
> > > <td>Lazy majority</td>
> > > <td>Sub-project active committers and active PMC members.</td>
> >
> > Added Product Release Candidate vote at the sub-project level
> > before PMC consideration.
> >
> >
> > 332,337c340,342
> > < <td>When a release of one of the sub-project's products is
> > < ready, a vote is required to accept the release as an official
> > < release of the Logging Services project.
> > <
> > < <p>This step ensures the overall supervision by the Logging
> > < Services PMC over its sub-projects.</p>
> > ---
> > > <td>Acceptance of a product release candidate as an official
> > > release of the Logging Services project. This vote ensures
> > overall supervision
> > > of sub-projects by the Logging Services PMC.
> > 338a344
> > > <td>Public sub-project list</td>
> >
> > Stated that PMC acceptance vote of release candidate should occur
> > on sub-project dev list. Any objections of a PMC member to a
> > release should be public at the primary source for information
> > about the project.
> >
> >
> > 344,349c350,352
> > < <td><strong>Adoption of New Codebase</strong></td>
> > < <td>
> > <
> > < <p>When the codebase for an existing, released product is to
> > < be replaced with an alternative codebase. If such a vote
> > fails
> > < to gain approval, the existing code base will continue.</p>
> > ---
> > > <td><strong>Sub-project Lifecycle</strong></td>
> > > <td>Creation of sub-project, acceptance of a sub-project
> > from another ASF project, replacement of existing, released product
> > > with an alternative codebase, proposing sub-project as
> > top-level ASF project, or terminating project.
> > 351,352d353
> > < <p>This also covers the creation of new sub-projects within
> > < the project</p>
> > 53a355
> > > <td>Public general or Private PMC list</td>
> >
> > Expanded the class of actions.
> >
> >
> > 360c362,363
> > < <td>Modification of this document</td>
> > ---
> > > <td>Modification of this document.</td>
> > > <td>Public general list</td>
> > 366,373c369,378
> > < <td><strong>New Committer</strong></td>
> > < <td>When a new committer is proposed for a sub-project.
> > <
> > < <p>The PMC must be informed of the result of the
> > < sub-project's vote.
> > < </p>
> > <
> > < </td>
> > ---
> > > <td><strong>New Committer Nomination</strong></td>
> > > <td>Nomination of a sub-project contributor to the PMC for
> > advancement to sub-project committer.</td>
> > > <td>Public sub-project list</td>
> > > <td>Lazy consensus</td>
> > > <td>Sub-project active committers and active PMC members.</td>
> > > </tr>
> > > <tr>
> > > <td><strong>New Committer Confirmation</strong></td>
> > > <td>Confirmation of nominated sub-project committer
> > candidate.</td>
> > > <td>Private PMC list</td>
> > 375c380
> > < <td>Active committers of the relevant sub-project</td>
> > ---
> > > <td>Active PMC members.</td>
> > 379c384,385
> > < <td>When a committer is proposed for the PMC</td>
> > ---
> > > <td>Election of a new PMC Member.</td>
> > > <td>Private PMC list</td>
> >
> > Added two-step process, nomination at sub-project, confirmation at
> > PMC.
> >
> >
> > 386c392,393
> > < <td> <p>When removal of commit privileges is sought.</p>
> > ---
> > > <td> <p>Revocation of commit privileges. Committer shall
> > refrain from committing
> > > during vote or commit privileges may be suspended until
> > conclusion of vote.</p>
> > 389a397
> > > <td>Private PMC list</td>
> > 397c405,406
> > < <td><p>When removal of a PMC member is sought.</p>
> > ---
> > > <td><p>Removal of a PMC member. PMC member shall refrain
> > from committing
> > > during vote or commit privileges may be suspended until
> > conclusion of vote.</p>
> > 400a410
> > > <td>Private PMC list</td>
> >
> > These drastic steps would only be contemplated in extreme
> > situations and suspending the commit privileges until resolution
> > would be prudent.
> >
> >
> >
> >
> >
> >
> >