Totally agree, thanks for elaborating! Hen <bay...@apache.org> schrieb am Fr., 15. Juni 2018, 00:44:
> That wasn't what I was trying to say (I'll try again - tis late and I'm > sure I'm speaking poorly :) ). > > It says: > > "When it comes to code contributions, quality is more important than > quantity. While all contributions are welcome and highly appreciated, > certain guidelines will be applied when it comes to committer nominations, > e.g. clean, documented and maintainable code, including unit tests if > applicable. Updating license text or fixing indentation in hundreds of > source files for instance is case of quantity trumping quality. " > > If someone is updating licensing text, or fixing indentation, then that is > great. That's as good as someone who wrote a lump of clean, documented and > maintainable code with unit tests. The important part isn't the patch, it's > how much back and forth there had to be to get the patch to the point where > it could be merged. > > My concern, and I feel the language on the page reflects this, is that one > commit is rated higher than a different commit with regards to showing > commitment. That's wrong imo. All commits are equal (as are any other > actions for the project, such as answering a question, improving wiki, > maintaining CI, helping people on Slack). Becoming a committer is about the > trust built up by the committers not having to modify the action (PR, > proposed-answer, proposed-wiki-change etc). > > Hen > > On Fri, Jun 15, 2018 at 12:26 AM, Marco de Abreu < > marco.g.ab...@googlemail.com.invalid> wrote: > > > Hen, > > > > As you stated, it's of significance of how much a PR has to be changed > as a > > result of a review. I think this is what this project defines as quality. > > > > If people submit a bunch of PRs and we reviewers spend a lot of time on > > every single one of them to give the contributors advice about how to do > it > > the right way, then that's a great contribution but doesn't really show > > that the person is either up par with the standards of the project or > > understood the design principles. In both cases they added value to the > > project, but the bar would have been lowered if the reviewers didn't > > intercept. Of course, there is always something people will have to > > criticize as part of the review and that's natural. But what you are > > describing here is basically that we should make people committers > because > > of the amount of value they added through the code. > > > > While that's a good way to look at it in general, it doesn't consider > > important aspects: how much of this value has been added by the reviewer? > > And what happens if that person starts merging other PRs. If a person > who > > is not up par with the standards of the project is granted permission to > > merge pull requests and they merge them prematurely because they don't > know > > that things are wrong, then this is harming the project in the long term. > > If more and more people with lower standards are granted permissions, we > > will enter a downwards spiral. > > > > That's why I have to disagree that it's not about how often a PR has been > > merged but rather about how often it has to be altered as result of our > > reviews. > > > > -Marco > > > > Hen <bay...@apache.org> schrieb am Fr., 15. Juni 2018, 00:00: > > > > > 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 > > > > > > > > > >
