You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beam.apache.org by Kenneth Knowles <kl...@google.com> on 2018/06/30 06:15:02 UTC

Beam's recent community development work

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
members@apache.org. So here is a long description. I have included
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/

Re: Beam's recent community development work

Posted by Marco de Abreu <ma...@googlemail.com.INVALID>.
Very interesting! I especially like the different levels of engagement and
beam committers actively engaging potential committers to mentor them
towards reaching the next level. This fact together with the feedback loop
sounds like a very promising and encouraging system.

Thanks a lot Yasser and Kenneth for sharing it!

-Marco


Yasser Zamani <ya...@apache.org> schrieb am Sa., 30. Juni 2018,
10:20:

> Thank you very much Kenneth, they're nice points!
>
> Regards.
>
> On 6/30/2018 10:45 AM, Kenneth Knowles 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
> > members@apache.org. So here is a long description. I have included
> > 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/
> >
>

Re: Beam's recent community development work

Posted by Marco de Abreu <ma...@googlemail.com.INVALID>.
Very interesting! I especially like the different levels of engagement and
beam committers actively engaging potential committers to mentor them
towards reaching the next level. This fact together with the feedback loop
sounds like a very promising and encouraging system.

Thanks a lot Yasser and Kenneth for sharing it!

-Marco


Yasser Zamani <ya...@apache.org> schrieb am Sa., 30. Juni 2018,
10:20:

> Thank you very much Kenneth, they're nice points!
>
> Regards.
>
> On 6/30/2018 10:45 AM, Kenneth Knowles 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
> > members@apache.org. So here is a long description. I have included
> > 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/
> >
>

Re: Beam's recent community development work

Posted by Marco de Abreu <ma...@googlemail.com>.
Very interesting! I especially like the different levels of engagement and
beam committers actively engaging potential committers to mentor them
towards reaching the next level. This fact together with the feedback loop
sounds like a very promising and encouraging system.

Thanks a lot Yasser and Kenneth for sharing it!

-Marco


Yasser Zamani <ya...@apache.org> schrieb am Sa., 30. Juni 2018,
10:20:

> Thank you very much Kenneth, they're nice points!
>
> Regards.
>
> On 6/30/2018 10:45 AM, Kenneth Knowles 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
> > members@apache.org. So here is a long description. I have included
> > 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/
> >
>

Re: Beam's recent community development work

Posted by Yasser Zamani <ya...@apache.org>.
Thank you very much Kenneth, they're nice points!

Regards.

On 6/30/2018 10:45 AM, Kenneth Knowles 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
> members@apache.org. So here is a long description. I have included
> 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/
>

Re: Beam's recent community development work

Posted by Matei Zaharia <ma...@gmail.com>.
I think telling people that they’re being considered as committers early on is a good idea, but AFAIK we’ve always had individual committers do that with contributors who were doing great work in various areas. We don’t have a centralized process for it though — it’s up to whoever wants to work with each contributor.

Matei

> On Jul 2, 2018, at 5:35 PM, Reynold Xin <rx...@databricks.com> wrote:
> 
> That's fair, and it's great to find high quality contributors. But I also feel the two projects have very different background and maturity phase. There are 1300+ contributors to Spark, and only 300 to Beam, with the vast majority of contributions coming from a single company for Beam (based on my cursory look at the two pages of commits on github). With the recent security and correctness storms, I actually worry about more quality (which requires more infrastructure) than just people adding more code to the project.
> 
> 
> 
> On Mon, Jul 2, 2018 at 5:25 PM Holden Karau <ho...@pigscanfly.ca> wrote:
> As someone who floats a bit between both projects (as a contributor) I'd love to see us adopt some of these techniques to be pro-active about growing our committer-ship (I think perhaps we could do this by also moving some of the newer committers into the PMC faster so there are more eyes out looking for people to bring forward)?
> 
> On Mon, Jul 2, 2018 at 4:54 PM, Sean Owen <sr...@apache.org> wrote:
> Worth, I think, a read and consideration from Spark folks. I'd be interested in comments; I have a few reactions too.
> 
> 
> ---------- Forwarded message ---------
> From: Kenneth Knowles <kl...@google.com>
> Date: Sat, Jun 30, 2018 at 1:15 AM
> Subject: Beam's recent community development work
> To: <de...@community.apache.org>, <me...@apache.org>, Griselda Cuevas <gr...@apache.org>, dev <de...@beam.apache.org>
> 
> 
> 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 members@apache.org. So here is a long description. I have included 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/
> 
> 
> 
> -- 
> Twitter: https://twitter.com/holdenkarau


---------------------------------------------------------------------
To unsubscribe e-mail: dev-unsubscribe@spark.apache.org

Re: Beam's recent community development work

Posted by Reynold Xin <rx...@databricks.com>.
That's fair, and it's great to find high quality contributors. But I also
feel the two projects have very different background and maturity phase.
There are 1300+ contributors to Spark, and only 300 to Beam, with the vast
majority of contributions coming from a single company for Beam (based on
my cursory look at the two pages of commits on github). With the recent
security and correctness storms, I actually worry about more quality (which
requires more infrastructure) than just people adding more code to the
project.



On Mon, Jul 2, 2018 at 5:25 PM Holden Karau <ho...@pigscanfly.ca> wrote:

> As someone who floats a bit between both projects (as a contributor) I'd
> love to see us adopt some of these techniques to be pro-active about
> growing our committer-ship (I think perhaps we could do this by also moving
> some of the newer committers into the PMC faster so there are more eyes out
> looking for people to bring forward)?
>
> On Mon, Jul 2, 2018 at 4:54 PM, Sean Owen <sr...@apache.org> wrote:
>
>> Worth, I think, a read and consideration from Spark folks. I'd be
>> interested in comments; I have a few reactions too.
>>
>>
>> ---------- Forwarded message ---------
>> From: Kenneth Knowles <kl...@google.com>
>> Date: Sat, Jun 30, 2018 at 1:15 AM
>> Subject: Beam's recent community development work
>> To: <de...@community.apache.org>, <me...@apache.org>, Griselda Cuevas <
>> gris@apache.org>, dev <de...@beam.apache.org>
>>
>>
>> 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
>> members@apache.org. So here is a long description. I have included
>> 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/
>>
>
>
>
> --
> Twitter: https://twitter.com/holdenkarau
>

Re: Beam's recent community development work

Posted by Holden Karau <ho...@pigscanfly.ca>.
As someone who floats a bit between both projects (as a contributor) I'd
love to see us adopt some of these techniques to be pro-active about
growing our committer-ship (I think perhaps we could do this by also moving
some of the newer committers into the PMC faster so there are more eyes out
looking for people to bring forward)?

On Mon, Jul 2, 2018 at 4:54 PM, Sean Owen <sr...@apache.org> wrote:

> Worth, I think, a read and consideration from Spark folks. I'd be
> interested in comments; I have a few reactions too.
>
>
> ---------- Forwarded message ---------
> From: Kenneth Knowles <kl...@google.com>
> Date: Sat, Jun 30, 2018 at 1:15 AM
> Subject: Beam's recent community development work
> To: <de...@community.apache.org>, <me...@apache.org>, Griselda Cuevas <
> gris@apache.org>, dev <de...@beam.apache.org>
>
>
> 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
> members@apache.org. So here is a long description. I have included
> 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/
>



-- 
Twitter: https://twitter.com/holdenkarau

Fwd: Beam's recent community development work

Posted by Sean Owen <sr...@apache.org>.
Worth, I think, a read and consideration from Spark folks. I'd be
interested in comments; I have a few reactions too.

---------- Forwarded message ---------
From: Kenneth Knowles <kl...@google.com>
Date: Sat, Jun 30, 2018 at 1:15 AM
Subject: Beam's recent community development work
To: <de...@community.apache.org>, <me...@apache.org>, Griselda Cuevas <
gris@apache.org>, dev <de...@beam.apache.org>


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
members@apache.org. So here is a long description. I have included
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/

Re: Beam's recent community development work

Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Jan 4, 2019 at 10:35 PM Kenneth Knowles <ke...@apache.org> wrote:
> On Wed, Oct 31, 2018 at 8:51 AM Bertrand Delacretaz <bd...@apache.org>
> wrote:
> >... Feel free to draft your blog post and we can then review and publish!
> I've drafted it....

Thank you, I reviewed [1] and it looks great to me!

I have just 3 minor comments:

-Add a link to the committer guidelines that you mention
-IIUC when you say "Every ~month" it means "about every month" - that
was not obvious to me initially
-for RTC and CTR you might link to
https://www.apache.org/foundation/glossary.html

-Bertrand

[1] https://blogs.apache.org/roller-ui/authoring/preview/comdev/?previewEntry=an-approach-to-community-building

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

Re: Beam's recent community development work

Posted by Shane Curcuru <as...@shanecurcuru.org>.
Kenneth Knowles wrote on 2/22/19 12:31 AM:
> Re-reading the earlier feedback and starting point, it sounds like:
> 
>  - the post was generally approved of, assuming comments were addressed
>  - there's not an established process for this sort of thing
>  - the PMC agreed to give me authoring access
> 
> So I will suggest that lazy consensus is good here. I will wait a bit
> longer, but would love to hit "publish" before the weekend.

Yes, please just publish.  I'll even say +1!  But this is just a blog
post that people have had plenty of time to review, so go do it!

Last-minute ideas:

- You might link to another article on the contributor funnel, to
provide readers with a broader perspective.  This is becoming a popular
concept for focusing on project growth:


https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/

- I don't know if you want to briefly introduce the RTC paragraph.  It
feels like it suddenly shows up after all the points about how you work
to encourage people.  It's definitely a good ending - especially how it
ties into engaging newcomers who do reviews - but doesn't quite flow.

Feel free to ignore those suggestions and just publish, too. 8-)

-- 

- Shane
  Director & Member
  The Apache Software Foundation

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

Re: Beam's recent community development work

Posted by Kenneth Knowles <ke...@apache.org>.
Re-reading the earlier feedback and starting point, it sounds like:

 - the post was generally approved of, assuming comments were addressed
 - there's not an established process for this sort of thing
 - the PMC agreed to give me authoring access

So I will suggest that lazy consensus is good here. I will wait a bit
longer, but would love to hit "publish" before the weekend.

Kenn


On Sun, Feb 10, 2019 at 1:54 PM Kenneth Knowles <ke...@apache.org> wrote:

> I made a bunch of perturbations and undid them and eventually the links
> are working as-is... So anyhow this is good to review or publish if you are
> happy with it.
>
> Kenn
>
> On Sun, Feb 10, 2019 at 1:35 PM Kenneth Knowles <ke...@apache.org> wrote:
>
>> Thanks for the feedback! I've revised to take it into account. I'll try
>> to reply inline to indicate how.
>>
>> On Mon, Jan 7, 2019 at 1:02 AM Bertrand Delacretaz <
>> bdelacretaz@apache.org> wrote:
>>
>>> On Fri, Jan 4, 2019 at 10:35 PM Kenneth Knowles <ke...@apache.org> wrote:
>>> > On Wed, Oct 31, 2018 at 8:51 AM Bertrand Delacretaz <
>>> bdelacretaz@apache.org>
>>> > wrote:
>>> > >... Feel free to draft your blog post and we can then review and
>>> publish!
>>> > I've drafted it....
>>>
>>> Thank you, I reviewed [1] and it looks great to me!
>>>
>>> I have just 3 minor comments:
>>>
>>> -Add a link to the committer guidelines that you mention
>>>
>>
>> The first sentence of the paragraph on that was a link. Something about
>> my source is making most links not render. I got this one working, but many
>> others are not. I'll figure that out...
>>
>>
>>> -IIUC when you say "Every ~month" it means "about every month" - that
>>> was not obvious to me initially
>>>
>>
>> Changed to "about every month"
>>
>>
>>> -for RTC and CTR you might link to
>>> https://www.apache.org/foundation/glossary.html
>>
>>
>> Done (but link is not yet working per above)
>>
>>
>>>
>>> -Bertrand
>>
>>
>>
>>
>> On Mon, Jan 7, 2019 at 5:11 PM Craig Russell <ap...@gmail.com>
>> wrote:
>>
>>> I realize that this message might be hard to read since copy/paste
>>> formatting is gone. So here goes my attempt to clarify...
>>>
>>> On Jan 7, 2019, at 8:28 AM, Craig Russell <ap...@gmail.com> wrote:
>>>
>>> Hi Kenn,
>>>
>>> Thanks for contributing this. I think it's a nice introduction to Beam's
>>> community building efforts.
>>>
>>> Here are a couple of comments:
>>>
>>> > We want our contributor-base (hence committer-base) to be more spread
>>> across companies and backgrounds, for the usual Apache reasons.
>>>
>>> I'd elaborate instead of saying "for the usual Apache reasons". Which
>>> reasons are important to Beam?
>>>
>>
>> Done.
>>
>>
>>> > (we have committers from community development, tech writing,
>>> training, etc).
>>>
>>> I'd make this a sentence of its own.
>>>
>>
>> Agree. Done.
>>
>>
>>
>>> > you shouldn't be proposing a committer for other reasons,
>>>
>>> I don't understand "for other reasons".
>>>
>>> > Every ~month, we call for new discussions and revisit ~all prior
>>> discussions.
>>>
>>> I find the "~" to be distracting. Words please.
>>>
>>
>> Done.
>>
>> > For a potential committer, we did this:
>>>
>>> It's not clear to me when a person becomes a potential committer. Is it
>>> in the "repeat contributor" phase?
>>>
>>> > For an early contributor,
>>>
>>> Perhaps move this paragraph above the "For a potential committer"
>>> paragraph?
>>>
>>
>> Done. I think re-ordering and slight rephrase helped.
>>
>> > ~3~4 obvious committer candidates
>>
>>
>>> As above, remove "~".
>>>
>>
>> Done. "a few"
>>
>> > If we have no feedback about which guidelines were a concern, that is a
>>> red flag that we are being driven by bias.
>>>
>>> I don't understand this. Lack of concern might be considered a "good
>>> thing" not a red flag.
>>>
>>
>> Rephrased: "Formulating this feedback is important for helping
>> contributors to learn, but it also serves as a check against bias and
>> politics. If we found ourselves unable to specify such feedback, that is a
>> sign that we are deciding for a reason other than those we have declared
>> and agreed upon."
>>
>> > as RMS says
>>>
>>> Who/what <https://teams.googleplex.com/u/what> is RMS?
>>>
>>
>> Rephrased and spelled out his name.
>>
>> I'll keep trying to figure out what is going on with the links, and if
>> you know the answer please share it!
>>
>> Kenn
>>
>>
>>>
>>> Regards,
>>>
>>> Craig
>>> >> On Jan 4, 2019, at 1:49 PM, Kenneth Knowles <kenn@apache.org <mailto:
>>> kenn@apache.org>> wrote:
>>> >>
>>> >> Here it is:
>>> >>
>>> https://blogs.apache.org/roller-ui/authoring/preview/comdev/?previewEntry=an-approach-to-community-building
>>> <
>>> https://blogs.apache.org/roller-ui/authoring/preview/comdev/?previewEntry=an-approach-to-community-building
>>> >
>>> >>
>>> >> Kenn
>>> >>
>>> >> On Fri, Jan 4, 2019 at 1:44 PM Griselda Cuevas
>>> <gr...@google.com.invalid>
>>> >> wrote:
>>> >>
>>> >>> Where could we find it?
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Fri, 4 Jan 2019 at 13:35, Kenneth Knowles <ke...@apache.org>
>>> wrote:
>>> >>>
>>> >>>> On Wed, Oct 31, 2018 at 8:51 AM Bertrand Delacretaz <
>>> >>>> bdelacretaz@apache.org>
>>> >>>> wrote:
>>> >>>>
>>> >>>>> Feel free to draft your blog post and we can then review and
>>> publish!
>>> >>>>>
>>> >>>>
>>> >>>> I've drafted it. It is pretty long but still feels terse to me.
>>> Feedback
>>> >>>> very welcome on that point. I will try to find time to give it
>>> another
>>> >>>> pass, unless someone tells me that it is fine as-is.
>>> >>>>
>>> >>>> Kenn
>>> >>>>
>>> >>>>
>>> >>>> -Bertrand
>>> >>>>>
>>> >>>>>
>>> ---------------------------------------------------------------------
>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
>>> >>>>> For additional commands, e-mail: dev-help@community.apache.org
>>> >>>>>
>>> >>>>>
>>> >>>>
>>> >>>
>>> >
>>> > Craig L Russell
>>> > Secretary, Apache Software Foundation
>>> > clr@apache.org <ma...@apache.org> http://db.apache.org/jdo <
>>> http://db.apache.org/jdo>
>>>
>>> Craig L Russell
>>> Secretary, Apache Software Foundation
>>> clr@apache.org <ma...@apache.org> http://db.apache.org/jdo <
>>> http://db.apache.org/jdo>
>>>
>>

Re: Beam's recent community development work

Posted by Kenneth Knowles <ke...@apache.org>.
Done. And I did rephrase the bit about RTC to make it fit in better.

On Fri, Feb 22, 2019 at 4:51 AM Bertrand Delacretaz <bd...@apache.org>
wrote:

> On Sun, Feb 10, 2019 at 10:54 PM Kenneth Knowles <ke...@apache.org> wrote:
> > ...this is good to review or publish if you are
> > happy with it...
>
> sorry I missed that message, +1 to publishing!
>
> -Bertrand
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
>

Re: Beam's recent community development work

Posted by "sroffromen@gmail.com" <sr...@gmail.com>.
Google.com

Sent from my ASUS

-------- Original Message --------
From:sroffromen@gmail.com
Sent:Sat, 23 Feb 2019 06:02:57 +0800
To:dev@community.apache.org,"Romensroff@gmail com" <sr...@gmail.com>
Subject:Re: Beam's recent community development work

>
>
>Sent from my ASUS
>
>-------- Original Message --------
>From:Bertrand Delacretaz 
>Sent:Fri, 22 Feb 2019 20:51:04 +0800
>To:dev 
>Subject:Re: Beam's recent community development work
>
>On Sun, Feb 10, 2019 at 10:54 PM Kenneth Knowles wrote:
>> ...this is good to review or publish if you are
>> happy with it...
>
>sorry I missed that message, +1 to publishing!
>
>-Bertrand
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
>For additional commands, e-mail: dev-help@community.apache.org
>

Re: Beam's recent community development work

Posted by "sroffromen@gmail.com" <sr...@gmail.com>.

Sent from my ASUS

-------- Original Message --------
From:Bertrand Delacretaz <bd...@apache.org>
Sent:Fri, 22 Feb 2019 20:51:04 +0800
To:dev <de...@community.apache.org>
Subject:Re: Beam's recent community development work

>On Sun, Feb 10, 2019 at 10:54 PM Kenneth Knowles <ke...@apache.org> wrote:
>> ...this is good to review or publish if you are
>> happy with it...
>
>sorry I missed that message, +1 to publishing!
>
>-Bertrand
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
>For additional commands, e-mail: dev-help@community.apache.org
>

Re: Beam's recent community development work

Posted by Bertrand Delacretaz <bd...@apache.org>.
On Sun, Feb 10, 2019 at 10:54 PM Kenneth Knowles <ke...@apache.org> wrote:
> ...this is good to review or publish if you are
> happy with it...

sorry I missed that message, +1 to publishing!

-Bertrand

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

Re: Beam's recent community development work

Posted by Kenneth Knowles <ke...@apache.org>.
I made a bunch of perturbations and undid them and eventually the links are
working as-is... So anyhow this is good to review or publish if you are
happy with it.

Kenn

On Sun, Feb 10, 2019 at 1:35 PM Kenneth Knowles <ke...@apache.org> wrote:

> Thanks for the feedback! I've revised to take it into account. I'll try to
> reply inline to indicate how.
>
> On Mon, Jan 7, 2019 at 1:02 AM Bertrand Delacretaz <bd...@apache.org>
> wrote:
>
>> On Fri, Jan 4, 2019 at 10:35 PM Kenneth Knowles <ke...@apache.org> wrote:
>> > On Wed, Oct 31, 2018 at 8:51 AM Bertrand Delacretaz <
>> bdelacretaz@apache.org>
>> > wrote:
>> > >... Feel free to draft your blog post and we can then review and
>> publish!
>> > I've drafted it....
>>
>> Thank you, I reviewed [1] and it looks great to me!
>>
>> I have just 3 minor comments:
>>
>> -Add a link to the committer guidelines that you mention
>>
>
> The first sentence of the paragraph on that was a link. Something about my
> source is making most links not render. I got this one working, but many
> others are not. I'll figure that out...
>
>
>> -IIUC when you say "Every ~month" it means "about every month" - that
>> was not obvious to me initially
>>
>
> Changed to "about every month"
>
>
>> -for RTC and CTR you might link to
>> https://www.apache.org/foundation/glossary.html
>
>
> Done (but link is not yet working per above)
>
>
>>
>> -Bertrand
>
>
>
>
> On Mon, Jan 7, 2019 at 5:11 PM Craig Russell <ap...@gmail.com> wrote:
>
>> I realize that this message might be hard to read since copy/paste
>> formatting is gone. So here goes my attempt to clarify...
>>
>> On Jan 7, 2019, at 8:28 AM, Craig Russell <ap...@gmail.com> wrote:
>>
>> Hi Kenn,
>>
>> Thanks for contributing this. I think it's a nice introduction to Beam's
>> community building efforts.
>>
>> Here are a couple of comments:
>>
>> > We want our contributor-base (hence committer-base) to be more spread
>> across companies and backgrounds, for the usual Apache reasons.
>>
>> I'd elaborate instead of saying "for the usual Apache reasons". Which
>> reasons are important to Beam?
>>
>
> Done.
>
>
>> > (we have committers from community development, tech writing, training,
>> etc).
>>
>> I'd make this a sentence of its own.
>>
>
> Agree. Done.
>
>
>
>> > you shouldn't be proposing a committer for other reasons,
>>
>> I don't understand "for other reasons".
>>
>> > Every ~month, we call for new discussions and revisit ~all prior
>> discussions.
>>
>> I find the "~" to be distracting. Words please.
>>
>
> Done.
>
> > For a potential committer, we did this:
>>
>> It's not clear to me when a person becomes a potential committer. Is it
>> in the "repeat contributor" phase?
>>
>> > For an early contributor,
>>
>> Perhaps move this paragraph above the "For a potential committer"
>> paragraph?
>>
>
> Done. I think re-ordering and slight rephrase helped.
>
> > ~3~4 obvious committer candidates
>
>
>> As above, remove "~".
>>
>
> Done. "a few"
>
> > If we have no feedback about which guidelines were a concern, that is a
>> red flag that we are being driven by bias.
>>
>> I don't understand this. Lack of concern might be considered a "good
>> thing" not a red flag.
>>
>
> Rephrased: "Formulating this feedback is important for helping
> contributors to learn, but it also serves as a check against bias and
> politics. If we found ourselves unable to specify such feedback, that is a
> sign that we are deciding for a reason other than those we have declared
> and agreed upon."
>
> > as RMS says
>>
>> Who/what <https://teams.googleplex.com/u/what> is RMS?
>>
>
> Rephrased and spelled out his name.
>
> I'll keep trying to figure out what is going on with the links, and if you
> know the answer please share it!
>
> Kenn
>
>
>>
>> Regards,
>>
>> Craig
>> >> On Jan 4, 2019, at 1:49 PM, Kenneth Knowles <kenn@apache.org <mailto:
>> kenn@apache.org>> wrote:
>> >>
>> >> Here it is:
>> >>
>> https://blogs.apache.org/roller-ui/authoring/preview/comdev/?previewEntry=an-approach-to-community-building
>> <
>> https://blogs.apache.org/roller-ui/authoring/preview/comdev/?previewEntry=an-approach-to-community-building
>> >
>> >>
>> >> Kenn
>> >>
>> >> On Fri, Jan 4, 2019 at 1:44 PM Griselda Cuevas <gris@google.com.invalid
>> >
>> >> wrote:
>> >>
>> >>> Where could we find it?
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On Fri, 4 Jan 2019 at 13:35, Kenneth Knowles <ke...@apache.org> wrote:
>> >>>
>> >>>> On Wed, Oct 31, 2018 at 8:51 AM Bertrand Delacretaz <
>> >>>> bdelacretaz@apache.org>
>> >>>> wrote:
>> >>>>
>> >>>>> Feel free to draft your blog post and we can then review and
>> publish!
>> >>>>>
>> >>>>
>> >>>> I've drafted it. It is pretty long but still feels terse to me.
>> Feedback
>> >>>> very welcome on that point. I will try to find time to give it
>> another
>> >>>> pass, unless someone tells me that it is fine as-is.
>> >>>>
>> >>>> Kenn
>> >>>>
>> >>>>
>> >>>> -Bertrand
>> >>>>>
>> >>>>>
>> ---------------------------------------------------------------------
>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
>> >>>>> For additional commands, e-mail: dev-help@community.apache.org
>> >>>>>
>> >>>>>
>> >>>>
>> >>>
>> >
>> > Craig L Russell
>> > Secretary, Apache Software Foundation
>> > clr@apache.org <ma...@apache.org> http://db.apache.org/jdo <
>> http://db.apache.org/jdo>
>>
>> Craig L Russell
>> Secretary, Apache Software Foundation
>> clr@apache.org <ma...@apache.org> http://db.apache.org/jdo <
>> http://db.apache.org/jdo>
>>
>

Re: Beam's recent community development work

Posted by Kenneth Knowles <ke...@apache.org>.
Thanks for the feedback! I've revised to take it into account. I'll try to
reply inline to indicate how.

On Mon, Jan 7, 2019 at 1:02 AM Bertrand Delacretaz <bd...@apache.org>
wrote:

> On Fri, Jan 4, 2019 at 10:35 PM Kenneth Knowles <ke...@apache.org> wrote:
> > On Wed, Oct 31, 2018 at 8:51 AM Bertrand Delacretaz <
> bdelacretaz@apache.org>
> > wrote:
> > >... Feel free to draft your blog post and we can then review and
> publish!
> > I've drafted it....
>
> Thank you, I reviewed [1] and it looks great to me!
>
> I have just 3 minor comments:
>
> -Add a link to the committer guidelines that you mention
>

The first sentence of the paragraph on that was a link. Something about my
source is making most links not render. I got this one working, but many
others are not. I'll figure that out...


> -IIUC when you say "Every ~month" it means "about every month" - that
> was not obvious to me initially
>

Changed to "about every month"


> -for RTC and CTR you might link to
> https://www.apache.org/foundation/glossary.html


Done (but link is not yet working per above)


>
> -Bertrand




On Mon, Jan 7, 2019 at 5:11 PM Craig Russell <ap...@gmail.com> wrote:

> I realize that this message might be hard to read since copy/paste
> formatting is gone. So here goes my attempt to clarify...
>
> On Jan 7, 2019, at 8:28 AM, Craig Russell <ap...@gmail.com> wrote:
>
> Hi Kenn,
>
> Thanks for contributing this. I think it's a nice introduction to Beam's
> community building efforts.
>
> Here are a couple of comments:
>
> > We want our contributor-base (hence committer-base) to be more spread
> across companies and backgrounds, for the usual Apache reasons.
>
> I'd elaborate instead of saying "for the usual Apache reasons". Which
> reasons are important to Beam?
>

Done.


> > (we have committers from community development, tech writing, training,
> etc).
>
> I'd make this a sentence of its own.
>

Agree. Done.



> > you shouldn't be proposing a committer for other reasons,
>
> I don't understand "for other reasons".
>
> > Every ~month, we call for new discussions and revisit ~all prior
> discussions.
>
> I find the "~" to be distracting. Words please.
>

Done.

> For a potential committer, we did this:
>
> It's not clear to me when a person becomes a potential committer. Is it in
> the "repeat contributor" phase?
>
> > For an early contributor,
>
> Perhaps move this paragraph above the "For a potential committer"
> paragraph?
>

Done. I think re-ordering and slight rephrase helped.

> ~3~4 obvious committer candidates


> As above, remove "~".
>

Done. "a few"

> If we have no feedback about which guidelines were a concern, that is a
> red flag that we are being driven by bias.
>
> I don't understand this. Lack of concern might be considered a "good
> thing" not a red flag.
>

Rephrased: "Formulating this feedback is important for helping contributors
to learn, but it also serves as a check against bias and politics. If we
found ourselves unable to specify such feedback, that is a sign that we are
deciding for a reason other than those we have declared and agreed upon."

> as RMS says
>
> Who/what <https://teams.googleplex.com/u/what> is RMS?
>

Rephrased and spelled out his name.

I'll keep trying to figure out what is going on with the links, and if you
know the answer please share it!

Kenn


>
> Regards,
>
> Craig
> >> On Jan 4, 2019, at 1:49 PM, Kenneth Knowles <kenn@apache.org <mailto:
> kenn@apache.org>> wrote:
> >>
> >> Here it is:
> >>
> https://blogs.apache.org/roller-ui/authoring/preview/comdev/?previewEntry=an-approach-to-community-building
> <
> https://blogs.apache.org/roller-ui/authoring/preview/comdev/?previewEntry=an-approach-to-community-building
> >
> >>
> >> Kenn
> >>
> >> On Fri, Jan 4, 2019 at 1:44 PM Griselda Cuevas <gris@google.com.invalid
> >
> >> wrote:
> >>
> >>> Where could we find it?
> >>>
> >>>
> >>>
> >>>
> >>> On Fri, 4 Jan 2019 at 13:35, Kenneth Knowles <ke...@apache.org> wrote:
> >>>
> >>>> On Wed, Oct 31, 2018 at 8:51 AM Bertrand Delacretaz <
> >>>> bdelacretaz@apache.org>
> >>>> wrote:
> >>>>
> >>>>> Feel free to draft your blog post and we can then review and publish!
> >>>>>
> >>>>
> >>>> I've drafted it. It is pretty long but still feels terse to me.
> Feedback
> >>>> very welcome on that point. I will try to find time to give it another
> >>>> pass, unless someone tells me that it is fine as-is.
> >>>>
> >>>> Kenn
> >>>>
> >>>>
> >>>> -Bertrand
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> >>>>> For additional commands, e-mail: dev-help@community.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>
> >
> > Craig L Russell
> > Secretary, Apache Software Foundation
> > clr@apache.org <ma...@apache.org> http://db.apache.org/jdo <
> http://db.apache.org/jdo>
>
> Craig L Russell
> Secretary, Apache Software Foundation
> clr@apache.org <ma...@apache.org> http://db.apache.org/jdo <
> http://db.apache.org/jdo>
>

Re: Beam's recent community development work

Posted by Craig Russell <ap...@gmail.com>.
I realize that this message might be hard to read since copy/paste formatting is gone. So here goes my attempt to clarify...

On Jan 7, 2019, at 8:28 AM, Craig Russell <ap...@gmail.com> wrote:

Hi Kenn,

Thanks for contributing this. I think it's a nice introduction to Beam's community building efforts.

Here are a couple of comments:

> We want our contributor-base (hence committer-base) to be more spread across companies and backgrounds, for the usual Apache reasons.

I'd elaborate instead of saying "for the usual Apache reasons". Which reasons are important to Beam?

> (we have committers from community development, tech writing, training, etc).


I'd make this a sentence of its own.

> you shouldn't be proposing a committer for other reasons, 

I don't understand "for other reasons".

> Every ~month, we call for new discussions and revisit ~all prior discussions. 

I find the "~" to be distracting. Words please.

> For a potential committer, we did this:

It's not clear to me when a person becomes a potential committer. Is it in the "repeat contributor" phase?

> For an early contributor, 

Perhaps move this paragraph above the "For a potential committer" paragraph?

> ~3~4 obvious committer candidates


As above, remove "~".

> If we have no feedback about which guidelines were a concern, that is a red flag that we are being driven by bias.


I don't understand this. Lack of concern might be considered a "good thing" not a red flag.

> as RMS says 

Who/what is RMS?

Regards,

Craig
>> On Jan 4, 2019, at 1:49 PM, Kenneth Knowles <kenn@apache.org <ma...@apache.org>> wrote:
>> 
>> Here it is:
>> https://blogs.apache.org/roller-ui/authoring/preview/comdev/?previewEntry=an-approach-to-community-building <https://blogs.apache.org/roller-ui/authoring/preview/comdev/?previewEntry=an-approach-to-community-building>
>> 
>> Kenn
>> 
>> On Fri, Jan 4, 2019 at 1:44 PM Griselda Cuevas <gr...@google.com.invalid>
>> wrote:
>> 
>>> Where could we find it?
>>> 
>>> 
>>> 
>>> 
>>> On Fri, 4 Jan 2019 at 13:35, Kenneth Knowles <ke...@apache.org> wrote:
>>> 
>>>> On Wed, Oct 31, 2018 at 8:51 AM Bertrand Delacretaz <
>>>> bdelacretaz@apache.org>
>>>> wrote:
>>>> 
>>>>> Feel free to draft your blog post and we can then review and publish!
>>>>> 
>>>> 
>>>> I've drafted it. It is pretty long but still feels terse to me. Feedback
>>>> very welcome on that point. I will try to find time to give it another
>>>> pass, unless someone tells me that it is fine as-is.
>>>> 
>>>> Kenn
>>>> 
>>>> 
>>>> -Bertrand
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
>>>>> For additional commands, e-mail: dev-help@community.apache.org
>>>>> 
>>>>> 
>>>> 
>>> 
> 
> Craig L Russell
> Secretary, Apache Software Foundation
> clr@apache.org <ma...@apache.org> http://db.apache.org/jdo <http://db.apache.org/jdo>

Craig L Russell
Secretary, Apache Software Foundation
clr@apache.org <ma...@apache.org> http://db.apache.org/jdo <http://db.apache.org/jdo>

Re: Beam's recent community development work

Posted by Craig Russell <ap...@gmail.com>.
Hi Kenn,

Thanks for contributing this. I think it's a nice introduction to Beam's community building efforts.

Here are a couple of comments:

We want our contributor-base (hence committer-base) to be more spread across companies and backgrounds, for the usual Apache reasons.

I'd elaborate instead of saying "for the usual Apache reasons". Which reasons are important to Beam?

(we have committers from community development, tech writing, training, etc).

I'd make this a sentence of its own.

you shouldn't be proposing a committer for other reasons, 

I don't understand "for other reasons".

Every ~month, we call for new discussions and revisit ~all prior discussions. 

I find the "~" to be distracting. Words please.

For a potential committer, we did this:

It's not clear to me when a person becomes a potential committer. Is it in the "repeat contributor" phase?

For an early contributor, 

Perhaps move this paragraph above the "For a potential committer" paragraph?

~3~4 obvious committer candidates

As above, remove "~".

If we have no feedback about which guidelines were a concern, that is a red flag that we are being driven by bias.

I don't understand this. Lack of concern might be considered a "good thing" not a red flag.

as RMS says 

Who/what is RMS?

Regards,

Craig
> On Jan 4, 2019, at 1:49 PM, Kenneth Knowles <ke...@apache.org> wrote:
> 
> Here it is:
> https://blogs.apache.org/roller-ui/authoring/preview/comdev/?previewEntry=an-approach-to-community-building
> 
> Kenn
> 
> On Fri, Jan 4, 2019 at 1:44 PM Griselda Cuevas <gr...@google.com.invalid>
> wrote:
> 
>> Where could we find it?
>> 
>> 
>> 
>> 
>> On Fri, 4 Jan 2019 at 13:35, Kenneth Knowles <ke...@apache.org> wrote:
>> 
>>> On Wed, Oct 31, 2018 at 8:51 AM Bertrand Delacretaz <
>>> bdelacretaz@apache.org>
>>> wrote:
>>> 
>>>> Feel free to draft your blog post and we can then review and publish!
>>>> 
>>> 
>>> I've drafted it. It is pretty long but still feels terse to me. Feedback
>>> very welcome on that point. I will try to find time to give it another
>>> pass, unless someone tells me that it is fine as-is.
>>> 
>>> Kenn
>>> 
>>> 
>>> -Bertrand
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
>>>> For additional commands, e-mail: dev-help@community.apache.org
>>>> 
>>>> 
>>> 
>> 

Craig L Russell
Secretary, Apache Software Foundation
clr@apache.org <ma...@apache.org> http://db.apache.org/jdo <http://db.apache.org/jdo>

Re: Beam's recent community development work

Posted by Kenneth Knowles <ke...@apache.org>.
Here it is:
https://blogs.apache.org/roller-ui/authoring/preview/comdev/?previewEntry=an-approach-to-community-building

Kenn

On Fri, Jan 4, 2019 at 1:44 PM Griselda Cuevas <gr...@google.com.invalid>
wrote:

> Where could we find it?
>
>
>
>
> On Fri, 4 Jan 2019 at 13:35, Kenneth Knowles <ke...@apache.org> wrote:
>
> > On Wed, Oct 31, 2018 at 8:51 AM Bertrand Delacretaz <
> > bdelacretaz@apache.org>
> > wrote:
> >
> > > Feel free to draft your blog post and we can then review and publish!
> > >
> >
> > I've drafted it. It is pretty long but still feels terse to me. Feedback
> > very welcome on that point. I will try to find time to give it another
> > pass, unless someone tells me that it is fine as-is.
> >
> > Kenn
> >
> >
> > -Bertrand
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> > > For additional commands, e-mail: dev-help@community.apache.org
> > >
> > >
> >
>

Re: Beam's recent community development work

Posted by Griselda Cuevas <gr...@google.com.INVALID>.
Where could we find it?




On Fri, 4 Jan 2019 at 13:35, Kenneth Knowles <ke...@apache.org> wrote:

> On Wed, Oct 31, 2018 at 8:51 AM Bertrand Delacretaz <
> bdelacretaz@apache.org>
> wrote:
>
> > Feel free to draft your blog post and we can then review and publish!
> >
>
> I've drafted it. It is pretty long but still feels terse to me. Feedback
> very welcome on that point. I will try to find time to give it another
> pass, unless someone tells me that it is fine as-is.
>
> Kenn
>
>
> -Bertrand
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> > For additional commands, e-mail: dev-help@community.apache.org
> >
> >
>

Re: Beam's recent community development work

Posted by "Yoyo yw." <aa...@gmail.com>.
saya tanda saya punya saja

Pada Sab, 5 Jan 2019 05:35 Kenneth Knowles <kenn@apache.org menulis:

> On Wed, Oct 31, 2018 at 8:51 AM Bertrand Delacretaz <
> bdelacretaz@apache.org>
> wrote:
>
> > Feel free to draft your blog post and we can then review and publish!
> >
>
> I've drafted it. It is pretty long but still feels terse to me. Feedback
> very welcome on that point. I will try to find time to give it another
> pass, unless someone tells me that it is fine as-is.
>
> Kenn
>
>
> -Bertrand
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> > For additional commands, e-mail: dev-help@community.apache.org
> >
> >
>

Re: Beam's recent community development work

Posted by Kenneth Knowles <ke...@apache.org>.
On Wed, Oct 31, 2018 at 8:51 AM Bertrand Delacretaz <bd...@apache.org>
wrote:

> Feel free to draft your blog post and we can then review and publish!
>

I've drafted it. It is pretty long but still feels terse to me. Feedback
very welcome on that point. I will try to find time to give it another
pass, unless someone tells me that it is fine as-is.

Kenn


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

Re: Beam's recent community development work

Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Oct 31, 2018 at 4:08 PM Kenneth Knowles <kl...@google.com.invalid> wrote:
> ...after login with LDAP
> credentials I was prompted to set up my blogging account (also `kenn`)...

Indeed, I see your username now, you should have received an invite.

Feel free to draft your blog post and we can then review and publish!

-Bertrand

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

Re: Beam's recent community development work

Posted by Kenneth Knowles <kl...@google.com.INVALID>.
On Wed, Oct 31, 2018 at 8:04 AM Bertrand Delacretaz <bd...@apache.org>
wrote:

> > On Thu, Oct 25, 2018 at 5:46 AM Kenneth Knowles <ke...@apache.org> wrote:
> > > ...I would like to make this a more easy to link blog post. There was
> the
> > > comment "the dev@community.a.o team can give you access". Can this
> happen?...
>
> The PMC accepted doing so, I'm ready to give you authoring access for
> https://blogs.apache.org/comdev/
>
> However I don't see your Apache ID in the list of users there - could
> you try to login using the login link at https://blogs.apache.org/ ? I
> suppose this will cause your user to be added, as those blogs are
> linked with our LDAP services now.
>

I've done it. Seems to have worked as expected - after login with LDAP
credentials I was prompted to set up my blogging account (also `kenn`).

Kenn


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

Re: Beam's recent community development work

Posted by Bertrand Delacretaz <bd...@apache.org>.
> On Thu, Oct 25, 2018 at 5:46 AM Kenneth Knowles <ke...@apache.org> wrote:
> > ...I would like to make this a more easy to link blog post. There was the
> > comment "the dev@community.a.o team can give you access". Can this happen?...

The PMC accepted doing so, I'm ready to give you authoring access for
https://blogs.apache.org/comdev/

However I don't see your Apache ID in the list of users there - could
you try to login using the login link at https://blogs.apache.org/ ? I
suppose this will cause your user to be added, as those blogs are
linked with our LDAP services now.

-Bertrand

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

Re: Beam's recent community development work

Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,

On Thu, Oct 25, 2018 at 5:46 AM Kenneth Knowles <ke...@apache.org> wrote:
> ...I would like to make this a more easy to link blog post. There was the
> comment "the dev@community.a.o team can give you access". Can this happen?...

I'm not sure if we have a defined process for this or for deciding who
gets authoring access to https://blogs.apache.org/comdev/

I'll check with the PMC and get back to you here. We can always copy a
draft post from somewhere else once that's sorted out, in case you
want to start working on it already.

-Bertrand

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

Re: Beam's recent community development work

Posted by Kenneth Knowles <ke...@apache.org>.
Hello!

(limiting prior thread to just comdev)

It has been quite some time, including a bit of parental leave for me, but
I would like to make this a more easy to link blog post. There was the
comment "the dev@community.a.o team can give you access". Can this happen?
What should I do? What are the next steps?

Kenn

On Sat, Jul 14, 2018 at 10:22 PM Kenneth Knowles <ke...@apache.org> wrote:

>
> On Thu, Jul 12, 2018 at 1:43 AM Bertrand Delacretaz <
> bdelacretaz@apache.org> wrote:
>
>> (note the mix of public and private lists)
>>
>> On Tue, Jul 10, 2018 at 9:56 PM Karl Fogel <kf...@red-bean.com> wrote:
>> > ...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.....
>>
>> +1 for a blog post and you're welcome at
>> https://blogs.apache.org/comdev/ if desired, the dev@community.a.o
>> team can give you access.
>>
>
> Thanks for the encouragement. That sounds great. I am most comfortable
> providing a testimonial ("here's what seemed to work so far") rather than
> prescriptive advice, and mentioning the feedback appropriately.
>
> Kenn
>
>
>
>> -Bertrand
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
>> For additional commands, e-mail: dev-help@community.apache.org
>>
>>

Re: Beam's recent community development work

Posted by Kenneth Knowles <ke...@apache.org>.
On Thu, Jul 12, 2018 at 1:43 AM Bertrand Delacretaz <bd...@apache.org>
wrote:

> (note the mix of public and private lists)
>
> On Tue, Jul 10, 2018 at 9:56 PM Karl Fogel <kf...@red-bean.com> wrote:
> > ...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.....
>
> +1 for a blog post and you're welcome at
> https://blogs.apache.org/comdev/ if desired, the dev@community.a.o
> team can give you access.
>

Thanks for the encouragement. That sounds great. I am most comfortable
providing a testimonial ("here's what seemed to work so far") rather than
prescriptive advice, and mentioning the feedback appropriately.

Kenn



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

Re: Beam's recent community development work

Posted by Kenneth Knowles <ke...@apache.org>.
On Thu, Jul 12, 2018 at 1:43 AM Bertrand Delacretaz <bd...@apache.org>
wrote:

> (note the mix of public and private lists)
>
> On Tue, Jul 10, 2018 at 9:56 PM Karl Fogel <kf...@red-bean.com> wrote:
> > ...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.....
>
> +1 for a blog post and you're welcome at
> https://blogs.apache.org/comdev/ if desired, the dev@community.a.o
> team can give you access.
>

Thanks for the encouragement. That sounds great. I am most comfortable
providing a testimonial ("here's what seemed to work so far") rather than
prescriptive advice, and mentioning the feedback appropriately.

Kenn



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

Re: Beam's recent community development work

Posted by Bertrand Delacretaz <bd...@apache.org>.
(note the mix of public and private lists)

On Tue, Jul 10, 2018 at 9:56 PM Karl Fogel <kf...@red-bean.com> wrote:
> ...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.....

+1 for a blog post and you're welcome at
https://blogs.apache.org/comdev/ if desired, the dev@community.a.o
team can give you access.

-Bertrand

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

Re: Beam's recent community development work

Posted by Bertrand Delacretaz <bd...@apache.org>.
(note the mix of public and private lists)

On Tue, Jul 10, 2018 at 9:56 PM Karl Fogel <kf...@red-bean.com> wrote:
> ...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.....

+1 for a blog post and you're welcome at
https://blogs.apache.org/comdev/ if desired, the dev@community.a.o
team can give you access.

-Bertrand

Re: Beam's recent community development work

Posted by Karl Fogel <kf...@red-bean.com>.
Ted Dunning <te...@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 <kl...@google.com>
  Subject: Beam's recent community development work
  To: dev@community.apache.org, members@apache.org,  Griselda Cuevas <gr...@apache.org>, dev <de...@beam.apache.org>
  Date: Fri, 29 Jun 2018 23:15:02 -0700
  Reply-To: members@apache.org
  Message-ID: <CA...@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 <ro...@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 <kl...@google.com>
>    Sent: Monday, July 2, 2018 4:47 PM
>    To: dev <de...@beam.apache.org>
>    Cc: members@apache.org; dev@community.apache.org; Griselda Cuevas
>    <gr...@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 <ma...@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
>    <ma...@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 <ma...@community.apache.org>  and 
>    members@apache.org <ma...@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

Re: Beam's recent community development work

Posted by Ted Dunning <te...@gmail.com>.
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 <ro...@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 <kl...@google.com>
> Sent: Monday, July 2, 2018 4:47 PM
> To: dev <de...@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
> <ma...@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 <ma...@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/
>
>

Re: Beam's recent community development work

Posted by Ted Dunning <te...@gmail.com>.
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 <ro...@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 <kl...@google.com>
> Sent: Monday, July 2, 2018 4:47 PM
> To: dev <de...@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
> <ma...@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 <ma...@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/
>
>

RE: Beam's recent community development work

Posted by ro...@gardler.org.
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 <kl...@google.com> 
Sent: Monday, July 2, 2018 4:47 PM
To: dev <de...@beam.apache.org>
Cc: members@apache.org; dev@community.apache.org; Griselda Cuevas <gr...@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 <ma...@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 <ma...@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 <ma...@community.apache.org>  and members@apache.org <ma...@apache.org> . So here is a long description. I have included dev@beam.apache.org <ma...@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/

RE: Beam's recent community development work

Posted by ro...@gardler.org.
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 <kl...@google.com> 
Sent: Monday, July 2, 2018 4:47 PM
To: dev <de...@beam.apache.org>
Cc: members@apache.org; dev@community.apache.org; Griselda Cuevas <gr...@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 <ma...@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 <ma...@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 <ma...@community.apache.org>  and members@apache.org <ma...@apache.org> . So here is a long description. I have included dev@beam.apache.org <ma...@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/

Re: Beam's recent community development work

Posted by Kenneth Knowles <kl...@google.com>.
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 <te...@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 <kl...@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
>> members@apache.org. So here is a long description. I have included
>> 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/
>>
>

Re: Beam's recent community development work

Posted by Kenneth Knowles <kl...@google.com.INVALID>.
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 <te...@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 <kl...@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
>> members@apache.org. So here is a long description. I have included
>> 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/
>>
>

Re: Beam's recent community development work

Posted by Ted Dunning <te...@gmail.com>.
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 <kl...@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
> members@apache.org. So here is a long description. I have included
> 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/
>

Re: Beam's recent community development work

Posted by Huxing Zhang <hu...@apache.org>.
Thanks for sharing, really nice post. I've learned a lot.

I think this can be a good example for incubating project like Dubbo,
which is facing the same issue here: not enough committer to review
the issue report and pull request.


On Sat, Jun 30, 2018 at 2:15 PM, Kenneth Knowles <kl...@google.com.invalid> 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
> members@apache.org. So here is a long description. I have included
> 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/



-- 
Best Regards！
Huxing

Re: Beam's recent community development work

Posted by Ted Dunning <te...@gmail.com>.
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 <kl...@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
> members@apache.org. So here is a long description. I have included
> 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/
>

Re: Beam's recent community development work

Posted by Huxing Zhang <hu...@apache.org>.
Thanks for sharing, really nice post. I've learned a lot.

I think this can be a good example for incubating project like Dubbo,
which is facing the same issue here: not enough committer to review
the issue report and pull request.


On Sat, Jun 30, 2018 at 2:15 PM, Kenneth Knowles <kl...@google.com.invalid> 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
> members@apache.org. So here is a long description. I have included
> 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/



-- 
Best Regards！
Huxing

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

Fwd: Beam's recent community development work

Posted by Dave Fisher <wa...@apache.org>.
Hi -

Here is a model form the Apache Beam project that may be worth considering for ECharts.

Note that identifying people asking good questions starts the process. This can be how non-code contributors are identified.

Regards,
Dave

> Begin forwarded message:
> 
> From: Kenneth Knowles <kl...@google.com>
> Subject: Beam's recent community development work
> Date: June 29, 2018 at 11:15:02 PM PDT
> To: dev@community.apache.org, members@apache.org, Griselda Cuevas <gr...@apache.org>, dev <de...@beam.apache.org>
> Reply-To: members@apache.org
> 
> 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 <ma...@community.apache.org> and members@apache.org <ma...@apache.org>. So here is a long description. I have included dev@beam.apache.org <ma...@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/ <https://beam.apache.org/contribute/become-a-committer/>

Re: Beam's recent community development work

Posted by Yasser Zamani <ya...@apache.org>.
Thank you very much Kenneth, they're nice points!

Regards.

On 6/30/2018 10:45 AM, Kenneth Knowles 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
> members@apache.org. So here is a long description. I have included
> 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/
>

Re: Beam's recent community development work

Posted by Yasser Zamani <ya...@apache.org>.
Thank you very much Kenneth, they're nice points!

Regards.

On 6/30/2018 10:45 AM, Kenneth Knowles 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
> members@apache.org. So here is a long description. I have included
> 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