Great points and feedback. I think everyone here wants the best for the project. We should definitely not shoot down pioneering contributions and be more inclusive with people that are actively contributing to the community with not just code. This should include code, documentation, website changes and other tasks like organizing a meetup or doing project management like helping us plan, organize tasks and milestones. The latter non-code contributions are hard work and should be recognized.
I would propose the two following action points: * Resetting the list of committers to people that have contributed in the previous terms in the latest 6 months * Suspend veto rights temporarily and use simple majority for decisions that need a vote so we realign the project with the communities best interests. As other people with extensive open source and community experience have pointed out, we should be more inclusive rather than exclusive. Which includes stop abusing veto and other 'powers' to block contributions or committer proposals, this short sighted behaviour is doing more harm than good to the project. Going forward I think we should raise the engineering standards bar in code contributions, meaning code should be: * Well designed * Reviewed * Documented * Have a reasonable degree of test coverage and be free of bugs in good faith. MXNet users and contributors are not beta testers and shouldn't have the time and financial burden of fixing hard to debug bugs in code that is not well tested. Pedro. On Fri, Jun 15, 2018 at 6:59 PM Tianqi Chen <tqc...@cs.washington.edu> wrote: > 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 > > > > > >
