Re: Formalize Committer Proposal and Application Procedure
Chris, The document (template) was just a guide and not everything in it is necessary to make a good nomination. Just having links to accepted PRs and optionally pointers to any additional supporting material is all that is needed. We can simplify the template if that serves to make this easy. The general requirements are outlined in the wiki. Thanks Madan On Fri, Aug 11, 2017 at 11:20 AM, Chris Olivier wrote: > My $0.02: > > I think it's neat to have a nice doc with summaries and whatnot. > > That being said, I am not sure that I would want to do something different > from all of the other Apache projects. Apache has shown that their method > is successful. > > I worry in this case that the focus may, for some, become how pretty (or > even possibly misleading) the document is, rather than actually clicking > and inspecting the work done. I know that someone pointed out that it is > too tedious to click the links, but isn't the work what this is all about? > > Some people have great talents for writing these sorts of documents -- I > don't know that this means they are a good contributor or not. > > In addition, since this is a global initiative, some worthy contributors > may struggle with English... > > > > -Chris > > > On Fri, Aug 11, 2017 at 11:03 AM, Madan Jampani > wrote: > > > All, I captured the comments and general feedback that emerged from this > > discussion into a set of guidelines for when someone can become a > committer > > and what record of contributions they need to have to strengthen their > > case. It also has a link to a nomination template Tianqi created for a > > specific user (@eric-haibin-lin) as an example. > > > > Here is the wiki link: > > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer > > > > I'd request the members to review it and provide feedback so that we can > > settle on a set of formal guidelines. > > > > Madan. > > > > On Fri, Aug 11, 2017 at 5:43 AM, Isabel Drost-Fromm > > wrote: > > > > > On Thu, Aug 10, 2017 at 12:31:23PM -0700, Bhavin Thaker wrote: > > > > The criteria should look not only at Quantity but at the Quality of > > work > > > as > > > > well. > > > > > > Just as one additional data point: > > > > > > http://community.apache.org/newcommitter.html is the Apache Community > > > Development Project's guidelines. > > > > > > For other tasks than coding see also here: > > > http://community.apache.org/committers/#assisting-with- > > > project-management-and-marketing > > > > > > > > > https://community.apache.org/apache-way/apache-project- > > > maturity-model.html#community for more on > > > the maturity model's take on community. > > > > > > > > > One thing to keep in mind: All successful OSS projects I came across at > > > some > > > point had to deal with topics that were very far away from writing > actual > > > code. > > > In your committer guidelines you can make a conscious choice to > > explicitly > > > mention that those tasks will be rewarded as well - which in turn might > > > lead to > > > people who won't necessarily contribute code (either due to legal > > > constraints or > > > simply lack of interest or skills) to take these tasks up for you. > > > > > > I remember seeing discussions on whether to turn > non-coding-contributors > > > into > > > committers recently, but my search-foo has left me, I don't find the > > > thread in > > > question anymore :/ > > > > > > Isabel > > > > > > > > > > > > -- > > > Sorry for any typos: Mail was typed in vim, written in mutt, via ssh > > (most > > > likely involving some kind of mobile connection only.) > > > > > >
Re: Formalize Committer Proposal and Application Procedure
My $0.02: I think it's neat to have a nice doc with summaries and whatnot. That being said, I am not sure that I would want to do something different from all of the other Apache projects. Apache has shown that their method is successful. I worry in this case that the focus may, for some, become how pretty (or even possibly misleading) the document is, rather than actually clicking and inspecting the work done. I know that someone pointed out that it is too tedious to click the links, but isn't the work what this is all about? Some people have great talents for writing these sorts of documents -- I don't know that this means they are a good contributor or not. In addition, since this is a global initiative, some worthy contributors may struggle with English... -Chris On Fri, Aug 11, 2017 at 11:03 AM, Madan Jampani wrote: > All, I captured the comments and general feedback that emerged from this > discussion into a set of guidelines for when someone can become a committer > and what record of contributions they need to have to strengthen their > case. It also has a link to a nomination template Tianqi created for a > specific user (@eric-haibin-lin) as an example. > > Here is the wiki link: > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer > > I'd request the members to review it and provide feedback so that we can > settle on a set of formal guidelines. > > Madan. > > On Fri, Aug 11, 2017 at 5:43 AM, Isabel Drost-Fromm > wrote: > > > On Thu, Aug 10, 2017 at 12:31:23PM -0700, Bhavin Thaker wrote: > > > The criteria should look not only at Quantity but at the Quality of > work > > as > > > well. > > > > Just as one additional data point: > > > > http://community.apache.org/newcommitter.html is the Apache Community > > Development Project's guidelines. > > > > For other tasks than coding see also here: > > http://community.apache.org/committers/#assisting-with- > > project-management-and-marketing > > > > > > https://community.apache.org/apache-way/apache-project- > > maturity-model.html#community for more on > > the maturity model's take on community. > > > > > > One thing to keep in mind: All successful OSS projects I came across at > > some > > point had to deal with topics that were very far away from writing actual > > code. > > In your committer guidelines you can make a conscious choice to > explicitly > > mention that those tasks will be rewarded as well - which in turn might > > lead to > > people who won't necessarily contribute code (either due to legal > > constraints or > > simply lack of interest or skills) to take these tasks up for you. > > > > I remember seeing discussions on whether to turn non-coding-contributors > > into > > committers recently, but my search-foo has left me, I don't find the > > thread in > > question anymore :/ > > > > Isabel > > > > > > > > -- > > Sorry for any typos: Mail was typed in vim, written in mutt, via ssh > (most > > likely involving some kind of mobile connection only.) > > >
Re: Formalize Committer Proposal and Application Procedure
All, I captured the comments and general feedback that emerged from this discussion into a set of guidelines for when someone can become a committer and what record of contributions they need to have to strengthen their case. It also has a link to a nomination template Tianqi created for a specific user (@eric-haibin-lin) as an example. Here is the wiki link: https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer I'd request the members to review it and provide feedback so that we can settle on a set of formal guidelines. Madan. On Fri, Aug 11, 2017 at 5:43 AM, Isabel Drost-Fromm wrote: > On Thu, Aug 10, 2017 at 12:31:23PM -0700, Bhavin Thaker wrote: > > The criteria should look not only at Quantity but at the Quality of work > as > > well. > > Just as one additional data point: > > http://community.apache.org/newcommitter.html is the Apache Community > Development Project's guidelines. > > For other tasks than coding see also here: > http://community.apache.org/committers/#assisting-with- > project-management-and-marketing > > > https://community.apache.org/apache-way/apache-project- > maturity-model.html#community for more on > the maturity model's take on community. > > > One thing to keep in mind: All successful OSS projects I came across at > some > point had to deal with topics that were very far away from writing actual > code. > In your committer guidelines you can make a conscious choice to explicitly > mention that those tasks will be rewarded as well - which in turn might > lead to > people who won't necessarily contribute code (either due to legal > constraints or > simply lack of interest or skills) to take these tasks up for you. > > I remember seeing discussions on whether to turn non-coding-contributors > into > committers recently, but my search-foo has left me, I don't find the > thread in > question anymore :/ > > Isabel > > > > -- > Sorry for any typos: Mail was typed in vim, written in mutt, via ssh (most > likely involving some kind of mobile connection only.) >
Re: Formalize Committer Proposal and Application Procedure
On Thu, Aug 10, 2017 at 12:31:23PM -0700, Bhavin Thaker wrote: > The criteria should look not only at Quantity but at the Quality of work as > well. Just as one additional data point: http://community.apache.org/newcommitter.html is the Apache Community Development Project's guidelines. For other tasks than coding see also here: http://community.apache.org/committers/#assisting-with-project-management-and-marketing https://community.apache.org/apache-way/apache-project-maturity-model.html#community for more on the maturity model's take on community. One thing to keep in mind: All successful OSS projects I came across at some point had to deal with topics that were very far away from writing actual code. In your committer guidelines you can make a conscious choice to explicitly mention that those tasks will be rewarded as well - which in turn might lead to people who won't necessarily contribute code (either due to legal constraints or simply lack of interest or skills) to take these tasks up for you. I remember seeing discussions on whether to turn non-coding-contributors into committers recently, but my search-foo has left me, I don't find the thread in question anymore :/ Isabel -- Sorry for any typos: Mail was typed in vim, written in mutt, via ssh (most likely involving some kind of mobile connection only.)
Re: Formalize Committer Proposal and Application Procedure
I agree with Sebastian. The criteria should look not only at Quantity but at the Quality of work as well. This page for Apache committer criteria describes the criteria pretty well. https://hadoop.apache.org/committer_criteria.html - *A history of sustained contribution to the project. This is a way for a contributor to demonstrate their expertise in an area, and thus their ability to help review and commit contributions by others in that same area. Sustained contribution is also a way of demonstrating commitment to the project, essentially that someone will continue contributing even after they become a committer.* - *High-quality contributions. As experienced contributors, committers set an example for others in the project, and help inculcate a culture of high-quality contributions. For code contributions, this means clean, documented code which includes unit tests if appropriate and passes precommit checks. For reviews, this means thorough, actionable feedback, and a +1 vote (even non-binding) only when there is a high degree of confidence in the change.* - *Community involvement. Contributors are always expected to be polite, constructive, and respectful of others during community interactions. Disagreement can (and will) happen over technical issues, but the discussion should remain friendly and focused on technical merits. Committers also have the additional responsibility of mentoring newer contributors, as well as helping to grow the community through actions like responding to emails on the user and dev list.* I would add another point that the committer should have the backbone to say no to contributions that do NOT meet the high quality bar but yet mentor the contributor in reaching that high bar. This is difficult to quantify but is a quality that is expected to be demonstrated in various conversations of the person being nominated to be the committer. Bhavin Thaker. On Wed, Aug 9, 2017 at 11:03 PM, Sebastian wrote: > > Another thing might be that having too many committers makes it less >> valuable to >> become a committer and therefore discourage new people. >> > > In my experience, quite the opposite is true: Having many committers is > beneficial for a project and makes life easier for everybody. There's more > eyes to look at code contributions, more people answer questions and it > also makes it easier for other committers to take time outs from the > project (which might be necessary if they change jobs, have kids, etc) > > I think the important thing to look at is not the number of committers, > but the culture and processes in a project. > > Best, > Sebastian >
Re: Formalize Committer Proposal and Application Procedure
Another thing might be that having too many committers makes it less valuable to become a committer and therefore discourage new people. In my experience, quite the opposite is true: Having many committers is beneficial for a project and makes life easier for everybody. There's more eyes to look at code contributions, more people answer questions and it also makes it easier for other committers to take time outs from the project (which might be necessary if they change jobs, have kids, etc) I think the important thing to look at is not the number of committers, but the culture and processes in a project. Best, Sebastian
Re: Formalize Committer Proposal and Application Procedure
On Fri, Aug 4, 2017 at 1:04 PM, Isabel Drost-Fromm wrote: > On Fri, Aug 04, 2017 at 12:27:16PM +0100, Chiyuan Zhang wrote: > > Suppose we lower the standard or completely remove the formal standard > for > > committers, then we could probably be able to get more committers from > the > > first type. But that might not necessarily be good to us > > Can you elaborate your reasoning here? (I'm not implying that I agree or > disagree with you, I just want to understand where this fear is coming > from.) > > I think this depends on what committers could do (writing permission to the repo? voting in decisions for the direction of the projects? etc.). Another thing might be that having too many committers makes it less valuable to become a committer and therefore discourage new people. > > > having people that could either contribute relatively important > components > > or provide longer term commitment to the project. But on the other hand, > > having a standard for committers do not (I hope) discourage the first > type > > of contributors to contribute PRs. > > Let me tell you a little campfire story: Back in the old days of Mahout we > implicitly had a relatively high bar for becoming a committer. People > thought > that in order to become committer they would have to contribute substantial > patches, often full new algorithm implementations. > > What the project really needed were a lot of work polishing, optimising, > cleaning, making easier to use, documenting etc. > > Due to the perception of requiring substantial contributions to get the > reward of becoming committer however we never received much of the latter. > Yes, I totally agree that open source project survival really needs continuous contributions from the committee and many maintenance and polishing work. I would like to re-state that I support having a *clear* policy or guideline for becoming committers, not necessarily one with very high bar that requires substantial contributions. I think if we are able to control the guidelines to a reasonable level and easy to follow and get started, then this might even encourage new users to contribute. chiyuan > > > Lesson learnt for me: The way you setup your reward systems greatly > influences which kind of help your project will receive. > > > Isabel > > -- > Sorry for any typos: Mail was typed in vim, written in mutt, via ssh (most > likely involving some kind of mobile connection only.) >
Re: Formalize Committer Proposal and Application Procedure
We totally understand the apache way of doing things and the projects has always been welcoming users as contributors from days of DMLC. This happens in MXNet, as well as other project, for example XGBoost ( https://github.com/dmlc/xgboost) , another project that originated from DMLC have most of its committers recruited from user of the project(who contributed heavily). So we are all for being welcoming in terms of contributions, without lock-down access of the code. This is actually exactly the reason why we want to formalize this process. A new comitter should not be nominated because he/she simply knows more PMCs, or he/she is in the "inner circle" of the community. The nomination should be purely based on the contributions, supported by facts and statistics. Sometimes I get complains about from contributors who say why this person is get committer-ship while my contribution is more significant. Having a public standard makes this transparent and fair to all users who are contributing, and encourages them to hold up to the standard. Finally, the fact that such practice carries out in other successful Apache projects(e.g. Mesos) put weights in this as well. Tianqi On Tue, Aug 8, 2017 at 1:12 PM, Isabel Drost-Fromm wrote: > > > Am 4. August 2017 13:27:16 MESZ schrieb Chiyuan Zhang : > >1. There are some people who contribute to MXNet due to something else > >(e.g. he used MXNet in his project and would like to contribute back > >examples, or bug fix, or new operators, etc.) > > Many Apache projects are building software where end users are developers, > not unlike what happens at mxnet I suppose. > > Now from what I've seen a common pattern for successfully recruiting new > committers, growing and diversifying communities is a scratch your own itch > approach: I know of several ppl who came to an Apache project as mere > users, who started fixing things they needed fixed and who became > committers to projects before they knew what was happening to them. In my > experience those are the people who turned into project members who stayed > longer than anyone else, they had a vested interest in staying. Often over > time these people turned into Foundation members, helping out in various > ways, e.g. mentoring new projects entering through the incubator. > > From my experience, my advise would be to treat everyone on any of your > lists as potential committer. Instead of trying to protect the project from > evil by locking down access try to establish a project vision and > contributing guidelines that make it easy to get involved in the right way > - whatever that means for mxnet, community over code is core to how the > foundation works because at the end of the day your project lives and dies > with ppl being interested in spending time on it (or not). > > That shouldn't imply that it's not a good idea to write down how to become > a committer, you'll get that question often soon enough and will get tired > answering it ;) > > > Hope this helps, > Isabel > > > > -- > Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet. >
Re: Formalize Committer Proposal and Application Procedure
Am 4. August 2017 13:27:16 MESZ schrieb Chiyuan Zhang : >1. There are some people who contribute to MXNet due to something else >(e.g. he used MXNet in his project and would like to contribute back >examples, or bug fix, or new operators, etc.) Many Apache projects are building software where end users are developers, not unlike what happens at mxnet I suppose. Now from what I've seen a common pattern for successfully recruiting new committers, growing and diversifying communities is a scratch your own itch approach: I know of several ppl who came to an Apache project as mere users, who started fixing things they needed fixed and who became committers to projects before they knew what was happening to them. In my experience those are the people who turned into project members who stayed longer than anyone else, they had a vested interest in staying. Often over time these people turned into Foundation members, helping out in various ways, e.g. mentoring new projects entering through the incubator. From my experience, my advise would be to treat everyone on any of your lists as potential committer. Instead of trying to protect the project from evil by locking down access try to establish a project vision and contributing guidelines that make it easy to get involved in the right way - whatever that means for mxnet, community over code is core to how the foundation works because at the end of the day your project lives and dies with ppl being interested in spending time on it (or not). That shouldn't imply that it's not a good idea to write down how to become a committer, you'll get that question often soon enough and will get tired answering it ;) Hope this helps, Isabel -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Re: Formalize Committer Proposal and Application Procedure
> > Could you provide an example that provides a likely (imaginary if you'd > like) candidate? Mu's a pretty bad example for a new committer :) From the > attached doc I walk away thinking that I need to contribute for 2 years > before I can become a committer. For example, I think https://github.com/eric-haibin-lin meets this standard, given his recent contribution to the sparse modules of mxnet and his continuous effort on pushing this module. Tianqi
Re: Formalize Committer Proposal and Application Procedure
My experience from the existing open-source project we have is that the developers are willing to contribute back as long as the software they use are hold up to a standard. I do not meant to say that the contributions of the language, documentations and others do not count as contributions to the project, but substantial contributions of these (e.g. maintaining the documentation and tutorials for half a year and contributed materials) are needed to become comitter. Have a clear public standard will actually encourage people to hold up to that standard, and makes the comittership more valuable, thus providing incentives for developers who are interested to put good effort into it. Tianqi On Fri, Aug 4, 2017 at 5:04 AM, Isabel Drost-Fromm wrote: > On Fri, Aug 04, 2017 at 12:27:16PM +0100, Chiyuan Zhang wrote: > > Suppose we lower the standard or completely remove the formal standard > for > > committers, then we could probably be able to get more committers from > the > > first type. But that might not necessarily be good to us > > Can you elaborate your reasoning here? (I'm not implying that I agree or > disagree with you, I just want to understand where this fear is coming > from.) > > > > having people that could either contribute relatively important > components > > or provide longer term commitment to the project. But on the other hand, > > having a standard for committers do not (I hope) discourage the first > type > > of contributors to contribute PRs. > > Let me tell you a little campfire story: Back in the old days of Mahout we > implicitly had a relatively high bar for becoming a committer. People > thought > that in order to become committer they would have to contribute substantial > patches, often full new algorithm implementations. > > What the project really needed were a lot of work polishing, optimising, > cleaning, making easier to use, documenting etc. > > Due to the perception of requiring substantial contributions to get the > reward of becoming committer however we never received much of the latter. > > > Lesson learnt for me: The way you setup your reward systems greatly > influences which kind of help your project will receive. > > > Isabel > > -- > Sorry for any typos: Mail was typed in vim, written in mutt, via ssh (most > likely involving some kind of mobile connection only.) >
Re: Formalize Committer Proposal and Application Procedure
FYI here is the comitter checklist from Apache Mesos http://mesos.apache.org/documentation/latest/committer-candidate-checklist/ which I mainly adopted from Tianqi On Fri, Aug 4, 2017 at 8:14 AM, Madan Jampani wrote: > There is a middle ground here. Instead of saying someone either has full > committer privileges or zero, an alternative is to have scope of ownership > start small and localized to modules or source folders where their primary > contributions currently lie. For example, there are folks who contributed > full languages bindings, or very good examples/tutorials. > > Over time, depending on the scope and complexity of their contributions > they can be nominated to have their commit privileges broadened or even > become core committers. Core committers have full commit privileges. > > Irrespective of whether some one is committer or not, we should all be > using the PR process and opening up contributions for review/feedback. > > Madan > > > > On Fri, Aug 4, 2017 at 5:04 AM, Isabel Drost-Fromm > wrote: > > > On Fri, Aug 04, 2017 at 12:27:16PM +0100, Chiyuan Zhang wrote: > > > Suppose we lower the standard or completely remove the formal standard > > for > > > committers, then we could probably be able to get more committers from > > the > > > first type. But that might not necessarily be good to us > > > > Can you elaborate your reasoning here? (I'm not implying that I agree or > > disagree with you, I just want to understand where this fear is coming > > from.) > > > > > > > having people that could either contribute relatively important > > components > > > or provide longer term commitment to the project. But on the other > hand, > > > having a standard for committers do not (I hope) discourage the first > > type > > > of contributors to contribute PRs. > > > > Let me tell you a little campfire story: Back in the old days of Mahout > we > > implicitly had a relatively high bar for becoming a committer. People > > thought > > that in order to become committer they would have to contribute > substantial > > patches, often full new algorithm implementations. > > > > What the project really needed were a lot of work polishing, optimising, > > cleaning, making easier to use, documenting etc. > > > > Due to the perception of requiring substantial contributions to get the > > reward of becoming committer however we never received much of the > latter. > > > > > > Lesson learnt for me: The way you setup your reward systems greatly > > influences which kind of help your project will receive. > > > > > > Isabel > > > > -- > > Sorry for any typos: Mail was typed in vim, written in mutt, via ssh > (most > > likely involving some kind of mobile connection only.) > > >
Re: Formalize Committer Proposal and Application Procedure
There is a middle ground here. Instead of saying someone either has full committer privileges or zero, an alternative is to have scope of ownership start small and localized to modules or source folders where their primary contributions currently lie. For example, there are folks who contributed full languages bindings, or very good examples/tutorials. Over time, depending on the scope and complexity of their contributions they can be nominated to have their commit privileges broadened or even become core committers. Core committers have full commit privileges. Irrespective of whether some one is committer or not, we should all be using the PR process and opening up contributions for review/feedback. Madan On Fri, Aug 4, 2017 at 5:04 AM, Isabel Drost-Fromm wrote: > On Fri, Aug 04, 2017 at 12:27:16PM +0100, Chiyuan Zhang wrote: > > Suppose we lower the standard or completely remove the formal standard > for > > committers, then we could probably be able to get more committers from > the > > first type. But that might not necessarily be good to us > > Can you elaborate your reasoning here? (I'm not implying that I agree or > disagree with you, I just want to understand where this fear is coming > from.) > > > > having people that could either contribute relatively important > components > > or provide longer term commitment to the project. But on the other hand, > > having a standard for committers do not (I hope) discourage the first > type > > of contributors to contribute PRs. > > Let me tell you a little campfire story: Back in the old days of Mahout we > implicitly had a relatively high bar for becoming a committer. People > thought > that in order to become committer they would have to contribute substantial > patches, often full new algorithm implementations. > > What the project really needed were a lot of work polishing, optimising, > cleaning, making easier to use, documenting etc. > > Due to the perception of requiring substantial contributions to get the > reward of becoming committer however we never received much of the latter. > > > Lesson learnt for me: The way you setup your reward systems greatly > influences which kind of help your project will receive. > > > Isabel > > -- > Sorry for any typos: Mail was typed in vim, written in mutt, via ssh (most > likely involving some kind of mobile connection only.) >
Re: Formalize Committer Proposal and Application Procedure
There are trade-offs. On one side, a small group of "core" committers who understands the whole picture makes the project move swiftly and safely. On the other side, the reward of becoming committer is really important to encourage more contributors. I think Tianqi's proposal gives a good criterion of "core" committers. So I would like to see something like: (1) Easy to become a committer as a reward of your contribution. (2) Hard to be promoted as a "core" committer unless you're likely to contribute to the project for a longer-term. (Similar to Blizzard's game concept: "easy to learn and difficult to master" :) ) Anyhow, I am not sure Apache's management allows this or not. From my bare understanding, it seems to be quite flat and committer is the only viable title? Or could we make this an implicit rule? On Fri, Aug 4, 2017 at 8:04 AM, Isabel Drost-Fromm wrote: > On Fri, Aug 04, 2017 at 12:27:16PM +0100, Chiyuan Zhang wrote: > > Suppose we lower the standard or completely remove the formal standard > for > > committers, then we could probably be able to get more committers from > the > > first type. But that might not necessarily be good to us > > Can you elaborate your reasoning here? (I'm not implying that I agree or > disagree with you, I just want to understand where this fear is coming > from.) > > > > having people that could either contribute relatively important > components > > or provide longer term commitment to the project. But on the other hand, > > having a standard for committers do not (I hope) discourage the first > type > > of contributors to contribute PRs. > > Let me tell you a little campfire story: Back in the old days of Mahout we > implicitly had a relatively high bar for becoming a committer. People > thought > that in order to become committer they would have to contribute substantial > patches, often full new algorithm implementations. > > What the project really needed were a lot of work polishing, optimising, > cleaning, making easier to use, documenting etc. > > Due to the perception of requiring substantial contributions to get the > reward of becoming committer however we never received much of the latter. > > > Lesson learnt for me: The way you setup your reward systems greatly > influences which kind of help your project will receive. > > > Isabel > > -- > Sorry for any typos: Mail was typed in vim, written in mutt, via ssh (most > likely involving some kind of mobile connection only.) > -- Minjie Wang *New York University | Computer Science* 715 Broadway, New York, NY, 10009
Re: Formalize Committer Proposal and Application Procedure
On Fri, Aug 04, 2017 at 12:27:16PM +0100, Chiyuan Zhang wrote: > Suppose we lower the standard or completely remove the formal standard for > committers, then we could probably be able to get more committers from the > first type. But that might not necessarily be good to us Can you elaborate your reasoning here? (I'm not implying that I agree or disagree with you, I just want to understand where this fear is coming from.) > having people that could either contribute relatively important components > or provide longer term commitment to the project. But on the other hand, > having a standard for committers do not (I hope) discourage the first type > of contributors to contribute PRs. Let me tell you a little campfire story: Back in the old days of Mahout we implicitly had a relatively high bar for becoming a committer. People thought that in order to become committer they would have to contribute substantial patches, often full new algorithm implementations. What the project really needed were a lot of work polishing, optimising, cleaning, making easier to use, documenting etc. Due to the perception of requiring substantial contributions to get the reward of becoming committer however we never received much of the latter. Lesson learnt for me: The way you setup your reward systems greatly influences which kind of help your project will receive. Isabel -- Sorry for any typos: Mail was typed in vim, written in mutt, via ssh (most likely involving some kind of mobile connection only.)
Re: Formalize Committer Proposal and Application Procedure
Hi all, just want to share my bits. I like the idea of formalizing the committer proposal mechanism. The actual standard for what count as good enough for a committer could be discussed. I think the worrying of not being able to recruit new committers might not be a serious problem. I am thinking about two types of people here 1. There are some people who contribute to MXNet due to something else (e.g. he used MXNet in his project and would like to contribute back examples, or bug fix, or new operators, etc.) 2. There are some people who is interested in MXNet development and would like to work on it for a relatively long term (maintaining or developing) or would like to work on a relatively major component. My point is that for the first type of contributors, we might not need to propose everyone of them as Apache committers (if I understand correctly, everyone can submit a PR, even without committer permission, right?). On the other hand, the second type of contributors are our main target for committers, and I think for those people, having a more clear standard (again the actual standard could be debatable) for committer would not be a huge barrier. Suppose we lower the standard or completely remove the formal standard for committers, then we could probably be able to get more committers from the first type. But that might not necessarily be good to us --- in terms of having people that could either contribute relatively important components or provide longer term commitment to the project. But on the other hand, having a standard for committers do not (I hope) discourage the first type of contributors to contribute PRs. Best, Chiyuan On Fri, Aug 4, 2017 at 8:42 AM, Henri Yandell wrote: > I worry that it creates a high barrier to entry. > > It's a far more common pattern for a project to do poorly at recruiting new > committers, than it is for one to recruit too many. > > Could you provide an example that provides a likely (imaginary if you'd > like) candidate? Mu's a pretty bad example for a new committer :) From the > attached doc I walk away thinking that I need to contribute for 2 years > before I can become a committer. > > Hen > > On Thu, Aug 3, 2017 at 9:49 AM, Ziheng Jiang wrote: > > > Forward my comment in private mail list: > > > > I agree that it would be nice to have some quantitative standards to > > evaluate the candidates. Let's encourage the future candidates do this. > > > > - Ziheng > > > > On Thu, Aug 3, 2017 at 09:44 Mu Li wrote: > > > > > It seems that this thread didn't show in the dev list. > > > > > > Totally agree that we should make the committer nomination more formal. > > > > > > -- Forwarded message -- > > > From: Tianqi Chen > > > Date: Wed, Aug 2, 2017 at 4:20 PM > > > Subject: Formalize Committer Proposal and Application Procedure > > > To: priv...@mxnet.incubator.apache.org > > > > > > > > > Hi Guys: > > > As I mentioned in another thread, I personally think the current > > > committer proposal and application process is too informal. > > > As MXNet grows larger and the community involves, I think it would > > be > > > very helpful to formalize the process and provide a clear standard for > > what > > > are we looking for in the comitter proposal process, and allow us to > > > evaluate based on the concrete evidence listed in the application to > > > promote the comitters. > > > This will setup a good standard for the contributors, as well as > > > provide solid material to back our decisions. After did some search, I > > > created this application template based on the committer application > from > > > Apache Mesos. I wrote it from the perspective of myself. > > > https://docs.google.com/document/d/1vKTgX1_EkAT7NSmaiBKBmbq > > > DuhF9kQd53BB4iUxGn4M/edit?usp=sharing > > > > > > I would recommend this to become the mandatory thing for the > future > > > committer nomination and voting, as well as the re-evaluation standard > of > > > current comitters when we graduate from the incubator project. > > > > > > Tianqi > > > > > -- > > Ziheng Jiang > > Fudan University | Computer Science > > >
Re: Formalize Committer Proposal and Application Procedure
On Fri, Aug 04, 2017 at 12:42:12AM -0700, Henri Yandell wrote: > I worry that it creates a high barrier to entry. +1 from my side to that worry. Isabel
Re: Formalize Committer Proposal and Application Procedure
I worry that it creates a high barrier to entry. It's a far more common pattern for a project to do poorly at recruiting new committers, than it is for one to recruit too many. Could you provide an example that provides a likely (imaginary if you'd like) candidate? Mu's a pretty bad example for a new committer :) From the attached doc I walk away thinking that I need to contribute for 2 years before I can become a committer. Hen On Thu, Aug 3, 2017 at 9:49 AM, Ziheng Jiang wrote: > Forward my comment in private mail list: > > I agree that it would be nice to have some quantitative standards to > evaluate the candidates. Let's encourage the future candidates do this. > > - Ziheng > > On Thu, Aug 3, 2017 at 09:44 Mu Li wrote: > > > It seems that this thread didn't show in the dev list. > > > > Totally agree that we should make the committer nomination more formal. > > > > -- Forwarded message ------ > > From: Tianqi Chen > > Date: Wed, Aug 2, 2017 at 4:20 PM > > Subject: Formalize Committer Proposal and Application Procedure > > To: priv...@mxnet.incubator.apache.org > > > > > > Hi Guys: > > As I mentioned in another thread, I personally think the current > > committer proposal and application process is too informal. > > As MXNet grows larger and the community involves, I think it would > be > > very helpful to formalize the process and provide a clear standard for > what > > are we looking for in the comitter proposal process, and allow us to > > evaluate based on the concrete evidence listed in the application to > > promote the comitters. > > This will setup a good standard for the contributors, as well as > > provide solid material to back our decisions. After did some search, I > > created this application template based on the committer application from > > Apache Mesos. I wrote it from the perspective of myself. > > https://docs.google.com/document/d/1vKTgX1_EkAT7NSmaiBKBmbq > > DuhF9kQd53BB4iUxGn4M/edit?usp=sharing > > > > I would recommend this to become the mandatory thing for the future > > committer nomination and voting, as well as the re-evaluation standard of > > current comitters when we graduate from the incubator project. > > > > Tianqi > > > -- > Ziheng Jiang > Fudan University | Computer Science >
Re: Formalize Committer Proposal and Application Procedure
Forward my comment in private mail list: I agree that it would be nice to have some quantitative standards to evaluate the candidates. Let's encourage the future candidates do this. - Ziheng On Thu, Aug 3, 2017 at 09:44 Mu Li wrote: > It seems that this thread didn't show in the dev list. > > Totally agree that we should make the committer nomination more formal. > > -- Forwarded message -- > From: Tianqi Chen > Date: Wed, Aug 2, 2017 at 4:20 PM > Subject: Formalize Committer Proposal and Application Procedure > To: priv...@mxnet.incubator.apache.org > > > Hi Guys: > As I mentioned in another thread, I personally think the current > committer proposal and application process is too informal. > As MXNet grows larger and the community involves, I think it would be > very helpful to formalize the process and provide a clear standard for what > are we looking for in the comitter proposal process, and allow us to > evaluate based on the concrete evidence listed in the application to > promote the comitters. > This will setup a good standard for the contributors, as well as > provide solid material to back our decisions. After did some search, I > created this application template based on the committer application from > Apache Mesos. I wrote it from the perspective of myself. > https://docs.google.com/document/d/1vKTgX1_EkAT7NSmaiBKBmbq > DuhF9kQd53BB4iUxGn4M/edit?usp=sharing > > I would recommend this to become the mandatory thing for the future > committer nomination and voting, as well as the re-evaluation standard of > current comitters when we graduate from the incubator project. > > Tianqi > -- Ziheng Jiang Fudan University | Computer Science
Fwd: Formalize Committer Proposal and Application Procedure
It seems that this thread didn't show in the dev list. Totally agree that we should make the committer nomination more formal. -- Forwarded message -- From: Tianqi Chen Date: Wed, Aug 2, 2017 at 4:20 PM Subject: Formalize Committer Proposal and Application Procedure To: priv...@mxnet.incubator.apache.org Hi Guys: As I mentioned in another thread, I personally think the current committer proposal and application process is too informal. As MXNet grows larger and the community involves, I think it would be very helpful to formalize the process and provide a clear standard for what are we looking for in the comitter proposal process, and allow us to evaluate based on the concrete evidence listed in the application to promote the comitters. This will setup a good standard for the contributors, as well as provide solid material to back our decisions. After did some search, I created this application template based on the committer application from Apache Mesos. I wrote it from the perspective of myself. https://docs.google.com/document/d/1vKTgX1_EkAT7NSmaiBKBmbq DuhF9kQd53BB4iUxGn4M/edit?usp=sharing I would recommend this to become the mandatory thing for the future committer nomination and voting, as well as the re-evaluation standard of current comitters when we graduate from the incubator project. Tianqi
