Re: [DISCUSS] Community diversity: current concerns and suggestions for improvement
On Nov 18, 2007 12:46 AM, Bertrand Delacretaz [EMAIL PROTECTED] wrote: ...Here's an attempt to summarize our recent discussions, and suggest some actions. Comments are welcome, of course Just want to note that I have not forgotten about these discussions, just didn't have time yet to summarize and act on the results. I think the next steps would be to come up with patches for our policy documentation, based on the consensus reached here, and vote on these patches. I hope to have time next week for this, but if someone wants to go ahead feel free to do that! -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Community diversity: current concerns and suggestions for improvement
On Nov 23, 2007, at 3:10 AM, ant elder wrote: Ask people to self nominate - I imagine often inactive commiters won't put themselves forward, removing any issue. Then maybe a review of the list by the the mentors and proposed PMC Chair. If there are issues it can be discussed in the community and if theres disagreement then vote. I imagine most of the time it won't come to voting. Niall That sounds reasonable but is it ok to do that? Its quite hard to remove a committer from a real Apache project, are incubating committers different and its ok to just ask who wants to be included at graduation? Just a data point, in Yoko here is consensus on the community that there is not enough interest to support Yoko as a TLP and that it is better placed as a sub-project as the code is used by other Apache projects. During the discussion it was asked who was interested in continuing on with the code base. Only a subset of the current committer base that is on record in SVN indicated that they were interested in continuing so there is at least one project that fits this model. I also think, as others have suggested, that this is not an exact science which is why we have mentors to provide the subjective input. I think we all trust the mentor's input on how a project is conducting itself. The Tuscany example of late is a good example where Paul Fremantle indicated he thought the project was doing well and was ready for graduation. Rather than simply relying on a set of external statistics (which can be useful at times) I very much trust those that have stepped up to mentor a project and give their opinion sufficient weight to help formulate a recommendation. My $.02 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Community diversity: current concerns and suggestions for improvement
On Nov 22, 2007 7:09 PM, Niall Pemberton [EMAIL PROTECTED] wrote: On Nov 20, 2007 9:14 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: I would agree with reviewing committers at graduation, but how do we implement that? I would say that this depends on the judgment of the mentors, and it is probably more important to evaluate the role they would be playing in the project once it is over to Apache, than what happened before entering incubation. Would you kick out people during graduation, if they don't show sufficient merit? I don't think you can make rules for that. Imho it's simple. The project has to prove it can behave the Apache way, and the project's members are responsible for this. People not functioning well in a project can be a reason to reject incubation, so the members better make sure that doesn't happen. Or re-elect all committers before graduation? That might be a good idea actually. Ask people to self nominate - I imagine often inactive commiters won't put themselves forward, removing any issue. Then maybe a review of the list by the the mentors and proposed PMC Chair. If there are issues it can be discussed in the community and if theres disagreement then vote. I imagine most of the time it won't come to voting. Niall That sounds reasonable but is it ok to do that? Its quite hard to remove a committer from a real Apache project, are incubating committers different and its ok to just ask who wants to be included at graduation? ...ant
Re: [DISCUSS] Community diversity: current concerns and suggestions for improvement
On Nov 23, 2007 9:10 AM, ant elder [EMAIL PROTECTED] wrote: On Nov 22, 2007 7:09 PM, Niall Pemberton [EMAIL PROTECTED] wrote: Ask people to self nominate That sounds reasonable but is it ok to do that? Its quite hard to remove a committer from a real Apache project, are incubating committers different and its ok to just ask who wants to be included at graduation? I think incubating committers are (or can be) different: someone might think that an incubating project sounds cool, and ask to join the list of initial committers, but then not find time to contribute. Or someone might be put on the list of committers as their company is incubating a project, but not get the way our projects work. I think it is fair to give such people a way out, if possible without having to use kick them out votes. Self-nomination, under the eyes of the mentors and of a community that is ready to graduate, is probably the best way, and it's easy to implement. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Community diversity: current concerns and suggestions for improvement
On Nov 20, 2007 9:14 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: I would agree with reviewing committers at graduation, but how do we implement that? I would say that this depends on the judgment of the mentors, and it is probably more important to evaluate the role they would be playing in the project once it is over to Apache, than what happened before entering incubation. Would you kick out people during graduation, if they don't show sufficient merit? I don't think you can make rules for that. Imho it's simple. The project has to prove it can behave the Apache way, and the project's members are responsible for this. People not functioning well in a project can be a reason to reject incubation, so the members better make sure that doesn't happen. Or re-elect all committers before graduation? That might be a good idea actually. Ask people to self nominate - I imagine often inactive commiters won't put themselves forward, removing any issue. Then maybe a review of the list by the the mentors and proposed PMC Chair. If there are issues it can be discussed in the community and if theres disagreement then vote. I imagine most of the time it won't come to voting. Niall Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Community diversity: current concerns and suggestions for improvement
Ask people to self nominate - I imagine often inactive commiters won't put themselves forward, removing any issue. Then maybe a review of the list by the the mentors and proposed PMC Chair. If there are issues it can be discussed in the community and if theres disagreement then vote. I imagine most of the time it won't come to voting. Yeah, that sounds like a very good idea. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Community diversity: current concerns and suggestions for improvement
Btw would people have interest in a small script that would analyze a given project history and give stats on commits and who committed? I've built something similar for infra [1] and such reports could be useful to the IPMC when a podling starts talking about graduation. I'm not sure how far we want to push the policing side of it though. Matthieu While I like the idea of this script for my own pleasure, I'm not sure that it encourages the right view of the incubator or any Apache project, so I would not personally like to see those kind of statistics used as part of graduation. Let me give an example. I am a keen participant in Apache Synapse. But I know if you ran your script, I would come out as a low-level committer. But I honestly don't think that would be a fair representation of my participation, commitment, or willingness to devote more time if needed. Paul
Re: [DISCUSS] Community diversity: current concerns and suggestions for improvement
On Nov 22, 2007 8:09 PM, Niall Pemberton [EMAIL PROTECTED] wrote: ...Or re-elect all committers before graduation?... ...Ask people to self nominate... Good idea, that's probably the easiest way of addressing that concern. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Community diversity: current concerns and suggestions for improvement
On Nov 19, 2007 8:05 PM, Craig L Russell [EMAIL PROTECTED] wrote: ...Some of the discussion here to me seems to be backward: adding constraints to the entry of a podling to the incubator... Agreed, we shouldn't add more constraints than needed. ...A couple of additional comments below... On Nov 19, 2007, at 9:05 AM, Jukka Zitting wrote: ...IMHO we should allow everyone who is actively involved with the codebase to follow the code as a committer within the incubating project. I agree. How can we exclude folks who are already active on a project?... Totally agreed, we want to include the members of an existing community when a podling enters incubation. But currently we are not asking if these people are actually members of an existing community, that's a simple question that we could add: indicate what role this committer has had in the project before it entered incubation. It is currently too easy to add someone to the list of initial committers, you just need to put their email address, without any meritocracy filtering. And with our process, these people stay on the list when the project graduates (more about that below). I'm not saying we have any such committers at the moment, but our process does not prevent that scenario. ...So I have no issue with anyone becoming a committer on a podling, given that all of the podling committers are reviewed at graduation to make sure they've demonstrated their commitment to the project... I would agree with reviewing committers at graduation, but how do we implement that? Would you kick out people during graduation, if they don't show sufficient merit? Or re-elect all committers before graduation? -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Community diversity: current concerns and suggestions for improvement
I would agree with reviewing committers at graduation, but how do we implement that? I would say that this depends on the judgment of the mentors, and it is probably more important to evaluate the role they would be playing in the project once it is over to Apache, than what happened before entering incubation. Would you kick out people during graduation, if they don't show sufficient merit? I don't think you can make rules for that. Imho it's simple. The project has to prove it can behave the Apache way, and the project's members are responsible for this. People not functioning well in a project can be a reason to reject incubation, so the members better make sure that doesn't happen. Or re-elect all committers before graduation? That might be a good idea actually. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Community diversity: current concerns and suggestions for improvement
On Nov 18, 2007 12:45 PM, Martijn Dashorst [EMAIL PROTECTED] wrote: On Nov 18, 2007 12:46 AM, Bertrand Delacretaz [EMAIL PROTECTED] wrote: 3) Limit the number of new non-ASF initial committers for incubating projects... ...I think this throws a too wide a net. Wicket would not be an Apache project if we had to go through re-getting merit... You're right, and thanks for giving a concrete example (well, as I co-mentored it I should have thought about the Wicket case ;-) ... I think you should add: when the introduced community is not already open, meritocracy based and diverse... That could be an option...but, and also taking into account remarks made by others in this thread, that could lead to too complicated rules. Not sure if we want to go that route. ...I also think that the diversity should be discussed during the proposal period. If it is found to be an unbalanced community, the number of initial committers could be limited. But again, this is only a guideline. One of the goals of the incubator is to increase diversity, not stifle communities I like the idea: discuss initial diversity among the Incubator PMC, when a new project comes in, with the option of limiting the number of initial non-ASF committers. But no hard rules on that. This might be easier to implement than having hard rules for initial diversity. The problem is that such a discussion would be subjective, are people comfortable with that? I'd be ok with trying that for a given period, and re-evaluating later. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Community diversity: current concerns and suggestions for improvement
On 11/19/07, Bertrand Delacretaz [EMAIL PROTECTED] wrote: I like the idea: discuss initial diversity among the Incubator PMC, when a new project comes in, with the option of limiting the number of initial non-ASF committers. But no hard rules on that. This might be easier to implement than having hard rules for initial diversity. The problem is that such a discussion would be subjective, are people comfortable with that? I'd be ok with trying that for a given period, and re-evaluating later. I think we can throw the ball back into the court of the new podling: how are they going to address increasing the diversity of the community. As the IPMC we could state that the podling is not diverse and that we want a more balanced initial committers list before accepting the proposal. The podling should then decide how they are going to address the IPMC's concerns: - only mentors are on the PPMC and committers list, each committer has to gain merit - limit the number of committers from one organization to an acceptable number - something else I haven't come up with These rules are different for different incubating communities: when a proposal comes in with 3 developers from 1 organization, that is a different situation than a proposal with 15 developers and 10 coming in from one organization. The former could just state that they will strive to accept only new developers from other organizations in the first couple of months to increase the diversity. The latter could opt for only allowing 5 initial committers from the big organization (or any number that would make us feel less queazy). The biggest problem I see is that the organization that wants to donate the project will have a hard time letting go of control because they have a vested interest in the product. However that is exactly what they need to do when they move the project to Apache: they have to hand the project over to the community and need to learn to work with the community instead of regulate it. Of course this doesn't concern (immediately) already established open source projects that seek to join the foundation to strengthen their community. For example Roller, Wicket and JspWiki are established projects that moved (or are moving) to the foundation with their community intact, and I wouldn't have them in any other way. Martijn -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-rc1 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/
Re: [DISCUSS] Community diversity: current concerns and suggestions for improvement
Hi, On Nov 18, 2007 1:46 AM, Bertrand Delacretaz [EMAIL PROTECTED] wrote: 3) Limit the number of new non-ASF initial committers for incubating projects People who were not ASF committers but come in via a newly incubating project do not get their commit rights via the normal ASF meritocracy rules. I don't see how being an ASF committer would make you special as an initial committer of an incubating project? IMHO we should allow everyone who is actively involved with the codebase to follow the code as a committer within the incubating project. We could (or should) better define what that actively involved means (based on ASF-like merit rules) and police that definition so people won't use the incubator proposals as shortcuts for committership. Making existing ASF committership a part of that entry criteria (even as a special bonus) sounds wrong to me. BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Community diversity: current concerns and suggestions for improvement
Same here. I think a good way to address the short way to committership problem is to make sure people really committed consistently during the lifetime of the poddling when the project effectively graduates. There's something to say for that, though I think you should take activity on the mailing list and maybe other areas into account as well. Someone can be a very irregular committer, but still be very involved in other parts of the project such as supporting users and writing documentation on WIKIs etc. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Community diversity: current concerns and suggestions for improvement
On Nov 19, 2007 10:23 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: Same here. I think a good way to address the short way to committership problem is to make sure people really committed consistently during the lifetime of the poddling when the project effectively graduates. There's something to say for that, though I think you should take activity on the mailing list and maybe other areas into account as well. Someone can be a very irregular committer, but still be very involved in other parts of the project such as supporting users and writing documentation on WIKIs etc. Yep, definitely. Matthieu Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Community diversity: current concerns and suggestions for improvement
Hi, Some of the discussion here to me seems to be backward: adding constraints to the entry of a podling to the incubator. I'd hope that we could get podlings, including all of their current community, into the incubator and then actively mentor/monitor its activities to promote diversity and openness. It may be quite time- consuming, if possible at all, to try to analyze a proposed podling's alignment with Apache's values, especially if the only metrics we have are the proposed podling's committer list. During incubation, diversity and openness have to be evaluated to see if the community has achieved its goals prior to graduation. If the community was not diverse at entry, and has not attracted outside committers, then it doesn't graduate. These goals are well-defined in the incubation process. Bottom line, I'd rather see the focus on achieving diversity goals on the way to graduation, not on raising barriers to entry into incubation. A couple of additional comments below... On Nov 19, 2007, at 9:05 AM, Jukka Zitting wrote: Hi, On Nov 18, 2007 1:46 AM, Bertrand Delacretaz [EMAIL PROTECTED] wrote: 3) Limit the number of new non-ASF initial committers for incubating projects People who were not ASF committers but come in via a newly incubating project do not get their commit rights via the normal ASF meritocracy rules. I don't see how being an ASF committer would make you special as an initial committer of an incubating project? Right. Podlings' committer lists are independent of current Apache committer lists. IMHO we should allow everyone who is actively involved with the codebase to follow the code as a committer within the incubating project. I agree. How can we exclude folks who are already active on a project? We could (or should) better define what that actively involved means (based on ASF-like merit rules) and police that definition so people won't use the incubator proposals as shortcuts for committership. I don't have experience with people padding their resumes with Committer on Incubating Apache Podling and not doing anything productive on Podling. Is this really a concern? If anyone does due diligence via the podling mailing lists it should be obvious what the truth is. So I have no issue with anyone becoming a committer on a podling, given that all of the podling committers are reviewed at graduation to make sure they've demonstrated their commitment to the project. Making existing ASF committership a part of that entry criteria (even as a special bonus) sounds wrong to me. I agree. Craig BR, Jukka Zitting - 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: [DISCUSS] Community diversity: current concerns and suggestions for improvement
Craig L Russell wrote: Some of the discussion here to me seems to be backward: adding constraints to the entry of a podling to the incubator. I'd hope that we could get podlings, including all of their current community, into the incubator and then actively mentor/monitor its activities to promote diversity and openness. It may be quite time-consuming, if possible at all, to try to analyze a proposed podling's alignment with Apache's values, especially if the only metrics we have are the proposed podling's committer list. During incubation, diversity and openness have to be evaluated to see if the community has achieved its goals prior to graduation. If the community was not diverse at entry, and has not attracted outside committers, then it doesn't graduate. These goals are well-defined in the incubation process. Bottom line, I'd rather see the focus on achieving diversity goals on the way to graduation, not on raising barriers to entry into incubation. Craig, these were great points. The one thought it provokes is that clearly documenting what's needed in the line between *here* (entry to incubator) and *there* (graduating from incubator) will help potential podlings self-filter their eligibility for ASF incubation. If some of the simply stated graduation requirements are clear up-front, then they should have the common sense to realize they don't share those same goals and don't intend to fulfill them. At that point, we save ourselves evaluating inappropriate podlings. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Community diversity: current concerns and suggestions for improvement
On Nov 18, 2007 12:46 AM, Bertrand Delacretaz [EMAIL PROTECTED] wrote: 3) Limit the number of new non-ASF initial committers for incubating projects People who were not ASF committers but come in via a newly incubating project do not get their commit rights via the normal ASF meritocracy rules. I think this throws a too wide a net. Wicket would not be an Apache project if we had to go through re-getting merit. I think you should add: when the introduced community is not already open, meritocracy based and diverse. Going through mailinglists of the podling should give enough evidence that this is the case and would open the door for existing projects that are already established as an open *and* diverse community. No public mailinglists? no 'short cut'. I also think that the diversity should be discussed during the proposal period. If it is found to be an unbalanced community, the number of initial committers could be limited. But again, this is only a guideline. One of the goals of the incubator is to increase diversity, not stifle communities. Martijn -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-rc1 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/
Re: [DISCUSS] Community diversity: current concerns and suggestions for improvement
3) Limit the number of new non-ASF initial committers for incubating projects People who were not ASF committers but come in via a newly incubating project do not get their commit rights via the normal ASF meritocracy rules. We might want to limit the number of such commiters, to limit the number of people who get in via this shortcut. The downside of such a limitation, as someone mentioned in discussions, is that getting new committers in this way is also an opportunity to convert more people to the ASF way. If I think about Wicket, this limitation would have been a problem, since at the time Wicket started incubation, only one of the team members (of the 10+) was already involved an ASF committer. I'm not sure what benefits such a rule would have. True, you don't have much insight in how people of incubating projects got into the project before incubation, but on the other hand, it shouldn't really matter as the incubation is meant for coaching the project members into the ASF way, or at least validating that they can behave in the ASF way for the ASF projects concerned. I believe this should be viewed entirely independent of what they do or have done in outside projects. In other words, I believe ASF should only be concerned about how ASF projects are affected. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Community diversity: current concerns and suggestions for improvement
I'd like to echo Eelco's comments in their entirety replacing Wicket with Woden. And, I'd like to add that I think 3 would significantly limit the number of new projects entering the incubator. Lawrence Eelco Hillenius [EMAIL PROTECTED] 11/17/2007 08:43 PM Please respond to general@incubator.apache.org To general@incubator.apache.org cc Subject Re: [DISCUSS] Community diversity: current concerns and suggestions for improvement 3) Limit the number of new non-ASF initial committers for incubating projects People who were not ASF committers but come in via a newly incubating project do not get their commit rights via the normal ASF meritocracy rules. We might want to limit the number of such commiters, to limit the number of people who get in via this shortcut. The downside of such a limitation, as someone mentioned in discussions, is that getting new committers in this way is also an opportunity to convert more people to the ASF way. If I think about Wicket, this limitation would have been a problem, since at the time Wicket started incubation, only one of the team members (of the 10+) was already involved an ASF committer. I'm not sure what benefits such a rule would have. True, you don't have much insight in how people of incubating projects got into the project before incubation, but on the other hand, it shouldn't really matter as the incubation is meant for coaching the project members into the ASF way, or at least validating that they can behave in the ASF way for the ASF projects concerned. I believe this should be viewed entirely independent of what they do or have done in outside projects. In other words, I believe ASF should only be concerned about how ASF projects are affected. Eelco - 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]
