Thanks for the guidance Ted,

All of your points are well taken. I/we will definitely stay careful about
phrasing encouragement emails and our guidelines.

Kenn

On Sat, Jun 30, 2018 at 8:45 AM Ted Dunning <ted.dunn...@gmail.com> wrote:

>
> Ken,
>
> This is really good.
>
> I would like to emphasize one nuance, however. That is that when you get
> to the committer consideration step, there is a strong Apache tradition
> that the actual decision about committer-ship is not communicated to the
> candidate to avoid disappointment or campaigning during the vote.
>
> What you have could veer close to that, but I think that what you actually
> have in mind is just fine. I think that there could be a few tweaks to your
> process to emphasize how your efforts are OK.
>
> 1) when you contact a person and mention committer progress, please
> emphasize that it is a bit more like "your efforts have been noticed and
> appreciated. More of that sort of effort is something that often leads to
> becoming a committer. That actual process is confidential, however, so you
> won't know if or when it happens unless you get an invitation to become a
> committer"
>
> 2) the part about "do you want to become one, do you want feedback?" is
> golden just the way it is.
>
> 3) you mention "committer guidelines". This can be dangerous if it gets
> viewed as an application form or committer status checklist. This is a hard
> problem because it helps the PMC to have a list of things that are
> considered good qualities of a committer. I recommend keeping this danger
> in mind when composing emails to candidate committers. Above all else, try
> to avoid having the equivalent of an application form.
>
> Overall, I think that your results speak for themselves. Well done.
>
>
>
> On Fri, Jun 29, 2018 at 11:15 PM Kenneth Knowles <k...@google.com> wrote:
>
>> Hi all,
>>
>> The ASF board suggested that we (Beam) share some of what we've been
>> doing for community development with dev@community.apache.org and
>> memb...@apache.org. So here is a long description. I have included
>> d...@beam.apache.org because it is the subject, really, and this is &
>> should be all public knowledge.
>>
>> We would love feedback! We based a lot of this on reading the community
>> project site, and probably could have learned even more with more study.
>>
>> # Background
>>
>> We face two problems in our contributor/committer-base:
>>
>> 1. Not enough committers to review all the code being contributed, in
>> part due to recent departure of a few committers
>> 2. We want our contributor-base (hence committer-base) to be more spread
>> across companies and backgrounds, for the usual Apache reasons. Our user
>> base is not active and varied enough to make this automatic. One solution
>> is to make the right software to get a varied user base, but that is a
>> different thread :-) so instead we have to work hard to build our community
>> around the software we have.
>>
>> # What we did
>>
>> ## Committer guidelines
>>
>> We published committer guidelines [1] for transparency and as an
>> invitation. We start by emphasizing that there are many kinds of
>> contributions, not just code (we have committers from community
>> development, tech writing, training, etc). Then we have three aspects:
>>
>> 1. ASF code of conduct
>> 2. ASF committer responsibilities
>> 3. Beam-specific committer responsibilities
>>
>> The best way to understand is to follow the link at the bottom of this
>> email. The important part is that you shouldn't be proposing a committer
>> for other reasons, and you shouldn't be blocking a committer for other
>> reasons.
>>
>> ## Instead of just "[DISCUSS] Potential committer XYZ" we discuss every
>> layer
>>
>> Gris (CC'd) outlined this: people go through these phases of relationship
>> with our project:
>>
>> 1. aware of it
>> 2. interested in it / checking it out
>> 3. using it for real
>> 4. first-time contributor
>> 5. repeat contributor
>> 6. committer
>> 7. PMC
>>
>> As soon as we notice someone, like a user asking really deep questions,
>> we invite discussion on private@ on how we can move them to the next
>> level of engagement.
>>
>> ## Monthly cadence
>>
>> Every ~month, we call for new discussions and revisit ~all prior
>> discussions. This way we do not forget to keep up this effort.
>>
>> ## Individual discussions
>>
>> For each person we have a separate thread on private@. This ensures we
>> have quality focused discussions that lead to feedback. In collective
>> discussions that we used to do, we often didn't really come up with
>> actionable feedback and ended up not even contacting potential committers
>> to encourage them. And consensus was much less clear.
>>
>> ## Feedback!
>>
>> If someone is brought up for a discussion, that means they got enough
>> attention that we hope to engage them more. But unsolicited feedback is
>> never a good idea. For a potential committer, we did this:
>>
>> 1. Send an email saying something like "you were discussed as a potential
>> committer - do you want to become one? do you want feedback?"
>> 2. If they say yes (so far everyone) we send a few bullet points from the
>> discussion and *most important* tie each bullet to the committer
>> guidelines. If we have no feedback about which guidelines were a concern,
>> that is a red flag that we are being driven by bias.
>>
>> We saw a *very* significant increase in engagement from those we sent
>> feedback to, and the trend is that they almost all will become committers
>> over time.
>>
>> ## Results
>>
>>  - Q1 we had no process and we added no new committers or PMC members.
>>  - Q2 when we tried these new things we added 7 committers and 1 PMC
>> member, with ~3~4 obvious committer candidates for next time around, plus
>> positive feedback from other contributors, spread across five companies.
>>
>> We've had a pretty major uptick in building Beam as a result.
>>
>> ## Review-then-commit
>>
>> We are dedicated to RTC as the best way to build software. Reviews not
>> only make the code better, but (with apologies to ASF/GNU differences) as
>> RMS says "The fundamental act of friendship among programmers is the
>> sharing of programs" and reviews are where we do that.
>>
>> As a minor point, we also changed our "review-then-commit" policy to
>> require that *either* the reviewer or the author be a committer. Previously
>> the reviewer had to be a committer. Rationale: if we trust someone as a
>> committer, we should trust their choice of reviewer. This also helps the
>> community, as it engages non-committers as reviewers.
>>
>> ----
>>
>> If you made it through this long email, thanks for reading!
>>
>> Kenn
>>
>> [1] https://beam.apache.org/contribute/become-a-committer/
>>
>

Reply via email to