community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject RE: Beam's recent community development work
Date Tue, 03 Jul 2018 03:27:16 GMT
There is one insight here that I particularly like and I believe helps me find a good compromise
that I’ve struggled with for years. I’m a fan of CTR rather than RTC for committers. However,
I recognize that a number of projects don’t share my views on this. I ***love*** your solution
and will quote it in case people missed it because you said “As a minor point” – I think
it is a key point:


“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.”


I like your overall process, but I especially applaud this insight – thank you beam community.





From: Kenneth Knowles <> 
Sent: Monday, July 2, 2018 4:47 PM
To: dev <>
Cc:;; Griselda Cuevas <>
Subject: Re: Beam's recent community development work


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.




On Sat, Jun 30, 2018 at 8:45 AM Ted Dunning < <>
> wrote:




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


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 < <>
> wrote:

Hi all,


The ASF board suggested that we (Beam) share some of what we've been doing for community development
with <>  and
<> . So here is a long description. I have included
<>  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!





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