Guidelines have been added here:

http://apex.incubator.apache.org/contributing.html

Would the status page be the right place to document the PPMC member list?

http://incubator.apache.org/projects/apex.html




On Sat, Nov 21, 2015 at 7:03 PM, Amol Kekre <[email protected]> wrote:

> Taylor,
> The intention is to list guidelines to be a committer and (P)PMC member. We
> do expect to grow both the committer list and the (P)PMC list drastically
> in near future.
>
> Thks,
> Amol
>
>
> On Fri, Nov 20, 2015 at 8:07 PM, P. Taylor Goetz <[email protected]>
> wrote:
>
> > Another option worth considering is Committer == (P)PMC. In other words,
> > you don't make much of a distinction. You vote on and invite new members
> to
> > become both.
> >
> > A number of projects have gone this route, as it can make things easier
> > when adding new members and reduce the number of votes/discussions that
> > need to take place.
> >
> > If Apex goes the Committer != (P)PMC route, I would suggest establishing
> > guidelines for advancing from Committer to PMC. What you don't want is a
> > perceived hierarchy or us/them situation, with no clear path for
> > advancement.
> >
> > -Taylor
> >
> > > On Nov 20, 2015, at 4:10 PM, York, Brennon <
> [email protected]>
> > wrote:
> > >
> > > All, I’ve done quite a bit of reading on this topic and, now that I
> feel
> > I’m informed on how things should work given the documentation on the
> > Apache site [1][2][3][4][5], here’s my 2c on the whole discussion.
> > >
> > > First I want to clarify the roles and responsibilities of a Committer
> > and a PMC Member according to Apache.
> > >
> > > Committer[6]
> > > A committer is a developer that was given write access to the code
> > repository and has a signed Contributor License Agreement (CLA) on file.
> > They have an apache.org mail address. Not needing to depend on other
> > people for the patches, they are actually making short-term decisions for
> > the project. The PMC can (even tacitly) agree and approve it into
> > permanency, or they can reject it. Remember that the PMC makes the
> > decisions, not the individual committers.
> > >
> > > PMC Member[7]
> > > A PMC member is a developer or a committer that was elected due to
> merit
> > for the evolution of the project and demonstration of commitment. They
> have
> > write access to the code repository, an apache.org mail address, the
> > right to vote for the community-related decisions and the right to
> propose
> > an active user for committership. The PMC as a whole is the entity that
> > controls the project, nobody else. In particular, the PMC must vote on
> any
> > formal release of their project's software products.
> > >
> > > The biggest difference I see is that a Committer does not have the
> power
> > to direct the *long term* roadmap for the project while a PMC Member can,
> > esp. as they (PMC Members) can reject patches as they see necessary for
> the
> > longevity of the project (including patches from Committers).
> Additionally
> > I haven’t found any documentation that changes the above definitions in
> the
> > context for an incubating project. Correct me if I’m wrong here.
> > >
> > > Now, if we (as the Apex committers / PPMC members) decide that we
> should
> > remove a majority of us (myself included) then I, personally, am okay
> with
> > that, but the better question I see would be *why* would we do that? If
> the
> > idea is to “trim the tree” so to speak and only keep a smaller set of
> > members in power (i.e. as PPMC members) then it is implying that the
> > original set of committers (that were proposed) should not have been so
> as
> > they cannot effectively direct the project. That’s an issue with the
> > original proposal and, I feel, should be addressed up front if so. More
> > than that though I assume each member that is on the original proposal is
> > actually completely and acutely able to aid in the direction of the
> project
> > and that is why they were chosen in the first place.
> > >
> > > If the goal is then to quickly “build back” a larger PPMC committee
> > based on current active contributions I feel that this is going against
> the
> > Apache Way (whether I like it or not)[8][9] and, esp. for the project, I
> > feel hurts us when considering a genuine goal of moving to a TLP. We
> should
> > instead use this as an opportunity to further embed Apache Apex into the
> > Apache Way and define what “inactivity” means for a (P)PMC Member and a
> > Committer.
> > >
> > > Another point I’ve heard is that we want Apex to be very open to new
> > Committers which is amazing, but I want to make a point here that I, as a
> > current PPMC Member, wouldn’t want to be giving away Committership like
> > candy. I would much rather see the Apache Way and its concept of
> > Meritocracy[10] in action. Moreover we, as a community, still haven’t
> > defined (that I know of) a strong set of guidelines that any individual
> can
> > follow to earn said merit in the project and become a Committer. This
> > certainly shouldn't be construed as a bad thing since we are still a
> > relatively young project and need to work these things out (and I’m sure
> we
> > will :) ).
> > >
> > > So, what are my recommendations?
> > >
> > > 1. Keep the current PPMC and Committer list as they are
> > > 2. Establish a set of guidelines on what it takes to be a Committer
> > > 3. Establish a set of roles and responsibilities for a Committer on
> > Apache Apex
> > > 4. Establish #2 and #3 for a (P)PMC Member as well
> > > 5. Most importantly, establish a set of guidelines on what “inactivity”
> > means for (P)PMC Members and Committers
> > >
> > > Also, because I didn’t want to clog the actual vote thread, I’ve
> > restarted this thread. Forgive me if that upsets anyone.
> > >
> > > I want to end by saying that this is my first foray in the Apache
> > project lifecycle, the Apache Way, and the general way Apache governs a
> > project. That said I have no clue how other projects have succeeded or
> > failed in the past with these issues, but I can only assume that this is
> > certainly not the first time something like this has happened for a
> project
> > (nor the last) and I, for one, am confident that no matter what the
> > decision is we, as a community, will continue to strive for what is best
> > for Apache Apex to grow into a truly successful project.
> > >
> > > Phew, that was a bit long. Candid feedback welcome and appreciated.
> > >
> > > [1]
> > http://incubator.apache.org/incubation/Roles_and_Responsibilities.html
> > > [2] http://incubator.apache.org/guides/ppmc.html
> > > [3] http://incubator.apache.org/guides/committer.html
> > > [4]
> >
> http://incubator.apache.org/incubation/Incubation_Policy.html#Roles+in+the+Incubation+Process
> > > [5] http://apache.org/foundation/how-it-works.html
> > > [6] http://apache.org/foundation/how-it-works.html#committers
> > > [7] http://apache.org/foundation/how-it-works.html#pmc-members
> > > [8] http://www.apache.org/dev/pmc.html#pmc-removal
> > > [9] http://www.apache.org/dev/committers.html#committer-set-term
> > > [10] http://www.apache.org/foundation/how-it-works.html#meritocracy
> > >
> > >
> > >> On Nov 11, 2015, at 3:49 PM, P. Taylor Goetz <[email protected]>
> wrote:
> > >>
> > >> +1
> > >>
> > >> I've seen references in email threads to the effect that there are 6
> > people that are/were supposed to form the PPMC, but I've not seen a list
> of
> > who those individuals are. Granted, I may have missed it and I haven't
> done
> > an exhaustive search of the mailing lists.
> > >>
> > >> As Justin mentioned, only PPMC member votes are binding for things
> like
> > a release, so we need to know this information. We may also have to
> revoke
> > karma, but I'd have to check on that.
> > >>
> > >> Again, my apologies if that list was discussed/documented and I missed
> > it.
> > >>
> > >> -Taylor
> > >>
> > >>> On Nov 11, 2015, at 6:28 PM, Justin Mclean <[email protected]>
> > wrote:
> > >>>
> > >>> Hi,
> > >>>
> > >>> Also remember that a main practice difference between committer and
> > PPMC is that only PPMC votes are binding on releases. Committer votes are
> > not binding. I see a lot of votes on Malhar release that state they are
> > binding when perhaps they may not depending who exactly is in the PPMC.
> > Would be good to clear this confusion up.
> > >>>
> > >>> Thanks,
> > >>> Justin
> > >
> > > ________________________________________________________
> > >
> > > The information contained in this e-mail is confidential and/or
> > proprietary to Capital One and/or its affiliates and may only be used
> > solely in performance of work or services for Capital One. The
> information
> > transmitted herewith is intended only for use by the individual or entity
> > to which it is addressed. If the reader of this message is not the
> intended
> > recipient, you are hereby notified that any review, retransmission,
> > dissemination, distribution, copying or other use of, or taking of any
> > action in reliance upon this information is strictly prohibited. If you
> > have received this communication in error, please contact the sender and
> > delete the material from your computer.
> >
>

Reply via email to