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 <brennon.y...@capitalone.com> > 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 <ptgo...@gmail.com> 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 <justinmcl...@me.com> 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.
