To add to this, Andrew Wong of the HDFS team mentioned that he will be putting out a wiki very similar to this.
Chatting with him privately, he mentioned there was a lot more to say on the topic at the panel but they ran out of time. So it would be worth going through that once he releases it to see if there's more we could learn from it. On Aug 4, 2016 2:28 PM, "Tim Armstrong" <[email protected]> wrote: > I agree that we shouldn't be too concerned about the risk of rogue commits > - between version control and code review it's unlikely to happen (without > violating other rules and norms of the project) and is easily reverted. > > I think the general criteria is that someone has made a significant > contribution to the project and has demonstrated an ability to work well > with the community, within the rules and norms of the project. It might be > easiest to give specific examples of some specific roles. > > E.g.someone could become a committer based on code contributions if they > have a solid history of code contribution (a few large patches, more > smaller patches) and can effectively shepherd their patches through code > review (i.e. post a good-quality initial patch and work well with the > reviewers to address concerns). > > With docs contributors, it would similarly be based on a solid history of > docs contributions and ability to work with the review process. > > Outside of that, we could also look at history of contributing to project > discussions and giving constructive feedback on JIRAs, code reviews, and > other project decision-making. > > On Thu, Aug 4, 2016 at 11:14 AM, Jim Apple <[email protected]> wrote: > > > I'd like to make a wiki page on what the criteria are for becoming an > > official Impala committer. Before doing so, I thought we could talk > > about what should go in that page. > > > > I went to a talk by some experienced ASF people on other projects > > (Spark, Hadoop, etc.) who said: > > > > 1. Every committer should be "an easy person to work with". > > > > 2. One mitigating factor to the risk of adding a new committer is that > > committers rarely go overboard and start committing code that is > > beyond their expertise. > > > > 3. Some projects want committers to be an expert in one area of the code. > > > > 4. Other people have the view that someone should be voted into a > > committer once it saves time to make them a committer. Making someone > > a committer can save time in a few ways: for instance, they can take > > on more responsibility, taking some work off the shoulders of the > > other committers. > > > > 5. Many projects will make someone a committer, or even a PMC member, > > if they are not committing new features but instead are contributing > > by filing bugs, triaging bugs, reviewing code, writing documentation, > > and so on. > > > > My plan for this [DISCUSS] thread is that we can chat for a while if > > anyone disagrees with any of these or wants to add something else. > > Once the thread quiets down, I'll write the wiki page and send the > > link to ts thread. After that, anyone with a wiki account will be able > > edit the page. > > > > Thoughts? > > >
