I believe the assumption has always been that current PMC members will remain PMC members.
On Wed, Oct 17, 2018 at 3:51 PM Michael Wall <mjw...@gmail.com> wrote: > 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 > > >> > > >> > > >
