https://cwiki.apache.org/confluence/display/IMPALA/Committer+Criteria
Feel free to edit. On Mon, Aug 8, 2016 at 12:36 PM, Henry Robinson <[email protected]> wrote: > I don't think it should have either. Productivity is not so easily > measured. Provide some guidance in this document about what the PMC is > likely looking for, but don't aim for an objective set of checkboxes. > > Fine to say "involved with the project for a sustained period, usually > around 6 months". I'd suggest staying away from any other metrics. > > On 8 August 2016 at 12:27, Jim Apple <[email protected]> wrote: > >> Do you have any ideas on how to be more specific on what "sustained >> contributions" could look like for non-code writers? >> >> Do you think it should have a time frame ("3 months of docs writing") >> or a quota ("17 confirmed bugs found")? >> >> On Mon, Aug 8, 2016 at 11:36 AM, Tim Armstrong <[email protected]> >> wrote: >> > "easy to work with && sustained contributions" sounds reasonable to me >> as >> > long as we have a couple of examples of what would meet this bar (it's a >> > bit vague otherwise) >> > >> > RE: the code review requirement. My feeling is that a history of code >> > reviews is a strong positive factor, but it shouldn't block someone from >> > committership if they have a history of submitting high-quality patches. >> > >> > I think a lot of contributors won't feel like they have a license to do >> > (thorough) code reviews if they don't have any formal status in the >> > project. Especially if most patches are coming from committers, it takes >> a >> > great deal of confidence for someone with no formal status in the project >> > to review a patch from a committers and block it from going in until it's >> > good enough. IMO we don't want to restrict committership to this subset >> of >> > people. >> > >> > On Mon, Aug 8, 2016 at 10:49 AM, Jim Apple <[email protected]> wrote: >> > >> >> Does anyone have thoughts about how, exactly, to evaluate non-code >> >> contributions? >> >> >> >> What criteria should Apache Impala use to evaluate contributors for >> >> committership if they have not committed any code? >> >> >> >> "easy to work with && sustained contributions"? >> >> >> >> >> >> >> >> On Mon, Aug 8, 2016 at 10:22 AM, Marcel Kornacker <[email protected]> >> >> wrote: >> >> > On Thu, Aug 4, 2016 at 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). >> >> > >> >> > Regarding the code contributions criterion: I would like to add to >> >> > that a requirement for a history of solid code reviews, ie, the person >> >> > can effectively shepherd other people's patches through code review >> >> > and maintain the integrity of the codebase. Writing code and reviewing >> >> > code go hand-in-hand. >> >> > >> >> >> >> >> >> 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? >> >> >>> >> >> >> > > > > -- > Henry Robinson > Software Engineer > Cloudera > 415-994-6679
