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 Mon, 22 Oct 2018 03:16:42 GMT
I am ok with this current doc. The other doc, I forget where it is, has a
list something like “things that will make you a committer....pushing a
release out” (or something like that). Which isn’t really the case, since
lots of people who have led a release aren’t committers yet.

On Thu, Oct 18, 2018 at 10: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