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 <carinme...@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 <j...@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....@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 >> >>
