Re: The podling initial committers issue
In DeltaSpike and a few other projects I was involved we treated it the following way. Our initial set of committers consisted of people who either contributed to the original (non-ASF) projects in this area or who are known ASF committers where we did know we could trust in. Additionally to this hurdle, when we graduated we also dropped all committers who have been listed in the incubator proposal but did not actively contribute during incubation. Sometimes we even dropped good folks who we know that they are really great hackers and OSS guys but did not have enough spare time to contribute to the very project. LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: general@incubator.apache.org general@incubator.apache.org Cc: Sent: Friday, 27 September 2013, 13:34 Subject: Re: The podling initial committers issue I think that all of this might boil down to the observation, way back in this thread, that there are different patterns of incoming projects. Some incoming podlings are very small groups of people. If they are paying attention, they know that attracting new people will be their biggest problem. Interested, enthusiastic, existing Apache committers/PMC members/foundation members are exactly what they want. They aren't a community yet, and starting out with a batch of people who have some idea how to run one is just fine. Other incoming podlings have an existing community. They are willing to work to adapt that community to Apache norms. We may not have observed them in their past, but it's reasonable to respect them to the extent of allowing them to set up shop as themselves and then bring in others via the usual process. Open Office was a special and unusual case on just about every dimension, so I don't think that it's necessary for every mental schema to perfectly fit that history. It seems to me that the cooler voices here, including particularly Bertrand, see this whole incident as an unfortunate misunderstanding over this distinction, and a tiny bit of policy clarification will fix it, with no further need for rhetoric. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: The podling initial committers issue
On Fri, Sep 27, 2013 at 6:29 PM, Marvin Humphrey mar...@rectangular.comwrote: On Fri, Sep 27, 2013 at 12:33 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: Perhaps the initial committers list should be split into two: - interested developers - initial committers This way a podling can engage with the interested developers and quickly form an (expanded) community. IMO when an existing project comes in, the initial committers list should consist of the original committers. Anyone interested should be added to interested developers. Empty, new proposals can either start with a list of initial committers or with a list of interested developers who get voted in by the mentors as they engage in a community on dev@. Existing projects can add new interested developers to either list, depending on what their preference is. I'd expect Apache committers with no prior stake in the project to explicitly ask to be listed as merely an interested developer and earn their merit through contribution rather than moving directly to committership. +1 Adding an Interested Developers section is an improvement over the patch to the proposal template suggested at the top of the thread because it gives newcomers a way to express interest and the proposed podling a way to say Thanks! I've added you... instead of Thanks but The new section should contain a note guiding interested parties to send email to general@incubator asking to be added. Martijn's suggestion preserves the best aspects of open enrollment while appropriately delaying delicate discussions about meritocracy and openness until incubation is underway. Well put ... I think this is the solution in the process that will prevent these kinds of misunderstandings in the future. -- Best Regards, -- Alex
Re: The podling initial committers issue
On Wed, Sep 25, 2013 at 7:53 PM, Jim Jagielski j...@jagunet.com wrote: Plus, since the ASF did not watch how Usergrid was handled when it was external, we (the ASF) has no idea how meritocratic it was... I have no idea how that is important for *entering* the incubator. One of the core tenets of incubating is to become a meritocratic community. By allowing jan en alleman [1] to join the project on the outset without having any previous stake is not meritocratic, nor Apache like, even if they are founders of the foundation. Incoming *existing* communities need to be mentored into becoming Apache communities, not being hammered into them when they are doing their babysteps. in fact, and I'm sorry to say this, the viciousness of all this leads me to wonder just what counted as merit. Yes, what does count as merit? Having done nothing for a project that has existed for 2 years, just stating I want to get in and expecting to be a full fledged committer? Is that the merit Apache values? Does merit not exist because we were not there to observe it? Did the tree not fall because we did not watch it falling? Just because merit was earned outside the foundation should not invalidate it. This was and still is one of my main gripes with the incubator when we brought Wicket to the foundation. This whole thing started because I made the mistake of assuming, as Champion, that the Usergrid community was more open to taking advantage of the proposal phase to ramp up additional interested developers and leverage their interest, energy and talents. Those additional interested developers can and should join the dev@ list as soon as it is created. They can already engage the current community and work their way up in the ranks. There is no need to get a commit bit at the outset to show and learn the incoming community all about meritocracy. Perhaps the initial committers list should be split into two: - interested developers - initial committers This way a podling can engage with the interested developers and quickly form an (expanded) community. IMO when an existing project comes in, the initial committers list should consist of the original committers. Anyone interested should be added to interested developers. Empty, new proposals can either start with a list of initial committers or with a list of interested developers who get voted in by the mentors as they engage in a community on dev@. Existing projects can add new interested developers to either list, depending on what their preference is. I'd expect Apache committers with no prior stake in the project to explicitly ask to be listed as merely an interested developer and earn their merit through contribution rather than moving directly to committership. Martijn [1] http://glosbe.com/nl/en/Jan%20en%20Alleman - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: The podling initial committers issue
On Sep 27, 2013, at 3:33 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: Incoming *existing* communities need to be mentored into becoming Apache communities, not being hammered into them when they are doing their babysteps. Who said or implied anything differently? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: The podling initial committers issue
I think that all of this might boil down to the observation, way back in this thread, that there are different patterns of incoming projects. Some incoming podlings are very small groups of people. If they are paying attention, they know that attracting new people will be their biggest problem. Interested, enthusiastic, existing Apache committers/PMC members/foundation members are exactly what they want. They aren't a community yet, and starting out with a batch of people who have some idea how to run one is just fine. Other incoming podlings have an existing community. They are willing to work to adapt that community to Apache norms. We may not have observed them in their past, but it's reasonable to respect them to the extent of allowing them to set up shop as themselves and then bring in others via the usual process. Open Office was a special and unusual case on just about every dimension, so I don't think that it's necessary for every mental schema to perfectly fit that history. It seems to me that the cooler voices here, including particularly Bertrand, see this whole incident as an unfortunate misunderstanding over this distinction, and a tiny bit of policy clarification will fix it, with no further need for rhetoric. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: The podling initial committers issue
On Fri, Sep 27, 2013 at 12:33 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: Perhaps the initial committers list should be split into two: - interested developers - initial committers This way a podling can engage with the interested developers and quickly form an (expanded) community. IMO when an existing project comes in, the initial committers list should consist of the original committers. Anyone interested should be added to interested developers. Empty, new proposals can either start with a list of initial committers or with a list of interested developers who get voted in by the mentors as they engage in a community on dev@. Existing projects can add new interested developers to either list, depending on what their preference is. I'd expect Apache committers with no prior stake in the project to explicitly ask to be listed as merely an interested developer and earn their merit through contribution rather than moving directly to committership. +1 Adding an Interested Developers section is an improvement over the patch to the proposal template suggested at the top of the thread because it gives newcomers a way to express interest and the proposed podling a way to say Thanks! I've added you... instead of Thanks but The new section should contain a note guiding interested parties to send email to general@incubator asking to be added. Martijn's suggestion preserves the best aspects of open enrollment while appropriately delaying delicate discussions about meritocracy and openness until incubation is underway. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: The podling initial committers issue
Hi, On Wed, Sep 25, 2013 at 8:58 PM, Craig L Russell craig.russ...@oracle.com wrote: When a proposal is just a candidate, there are two possible approaches (for those interested in committership) IMO once the possible approaches are documented, we should require incoming podlings to choose one and indicate which one in the incubation proposal. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
The podling initial committers issue
How do we go about changing the Incubator Proposal Guide so that the rules around adding new committers to a podling at proposal time? As much fun as a good email thread can be, we don't want to have to relive the same ones over and over. Can we come up with a consensus view and get it into the guide here? http://incubator.apache.org/guides/proposal.html#template-initial-committers Here's what I think we should add: After a proposal is submitted to the incubator but before a vote is called the proposing community may choose to add additional committers who ask to be committers or may chose to defer adding new committers until the podling is in the Incubator and can use the normal ways of ASF meritocracy, nominate new committers, etc. Do people agree with that text? What's the process for getting a change like this into the guide? Thanks, Dave
Re: The podling initial committers issue
On Sep 25, 2013, at 1:01 PM, Dave snoopd...@gmail.com wrote: Here's what I think we should add: After a proposal is submitted to the incubator but before a vote is called the proposing community may choose to add additional committers who ask to be committers or may chose to defer adding new committers until the podling is in the Incubator and can use the normal ways of ASF meritocracy, nominate new committers, etc. Do people agree with that text? The normal ways stuff needs to be word-smithed. It's an obvious slam against the way 90-95% of how other proposals have been done and implies that somehow that's wrong. If you delete everything after is in the Incubator... then it's a little less biased or leading. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: The podling initial committers issue
On Wed, Sep 25, 2013 at 1:24 PM, Jim Jagielski j...@apache.org wrote: On Sep 25, 2013, at 1:01 PM, Dave snoopd...@gmail.com wrote: Here's what I think we should add: After a proposal is submitted to the incubator but before a vote is called the proposing community may choose to add additional committers who ask to be committers or may chose to defer adding new committers until the podling is in the Incubator and can use the normal ways of ASF meritocracy, nominate new committers, etc. Do people agree with that text? The normal ways stuff needs to be word-smithed. It's an obvious slam against the way 90-95% of how other proposals have been done and implies that somehow that's wrong. If you delete everything after is in the Incubator... then it's a little less biased or leading. That's a very good suggestion. - Dave
Re: The podling initial committers issue
On Wed, Sep 25, 2013 at 11:24 PM, Jim Jagielski j...@apache.org wrote: On Sep 25, 2013, at 1:01 PM, Dave snoopd...@gmail.com wrote: Here's what I think we should add: After a proposal is submitted to the incubator but before a vote is called the proposing community may choose to add additional committers who ask to be committers or may chose to defer adding new committers until the podling is in the Incubator and can use the normal ways of ASF meritocracy, nominate new committers, etc. Do people agree with that text? The normal ways stuff needs to be word-smithed. It's an obvious slam against the way 90-95% of how other proposals have been done and implies that somehow that's wrong. There's no slam against podlings that have gone through an Incubator process that was less meritocratic. This is not a failure of podlings exposed to that process. It's just something we can make better, and more consistent with our standard meritocratic policies for PMCs. If you delete everything after is in the Incubator... then it's a little less biased or leading. I don't find this biased or leading. It's a genuine reference to mirror policies that are the norm for PMCs. Alex
Re: The podling initial committers issue
Alex, you are constantly mixing up expectations of PMCs and podlings. Plus, since the ASF did not watch how Usergrid was handled when it was external, we (the ASF) has no idea how meritocratic it was... in fact, and I'm sorry to say this, the viciousness of all this leads me to wonder just what counted as merit. Your definition of what is better does not align with everyones, nor does it align with the experience of other successful podlings. As you state, what works for podling A may nor work for podling B (or be better for B), and we should not force or coerce or strongly imply one or the other. I suggested changing Dave's addition to make it unbiased one way or another. This whole thing started because I made the mistake of assuming, as Champion, that the Usergrid community was more open to taking advantage of the proposal phase to ramp up additional interested developers and leverage their interest, energy and talents. On Sep 25, 2013, at 1:34 PM, Alex Karasulu akaras...@apache.org wrote: On Wed, Sep 25, 2013 at 11:24 PM, Jim Jagielski j...@apache.org wrote: On Sep 25, 2013, at 1:01 PM, Dave snoopd...@gmail.com wrote: Here's what I think we should add: After a proposal is submitted to the incubator but before a vote is called the proposing community may choose to add additional committers who ask to be committers or may chose to defer adding new committers until the podling is in the Incubator and can use the normal ways of ASF meritocracy, nominate new committers, etc. Do people agree with that text? The normal ways stuff needs to be word-smithed. It's an obvious slam against the way 90-95% of how other proposals have been done and implies that somehow that's wrong. There's no slam against podlings that have gone through an Incubator process that was less meritocratic. This is not a failure of podlings exposed to that process. It's just something we can make better, and more consistent with our standard meritocratic policies for PMCs. If you delete everything after is in the Incubator... then it's a little less biased or leading. I don't find this biased or leading. It's a genuine reference to mirror policies that are the norm for PMCs. Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: The podling initial committers issue
I was under the impression that what you describe was the policy - if it is not then is should certainly be clarified. In the event that podlings continue to or are to be given such a choice, I believe that there needs to be a clear understanding between the incoming community and those volunteers that are shepherding them through the process as to what the choice is and some of the nuances that will be encountered in the execution. If there is no choice there then this consensus step is less necessary and the process can be more easily executed by the champion, mentors and incoming community. That shared understanding seems to be what was missing in this case. On Wed, Sep 25, 2013 at 1:06 PM, Dave snoopd...@gmail.com wrote: Or better yet, a change like that could be made to the Incubator Policy. http://incubator.apache.org/incubation/Incubation_Policy.html Thoughts? - Dave On Wed, Sep 25, 2013 at 1:01 PM, Dave snoopd...@gmail.com wrote: How do we go about changing the Incubator Proposal Guide so that the rules around adding new committers to a podling at proposal time? As much fun as a good email thread can be, we don't want to have to relive the same ones over and over. Can we come up with a consensus view and get it into the guide here? http://incubator.apache.org/guides/proposal.html#template-initial-committers Here's what I think we should add: After a proposal is submitted to the incubator but before a vote is called the proposing community may choose to add additional committers who ask to be committers or may chose to defer adding new committers until the podling is in the Incubator and can use the normal ways of ASF meritocracy, nominate new committers, etc. Do people agree with that text? What's the process for getting a change like this into the guide? Thanks, Dave
Re: The podling initial committers issue
Hi Dave, This topic actually did make it into the incubator guides but it's a bit hard to find it. From http://incubator.apache.org/guides/participation.html#committer: When a proposal is just a candidate, there are two possible approaches (for those interested in committership). The proposal typically contains a list of initial committers. When a podling is bootstrapped, this list is used by the mentors to set up initial accounts. So, one way to become a committer for a podling is to be listed on the proposal as an initial committer. The right way to express interest is by a post to the list with a brief introduction. Piling onto a proposal (by adding your own name as an initial committer) is impolite. Read this thread. A podling needs to learn how to recruit new committers from its developers. So, another way is to show up on the list and start helping with the development. This path will help the podling more than adding your name to the list of initial committers. So I think there is already consensus on the bad practice of piling on. And please note that I am not suggesting that anything like piling on has recently occurred here! So, if you would like to propose a patch that puts that information in other, possibly more easily found, places, go for it. Craig On Sep 25, 2013, at 10:01 AM, Dave wrote: How do we go about changing the Incubator Proposal Guide so that the rules around adding new committers to a podling at proposal time? As much fun as a good email thread can be, we don't want to have to relive the same ones over and over. Can we come up with a consensus view and get it into the guide here? http://incubator.apache.org/guides/proposal.html#template-initial-committers Here's what I think we should add: After a proposal is submitted to the incubator but before a vote is called the proposing community may choose to add additional committers who ask to be committers or may chose to defer adding new committers until the podling is in the Incubator and can use the normal ways of ASF meritocracy, nominate new committers, etc. Do people agree with that text? What's the process for getting a change like this into the guide? Thanks, Dave Craig L Russell Architect, Oracle http://db.apache.org/jdo 408 276-5638 mailto:craig.russ...@oracle.com P.S. A good JDO? O, Gasp! - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: The podling initial committers issue
I propose that this then be seen as a learning experience and determine what questions a champion needs to ask of the mentors and incoming community on the outset in order to execute. This has been an unfortunate bit of thrashing that was avoidable through communication. That is not to say that it is anyone's fault or anyone is right or wrong. We just need the champion/mentor survey questions established. On Wed, Sep 25, 2013 at 2:09 PM, Jim Jagielski j...@jagunet.com wrote: On Sep 25, 2013, at 1:33 PM, larry mccay larry.mc...@gmail.com wrote: That shared understanding seems to be what was missing in this case. Indeed that was the case, as I indicated in a previous post. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
