mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Olivier <cjolivie...@gmail.com>
Subject Re: [Discussion] Separating PMC and Committership
Date Wed, 17 Oct 2018 23:28:39 GMT
I believe the assumption has always been that current PMC members will
remain PMC members.

On Wed, Oct 17, 2018 at 3:51 PM Michael Wall <mjwall@gmail.com> wrote:

> I too think separating committers from PMC is a good idea for your project
> given the desire to grow committers and the concerns I have seen trying to
> add new committers.  I saw at least one other mentor, Jim on this thread
> too.
>
> Is the plan to leave all current PMC members in the PMC?  If that is not
> the plan, perhaps more discussion is required before moving on.
>
> Assuming you feel the discussion is done, someone needs to start a vote.
> This would be a procedural change as outlined on
> https://www.apache.org/foundation/voting.html
>
> If I were doing it, I would announce on this thread I am starting a vote on
> this matter tomorrow or some specified time.  I might even outline what the
> vote will be.  This give people a chance to speak up if they think more
> discussion is needed.  Assuming no more discussion, start a [VOTE] thread
> on the dev list.
>
> I am used to seeing [VOTE] and [DISCUSS] in the subject line of such emails
> but I didn't find any official guidance on that.  Maybe it is a project by
> project decision, I did find
> https://cwiki.apache.org/confluence/display/EDGENT/Sample+process+emails.
> I totally parsed right over the [Discussion] in the subject this thread but
> I'll be on the look out for it in the future.
>
> Thanks
>
> Mike
>
> On Wed, Oct 17, 2018 at 6:05 PM Carin Meier <carinmeier@gmail.com> wrote:
>
> > Let me rephrase the question.
> >
> > Since I'm new to the committer/PMC process, I wondering what the next
> step
> > is in a proposed change of process like this.
> >
> > If we gauge that there is a significant enough interest do we propose a
> > vote? Is there enough interest and information to have a vote in this
> case?
> >
> > (Anyone feel free to answer the question - mentor or not :) )
> >
> > - Carin
> >
> > On Tue, Oct 16, 2018 at 7:48 PM Carin Meier <carinmeier@gmail.com>
> wrote:
> >
> > > This has been a very interesting discussion and I think it underlined a
> > > desire to increase the committer pool and community for the project.
> I'm
> > > wondering now what the next steps would look like?
> > >
> > > Do any mentors have any advice on how to proceed?
> > >
> > > - Carin
> > >
> > > On Thu, Oct 11, 2018 at 1:23 PM Jim Jagielski <jim@jagunet.com> wrote:
> > >
> > >> In my experience, and in my opinion, it makes sense to distinguish and
> > >> differentiate between a committer and a PMC member. The latter shows
> > just a
> > >> bit more "investment" in the project and has obtained a bit more merit
> > due
> > >> to their continued efforts.
> > >>
> > >> Of course, what we also need is some public governance model that
> shows
> > >> what these levels are, what they mean and how to obtain them. The
> > following
> > >> is the normal setup for Apache projects:
> > >>
> > >>     https://www.apache.org/foundation/how-it-works.html#roles
> > >>
> > >> The nice this is that this also allows for a very low-bar-to-entry for
> > >> committer-ship while still maintain a somewhat higher bar for the
> PPMC,
> > >> which is great for community building.
> > >>
> > >> > On Oct 9, 2018, at 2:11 PM, Haibin Lin <haibin.lin.aws@gmail.com>
> > >> wrote:
> > >> >
> > >> > Dear MXNet community,
> > >> >
> > >> > In the past when we invite a person to become a committer, he/she
is
> > >> > automatically made a PMC member. However, a lot of communities keep
> a
> > >> small
> > >> > PMC, and a bigger and more diverse committers to enrich the
> community.
> > >> This
> > >> > has the benefit of having two opportunities to encourage
> contribution.
> > >> This
> > >> > can also help lower the bar for inviting committers, which helps
> build
> > >> > consensus in our already large PMC. I'd like to propose the
> following:
> > >> >
> > >> > For active contributors we first invite them to become our
> committers.
> > >> > Later on as they make significant contribution, we can invite them
> to
> > >> PMC.
> > >> >
> > >> >
> > >> > ===============================================================
> > >> > Comments from Marco:
> > >> >
> > >> > That's a great idea!
> > >> >
> > >> > The hard question is how to differentiate between a committer and
a
> > PMC
> > >> > member and where we set the bar for each. If I understand you right,
> > you
> > >> > are proposing to honor active contributions by volume (or another
> > >> similar
> > >> > metric). While I think that's a good idea in general, I have a few
> > >> thoughts:
> > >> >
> > >> > We definitely have a lot of active people in the project, but let's
> > say
> > >> > that they contribute a substantial amount, but their contributions
> > >> can't go
> > >> > in as-is because they lack quality, consistency, testing or they
> don't
> > >> > match with the overall style and best practices. For a
> code-committer,
> > >> this
> > >> > would still be a no-go in my opinion. That person would still
> require
> > >> some
> > >> > guidance and mentoring until they are aligned with the project style
> > and
> > >> > guidelines as otherwise they might accept low-quality PRs. I know
we
> > can
> > >> > revert that, but let's avoid confrontation as much as possible.
> > >> >
> > >> > The minimum bar for a code committer would then be:
> > >> > - (almost) unaltered acceptance of their PRs (of course, some PRs
> are
> > >> > intentionally made for discussions and those would even be a plus!)
> > >> > - following mxnets community guidelines, rules and styles
> > >> > - giving useful reviews (in order to see how they would be as
> > reviewers
> > >> if
> > >> > they were a committer)
> > >> > The would be weighted differently on a case by case base, but this
> > >> could be
> > >> > a starting point to describe what we are looking for.
> > >> >
> > >> > From committer to PMC on the other hand, the difference is quite
> > small.
> > >> > Something I personally would be looking for are three things:
> > >> > - judgement
> > >> > - community engagement
> > >> > - Apache way
> > >> > While a committer might be chosen due to their contributions, they
> > >> wouldn't
> > >> > be evaluated that strictly for the above points. A PMC member is a
> > >> > representative of the project who steers the long term development
> of
> > >> it.
> > >> > Thus, they should be active on our channels like dev@, make good
> > >> reviews on
> > >> > GitHub (if applicable), express good judgement and reasoning during
> > >> votes
> > >> > and generally show that they are generally helpful to the project
> on a
> > >> > non-code level.
> > >> >
> > >> > These are just some thoughts of mine to help start of this
> > discussions.
> > >> It
> > >> > would be good to hear what other people are looking for while
> > evaluating
> > >> > candidates and if there's anything they would like to highlight.
> > >> >
> > >> > ==============================================================
> > >> >
> > >> > Comments from Carin:
> > >> >
> > >> > I think it is a good idea. Here is a bit of reasoning behind my
> > >> thoughts.
> > >> >
> > >> > *Pros of separating Committer and PMC *
> > >> > - It would allow us to bring on more committers than the previous
> > >> criteria
> > >> > which would help in giving people the tools they need to be
> > productive.
> > >> > - The increased productivity should allow PRs to be reviewed and
> > merged
> > >> > more quickly.
> > >> > - Provide a more welcoming experience for people posting new PRs to
> > have
> > >> > them processed faster.
> > >> > - Also provide an additional layer of membership (PMC) after a
> > committer
> > >> > to help motivate involvement.
> > >> >
> > >> > *Cons of separating*
> > >> > - There is a possibility of having someone as a committer that isn't
> > as
> > >> > closely aligned to the standards and quality suffers.
> > >> >    *Possible Mitigation*
> > >> >    - We do have a robust CI that should ensure that basic
> > functionality
> > >> > doesn't break.
> > >> >    - Do additional communication when a new committer is announced
> > what
> > >> > the expectation of the standards of committership is.
> > >> > - Two votes now need to happen for a person since there are two
> > levels.
> > >> >   *Possible Mitigation*
> > >> >    - If we are convinced the person would be a good PMC member as
> > well,
> > >> we
> > >> > could vote them as both at the same time.
> > >> >
> > >> > I think it would be a good change to try and see how it works out
> > over a
> > >> > period of a few months. The nice thing is that if we feel like it
> > isn't
> > >> > working well, we can always change the process.
> > >> >
> > >> > ==============================================================
> > >> >
> > >> >
> > >> > Best,
> > >> > Haibin
> > >>
> > >>
> >
>

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