IMHO it’s not a great idea to develop a hard criteria for committer and PMC as if it were some sort of checklist. If that were the case, then people would tend to be just laser-focused on checking items off the list rather than a bonafied drive to improve the product and the community. It would also make it difficult to consider other intangeables in the decision.
On Thu, Oct 18, 2018 at 5:43 AM Carin Meier <carinme...@gmail.com> wrote: > Thanks Micheal for making the process clearer to me. It helps quite a bit. > > Also thanks to Chris and Steffen for your clarification and input. > > I think there are two issues that are intermingled in considering this. One > relates to separating levels of committer and PMC member. The other, as > Steffen pointed out, relates to the criteria which we use to consider > people for these levels of membership. I would propose that to make it > easier to achieve consensus, we consider them each as their own proposal. > > The proposal of separating levels of committer and PMC member can be > considered on the Apache definitions of rights and responsibilities here > https://www.apache.org/foundation/how-it-works.html#roles: Since the PMC > member has more rights and responsibilities than a committer, I think it > implies a stricter criteria, (although it would be unspecified in the > proposal). > > The proposal of redefining our project's criteria in respect to how we > consider nomination to those roles could be a separate discussion and vote > since there are other issues that we might want to tackle such as inclusion > of non-code contributions and general alignment to the Apache definitions. > > We can of course choose to tackle the proposal of redefining the criteria > first or do the separation of levels first since the discussion is already > in progress. > > Thoughts? > > - Carin > > > > > > > On Thu, Oct 18, 2018 at 2:04 AM Steffen Rochel <steffenroc...@gmail.com> > wrote: > > > Haibin's proposed "For active contributors we first invite them to become > > our committers. Later on as they make significant contribution, we can > > invite them to PMC." > > Several people raised the question what defines "active contributors" and > > "make significant contribution". In my view the discussion has not > answered > > the questions and it is not clear to me what changes are proposed to > > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer . > > I'm making the assumption that the proposal is to simplify the path for > > becoming a committer to grow the committer community. So far I have not > > heard what changes or simplifications are proposed. Without a change I > fail > > to see the benefit of this proposal to increase the number of committers. > > I agree that the path from committer to PMC member should be clarified as > > well and suggest to align with expectations and responsibilities of PMC > > members. > > I'm also under the assumption that the proposal only applies for future > > committers and PMC members, not for existing PMC members and this > > assumption should be clarified. > > > > Steffen > > > > On Wed, Oct 17, 2018 at 4:29 PM Chris Olivier <cjolivie...@gmail.com> > > wrote: > > > > > 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 > > > > > >> > > > > > >> > > > > > > > > > > > > > > >
