[Feature Request] Remove or shorten the PR checklist

[andrross]

Is your feature request related to a problem? Please describe

I personally find the PR checklist to be rote busy work that doesn't add a lot of value. Going entry by entry:

• New functionality includes testing - This is general software development best practice. Reviewers should be enforcing this. We have code coverage metrics published on each PR as well. I'm skeptical this checklist entry is helpful.
• All tests pass - PR workflows enforce this.
• New functionality has been documented - The javadoc targets enforce this as a part of the build if this refers to javadoc. If not, then this is duplicated by the "public documentation" entry below.
• New functionality has javadoc added - Same as above
• API changes companion pull request created - I could be convinced this one should stay, maybe.
• Failing checks are inspected and point to the corresponding known issue(s) - The failing checks post a comment linking to the flaky test guide telling you want to do.
• Commits are signed per the DCO using --signoff - The DCO workflow enforces this
• Commit changes are listed out in CHANGELOG.md file (See: Changelog) - The changelog workflow enforces this.
• Public documentation issue/PR created - I could be convinced this one should stay, maybe.

Describe the solution you'd like

Remove all checklist items except the "API Changes" and "Public Documentation" entries. Maybe consider removing the entire checklist if we don't have evidence the remaining two entries are effective.

Related component

Other

[kotwanikunal]

+1 on the direction.
Ever since we have made all checks as required, items on the checklist are redundant.

[kotwanikunal]

@peternied / @dblock - Thoughts here?

[andrross]

One potential goal of the checklist is to encourage contributors to do these things before submitting a PR. However, given how many PRs I see where none of the template or checklist is filled out, I'd say the checklist has proven to be ineffective at accomplishing this goal.

[peternied]

I think of the checklist as a tool to inform on the requirements of the project and help remind maintainers what to check in on before merging a change. However, if we feel its working counter to this purpose or hindering contributions we can certainly change it.

If you were to ask me what I would target first, I wouldn't mind the removal of the sub-bullets All tests pass, New functionality has javadoc added - want to make a PR to start trimming them down?

[peternied]

However, given how many PRs I see where none of the template or checklist is filled out, I'd say the checklist has proven to be ineffective at accomplishing this goal.

@andrross I see you point; however, I'd offer an alternative perspective when I see empty PR templates its a great indicator to provide guidance to that contributor.

[reta]

@andrross thanks a lot for bringing this one up, I think keeping the checklist but making it shorter would be a good path forward:

The functionality include testing
API changes companion pull request created
Public documentation companion pull request [created] created

WDYT?

[andrross]

@reta I like it.

My remaining nitpick is that the majority of PRs do not change the REST API nor require an update to the documentation website. Is there a way to still surface those concerns when applicable without forcing every PR to check a box?

[reta]

@reta I like it.

❤️

My remaining nitpick is that the majority of PRs do not change the REST API nor require an update to the documentation website. Is there a way to still surface those concerns when applicable without forcing every PR to check a box?

I think it is hard to have a template that is equally helpful for new and existing contributors. These two checklist items basically hint people that this is not all-in-one repository but there are at least 2 others one may need to look at. But keeping it short is less annoying for the seasoned contributors, nonetheless raising the awareness for others.

[peternied]

[Triage - attendees 1 2 3 4 5 6 7]
@andrross Thanks for creating this issue, looking forward to a pull request