Update pull request template

[colebow]

Description

• Getting rid of the various descriptive questions and consolidating them into a "non-technical explanation" header.
• Moving the comments with instructions to above the headings and adding sufficient whitespace between them, so that it's much clearer and more obvious as to where a PR author needs to fill in the template.
• Getting rid of the docs question. This was often a no-signal question, as many contributors weren't clear on what constitutes documentation, and they would mark "sufficient docs included" thinking that commented code counted as docs. It was pretty misleading, and I'd rather get rid of it just to get rid of any possible confusion. I think it'll be easier and less error-prone to check the descriptions, conclude whether or not there should be docs, and check the code changes to see if we have any .rst changes, then follow-up as needed from there.
• Adding reasons why release notes may not be necessary, as well as adding a box to ask for the maintainer/release manager to handle the RN for the change. I think this'll encourage people to think a little more critically about release notes, and it's trying to discourage saying "no release notes required" as a means of avoiding having to think about them. Open to feedback on this, I think it's where this change is the most spicy.

If we're changing the template to this, we also need to be sure that it is being filled out by everyone, always. There are three touchpoints, the first one is the most important as the broad description that helps with a review, and the other two can be very brief, especially for technical changes that aren't user-facing and shouldn't require much effort. "Just tests" or "refactor" and a single (x) will handle test changes/refactors for those last two questions, and it'd be nice to see that done for every PR with no exceptions. This change shortens it from 1-2 minutes of scrolling and trying to find the right places to type to an extremely quick and trivial process, and it should be low-friction enough for it to be used by everyone.

Alternate approach to #13916.

I would also want to accompany this change by adding #13916 (comment) to the Trino project.

Non-technical explanation

Updating the PR template on GitHub! I'm even using the new template here.

Release notes

(x) This is not user-visible and no release notes are required.
( ) Release notes are required, please propose a release note for me.
( ) Release notes are required, with the following suggested text:

[hashhar]

Can you share an example of what you think you would like to see here? I can't see the utility of this over the description above.

[colebow]

I think for a lot of things, this is going to simply be "Refactor" or "Update tests" or "Upgrade dependency version" or something along those lines, or otherwise a simple restatement of a description which is easily understood from a non-technical perspective.

As an arbitrary example where it would be helpful, on #13736, it would be useful to say something like "make sure Trino stops running if it can't secure sufficient resources" in this section, because a less-technical user won't understand what jvmkill is or why terminating the jvm matters.

The section admittedly won't provide a ton of value most of the time, but when it does, it'll help a lot with making sure release notes make sense in situations where the PR author wouldn't otherwise provide a ton of detail as to why users should care about a change.

[findepi]

Definitely a step in the right direction.

[findepi]

is it intentionally not using checkboxes (* [ ])?

checkboxes would allow the option to be marked with a click.

[colebow]

I think @mosabua told me at one point that that something in Trino's Github automation expects all of them to be ticked before a PR is merged? I've kind of just gone off of that, and I assumed it was previously made to be parentheses for a reason.

[mosabua]

Correct.. if you use [] it counts as a build action..

[findepi]

I edited description of #1394 #13941 so it includes checkboxes.
@colebow @mosabua where can i see the consequences of the fact these checkboxes are not checked yet?

[findepi]

@colebow can you please address #13947 (comment) in a followup?

[findepi]

btw many thanks for simplifying this!