Re: [Proposal] add pull request template

[Claude Warren, Jr via dev]

Since there seems to be agreement, I opened a ticket (CASSANDRA-17837) and
a pull request (https://github.com/apache/cassandra/pull/1799) in so that
the final text can be hashed out and accepted.

I also used the proposed pull request in the text of the pull so that it
can be seen in all its glory 

On Thu, Aug 18, 2022 at 9:10 PM Josh McKenzie  wrote:

> I have never seen this
> kind of git merging strategy elsewhere, I am not sure if I am not
> experienced enough or we are truly unique the way we do things.
>
> I am very fond of this project and this community. THAT SAID ;) you could
> replace "kind of git merging strategy" with a lot of different things and
> have it equally apply on this project.
>
> Perils of being a mature long-lived project I suspect. I'm all for us
> doing the hard work of introspecting on how we do things and changing them
> to improve or match industry standards where applicable.
>
> On Thu, Aug 18, 2022, at 3:33 PM, Stefan Miklosovic wrote:
>
> Interesting, thanks for explicitly writing that down. I humbly think
> the CI and the convenience of the GitHub workflow is ultimately
> secondary when it comes to the code-base as such. Indeed, nice to
> have, but if it turns out to be uncomfortable in other ways, I guess
> we just have to live with what we have. TBH I have never seen this
> kind of git merging strategy elsewhere, I am not sure if I am not
> experienced enough or we are truly unique the way we do things.
> However, it does make sense.
>
> On Thu, 18 Aug 2022 at 21:28, Benedict 
> wrote:
> >
> > The benefits being extolled involve people setting up GitHub bots to
> integrate with PRs to run CI etc, which will require some non-trivial
> investment by somebody to put together
> >
> > The alternative merge strategy being discussed is not to merge, but to
> instead cherry-pick or rebase. This means we can produce separate PRs for
> each branch, that can be merged independently via the GitHub API. The
> downside of this is that there are no merge commits, while one upside of
> this is that there are no merge commits.
> >
> > On 18 Aug 2022, at 20:20, Stefan Miklosovic <
> stefan.mikloso...@instaclustr.com> wrote:
> >
> > No chicken-egg to me. All it takes is ctrl+c & ctrl+v on your merging
> > commits. How would new merging strategy actually look like? I am all
> > ears. This seems to be quite nice as is if we stick to be more verbose
> > what we did.
> >
> > On Thu, 18 Aug 2022 at 20:27, Benedict  wrote:
> >
> >
> > Was it?
> >
> >
> > I mean, we’ve all (or most) I think worked on projects with those
> things, so we all know what the benefits are?
> >
> >
> > It’s fair to point out that we don’t have it even running for any branch
> yet. However there’s perhaps a chicken-and-egg situation, where I’m unsure
> the investment to develop can be justified by those who are able, if
> there’s a chance it will be discarded? I can’t see us maintaining a
> bifurcated process, where some patches go through automation and others
> don’t, so if we don’t change the merge strategy that work would presumably
> end up wasted.
> >
> >
> > On 18 Aug 2022, at 18:53, Mick Semb Wever  wrote:
> >
> >
> > 
> >
> >
> > That debatable benefit aside, not doing merge commits would also open up
> options for us to use PR's for merges and integrate running CI, and
> blocking on clean CI, pre-merge. Which has some other pretty big benefits.
> :)
> >
> >
> >
> >
> > The past agreement IIRC was to start doing those things on trunk-only so
> we can evaluate them for real.
>
>
>

Re: [Proposal] add pull request template

[Josh McKenzie]

> I have never seen this
> kind of git merging strategy elsewhere, I am not sure if I am not
> experienced enough or we are truly unique the way we do things.
I am very fond of this project and this community. THAT SAID ;) you could 
replace "kind of git merging strategy" with a lot of different things and have 
it equally apply on this project.

Perils of being a mature long-lived project I suspect. I'm all for us doing the 
hard work of introspecting on how we do things and changing them to improve or 
match industry standards where applicable.

On Thu, Aug 18, 2022, at 3:33 PM, Stefan Miklosovic wrote:
> Interesting, thanks for explicitly writing that down. I humbly think
> the CI and the convenience of the GitHub workflow is ultimately
> secondary when it comes to the code-base as such. Indeed, nice to
> have, but if it turns out to be uncomfortable in other ways, I guess
> we just have to live with what we have. TBH I have never seen this
> kind of git merging strategy elsewhere, I am not sure if I am not
> experienced enough or we are truly unique the way we do things.
> However, it does make sense.
> 
> On Thu, 18 Aug 2022 at 21:28, Benedict  wrote:
> >
> > The benefits being extolled involve people setting up GitHub bots to 
> > integrate with PRs to run CI etc, which will require some non-trivial 
> > investment by somebody to put together
> >
> > The alternative merge strategy being discussed is not to merge, but to 
> > instead cherry-pick or rebase. This means we can produce separate PRs for 
> > each branch, that can be merged independently via the GitHub API. The 
> > downside of this is that there are no merge commits, while one upside of 
> > this is that there are no merge commits.
> >
> > On 18 Aug 2022, at 20:20, Stefan Miklosovic 
> >  wrote:
> >
> > No chicken-egg to me. All it takes is ctrl+c & ctrl+v on your merging
> > commits. How would new merging strategy actually look like? I am all
> > ears. This seems to be quite nice as is if we stick to be more verbose
> > what we did.
> >
> > On Thu, 18 Aug 2022 at 20:27, Benedict  wrote:
> >
> >
> > Was it?
> >
> >
> > I mean, we’ve all (or most) I think worked on projects with those things, 
> > so we all know what the benefits are?
> >
> >
> > It’s fair to point out that we don’t have it even running for any branch 
> > yet. However there’s perhaps a chicken-and-egg situation, where I’m unsure 
> > the investment to develop can be justified by those who are able, if 
> > there’s a chance it will be discarded? I can’t see us maintaining a 
> > bifurcated process, where some patches go through automation and others 
> > don’t, so if we don’t change the merge strategy that work would presumably 
> > end up wasted.
> >
> >
> > On 18 Aug 2022, at 18:53, Mick Semb Wever  wrote:
> >
> >
> > 
> >
> >
> > That debatable benefit aside, not doing merge commits would also open up 
> > options for us to use PR's for merges and integrate running CI, and 
> > blocking on clean CI, pre-merge. Which has some other pretty big benefits. 
> > :)
> >
> >
> >
> >
> > The past agreement IIRC was to start doing those things on trunk-only so we 
> > can evaluate them for real.
> 

Re: [Proposal] add pull request template

[Stefan Miklosovic]

Interesting, thanks for explicitly writing that down. I humbly think
the CI and the convenience of the GitHub workflow is ultimately
secondary when it comes to the code-base as such. Indeed, nice to
have, but if it turns out to be uncomfortable in other ways, I guess
we just have to live with what we have. TBH I have never seen this
kind of git merging strategy elsewhere, I am not sure if I am not
experienced enough or we are truly unique the way we do things.
However, it does make sense.

On Thu, 18 Aug 2022 at 21:28, Benedict  wrote:
>
> The benefits being extolled involve people setting up GitHub bots to 
> integrate with PRs to run CI etc, which will require some non-trivial 
> investment by somebody to put together
>
> The alternative merge strategy being discussed is not to merge, but to 
> instead cherry-pick or rebase. This means we can produce separate PRs for 
> each branch, that can be merged independently via the GitHub API. The 
> downside of this is that there are no merge commits, while one upside of this 
> is that there are no merge commits.
>
> On 18 Aug 2022, at 20:20, Stefan Miklosovic 
>  wrote:
>
> No chicken-egg to me. All it takes is ctrl+c & ctrl+v on your merging
> commits. How would new merging strategy actually look like? I am all
> ears. This seems to be quite nice as is if we stick to be more verbose
> what we did.
>
> On Thu, 18 Aug 2022 at 20:27, Benedict  wrote:
>
>
> Was it?
>
>
> I mean, we’ve all (or most) I think worked on projects with those things, so 
> we all know what the benefits are?
>
>
> It’s fair to point out that we don’t have it even running for any branch yet. 
> However there’s perhaps a chicken-and-egg situation, where I’m unsure the 
> investment to develop can be justified by those who are able, if there’s a 
> chance it will be discarded? I can’t see us maintaining a bifurcated process, 
> where some patches go through automation and others don’t, so if we don’t 
> change the merge strategy that work would presumably end up wasted.
>
>
> On 18 Aug 2022, at 18:53, Mick Semb Wever  wrote:
>
>
> 
>
>
> That debatable benefit aside, not doing merge commits would also open up 
> options for us to use PR's for merges and integrate running CI, and blocking 
> on clean CI, pre-merge. Which has some other pretty big benefits. :)
>
>
>
>
> The past agreement IIRC was to start doing those things on trunk-only so we 
> can evaluate them for real.

Re: [Proposal] add pull request template

[Benedict]

The benefits being extolled involve people setting up GitHub bots to integrate 
with PRs to run CI etc, which will require some non-trivial investment by 
somebody to put together

The alternative merge strategy being discussed is not to merge, but to instead 
cherry-pick or rebase. This means we can produce separate PRs for each branch, 
that can be merged independently via the GitHub API. The downside of this is 
that there are no merge commits, while one upside of this is that there are no 
merge commits.

> On 18 Aug 2022, at 20:20, Stefan Miklosovic 
>  wrote:
> 
> No chicken-egg to me. All it takes is ctrl+c & ctrl+v on your merging
> commits. How would new merging strategy actually look like? I am all
> ears. This seems to be quite nice as is if we stick to be more verbose
> what we did.
> 
>> On Thu, 18 Aug 2022 at 20:27, Benedict  wrote:
>> 
>> Was it?
>> 
>> I mean, we’ve all (or most) I think worked on projects with those things, so 
>> we all know what the benefits are?
>> 
>> It’s fair to point out that we don’t have it even running for any branch 
>> yet. However there’s perhaps a chicken-and-egg situation, where I’m unsure 
>> the investment to develop can be justified by those who are able, if there’s 
>> a chance it will be discarded? I can’t see us maintaining a bifurcated 
>> process, where some patches go through automation and others don’t, so if we 
>> don’t change the merge strategy that work would presumably end up wasted.
>> 
>> On 18 Aug 2022, at 18:53, Mick Semb Wever  wrote:
>> 
>> 
>>> 
>>> That debatable benefit aside, not doing merge commits would also open up 
>>> options for us to use PR's for merges and integrate running CI, and 
>>> blocking on clean CI, pre-merge. Which has some other pretty big benefits. 
>>> :)
>> 
>> 
>> 
>> The past agreement IIRC was to start doing those things on trunk-only so we 
>> can evaluate them for real.

Re: [Proposal] add pull request template

[Stefan Miklosovic]

No chicken-egg to me. All it takes is ctrl+c & ctrl+v on your merging
commits. How would new merging strategy actually look like? I am all
ears. This seems to be quite nice as is if we stick to be more verbose
what we did.

On Thu, 18 Aug 2022 at 20:27, Benedict  wrote:
>
> Was it?
>
> I mean, we’ve all (or most) I think worked on projects with those things, so 
> we all know what the benefits are?
>
> It’s fair to point out that we don’t have it even running for any branch yet. 
> However there’s perhaps a chicken-and-egg situation, where I’m unsure the 
> investment to develop can be justified by those who are able, if there’s a 
> chance it will be discarded? I can’t see us maintaining a bifurcated process, 
> where some patches go through automation and others don’t, so if we don’t 
> change the merge strategy that work would presumably end up wasted.
>
> On 18 Aug 2022, at 18:53, Mick Semb Wever  wrote:
>
> 
>>
>> That debatable benefit aside, not doing merge commits would also open up 
>> options for us to use PR's for merges and integrate running CI, and blocking 
>> on clean CI, pre-merge. Which has some other pretty big benefits. :)
>
>
>
> The past agreement IIRC was to start doing those things on trunk-only so we 
> can evaluate them for real.

Re: [Proposal] add pull request template

[Benedict]

Was it?

I mean, we’ve all (or most) I think worked on projects with those things, so we 
all know what the benefits are?

It’s fair to point out that we don’t have it even running for any branch yet. 
However there’s perhaps a chicken-and-egg situation, where I’m unsure the 
investment to develop can be justified by those who are able, if there’s a 
chance it will be discarded? I can’t see us maintaining a bifurcated process, 
where some patches go through automation and others don’t, so if we don’t 
change the merge strategy that work would presumably end up wasted.

> On 18 Aug 2022, at 18:53, Mick Semb Wever  wrote:
> 
> 
>> That debatable benefit aside, not doing merge commits would also open up 
>> options for us to use PR's for merges and integrate running CI, and blocking 
>> on clean CI, pre-merge. Which has some other pretty big benefits. :)
> 
> 
> The past agreement IIRC was to start doing those things on trunk-only so we 
> can evaluate them for real.

Re: [Proposal] add pull request template

[Mick Semb Wever]

>
> That debatable benefit aside, not doing merge commits would also open up
> options for us to use PR's for merges and integrate running CI, and
> blocking on clean CI, pre-merge. Which has some other pretty big benefits.
> :)
>


The past agreement IIRC was to start doing those things on trunk-only so we
can evaluate them for real.

Re: [Proposal] add pull request template

[Josh McKenzie]

re: history on merges, there's probably some incantation in idea I haven't yet 
uncovered to be able to stay in one environment instead of having to jump out 
to a terminal to dig into something. I'm a bit of a stickler when it comes to 
optimizing workflow; this may just be a Me Thing.

> Having different merge strategies in our history would be worse IMHO.
I disagree pretty strongly here. I think an "all commits are chronologically 
applied to the branch, no changes are hidden inside merge commits" approach is 
immediately intuitive; people would only have to know the old strategy when 
they stumble across merge commits which is explicitly no worse than our status 
quo.

That debatable benefit aside, not doing merge commits would also open up 
options for us to use PR's for merges and integrate running CI, and blocking on 
clean CI, pre-merge. Which has some other pretty big benefits. :)

On Thu, Aug 18, 2022, at 12:07 PM, Avi Kivity via dev wrote:
> 
> 
> On 18/08/2022 18.46, Mick Semb Wever wrote:
>> 
>> 
 Until IDEs auto cross-reference JIRA,
>>> I'm going to lightly touch the lid of Pandora's Box here and walk away 
>>> slowly. It drives me *nuts* when I'm git blaming a file to understand the 
>>> context of why a change was made (to make sure I continue to respect it!) 
>>> and I see "merge 3.11 into trunk" or some other such useless commit 
>>> message, then have to dig into the git integration and history, then figure 
>>> out which merge commits were real and which were -s ours and silently 
>>> changed, etc.
>>> 
>>> So about those merge commits... ;)
>> 
>> 
>> The beef I have with this is it's just not that difficult: just look at the 
>> parent 2 commit of the merge.
>> 
>> ```
>> `git log -n1 ^2`
>> ```
>> (you can also use `git log --follow .` if you like history without merge 
>> commits)
>> 
> 
> 
> There's `git merge --log` which provides a short-form log in the merge commit.
> 
> 
> 

Re: [Proposal] add pull request template

[Stefan Miklosovic]

I will gladly apply commit messages to merge commits as well from now
on (or when we formally vote on that, if you prefer).

On Thu, 18 Aug 2022 at 18:21, Mick Semb Wever  wrote:
>
>
>> There's `git merge --log` which provides a short-form log in the merge 
>> commit.
>
>
>
> Let's do it!
>
> Can anyone see the problem in having some of our new merge commits with this 
> additional info, in the hope it will just catch on and become the norm 
> (precedence > policy) ?
>
>
>
>

Re: [Proposal] add pull request template

[Mick Semb Wever]

> There's `git merge --log` which provides a short-form log in the merge
> commit.
>


Let's do it!

Can anyone see the problem in having some of our new merge commits with
this additional info, in the hope it will just catch on and become the norm
(precedence > policy) ?

Re: [Proposal] add pull request template

[Avi Kivity via dev]

On 18/08/2022 18.46, Mick Semb Wever wrote:




Until IDEs auto cross-reference JIRA,

I'm going to lightly touch the lid of Pandora's Box here and walk
away slowly. It drives me *nuts* when I'm git blaming a file to
understand the context of why a change was made (to make sure I
continue to respect it!) and I see "merge 3.11 into trunk" or some
other such useless commit message, then have to dig into the git
integration and history, then figure out which merge commits were
real and which were -s ours and silently changed, etc.

So about those merge commits... ;)



The beef I have with this is it's just not that difficult: just look 
at the parent 2 commit of the merge.


```
|git log -n1 ^2|
```
(you can also use `git log --follow .` if you like history without 
merge commits)




There's `git merge --log` which provides a short-form log in the merge 
commit.

Re: [Proposal] add pull request template

[Mick Semb Wever]

Until IDEs auto cross-reference JIRA,
>
> I'm going to lightly touch the lid of Pandora's Box here and walk away
> slowly. It drives me *nuts* when I'm git blaming a file to understand the
> context of why a change was made (to make sure I continue to respect it!)
> and I see "merge 3.11 into trunk" or some other such useless commit
> message, then have to dig into the git integration and history, then figure
> out which merge commits were real and which were -s ours and silently
> changed, etc.
>
> So about those merge commits... ;)
>


The beef I have with this is it's just not that difficult: just look at the
parent 2 commit of the merge.

```

git log -n1 ^2

```

(you can also use `git log --follow .` if you like history without merge
commits)



> (… also propagate into merge commits and also indicate when a merge
> commit makes material changes to the base branch diff)
>


Beef aside (take it w/ a grain of salt!), this is a good idea. Enforcing it
is another matter, and what about all existing history… 路‍♀️
Having different merge strategies in our history would be worse IMHO.



> That's not accurate. The ASF requires that any significant contribution
> requires a i(CLA), committer or not.
>
> Is there any guidance in the ASF docs as to what qualifies as
> "significant"? This seems like stuff we could document pretty trivially as
> a project and maybe link from the PR template.
>

Nothing qualifies it AFAIK.

The Apache License contains the following:
"Unless You explicitly state otherwise, any Contribution intentionally
submitted for inclusion in the Work by You to the Licensor shall be under
the terms and conditions of this License, without any additional terms or
conditions."

Good reads: https://lists.apache.org/thread/0mytpqj7too29bj90yz65rggdv7gd35d
and https://lists.apache.org/thread/vob27jog5qzrr9m2gz0063log3v6gkc1

In the second, Ted writes "If it is large enough or clever enough to be
hard to replicate you should probably ask for a more formal record of
agreement to the license."

Re: [Proposal] add pull request template

[Benedict]

Let’s change our merge strategy!

I really want us to. Perhaps I should start a formal discussion about it, and 
afterwards we can see where the votes land.

> On 18 Aug 2022, at 15:37, Josh McKenzie  wrote:
> 
> 
>> 
>> Until IDEs auto cross-reference JIRA,
> I'm going to lightly touch the lid of Pandora's Box here and walk away 
> slowly. It drives me *nuts* when I'm git blaming a file to understand the 
> context of why a change was made (to make sure I continue to respect it!) and 
> I see "merge 3.11 into trunk" or some other such useless commit message, then 
> have to dig into the git integration and history, then figure out which merge 
> commits were real and which were -s ours and silently changed, etc.
> 
> So about those merge commits... ;)
> 
> Anyway - longer-form commit messages (that we also propagate into merge 
> commits and also indicate when a merge commit makes material changes to the 
> base branch diff) would be a large quality of life improvement as this 
> codebase continues to mature IMO.
> 
>> On Thu, Aug 18, 2022, at 6:55 AM, Mick Semb Wever wrote:
>> That's not accurate. The ASF requires that any significant contribution 
>> requires a i(CLA), committer or not.
> Is there any guidance in the ASF docs as to what qualifies as "significant"? 
> This seems like stuff we could document pretty trivially as a project and 
> maybe link from the PR template.
> 
> The more we can encourage and enable folks to independently work on something 
> and pull the trigger on contributing to the project, the better.

Re: [Proposal] add pull request template

[Stefan Miklosovic]

Thinking about this a little bit more, I am not sure what would change
in practice if we introduced such a policy (of adding messages to
merge commits). We are not automatically enforcing the current format
of commit messages so why is it a problem we would not enforce the
format of commit messages in the merge commits? I can not be worse
than it currently is. If we now say what a commit message should look
like for "normal" commits, why would it be any different on merge
commits?

On Thu, 18 Aug 2022 at 16:46, Josh McKenzie  wrote:
>
> this should be pretty easy to incorporate into the workflow?
>
> The hard part isn't incorporating this into one's workflow, the hard part is 
> getting all of us to agree that this is something we should all do and 
> formalize it as our project process. :)
>
> On Thu, Aug 18, 2022, at 10:41 AM, Stefan Miklosovic wrote:
>
> Adding commit messages into merge commits for increased understanding
> of the codebase when you are git-blaming is the absolute minimum we
> can do to help you with (not only) your frustration. merging with -s
> ours opens up an editor where you do have a possibility to tweak the
> message as you wish so this should be pretty easy to incorporate into
> the workflow?
>
> On Thu, 18 Aug 2022 at 16:36, Josh McKenzie  wrote:
> >
> > Until IDEs auto cross-reference JIRA,
> >
> > I'm going to lightly touch the lid of Pandora's Box here and walk away 
> > slowly. It drives me *nuts* when I'm git blaming a file to understand the 
> > context of why a change was made (to make sure I continue to respect it!) 
> > and I see "merge 3.11 into trunk" or some other such useless commit 
> > message, then have to dig into the git integration and history, then figure 
> > out which merge commits were real and which were -s ours and silently 
> > changed, etc.
> >
> > So about those merge commits... ;)
> >
> > Anyway - longer-form commit messages (that we also propagate into merge 
> > commits and also indicate when a merge commit makes material changes to the 
> > base branch diff) would be a large quality of life improvement as this 
> > codebase continues to mature IMO.
> >
> > On Thu, Aug 18, 2022, at 6:55 AM, Mick Semb Wever wrote:
> >
> > That's not accurate. The ASF requires that any significant contribution 
> > requires a i(CLA), committer or not.
> >
> > Is there any guidance in the ASF docs as to what qualifies as 
> > "significant"? This seems like stuff we could document pretty trivially as 
> > a project and maybe link from the PR template.
> >
> > The more we can encourage and enable folks to independently work on 
> > something and pull the trigger on contributing to the project, the better.
>
>

Re: [Proposal] add pull request template

[Stefan Miklosovic]

Actually, yes. We can even all agree on that, the thing is who is
going to actually enforce it when it is solely upon an actual
committer to stick with the policy. What I tend to see in the other
projects is that they have even automatic checks on commit message
format but given the fact how we are merging / committing I do not
thing this approach applies to anything more complicated than a nice
linear commit history.

On Thu, 18 Aug 2022 at 16:46, Josh McKenzie  wrote:
>
> this should be pretty easy to incorporate into the workflow?
>
> The hard part isn't incorporating this into one's workflow, the hard part is 
> getting all of us to agree that this is something we should all do and 
> formalize it as our project process. :)
>
> On Thu, Aug 18, 2022, at 10:41 AM, Stefan Miklosovic wrote:
>
> Adding commit messages into merge commits for increased understanding
> of the codebase when you are git-blaming is the absolute minimum we
> can do to help you with (not only) your frustration. merging with -s
> ours opens up an editor where you do have a possibility to tweak the
> message as you wish so this should be pretty easy to incorporate into
> the workflow?
>
> On Thu, 18 Aug 2022 at 16:36, Josh McKenzie  wrote:
> >
> > Until IDEs auto cross-reference JIRA,
> >
> > I'm going to lightly touch the lid of Pandora's Box here and walk away 
> > slowly. It drives me *nuts* when I'm git blaming a file to understand the 
> > context of why a change was made (to make sure I continue to respect it!) 
> > and I see "merge 3.11 into trunk" or some other such useless commit 
> > message, then have to dig into the git integration and history, then figure 
> > out which merge commits were real and which were -s ours and silently 
> > changed, etc.
> >
> > So about those merge commits... ;)
> >
> > Anyway - longer-form commit messages (that we also propagate into merge 
> > commits and also indicate when a merge commit makes material changes to the 
> > base branch diff) would be a large quality of life improvement as this 
> > codebase continues to mature IMO.
> >
> > On Thu, Aug 18, 2022, at 6:55 AM, Mick Semb Wever wrote:
> >
> > That's not accurate. The ASF requires that any significant contribution 
> > requires a i(CLA), committer or not.
> >
> > Is there any guidance in the ASF docs as to what qualifies as 
> > "significant"? This seems like stuff we could document pretty trivially as 
> > a project and maybe link from the PR template.
> >
> > The more we can encourage and enable folks to independently work on 
> > something and pull the trigger on contributing to the project, the better.
>
>

Re: [Proposal] add pull request template

[Josh McKenzie]

> this should be pretty easy to incorporate into the workflow?
The hard part isn't incorporating this into one's workflow, the hard part is 
getting all of us to agree that this is something we should all do and 
formalize it as our project process. :)

On Thu, Aug 18, 2022, at 10:41 AM, Stefan Miklosovic wrote:
> Adding commit messages into merge commits for increased understanding
> of the codebase when you are git-blaming is the absolute minimum we
> can do to help you with (not only) your frustration. merging with -s
> ours opens up an editor where you do have a possibility to tweak the
> message as you wish so this should be pretty easy to incorporate into
> the workflow?
> 
> On Thu, 18 Aug 2022 at 16:36, Josh McKenzie  wrote:
> >
> > Until IDEs auto cross-reference JIRA,
> >
> > I'm going to lightly touch the lid of Pandora's Box here and walk away 
> > slowly. It drives me *nuts* when I'm git blaming a file to understand the 
> > context of why a change was made (to make sure I continue to respect it!) 
> > and I see "merge 3.11 into trunk" or some other such useless commit 
> > message, then have to dig into the git integration and history, then figure 
> > out which merge commits were real and which were -s ours and silently 
> > changed, etc.
> >
> > So about those merge commits... ;)
> >
> > Anyway - longer-form commit messages (that we also propagate into merge 
> > commits and also indicate when a merge commit makes material changes to the 
> > base branch diff) would be a large quality of life improvement as this 
> > codebase continues to mature IMO.
> >
> > On Thu, Aug 18, 2022, at 6:55 AM, Mick Semb Wever wrote:
> >
> > That's not accurate. The ASF requires that any significant contribution 
> > requires a i(CLA), committer or not.
> >
> > Is there any guidance in the ASF docs as to what qualifies as 
> > "significant"? This seems like stuff we could document pretty trivially as 
> > a project and maybe link from the PR template.
> >
> > The more we can encourage and enable folks to independently work on 
> > something and pull the trigger on contributing to the project, the better.
> 

Re: [Proposal] add pull request template

[Stefan Miklosovic]

Adding commit messages into merge commits for increased understanding
of the codebase when you are git-blaming is the absolute minimum we
can do to help you with (not only) your frustration. merging with -s
ours opens up an editor where you do have a possibility to tweak the
message as you wish so this should be pretty easy to incorporate into
the workflow?

On Thu, 18 Aug 2022 at 16:36, Josh McKenzie  wrote:
>
> Until IDEs auto cross-reference JIRA,
>
> I'm going to lightly touch the lid of Pandora's Box here and walk away 
> slowly. It drives me *nuts* when I'm git blaming a file to understand the 
> context of why a change was made (to make sure I continue to respect it!) and 
> I see "merge 3.11 into trunk" or some other such useless commit message, then 
> have to dig into the git integration and history, then figure out which merge 
> commits were real and which were -s ours and silently changed, etc.
>
> So about those merge commits... ;)
>
> Anyway - longer-form commit messages (that we also propagate into merge 
> commits and also indicate when a merge commit makes material changes to the 
> base branch diff) would be a large quality of life improvement as this 
> codebase continues to mature IMO.
>
> On Thu, Aug 18, 2022, at 6:55 AM, Mick Semb Wever wrote:
>
> That's not accurate. The ASF requires that any significant contribution 
> requires a i(CLA), committer or not.
>
> Is there any guidance in the ASF docs as to what qualifies as "significant"? 
> This seems like stuff we could document pretty trivially as a project and 
> maybe link from the PR template.
>
> The more we can encourage and enable folks to independently work on something 
> and pull the trigger on contributing to the project, the better.

Re: [Proposal] add pull request template

[Josh McKenzie]

> Until IDEs auto cross-reference JIRA,
I'm going to lightly touch the lid of Pandora's Box here and walk away slowly. 
It drives me *nuts* when I'm git blaming a file to understand the context of 
why a change was made (to make sure I continue to respect it!) and I see "merge 
3.11 into trunk" or some other such useless commit message, then have to dig 
into the git integration and history, then figure out which merge commits were 
real and which were -s ours and silently changed, etc.

So about those merge commits... ;)

Anyway - longer-form commit messages (that we also propagate into merge commits 
and also indicate when a merge commit makes material changes to the base branch 
diff) would be a *large* quality of life improvement as this codebase continues 
to mature IMO.

On Thu, Aug 18, 2022, at 6:55 AM, Mick Semb Wever wrote:
> That's not accurate. The ASF requires that any significant contribution 
> requires a i(CLA), committer or not.
Is there any guidance in the ASF docs as to what qualifies as "significant"? 
This seems like stuff we could document pretty trivially as a project and maybe 
link from the PR template.

The more we can encourage and enable folks to independently work on something 
and pull the trigger on contributing to the project, the better.

Re: [Proposal] add pull request template

[Mick Semb Wever]

> My understanding is that ICLA is not required for every single
> contributor. I don’t think we ask anybody to sign it unless they’re a
> committer.
>


That's not accurate. The ASF requires that any significant contribution
requires a i(CLA), committer or not.



>  I would strongly encourage that we point new contributors to the getting
> started page which should cover these details. They need to go through it
> once and not with each and every PR.
>


Yeah, totally agree.

Re: [Proposal] add pull request template

[Dinesh Joshi]

I’m all for having a consistent template but the legal disclaimer is something 
I personally dislike and will discourage contributions. My understanding is 
that ICLA is not required for every single contributor. I don’t think we ask 
anybody to sign it unless they’re a committer. Under the Apache license even 
emails to the dev or user list, jira comments, slack comments are considered 
“contributions”. We don’t have disclaimers or acknowledgment each time a 
contributor emails the dev list. I would strongly encourage that we point new 
contributors to the getting started page which should cover these details. They 
need to go through it once and not with each and every PR. Alternatively we 
could have a GitHub bot that identifies a new contributor and asks them to 
accept CoC, License agreement, etc for their first PR only.

> 
> On Aug 18, 2022, at 1:01 AM, Mick Semb Wever  wrote:
> 
> 
> 
> 
>> On Thu, 18 Aug 2022 at 08:10, Benedict  wrote:
>> > By submitting this pull request, I acknowledge that I am making a 
>> > contribution to the Apache Software Foundation under the terms and 
>> > conditions of the [Contributor's 
>> > Agreement](https://www.apache.org/licenses/contributor-agreements.html).
>> 
>> Do we expect every contributor who makes any contribution to agree to this? 
>> If we don’t, does it imply anything weird to start stipulating this for PRs 
>> only? Might be worth running past legal, as we don’t expect ICLAs to be 
>> signed for many contributions today, nor any specific assignment besides the 
>> notice at the top of any files in the contribution.
>> I’m also not convinced we should be doing much more than letting the user 
>> know they should have read and followed the style guide and contribution 
>> guide, and that before being merged a commit should include documentation 
>> and test changes - but these aren’t probably blockers for an initial review, 
>> and might discourage contributions by making the initial hurdles appear 
>> higher.
> 
>  
> It is accurate Benedict. There's past conversations at the foundation level 
> (+legal) about whether this agreement needed to be made explicitly (at the 
> time integration with github was being accepted). The verdict was that it 
> does not need to be explicit when contributing to existing files, because 
> those files are already copyright to the ASF and the contributor is not 
> requesting any change to that.
> 
> When a contribution adds new files we move towards requiring them to sign a 
> (i)CLA.
> But even, for simple contributions, this can be tackled implicitly, if fixing 
> any rat errors is on them. If the contributor puts the license header onto 
> the new files, the license includes reference to the copyright owner (being 
> the ASF).
> 
> I see no harm in providing this information. With a preference as it is just 
> as information (not a checkbox). It's a soft opinion, but I suspect the 
> majority of PRs will be from folk that know all this already and the 
> checkboxes will be ignored.
> 

Re: [Proposal] add pull request template

[Mick Semb Wever]

On Thu, 18 Aug 2022 at 08:10, Benedict  wrote:

> Yes, I strongly endorse long form commit messages, though I’m often remiss
> about them myself. Until IDEs auto cross-reference JIRA, and we start
> sanitising our JIRA summaries, a commit record is going to be a better
> description of what has been done and why.
>
> I think Jon is another proponent, who is more consistent about practicing
> what he preaches. It would be great to formalise this as an expectation, as
> if we’re honest the cost is *not* high to write a paragraph or two
> distilling the work that was done.
>


I strongly endorse long form commit messages as well. I read the history
around anything I'm patching, and am very happy when I come across well
written commits (and don't need to jump to the jira ticket).

Re: [Proposal] add pull request template

[Mick Semb Wever]

On Thu, 18 Aug 2022 at 08:10, Benedict  wrote:

> > By submitting this pull request, I acknowledge that I am making a
> contribution to the Apache Software Foundation under the terms and
> conditions of the [Contributor's Agreement](
> https://www.apache.org/licenses/contributor-agreements.html).
>
> Do we expect every contributor who makes any contribution to agree to this? 
> If we don’t, does it imply anything weird to start stipulating this for PRs 
> only? Might be worth running past legal, as we don’t expect ICLAs to be 
> signed for many contributions today, nor any specific assignment besides the 
> notice at the top of any files in the contribution.
>
> I’m also not convinced we should be doing much more than letting the user
> know they should have read and followed the style guide and contribution
> guide, and that before being merged a commit should include documentation
> and test changes - but these aren’t probably blockers for an initial
> review, and might discourage contributions by making the initial hurdles
> appear higher.
>


It is accurate Benedict. There's past conversations at the foundation level
(+legal) about whether this agreement needed to be made explicitly (at the
time integration with github was being accepted). The verdict was that it
does not need to be explicit when contributing to existing files, because
those files are already copyright to the ASF and the contributor is not
requesting any change to that.

When a contribution adds new files we move towards requiring them to sign a
(i)CLA.
But even, for simple contributions, this can be tackled implicitly, if
fixing any rat errors is on them. If the contributor puts the license
header onto the new files, the license includes reference to the copyright
owner (being the ASF).

I see no harm in providing this information. With a preference as it is
just as information (not a checkbox). It's a soft opinion, but I suspect
the majority of PRs will be from folk that know all this already and the
checkboxes will be ignored.

Re: [Proposal] add pull request template

[Benedict]

> By submitting this pull request, I acknowledge that I am making a 
> contribution to the Apache Software Foundation under the terms and conditions 
> of the [Contributor's 
> Agreement](https://www.apache.org/licenses/contributor-agreements.html).

Do we expect every contributor who makes any contribution to agree to this? If 
we don’t, does it imply anything weird to start stipulating this for PRs only? 
Might be worth running past legal, as we don’t expect ICLAs to be signed for 
many contributions today, nor any specific assignment besides the notice at the 
top of any files in the contribution.
I’m also not convinced we should be doing much more than letting the user know 
they should have read and followed the style guide and contribution guide, and 
that before being merged a commit should include documentation and test changes 
- but these aren’t probably blockers for an initial review, and might 
discourage contributions by making the initial hurdles appear higher.

> On 16 Aug 2022, at 09:01, Claude Warren, Jr via dev 
>  wrote:
> 
> 
> I am all for simplification.  How about
> 
> - start of text 
> 
> Issue resolved:  CASSANDRA-
> 
> 
>  - [ ] Jira ticket contains a description of: what is fixed, why it is 
> needed, and what branches to apply it to.
>  - [ ] Commits have been squashed to remove intermediate development commit 
> messages.
>  - [ ] Key commit messages start with the issue number (CASSANDRA-)
> 
> either
>  - [ ] this is a trivial documentation change. (e.g. fixes a typo)
> or:
>  - [ ] Tests are included.
>  - [ ] Documentation changes and/or updates are included.
>  
> 
> By submitting this pull request, I acknowledge that I am making a 
> contribution to the Apache Software Foundation under the terms and conditions 
> of the [Contributor's 
> Agreement](https://www.apache.org/licenses/contributor-agreements.html).
> 
> See the [Apache Cassandra "Contributing to Cassandra" 
> guide](https://cassandra.apache.org/_/development/index.html) and/or the 
> [Apache Cassandra "Working on Documentation" 
> guide](https://cassandra.apache.org/_/development/documentation.html)
> 
>  
>  end of text 
> 
>> On Tue, Aug 16, 2022 at 8:42 AM Erick Ramirez  
>> wrote:
>> +1 this is a great idea. But personally, I'm not too fussed about the level 
>> of detail that is in the template -- what is important is that contributors 
>> are reminded that there needs to be a ticket associated with contributions. 
>> Without being too prescriptive, aspiring contributors should really 
>> familiarise themselves with how to contribute[1] so they would know to 
>> search existing tickets first to avoid things like duplication.
>> 
>>  Additionally, I personally prefer details about a contribution to be 
>> documented in a ticket rather than a PR because information stored in 
>> tickets are more persistent. Having said that, it doesn't hurt to have the 
>> details included in the PR as long as it is in the ticket too. Cheers!

Re: [Proposal] add pull request template

[Benedict]

Yes, I strongly endorse long form commit messages, though I’m often remiss 
about them myself. Until IDEs auto cross-reference JIRA, and we start 
sanitising our JIRA summaries, a commit record is going to be a better 
description of what has been done and why.

I think Jon is another proponent, who is more consistent about practicing what 
he preaches. It would be great to formalise this as an expectation, as if we’re 
honest the cost is not high to write a paragraph or two distilling the work 
that was done.

> On 16 Aug 2022, at 17:36, Josh McKenzie  wrote:
> 
> 
>> 
>> something more descriptive like "Describe what the pull request fixes, why 
>> it is needed, and what branch(s) you expect it to be applied to."
> I recall us having a conversation a long while ago about our commit messages 
> and whether they're optimal in their current format (defer all context to 
> JIRA) or whether there's value in adding a longer form digest of context in a 
> paragraph below the commit.
> 
> Over time I've become more sympathetic to the approach of informative 
> long-form bodies (I think you advocated for this in the past Benedict?) - 
> google does a decent job of documenting the process and reasoning here: 
> https://google.github.io/eng-practices/review/developer/cl-descriptions.html
> 
> One of the benefits of including information about the context of what you're 
> doing in the commit message, even if it's redundant with the JIRA ticket, is 
> that someone in-IDE using integrated annotation/blame can get the "why" of a 
> code-change in their existing workflow without having to jump out to a JIRA 
> ticket where the signal/noise ratio is often much poorer. This efficiency or 
> inefficiency is magnified the more historical patches you need to understand 
> to understand the context of the change you're making.
> 
> Changing our commit message process to include this would also translate into 
> having that information available in PR's, and in the PR description body, 
> which we could easily lift over to the commit itself and/or JIRA ticket.
> 

Re: [Proposal] add pull request template

[Erick Ramirez]

Yes, it's me. Guilty as charged. 

I appreciate the acknowledgement. Cheers!

On Thu, 18 Aug 2022 at 03:00, Amit Aggarwal 
wrote:

> Hi Erick,
>
> If you are the same Erick, Thank you for answering lots of questions
> related to Cassandra on stack overflow.
>
>
> Thanks
> Amit Aggarwal
>
> On 16-Aug-2022, at 2:28 PM, Erick Ramirez 
> wrote:
>
> I forgot to mention that whatever gets decided, I think it should be
> implemented across all GitHub repos of the project. See here for the
> complete list -- https://projects.apache.org/committee.html?cassandra.
> Cheers!
>
>
>
> *The content of this e-mail is confidential and is intended solely for the
> use of the individual or entity to whom it is addressed. If you have
> received this e-mail by mistake, please reply to this e-mail and follow
> with its deletion. If you are not the intended recipient, please note that
> it shall be considered unlawful to copy, forward or in any manner reveal
> the contents of this e-mail or any part thereof to anyone. Although
> Freshworks has taken reasonable precautions to ensure no malware is present
> in this e-mail, Freshworks cannot accept responsibility for any loss or
> damage arising from the use of this e-mail or attachments.*

Re: [Proposal] add pull request template

[Amit Aggarwal]

Hi Erick, 

If you are the same Erick, Thank you for answering lots of questions related to 
Cassandra on stack overflow. 


Thanks
Amit Aggarwal 

> On 16-Aug-2022, at 2:28 PM, Erick Ramirez  wrote:
> 
> I forgot to mention that whatever gets decided, I think it should be 
> implemented across all GitHub repos of the project. See here for the complete 
> list -- https://projects.apache.org/committee.html?cassandra 
> . Cheers!


-- 
**The content of this e-mail is confidential and is intended solely for the 
use of the individual or entity to whom it is addressed. If you have 
received this e-mail by mistake, please reply to this e-mail and follow 
with its deletion. If you are not the intended recipient, please note that 
it shall be considered unlawful to copy, forward or in any manner reveal 
the contents of this e-mail or any part thereof to anyone. Although 
Freshworks has taken reasonable precautions to ensure no malware is present 
in this e-mail, Freshworks cannot accept responsibility for any loss or 
damage arising from the use of this e-mail or attachments.**

Re: [Proposal] add pull request template

[Josh McKenzie]

> something more descriptive like "Describe what the pull request fixes, why it 
> is needed, and what branch(s) you expect it to be applied to."
I recall us having a conversation a long while ago about our commit messages 
and whether they're optimal in their current format (defer all context to JIRA) 
or whether there's value in adding a longer form digest of context in a 
paragraph below the commit.

Over time I've become more sympathetic to the approach of informative long-form 
bodies (I think you advocated for this in the past Benedict?) - google does a 
decent job of documenting the process and reasoning here: 
https://google.github.io/eng-practices/review/developer/cl-descriptions.html

One of the benefits of including information about the context of what you're 
doing in the commit message, even if it's redundant with the JIRA ticket, is 
that someone in-IDE using integrated annotation/blame can get the "why" of a 
code-change in their existing workflow without having to jump out to a JIRA 
ticket where the signal/noise ratio is often much poorer. This efficiency or 
inefficiency is magnified the more historical patches you need to understand to 
understand the context of the change you're making.

Changing our commit message process to include this would also translate into 
having that information available in PR's, and in the PR description body, 
which we could easily lift over to the commit itself and/or JIRA ticket.

Re: [Proposal] add pull request template

[Erick Ramirez]

I forgot to mention that whatever gets decided, I think it should be
implemented across all GitHub repos of the project. See here for the
complete list -- https://projects.apache.org/committee.html?cassandra.
Cheers!

Re: [Proposal] add pull request template

[Claude Warren, Jr via dev]

I am all for simplification.  How about

- start of text 

Issue resolved:  CASSANDRA-



 - [ ] Jira ticket contains a description of: what is fixed, why it is
needed, and what branches to apply it to.

 - [ ] Commits have been squashed to remove intermediate development
commit messages.

 - [ ] Key commit messages start with the issue number (CASSANDRA-)


either - [ ] this is a trivial documentation change. (e.g. fixes a typo)

or:
 - [ ] Tests are included.
 - [ ] Documentation changes and/or updates are included.


By submitting this pull request, I acknowledge that I am making a
contribution to the Apache Software Foundation under the terms and
conditions of the [Contributor's
Agreement](https://www.apache.org/licenses/contributor-agreements.html).


See the [Apache Cassandra "Contributing to Cassandra"
guide](https://cassandra.apache.org/_/development/index.html) and/or
the [Apache Cassandra "Working on Documentation"
guide](https://cassandra.apache.org/_/development/documentation.html)



 end of text 

On Tue, Aug 16, 2022 at 8:42 AM Erick Ramirez 
wrote:

> +1 this is a great idea. But personally, I'm not too fussed about the
> level of detail that is in the template -- what is important is that
> contributors are reminded that there needs to be a ticket associated with
> contributions. Without being too prescriptive, aspiring contributors should
> really familiarise themselves with how to contribute[1] so they would know
> to search existing tickets first to avoid things like duplication.
>
>  Additionally, I personally prefer details about a contribution to be
> documented in a ticket rather than a PR because information stored in
> tickets are more persistent. Having said that, it doesn't hurt to have the
> details included in the PR as long as it is in the ticket too. Cheers!
>
>>

Re: [Proposal] add pull request template

[Erick Ramirez]

Sorry. I hit "send" before pasting the link:

[1] https://cassandra.apache.org/_/development/patches.html

Re: [Proposal] add pull request template

[Erick Ramirez]

+1 this is a great idea. But personally, I'm not too fussed about the level
of detail that is in the template -- what is important is that contributors
are reminded that there needs to be a ticket associated with contributions.
Without being too prescriptive, aspiring contributors should really
familiarise themselves with how to contribute[1] so they would know to
search existing tickets first to avoid things like duplication.

 Additionally, I personally prefer details about a contribution to be
documented in a ticket rather than a PR because information stored in
tickets are more persistent. Having said that, it doesn't hurt to have the
details included in the PR as long as it is in the ticket too. Cheers!

>

Re: [Proposal] add pull request template

[Mick Semb Wever]

> If there is consensus that the PR template is a good idea, I'll create a
> branch and we can wrangle the words.
>
> I think the pull request generally is against a specific branch but having
> the branch listed in the template is not a bad idea.  I do want to avoid
> having too many questions.  We could change the text "Pull request
> Description:" to be something more descriptive like "Describe what the
> pull request fixes, why it is needed, and what branch(s) you expect it to
> be applied to."
>
> Or perhaps the branch question should be separate. Opinions?
>


Repeating Stefan, for in-tree patches this information is to go into the
jira ticket.

But I'm +1 on a template providing the important contribution information
and links (the bottom bit you wrote). Also a good place to remind folk that
a jira ticket is required.

Re: [Proposal] add pull request template

[Claude Warren, Jr via dev]

If there is consensus that the PR template is a good idea, I'll create a
branch and we can wrangle the words.

I think the pull request generally is against a specific branch but having
the branch listed in the template is not a bad idea.  I do want to avoid
having too many questions.  We could change the text "Pull request
Description:" to be something more descriptive like "Describe what the pull
request fixes, why it is needed, and what branch(s) you expect it to be
applied to."

Or perhaps the branch question should be separate. Opinions?



On Mon, Aug 15, 2022 at 10:00 AM Stefan Miklosovic <
stefan.mikloso...@instaclustr.com> wrote:

> I like auto linking, definitely a handy feature.
>
> I am not sure about the content of the pull request description. I
> would include what that PR is actually for / why it is necessary to
> merge it and into what branches a contributor expects that PR to be
> merged in. However, this might be omitted if all this information is
> in a JIRA ticket already, I find the correct auto linking to be the
> most crucial here.
>
> There might be a bullet point for adding relevant CI builds (Jenkins or
> Circle).
>
> I am not sure we are going to enforce a commit message to start with
> the issue number. The issue number is already mentioned in the commit
> message. I feel like this kind of stuff is not crucial for a PR to be
> opened, a committer who is actually going to merge it will take extra
> time and care when it comes to these formalities anyway. The reason
> why a PR should be merged should be the priority.
>
> On Mon, 15 Aug 2022 at 10:41, Claude Warren, Jr via dev
>  wrote:
> >
> > Github provides the ability to add a pull request template [1].  I think
> that such a template could assist in making the pull requests better.
> Something like the text below, along with verifying that CASSANDRA-### will
> link to Jira [2], should provide the information needed and remind
> submitters of what is desired.
> >
> > If there is agreement here, I'll open a pull request to add the
> documentation and ask Apache devops to verify that the CASSANDRA-### will
> link to Jira.
> >
> > Claude
> >
> > [1]
> https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repository
> for more information.
> >  [2]
> https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/configuring-autolinks-to-reference-external-resources
> >
> > - start of text
> >
> > Issue resolved #  CASSANDRA-
> >
> > Pull request Description:
> >
> >
> >
> > 
> >
> > - [ ] Commits have been squashed to remove intermediate development
> commit messages.
> >  - [ ] Key commit messages start with the issue number (CASSANDRA-)
> >
> >
> > either
> >  - [ ] this is a trivial documentation change. (e.g. fixes a typo)
> >
> > or:
> >  - [ ] Tests are included.
> >  - [ ] Documentation changes and/or updates are included.
> >
> >
> > By submitting this pull request, I acknowledge that I am making a
> contribution to the Apache Software Foundation under the terms and
> conditions of the [Contributor's Agreement](
> https://www.apache.org/licenses/contributor-agreements.html).
> >
> > 
> >
> > See the [Apache Cassandra "Contributing to Cassandra" guide](
> https://cassandra.apache.org/_/development/index.html) and/or the [Apache
> Cassandra "Working on Documentation" guide](
> https://cassandra.apache.org/_/development/documentation.html)
>

Re: [Proposal] add pull request template

[Stefan Miklosovic]

I like auto linking, definitely a handy feature.

I am not sure about the content of the pull request description. I
would include what that PR is actually for / why it is necessary to
merge it and into what branches a contributor expects that PR to be
merged in. However, this might be omitted if all this information is
in a JIRA ticket already, I find the correct auto linking to be the
most crucial here.

There might be a bullet point for adding relevant CI builds (Jenkins or Circle).

I am not sure we are going to enforce a commit message to start with
the issue number. The issue number is already mentioned in the commit
message. I feel like this kind of stuff is not crucial for a PR to be
opened, a committer who is actually going to merge it will take extra
time and care when it comes to these formalities anyway. The reason
why a PR should be merged should be the priority.

On Mon, 15 Aug 2022 at 10:41, Claude Warren, Jr via dev
 wrote:
>
> Github provides the ability to add a pull request template [1].  I think that 
> such a template could assist in making the pull requests better.  Something 
> like the text below, along with verifying that CASSANDRA-### will link to 
> Jira [2], should provide the information needed and remind submitters of what 
> is desired.
>
> If there is agreement here, I'll open a pull request to add the documentation 
> and ask Apache devops to verify that the CASSANDRA-### will link to Jira.
>
> Claude
>
> [1] 
> https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repository
>  for more information.
>  [2] 
> https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/configuring-autolinks-to-reference-external-resources
>
> - start of text
>
> Issue resolved #  CASSANDRA-
>
> Pull request Description:
>
>
>
> 
>
> - [ ] Commits have been squashed to remove intermediate development commit 
> messages.
>  - [ ] Key commit messages start with the issue number (CASSANDRA-)
>
>
> either
>  - [ ] this is a trivial documentation change. (e.g. fixes a typo)
>
> or:
>  - [ ] Tests are included.
>  - [ ] Documentation changes and/or updates are included.
>
>
> By submitting this pull request, I acknowledge that I am making a 
> contribution to the Apache Software Foundation under the terms and conditions 
> of the [Contributor's 
> Agreement](https://www.apache.org/licenses/contributor-agreements.html).
>
> 
>
> See the [Apache Cassandra "Contributing to Cassandra" 
> guide](https://cassandra.apache.org/_/development/index.html) and/or the 
> [Apache Cassandra "Working on Documentation" 
> guide](https://cassandra.apache.org/_/development/documentation.html)

[Proposal] add pull request template

[Claude Warren, Jr via dev]

Github provides the ability to add a pull request template [1].  I think
that such a template could assist in making the pull requests better.
Something like the text below, along with verifying that CASSANDRA-### will
link to Jira [2], should provide the information needed and remind
submitters of what is desired.

If there is agreement here, I'll open a pull request to add the
documentation and ask Apache devops to verify that the CASSANDRA-### will
link to Jira.

Claude

[1]
https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repository
for more information.
 [2]
https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/configuring-autolinks-to-reference-external-resources

- start of text

Issue resolved #  CASSANDRA-

Pull request Description:





- [ ] Commits have been squashed to remove intermediate development
commit messages.
 - [ ] Key commit messages start with the issue number (CASSANDRA-)


either - [ ] this is a trivial documentation change. (e.g. fixes a typo)

or:
 - [ ] Tests are included.
 - [ ] Documentation changes and/or updates are included.


By submitting this pull request, I acknowledge that I am making a
contribution to the Apache Software Foundation under the terms and
conditions of the [Contributor's
Agreement](https://www.apache.org/licenses/contributor-agreements.html).



See the [Apache Cassandra "Contributing to Cassandra"
guide](https://cassandra.apache.org/_/development/index.html) and/or
the [Apache Cassandra "Working on Documentation"
guide](https://cassandra.apache.org/_/development/documentation.html)