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?
>> >>>
>>
