impala-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henry Robinson <he...@cloudera.com>
Subject Re: [DISCUSS] Criteria for becoming a committer
Date Mon, 08 Aug 2016 19:36:57 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message