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 Thu, 18 Oct 2018 15:16:33 GMT
IMHO it’s not a great idea to develop a hard criteria for committer and PMC
as if it were some sort of checklist. If that were the case, then people
would tend to be just laser-focused on checking items off the list rather
than a bonafied drive to improve the product and the community.  It would
also make it difficult to consider other intangeables in the decision.


On Thu, Oct 18, 2018 at 5:43 AM Carin Meier <carinmeier@gmail.com> wrote:

> Thanks Micheal for making the process clearer to me. It helps quite a bit.
>
> Also thanks to Chris and Steffen for your clarification and input.
>
> I think there are two issues that are intermingled in considering this. One
> relates to separating levels of committer and PMC member. The other, as
> Steffen pointed out, relates to the criteria which we use to consider
> people for these levels of membership. I would propose that to make it
> easier to achieve consensus, we consider them each as their own proposal.
>
> The proposal of separating levels of committer and PMC member can be
> considered on the Apache definitions of rights and responsibilities here
> https://www.apache.org/foundation/how-it-works.html#roles: Since the PMC
> member has more rights and responsibilities than a committer, I think it
> implies a stricter criteria, (although it would be unspecified in the
> proposal).
>
> The proposal of redefining our project's criteria in respect to how we
> consider nomination to those roles could be a separate discussion and vote
> since there are other issues that we might want to tackle such as inclusion
> of non-code contributions and general alignment to the Apache definitions.
>
> We can of course choose to tackle the proposal of redefining the criteria
> first or do the separation of levels first since the discussion is already
> in progress.
>
> Thoughts?
>
> - Carin
>
>
>
>
>
>
> On Thu, Oct 18, 2018 at 2:04 AM Steffen Rochel <steffenrochel@gmail.com>
> wrote:
>
> > Haibin's proposed "For active contributors we first invite them to become
> > our committers. Later on as they make significant contribution, we can
> > invite them to PMC."
> > Several people raised the question what defines "active contributors" and
> > "make significant contribution". In my view the discussion has not
> answered
> > the questions and it is not clear to me what changes are proposed to
> > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer .
> > I'm making the assumption that the proposal is to simplify the path for
> > becoming a committer to grow the committer community. So far I have not
> > heard what changes or simplifications are proposed. Without a change I
> fail
> > to see the benefit of this proposal to increase the number of committers.
> > I agree that the path from committer to PMC member should be clarified as
> > well and suggest to align with expectations and responsibilities of PMC
> > members.
> > I'm also under the assumption that the proposal only applies for future
> > committers and PMC members, not for existing PMC members and this
> > assumption should be clarified.
> >
> > Steffen
> >
> > On Wed, Oct 17, 2018 at 4:29 PM Chris Olivier <cjolivier01@gmail.com>
> > wrote:
> >
> > > 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