Re: About Becoming a Committer
Oh Pedro... lol funny stuff. On Sat, Jun 16, 2018 at 10:20 AM Sebastian wrote: > On 16.06.2018 10:57, Pedro Larroy wrote: > > Hi Sebastian. > > > > Thank you for your comment. That's why I said "I would propose", because > I > > don't know if it's possible as my experience with Apache is limited to > the > > MXNet project. > > > > How do you interpret this part?: "Since the appointed Project Management > > Committees have the power to create their own self-governing rules, there > > is no single vision on how PMCs should run a project and the communities > > they host." > > A podling can decide on many things, e.g., > > * what the bar for committership should be > * whether to automatically make committers PMC members > * rules for commits (e.g., whether you need an ok from a second > committer) > > However, a podling cannot change the fundamental rules of how Apache > works (a podling can however decide to leave the incubator and run the > project under their own umbrella according to their own rules). > > -s >
Re: About Becoming a Committer
On 16.06.2018 10:57, Pedro Larroy wrote: Hi Sebastian. Thank you for your comment. That's why I said "I would propose", because I don't know if it's possible as my experience with Apache is limited to the MXNet project. How do you interpret this part?: "Since the appointed Project Management Committees have the power to create their own self-governing rules, there is no single vision on how PMCs should run a project and the communities they host." A podling can decide on many things, e.g., * what the bar for committership should be * whether to automatically make committers PMC members * rules for commits (e.g., whether you need an ok from a second committer) However, a podling cannot change the fundamental rules of how Apache works (a podling can however decide to leave the incubator and run the project under their own umbrella according to their own rules). -s
Re: About Becoming a Committer
Whoa, who said that? I can’t find it on this thread. On Sat, Jun 16, 2018 at 8:37 AM Sebastian wrote: > > I would propose the two following action points: > > > > * Resetting the list of committers to people that have contributed in > the > > previous terms in the latest 6 months > > * Suspend veto rights temporarily and use simple majority for decisions > > that need a vote so we realign the project with the communities best > > interests. > > None of this is possible within the structure of the ASF, please get > familiar with how the ASF works before making such proposals. > > https://www.apache.org/foundation/how-it-works.html >
Re: About Becoming a Committer
Hi Sebastian. Thank you for your comment. That's why I said "I would propose", because I don't know if it's possible as my experience with Apache is limited to the MXNet project. How do you interpret this part?: "Since the appointed Project Management Committees have the power to create their own self-governing rules, there is no single vision on how PMCs should run a project and the communities they host." Pedro. On Sat, Jun 16, 2018 at 8:37 AM Sebastian wrote: > > I would propose the two following action points: > > > > * Resetting the list of committers to people that have contributed in > the > > previous terms in the latest 6 months > > * Suspend veto rights temporarily and use simple majority for decisions > > that need a vote so we realign the project with the communities best > > interests. > > None of this is possible within the structure of the ASF, please get > familiar with how the ASF works before making such proposals. > > https://www.apache.org/foundation/how-it-works.html >
Re: About Becoming a Committer
I would propose the two following action points: * Resetting the list of committers to people that have contributed in the previous terms in the latest 6 months * Suspend veto rights temporarily and use simple majority for decisions that need a vote so we realign the project with the communities best interests. None of this is possible within the structure of the ASF, please get familiar with how the ASF works before making such proposals. https://www.apache.org/foundation/how-it-works.html
Re: About Becoming a Committer
Great points and feedback. I think everyone here wants the best for the project. We should definitely not shoot down pioneering contributions and be more inclusive with people that are actively contributing to the community with not just code. This should include code, documentation, website changes and other tasks like organizing a meetup or doing project management like helping us plan, organize tasks and milestones. The latter non-code contributions are hard work and should be recognized. I would propose the two following action points: * Resetting the list of committers to people that have contributed in the previous terms in the latest 6 months * Suspend veto rights temporarily and use simple majority for decisions that need a vote so we realign the project with the communities best interests. As other people with extensive open source and community experience have pointed out, we should be more inclusive rather than exclusive. Which includes stop abusing veto and other 'powers' to block contributions or committer proposals, this short sighted behaviour is doing more harm than good to the project. Going forward I think we should raise the engineering standards bar in code contributions, meaning code should be: * Well designed * Reviewed * Documented * Have a reasonable degree of test coverage and be free of bugs in good faith. MXNet users and contributors are not beta testers and shouldn't have the time and financial burden of fixing hard to debug bugs in code that is not well tested. Pedro. On Fri, Jun 15, 2018 at 6:59 PM Tianqi Chen wrote: > First of all, Apache allows each community to define its standard of > comittership -- which I think is super valuable as different projects have > different backgrounds and challenges. Having such flexibility instead of > enforcing a global standard is one of the reasons why many Apache projects > succeed. Here is my reasoning on the standard. > > First of all, all contributions are valuable, and we evaluate them when > considering committer nominations and evaluate them in an unbiased way. > On the other hand, it is hard to create a standard of "equality" of > contributions. Hen's suggestion of code being committed is a good proposal, > but never-the-less biased against contributions that bring in drastically > new design (we can call these type of contributors "pioneers"). The reason > behind this is clear -- it is arguably true that contributions of new > proposals are easier to bring in mistakes, and take a longer time to pass > code reviews (thus costs more effort of fellow committers). "pioneers" get > shot down more easily -- which is not what we want to see. Bring it to > MXNet and the playground we are facing. We are on a super competitive > field, with major tech giants in the play. All the players in the field are > trying out drastically new ideas, and it is even more in our case to not > have such bias. > > So it is indeed important to evaluate it on the basis of contribution, > "quality" is just one word that we choose, and we put trust on the > committers when evaluating them. While it is indeed hard to define such > standard, we are trying our best to make fair evaluations. > > > > On Fri, Jun 15, 2018 at 12:00 AM, Hen wrote: > > > On the 'Becoming+a+Committer' guidelines, I dislike this phrase: > > > > "When it comes to code contributions, quality is more important than > > quantity" > > > > There is only one 'quality' measurement, and that is "was the code > merged". > > If someone makes 10 different contributions and they were all horrible > and > > never merged (or the merger had to write a ton of fixes/tests/additions) > > then yes, that's a pretty bad sign. > > > > If the code was merged; I don't care if it's stunning code or an inspired > > design. It was merged. This isn't a technical promotion process, this is > > about whether the individual has shown the commitment to be extended the > > trust to manage commits. > > > > So; -1 to quality being more important than quantity. It's not. > > > > Hen > > > > > > > > On Fri, Jun 8, 2018 at 1:15 PM, Sheng Zha wrote: > > > > > Hi, > > > > > > There have been a couple of offline inquiries from contributors about > > > becoming a committer. From those inquiries, it seems that there’s > > confusion > > > in our community about how to become a committer, so I’d like to take > > this > > > opportunity to clarify. > > > > > > The guideline about becoming a committer can be found at > > > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer > . > > > The > > > gist of the guideline is that, like any other Apache project, MXNet > > > committers are invited by existing committers based on merit. The > > existing > > > committers look for sustained, high quality contribution and community > > > involvement among project contributors. When a candidate is spotted, > this > > > contributor will be nominated and voted among PMC members, and if all > > goes > > >
Re: About Becoming a Committer
First of all, Apache allows each community to define its standard of comittership -- which I think is super valuable as different projects have different backgrounds and challenges. Having such flexibility instead of enforcing a global standard is one of the reasons why many Apache projects succeed. Here is my reasoning on the standard. First of all, all contributions are valuable, and we evaluate them when considering committer nominations and evaluate them in an unbiased way. On the other hand, it is hard to create a standard of "equality" of contributions. Hen's suggestion of code being committed is a good proposal, but never-the-less biased against contributions that bring in drastically new design (we can call these type of contributors "pioneers"). The reason behind this is clear -- it is arguably true that contributions of new proposals are easier to bring in mistakes, and take a longer time to pass code reviews (thus costs more effort of fellow committers). "pioneers" get shot down more easily -- which is not what we want to see. Bring it to MXNet and the playground we are facing. We are on a super competitive field, with major tech giants in the play. All the players in the field are trying out drastically new ideas, and it is even more in our case to not have such bias. So it is indeed important to evaluate it on the basis of contribution, "quality" is just one word that we choose, and we put trust on the committers when evaluating them. While it is indeed hard to define such standard, we are trying our best to make fair evaluations. On Fri, Jun 15, 2018 at 12:00 AM, Hen wrote: > On the 'Becoming+a+Committer' guidelines, I dislike this phrase: > > "When it comes to code contributions, quality is more important than > quantity" > > There is only one 'quality' measurement, and that is "was the code merged". > If someone makes 10 different contributions and they were all horrible and > never merged (or the merger had to write a ton of fixes/tests/additions) > then yes, that's a pretty bad sign. > > If the code was merged; I don't care if it's stunning code or an inspired > design. It was merged. This isn't a technical promotion process, this is > about whether the individual has shown the commitment to be extended the > trust to manage commits. > > So; -1 to quality being more important than quantity. It's not. > > Hen > > > > On Fri, Jun 8, 2018 at 1:15 PM, Sheng Zha wrote: > > > Hi, > > > > There have been a couple of offline inquiries from contributors about > > becoming a committer. From those inquiries, it seems that there’s > confusion > > in our community about how to become a committer, so I’d like to take > this > > opportunity to clarify. > > > > The guideline about becoming a committer can be found at > > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer. > > The > > gist of the guideline is that, like any other Apache project, MXNet > > committers are invited by existing committers based on merit. The > existing > > committers look for sustained, high quality contribution and community > > involvement among project contributors. When a candidate is spotted, this > > contributor will be nominated and voted among PMC members, and if all > goes > > well, this contributor will receive an invitation to join as a committer > > and PMC member. > > > > Note that such discussion and decision happens in private among existing > > PMC members and mentors through consensus, and information regarding what > > happened in this process will always remain private, so as to rid the > > influence of different interest groups. PMC members will not ask > > contributors for committer application, nor will they accept one. Except > > the aforementioned PMC members consensus process, any other process by > any > > organization under any circumstances will not be recognized. > > > > I hope that you find the above clarification helpful. If you have further > > question on this topic feel free to ask. > > > > Sheng > > >
Re: About Becoming a Committer
Totally agree, thanks for elaborating! Hen schrieb am Fr., 15. Juni 2018, 00:44: > That wasn't what I was trying to say (I'll try again - tis late and I'm > sure I'm speaking poorly :) ). > > It says: > > "When it comes to code contributions, quality is more important than > quantity. While all contributions are welcome and highly appreciated, > certain guidelines will be applied when it comes to committer nominations, > e.g. clean, documented and maintainable code, including unit tests if > applicable. Updating license text or fixing indentation in hundreds of > source files for instance is case of quantity trumping quality. " > > If someone is updating licensing text, or fixing indentation, then that is > great. That's as good as someone who wrote a lump of clean, documented and > maintainable code with unit tests. The important part isn't the patch, it's > how much back and forth there had to be to get the patch to the point where > it could be merged. > > My concern, and I feel the language on the page reflects this, is that one > commit is rated higher than a different commit with regards to showing > commitment. That's wrong imo. All commits are equal (as are any other > actions for the project, such as answering a question, improving wiki, > maintaining CI, helping people on Slack). Becoming a committer is about the > trust built up by the committers not having to modify the action (PR, > proposed-answer, proposed-wiki-change etc). > > Hen > > On Fri, Jun 15, 2018 at 12:26 AM, Marco de Abreu < > marco.g.ab...@googlemail.com.invalid> wrote: > > > Hen, > > > > As you stated, it's of significance of how much a PR has to be changed > as a > > result of a review. I think this is what this project defines as quality. > > > > If people submit a bunch of PRs and we reviewers spend a lot of time on > > every single one of them to give the contributors advice about how to do > it > > the right way, then that's a great contribution but doesn't really show > > that the person is either up par with the standards of the project or > > understood the design principles. In both cases they added value to the > > project, but the bar would have been lowered if the reviewers didn't > > intercept. Of course, there is always something people will have to > > criticize as part of the review and that's natural. But what you are > > describing here is basically that we should make people committers > because > > of the amount of value they added through the code. > > > > While that's a good way to look at it in general, it doesn't consider > > important aspects: how much of this value has been added by the reviewer? > > And what happens if that person starts merging other PRs. If a person > who > > is not up par with the standards of the project is granted permission to > > merge pull requests and they merge them prematurely because they don't > know > > that things are wrong, then this is harming the project in the long term. > > If more and more people with lower standards are granted permissions, we > > will enter a downwards spiral. > > > > That's why I have to disagree that it's not about how often a PR has been > > merged but rather about how often it has to be altered as result of our > > reviews. > > > > -Marco > > > > Hen schrieb am Fr., 15. Juni 2018, 00:00: > > > > > On the 'Becoming+a+Committer' guidelines, I dislike this phrase: > > > > > > "When it comes to code contributions, quality is more important than > > > quantity" > > > > > > There is only one 'quality' measurement, and that is "was the code > > merged". > > > If someone makes 10 different contributions and they were all horrible > > and > > > never merged (or the merger had to write a ton of > fixes/tests/additions) > > > then yes, that's a pretty bad sign. > > > > > > If the code was merged; I don't care if it's stunning code or an > inspired > > > design. It was merged. This isn't a technical promotion process, this > is > > > about whether the individual has shown the commitment to be extended > the > > > trust to manage commits. > > > > > > So; -1 to quality being more important than quantity. It's not. > > > > > > Hen > > > > > > > > > > > > On Fri, Jun 8, 2018 at 1:15 PM, Sheng Zha wrote: > > > > > > > Hi, > > > > > > > > There have been a couple of offline inquiries from contributors about > > > > becoming a committer. From those inquiries, it seems that there’s > > > confusion > > > > in our community about how to become a committer, so I’d like to take > > > this > > > > opportunity to clarify. > > > > > > > > The guideline about becoming a committer can be found at > > > > > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer > > . > > > > The > > > > gist of the guideline is that, like any other Apache project, MXNet > > > > committers are invited by existing committers based on merit. The > > > existing > > > > committers look for sustained, high quality contribution and > community > > > > involvement among
Re: About Becoming a Committer
That wasn't what I was trying to say (I'll try again - tis late and I'm sure I'm speaking poorly :) ). It says: "When it comes to code contributions, quality is more important than quantity. While all contributions are welcome and highly appreciated, certain guidelines will be applied when it comes to committer nominations, e.g. clean, documented and maintainable code, including unit tests if applicable. Updating license text or fixing indentation in hundreds of source files for instance is case of quantity trumping quality. " If someone is updating licensing text, or fixing indentation, then that is great. That's as good as someone who wrote a lump of clean, documented and maintainable code with unit tests. The important part isn't the patch, it's how much back and forth there had to be to get the patch to the point where it could be merged. My concern, and I feel the language on the page reflects this, is that one commit is rated higher than a different commit with regards to showing commitment. That's wrong imo. All commits are equal (as are any other actions for the project, such as answering a question, improving wiki, maintaining CI, helping people on Slack). Becoming a committer is about the trust built up by the committers not having to modify the action (PR, proposed-answer, proposed-wiki-change etc). Hen On Fri, Jun 15, 2018 at 12:26 AM, Marco de Abreu < marco.g.ab...@googlemail.com.invalid> wrote: > Hen, > > As you stated, it's of significance of how much a PR has to be changed as a > result of a review. I think this is what this project defines as quality. > > If people submit a bunch of PRs and we reviewers spend a lot of time on > every single one of them to give the contributors advice about how to do it > the right way, then that's a great contribution but doesn't really show > that the person is either up par with the standards of the project or > understood the design principles. In both cases they added value to the > project, but the bar would have been lowered if the reviewers didn't > intercept. Of course, there is always something people will have to > criticize as part of the review and that's natural. But what you are > describing here is basically that we should make people committers because > of the amount of value they added through the code. > > While that's a good way to look at it in general, it doesn't consider > important aspects: how much of this value has been added by the reviewer? > And what happens if that person starts merging other PRs. If a person who > is not up par with the standards of the project is granted permission to > merge pull requests and they merge them prematurely because they don't know > that things are wrong, then this is harming the project in the long term. > If more and more people with lower standards are granted permissions, we > will enter a downwards spiral. > > That's why I have to disagree that it's not about how often a PR has been > merged but rather about how often it has to be altered as result of our > reviews. > > -Marco > > Hen schrieb am Fr., 15. Juni 2018, 00:00: > > > On the 'Becoming+a+Committer' guidelines, I dislike this phrase: > > > > "When it comes to code contributions, quality is more important than > > quantity" > > > > There is only one 'quality' measurement, and that is "was the code > merged". > > If someone makes 10 different contributions and they were all horrible > and > > never merged (or the merger had to write a ton of fixes/tests/additions) > > then yes, that's a pretty bad sign. > > > > If the code was merged; I don't care if it's stunning code or an inspired > > design. It was merged. This isn't a technical promotion process, this is > > about whether the individual has shown the commitment to be extended the > > trust to manage commits. > > > > So; -1 to quality being more important than quantity. It's not. > > > > Hen > > > > > > > > On Fri, Jun 8, 2018 at 1:15 PM, Sheng Zha wrote: > > > > > Hi, > > > > > > There have been a couple of offline inquiries from contributors about > > > becoming a committer. From those inquiries, it seems that there’s > > confusion > > > in our community about how to become a committer, so I’d like to take > > this > > > opportunity to clarify. > > > > > > The guideline about becoming a committer can be found at > > > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer > . > > > The > > > gist of the guideline is that, like any other Apache project, MXNet > > > committers are invited by existing committers based on merit. The > > existing > > > committers look for sustained, high quality contribution and community > > > involvement among project contributors. When a candidate is spotted, > this > > > contributor will be nominated and voted among PMC members, and if all > > goes > > > well, this contributor will receive an invitation to join as a > committer > > > and PMC member. > > > > > > Note that such discussion and decision happens in private
Re: About Becoming a Committer
Hen, As you stated, it's of significance of how much a PR has to be changed as a result of a review. I think this is what this project defines as quality. If people submit a bunch of PRs and we reviewers spend a lot of time on every single one of them to give the contributors advice about how to do it the right way, then that's a great contribution but doesn't really show that the person is either up par with the standards of the project or understood the design principles. In both cases they added value to the project, but the bar would have been lowered if the reviewers didn't intercept. Of course, there is always something people will have to criticize as part of the review and that's natural. But what you are describing here is basically that we should make people committers because of the amount of value they added through the code. While that's a good way to look at it in general, it doesn't consider important aspects: how much of this value has been added by the reviewer? And what happens if that person starts merging other PRs. If a person who is not up par with the standards of the project is granted permission to merge pull requests and they merge them prematurely because they don't know that things are wrong, then this is harming the project in the long term. If more and more people with lower standards are granted permissions, we will enter a downwards spiral. That's why I have to disagree that it's not about how often a PR has been merged but rather about how often it has to be altered as result of our reviews. -Marco Hen schrieb am Fr., 15. Juni 2018, 00:00: > On the 'Becoming+a+Committer' guidelines, I dislike this phrase: > > "When it comes to code contributions, quality is more important than > quantity" > > There is only one 'quality' measurement, and that is "was the code merged". > If someone makes 10 different contributions and they were all horrible and > never merged (or the merger had to write a ton of fixes/tests/additions) > then yes, that's a pretty bad sign. > > If the code was merged; I don't care if it's stunning code or an inspired > design. It was merged. This isn't a technical promotion process, this is > about whether the individual has shown the commitment to be extended the > trust to manage commits. > > So; -1 to quality being more important than quantity. It's not. > > Hen > > > > On Fri, Jun 8, 2018 at 1:15 PM, Sheng Zha wrote: > > > Hi, > > > > There have been a couple of offline inquiries from contributors about > > becoming a committer. From those inquiries, it seems that there’s > confusion > > in our community about how to become a committer, so I’d like to take > this > > opportunity to clarify. > > > > The guideline about becoming a committer can be found at > > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer. > > The > > gist of the guideline is that, like any other Apache project, MXNet > > committers are invited by existing committers based on merit. The > existing > > committers look for sustained, high quality contribution and community > > involvement among project contributors. When a candidate is spotted, this > > contributor will be nominated and voted among PMC members, and if all > goes > > well, this contributor will receive an invitation to join as a committer > > and PMC member. > > > > Note that such discussion and decision happens in private among existing > > PMC members and mentors through consensus, and information regarding what > > happened in this process will always remain private, so as to rid the > > influence of different interest groups. PMC members will not ask > > contributors for committer application, nor will they accept one. Except > > the aforementioned PMC members consensus process, any other process by > any > > organization under any circumstances will not be recognized. > > > > I hope that you find the above clarification helpful. If you have further > > question on this topic feel free to ask. > > > > Sheng > > >
Re: About Becoming a Committer
On the 'Becoming+a+Committer' guidelines, I dislike this phrase: "When it comes to code contributions, quality is more important than quantity" There is only one 'quality' measurement, and that is "was the code merged". If someone makes 10 different contributions and they were all horrible and never merged (or the merger had to write a ton of fixes/tests/additions) then yes, that's a pretty bad sign. If the code was merged; I don't care if it's stunning code or an inspired design. It was merged. This isn't a technical promotion process, this is about whether the individual has shown the commitment to be extended the trust to manage commits. So; -1 to quality being more important than quantity. It's not. Hen On Fri, Jun 8, 2018 at 1:15 PM, Sheng Zha wrote: > Hi, > > There have been a couple of offline inquiries from contributors about > becoming a committer. From those inquiries, it seems that there’s confusion > in our community about how to become a committer, so I’d like to take this > opportunity to clarify. > > The guideline about becoming a committer can be found at > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer. > The > gist of the guideline is that, like any other Apache project, MXNet > committers are invited by existing committers based on merit. The existing > committers look for sustained, high quality contribution and community > involvement among project contributors. When a candidate is spotted, this > contributor will be nominated and voted among PMC members, and if all goes > well, this contributor will receive an invitation to join as a committer > and PMC member. > > Note that such discussion and decision happens in private among existing > PMC members and mentors through consensus, and information regarding what > happened in this process will always remain private, so as to rid the > influence of different interest groups. PMC members will not ask > contributors for committer application, nor will they accept one. Except > the aforementioned PMC members consensus process, any other process by any > organization under any circumstances will not be recognized. > > I hope that you find the above clarification helpful. If you have further > question on this topic feel free to ask. > > Sheng >
Re: About Becoming a Committer
On Tue, Jun 12, 2018 at 10:54 PM, Pedro Larroy wrote: > * I personally don't like the idea that comittership status is decided in a > closed mail list. This is not the transparency level that I would expect in > an open source project. I'm happy to receive feedback from others that > might be opposed to my application for committer to know what things could > be improved to get there. I have been doing a plethora of contributions to > the project over a year including ARM support, Android and CI, obviously > some of this work together with my team at Amazon (@lebeg, > @KellenSunderland, @marcoabreu). I don't have visibility on how much longer > one has to wait, or what needs to be improved to get there. > I agree in principle (which means I'm going to disagree, right? :) ). Ideally discussion about extending community trust would be made in public, however for many of us having that discussion in public is an uncomfortable act. A private channel for feedback is not about hiding information from the subject, but about creating a safe place in which someone can provide that feedback. I think you have a very valid and, slightly to the side, point of it not being clear what steps are needed/remaining to become a committer; which is affected by the podling pmc still seeking consensus on how they view it. > > * My team is on-call for CI / CD which is also sponsored by us. To fix > problems promptly we would need write permissions to the repository. This > would normal in any other project, be open source or corporate. I think > it's not effective to be on-call when you can't submit critical fixes and > wait days for a CR. Basically I think everyone responsible or involved in > CI should have access rights. As you know, testing our project is a > challenging task for reasons discussed before. > Personally I don't care. If the committers aren't handling the CI/CD then it's not important to the project. It's EXCELLENT that you and your team are contributing your time to run CI/CD for the project, but the notion that an open source project requires an on-call CI/CD is, in my opinion, the project having its priorities skewed. However, that said, I agree that if the project is unable to survive without the CI/CD, then it sounds far more important than whatever code is being committed and shows more commitment to the project than the creator of a piece of code. I'm pretty sure my opinion that the CI/CD is not crucial is heretical for this community. I suspect that if I said we should turn it off for a week there would be a wailing and gnashing of teeth from every corner of the mailing list. Given that, I think you earn more 'become committer points' by maintaining that CI/CD than someone does by coding. > Please committers and mentors, provide a solution that allows us to work > more effectively and move the project forward faster, as is vital to make > it easier to contribute so we can attract more users. > +1. The podling pmc needs to find consensus on the become-committer stage. Hen
Re: About Becoming a Committer
As an aside: if you want to learn more on the background of Apache, or free and open source in general join us at Http://fossbackstage.de in Berlin in walking distance from U2 stop Eberswalder Str. -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Re: About Becoming a Committer
Hi, I would like to share some inspiration: https://blogs.apache.org/foundation/entry/success-at-apache-jfdi-the I do believe in pulling people in quickly, in giving them responsibility early, on rewarding contributions in a timely manner. Apache was born out of a collaboration of people using a web server that was abandoned because they depended on it for their daily work. The mechanisms build into the ASF are based on the assumption that contributors work on projects based on their individual needs. On an on and off schedule - as time permits. Requiring to work full time on a project to show sufficient commitment doesn't allow for very many people to become committed to mxnet. It doesn't allow for the project to survive times where there is no sponsoring entity. People asking to have people desisions in public to me points to serious problems in the project. Isabel Am 13. Juni 2018 07:54:41 MESZ schrieb Pedro Larroy : >* I personally don't like the idea that comittership status is decided >in a >closed mail list. This is not the transparency level that I would >expect in >an open source project. I'm happy to receive feedback from others that >might be opposed to my application for committer to know what things >could >be improved to get there. I have been doing a plethora of contributions >to >the project over a year including ARM support, Android and CI, >obviously >some of this work together with my team at Amazon (@lebeg, >@KellenSunderland, @marcoabreu). I don't have visibility on how much >longer >one has to wait, or what needs to be improved to get there. > >* My team is on-call for CI / CD which is also sponsored by us. To fix >problems promptly we would need write permissions to the repository. >This >would normal in any other project, be open source or corporate. I think >it's not effective to be on-call when you can't submit critical fixes >and >wait days for a CR. Basically I think everyone responsible or involved >in >CI should have access rights. As you know, testing our project is a >challenging task for reasons discussed before. > >Please comitters and mentors, provide a solution that allows us to work >more effectively and move the project forward faster, as is vital to >make >it easier to contribute so we can attract more users. > >Pedro. > >On Tue, Jun 12, 2018 at 10:31 AM Yasser Zamani > >wrote: > >> >> >> On 6/9/2018 12:45 AM, Sheng Zha wrote: >> > There have been a couple of offline inquiries from contributors >about >> > becoming a committer. From those inquiries, it seems that there’s >> confusion >> > in our community about how to become a committer, so I’d like to >take >> this >> > opportunity to clarify. >> > >> > The guideline about becoming a committer can be found at >> > >https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer. >> >> I think that page at above link is great but the problem is new >visitors >> cannot find it quickly then they ask privately from you. I myself was >> looking for it at mxnet.incubator.apache.org, so clicked on >> "Community->Contribute", the I read all page then I saw a link to >wiki >> on page i.e. "MXNet Confluence Wiki: Development" where I guessed I >> might find something in wiki so clicked that. Then I saw "Becoming a >> Committer" in left side wiki's menu. >> >> I think we'll get fewer private inquiries on this if we add a direct >> link about it at >> https://mxnet.incubator.apache.org/community/contribute.html >> >> Regards. >> -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Re: About Becoming a Committer
* I personally don't like the idea that comittership status is decided in a closed mail list. This is not the transparency level that I would expect in an open source project. I'm happy to receive feedback from others that might be opposed to my application for committer to know what things could be improved to get there. I have been doing a plethora of contributions to the project over a year including ARM support, Android and CI, obviously some of this work together with my team at Amazon (@lebeg, @KellenSunderland, @marcoabreu). I don't have visibility on how much longer one has to wait, or what needs to be improved to get there. * My team is on-call for CI / CD which is also sponsored by us. To fix problems promptly we would need write permissions to the repository. This would normal in any other project, be open source or corporate. I think it's not effective to be on-call when you can't submit critical fixes and wait days for a CR. Basically I think everyone responsible or involved in CI should have access rights. As you know, testing our project is a challenging task for reasons discussed before. Please comitters and mentors, provide a solution that allows us to work more effectively and move the project forward faster, as is vital to make it easier to contribute so we can attract more users. Pedro. On Tue, Jun 12, 2018 at 10:31 AM Yasser Zamani wrote: > > > On 6/9/2018 12:45 AM, Sheng Zha wrote: > > There have been a couple of offline inquiries from contributors about > > becoming a committer. From those inquiries, it seems that there’s > confusion > > in our community about how to become a committer, so I’d like to take > this > > opportunity to clarify. > > > > The guideline about becoming a committer can be found at > > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer. > > I think that page at above link is great but the problem is new visitors > cannot find it quickly then they ask privately from you. I myself was > looking for it at mxnet.incubator.apache.org, so clicked on > "Community->Contribute", the I read all page then I saw a link to wiki > on page i.e. "MXNet Confluence Wiki: Development" where I guessed I > might find something in wiki so clicked that. Then I saw "Becoming a > Committer" in left side wiki's menu. > > I think we'll get fewer private inquiries on this if we add a direct > link about it at > https://mxnet.incubator.apache.org/community/contribute.html > > Regards. >
Re: About Becoming a Committer
On 6/9/2018 12:45 AM, Sheng Zha wrote: > There have been a couple of offline inquiries from contributors about > becoming a committer. From those inquiries, it seems that there’s confusion > in our community about how to become a committer, so I’d like to take this > opportunity to clarify. > > The guideline about becoming a committer can be found at > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer. I think that page at above link is great but the problem is new visitors cannot find it quickly then they ask privately from you. I myself was looking for it at mxnet.incubator.apache.org, so clicked on "Community->Contribute", the I read all page then I saw a link to wiki on page i.e. "MXNet Confluence Wiki: Development" where I guessed I might find something in wiki so clicked that. Then I saw "Becoming a Committer" in left side wiki's menu. I think we'll get fewer private inquiries on this if we add a direct link about it at https://mxnet.incubator.apache.org/community/contribute.html Regards.
Re: About Becoming a Committer
I guess you should add instructions about speaking on various event like conf., meetups - to present the whole project team. On Fri, Jun 8, 2018 at 11:15 PM, Sheng Zha wrote: > Hi, > > There have been a couple of offline inquiries from contributors about > becoming a committer. From those inquiries, it seems that there’s confusion > in our community about how to become a committer, so I’d like to take this > opportunity to clarify. > > The guideline about becoming a committer can be found at > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer. > The > gist of the guideline is that, like any other Apache project, MXNet > committers are invited by existing committers based on merit. The existing > committers look for sustained, high quality contribution and community > involvement among project contributors. When a candidate is spotted, this > contributor will be nominated and voted among PMC members, and if all goes > well, this contributor will receive an invitation to join as a committer > and PMC member. > > Note that such discussion and decision happens in private among existing > PMC members and mentors through consensus, and information regarding what > happened in this process will always remain private, so as to rid the > influence of different interest groups. PMC members will not ask > contributors for committer application, nor will they accept one. Except > the aforementioned PMC members consensus process, any other process by any > organization under any circumstances will not be recognized. > > I hope that you find the above clarification helpful. If you have further > question on this topic feel free to ask. > > Sheng >
