[Discussion] Separating PMC and Committership
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
Re: [Discussion] Separating PMC and Committership
is it convenient to define the difference and the rights and privileges of each? write access, private list, voting and veto power, etc? On Tue, Oct 9, 2018 at 11:11 AM Haibin Lin 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 >
Re: [Discussion] Separating PMC and Committership
Am 10. Oktober 2018 04:31:49 MESZ schrieb Chris Olivier : >is it convenient to define the difference and the rights and privileges >of >each? write access, private list, voting and veto power, etc? +1 - also, likely it would make sense to also list the responsibilities of each. Isabel -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Re: [Discussion] Separating PMC and Committership
I think it makes a lot of sense to separate these roles Haibin. My impression is there's a high degree of knowledge and experience required to make strategic design decisions on the project. There's a bunch of core members of the team that have that knowledge, and I feel there's a bit of an un-written rule at the moment within the community that we defer to their judgement for important decisions. Given this I think it makes sense to have some tiered membership. This gives some opportunities for contributors to be recognized, and would allow them to help out with some of the day-to-day tasks that PPMC members wouldn't have time for. When it comes to responsibilities one high-level suggestion I'd make is that core members retain decision making abilities for the 'big' decisions where experience is required. Anything controversial, anything that has wide impacts on the project etc. should be signed off on by a PPMC member. Committers could then potentially be free to work on anything that doesn't fall in this category. As an example a committer could help update code to follow existing style guides, and PPMC member would be required to sign off on new guides. On Wed, Oct 10, 2018 at 6:44 AM Isabel Drost-Fromm wrote: > > > Am 10. Oktober 2018 04:31:49 MESZ schrieb Chris Olivier < > cjolivie...@gmail.com>: > >is it convenient to define the difference and the rights and privileges > >of > >each? write access, private list, voting and veto power, etc? > > +1 - also, likely it would make sense to also list the responsibilities of > each. > > Isabel > > -- > Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet. >
Re: [Discussion] Separating PMC and Committership
Am 10. Oktober 2018 11:04:30 MESZ schrieb kellen sunderland : > My >impression is there's a high degree of knowledge and experience >required to >make strategic design decisions on the project. This statement indicates a certain understanding of what a PMC actually does. As a first step, would everyone please state their perspective on what their understanding of what the role committer, PMC member and PMC chair actually are? I really want to make sure we are talking about the same things here. Isabel -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Re: [Discussion] Separating PMC and Committership
+1 This will be very useful for increasing our committer pool that has expertise in various components and not necessarily across and complete in-depth expertise. This will have mainly 3 major positive impact on the project: 1. Will greatly help in managing PRs and issues with fast turn around. There by more activity and frustration free contributions and hence more people eligible for committership. A positive cycle effect in community building. Currently this is a most critical missing piece in the project that is delaying and not so great quick start for new contributions. 2. Increase in committer pool is more motivation for more people to be part of the MXNet community and contribute and learn more parts of the project and increase their expertise. 3. PMC being able to focus on more critical decision making and steer the direction. However, like others suggested, success of this whole effort will be based on defining clear responsibility of PMC, committers and path for the community to be part of committers and PMC. On Wed, Oct 10, 2018, 3:37 AM Isabel Drost-Fromm wrote: > > > Am 10. Oktober 2018 11:04:30 MESZ schrieb kellen sunderland < > kellen.sunderl...@gmail.com>: > > My > >impression is there's a high degree of knowledge and experience > >required to > >make strategic design decisions on the project. > > This statement indicates a certain understanding of what a PMC actually > does. As a first step, would everyone please state their perspective on > what their understanding of what the role committer, PMC member and PMC > chair actually are? I really want to make sure we are talking about the > same things here. > > Isabel > > > -- > Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet. >
Re: [Discussion] Separating PMC and Committership
Am 10. Oktober 2018 16:16:47 MESZ schrieb sandeep krishnamurthy : >However, like others suggested, success of this whole effort will be >based >on defining clear responsibility of PMC, committers and path for the >community to be part of committers and PMC. PMC member and chair are ASF defined roles. Some getting started docs: http://www.apache.org/foundation/how-it-works.html#pmc So to make my previous ask more explicit: Before discussing pros and cons of splitting roles I think it would make sense for everyone to either share their understanding of what those roles are or research the terms and share their resulting understanding. From the discussion so far to me it looks like this could be a helpful exercise to avoid confusion. Isabel -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Re: [Discussion] Separating PMC and Committership
Thanks for bringing up here. I think this topic and suggestions should be a little more concrete by clarifying the difference between the role of committer and PMC member. Based on my understanding of here are my comments and concerns 1) I agree we need to bring more committers into the project, How would you change the existing (but not followed IMO) committer criteria[1]. 2) Can you expand on what significant contribution means to become a PMC member? I think its important to recognize people who are supporting the project in other ways than making code contributions like those building tutorials/documentation/managing CI/managing community, etc., 3) There are ~40 PMC members(committer+mentors), out of which i can count in one hand the number of people who participate on the list(not questioning) - This separation might lose perspectives that new members bring into the PMC. 4) Building consensus in the PMC - IMHO, the problem here is when we have disagreements is whether we(self included) accept each other's feedback and respectfully disagree with each other - that is something for the PMC to contemplate. I wonder if keeping people out would solve that problem. 5) like other's mentioned, it's important to call out what does being a committer and a PMC member mean. [1] https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer On Wed, Oct 10, 2018 at 7:29 AM Isabel Drost-Fromm wrote: > > > Am 10. Oktober 2018 16:16:47 MESZ schrieb sandeep krishnamurthy < > sandeep.krishn...@gmail.com>: > >However, like others suggested, success of this whole effort will be > >based > >on defining clear responsibility of PMC, committers and path for the > >community to be part of committers and PMC. > > PMC member and chair are ASF defined roles. Some getting started docs: > > http://www.apache.org/foundation/how-it-works.html#pmc > > So to make my previous ask more explicit: Before discussing pros and cons > of splitting roles I think it would make sense for everyone to either share > their understanding of what those roles are or research the terms and share > their resulting understanding. From the discussion so far to me it looks > like this could be a helpful exercise to avoid confusion. > > Isabel > > -- > Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet. >
Re: [Discussion] Separating PMC and Committership
Hi Haibin - thanks for driving the discussion and thanks to Isabel to suggest review of roles and responsibilities. I do agree with the points Sandeep raised. I though about such separation myself and discussed with a few project members. Honestly, I got mixed feedback and couldn't really give myself a satisfying answer how to differentiate between committer and PMC member at this stage of the MXNet project. Apache MXNet (incubating) project does have an agreed process for electing committers - https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer and in my personal analysis there are a number of active contributors meeting the criteria. I suggest that a fair evaluation of active contributors by the PPMC will help to determine if established criteria are meet for consideration to election as committer and PPMC member. Such an analysis might also help to get a better understanding why a differentiation might be useful and what criteria to modify or establish. It might also help to identify potential gaps of contributions, which could be closed with mentoring. A friend of the MXNet project suggested to look at https://lists.apache.org/thread.html/33a6c3aa0fffa6e961aa2b861ebde333d898a5e1062d0d71d0e13d46@%3Cdev.community.apache.org%3E– and learn from the experience of beam project in a similar situation. Either way, it is a good discussion to have to help to grow the community and project. I hope the that a lot of committers and contributors will participate. I met with Mark Thomas at ApacheCon in Montreal. He gave a pretty interesting talk in June in Berlin - https://foss-backstage.de/session/community-anti-patterns. He offered to present and discuss with interested members of the project about his experience on growing projects and communities. Happy to make arrangements, if the community is interested. Regards, Steffen On Wed, Oct 10, 2018 at 7:17 AM sandeep krishnamurthy < sandeep.krishn...@gmail.com> wrote: > +1 > This will be very useful for increasing our committer pool that has > expertise in various components and not necessarily across and complete > in-depth expertise. This will have mainly 3 major positive impact on the > project: > 1. Will greatly help in managing PRs and issues with fast turn around. > There by more activity and frustration free contributions and hence more > people eligible for committership. A positive cycle effect in community > building. Currently this is a most critical missing piece in the project > that is delaying and not so great quick start for new contributions. > > 2. Increase in committer pool is more motivation for more people to be part > of the MXNet community and contribute and learn more parts of the project > and increase their expertise. > > 3. PMC being able to focus on more critical decision making and steer the > direction. > > However, like others suggested, success of this whole effort will be based > on defining clear responsibility of PMC, committers and path for the > community to be part of committers and PMC. > > > On Wed, Oct 10, 2018, 3:37 AM Isabel Drost-Fromm > wrote: > > > > > > > Am 10. Oktober 2018 11:04:30 MESZ schrieb kellen sunderland < > > kellen.sunderl...@gmail.com>: > > > My > > >impression is there's a high degree of knowledge and experience > > >required to > > >make strategic design decisions on the project. > > > > This statement indicates a certain understanding of what a PMC actually > > does. As a first step, would everyone please state their perspective on > > what their understanding of what the role committer, PMC member and PMC > > chair actually are? I really want to make sure we are talking about the > > same things here. > > > > Isabel > > > > > > -- > > Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet. > > >
Re: [Discussion] Separating PMC and Committership
On 2018/10/10 09:04:30, kellen sunderland wrote: > When it comes to responsibilities one high-level suggestion I'd make is > that core members retain decision making abilities for the 'big' decisions > where experience is required. Written from the PMC point of view: Every individual member of the PMC is held accountable for the project to report quarterly, to comply with legal standards, to comply with brand management policies, follow press standards, address security vulnerabilities, to conduct business on public mailing lists, grow the community, to limit the use of private mailing lists. All of these account-abilities come without discretionary power over your peers who are working as individuals on mxnet. PMC members do have binding votes on releases. They do have binding votes for adding new committers and new PMC members. While in incubation there's quite a bit of help from mentors for all of the above, as soon as you leave incubation those are the main responsibilities of PMC members. (For those who want to dig deeper: http://www.apache.org/dev/pmc.html ) Notice how little all of these tasks have to do with coding decisions. Or to quote the link I sent earlier: "The role of the PMC from a Foundation perspective is oversight. The main role of the PMC is not code and not coding - but to ensure that all legal issues are addressed, that procedure is followed, and that each and every release is the product of the community as a whole. That is key to our litigation protection mechanisms." The tl;dr; version that I (half jokingly) tell people: "You don't want to become a PMC member - it gives you access to yet another mailing list to follow and it adds a whole lot of new responsibilities." Coming from that perspective, several of the arguments I have seen exchanged so far wrt. to splitting the roles to me read like you have an understanding of those roles that is different from the above. I hope the above helps, Isabel
Re: [Discussion] Separating PMC and Committership
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 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 b
Re: [Discussion] Separating PMC and Committership
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 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 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 possibili
Re: [Discussion] Separating PMC and Committership
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 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 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 >> 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
Re: [Discussion] Separating PMC and Committership
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 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 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 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 > >> 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
Re: [Discussion] Separating PMC and Committership
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 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 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 > 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 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 > > >> 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 a
Re: [Discussion] Separating PMC and Committership
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 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 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 > 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 > > 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 > 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 > > > >> 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 > >
Re: [Discussion] Separating PMC and Committership
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 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 > 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 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 > > 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 > > > wrote: > > > > > > > > > This has been a very interesting discussion and I think it > > underlined a > > > > > desire to increase the committer pool and community for th
Re: [Discussion] Separating PMC and Committership
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 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 > 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 > > 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 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 > > > wrote: > > > > > > > > > Let me rephrase the question. > > > > > > > > > >
Re: [Discussion] Separating PMC and Committership
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 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 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 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 > > 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 > > > 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 > 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 > > > >
Re: [Discussion] Separating PMC and Committership
I think in general it's always a good idea to reduce barriers to entry into the project. Therefore I think separating committer and PMC roles is a good idea, as it helps encourage and recognize contributors by giving them commit early; and then it allows the new committers to spend some more time to understand the projects governance (esp. how the the Apache Way is applied by the PMC), so as to get ready for the PMC role. Thanks, -Jason On Fri, Oct 19, 2018 at 1:16 AM Naveen Swamy 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 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 > 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 > 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 > > > > > 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 > > 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 com
Re: [Discussion] Separating PMC and Committership
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 committerpushing 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 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 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 > 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 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 > > >> > 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 >> > > 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 >> 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. >> > > > > >> > > > > Assu
Re: [Discussion] Separating PMC and Committership
Haibin - Now that the updated document on "Becoming a Committer and PPMC Member" has been adopted by the community, would you be interested in starting a procedural vote on this? If not, I'd be happy to facilitate, but since it was your idea to start off with, I thought I would ask :) Best, Carin On Tue, Oct 9, 2018 at 2:11 PM Haibin Lin 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 >
Re: [Discussion] Separating PMC and Committership
If there are no objections, I plan to start a vote on this tomorrow (Monday) - Carin On Fri, Nov 2, 2018 at 10:24 AM Carin Meier wrote: > Haibin - Now that the updated document on "Becoming a Committer and PPMC > Member" has been adopted by the community, would you be interested in > starting a procedural vote on this? > > If not, I'd be happy to facilitate, but since it was your idea to start > off with, I thought I would ask :) > > Best, > Carin > > On Tue, Oct 9, 2018 at 2:11 PM Haibin Lin > 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
