Re: Parallelizing test runs

[Rafael Fernandez]

- How many resources to ValidatesRunner tests use?
- Where are those settings?

On Sat, Jun 30, 2018 at 9:50 AM Reuven Lax  wrote:

> The specific issue only affects Dataflow ValidatesRunner tests. We
> currently allow only one of these to run at a time, to control usage of
> Dataflow and of GCE quota. Other types of tests do not suffer from this
> issue.
>
> I would like to see if it's possible to increase Dataflow quota so we can
> run more of these in parallel. It took me 8 hours end to end to run these
> tests (about 6 hours for the run to be scheduled). If there was a failure,
> I would have had to repeat the whole process. In the worst case, this
> process could have taken me days. While this is not as pressing as some
> other issues (as most people don't need to run the Dataflow tests on every
> PR), fixing it would make such changes much easier to manage.
>
> Reuven
>
> On Sat, Jun 30, 2018 at 9:32 AM Rafael Fernandez 
> wrote:
>
>> +Reuven Lax  told me yesterday that he was waiting for
>> some test to be scheduled and run, and it took 6 hours or so. I would like
>> to help reduce these wait times by increasing parallelism. I need help
>> understanding the continuous minimum of what we use. It seems the following
>> is true:
>>
>>
>>- There seems to always be 16 jenkins machines on (16 CPUs each)
>>- There seems to be three GKE machines always on (1 CPU each)
>>- Most (if not all) unit tests run on 1 machine, and seem to run
>>one-at-a-time <-- I think we can safely parallelize this to 20.
>>
>> With current quotas, if we parallelize to 20 concurrent unit tests, we
>> still have room for 80 other concurrent dataflow jobs to execute, with 75%
>> of CPU capacity.
>>
>> Thoughts? Additional data?
>>
>> Thanks,
>> r
>>
>


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Parallelizing test runs

[Reuven Lax]

The specific issue only affects Dataflow ValidatesRunner tests. We
currently allow only one of these to run at a time, to control usage of
Dataflow and of GCE quota. Other types of tests do not suffer from this
issue.

I would like to see if it's possible to increase Dataflow quota so we can
run more of these in parallel. It took me 8 hours end to end to run these
tests (about 6 hours for the run to be scheduled). If there was a failure,
I would have had to repeat the whole process. In the worst case, this
process could have taken me days. While this is not as pressing as some
other issues (as most people don't need to run the Dataflow tests on every
PR), fixing it would make such changes much easier to manage.

Reuven

On Sat, Jun 30, 2018 at 9:32 AM Rafael Fernandez 
wrote:

> +Reuven Lax  told me yesterday that he was waiting for
> some test to be scheduled and run, and it took 6 hours or so. I would like
> to help reduce these wait times by increasing parallelism. I need help
> understanding the continuous minimum of what we use. It seems the following
> is true:
>
>
>- There seems to always be 16 jenkins machines on (16 CPUs each)
>- There seems to be three GKE machines always on (1 CPU each)
>- Most (if not all) unit tests run on 1 machine, and seem to run
>one-at-a-time <-- I think we can safely parallelize this to 20.
>
> With current quotas, if we parallelize to 20 concurrent unit tests, we
> still have room for 80 other concurrent dataflow jobs to execute, with 75%
> of CPU capacity.
>
> Thoughts? Additional data?
>
> Thanks,
> r
>

Parallelizing test runs

[Rafael Fernandez]

+Reuven Lax  told me yesterday that he was waiting for
some test to be scheduled and run, and it took 6 hours or so. I would like
to help reduce these wait times by increasing parallelism. I need help
understanding the continuous minimum of what we use. It seems the following
is true:


   - There seems to always be 16 jenkins machines on (16 CPUs each)
   - There seems to be three GKE machines always on (1 CPU each)
   - Most (if not all) unit tests run on 1 machine, and seem to run
   one-at-a-time <-- I think we can safely parallelize this to 20.

With current quotas, if we parallelize to 20 concurrent unit tests, we
still have room for 80 other concurrent dataflow jobs to execute, with 75%
of CPU capacity.

Thoughts? Additional data?

Thanks,
r


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Beam's recent community development work

[Ted Dunning]

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

> Hi all,
>
> The ASF board suggested that we (Beam) share some of what we've been doing
> for community development with d...@community.apache.org and
> memb...@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* 

Re: Samza runner committer support

[Xinyu Liu]

Thanks you guys for volunteering! Looks we got plenty coverage on
portability, Python and Go. I will reach out to you guys for reviews and
questions.

Thanks,
Xinyu

On Fri, Jun 29, 2018 at 2:51 PM, Lukasz Cwik  wrote:

> I would also have context on any portability related changes and would be
> glad to give guidance in this regard. I'm also a good resource for asking
> runner implementation questions as well.
>
> On Fri, Jun 29, 2018 at 11:01 AM Henning Rohde  wrote:
>
>> I would be happy to help with some of the portability-related changes, as
>> well as trying out Go-on-Samza. I'm out on vacation most of July, though.
>>
>> On Thu, Jun 28, 2018 at 1:12 PM Ahmet Altay  wrote:
>>
>>> I would be happy to help with this. I can prioritize python related
>>> changes. For portability related changes I can try to help but I may not be
>>> the best person.
>>>
>>> On Thu, Jun 28, 2018 at 12:33 PM, Xinyu Liu 
>>> wrote:
>>>
 Hi, All,

 Our Samza runner has recently been merged to master, and Kenn has been
 extremely instrumental during the whole process, e.g. design decisions,
 feature requests and code reviews. We would like thank him for all the
 support he has been given to us!

 Given Kenn is going to be on leave soon, we want to call out for
 committer sponsors who will work with us in the mean time. We expect a lot
 more upcoming updates for the Samza runner, such as the portable runner and
 python support. We will also have some feature asks, e.g. the async API
 briefly discussed in the previous email. Would anyone be interested in
 being a sponsor part time for the Samza runner?

 Thanks,
 Xinyu

>>>
>>>

Jenkins build is back to stable : beam_SeedJob #2122

[Apache Jenkins Server]

See 

Jenkins build became unstable: beam_SeedJob #2121

[Apache Jenkins Server]

See 

Build failed in Jenkins: beam_Release_Gradle_NightlySnapshot #85

[Apache Jenkins Server]

See 


Changes:

[xiliu] [BEAM-4641] Samza runner postcommit status in PR template

[Scott Wegner] Update pre-commit filter to include migrated build rules

[lukasz.gajowy] Remove mvn leftovers from jenkins IOIT job definitions

[xiliu] Make Samza runner in lexicographical order

[relax] Rename RowType -> Schema and move to new schemas package.

[relax] Add classes for SchemaRegistry and SchemaProvider.

[relax] Add SchemaCoder, some more detail in SchemaProvider/Registery, and

[relax] Update to comment.

[relax] Integrate Schemas into PCollection Coder inference.

[relax] Add setSchema convenience method.

[relax] Fix compilation errors.

[relax] Refactor Schema: Schema now is a fully-specified based on primitive

[relax] Implement SchemaCoder and fix up schema classes.

[relax] Flesh out FieldAccessDescriptor.

[relax] Start plumbing through DoFn.

[relax] Start editing signatures

[relax] Finish plumbing schemas through.

[relax] Add test for schema PCollection.

[relax] Add withSchema to Create.java

[relax] Plumb schemas through OutputReceiver.

[relax] Add an implementation of SchemaProvider.

[relax] Add SchemaRegistry and a test for schema inference. Change schema

[relax] Add unit test for SchemaRegistry.

[relax] Add FieldAccessDescriptorTest

[relax] Add test for Create changes.

[relax] Plumb FieldAccess through.

[relax] Make sure everything is marked experimental with Kind.SCHEMAS

[relax] Add graph-construction time verification of schemas.

[relax] Fix build and style failures.

[relax] Address code-review comments.

[relax] Fixup after merge.

[relax] Apply spotless autoformat.

[relax] Fix compilation error introduced by merge.

[robertwb] Remove obsolete comment about multimap fitting into memory.

[relax] Fix CheckStyle errors.

[relax] Fix Apex runner.

[relax] Fix more breakages.

[relax] run spotless.

[ankurgoenka] Adding non standard side input urn to flink

[relax] Fix issues.

[relax] Fix Spark issue.

[mariagh] Allow streaming mobile examples to read from either a topic or a

[relax] Address code-review comments and fix a failing test.

[relax] Fix Apex runner.

[echauchot] [BEAM-2850] Add Nexmark PostCommit runs for spark, flink and direct

[relax] Change ParDoSchemaTest to ValidatesRunner, and exclude unsupported

[relax] Make worker changes backwards compatible with DataflowRunner. Once

[mariagh] Address review comments

[relax] Add another backwards-compatible method.

[Pablo] Test case for providing experiments to pipeline

[kirpichov] [BEAM-4689] Reverts change of SDF key type

[klk] Add integrationTest task for GCP IO module

[klk] PubsubIO: Always use GCP project from PipelineOptions for subscriptions

[klk] Use BagState in PubsubSignal since it doesn't use SetState methods

[klk] Replace println with logging

[klk] More logging when PubsubJsonIT fails

[klk] Add start signal to TestPubsubSignal

[klk] Use futures in PubsubJsonIT LIMIT test

[klk] Integration test of Pubsub public dataset

[klk] Use test PipelineOptions in PubsubJsonIT LIMIT test

[klk] Sickbay PubsubReadIT on Dataflow

[klk] Fix import order

--
[...truncated 1.19 MB...]
:beam-sdks-java-maven-archetypes-examples:generatePomPropertiesFileForMavenJavaPublication
 (Thread[Task worker for ':' Thread 11,5,main]) completed. Took 0.001 secs.
:beam-sdks-java-maven-archetypes-examples:processTestResources (Thread[Task 
worker for ':' Thread 11,5,main]) started.

> Task :beam-sdks-java-maven-archetypes-examples:processTestResources
Build cache key for task 
':beam-sdks-java-maven-archetypes-examples:processTestResources' is 
32f999b722303cf823d337566e91f1de
Caching disabled for task 
':beam-sdks-java-maven-archetypes-examples:processTestResources': Caching has 
not been enabled for the task
Task ':beam-sdks-java-maven-archetypes-examples:processTestResources' is not 
up-to-date because:
  No history is available.
:beam-sdks-java-maven-archetypes-examples:processTestResources (Thread[Task 
worker for ':' Thread 11,5,main]) completed. Took 0.003 secs.
:beam-sdks-java-maven-archetypes-examples:sourcesJar (Thread[Task worker for 
':' Thread 11,5,main]) started.

> Task :beam-sdks-java-maven-archetypes-examples:sourcesJar
file or directory 
'
 not found
Build cache key for task ':beam-sdks-java-maven-archetypes-examples:sourcesJar' 
is 718739526992345fb0b137870e83dcb9
Caching disabled for task 
':beam-sdks-java-maven-archetypes-examples:sourcesJar': Caching has not been 
enabled for the task
Task ':beam-sdks-java-maven-archetypes-examples:sourcesJar' is not up-to-date 
because:
  No history is available.
file or directory 
'
 not 

Re: Beam's recent community development work

[Marco de Abreu]

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  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 d...@community.apache.org and
> > memb...@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 

Re: Beam's recent community development work

[Yasser Zamani]

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 d...@community.apache.org and
> memb...@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/
> 

Beam's recent community development work

[Kenneth Knowles]

Hi all,

The ASF board suggested that we (Beam) share some of what we've been doing
for community development with d...@community.apache.org and
memb...@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/