Haibin - Now that the updated document on "Becoming a Committer and PPMC Member" has been adopted by the community, would you be interested in starting a procedural vote on this?
If not, I'd be happy to facilitate, but since it was your idea to start off with, I thought I would ask :) Best, Carin On Tue, Oct 9, 2018 at 2:11 PM Haibin Lin <haibin.lin....@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 >
