Ok, that makes sense to me as long as we're proactive about encouraging people in that situation to do code reviews.
On Mon, Aug 8, 2016 at 11:42 AM, Todd Lipcon <[email protected]> wrote: > 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. > > > > While I partially agree with you that it's difficult for new contributors > to do code reviews, I also agree with Marcel that showing the ability to do > good reviews is important for those with development roles in the project. > > One thing that the Hadoop PMC tries to do is to watch for new contributors > who are becoming active and have private 'DISCUSS' threads about them (even > before they're really ready for committership). Usually the output of such > a private thread is comments such as "the person writes good code but > hasn't done any thorough reviews". A PMC member then usually volunteers to > mentor the person, which would start with relaying this feedback to the > contributor -- letting them know that they're on the way towards > committership but that the PMC would like to see more code reviews from > them. > > In my experience this kind of 1-on-1 attention to grow new contributors can > offset any fear they might have around reviewing without the official > committership bit granted. > > -Todd > > > > > > 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? > > > >>> > > > > > > > > > -- > Todd Lipcon > Software Engineer, Cloudera >
