Re: PPMC guidance on new committers
Niclas Hedhman wrote: On Tuesday 05 June 2007 07:48, Craig L Russell wrote: Hi Niclas, There is one issue that still bothers me about your proposed ways of voting. At some point, the nominee has to be asked, and accept, to become a committer. This would have to be after the private votes are done and before the public vote. So after the nominee accepts, they suddenly see a [vote] thread regarding their candidacy on the dev list and wonder what *that* is about. I think a public welcome to the new committer would be sufficient feel good instead of the phony public vote. I don't know all the communities around ASF, but what I have seen is that the acceptance/decline happens after the public vote. Entries to PMCs seems more like private vote - accept/decline - welcome in the communities I know of. Mind you, my own opinion in the matter differs from how things are done, for instance; IMHO either the vote is public OR private, and if the latter then don't have the charade on the public list. That would simplify things at Incubator as well. 1. [Discuss] on [EMAIL PROTECTED] 2. [Vote] on [EMAIL PROTECTED] 3. [Vote] on [EMAIL PROTECTED] 4. [Accept/Decline] in private mail 5. [Announce/Welcome] in [EMAIL PROTECTED] +1 - richard Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMC guidance on new committers
Richard S. Hall wrote: Niclas Hedhman wrote: I don't know all the communities around ASF, but what I have seen is that the acceptance/decline happens after the public vote. Entries to PMCs seems more like private vote - accept/decline - welcome in the communities I know of. Mind you, my own opinion in the matter differs from how things are done, for instance; IMHO either the vote is public OR private, and if the latter then don't have the charade on the public list. That would simplify things at Incubator as well. 1. [Discuss] on [EMAIL PROTECTED] 2. [Vote] on [EMAIL PROTECTED] 3. [Vote] on [EMAIL PROTECTED] 4. [Accept/Decline] in private mail 5. [Announce/Welcome] in [EMAIL PROTECTED] +1 Ditto to everything above. The 2 suggestions, we can point out the 3rd bullet can be lazy concensus if 3 binding +1's were already cast in the podling (by incubator PMC members) - that Vote essentially becomes a Notice to the [EMAIL PROTECTED] list (for them to raise an objection if absolutely necessary). If 72 hours pass with no objection, we can call them elected by the PMC votes on the podling list. The other suggestion - you could renumber these based from 0, since the [discuss] is the one completely optional thing in the list, and the process of discussing different potential committers should be an ongoing dialog on the podling's private list :) Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMC guidance on new committers
Hi Niclas, There is one issue that still bothers me about your proposed ways of voting. At some point, the nominee has to be asked, and accept, to become a committer. This would have to be after the private votes are done and before the public vote. So after the nominee accepts, they suddenly see a [vote] thread regarding their candidacy on the dev list and wonder what *that* is about. I think a public welcome to the new committer would be sufficient feel good instead of the phony public vote. Craig On May 30, 2007, at 6:16 AM, Niclas Hedhman wrote: On Wednesday 30 May 2007 20:59, Davanum Srinivas wrote: I like the second option. thanks for bringing this up. I don't. It assumes that the [Discuss] thread was all dandy. If not, then the vote passes in public and the Incubator PMC will become the 'bad guys who doesn't let X in'. Looking at ASF at large, one of the more common ways of committer voting is; 1. [Discuss] on private@ 2. [Vote] on private@ 3. [Vote] in [EMAIL PROTECTED] How about teaching that is the process, we inject one extra step for podlings for legal reasons (if they now exist)? 1. [Discuss] on [EMAIL PROTECTED] 2. [Vote] on [EMAIL PROTECTED] 3. [Vote] on [EMAIL PROTECTED] 4. [Vote] in [EMAIL PROTECTED] IMHO, IPMC members only need to browse the Discuss Vote threads a couple of minutes to give the heads-up. And if the mentors don't cry No this should be a swift exercise. Cheers Niclas On 5/30/07, Craig L Russell [EMAIL PROTECTED] wrote: I'd like to open the discussion on the best practice referred to by the guides/ppmc because I'm not convinced that best practice for a TLP is best practice for the incubator. The reason is that PPMC votes have no legal status. And incubator PMC members generally don't track podlings closely. So it's difficult to get incubator PMC members to vote for new committers. But incubator PMC members should be very good at looking at PPMC processes and voting based on the PPMC vote process. Personally, if I saw a vote on the incubator private PMC list for a new committer on a podling, including references to the PPMC discussion and vote, I would be inclined to vote for that committer. On the other hand, if I saw a vote on the incubator private PMC list that just offered the usual so-and-so is a great contributor, I'd have no real way to see if the PPMC was really learning its job. So IMHO, best practice for podlings is to hold a [DISCUSS] Joe Bleau for committer on the PPMC private list, followed by a [VOTE] on the PPMC private list, and then a formal [VOTE] on the private incubator PMC list with references to the discussion and vote of the PPMC. [Only the final vote is binding.] Alternatively, hold a [DISCUSS] Joe Bleau for committer on the PPMC private list, followed by a [VOTE] on the dev list, and then a formal [VOTE] on the incubator list with references to the discussion and vote of the community. This way, the incubator PMC can see that the PPMC gets the Apache Way. Craig On May 30, 2007, at 5:35 AM, Craig L Russell wrote: Having seen this identical discussion at least half a dozen times, I've committed changes to the guides/ppmc document removing the distracting (P) from the discussion on new committers. The new text says Only votes cast by Incubator PMC members are binding. If the vote is positive, and the contributor accepts the responsibility of a committer for the project, the contributor formally becomes an Apache committer. An Incubator PMC member should then follow the documented procedures to complete the process, and CC both the Incubator PMC and the PPMC when sending the necessary e-mails to root. I included the redundant Incubator in Incubator PMC simply to reinforce Noel's comment that PMC means Incubator PMC. Craig On May 29, 2007, at 8:49 PM, Noel J. Bergman wrote: Yoav Shapira wrote: I voted +0, not having had time to review the proposed committer's contributions. +1 != +0 I always thought (and the documentation at http://incubator.apache.org/guides/ppmc.html) says PPMC votes are binding. It says (P), and the (P) clearly does not belong. Notice that elsewhere it properly says PPMC, with no (), and the places that are wrong were PMC to which someone added (P). Likewise IPMC should simply be PMC. There is only one PMC: the Incubator PMC. I don't know how to say this more clearly. The PPMC is not a recognized entity in the ASF Bylaws. The PMC is the legal entity, and only PMC votes count in any ASF project. PPMC members should still vote, as can other members of the community, but as a legal matter, only PMC votes are binding. This is not Incubator policy, it is how the ASF works. It is the same in Jakarta, for example, where any Jakarta Committer who isn't on the PMC can vote, but only Jakarta PMC votes count. For years people didn't understand this, but please understand that Jakarta is the source of many of the wrong and bad practices in ASF
Re: PPMC guidance on new committers
On Tuesday 05 June 2007 07:48, Craig L Russell wrote: Hi Niclas, There is one issue that still bothers me about your proposed ways of voting. At some point, the nominee has to be asked, and accept, to become a committer. This would have to be after the private votes are done and before the public vote. So after the nominee accepts, they suddenly see a [vote] thread regarding their candidacy on the dev list and wonder what *that* is about. I think a public welcome to the new committer would be sufficient feel good instead of the phony public vote. I don't know all the communities around ASF, but what I have seen is that the acceptance/decline happens after the public vote. Entries to PMCs seems more like private vote - accept/decline - welcome in the communities I know of. Mind you, my own opinion in the matter differs from how things are done, for instance; IMHO either the vote is public OR private, and if the latter then don't have the charade on the public list. That would simplify things at Incubator as well. 1. [Discuss] on [EMAIL PROTECTED] 2. [Vote] on [EMAIL PROTECTED] 3. [Vote] on [EMAIL PROTECTED] 4. [Accept/Decline] in private mail 5. [Announce/Welcome] in [EMAIL PROTECTED] Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMC guidance on new committers
Hi Niclas, On Jun 4, 2007, at 6:04 PM, Niclas Hedhman wrote: On Tuesday 05 June 2007 07:48, Craig L Russell wrote: Hi Niclas, There is one issue that still bothers me about your proposed ways of voting. At some point, the nominee has to be asked, and accept, to become a committer. This would have to be after the private votes are done and before the public vote. So after the nominee accepts, they suddenly see a [vote] thread regarding their candidacy on the dev list and wonder what *that* is about. I think a public welcome to the new committer would be sufficient feel good instead of the phony public vote. I don't know all the communities around ASF, but what I have seen is that the acceptance/decline happens after the public vote. Entries to PMCs seems more like private vote - accept/decline - welcome in the communities I know of. Mind you, my own opinion in the matter differs from how things are done, for instance; IMHO either the vote is public OR private, and if the latter then don't have the charade on the public list. That would simplify things at Incubator as well. 1. [Discuss] on [EMAIL PROTECTED] 2. [Vote] on [EMAIL PROTECTED] 3. [Vote] on [EMAIL PROTECTED] 4. [Accept/Decline] in private mail 5. [Announce/Welcome] in [EMAIL PROTECTED] This is what I proposed to put into the guide. So at least two of us agree. But I also put the not necessarily recommended approach into the guide for completeness. So there should not be any big issues. Craig Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: PPMC guidance on new committers
Thanks Craig. Some suggestions/comments: On May 31, 2007, at 7:56 AM, Craig L Russell wrote: Voting in a new committer If a developer has contributed a significant number of high-quality patches, is interested in continuing the contribution, and has demonstrated the ability to work well with others under the Apache guidelines, the project might vote to grant that developer commit access. See the ASF How it Works document, which explains meritocracy and roles. Rewrite: If someone has made significant contributions and is interested in continuing to contribute, and works well under apache guidelines, the project might vote to grant that person commit access. See the ASF How it Works document, which explains meritocracy and roles. [non-code contributions can lead to committership] One of the PPMC members should lead the process of accepting a new committer. For the purposes of this document, the proposing PPMC member is referred to as the proposer, and the proposed committer is referred to as the nominee. Discussion of a nominee should take place on the podling project's private (PPMC) list [normally it would take place on a project's private list]. If there are any concerns raised during the discussion, these need to be resolved so that there is consensus among the PPMC members as to the suitability of the nominee for the project and for Apache. Add: Many projects adopt an approach where, if there are *any* concerns, the nomination is simply tabled for a few months. Many concerns often go away with continued participation. After vetting the nominee, the vote can be called on either one of the two places listed below (notice the balance between private and public lists): o The podling's private list, with notice posted to the Incubator private list. The notice is a separate email forwarding the vote email with a cover statement that this vote is underway on the podling's private list. This is a good approach if you are not sure of getting the required three +1 votes from incubator PMC members on the first vote. After completing the vote on the PPMC list, if there are not three +1 votes from incubator PMC members, the proposer should call a vote on the incubator PMC private list with a reference to the archived discussion and vote by the PPMC. Add: Many projects that have these private votes also have a pro forma public vote after the private vote completes, or have a welcome thread on their public mailing list. Those are good because they make people feel welcome. o The podling's developer list, with notice posted to the Incubator general list. The notice is a separate email forwarding the vote email with a cover statement that this vote is underway on the podling's developer list. This is a good approach if you are sure of getting the required three +1 votes from incubator PMC members. It is embarrassing to have a public vote fail or take a very long time because not enough incubator PMC members vote and have to be solicited to vote for a committer. [Just a note here - a lot of IPMC people feel strongly that any voting on people in public is bad; I'm one of them. However, it is probably still an active practice somewhere at apache and I don't think we should quite forbid it, so it should be in this guide.] Replace: o The podling's developer list, with notice posted to the Incubator general list. The notice is a separate email forwarding the vote email with a cover statement that this vote is underway on the podling's developer list. Add: The second approach is considered inferior by many, because it is embarrassing to have a public vote like this fail or take a very long time. Consider holding a vote on a private mailing list followed by a public vote after consensus is evident. Only votes cast by Incubator PMC members are binding. Add: However, votes from the PPMC are really important here. The entire PPMC should show their support for this new committer If the vote is positive (three or more binding +1 votes and no binding -1 votes), the proposer offers committership to the nominee. If the nominee accepts the responsibility of a committer for the project, Replace: of a committer for the project with of being a committer on the project the nominee formally becomes an Apache committer. The proposer then asks an Incubator PMC member to follow the documented procedures to complete the process. If the nominee is already an Apache committer on another project, the proposer asks the incubator PMC chair Replace: incubator PMC chair with incubator PMC to update the authorization file to include the nominee as a committer on the podling. If the nominee is not already an Apache committer, the incubator PMC member CC's both the Incubator PMC and the PPMC when sending the necessary e-mails to root. Normally, the incubator PMC member is a Mentor on the
Re: PPMC guidance on new committers
Craig L Russell wrote: Hi Martin, On May 30, 2007, at 11:07 AM, Martin Sebor wrote: Craig L Russell wrote: [...] So IMHO, best practice for podlings is to hold a [DISCUSS] Joe Bleau for committer on the PPMC private list, followed by a [VOTE] on the PPMC private list, and then a formal [VOTE] on the private incubator PMC list with references to the discussion and vote of the PPMC. [Only the final vote is binding.] How could a PPMC participate in a vote on the Incubator PMC's private list? It cannot, and I don't believe I implied that this would be the case. The idea is that the PPMC, with the help of the Mentors, conducts a discussion and a vote just as they would if they were a TLP PMC. What we're trying to do in the incubator is to give the PPMC the opportunity to act like a PMC and this committer discussion and vote is one of the most important things to learn. How could they learn anything when some of the most important decisions were made behind closed doors (i.e., on the Incubator private list?) Even if the PPMC's private list were CC'd on the initial vote there would be no way for the PPMC members to know whether they were being CC'd on all the relevant discussions and given sufficient opportunity to address any concerns. I guess this would be the responsibility of the Mentors to carry any feedback from the incubator PMC vote. During the incubator PMC vote, the Mentors will be active in responding to any concerns of the incubator PMC. That sounds backwards. Aren't each podling's mentors supposed to represent the Incubator PMC on the podling's PPMC? Doesn't the PMC trust the mentors to adequately represent them? It seems to me that if a mentor has reason to be concerned about a committer vote they can bring it up on the Incubator PMC list. Otherwise there should be no reason to involve it. If there are Incubator PMC members who are concerned about a podling's ability to make these type of decisions despite the oversight of its mentors they have the option of subscribing to the PPMC list or even becoming mentors themselves. Otherwise, it would be hard to argue that they have the insight necessary to make these types of fundamental decisions for the PPMC. Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMC guidance on new committers
Martin Sebor wrote: Craig L Russell wrote: How could a PPMC participate in a vote on the Incubator PMC's private list? It cannot, and I don't believe I implied that this would be the case. The idea is that the PPMC, with the help of the Mentors, conducts a discussion and a vote just as they would if they were a TLP PMC. What we're trying to do in the incubator is to give the PPMC the opportunity to act like a PMC and this committer discussion and vote is one of the most important things to learn. How could they learn anything when some of the most important decisions were made behind closed doors (i.e., on the Incubator private list?) Every ASF member has access to every private list (little known trivia, but it's pretty obvious when you consider the role of the foundation, through it's members, is to oversee the whole of the foundation.) Of course, there's the edge case of PMC members who aren't members, but let's not rehash that today :) Even if the PPMC's private list were CC'd on the initial vote there would be no way for the PPMC members to know whether they were being CC'd on all the relevant discussions and given sufficient opportunity to address any concerns. I guess this would be the responsibility of the Mentors to carry any feedback from the incubator PMC vote. During the incubator PMC vote, the Mentors will be active in responding to any concerns of the incubator PMC. That sounds backwards. Aren't each podling's mentors supposed to represent the Incubator PMC on the podling's PPMC? Doesn't the PMC trust the mentors to adequately represent them? It seems to me that if a mentor has reason to be concerned about a committer vote they can bring it up on the Incubator PMC list. Otherwise there should be no reason to involve it. If there are Incubator PMC members who are concerned about a podling's ability to make these type of decisions despite the oversight of its mentors they have the option of subscribing to the PPMC list or even becoming mentors themselves. Otherwise, it would be hard to argue that they have the insight necessary to make these types of fundamental decisions for the PPMC. Well, this is a two way street. As members, we represent our podlings to the PMC, and represent the PMC to our podlings. Of course every PMC member is welcome to go back through the public/private archives themselves, but it's much quicker when the mentors provide a summary. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMC guidance on new committers
Hi Bill, Thanks for clarifying your position. This is a bit of a surprise, since I thought I was just elaborating existing practice as documented in the ppmc guide. The section in question had been in the guides/ppmc for as long as I've been at Apache, and I missed any dialog regarding this issue earlier. I'll take another stab at updating the ppmc guidance. Thanks, Craig On May 31, 2007, at 1:08 PM, William A. Rowe, Jr. wrote: Craig L Russell wrote: Hi Bill, On May 30, 2007, at 11:37 PM, William A. Rowe, Jr. wrote: Craig L Russell wrote: o The podling's developer list, with notice posted to the Incubator general list. The notice is a separate email forwarding the vote email with a cover statement that this vote is underway on the podling's developer list. This is a good approach if you are sure of getting the required three +1 votes from incubator PMC members. It is embarrassing to have a public vote fail or take a very long time because not enough incubator PMC members vote and have to be solicited to vote for a committer. I'm strongly against this. I'm sorry I can't tell what you are against, even after reading the following. Are you suggesting that we should no ever recommend this as a possible option? Correct. If you think it's to spare embarrassment, you missed the issue. The issue is that it is unnecessarily hostile and confrontational to have to reject a committer on a public list. That's why I included This is a good approach if you are strongsure/strong of getting the required three +1 votes from incubator PMC members. Does this mean 4 of you were sitting at a hackathon table and decided, HEY, that's a good idea! Jeremy would make a great committer! Did that raise a chance for others to point out why Jeremy wasn't accepted or was actually kicked from committer status on Project X, or raise other concerns? It doesn't matter if you know three people who agree, the point is that it's for all PMC members to consider. And that a public vote will undercut an honest dialog about that contributor's readiness to become a committer or PPMC member. That includes the opinions, even if they are not binding, of the PPMC members who have probably had longer contact with coders in their specific development arena. I've been there, in a very unusual way - raising an objection to a good soul of the ASF membership, a reader of a private PMC list, who had quite honestly not earned local-merit to that project. We are all adults, and that didn't turn out 1/10th as badly as it could have, but it sensitized me to this issue. Many with objections simply would not/did not speak up. I'm sure Jakarta participants can relate similarly uncomfortable instances. Are you suggesting that this approach is never good? Correct. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: PPMC guidance on new committers
On 5/30/07, Noel J. Bergman [EMAIL PROTECTED] wrote: Carl Trieloff wrote: One more question on this topic as I have also seen differing views from different members of the Incubator PMC on: Who can and who can not send the account setup mail to root? The view that counts is from http://www.apache.org/dev/pmc.html#newcommitter. Please note: that is not an Incubator URL. These are ASF-wide documents, and everyone should become familar with the contents under http://www.apache.org/dev. Given each new committer vote will have 3 PMC votes, why does a mentor have to send the account setup to root? Why can't the mail to root just contain a link to the vote result with 3 PMC members on it from the general list? See the above URL. Technically, it can come from any PMC member, not just a Mentor. It ought to come from a Mentor in terms of social interfactions, but if your Mentor(s) are not being responsive, any PMC member can do it. Some PMC members have the view that any PPMC member should be able to send the account setup to root to learn the system, others say it has to be a mentor. See above. Any PMC mamber. The Incubator is unique in that we are the sole umbrella structure (there are/were others, and the ASF is deep into the process of eliminating them). Here in the Incubator, we have to navigate a duality: wanting the PPMC as much as possible to manage its project with guidance, and at the same time having to ensure PMC oversight. So although only PMC votes are binding, and some actions require PMC involvement, this is why having enough Mentors on a project to satisfy voting requirements and other PMC actions is a good thing. Interesting thread. One thing i noticed is at http://www.apache.org/dev/pmc.html#newcommitter it says: If you are acting on behalf of a project which was accepted for incubation, please get in touch with the sponsoring PMC and let them take care of requesting any new accounts. Do members of the sponsoring PMC have any other special powers over PPMC members other than this being able to send off the email for new committer account requests? Do sponsoring PMC members have binding votes on things like releases or voting in new commiters? ...ant
Re: PPMC guidance on new committers
I'd like to discuss one detail of the process for new committers. On May 30, 2007, at 10:56 PM, Craig L Russell wrote: If the nominee is already an Apache committer on another project, the proposer asks the incubator PMC chair to update the authorization file to include the nominee as a committer on the podling. If the nominee is not already an Apache committer, the incubator PMC member CC's both the Incubator PMC and the PPMC when sending the necessary e-mails to root. Normally, the incubator PMC member is a Mentor on the podling's PPMC but due to unavailability, the proposer can ask any incubator PMC member. Is it really required for the incubator PMC chair to update the authorization file? Seems like a single point of failure and a possible source of delay. Would it be ok for *any* incubator PMC member with write access to the authorization file to perform this task? There are lots of incubator PMC members with sufficient karma to do the deed. The issue is probably not a problem on a normal PMC since the number of committer requests is low. But the incubator is in charge of dozens of podlings and it seems like this might be a bigger problem here. Craig Craig Russell DB PMC, OpenJPA PMC [EMAIL PROTECTED] http://db.apache.org/jdo smime.p7s Description: S/MIME cryptographic signature
Re: PPMC guidance on new committers
Craig L Russell wrote: o The podling's developer list, with notice posted to the Incubator general list. The notice is a separate email forwarding the vote email with a cover statement that this vote is underway on the podling's developer list. This is a good approach if you are sure of getting the required three +1 votes from incubator PMC members. It is embarrassing to have a public vote fail or take a very long time because not enough incubator PMC members vote and have to be solicited to vote for a committer. I'm strongly against this. If you think it's to spare embarrassment, you missed the issue. The issue is that it is unnecessarily hostile and confrontational to have to reject a committer on a public list. So one of two things happen when there is a valid reason to reject the nomination - either the list becomes hostile and you alienate a contributor who might be voted in with simply another month or two of participation, or the objection goes unstated which is bad for the health and progress of the project. Voting on-list is a bad thing for the project; not a bad thing to do to the nominee. This is another artifact from Jakarta practice, which Noel had some observations about earlier today :) Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMC guidance on new committers
Craig L Russell wrote: [...] So IMHO, best practice for podlings is to hold a [DISCUSS] Joe Bleau for committer on the PPMC private list, followed by a [VOTE] on the PPMC private list, and then a formal [VOTE] on the private incubator PMC list with references to the discussion and vote of the PPMC. [Only the final vote is binding.] How could a PPMC participate in a vote on the Incubator PMC's private list? Even if the PPMC's private list were CC'd on the initial vote there would be no way for the PPMC members to know whether they were being CC'd on all the relevant discussions and given sufficient opportunity to address any concerns. Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMC guidance on new committers
Hi Bill, On May 30, 2007, at 11:37 PM, William A. Rowe, Jr. wrote: Craig L Russell wrote: o The podling's developer list, with notice posted to the Incubator general list. The notice is a separate email forwarding the vote email with a cover statement that this vote is underway on the podling's developer list. This is a good approach if you are sure of getting the required three +1 votes from incubator PMC members. It is embarrassing to have a public vote fail or take a very long time because not enough incubator PMC members vote and have to be solicited to vote for a committer. I'm strongly against this. I'm sorry I can't tell what you are against, even after reading the following. Are you suggesting that we should no ever recommend this as a possible option? Craig If you think it's to spare embarrassment, you missed the issue. The issue is that it is unnecessarily hostile and confrontational to have to reject a committer on a public list. That's why I included This is a good approach if you are strongsure/strong of getting the required three +1 votes from incubator PMC members. Are you suggesting that this approach is never good? Regards, Craig So one of two things happen when there is a valid reason to reject the nomination - either the list becomes hostile and you alienate a contributor who might be voted in with simply another month or two of participation, or the objection goes unstated which is bad for the health and progress of the project. Voting on-list is a bad thing for the project; not a bad thing to do to the nominee. This is another artifact from Jakarta practice, which Noel had some observations about earlier today :) Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: PPMC guidance on new committers
Hi Martin, On May 30, 2007, at 11:07 AM, Martin Sebor wrote: Craig L Russell wrote: [...] So IMHO, best practice for podlings is to hold a [DISCUSS] Joe Bleau for committer on the PPMC private list, followed by a [VOTE] on the PPMC private list, and then a formal [VOTE] on the private incubator PMC list with references to the discussion and vote of the PPMC. [Only the final vote is binding.] How could a PPMC participate in a vote on the Incubator PMC's private list? It cannot, and I don't believe I implied that this would be the case. The idea is that the PPMC, with the help of the Mentors, conducts a discussion and a vote just as they would if they were a TLP PMC. What we're trying to do in the incubator is to give the PPMC the opportunity to act like a PMC and this committer discussion and vote is one of the most important things to learn. Even if the PPMC's private list were CC'd on the initial vote there would be no way for the PPMC members to know whether they were being CC'd on all the relevant discussions and given sufficient opportunity to address any concerns. I guess this would be the responsibility of the Mentors to carry any feedback from the incubator PMC vote. During the incubator PMC vote, the Mentors will be active in responding to any concerns of the incubator PMC. Craig Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: PPMC guidance on new committers
Craig L Russell wrote: Hi Bill, On May 30, 2007, at 11:37 PM, William A. Rowe, Jr. wrote: Craig L Russell wrote: o The podling's developer list, with notice posted to the Incubator general list. The notice is a separate email forwarding the vote email with a cover statement that this vote is underway on the podling's developer list. This is a good approach if you are sure of getting the required three +1 votes from incubator PMC members. It is embarrassing to have a public vote fail or take a very long time because not enough incubator PMC members vote and have to be solicited to vote for a committer. I'm strongly against this. I'm sorry I can't tell what you are against, even after reading the following. Are you suggesting that we should no ever recommend this as a possible option? Correct. If you think it's to spare embarrassment, you missed the issue. The issue is that it is unnecessarily hostile and confrontational to have to reject a committer on a public list. That's why I included This is a good approach if you are strongsure/strong of getting the required three +1 votes from incubator PMC members. Does this mean 4 of you were sitting at a hackathon table and decided, HEY, that's a good idea! Jeremy would make a great committer! Did that raise a chance for others to point out why Jeremy wasn't accepted or was actually kicked from committer status on Project X, or raise other concerns? It doesn't matter if you know three people who agree, the point is that it's for all PMC members to consider. And that a public vote will undercut an honest dialog about that contributor's readiness to become a committer or PPMC member. That includes the opinions, even if they are not binding, of the PPMC members who have probably had longer contact with coders in their specific development arena. I've been there, in a very unusual way - raising an objection to a good soul of the ASF membership, a reader of a private PMC list, who had quite honestly not earned local-merit to that project. We are all adults, and that didn't turn out 1/10th as badly as it could have, but it sensitized me to this issue. Many with objections simply would not/did not speak up. I'm sure Jakarta participants can relate similarly uncomfortable instances. Are you suggesting that this approach is never good? Correct. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMC guidance on new committers
As this seems to be an evolving Best Practice, I don't know that when started a vote recently on two new committers for CXF that all of this was apparent to me at the time. The current documentation at least http://incubator.apache.org/guides/ppmc.html seems to indicate that we just need a net positive of IPMC votes (If the vote is positive...) and doesn't seem to explicitly require a private vote*. The current state of those votes are that we received 15 +1s for each person, but none of the votes were from PMC members. I'm hoping that someone can help me clarify what we should do next then. Specifically: 1. Do we need just a net positive of IPMC votes? Or 3 IPMC +1s? 2. We voted on the public list (the two committers both had great contributions and I have/had no reason to think anyone would be -1 on them) - even if thats not necessarily the best practice according to this document (which we can maybe discuss in another thread) - I'm wondering what we should do now. Should I put the [vote] to [EMAIL PROTECTED] still with some descriptions of the things each individual has contributed and why we feel they deserve commits? 3. Just to ensure I'm straight here - whoever sends in the account request MUST be an IPMC member, right? I have already pinged our mentors on the private cxf list, but didn't receive any more votes yet, so I'm hoping we can get some guidance about what to do next. Thanks, - Dan * We've certainly done just public votes before and our mentors seemed ok with it. On 5/31/07, Craig L Russell [EMAIL PROTECTED] wrote: Here's what I'd like to do with the ppmc guide. Change: Voting in a new committer If a developer has contributed a significant number of high-quality patches, is interested in continuing the contribution, and has demonstrated the ability to work well with others under the Apache guidelines, the project might vote to grant that developer commit access. See the ASF How it Works document, which explains meritocracy and roles. Discussion of a potential new committer should take place on the podling project's private list; normally it would take place on a project's private list. After vetting the new candidate, the vote can be called on either one of the two places listed below (notice the balance between private and public lists): The podling's private list, with notice posted to the Incubator private list. The developer list, with notice posted to the Incubator general list. The practice of a private discussion followed by a public, pro-forma, vote is re-emerging as a Best Practice for ASF projects (see this comprehensive discussion about these practices). Only votes cast by Incubator PMC members are binding. If the vote is positive, and the contributor accepts the responsibility of a committer for the project, the contributor formally becomes an Apache committer. An Incubator PMC member should then follow the documented procedures to complete the process, and CC both the Incubator PMC and the PPMC when sending the necessary e-mails to root. Please direct the new committer to the Apache developer's pages, to the Apache Incubator site and to the Incubator Committers Guide for important additional information. to: Voting in a new committer If a developer has contributed a significant number of high-quality patches, is interested in continuing the contribution, and has demonstrated the ability to work well with others under the Apache guidelines, the project might vote to grant that developer commit access. See the ASF How it Works document, which explains meritocracy and roles. One of the PPMC members should lead the process of accepting a new committer. For the purposes of this document, the proposing PPMC member is referred to as the proposer, and the proposed committer is referred to as the nominee. Discussion of a nominee should take place on the podling project's private (PPMC) list [normally it would take place on a project's private list]. If there are any concerns raised during the discussion, these need to be resolved so that there is consensus among the PPMC members as to the suitability of the nominee for the project and for Apache. After vetting the nominee, the vote can be called on either one of the two places listed below (notice the balance between private and public lists): o The podling's private list, with notice posted to the Incubator private list. The notice is a separate email forwarding the vote email with a cover statement that this vote is underway on the podling's private list. This is a good approach if you are not sure of getting the required three +1 votes from incubator PMC members on the first vote. After completing the vote on the PPMC list, if there are not three +1 votes from incubator PMC members, the proposer should call a vote on the incubator PMC private list with a reference to the archived discussion and vote by the PPMC. o The podling's developer list, with notice posted to the Incubator general list. The notice is a
Re: PPMC guidance on new committers
Speaking of being unnecessarily hostile and confrontational, thanks for bagging Jakarta. FWIW, The most recent Jakarta committer votes have been conducted in private, and what you describe is not a current Jakarta practice. Where are Noel's comments about bad Jakarta practice? I had a quick look through my recent emails from Noel, but couldn't find any. Regards, Dion On 5/31/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Craig L Russell wrote: o The podling's developer list, with notice posted to the Incubator general list. The notice is a separate email forwarding the vote email with a cover statement that this vote is underway on the podling's developer list. This is a good approach if you are sure of getting the required three +1 votes from incubator PMC members. It is embarrassing to have a public vote fail or take a very long time because not enough incubator PMC members vote and have to be solicited to vote for a committer. I'm strongly against this. If you think it's to spare embarrassment, you missed the issue. The issue is that it is unnecessarily hostile and confrontational to have to reject a committer on a public list. So one of two things happen when there is a valid reason to reject the nomination - either the list becomes hostile and you alienate a contributor who might be voted in with simply another month or two of participation, or the objection goes unstated which is bad for the health and progress of the project. Voting on-list is a bad thing for the project; not a bad thing to do to the nominee. This is another artifact from Jakarta practice, which Noel had some observations about earlier today :) Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- dIon Gillard Rule #131 of Acquisition: Information is Profit.
Re: PPMC guidance on new committers
I'd like to open the discussion on the best practice referred to by the guides/ppmc because I'm not convinced that best practice for a TLP is best practice for the incubator. The reason is that PPMC votes have no legal status. And incubator PMC members generally don't track podlings closely. So it's difficult to get incubator PMC members to vote for new committers. But incubator PMC members should be very good at looking at PPMC processes and voting based on the PPMC vote process. Personally, if I saw a vote on the incubator private PMC list for a new committer on a podling, including references to the PPMC discussion and vote, I would be inclined to vote for that committer. On the other hand, if I saw a vote on the incubator private PMC list that just offered the usual so-and-so is a great contributor, I'd have no real way to see if the PPMC was really learning its job. So IMHO, best practice for podlings is to hold a [DISCUSS] Joe Bleau for committer on the PPMC private list, followed by a [VOTE] on the PPMC private list, and then a formal [VOTE] on the private incubator PMC list with references to the discussion and vote of the PPMC. [Only the final vote is binding.] Alternatively, hold a [DISCUSS] Joe Bleau for committer on the PPMC private list, followed by a [VOTE] on the dev list, and then a formal [VOTE] on the incubator list with references to the discussion and vote of the community. This way, the incubator PMC can see that the PPMC gets the Apache Way. Craig On May 30, 2007, at 5:35 AM, Craig L Russell wrote: Having seen this identical discussion at least half a dozen times, I've committed changes to the guides/ppmc document removing the distracting (P) from the discussion on new committers. The new text says Only votes cast by Incubator PMC members are binding. If the vote is positive, and the contributor accepts the responsibility of a committer for the project, the contributor formally becomes an Apache committer. An Incubator PMC member should then follow the documented procedures to complete the process, and CC both the Incubator PMC and the PPMC when sending the necessary e-mails to root. I included the redundant Incubator in Incubator PMC simply to reinforce Noel's comment that PMC means Incubator PMC. Craig On May 29, 2007, at 8:49 PM, Noel J. Bergman wrote: Yoav Shapira wrote: I voted +0, not having had time to review the proposed committer's contributions. +1 != +0 I always thought (and the documentation at http://incubator.apache.org/guides/ppmc.html) says PPMC votes are binding. It says (P), and the (P) clearly does not belong. Notice that elsewhere it properly says PPMC, with no (), and the places that are wrong were PMC to which someone added (P). Likewise IPMC should simply be PMC. There is only one PMC: the Incubator PMC. I don't know how to say this more clearly. The PPMC is not a recognized entity in the ASF Bylaws. The PMC is the legal entity, and only PMC votes count in any ASF project. PPMC members should still vote, as can other members of the community, but as a legal matter, only PMC votes are binding. This is not Incubator policy, it is how the ASF works. It is the same in Jakarta, for example, where any Jakarta Committer who isn't on the PMC can vote, but only Jakarta PMC votes count. For years people didn't understand this, but please understand that Jakarta is the source of many of the wrong and bad practices in ASF projects that didn't go through either the HTTP Server project or the Incubator. the documentation link above is out of date. It was never in date. It is wrong, regardless of date. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: PPMC guidance on new committers
I like the second option. thanks for bringing this up. thanks, dims On 5/30/07, Craig L Russell [EMAIL PROTECTED] wrote: I'd like to open the discussion on the best practice referred to by the guides/ppmc because I'm not convinced that best practice for a TLP is best practice for the incubator. The reason is that PPMC votes have no legal status. And incubator PMC members generally don't track podlings closely. So it's difficult to get incubator PMC members to vote for new committers. But incubator PMC members should be very good at looking at PPMC processes and voting based on the PPMC vote process. Personally, if I saw a vote on the incubator private PMC list for a new committer on a podling, including references to the PPMC discussion and vote, I would be inclined to vote for that committer. On the other hand, if I saw a vote on the incubator private PMC list that just offered the usual so-and-so is a great contributor, I'd have no real way to see if the PPMC was really learning its job. So IMHO, best practice for podlings is to hold a [DISCUSS] Joe Bleau for committer on the PPMC private list, followed by a [VOTE] on the PPMC private list, and then a formal [VOTE] on the private incubator PMC list with references to the discussion and vote of the PPMC. [Only the final vote is binding.] Alternatively, hold a [DISCUSS] Joe Bleau for committer on the PPMC private list, followed by a [VOTE] on the dev list, and then a formal [VOTE] on the incubator list with references to the discussion and vote of the community. This way, the incubator PMC can see that the PPMC gets the Apache Way. Craig On May 30, 2007, at 5:35 AM, Craig L Russell wrote: Having seen this identical discussion at least half a dozen times, I've committed changes to the guides/ppmc document removing the distracting (P) from the discussion on new committers. The new text says Only votes cast by Incubator PMC members are binding. If the vote is positive, and the contributor accepts the responsibility of a committer for the project, the contributor formally becomes an Apache committer. An Incubator PMC member should then follow the documented procedures to complete the process, and CC both the Incubator PMC and the PPMC when sending the necessary e-mails to root. I included the redundant Incubator in Incubator PMC simply to reinforce Noel's comment that PMC means Incubator PMC. Craig On May 29, 2007, at 8:49 PM, Noel J. Bergman wrote: Yoav Shapira wrote: I voted +0, not having had time to review the proposed committer's contributions. +1 != +0 I always thought (and the documentation at http://incubator.apache.org/guides/ppmc.html) says PPMC votes are binding. It says (P), and the (P) clearly does not belong. Notice that elsewhere it properly says PPMC, with no (), and the places that are wrong were PMC to which someone added (P). Likewise IPMC should simply be PMC. There is only one PMC: the Incubator PMC. I don't know how to say this more clearly. The PPMC is not a recognized entity in the ASF Bylaws. The PMC is the legal entity, and only PMC votes count in any ASF project. PPMC members should still vote, as can other members of the community, but as a legal matter, only PMC votes are binding. This is not Incubator policy, it is how the ASF works. It is the same in Jakarta, for example, where any Jakarta Committer who isn't on the PMC can vote, but only Jakarta PMC votes count. For years people didn't understand this, but please understand that Jakarta is the source of many of the wrong and bad practices in ASF projects that didn't go through either the HTTP Server project or the Incubator. the documentation link above is out of date. It was never in date. It is wrong, regardless of date. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMC guidance on new committers
One more question on this topic as I have also seen differing views from different members of the Incubator PMC on: Who can and who can not send the account setup mail to root? Given each new committer vote will have 3 PMC votes, why does a mentor have to send the account setup to root? Why can't the mail to root just contain a link to the vote result with 3 PMC members on it from the general list? Some PMC members have the view that any PPMC member should be able to send the account setup to root to learn the system, others say it has to be a mentor. Cliff has kindly taken care of most of these mail for us so far so this is more theoretical, however having clarity on this in the document would also be good as I have wondered about the reasoning behind this practice. If the mail to root has to be cc-ed to general list and PPMC and has 3 PMC votes on it then it would seem to me that it could be send by anyone. Carl. Craig L Russell wrote: Having seen this identical discussion at least half a dozen times, I've committed changes to the guides/ppmc document removing the distracting (P) from the discussion on new committers. The new text says Only votes cast by Incubator PMC members are binding. If the vote is positive, and the contributor accepts the responsibility of a committer for the project, the contributor formally becomes an Apache committer. An Incubator PMC member should then follow the documented procedures to complete the process, and CC both the Incubator PMC and the PPMC when sending the necessary e-mails to root. I included the redundant Incubator in Incubator PMC simply to reinforce Noel's comment that PMC means Incubator PMC. Craig On May 29, 2007, at 8:49 PM, Noel J. Bergman wrote: Yoav Shapira wrote: I voted +0, not having had time to review the proposed committer's contributions. +1 != +0 I always thought (and the documentation at http://incubator.apache.org/guides/ppmc.html) says PPMC votes are binding. It says (P), and the (P) clearly does not belong. Notice that elsewhere it properly says PPMC, with no (), and the places that are wrong were PMC to which someone added (P). Likewise IPMC should simply be PMC. There is only one PMC: the Incubator PMC. I don't know how to say this more clearly. The PPMC is not a recognized entity in the ASF Bylaws. The PMC is the legal entity, and only PMC votes count in any ASF project. PPMC members should still vote, as can other members of the community, but as a legal matter, only PMC votes are binding. This is not Incubator policy, it is how the ASF works. It is the same in Jakarta, for example, where any Jakarta Committer who isn't on the PMC can vote, but only Jakarta PMC votes count. For years people didn't understand this, but please understand that Jakarta is the source of many of the wrong and bad practices in ASF projects that didn't go through either the HTTP Server project or the Incubator. the documentation link above is out of date. It was never in date. It is wrong, regardless of date. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMC guidance on new committers
Hi Dims, It wasn't completely clear from my message, but I intended this to be a choice of the PPMC (with guidance by the Mentors) to hold the votes either in private or in public. I'd like to get others' input as well on whether the guidance here should be 1. private vote on PPMC then private vote on incubator PMC 2. public vote on dev then public vote on incubator general 3. PPMC/Mentors decide which of 1 or 2 to follow. This might be a podling policy or decided on each [DISCUSS] of a new committer. Craig On May 30, 2007, at 5:59 AM, Davanum Srinivas wrote: I like the second option. thanks for bringing this up. thanks, dims On 5/30/07, Craig L Russell [EMAIL PROTECTED] wrote: I'd like to open the discussion on the best practice referred to by the guides/ppmc because I'm not convinced that best practice for a TLP is best practice for the incubator. The reason is that PPMC votes have no legal status. And incubator PMC members generally don't track podlings closely. So it's difficult to get incubator PMC members to vote for new committers. But incubator PMC members should be very good at looking at PPMC processes and voting based on the PPMC vote process. Personally, if I saw a vote on the incubator private PMC list for a new committer on a podling, including references to the PPMC discussion and vote, I would be inclined to vote for that committer. On the other hand, if I saw a vote on the incubator private PMC list that just offered the usual so-and-so is a great contributor, I'd have no real way to see if the PPMC was really learning its job. So IMHO, best practice for podlings is to hold a [DISCUSS] Joe Bleau for committer on the PPMC private list, followed by a [VOTE] on the PPMC private list, and then a formal [VOTE] on the private incubator PMC list with references to the discussion and vote of the PPMC. [Only the final vote is binding.] Alternatively, hold a [DISCUSS] Joe Bleau for committer on the PPMC private list, followed by a [VOTE] on the dev list, and then a formal [VOTE] on the incubator list with references to the discussion and vote of the community. This way, the incubator PMC can see that the PPMC gets the Apache Way. Craig On May 30, 2007, at 5:35 AM, Craig L Russell wrote: Having seen this identical discussion at least half a dozen times, I've committed changes to the guides/ppmc document removing the distracting (P) from the discussion on new committers. The new text says Only votes cast by Incubator PMC members are binding. If the vote is positive, and the contributor accepts the responsibility of a committer for the project, the contributor formally becomes an Apache committer. An Incubator PMC member should then follow the documented procedures to complete the process, and CC both the Incubator PMC and the PPMC when sending the necessary e-mails to root. I included the redundant Incubator in Incubator PMC simply to reinforce Noel's comment that PMC means Incubator PMC. Craig On May 29, 2007, at 8:49 PM, Noel J. Bergman wrote: Yoav Shapira wrote: I voted +0, not having had time to review the proposed committer's contributions. +1 != +0 I always thought (and the documentation at http://incubator.apache.org/guides/ppmc.html) says PPMC votes are binding. It says (P), and the (P) clearly does not belong. Notice that elsewhere it properly says PPMC, with no (), and the places that are wrong were PMC to which someone added (P). Likewise IPMC should simply be PMC. There is only one PMC: the Incubator PMC. I don't know how to say this more clearly. The PPMC is not a recognized entity in the ASF Bylaws. The PMC is the legal entity, and only PMC votes count in any ASF project. PPMC members should still vote, as can other members of the community, but as a legal matter, only PMC votes are binding. This is not Incubator policy, it is how the ASF works. It is the same in Jakarta, for example, where any Jakarta Committer who isn't on the PMC can vote, but only Jakarta PMC votes count. For years people didn't understand this, but please understand that Jakarta is the source of many of the wrong and bad practices in ASF projects that didn't go through either the HTTP Server project or the Incubator. the documentation link above is out of date. It was never in date. It is wrong, regardless of date. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/ products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/ jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! -- Davanum Srinivas :: http://davanum.wordpress.com
Re: PPMC guidance on new committers
On Wednesday 30 May 2007 20:59, Davanum Srinivas wrote: I like the second option. thanks for bringing this up. I don't. It assumes that the [Discuss] thread was all dandy. If not, then the vote passes in public and the Incubator PMC will become the 'bad guys who doesn't let X in'. Looking at ASF at large, one of the more common ways of committer voting is; 1. [Discuss] on private@ 2. [Vote] on private@ 3. [Vote] in [EMAIL PROTECTED] How about teaching that is the process, we inject one extra step for podlings for legal reasons (if they now exist)? 1. [Discuss] on [EMAIL PROTECTED] 2. [Vote] on [EMAIL PROTECTED] 3. [Vote] on [EMAIL PROTECTED] 4. [Vote] in [EMAIL PROTECTED] IMHO, IPMC members only need to browse the Discuss Vote threads a couple of minutes to give the heads-up. And if the mentors don't cry No this should be a swift exercise. Cheers Niclas On 5/30/07, Craig L Russell [EMAIL PROTECTED] wrote: I'd like to open the discussion on the best practice referred to by the guides/ppmc because I'm not convinced that best practice for a TLP is best practice for the incubator. The reason is that PPMC votes have no legal status. And incubator PMC members generally don't track podlings closely. So it's difficult to get incubator PMC members to vote for new committers. But incubator PMC members should be very good at looking at PPMC processes and voting based on the PPMC vote process. Personally, if I saw a vote on the incubator private PMC list for a new committer on a podling, including references to the PPMC discussion and vote, I would be inclined to vote for that committer. On the other hand, if I saw a vote on the incubator private PMC list that just offered the usual so-and-so is a great contributor, I'd have no real way to see if the PPMC was really learning its job. So IMHO, best practice for podlings is to hold a [DISCUSS] Joe Bleau for committer on the PPMC private list, followed by a [VOTE] on the PPMC private list, and then a formal [VOTE] on the private incubator PMC list with references to the discussion and vote of the PPMC. [Only the final vote is binding.] Alternatively, hold a [DISCUSS] Joe Bleau for committer on the PPMC private list, followed by a [VOTE] on the dev list, and then a formal [VOTE] on the incubator list with references to the discussion and vote of the community. This way, the incubator PMC can see that the PPMC gets the Apache Way. Craig On May 30, 2007, at 5:35 AM, Craig L Russell wrote: Having seen this identical discussion at least half a dozen times, I've committed changes to the guides/ppmc document removing the distracting (P) from the discussion on new committers. The new text says Only votes cast by Incubator PMC members are binding. If the vote is positive, and the contributor accepts the responsibility of a committer for the project, the contributor formally becomes an Apache committer. An Incubator PMC member should then follow the documented procedures to complete the process, and CC both the Incubator PMC and the PPMC when sending the necessary e-mails to root. I included the redundant Incubator in Incubator PMC simply to reinforce Noel's comment that PMC means Incubator PMC. Craig On May 29, 2007, at 8:49 PM, Noel J. Bergman wrote: Yoav Shapira wrote: I voted +0, not having had time to review the proposed committer's contributions. +1 != +0 I always thought (and the documentation at http://incubator.apache.org/guides/ppmc.html) says PPMC votes are binding. It says (P), and the (P) clearly does not belong. Notice that elsewhere it properly says PPMC, with no (), and the places that are wrong were PMC to which someone added (P). Likewise IPMC should simply be PMC. There is only one PMC: the Incubator PMC. I don't know how to say this more clearly. The PPMC is not a recognized entity in the ASF Bylaws. The PMC is the legal entity, and only PMC votes count in any ASF project. PPMC members should still vote, as can other members of the community, but as a legal matter, only PMC votes are binding. This is not Incubator policy, it is how the ASF works. It is the same in Jakarta, for example, where any Jakarta Committer who isn't on the PMC can vote, but only Jakarta PMC votes count. For years people didn't understand this, but please understand that Jakarta is the source of many of the wrong and bad practices in ASF projects that didn't go through either the HTTP Server project or the Incubator. the documentation link above is out of date. It was never in date. It is wrong, regardless of date. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMC guidance on new committers
On 5/30/07, Carl Trieloff [EMAIL PROTECTED] wrote: behind this practice. If the mail to root has to be cc-ed to general list and PPMC and has 3 PMC votes on it then it would seem to me that it could be send by anyone. I can only think of one reason: [EMAIL PROTECTED] is not accessible to PPMC members that are not IPMC members. If the commiter acceptance vote is held in private, there is no way for a PPMC member to provide a link to that vote. That said, I think letting PPMC members send the message to root is great for educational purposes and lets the podling integrate more into Apache ways. Martijn -- Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.6 contains a very important fix. Download Wicket now! http://wicketframework.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMC guidance on new committers
Hi, On 5/30/07, Craig L Russell [EMAIL PROTECTED] wrote: Personally, if I saw a vote on the incubator private PMC list for a new committer on a podling, including references to the PPMC discussion and vote, I would be inclined to vote for that committer. On the other hand, if I saw a vote on the incubator private PMC list that just offered the usual so-and-so is a great contributor, I'd have no real way to see if the PPMC was really learning its job. You're not the first one to have mentioned this approach. The thing that troubles me in this approach is that it distorts the meaning of +1/0/+1 votes with respect to committership. To me, a +1 vote on someone becoming a committer means I've personally reviewed the person's contributions (in terms of code, mailing list activity, etc.) in decent depth. It does NOT mean I trust a bunch of other people to form my opinion for me. If, for whatever reason (for example a long holiday weekend), I haven't had a chance to look at the person's history, and a vote is required right now, a 0 seems more correct. Voting +1 explicitly without due diligence just so someone can reach a 3 +1 bar seems wrong to me. I guess there do exist other options, like asking for the vote to be open longer, saying explicitly that my +1 is for the process and the PMC without reviewing the person, and others. So maybe this is soluble and OK after all. I'm just thinking out loud here... Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMC guidance on new committers
Hi Carl, On May 30, 2007, at 6:14 AM, Carl Trieloff wrote: One more question on this topic as I have also seen differing views from different members of the Incubator PMC on: Who can and who can not send the account setup mail to root? Given each new committer vote will have 3 PMC votes, why does a mentor have to send the account setup to root? Why can't the mail to root just contain a link to the vote result with 3 PMC members on it from the general list? This is a question that I believe only infrastructure can answer. The issue is that right now, root has to respond only to emails from PMC chairs, and it's easy to verify that it's really the PMC chair sending the request. Some PMC members have the view that any PPMC member should be able to send the account setup to root to learn the system, others say it has to be a mentor. Cliff has kindly taken care of most of these mail for us so far so this is more theoretical, however having clarity on this in the document would also be good as I have wondered about the reasoning behind this practice. If the mail to root has to be cc-ed to general list and PPMC and has 3 PMC votes on it then it would seem to me that it could be send by anyone. If anyone can send the request, then root has to do more work by verifying the vote thread, following the link provided in the message, to make sure that the request is valid. I agree that it's better for the PPMC members themselves to be able to make the request to root, but I'd have to leave it up to infrastructure to decide if they can handle it. Craig Carl. Craig L Russell wrote: Having seen this identical discussion at least half a dozen times, I've committed changes to the guides/ppmc document removing the distracting (P) from the discussion on new committers. The new text says Only votes cast by Incubator PMC members are binding. If the vote is positive, and the contributor accepts the responsibility of a committer for the project, the contributor formally becomes an Apache committer. An Incubator PMC member should then follow the documented procedures to complete the process, and CC both the Incubator PMC and the PPMC when sending the necessary e-mails to root. I included the redundant Incubator in Incubator PMC simply to reinforce Noel's comment that PMC means Incubator PMC. Craig On May 29, 2007, at 8:49 PM, Noel J. Bergman wrote: Yoav Shapira wrote: I voted +0, not having had time to review the proposed committer's contributions. +1 != +0 I always thought (and the documentation at http://incubator.apache.org/guides/ppmc.html) says PPMC votes are binding. It says (P), and the (P) clearly does not belong. Notice that elsewhere it properly says PPMC, with no (), and the places that are wrong were PMC to which someone added (P). Likewise IPMC should simply be PMC. There is only one PMC: the Incubator PMC. I don't know how to say this more clearly. The PPMC is not a recognized entity in the ASF Bylaws. The PMC is the legal entity, and only PMC votes count in any ASF project. PPMC members should still vote, as can other members of the community, but as a legal matter, only PMC votes are binding. This is not Incubator policy, it is how the ASF works. It is the same in Jakarta, for example, where any Jakarta Committer who isn't on the PMC can vote, but only Jakarta PMC votes count. For years people didn't understand this, but please understand that Jakarta is the source of many of the wrong and bad practices in ASF projects that didn't go through either the HTTP Server project or the Incubator. the documentation link above is out of date. It was never in date. It is wrong, regardless of date. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/ jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: PPMC guidance on new committers
Craig L Russell wrote: Hi Carl, On May 30, 2007, at 6:14 AM, Carl Trieloff wrote: One more question on this topic as I have also seen differing views from different members of the Incubator PMC on: Who can and who can not send the account setup mail to root? Given each new committer vote will have 3 PMC votes, why does a mentor have to send the account setup to root? Why can't the mail to root just contain a link to the vote result with 3 PMC members on it from the general list? This is a question that I believe only infrastructure can answer. The issue is that right now, root has to respond only to emails from PMC chairs, and it's easy to verify that it's really the PMC chair sending the request. Some PMC members have the view that any PPMC member should be able to send the account setup to root to learn the system, others say it has to be a mentor. Cliff has kindly taken care of most of these mail for us so far so this is more theoretical, however having clarity on this in the document would also be good as I have wondered about the reasoning behind this practice. If the mail to root has to be cc-ed to general list and PPMC and has 3 PMC votes on it then it would seem to me that it could be send by anyone. If anyone can send the request, then root has to do more work by verifying the vote thread, following the link provided in the message, to make sure that the request is valid. I agree that it's better for the PPMC members themselves to be able to make the request to root, but I'd have to leave it up to infrastructure to decide if they can handle it. Craig, Thanks, that is a meaningful/practical reason. Carl. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMC guidance on new committers
Hi Yoav, On May 30, 2007, at 6:38 AM, Yoav Shapira wrote: Hi, On 5/30/07, Craig L Russell [EMAIL PROTECTED] wrote: Personally, if I saw a vote on the incubator private PMC list for a new committer on a podling, including references to the PPMC discussion and vote, I would be inclined to vote for that committer. On the other hand, if I saw a vote on the incubator private PMC list that just offered the usual so-and-so is a great contributor, I'd have no real way to see if the PPMC was really learning its job. You're not the first one to have mentioned this approach. The thing that troubles me in this approach is that it distorts the meaning of +1/0/+1 votes with respect to committership. To me, a +1 vote on someone becoming a committer means I've personally reviewed the person's contributions (in terms of code, mailing list activity, etc.) in decent depth. In a TLP PMC, I agree that a +1 should mean due diligence. PMC members should be aware of contributions made by non-committers, and the [DISCUSSION] before the [VOTE] should uncover any issues. Which implies that due diligence really should be done during [DISCUSS] and not wait until [VOTE]. It does NOT mean I trust a bunch of other people to form my opinion for me. If, for whatever reason (for example a long holiday weekend), I haven't had a chance to look at the person's history, and a vote is required right now, a 0 seems more correct. For a TLP PMC, I agree. But if there is some reason to delay the vote, I don't have any trouble with an incubator PMC member requesting an extension. Voting +1 explicitly without due diligence just so someone can reach a 3 +1 bar seems wrong to me. I guess there do exist other options, like asking for the vote to be open longer, saying explicitly that my +1 is for the process and the PMC without reviewing the person, and others. So maybe this is soluble and OK after all. I'm just thinking out loud here... My main argument here is that the incubator is not a normal project. The role of the incubator PMC is to guide podlings in the way of Apache. And a big part of the way is learning how to grant commit privileges to people who demonstrate to the project that they deserve it. I'm also very aware that most incubator PMC members simply don't have the time to perform due diligence on requests for commit access for podlings. So what I'm proposing allows incubator PMC members to perform due diligence if they want to, or simply provide oversight of the PPMC's actions on new committers. Craig Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: PPMC guidance on new committers
On 30/05/07, Craig L Russell [EMAIL PROTECTED] wrote: Hi Yoav, On May 30, 2007, at 6:38 AM, Yoav Shapira wrote: Hi, On 5/30/07, Craig L Russell [EMAIL PROTECTED] wrote: Personally, if I saw a vote on the incubator private PMC list for a new committer on a podling, including references to the PPMC discussion and vote, I would be inclined to vote for that committer. On the other hand, if I saw a vote on the incubator private PMC list that just offered the usual so-and-so is a great contributor, I'd have no real way to see if the PPMC was really learning its job. You're not the first one to have mentioned this approach. The thing that troubles me in this approach is that it distorts the meaning of +1/0/+1 votes with respect to committership. To me, a +1 vote on someone becoming a committer means I've personally reviewed the person's contributions (in terms of code, mailing list activity, etc.) in decent depth. In a TLP PMC, I agree that a +1 should mean due diligence. PMC members should be aware of contributions made by non-committers, and the [DISCUSSION] before the [VOTE] should uncover any issues. Which implies that due diligence really should be done during [DISCUSS] and not wait until [VOTE]. It does NOT mean I trust a bunch of other people to form my opinion for me. If, for whatever reason (for example a long holiday weekend), I haven't had a chance to look at the person's history, and a vote is required right now, a 0 seems more correct. For a TLP PMC, I agree. But if there is some reason to delay the vote, I don't have any trouble with an incubator PMC member requesting an extension. Voting +1 explicitly without due diligence just so someone can reach a 3 +1 bar seems wrong to me. I guess there do exist other options, like asking for the vote to be open longer, saying explicitly that my +1 is for the process and the PMC without reviewing the person, and others. So maybe this is soluble and OK after all. I'm just thinking out loud here... My main argument here is that the incubator is not a normal project. The role of the incubator PMC is to guide podlings in the way of Apache. And a big part of the way is learning how to grant commit privileges to people who demonstrate to the project that they deserve it. I'm also very aware that most incubator PMC members simply don't have the time to perform due diligence on requests for commit access for podlings. So what I'm proposing allows incubator PMC members to perform due diligence if they want to, or simply provide oversight of the PPMC's actions on new committers. Craig Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! What we need is two public lists that can be referenced so that the incubator PMC can be satisfied that the podling is adhering to policy. To adapt the suggestion by Niclas, I would say that step 3 be performed on the public incubator list. As the [EMAIL PROTECTED] list is also private a link cannot be made to the discussion so the three active mentors of the project are the only ones that would be able to approve the process carried out by the PPMC (Unless IPMC members can browse the private lists). It is unlikely that this process would be denied on the public list as the three mentors should have addressed any problems on the [EMAIL PROTECTED] list. This of course requires that all podlings have three mentors and that they are actively guiding their podling, not an unreasonable request IMHO. This would then give the PPMC authority to carry out the [Vote] on the [EMAIL PROTECTED] list and a reference to include on the email to root to verify that the work done on [EMAIL PROTECTED] is in line with 'The Apache Way' even though it cannot be referenced. 1. [Discuss] on [EMAIL PROTECTED] 2. [Vote] on [EMAIL PROTECTED] 3. [Vote] [Process Approval] on [EMAIL PROTECTED] 4. [Vote] in [EMAIL PROTECTED] Regards -- Martin Ritchie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMC guidance on new committers
Craig L Russell wrote: Hi Carl, On May 30, 2007, at 6:14 AM, Carl Trieloff wrote: One more question on this topic as I have also seen differing views from different members of the Incubator PMC on: Who can and who can not send the account setup mail to root? Given each new committer vote will have 3 PMC votes, why does a mentor have to send the account setup to root? Why can't the mail to root just contain a link to the vote result with 3 PMC members on it from the general list? This is a question that I believe only infrastructure can answer. The issue is that right now, root has to respond only to emails from PMC chairs, and it's easy to verify that it's really the PMC chair sending the request. In the general PMC case, root responds to requests from PMC members: The project PMC needs to send an email to root at apache.org requesting a new account to be created [1]. It says project PMC not project PMC chair. But I think the issue is that PPMCs aren't real PMCs, so for the Incubator the request should come from a mentor. -jean [1] http://www.apache.org/dev/pmc.html#newcommitter Some PMC members have the view that any PPMC member should be able to send the account setup to root to learn the system, others say it has to be a mentor. Cliff has kindly taken care of most of these mail for us so far so this is more theoretical, however having clarity on this in the document would also be good as I have wondered about the reasoning behind this practice. If the mail to root has to be cc-ed to general list and PPMC and has 3 PMC votes on it then it would seem to me that it could be send by anyone. If anyone can send the request, then root has to do more work by verifying the vote thread, following the link provided in the message, to make sure that the request is valid. I agree that it's better for the PPMC members themselves to be able to make the request to root, but I'd have to leave it up to infrastructure to decide if they can handle it. Craig Carl. Craig L Russell wrote: Having seen this identical discussion at least half a dozen times, I've committed changes to the guides/ppmc document removing the distracting (P) from the discussion on new committers. The new text says Only votes cast by Incubator PMC members are binding. If the vote is positive, and the contributor accepts the responsibility of a committer for the project, the contributor formally becomes an Apache committer. An Incubator PMC member should then follow the documented procedures to complete the process, and CC both the Incubator PMC and the PPMC when sending the necessary e-mails to root. I included the redundant Incubator in Incubator PMC simply to reinforce Noel's comment that PMC means Incubator PMC. Craig On May 29, 2007, at 8:49 PM, Noel J. Bergman wrote: Yoav Shapira wrote: I voted +0, not having had time to review the proposed committer's contributions. +1 != +0 I always thought (and the documentation at http://incubator.apache.org/guides/ppmc.html) says PPMC votes are binding. It says (P), and the (P) clearly does not belong. Notice that elsewhere it properly says PPMC, with no (), and the places that are wrong were PMC to which someone added (P). Likewise IPMC should simply be PMC. There is only one PMC: the Incubator PMC. I don't know how to say this more clearly. The PPMC is not a recognized entity in the ASF Bylaws. The PMC is the legal entity, and only PMC votes count in any ASF project. PPMC members should still vote, as can other members of the community, but as a legal matter, only PMC votes are binding. This is not Incubator policy, it is how the ASF works. It is the same in Jakarta, for example, where any Jakarta Committer who isn't on the PMC can vote, but only Jakarta PMC votes count. For years people didn't understand this, but please understand that Jakarta is the source of many of the wrong and bad practices in ASF projects that didn't go through either the HTTP Server project or the Incubator. the documentation link above is out of date. It was never in date. It is wrong, regardless of date. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/ jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! - To unsubscribe, e-mail:
RE: PPMC guidance on new committers
Craig Russell wrote: I'd like to open the discussion on the best practice referred to by the guides/ppmc because I'm not convinced that best practice for a TLP is best practice for the incubator. Personally, if I saw a vote on the incubator private PMC list for a new committer on a podling, including references to the PPMC discussion and vote, I would be inclined to vote for that committer. On the other hand, if I saw a vote on the incubator private PMC list that just offered the usual so-and-so is a great contributor, I'd have no real way to see if the PPMC was really learning its job. This is mostly a limitation of being a non-ASF Member. ASF Members have access to all of the mailing list archives, including private lists. So IMHO, best practice for podlings is to hold a [DISCUSS] Joe Bleau for committer on the PPMC private list, followed by a [VOTE] on the PPMC private list, and then a formal [VOTE] on the private incubator PMC list with references to the discussion and vote of the PPMC. Alternatively, hold a [DISCUSS] Joe Bleau for committer on the PPMC private list, followed by a [VOTE] on the dev list, and then a formal [VOTE] on the incubator list with references to the discussion and vote of the community. The only difference being the formal vote being on the open list, right? Do you expect people to vote -1 in public, or do you expect the PPMC not to hold the vote at all if people express negative views? And do you want negative views about a Committer to be maintained in perpetuity around the Internet? I've certainly seen that raised as a concern, particularly as more and more employers mine the Internet for information about potential employees. --- Noel smime.p7s Description: S/MIME cryptographic signature
RE: PPMC guidance on new committers
Carl Trieloff wrote: One more question on this topic as I have also seen differing views from different members of the Incubator PMC on: Who can and who can not send the account setup mail to root? The view that counts is from http://www.apache.org/dev/pmc.html#newcommitter. Please note: that is not an Incubator URL. These are ASF-wide documents, and everyone should become familar with the contents under http://www.apache.org/dev. Given each new committer vote will have 3 PMC votes, why does a mentor have to send the account setup to root? Why can't the mail to root just contain a link to the vote result with 3 PMC members on it from the general list? See the above URL. Technically, it can come from any PMC member, not just a Mentor. It ought to come from a Mentor in terms of social interfactions, but if your Mentor(s) are not being responsive, any PMC member can do it. Some PMC members have the view that any PPMC member should be able to send the account setup to root to learn the system, others say it has to be a mentor. See above. Any PMC mamber. The Incubator is unique in that we are the sole umbrella structure (there are/were others, and the ASF is deep into the process of eliminating them). Here in the Incubator, we have to navigate a duality: wanting the PPMC as much as possible to manage its project with guidance, and at the same time having to ensure PMC oversight. So although only PMC votes are binding, and some actions require PMC involvement, this is why having enough Mentors on a project to satisfy voting requirements and other PMC actions is a good thing. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMC guidance on new committers
On May 30, 2007, at 10:00 AM, Noel J. Bergman wrote: Craig Russell wrote: I'd like to open the discussion on the best practice referred to by the guides/ppmc because I'm not convinced that best practice for a TLP is best practice for the incubator. Personally, if I saw a vote on the incubator private PMC list for a new committer on a podling, including references to the PPMC discussion and vote, I would be inclined to vote for that committer. On the other hand, if I saw a vote on the incubator private PMC list that just offered the usual so-and-so is a great contributor, I'd have no real way to see if the PPMC was really learning its job. This is mostly a limitation of being a non-ASF Member. ASF Members have access to all of the mailing list archives, including private lists. Actually, as an incubator pmc member, I don't necessarily want to mine the archives. I want to see that the PPMC members have expressed their opinions on the candidates. So IMHO, best practice for podlings is to hold a [DISCUSS] Joe Bleau for committer on the PPMC private list, followed by a [VOTE] on the PPMC private list, and then a formal [VOTE] on the private incubator PMC list with references to the discussion and vote of the PPMC. Alternatively, hold a [DISCUSS] Joe Bleau for committer on the PPMC private list, followed by a [VOTE] on the dev list, and then a formal [VOTE] on the incubator list with references to the discussion and vote of the community. The only difference being the formal vote being on the open list, right? Right. Do you expect people to vote -1 in public, or do you expect the PPMC not to hold the vote at all if people express negative views? I expect that during the [DISCUSS] part of the process, if anyone expresses concerns about the suitability of the candidate, then these concerns should be thoroughly resolved before further action is taken. So in this scenario, no one ever has to vote -1 in public. And do you want negative views about a Committer to be maintained in perpetuity around the Internet? I've certainly seen that raised as a concern, particularly as more and more employers mine the Internet for information about potential employees. I share that concern. If serious objections are raised during [DISCUSSION] then the PPMC member proposing the candidate needs to either resolve the objections or wait some time before trying to propose the candidate again. Either way avoids embarrassment. Craig --- Noel Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: PPMC guidance on new committers
Hi Jean, On May 30, 2007, at 8:11 AM, Jean T. Anderson wrote: Craig L Russell wrote: Hi Carl, On May 30, 2007, at 6:14 AM, Carl Trieloff wrote: One more question on this topic as I have also seen differing views from different members of the Incubator PMC on: Who can and who can not send the account setup mail to root? Given each new committer vote will have 3 PMC votes, why does a mentor have to send the account setup to root? Why can't the mail to root just contain a link to the vote result with 3 PMC members on it from the general list? This is a question that I believe only infrastructure can answer. The issue is that right now, root has to respond only to emails from PMC chairs, and it's easy to verify that it's really the PMC chair sending the request. In the general PMC case, root responds to requests from PMC members: The project PMC needs to send an email to root at apache.org requesting a new account to be created [1]. It says project PMC not project PMC chair. Thanks for the correction. I need to remind myself to read the entire documentation every time, and not rely on memory. ;-) But I think the issue is that PPMCs aren't real PMCs, Right. so for the Incubator the request should come from a mentor. I'd prefer to say that the request must come from an incubator pmc member. But then the ppmc member who is managing the new committer process should ask an incubator pmc member to make the root request, and that incubator pmc member would naturally but not necessarily be one of the podling's mentors. Craig -jean [1] http://www.apache.org/dev/pmc.html#newcommitter Some PMC members have the view that any PPMC member should be able to send the account setup to root to learn the system, others say it has to be a mentor. Cliff has kindly taken care of most of these mail for us so far so this is more theoretical, however having clarity on this in the document would also be good as I have wondered about the reasoning behind this practice. If the mail to root has to be cc-ed to general list and PPMC and has 3 PMC votes on it then it would seem to me that it could be send by anyone. If anyone can send the request, then root has to do more work by verifying the vote thread, following the link provided in the message, to make sure that the request is valid. I agree that it's better for the PPMC members themselves to be able to make the request to root, but I'd have to leave it up to infrastructure to decide if they can handle it. Craig Carl. Craig L Russell wrote: Having seen this identical discussion at least half a dozen times, I've committed changes to the guides/ppmc document removing the distracting (P) from the discussion on new committers. The new text says Only votes cast by Incubator PMC members are binding. If the vote is positive, and the contributor accepts the responsibility of a committer for the project, the contributor formally becomes an Apache committer. An Incubator PMC member should then follow the documented procedures to complete the process, and CC both the Incubator PMC and the PPMC when sending the necessary e-mails to root. I included the redundant Incubator in Incubator PMC simply to reinforce Noel's comment that PMC means Incubator PMC. Craig On May 29, 2007, at 8:49 PM, Noel J. Bergman wrote: Yoav Shapira wrote: I voted +0, not having had time to review the proposed committer's contributions. +1 != +0 I always thought (and the documentation at http://incubator.apache.org/guides/ppmc.html) says PPMC votes are binding. It says (P), and the (P) clearly does not belong. Notice that elsewhere it properly says PPMC, with no (), and the places that are wrong were PMC to which someone added (P). Likewise IPMC should simply be PMC. There is only one PMC: the Incubator PMC. I don't know how to say this more clearly. The PPMC is not a recognized entity in the ASF Bylaws. The PMC is the legal entity, and only PMC votes count in any ASF project. PPMC members should still vote, as can other members of the community, but as a legal matter, only PMC votes are binding. This is not Incubator policy, it is how the ASF works. It is the same in Jakarta, for example, where any Jakarta Committer who isn't on the PMC can vote, but only Jakarta PMC votes count. For years people didn't understand this, but please understand that Jakarta is the source of many of the wrong and bad practices in ASF projects that didn't go through either the HTTP Server project or the Incubator. the documentation link above is out of date. It was never in date. It is wrong, regardless of date. --- Noel -- -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/ products/ jdo
Re: PPMC guidance on new committers
Craig L Russell wrote: Hi Jean, On May 30, 2007, at 8:11 AM, Jean T. Anderson wrote: Craig L Russell wrote: Hi Carl, On May 30, 2007, at 6:14 AM, Carl Trieloff wrote: One more question on this topic as I have also seen differing views from different members of the Incubator PMC on: Who can and who can not send the account setup mail to root? Given each new committer vote will have 3 PMC votes, why does a mentor have to send the account setup to root? Why can't the mail to root just contain a link to the vote result with 3 PMC members on it from the general list? This is a question that I believe only infrastructure can answer. The issue is that right now, root has to respond only to emails from PMC chairs, and it's easy to verify that it's really the PMC chair sending the request. In the general PMC case, root responds to requests from PMC members: The project PMC needs to send an email to root at apache.org requesting a new account to be created [1]. It says project PMC not project PMC chair. Thanks for the correction. I need to remind myself to read the entire documentation every time, and not rely on memory. ;-) I don't know of anyone who has committed all apache docs to memory -- I sure haven't. :-) The only reason I'm attentive to this detail is as a pmc chair myself I don't want account requests to be held up just because I don't happen to be around. But I think the issue is that PPMCs aren't real PMCs, Right. so for the Incubator the request should come from a mentor. I'd prefer to say that the request must come from an incubator pmc member. yes; I think what matters to root is that the request is made from somebody formally on the PMC, which makes this somebody easily verified by checking https://svn.apache.org/repos/private/committers/board/committee-info.txt . Just like most of us haven't committed all apache docs to memory, root won't have committed the list of who is on which PMC to memory. We want to make it easy for root to process that account request. -jean But then the ppmc member who is managing the new committer process should ask an incubator pmc member to make the root request, and that incubator pmc member would naturally but not necessarily be one of the podling's mentors. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMC guidance on new committers
Here's what I'd like to do with the ppmc guide. Change: Voting in a new committer If a developer has contributed a significant number of high-quality patches, is interested in continuing the contribution, and has demonstrated the ability to work well with others under the Apache guidelines, the project might vote to grant that developer commit access. See the ASF How it Works document, which explains meritocracy and roles. Discussion of a potential new committer should take place on the podling project's private list; normally it would take place on a project's private list. After vetting the new candidate, the vote can be called on either one of the two places listed below (notice the balance between private and public lists): The podling's private list, with notice posted to the Incubator private list. The developer list, with notice posted to the Incubator general list. The practice of a private discussion followed by a public, pro-forma, vote is re-emerging as a Best Practice for ASF projects (see this comprehensive discussion about these practices). Only votes cast by Incubator PMC members are binding. If the vote is positive, and the contributor accepts the responsibility of a committer for the project, the contributor formally becomes an Apache committer. An Incubator PMC member should then follow the documented procedures to complete the process, and CC both the Incubator PMC and the PPMC when sending the necessary e-mails to root. Please direct the new committer to the Apache developer's pages, to the Apache Incubator site and to the Incubator Committers Guide for important additional information. to: Voting in a new committer If a developer has contributed a significant number of high-quality patches, is interested in continuing the contribution, and has demonstrated the ability to work well with others under the Apache guidelines, the project might vote to grant that developer commit access. See the ASF How it Works document, which explains meritocracy and roles. One of the PPMC members should lead the process of accepting a new committer. For the purposes of this document, the proposing PPMC member is referred to as the proposer, and the proposed committer is referred to as the nominee. Discussion of a nominee should take place on the podling project's private (PPMC) list [normally it would take place on a project's private list]. If there are any concerns raised during the discussion, these need to be resolved so that there is consensus among the PPMC members as to the suitability of the nominee for the project and for Apache. After vetting the nominee, the vote can be called on either one of the two places listed below (notice the balance between private and public lists): o The podling's private list, with notice posted to the Incubator private list. The notice is a separate email forwarding the vote email with a cover statement that this vote is underway on the podling's private list. This is a good approach if you are not sure of getting the required three +1 votes from incubator PMC members on the first vote. After completing the vote on the PPMC list, if there are not three +1 votes from incubator PMC members, the proposer should call a vote on the incubator PMC private list with a reference to the archived discussion and vote by the PPMC. o The podling's developer list, with notice posted to the Incubator general list. The notice is a separate email forwarding the vote email with a cover statement that this vote is underway on the podling's developer list. This is a good approach if you are sure of getting the required three +1 votes from incubator PMC members. It is embarrassing to have a public vote fail or take a very long time because not enough incubator PMC members vote and have to be solicited to vote for a committer. Only votes cast by Incubator PMC members are binding. If the vote is positive (three or more binding +1 votes and no binding -1 votes), the proposer offers committership to the nominee. If the nominee accepts the responsibility of a committer for the project, the nominee formally becomes an Apache committer. The proposer then asks an Incubator PMC member to follow the documented procedures to complete the process. If the nominee is already an Apache committer on another project, the proposer asks the incubator PMC chair to update the authorization file to include the nominee as a committer on the podling. If the nominee is not already an Apache committer, the incubator PMC member CC's both the Incubator PMC and the PPMC when sending the necessary e- mails to root. Normally, the incubator PMC member is a Mentor on the podling's PPMC but due to unavailability, the proposer can ask any incubator PMC member. The proposer then directs the new committer to the Apache developer's pages, to the Apache Incubator site, and to
