community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Fogel <kfo...@red-bean.com>
Subject Re: Beam's recent community development work
Date Tue, 10 Jul 2018 19:56:13 GMT
Ted Dunning <ted.dunning@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 <klk@google.com>
  Subject: Beam's recent community development work
  To: dev@community.apache.org, members@apache.org,  Griselda Cuevas <gris@apache.org>,
dev <dev@beam.apache.org>
  Date: Fri, 29 Jun 2018 23:15:02 -0700
  Reply-To: members@apache.org
  Message-ID: <CAN_Ypr3PAV9mcLcaq=qj6+_S5Cr-aX6qwoZ=rjHYb8w+KWEgcA@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 <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/
>   

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org


Mime
View raw message