Re: Using labels on pull requests in GitHub

2022-03-17 Thread Ruslan Fomkin
Hi,

I would like to note that I as contributor cannot add labels or do almost 
nothing in my PRs to Apache Cassandra. So it completely relies on committers, I 
guess.
In a case you decide to ask contributors/PR owners to label their PRs it will 
be necessary to provide the functionality.

Best regards,
Ruslan

Re: Using labels on pull requests in GitHub

2022-03-16 Thread Yifan Cai
Thank you Stefan for all the efforts!

Regarding the "merge strategy change", should we start a new thread?

I am +1 on adopting the merge button. It should work in the single branch
commit. Just the cross branch commit could be tricky.

- Yifan


Re: Using labels on pull requests in GitHub

2022-03-16 Thread Erick Ramirez
Sounds good to me. Thanks for doing all this work, Stefan. 


Re: Using labels on pull requests in GitHub

2022-03-16 Thread Stefan Miklosovic
So, I went through all pull requests we have on GitHub manually (yes,
I did that, never more!) and out of ~550 PRs I managed to reduce it to
188 so I closed around 400 PRs.

All remaining PRs are of this nature:

1) Every PR has a name of "CASSANDRA-XYZ - description" or there is a
ticket number in it so it is searchable on GH.
2) PR which does not have a ticket is labeled "missing-ticket"
3) PRs which are related to docs are labeled as docs, PRs related to
tests are labeled as "tests"
4) There are combinations of 2) and 3) so we can have, for example,
only PRs which are missing ticket and they are related to docs.

docs PRs: 
https://github.com/apache/cassandra/pulls?q=is%3Apr+is%3Aopen+label%3Adocs
missing tickets PRs:
https://github.com/apache/cassandra/pulls?q=is%3Apr+is%3Aopen+label%3Amissing-ticket
tests PRs: https://github.com/apache/cassandra/labels/tests

Out of 188 PRs open, there is 35 documentation related PRs and 54 PRs
are missing their tickets.

What I would like to do now is to go to documentation guys and it
would be awesome if they can go through documentation PRs and resolve
all of them, preferably in one big PRs to solve it all. It does not
make a lot of sense to deal with each minor thing separately. Then we
might deal with the PRs which are solely missing tickets separately.

How does this sound to you?

Regards,

Stefan

On Wed, 16 Mar 2022 at 15:02, Jeff Jirsa  wrote:
>
> An easier fix here is just to put a close action into the commit message:
>
> Closes #nnn
>
> e.g. 
> https://github.com/apache/cassandra/commit/ad249424814836bd00f47931258ad58bfefb24fd
>  / https://github.com/apache/cassandra/pull/1046
>
> On Wed, Mar 16, 2022 at 5:40 AM Josh McKenzie  wrote:
>>
>> I think the fact that they pile up is because our merge strategy means we 
>> don't actually merge using the PR's we use for review so there's nothing 
>> codified in the workflow to close them out when a ticket's done.
>>
>> An easy fix would be to change our merge strategy and use the merge button 
>> on PR's to merge things in so they auto-close. :)
>>
>> (/grinding my axe)
>>
>> On Wed, Mar 16, 2022, at 7:27 AM, Paulo Motta wrote:
>>
>> Thanks for doing this Stefan.
>>
>> The fact that PRs are abandoned and piling up on github demonstrates a 
>> hygiene problem and creates a bad user experience to newcomers which are 
>> accustomed to the Github workflow. I'm supportive of any initiative to 
>> improve this
>>
>> I think starting labelling PRs manually and then looking into ways to 
>> automate this would be a good improvement from the status quo.
>>
>>


Re: Using labels on pull requests in GitHub

2022-03-16 Thread Jeff Jirsa
An easier fix here is just to put a close action into the commit message:

Closes #nnn

e.g.
https://github.com/apache/cassandra/commit/ad249424814836bd00f47931258ad58bfefb24fd
/ https://github.com/apache/cassandra/pull/1046

On Wed, Mar 16, 2022 at 5:40 AM Josh McKenzie  wrote:

> I think the fact that they pile up is because our merge strategy means we
> don't actually merge using the PR's we use for review so there's nothing
> codified in the workflow to close them out when a ticket's done.
>
> An easy fix would be to change our merge strategy and use the merge button
> on PR's to merge things in so they auto-close. :)
>
> (/grinding my axe)
>
> On Wed, Mar 16, 2022, at 7:27 AM, Paulo Motta wrote:
>
> Thanks for doing this Stefan.
>
> The fact that PRs are abandoned and piling up on github demonstrates a
> hygiene problem and creates a bad user experience to newcomers which are
> accustomed to the Github workflow. I'm supportive of any initiative to
> improve this
>
> I think starting labelling PRs manually and then looking into ways to
> automate this would be a good improvement from the status quo.
>
>
>


Re: Using labels on pull requests in GitHub

2022-03-16 Thread bened...@apache.org
+1, let’s change our merge strategy 


From: Josh McKenzie 
Date: Wednesday, 16 March 2022 at 12:47
To: dev@cassandra.apache.org 
Subject: Re: Using labels on pull requests in GitHub
I think the fact that they pile up is because our merge strategy means we don't 
actually merge using the PR's we use for review so there's nothing codified in 
the workflow to close them out when a ticket's done.

An easy fix would be to change our merge strategy and use the merge button on 
PR's to merge things in so they auto-close. :)

(/grinding my axe)

On Wed, Mar 16, 2022, at 7:27 AM, Paulo Motta wrote:
Thanks for doing this Stefan.

The fact that PRs are abandoned and piling up on github demonstrates a hygiene 
problem and creates a bad user experience to newcomers which are accustomed to 
the Github workflow. I'm supportive of any initiative to improve this

I think starting labelling PRs manually and then looking into ways to automate 
this would be a good improvement from the status quo.



Re: Using labels on pull requests in GitHub

2022-03-16 Thread Erick Ramirez
I confess, I'm guilty as charged. I use the git CLI for everything else but
use the merge button on the web UI for convenience. 


Re: Using labels on pull requests in GitHub

2022-03-16 Thread Josh McKenzie
I think the fact that they pile up is because our merge strategy means we don't 
actually merge using the PR's we use for review so there's nothing codified in 
the workflow to close them out when a ticket's done.

An easy fix would be to change our merge strategy and use the merge button on 
PR's to merge things in so they auto-close. :)

(/grinding my axe)

On Wed, Mar 16, 2022, at 7:27 AM, Paulo Motta wrote:
> Thanks for doing this Stefan.
> 
> The fact that PRs are abandoned and piling up on github demonstrates a 
> hygiene problem and creates a bad user experience to newcomers which are 
> accustomed to the Github workflow. I'm supportive of any initiative to 
> improve this
> 
> I think starting labelling PRs manually and then looking into ways to 
> automate this would be a good improvement from the status quo.


Re: Using labels on pull requests in GitHub

2022-03-16 Thread Paulo Motta
Thanks for doing this Stefan.

The fact that PRs are abandoned and piling up on github demonstrates a
hygiene problem and creates a bad user experience to newcomers which are
accustomed to the Github workflow. I'm supportive of any initiative to
improve this

I think starting labelling PRs manually and then looking into ways to
automate this would be a good improvement from the status quo.


Re: Using labels on pull requests in GitHub

2022-03-16 Thread bened...@apache.org
Since PRs are a second class citizen to Jira, mostly used for a scratch pad for 
nits and questions with code context, I suspect any improvements here will need 
to be automated to have any hope of success.

From: Stefan Miklosovic 
Date: Wednesday, 16 March 2022 at 08:16
To: dev@cassandra.apache.org 
Subject: Re: Using labels on pull requests in GitHub
Yeah, what I see quite frequently is that people come over, they open
PR but it does not have any related JIRA ticket and they just drop it
there and never return hence these PRs are in a constant limbo, not in
JIRA and they are more often than not left behind completely. Creating
categories would at least provide some minimal visibility where we are
at.

On Wed, 16 Mar 2022 at 09:07, Erick Ramirez  wrote:
>
> +1 it's a great idea. I have to admit that I don't go through the PRs and I 
> only pay attention to tickets so if doc PRs are "orphans" (don't have 
> associated tickets), I don't ever work on them. I'll aim to do this when I 
> have bandwidth. Cheers! 
>
> On Wed, 16 Mar 2022 at 19:02, Stefan Miklosovic 
>  wrote:
>>
>> Hello,
>>
>> Is somebody fundamentally opposing the idea of applying labels to pull
>> requests when applicable? I went through the pull requests and it
>> would be nice to have some basic filters, like "show me all pull
>> requests related to documentation" would be labeled as "docs", then
>> PRs fixing some tests would be "tests" and so on. We may further
>> narrow it down for subsystems etc.
>>
>> I do not mind applying myself in this to tag the PRs as they come if
>> people do not tag it themselves in order to have at least some basic
>> "filterability". As I went through PRs closing already committed ones,
>> I noticed there are a lot of PRs related to documentation which just
>> tend to be completely forgotten in the long run.
>>
>> Does this make sense to people?
>>
>> Regards
>>
>> Stefan


Re: Using labels on pull requests in GitHub

2022-03-16 Thread Stefan Miklosovic
Yeah, what I see quite frequently is that people come over, they open
PR but it does not have any related JIRA ticket and they just drop it
there and never return hence these PRs are in a constant limbo, not in
JIRA and they are more often than not left behind completely. Creating
categories would at least provide some minimal visibility where we are
at.

On Wed, 16 Mar 2022 at 09:07, Erick Ramirez  wrote:
>
> +1 it's a great idea. I have to admit that I don't go through the PRs and I 
> only pay attention to tickets so if doc PRs are "orphans" (don't have 
> associated tickets), I don't ever work on them. I'll aim to do this when I 
> have bandwidth. Cheers! 
>
> On Wed, 16 Mar 2022 at 19:02, Stefan Miklosovic 
>  wrote:
>>
>> Hello,
>>
>> Is somebody fundamentally opposing the idea of applying labels to pull
>> requests when applicable? I went through the pull requests and it
>> would be nice to have some basic filters, like "show me all pull
>> requests related to documentation" would be labeled as "docs", then
>> PRs fixing some tests would be "tests" and so on. We may further
>> narrow it down for subsystems etc.
>>
>> I do not mind applying myself in this to tag the PRs as they come if
>> people do not tag it themselves in order to have at least some basic
>> "filterability". As I went through PRs closing already committed ones,
>> I noticed there are a lot of PRs related to documentation which just
>> tend to be completely forgotten in the long run.
>>
>> Does this make sense to people?
>>
>> Regards
>>
>> Stefan


Re: Using labels on pull requests in GitHub

2022-03-16 Thread Erick Ramirez
+1 it's a great idea. I have to admit that I don't go through the PRs and I
only pay attention to tickets so if doc PRs are "orphans" (don't have
associated tickets), I don't ever work on them. I'll aim to do this when I
have bandwidth. Cheers! 

On Wed, 16 Mar 2022 at 19:02, Stefan Miklosovic <
stefan.mikloso...@instaclustr.com> wrote:

> Hello,
>
> Is somebody fundamentally opposing the idea of applying labels to pull
> requests when applicable? I went through the pull requests and it
> would be nice to have some basic filters, like "show me all pull
> requests related to documentation" would be labeled as "docs", then
> PRs fixing some tests would be "tests" and so on. We may further
> narrow it down for subsystems etc.
>
> I do not mind applying myself in this to tag the PRs as they come if
> people do not tag it themselves in order to have at least some basic
> "filterability". As I went through PRs closing already committed ones,
> I noticed there are a lot of PRs related to documentation which just
> tend to be completely forgotten in the long run.
>
> Does this make sense to people?
>
> Regards
>
> Stefan
>