Mailing List Archive

Healthy PR Approaches from Apache Beam
Hi all,

I recently learned a few interesting things that the Beam
<https://github.com/apache/beam> project does to
promote and maintain good interactions on PRs.

1. Community metrics dashboard
<http://35.193.202.176/d/code_velocity/code-velocity?orgId=1>. The graphs
are pretty and insightful. You can
see things like the number of open PRs across time or the mean time to
first interaction on a new PR.

2. Life cycle management for PRs.
a. A bot labels the PR and assigns reviewers based on the labels
(example
<https://github.com/apache/beam/pull/26424#issuecomment-1522788593>).
b. Authors can run and re-run the pre-commit checks (doc
<https://github.com/apache/beam/blob/master/CONTRIBUTING.md#create-a-pull-request>
).
c. If the PR is not reviewed within 3 business days, the author is
encouraged to notify the mailing list (doc
<https://github.com/apache/beam/blob/master/CONTRIBUTING.md#get-reviewed>).
d. If the PR doesn't have activity, the bot comments on it, warning
that it
will be closed (example
<https://github.com/apache/beam/pull/26424#issuecomment-1671254755>).

It's hard for me to tell which of these ideas would translate well to the
Lucene community, but we can try out something small, like an automated
comment
on stale PRs.


Stefan


https://github.com/apache/beam
http://35.193.202.176/d/code_velocity/code-velocity?orgId=1
https://github.com/apache/beam/pull/26424#issuecomment-1522788593
https://github.com/apache/beam/blob/master/CONTRIBUTING.md#create-a-pull-request
https://github.com/apache/beam/blob/master/CONTRIBUTING.md#get-reviewed
https://github.com/apache/beam/pull/26424#issuecomment-1671254755
Re: Healthy PR Approaches from Apache Beam [ In reply to ]
Thanks for raising this Stefan. This is an impressive approach to more
rigorously responding on PRs and taking them through their lifecycle,
giving a better community experience especially for newcomers. I love
their docs too.

Those graphs are awesome! Much better than the simple PR open/closed count
chart we have in our nightlies:
https://home.apache.org/~mikemccand/lucenebench/github_pr_counts.html

I just made a pass through some of our PRs (sorted oldest to newest, and
sorry for all the dev list noise!) and it's sad how many PRs we (Lucene dev
community) really should have responded to, but failed to, in a
timely manner. I think something like the Apache Beam bot could help this,
though we don't really document attaching labels to newly opened PRs.

I wonder what baby step we could adopt from Beam's approach to PRs? Maybe
open an issue on GitHub so we can discuss?

Mike McCandless

http://blog.mikemccandless.com


On Tue, Oct 31, 2023 at 5:39?AM Stefan Vodita <stefan.vodita@gmail.com>
wrote:

> Hi all,
>
> I recently learned a few interesting things that the Beam
> <https://github.com/apache/beam> project does to
> promote and maintain good interactions on PRs.
>
> 1. Community metrics dashboard
> <http://35.193.202.176/d/code_velocity/code-velocity?orgId=1>. The graphs
> are pretty and insightful. You can
> see things like the number of open PRs across time or the mean time to
> first interaction on a new PR.
>
> 2. Life cycle management for PRs.
> a. A bot labels the PR and assigns reviewers based on the labels
> (example
> <https://github.com/apache/beam/pull/26424#issuecomment-1522788593>).
> b. Authors can run and re-run the pre-commit checks (doc
> <https://github.com/apache/beam/blob/master/CONTRIBUTING.md#create-a-pull-request>
> ).
> c. If the PR is not reviewed within 3 business days, the author is
> encouraged to notify the mailing list (doc
> <https://github.com/apache/beam/blob/master/CONTRIBUTING.md#get-reviewed>
> ).
> d. If the PR doesn't have activity, the bot comments on it, warning
> that it
> will be closed (example
> <https://github.com/apache/beam/pull/26424#issuecomment-1671254755>).
>
> It's hard for me to tell which of these ideas would translate well to the
> Lucene community, but we can try out something small, like an automated
> comment
> on stale PRs.
>
>
> Stefan
>
>
> https://github.com/apache/beam
> http://35.193.202.176/d/code_velocity/code-velocity?orgId=1
> https://github.com/apache/beam/pull/26424#issuecomment-1522788593
>
> https://github.com/apache/beam/blob/master/CONTRIBUTING.md#create-a-pull-request
> https://github.com/apache/beam/blob/master/CONTRIBUTING.md#get-reviewed
> https://github.com/apache/beam/pull/26424#issuecomment-1671254755
>
>
Re: Healthy PR Approaches from Apache Beam [ In reply to ]
Thank you for going through all those PRs Mike!
I opened an issue for porting some of the bot functionality:
https://github.com/apache/lucene/issues/12796

Stefan


On Thu, 2 Nov 2023 at 15:30, Michael McCandless <lucene@mikemccandless.com>
wrote:

> Thanks for raising this Stefan. This is an impressive approach to more
> rigorously responding on PRs and taking them through their lifecycle,
> giving a better community experience especially for newcomers. I love
> their docs too.
>
> Those graphs are awesome! Much better than the simple PR open/closed
> count chart we have in our nightlies:
> https://home.apache.org/~mikemccand/lucenebench/github_pr_counts.html
>
> I just made a pass through some of our PRs (sorted oldest to newest, and
> sorry for all the dev list noise!) and it's sad how many PRs we (Lucene dev
> community) really should have responded to, but failed to, in a
> timely manner. I think something like the Apache Beam bot could help this,
> though we don't really document attaching labels to newly opened PRs.
>
> I wonder what baby step we could adopt from Beam's approach to PRs? Maybe
> open an issue on GitHub so we can discuss?
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Tue, Oct 31, 2023 at 5:39?AM Stefan Vodita <stefan.vodita@gmail.com>
> wrote:
>
>> Hi all,
>>
>> I recently learned a few interesting things that the Beam
>> <https://github.com/apache/beam> project does to
>> promote and maintain good interactions on PRs.
>>
>> 1. Community metrics dashboard
>> <http://35.193.202.176/d/code_velocity/code-velocity?orgId=1>. The
>> graphs are pretty and insightful. You can
>> see things like the number of open PRs across time or the mean time to
>> first interaction on a new PR.
>>
>> 2. Life cycle management for PRs.
>> a. A bot labels the PR and assigns reviewers based on the labels
>> (example
>> <https://github.com/apache/beam/pull/26424#issuecomment-1522788593>).
>> b. Authors can run and re-run the pre-commit checks (doc
>> <https://github.com/apache/beam/blob/master/CONTRIBUTING.md#create-a-pull-request>
>> ).
>> c. If the PR is not reviewed within 3 business days, the author is
>> encouraged to notify the mailing list (doc
>> <https://github.com/apache/beam/blob/master/CONTRIBUTING.md#get-reviewed>
>> ).
>> d. If the PR doesn't have activity, the bot comments on it, warning
>> that it
>> will be closed (example
>> <https://github.com/apache/beam/pull/26424#issuecomment-1671254755>).
>>
>> It's hard for me to tell which of these ideas would translate well to the
>> Lucene community, but we can try out something small, like an automated
>> comment
>> on stale PRs.
>>
>>
>> Stefan
>>
>>
>> https://github.com/apache/beam
>> http://35.193.202.176/d/code_velocity/code-velocity?orgId=1
>> https://github.com/apache/beam/pull/26424#issuecomment-1522788593
>>
>> https://github.com/apache/beam/blob/master/CONTRIBUTING.md#create-a-pull-request
>> https://github.com/apache/beam/blob/master/CONTRIBUTING.md#get-reviewed
>> https://github.com/apache/beam/pull/26424#issuecomment-1671254755
>>
>>
Re: Healthy PR Approaches from Apache Beam [ In reply to ]
Thanks Stefan!

Mike McCandless

http://blog.mikemccandless.com


On Sat, Nov 11, 2023 at 5:22?AM Stefan Vodita <stefan.vodita@gmail.com>
wrote:

> Thank you for going through all those PRs Mike!
> I opened an issue for porting some of the bot functionality:
> https://github.com/apache/lucene/issues/12796
>
> Stefan
>
>
> On Thu, 2 Nov 2023 at 15:30, Michael McCandless <lucene@mikemccandless.com>
> wrote:
>
>> Thanks for raising this Stefan. This is an impressive approach to more
>> rigorously responding on PRs and taking them through their lifecycle,
>> giving a better community experience especially for newcomers. I love
>> their docs too.
>>
>> Those graphs are awesome! Much better than the simple PR open/closed
>> count chart we have in our nightlies:
>> https://home.apache.org/~mikemccand/lucenebench/github_pr_counts.html
>>
>> I just made a pass through some of our PRs (sorted oldest to newest, and
>> sorry for all the dev list noise!) and it's sad how many PRs we (Lucene dev
>> community) really should have responded to, but failed to, in a
>> timely manner. I think something like the Apache Beam bot could help this,
>> though we don't really document attaching labels to newly opened PRs.
>>
>> I wonder what baby step we could adopt from Beam's approach to PRs?
>> Maybe open an issue on GitHub so we can discuss?
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>>
>> On Tue, Oct 31, 2023 at 5:39?AM Stefan Vodita <stefan.vodita@gmail.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> I recently learned a few interesting things that the Beam
>>> <https://github.com/apache/beam> project does to
>>> promote and maintain good interactions on PRs.
>>>
>>> 1. Community metrics dashboard
>>> <http://35.193.202.176/d/code_velocity/code-velocity?orgId=1>. The
>>> graphs are pretty and insightful. You can
>>> see things like the number of open PRs across time or the mean time to
>>> first interaction on a new PR.
>>>
>>> 2. Life cycle management for PRs.
>>> a. A bot labels the PR and assigns reviewers based on the labels
>>> (example
>>> <https://github.com/apache/beam/pull/26424#issuecomment-1522788593>).
>>> b. Authors can run and re-run the pre-commit checks (doc
>>> <https://github.com/apache/beam/blob/master/CONTRIBUTING.md#create-a-pull-request>
>>> ).
>>> c. If the PR is not reviewed within 3 business days, the author is
>>> encouraged to notify the mailing list (doc
>>> <https://github.com/apache/beam/blob/master/CONTRIBUTING.md#get-reviewed>
>>> ).
>>> d. If the PR doesn't have activity, the bot comments on it, warning
>>> that it
>>> will be closed (example
>>> <https://github.com/apache/beam/pull/26424#issuecomment-1671254755>).
>>>
>>> It's hard for me to tell which of these ideas would translate well to the
>>> Lucene community, but we can try out something small, like an automated
>>> comment
>>> on stale PRs.
>>>
>>>
>>> Stefan
>>>
>>>
>>> https://github.com/apache/beam
>>> http://35.193.202.176/d/code_velocity/code-velocity?orgId=1
>>> https://github.com/apache/beam/pull/26424#issuecomment-1522788593
>>>
>>> https://github.com/apache/beam/blob/master/CONTRIBUTING.md#create-a-pull-request
>>> https://github.com/apache/beam/blob/master/CONTRIBUTING.md#get-reviewed
>>> https://github.com/apache/beam/pull/26424#issuecomment-1671254755
>>>
>>>