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
