If there are no objections, I plan to start a vote on this tomorrow (Monday)
- Carin On Fri, Nov 2, 2018 at 10:24 AM Carin Meier <carinme...@gmail.com> wrote: > 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 >> >
