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. >
