community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: Beam's recent community development work
Date Tue, 03 Jul 2018 03:37:00 GMT
Dang. I missed that.

Ross is exactly right here. GREAT idea.

I am going to push this all over.



On Mon, Jul 2, 2018 at 8:27 PM <ross@gardler.org> wrote:

> 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.
>
>
>
> Ross
>
>
>
>
>
> From: Kenneth Knowles <klk@google.com>
> Sent: Monday, July 2, 2018 4:47 PM
> To: dev <dev@beam.apache.org>
> Cc: members@apache.org; dev@community.apache.org; Griselda Cuevas <
> gris@apache.org>
> 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.
>
>
>
> Kenn
>
>
>
> On Sat, Jun 30, 2018 at 8:45 AM Ted Dunning <ted.dunning@gmail.com
> <mailto:ted.dunning@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 <klk@google.com <mailto:
> klk@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 <mailto:
> dev@community.apache.org>  and members@apache.org <mailto:
> members@apache.org> . So here is a long description. I have included
> dev@beam.apache.org <mailto:dev@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/
>
>

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