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