Mailing-List: contact dev-help@impala.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@impala.incubator.apache.org
MIME-Version: 1.0
In-Reply-To: <CADZba-Q=oN5+s8A9piZR1NTqkrwEtq47Mq_KGGNjzxgnfi_P6Q@mail.gmail.com>
References: <CAC-pSX0Pq9__YP7vFTYdzR9GEyuT+4BejzL1eyi9t65X21THjg@mail.gmail.com>
 <CAEoRBewzbPBhkbjbhMCd05Kg_4BZFNni73e=XJkirceO8odOXw@mail.gmail.com>
 <CAM7YqvMziyc-RvHLpOe4V8yY1jExNGmE4-6oTYORw=whLdtUzw@mail.gmail.com>
 <CAC-pSX14Na7tkn96uMmXy1mYD1u3GBmhjtUbd8n7FGuyJE0i+A@mail.gmail.com>
 <CAEoRBewYd9Jucgu-DTp0Ey2C95V6iwqn+3eaB8gFAA+GROONcQ@mail.gmail.com>
 <CAC-pSX2QCLvt0RyO-=RG+iDGLiqL-OUDLRRoit==7Ykiu_xdxg@mail.gmail.com> <CADZba-Q=oN5+s8A9piZR1NTqkrwEtq47Mq_KGGNjzxgnfi_P6Q@mail.gmail.com>
From: Jim Apple <jbapple@cloudera.com>
Date: Fri, 19 Aug 2016 16:12:43 -0700
Message-ID: <CAC-pSX2uVUAqfSuGyhBmCY9XypaTCX5+3APZE9NGgC7NewfD_w@mail.gmail.com>
Subject: Re: [DISCUSS] Criteria for becoming a committer
To: "dev@impala" <dev@impala.incubator.apache.org>
Content-Type: text/plain; charset=UTF-8
archived-at: Fri, 19 Aug 2016 23:13:29 -0000

https://cwiki.apache.org/confluence/display/IMPALA/Committer+Criteria

Feel free to edit.

On Mon, Aug 8, 2016 at 12:36 PM, Henry Robinson <henry@cloudera.com> 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 <jbapple@cloudera.com> 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 <tarmstrong@cloudera.com>
>> 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 <jbapple@cloudera.com> 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 <marcel@cloudera.com>
>> >> wrote:
>> >> > On Thu, Aug 4, 2016 at 2:28 PM, Tim Armstrong <
>> tarmstrong@cloudera.com>
>> >> 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 <jbapple@cloudera.com>
>> >> 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