mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dai <jason....@gmail.com>
Subject Re: [Discussion] Separating PMC and Committership
Date Fri, 19 Oct 2018 14:36:17 GMT
I think in general it's always a good idea to reduce barriers to entry into
the project. Therefore I think separating committer and PMC roles is a good
idea, as it helps encourage and recognize contributors by giving them
commit early; and then it allows the new committers to spend some more time
to understand the projects governance (esp. how the the Apache Way is
applied by the PMC), so as to get ready for the PMC role.

Thanks,
-Jason

On Fri, Oct 19, 2018 at 1:16 AM Naveen Swamy <mnnaveen@gmail.com> wrote:

> I suggest we discuss on what the revised criteria for committers will be
> and how do committers move up to become a PMC member before voting on the
> separation ? I would like to see if that helps grow the community before
> Voting on this.
>
> @Chris Olivier <cjolivier01@gmail.com> Can you clarify what you mean by
> bonafide intentions and other intangeables ?,
> I would assume one can still consider them while you vote if you can
> justify or support it and not be just based on how someone feels.
>
> On Thu, Oct 18, 2018 at 8:29 AM Chris Olivier <cjolivier01@gmail.com>
> wrote:
>
> > 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