I am ok with this current doc. The other doc, I forget where it is, has a list something like “things that will make you a committer....pushing a release out” (or something like that). Which isn’t really the case, since lots of people who have led a release aren’t committers yet.
On Thu, Oct 18, 2018 at 10:16 AM Naveen Swamy <mnnav...@gmail.com> wrote: > I suggest we discuss on what the revised criteria for committers will be > and how do committers move up to become a PMC member before voting on the > separation ? I would like to see if that helps grow the community before > Voting on this. > > @Chris Olivier <cjolivie...@gmail.com> Can you clarify what you mean by > bonafide intentions and other intangeables ?, > I would assume one can still consider them while you vote if you can > justify or support it and not be just based on how someone feels. > > On Thu, Oct 18, 2018 at 8:29 AM Chris Olivier <cjolivie...@gmail.com> > wrote: > >> 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 >> > > > > > >> >> > > > > > >> >> > > > > > >> > > > > >> > > > >> > > >> > >> >
