Re: PPMCs [was Re: what are required for contributing to release management]
On Oct 1, 2006, at 11:36 AM, Dan Diephouse wrote: I assume you're referring to this sentence: Initially, it is composed of the Podling's mentors and initial committers. I have also found some threads which indicate that all committers should be added [1][2].opinion I am pretty philosophically against making every committer PPMC members. Who is advocating that?? certainly not I. I'm just stating that the initial list of committers are likely those most active in the community of that code and are good candidates for initial PPMC membership. In fact, I would guess that they are better judges than Mentors. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMCs [was Re: what are required for contributing to release management]
On Oct 1, 2006, at 5:17 PM, Justin Erenkrantz wrote: On 10/1/06, Dan Diephouse [EMAIL PROTECTED] wrote: would however encourage only voting people in after they an appropriate level of committment and involvement with the project. This creates a dividing line by omitting past contributions from the discussion which I feel is inappropriate. For example, if I were to work on a project for many months at Google Code and then propose it to come here, why shouldn't I continue to have a say in what the project does? Why do I need to justify myself all over again? Why aren't my past contributions enough to merit a seat on the PPMC? What gives the mentors the power to 'reset' the community and block me from participating until I jump through their vague and ill-defined hoops? -- justin ++1. If the problem is piling on in the committer list for the proposal *then that should be addressed at the proposal timeframe and before the podling is accepted*! As mentioned in a different Email, I'm +1 on adding in, in the proposal: Mentors | Initial PPMC | Initial Committers if people want it explicit, but no matter what, this should be handled before podlings are accepted, not after. I think that issue is that some Mentors have different feelings from what is documented... Recall, after all, that people from the outside ONLY have access to what is documented, not our internal discussions... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMCs [was Re: what are required for contributing to release management]
Let me see if I can summarize some of the issues as I see them... Currently, new podlings come from one of three sources: 1) Closed source code (usually from and external company) that is useful and thus would like to be made open source. (tuscany, yoko, etc...) 2) One (or more) open source communities wanting to move their project to Apache. (CXF, Wicket, etc...) 3) Completely ground up, no code yet exists, ideas to be complete built in apache. All three have a different set of initial concerns that I think we all need to think about.I don't know enough about the 3rd case so I cannot comment on it. Does that even happen? Or is it mostly some code exists somewhere? For case (2) - there are public communities that exist with commiters, effective PMC's, etc... We should definitely leverage those and move those lists along with the code whenever possible. However, the thing that I've seen recently is during the proposals a LOT more people are added onto the initial commiter list than have earned commit access in the other community. To me, that is the the problem. If they didn't earn it there, why should we give it to them for free?Thus, for (2), I would suggest just commiters from the external project(s) and no others for the initial bootstrap list. I'd like to see something mentioned about inactive commiters from the other projects, but the PPMC could deal with that in incubation or upon graduation. One thought would be to ask each of the commiters on those projects if they want to be commiters on the new one at apache.If yes, then add them. If they say no, no harm done.Some people may actually prefer not to be apache commiters. Taking the CXF proposal for example (I was involved with this one so I'm just as guilty as anyone here): of the 34 proposed initial commiters, I think 8-10 of them had not been commiters at either Celtix or XFire. Another 5 or 6 or so would be in the inactive category. For case (1), there doesn't exist a community already except for within a single company. If we just go with those who have worked on the code as initial commiters, they'd all be from one company. (not that I'm saying that's bad for a start in the incubator. I'm actually 100% OK with that. To me, that's a good thing.) However, going the other way of throwing on 20+ commiters that have yet to even see the code is probably not good. Again, to me, that's giving out karma like it's candy. Anyone who asks during the proposal phase gets it without any other criteria. Unfortunately, lately, it seems like there are more of the later case of throwing on people that express any interest. Personally, IMO, I'd like the initial commit list to be ONLY those who have seen the code, and in the incubator, they can completely build their community. I COULD see adding other industry experts (example: if the project is implementing a spec, having some of the spec reps on the project might be OK to help direct it), but even then, I don't see the downside of having them earn it. Anyway, I'm not sure of the right approach for dealing with (1). I would say that in all three cases, the incubator PMC needs to do a better job of reviewing the commiter lists before the vote. Basically, I'd like to know: 1) Why are projects being submitted with 20-40 initial commiters? Most of the successful projects in apache don't have that many. The barrier to getting accepted at apache is supposed to be very low. To me, 3-5 commiters should be more than adequate. One the PPMC is setup, they can quickly and easily grow their community. That's not a problem.It's easier, and certainly produces less arguments, to grow a community than to remove people that don't belong. 2) What's the downside of having people in the incubator projects actually earn the commit rights instead of giving it freely? If normal apache projects grow their community through contributions, why shouldn't a podling try and act like a normal apache project?The recent trend of giving everyone commit access immediately, to me, has more downsides. It doesn't follow the apache meritorious processes and it can also cause the community to fracture if corrective action is taken.I really don't like the PPMC can correct it in incubation idea.From this whole thread, you can see that the major effect this has is to splinter the community, causes heated discussions, pisses people off, etc If a project/podling can start off on the right foot, there would be a much better experience. Of course, I'm not an incubator PMC member so my opinion definitely doesn't bind to a vote and I don't have the years of experience and expertise, this is just based on my (limited) experience so far. Enjoy! Dan On Monday October 02 2006 8:42 am, Jim Jagielski wrote: On Oct 1, 2006, at 5:17 PM, Justin Erenkrantz wrote: On 10/1/06, Dan Diephouse [EMAIL
RE: PPMCs [was Re: what are required for contributing to release management]
As a general statement, it is difficult if not impossible to do the right thing when the rules keep changing. The only sensible thing at this point is to continue the CeltiXfire project as originally proposed and accepted. If there are any retrospective issues or problems let's get them on this or another public email list and fix them. Eric -Original Message- From: Jim Jagielski [mailto:[EMAIL PROTECTED] Sent: Monday, October 02, 2006 8:43 AM To: general@incubator.apache.org Subject: Re: PPMCs [was Re: what are required for contributing to release management] On Oct 1, 2006, at 5:17 PM, Justin Erenkrantz wrote: On 10/1/06, Dan Diephouse [EMAIL PROTECTED] wrote: would however encourage only voting people in after they an appropriate level of committment and involvement with the project. This creates a dividing line by omitting past contributions from the discussion which I feel is inappropriate. For example, if I were to work on a project for many months at Google Code and then propose it to come here, why shouldn't I continue to have a say in what the project does? Why do I need to justify myself all over again? Why aren't my past contributions enough to merit a seat on the PPMC? What gives the mentors the power to 'reset' the community and block me from participating until I jump through their vague and ill-defined hoops? -- justin ++1. If the problem is piling on in the committer list for the proposal *then that should be addressed at the proposal timeframe and before the podling is accepted*! As mentioned in a different Email, I'm +1 on adding in, in the proposal: Mentors | Initial PPMC | Initial Committers if people want it explicit, but no matter what, this should be handled before podlings are accepted, not after. I think that issue is that some Mentors have different feelings from what is documented... Recall, after all, that people from the outside ONLY have access to what is documented, not our internal discussions... - 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: PPMCs [was Re: what are required for contributing to release management]
On Sep 30, 2006, at 11:51 AM, Jason van Zyl wrote: On 28 Sep 06, at 12:59 PM 28 Sep 06, Garrett Rooney wrote: Well, PMCs are formed by the board when a project moves to top level status. PPMCs are formed for an incubating project, and exactly how that works tends to differ a bit between projects. Some mentors start off with just the mentors on the PPMC, and then invite project members as time goes on (or that's the impression I've gotten). Others just start with the whole group of committers plus the mentors on the PPMC (that's what we did with Abdera). I think starting with the mentors is the wisest choice as at that point any committers can be brought aboard if deemed fit. So that can support both models as all committers can be brought aboard if it fits, or over time if more suitable. I was also confused about this as I heard one thing from Noel and one thing from Jim, but the mentors deciding seems sensible as projects can be dealt with on a case by case basis. I don't believe committers should automatically be made (P)PMC members as to me it's a different level of understanding and commitment. http://incubator.apache.org/guides/ppmc.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMCs [was Re: what are required for contributing to release management]
Hi Jim, Jim Jagielski wrote: On Sep 30, 2006, at 11:51 AM, Jason van Zyl wrote: On 28 Sep 06, at 12:59 PM 28 Sep 06, Garrett Rooney wrote: Well, PMCs are formed by the board when a project moves to top level status. PPMCs are formed for an incubating project, and exactly how that works tends to differ a bit between projects. Some mentors start off with just the mentors on the PPMC, and then invite project members as time goes on (or that's the impression I've gotten). Others just start with the whole group of committers plus the mentors on the PPMC (that's what we did with Abdera). I think starting with the mentors is the wisest choice as at that point any committers can be brought aboard if deemed fit. So that can support both models as all committers can be brought aboard if it fits, or over time if more suitable. I was also confused about this as I heard one thing from Noel and one thing from Jim, but the mentors deciding seems sensible as projects can be dealt with on a case by case basis. I don't believe committers should automatically be made (P)PMC members as to me it's a different level of understanding and commitment. http://incubator.apache.org/guides/ppmc.html I assume you're referring to this sentence: Initially, it is composed of the Podling's mentors and initial committers. I have also found some threads which indicate that all committers should be added [1][2]. I want to know here - who is wrong? The documentation? Or the previous incubated projects who didn't add all the initial committers? There is also the following sentence which adds some doubt that the above is the official policy: The PPMC is directly responsible for the oversight of the podling and it also decides who to add as a PPMC member. While this could be referrering to post PPMC formation, it isn't clear. I will happily make a patch for the documentation to make things more clear if there is consensus. opinion I am pretty philosophically against making every committer PPMC members. Apache is meritocracy based and IMO it makes much more sense to start with the mentors on the PPMC and have committers voted on based on their leadership. There may be many people on the incubation proposal or who have committed code to a project in the past, but an additional level of leadership is needed [3]. Not everyone may have the necessary leadership skills, and to presuppose they do because they have contributed good code, is IMO, a mistake. /opinion Cheerz, - Dan 1. http://mail-archives.apache.org/mod_mbox/incubator-general/200312.mbox/[EMAIL PROTECTED] 2. http://mail-archives.apache.org/mod_mbox/incubator-general/200603.mbox/[EMAIL PROTECTED] 3. See Project Management Committee section here http://www.apache.org/foundation/how-it-works.html#structure -- Dan Diephouse (616) 971-2053 Envoi Solutions LLC http://netzooid.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMCs [was Re: what are required for contributing to release management]
+1 to Dan's opinion. --steve On Oct 1, 2006, at 11:36 AM, Dan Diephouse wrote: Hi Jim, Jim Jagielski wrote: On Sep 30, 2006, at 11:51 AM, Jason van Zyl wrote: On 28 Sep 06, at 12:59 PM 28 Sep 06, Garrett Rooney wrote: Well, PMCs are formed by the board when a project moves to top level status. PPMCs are formed for an incubating project, and exactly how that works tends to differ a bit between projects. Some mentors start off with just the mentors on the PPMC, and then invite project members as time goes on (or that's the impression I've gotten). Others just start with the whole group of committers plus the mentors on the PPMC (that's what we did with Abdera). I think starting with the mentors is the wisest choice as at that point any committers can be brought aboard if deemed fit. So that can support both models as all committers can be brought aboard if it fits, or over time if more suitable. I was also confused about this as I heard one thing from Noel and one thing from Jim, but the mentors deciding seems sensible as projects can be dealt with on a case by case basis. I don't believe committers should automatically be made (P)PMC members as to me it's a different level of understanding and commitment. http://incubator.apache.org/guides/ppmc.html I assume you're referring to this sentence: Initially, it is composed of the Podling's mentors and initial committers. I have also found some threads which indicate that all committers should be added [1][2]. I want to know here - who is wrong? The documentation? Or the previous incubated projects who didn't add all the initial committers? There is also the following sentence which adds some doubt that the above is the official policy: The PPMC is directly responsible for the oversight of the podling and it also decides who to add as a PPMC member. While this could be referrering to post PPMC formation, it isn't clear. I will happily make a patch for the documentation to make things more clear if there is consensus. opinion I am pretty philosophically against making every committer PPMC members. Apache is meritocracy based and IMO it makes much more sense to start with the mentors on the PPMC and have committers voted on based on their leadership. There may be many people on the incubation proposal or who have committed code to a project in the past, but an additional level of leadership is needed [3]. Not everyone may have the necessary leadership skills, and to presuppose they do because they have contributed good code, is IMO, a mistake. /opinion Cheerz, - Dan 1. http://mail-archives.apache.org/mod_mbox/incubator-general/ 200312.mbox/[EMAIL PROTECTED] 2. http://mail-archives.apache.org/mod_mbox/incubator-general/ 200603.mbox/[EMAIL PROTECTED] 3. See Project Management Committee section here http:// www.apache.org/foundation/how-it-works.html#structure -- Dan Diephouse (616) 971-2053 Envoi Solutions LLC http://netzooid.com - 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: PPMCs [was Re: what are required for contributing to release management]
Jason van Zyl wrote: I think starting with the mentors is the wisest choice as at that point any committers can be brought aboard if deemed fit. My view of that should be quite clear by now. :-) I was also confused about this as I heard one thing from Noel and one thing from Jim Can you elaborate so that we can clarify and make sure that we have a consensus? the mentors deciding seems sensible as projects can be dealt with on a case by case basis. Agreed. The Mentors are PMC members. And the rest of the PMC can be as involved as any PMC member wants to be involved. I don't believe committers should automatically be made (P)PMC members as to me it's a different level of understanding and commitment. Yes, although there are benefits to making people PPMC members as soon as you feel that they can be trusted with confidentiality. After all, they do NOT gain binding votes in the PPMC, since those are exclusively held by PMC members. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMCs [was Re: what are required for contributing to release management]
On 10/1/06, Dan Diephouse [EMAIL PROTECTED] wrote: I am pretty philosophically against making every committer PPMC members. Apache is meritocracy based and IMO it makes much more sense to start with the mentors on the PPMC and have committers voted on based on their leadership. There may be many people on the incubation proposal or who have committed code to a project in the past, but an additional level of leadership is needed [3]. Not everyone may have the necessary leadership skills, and to presuppose they do because they have contributed good code, is IMO, a mistake. I don't agree at all. If they contribute code, they merit a say in the direction of the project. To do otherwise is to exclude them from the community. Remember that only folks on the PPMC have a vote: a committer does not have any say or vote in the project at all. The critical aim of the PPMC is to create a self-managing project. By excluding everyone from that process except for mentors, you will not be teaching the new people how the project should be managed. In the early days of the podlngs, the mentors should have proportionally more say in how things proceed; but in order to graduate to TLP status, the PPMC must be able to demonstrate the ability to manage itself - and probably the contributions from the mentors should be excluded from that determination - i.e. is the PPMC without the mentor able to govern itself. -- justin
RE: PPMCs [was Re: what are required for contributing to release management]
Dan Diephouse wrote: I assume you're referring to this sentence: Initially, it is composed of the Podling's mentors and initial committers. I have also found some threads which indicate that all committers should be added [1][2]. I want to know here - who is wrong? The documentation? Neither. Both. I'm probably the one who is quoted in that documentation. And the idea of the PPMC and Incubator oversight has evolved. Taken at face value, the sentence says that the PPMC is bootstrapped from the PMC members acting as Mentors and the initial people involved in the project. At the time, it probably made sense, since we had few problems with the initial commit lists. Then things started to change, with accusations both of piling on and exclusionary behavior. At the moment, there is a proposal being mooted to remove the list of initial committers from the proposal (there would be a list of interested participants), and have the whole thing bootstrapped by the Mentors after the PMC has voted to accept. The PPMC is directly responsible for the oversight of the podling and it also decides who to add as a PPMC member. That is correct. I am pretty philosophically against making every committer PPMC members. Personally, I agree, but there are benefits to biasing the process towards making people PPMC members in short course. I'd have a lower bar on that than on a PMC member, since only PMC members have binding votes, anyway. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: PPMCs [was Re: what are required for contributing to release management]
Justin Erenkrantz wrote: Dan Diephouse wrote: I am pretty philosophically against making every committer PPMC members. I don't agree at all. If they contribute code, they merit a say in the direction of the project. To do otherwise is to exclude them from the community. Remember that only folks on the PPMC have a vote: a committer does not have any say or vote in the project at all. Are you reading Dan's statement as independent or dependent upon time? I read it as an objection to mandated concurrency. Over time, your view should be the dominant one, as each Committer becomes a (P)PMC member. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMCs [was Re: what are required for contributing to release management]
On 10/1/06, Noel J. Bergman [EMAIL PROTECTED] wrote: I am pretty philosophically against making every committer PPMC members. I don't agree at all. If they contribute code, they merit a say in the direction of the project. To do otherwise is to exclude them from the community. Remember that only folks on the PPMC have a vote: a committer does not have any say or vote in the project at all. Are you reading Dan's statement as independent or dependent upon time? I read it as an objection to mandated concurrency. Over time, your view should be the dominant one, as each Committer becomes a (P)PMC member. My comment was in reply to the entirety of Dan's comment (which you snipped). But, as for the one line that you retained: I view Dan's perspective as being independent of time - that is, committers should never equal the PMC - I view that as extremely unhealthy. Placing qualities besides what they contribute as qualifications to PMC status is to miss the point - if you contribute to the project, you get a vote. -- justin
RE: PPMCs [was Re: what are required for contributing to release management]
Justin Erenkrantz wrote: Noel J. Bergman [EMAIL PROTECTED] wrote: I am pretty philosophically against making every committer PPMC members. I don't agree at all. If they contribute code, they merit a say in the direction of the project. Are you reading Dan's statement as independent or dependent upon time? I read it as an objection to mandated concurrency. Over time, your view should be the dominant one, as each Committer becomes a (P)PMC member. as for the one line that you retained: I view Dan's perspective as being independent of time - that is, committers should never equal the PMC - I view that as extremely unhealthy. If I had read it as you do, I would agree with you. I read it as suggestive of a process over time, and that at any snapshot in time, the body of Committers might not be entirely present in the PPMC. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMCs [was Re: what are required for contributing to release management]
Noel J. Bergman wrote: Justin Erenkrantz wrote: Noel J. Bergman [EMAIL PROTECTED] wrote: I am pretty philosophically against making every committer PPMC members. I don't agree at all. If they contribute code, they merit a say in the direction of the project. Are you reading Dan's statement as independent or dependent upon time? I read it as an objection to mandated concurrency. Over time, your view should be the dominant one, as each Committer becomes a (P)PMC member. as for the one line that you retained: I view Dan's perspective as being independent of time - that is, committers should never equal the PMC - I view that as extremely unhealthy. If I had read it as you do, I would agree with you. I read it as suggestive of a process over time, and that at any snapshot in time, the body of Committers might not be entirely present in the PPMC. I did in fact mean it as dependent on time. And specifically I meant at the beginning of incubation. I don't think every committer should be on the PPMC from the outset. Every committer may be on the PPMC at graduation, and this is encouraged, but only after they are explicitly voted on by the existing PPMC members. Now the PPMC may just chose to vote on specific individuals or everyone at once, its up to them. I would however encourage only voting people in after they an appropriate level of committment and involvement with the project. - Dan -- Dan Diephouse (616) 971-2053 Envoi Solutions LLC http://netzooid.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMCs [was Re: what are required for contributing to release management]
Dan Diephouse wrote: Noel J. Bergman wrote: Justin Erenkrantz wrote: Noel J. Bergman [EMAIL PROTECTED] wrote: I am pretty philosophically against making every committer PPMC members. I don't agree at all. If they contribute code, they merit a say in the direction of the project. Are you reading Dan's statement as independent or dependent upon time? I read it as an objection to mandated concurrency. Over time, your view should be the dominant one, as each Committer becomes a (P)PMC member. as for the one line that you retained: I view Dan's perspective as being independent of time - that is, committers should never equal the PMC - I view that as extremely unhealthy. If I had read it as you do, I would agree with you. I read it as suggestive of a process over time, and that at any snapshot in time, the body of Committers might not be entirely present in the PPMC. I did in fact mean it as dependent on time. And specifically I meant at the beginning of incubation. I don't think every committer should be on the PPMC from the outset. Every committer may be on the PPMC at graduation, and this is encouraged, but only after they are explicitly voted on by the existing PPMC members. Now the PPMC may just chose to vote on specific individuals or everyone at once, its up to them. I would however encourage only voting people in after they an appropriate level of committment and involvement with the project. One reason I feel this way is that I think protect's Apache's interests. Lets say that hypothetically, more people are put on a proposal than should be. If the PPMC members are elected after showing their committment to the long term health of the project, as opposed to all committers being added at the outset of the project, I believe this gives a better chance for correction. If I end up on the CXF (P)PMC I have every intention of starting a vote which removes any committers who have not contributed anything during incubation or significantly in the past. I hope I don't have to do that, but it doesn't seem fair that they would graduate as part of the project and have as much say as those who have shown their committment. If someone wants to get involved later, they can always contribute and get voted back in. I think this gives people a slightly lower barrier to get involved, which seems befitting to incubation and starting of a project, but also provides corrective measures in case there are problems. Cheers, - Dan -- Dan Diephouse (616) 971-2053 Envoi Solutions LLC http://netzooid.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMCs [was Re: what are required for contributing to release management]
On 10/1/06, Dan Diephouse [EMAIL PROTECTED] wrote: would however encourage only voting people in after they an appropriate level of committment and involvement with the project. This creates a dividing line by omitting past contributions from the discussion which I feel is inappropriate. For example, if I were to work on a project for many months at Google Code and then propose it to come here, why shouldn't I continue to have a say in what the project does? Why do I need to justify myself all over again? Why aren't my past contributions enough to merit a seat on the PPMC? What gives the mentors the power to 'reset' the community and block me from participating until I jump through their vague and ill-defined hoops? -- justin
Re: PPMCs [was Re: what are required for contributing to release management]
On 10/1/06, Justin Erenkrantz [EMAIL PROTECTED] wrote: For example, if I were to work on a project for many months at Google Code and then propose it to come here, why shouldn't I continue to have a say in what the project does? Why do I need to justify myself all over again? Why aren't my past contributions enough to merit a seat on the PPMC? What gives the mentors the power to 'reset' the community and block me from participating until I jump through their vague and ill-defined hoops? Personally, I think the bar on commit to incoming projects should be simple, if you've made a contribution (code, docs, whatever) that's significant enough that it would justify commit access here, you should get it. For projects that are coming from the open source world, that just means If you've got commit on it before it's at the ASF, you still do when it moves to the ASF, if it's corporate then obviously some due diligence needs to be done, but I think that's probably important in order to prevent the problem of providing a backdoor that avoids the whole meritocracy thing. Specifically though, I'd like to be clear that I don't think you should have to be an active participant in the project at the time it moves to the ASF in order to get commit/PPMC membership. As long as you're paying attention enough to sign the paperwork, the fact that you at one point qualified for this sort of access should be enough IMO. I know personally, when I have earned commit access to a project I expect that to still be there in the future, even if I fall off the planet for a while and don't have time to work on it. If the project had moved to the ASF in the meantime and all of a sudden I had to fight my way back to the same level of access I had in the past, I'd be pissed. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMCs [was Re: what are required for contributing to release management]
On 28 Sep 06, at 12:59 PM 28 Sep 06, Garrett Rooney wrote: Well, PMCs are formed by the board when a project moves to top level status. PPMCs are formed for an incubating project, and exactly how that works tends to differ a bit between projects. Some mentors start off with just the mentors on the PPMC, and then invite project members as time goes on (or that's the impression I've gotten). Others just start with the whole group of committers plus the mentors on the PPMC (that's what we did with Abdera). I think starting with the mentors is the wisest choice as at that point any committers can be brought aboard if deemed fit. So that can support both models as all committers can be brought aboard if it fits, or over time if more suitable. I was also confused about this as I heard one thing from Noel and one thing from Jim, but the mentors deciding seems sensible as projects can be dealt with on a case by case basis. I don't believe committers should automatically be made (P)PMC members as to me it's a different level of understanding and commitment. -garrett - 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]
PPMCs [was Re: what are required for contributing to release management]
robert burrell donkin wrote: thinking about whether there's a need to wait to release until the PPMC is fully formed and representation of the podling committers. PPMCs are typically filled up relatively late in the process - towards graduation. (whether this is a good idea, i'm not sure.) if there are just mentors on the PPMC then i see no benefit in waiting until the PPMC is composed of a representation cross-section of committers before creating a release. - robert Hiya, Pardon my ignorance here, but can you elaborate or point me to docs on how exactly the PMCs are formed? I know that the mentors from a project are on it, but as for the rest of the committers I have heard conflicting things. I have heard that you need to be voted on and I have also heard that the all of initial committers ends up on the PPMC. Obviously it can't be both and I can't find any real docs on it (http://incubator.apache.org/guides/ppmc.html is silent) either. Cheers, - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com http://netzooid.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMCs [was Re: what are required for contributing to release management]
On 9/28/06, Dan Diephouse [EMAIL PROTECTED] wrote: robert burrell donkin wrote: thinking about whether there's a need to wait to release until the PPMC is fully formed and representation of the podling committers. PPMCs are typically filled up relatively late in the process - towards graduation. (whether this is a good idea, i'm not sure.) if there are just mentors on the PPMC then i see no benefit in waiting until the PPMC is composed of a representation cross-section of committers before creating a release. - robert Hiya, Pardon my ignorance here, but can you elaborate or point me to docs on how exactly the PMCs are formed? I know that the mentors from a project are on it, but as for the rest of the committers I have heard conflicting things. I have heard that you need to be voted on and I have also heard that the all of initial committers ends up on the PPMC. Obviously it can't be both and I can't find any real docs on it (http://incubator.apache.org/guides/ppmc.html is silent) either. Well, PMCs are formed by the board when a project moves to top level status. PPMCs are formed for an incubating project, and exactly how that works tends to differ a bit between projects. Some mentors start off with just the mentors on the PPMC, and then invite project members as time goes on (or that's the impression I've gotten). Others just start with the whole group of committers plus the mentors on the PPMC (that's what we did with Abdera). -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMCs [was Re: what are required for contributing to release management]
Garrett Rooney wrote: On 9/28/06, Dan Diephouse [EMAIL PROTECTED] wrote: robert burrell donkin wrote: thinking about whether there's a need to wait to release until the PPMC is fully formed and representation of the podling committers. PPMCs are typically filled up relatively late in the process - towards graduation. (whether this is a good idea, i'm not sure.) if there are just mentors on the PPMC then i see no benefit in waiting until the PPMC is composed of a representation cross-section of committers before creating a release. - robert Hiya, Pardon my ignorance here, but can you elaborate or point me to docs on how exactly the PMCs are formed? I know that the mentors from a project are on it, but as for the rest of the committers I have heard conflicting things. I have heard that you need to be voted on and I have also heard that the all of initial committers ends up on the PPMC. Obviously it can't be both and I can't find any real docs on it (http://incubator.apache.org/guides/ppmc.html is silent) either. Well, PMCs are formed by the board when a project moves to top level status. Sorry for the confusion - I meant to say PPMC, not PMC in my message. PPMCs are formed for an incubating project, and exactly how that works tends to differ a bit between projects. Some mentors start off with just the mentors on the PPMC, and then invite project members as time goes on (or that's the impression I've gotten). Others just start with the whole group of committers plus the mentors on the PPMC (that's what we did with Abdera). Well that explains my utter confusion. Thanks for the clarification. So this is up to the mentors to decide then? - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com http://netzooid.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMCs [was Re: what are required for contributing to release management]
On 9/28/06, Dan Diephouse [EMAIL PROTECTED] wrote: Garrett Rooney wrote: snip PPMCs are formed for an incubating project, and exactly how that works tends to differ a bit between projects. Some mentors start off with just the mentors on the PPMC, and then invite project members as time goes on (or that's the impression I've gotten). Others just start with the whole group of committers plus the mentors on the PPMC (that's what we did with Abdera). Well that explains my utter confusion. Thanks for the clarification. So this is up to the mentors to decide then? i think so (hopefully someone will jump in with a correction if i have this wrong) it would probably be a good idea to record any election as a VOTE of the mentors on the private list - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMCs [was Re: what are required for contributing to release management]
On 9/28/06, robert burrell donkin [EMAIL PROTECTED] wrote: On 9/28/06, Dan Diephouse [EMAIL PROTECTED] wrote: Garrett Rooney wrote: snip PPMCs are formed for an incubating project, and exactly how that works tends to differ a bit between projects. Some mentors start off with just the mentors on the PPMC, and then invite project members as time goes on (or that's the impression I've gotten). Others just start with the whole group of committers plus the mentors on the PPMC (that's what we did with Abdera). Well that explains my utter confusion. Thanks for the clarification. So this is up to the mentors to decide then? i think so (hopefully someone will jump in with a correction if i have this wrong) it would probably be a good idea to record any election as a VOTE of the mentors on the private list Makes sense to me. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
