encouraging and cultivating new committers

[Ted Dunning <te...@gmail.com>]

I have been thinking about what makes good committer process lately and
wanted to share my thoughts and gather feedback from others.

Please comment!

Over the last 6 months or so, the way that Apache Beam recruits and
encourages a wide range of committers has been highlighted and widely
admired in various parts of Apache.

There are a couple of aspects of how this goes in Beam that merit some
interesting discussion and I think that adopting some of these ideas in
Drill could be really useful.

First off, there is some really nice documentation about the contributions
that can lead to committer status. See here:
https://beam.apache.org/contribute/become-a-committer/

Secondly, there is a very interesting process in which early contributors
are encouraged to progress in the project and to stick around. This takes
the form of an encouraging email on the event of very early contributions,
as well as another dialog that is started once a contributor starts making
repeated contributions. The first encouragement just makes sense, but the
second dialog is much more subtle. What happens is that the newly
productive contributor is told about the committer process (and what
committership means) and is told that their first few contributions have
been noticed and are being watched by the PMC with interest. They are
pointed at the committer guide so that they can see if there are other
kinds of contributions that they could make that would be of real interest
to the project. One (or more) of the PMC are appointed to serve as a mentor
for each such potential committer. The role of the mentor is to answer
questions about Apache and to encourage the potential committer.

One dangerous tendency in this encouragement is that it can be interpreted
as a strict bar to be passed or that it is like an exam of some kind. Such
a committer test is widely frowned on in the Apache Foundation, but good
encouragement is widely considered very good. This is a thin line.

One lesson that Beam has learned well and which is not a new concept at all
is that it is very important to recognize a few facts:

- giving somebody committer status has nearly no risk for the project

- giving somebody committer status, especially if it is their first Apache
project is a HUGE emotional boost that helps bind people to the project

- having too many inactive committers has almost no effect on a project

This means that it is usually better to lower the bar for nominating a
committer rather than raise it. There is little risk and lots of potential
benefit.

Re: encouraging and cultivating new committers

[Aman Sinha <am...@gmail.com>]

Beam has a good set of guidelines and certainly some thought has gone into
articulating these to the community.
I generally agree with these and in particular the use of the word
'earnestly' in the following:


   - *They earnestly try to make Beam better with their contributions*
   - *In particular, if a code contributor:*
      - *They earnestly try to make Beam better with their own code*
      - *They earnestly try to make Beam better with code review*

The way I would interpret is the person is going an extra distance to
improve the project.  This is easier to check for coding
contributions but gets muddier for non-coders. Suppose someone is doing
testing, it is not sufficient to file a JIRA with the
errors or even with sample data.  An 'earnest' effort would be to do some
more analysis, perhaps look at the profile and/or the drillbit.log file.
Does the error occur with only TimeStamp data types or is it more generic
?
If there is an out-of-memory,  which operator might be a potential culprit
? (based on the query profile) ..
  etc.

Similarly, for documentation, I would encourage a contributor who wants to
become a committer to 'go the extra distance' .. a good example
is an early doc person - Kristine - who is not active anymore.  She became
a committer because she was quite diligent about answering StackOverflow
questions or questions on the user list and if she did not know the answer
she would try to find out from developers.    Also, submitting sample data
and
example queries / scripts etc  to improve the documentation is a great way
to showcase the effort.

I agree that an encouraging email from a PMC member would help in getting
more contributors  excited about contributing further.  These can be
evaluated on a case-by-case basis.

-Aman


On Fri, May 10, 2019 at 5:02 PM Ted Dunning <te...@gmail.com> wrote:

> I have been thinking about what makes good committer process lately and
> wanted to share my thoughts and gather feedback from others.
>
> Please comment!
>
> Over the last 6 months or so, the way that Apache Beam recruits and
> encourages a wide range of committers has been highlighted and widely
> admired in various parts of Apache.
>
> There are a couple of aspects of how this goes in Beam that merit some
> interesting discussion and I think that adopting some of these ideas in
> Drill could be really useful.
>
> First off, there is some really nice documentation about the contributions
> that can lead to committer status. See here:
> https://beam.apache.org/contribute/become-a-committer/
>
> Secondly, there is a very interesting process in which early contributors
> are encouraged to progress in the project and to stick around. This takes
> the form of an encouraging email on the event of very early contributions,
> as well as another dialog that is started once a contributor starts making
> repeated contributions. The first encouragement just makes sense, but the
> second dialog is much more subtle. What happens is that the newly
> productive contributor is told about the committer process (and what
> committership means) and is told that their first few contributions have
> been noticed and are being watched by the PMC with interest. They are
> pointed at the committer guide so that they can see if there are other
> kinds of contributions that they could make that would be of real interest
> to the project. One (or more) of the PMC are appointed to serve as a mentor
> for each such potential committer. The role of the mentor is to answer
> questions about Apache and to encourage the potential committer.
>
> One dangerous tendency in this encouragement is that it can be interpreted
> as a strict bar to be passed or that it is like an exam of some kind. Such
> a committer test is widely frowned on in the Apache Foundation, but good
> encouragement is widely considered very good. This is a thin line.
>
> One lesson that Beam has learned well and which is not a new concept at all
> is that it is very important to recognize a few facts:
>
> - giving somebody committer status has nearly no risk for the project
>
> - giving somebody committer status, especially if it is their first Apache
> project is a HUGE emotional boost that helps bind people to the project
>
> - having too many inactive committers has almost no effect on a project
>
> This means that it is usually better to lower the bar for nominating a
> committer rather than raise it. There is little risk and lots of potential
> benefit.
>