Ted Dunning <ted.dunn...@gmail.com> writes: >Dang. I missed that. >Ross is exactly right here. GREAT idea. >I am going to push this all over.
+1 -- it's a great idea, and IMHO not a minor point at all. Kenneth, are you planning to turn your email into a blog post or other easily-pointable-at-on-the-web thing? I'm referring to your original email... From: Kenneth Knowles <k...@google.com> Subject: Beam's recent community development work To: dev@community.apache.org, memb...@apache.org, Griselda Cuevas <g...@apache.org>, dev <d...@beam.apache.org> Date: Fri, 29 Jun 2018 23:15:02 -0700 Reply-To: memb...@apache.org Message-ID: <CAN_Ypr3PAV9mcLcaq=qj6+_S5Cr-aX6qwoZ=rjhyb8w+kwe...@mail.gmail.com> ...of course with whatever feedback (e.g., Ted's) incorporated that you want. Best regards, -Karl >On Mon, Jul 2, 2018 at 8:27 PM <r...@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 <k...@google.com> > Sent: Monday, July 2, 2018 4:47 PM > To: dev <d...@beam.apache.org> > Cc: memb...@apache.org; dev@community.apache.org; Griselda Cuevas > <g...@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.dunn...@gmail.com <mailto: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 > <mailto: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 <mailto:dev@community.apache.org> and > memb...@apache.org <mailto:memb...@apache.org> . So here is a > long description. I have included d...@beam.apache.org <mailto: > 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/ > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
