First of all, Apache allows each community to define its standard of comittership -- which I think is super valuable as different projects have different backgrounds and challenges. Having such flexibility instead of enforcing a global standard is one of the reasons why many Apache projects succeed. Here is my reasoning on the standard.
First of all, all contributions are valuable, and we evaluate them when considering committer nominations and evaluate them in an unbiased way. On the other hand, it is hard to create a standard of "equality" of contributions. Hen's suggestion of code being committed is a good proposal, but never-the-less biased against contributions that bring in drastically new design (we can call these type of contributors "pioneers"). The reason behind this is clear -- it is arguably true that contributions of new proposals are easier to bring in mistakes, and take a longer time to pass code reviews (thus costs more effort of fellow committers). "pioneers" get shot down more easily -- which is not what we want to see. Bring it to MXNet and the playground we are facing. We are on a super competitive field, with major tech giants in the play. All the players in the field are trying out drastically new ideas, and it is even more in our case to not have such bias. So it is indeed important to evaluate it on the basis of contribution, "quality" is just one word that we choose, and we put trust on the committers when evaluating them. While it is indeed hard to define such standard, we are trying our best to make fair evaluations. On Fri, Jun 15, 2018 at 12:00 AM, Hen <bay...@apache.org> wrote: > On the 'Becoming+a+Committer' guidelines, I dislike this phrase: > > "When it comes to code contributions, quality is more important than > quantity" > > There is only one 'quality' measurement, and that is "was the code merged". > If someone makes 10 different contributions and they were all horrible and > never merged (or the merger had to write a ton of fixes/tests/additions) > then yes, that's a pretty bad sign. > > If the code was merged; I don't care if it's stunning code or an inspired > design. It was merged. This isn't a technical promotion process, this is > about whether the individual has shown the commitment to be extended the > trust to manage commits. > > So; -1 to quality being more important than quantity. It's not. > > Hen > > > > On Fri, Jun 8, 2018 at 1:15 PM, Sheng Zha <szha....@gmail.com> wrote: > > > Hi, > > > > There have been a couple of offline inquiries from contributors about > > becoming a committer. From those inquiries, it seems that there’s > confusion > > in our community about how to become a committer, so I’d like to take > this > > opportunity to clarify. > > > > The guideline about becoming a committer can be found at > > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer. > > The > > gist of the guideline is that, like any other Apache project, MXNet > > committers are invited by existing committers based on merit. The > existing > > committers look for sustained, high quality contribution and community > > involvement among project contributors. When a candidate is spotted, this > > contributor will be nominated and voted among PMC members, and if all > goes > > well, this contributor will receive an invitation to join as a committer > > and PMC member. > > > > Note that such discussion and decision happens in private among existing > > PMC members and mentors through consensus, and information regarding what > > happened in this process will always remain private, so as to rid the > > influence of different interest groups. PMC members will not ask > > contributors for committer application, nor will they accept one. Except > > the aforementioned PMC members consensus process, any other process by > any > > organization under any circumstances will not be recognized. > > > > I hope that you find the above clarification helpful. If you have further > > question on this topic feel free to ask. > > > > Sheng > > >
