Re: [Proposal] add pull request template
+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
Sorry. I hit "send" before pasting the link: [1] https://cassandra.apache.org/_/development/patches.html
Re: [Proposal] add pull request template
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
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
> 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.
