mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marco de Abreu <marco.g.ab...@googlemail.com.INVALID>
Subject Re: About Becoming a Committer
Date Fri, 15 Jun 2018 07:26:30 GMT
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 <bayard@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.pvg@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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message