MNT: Simplify PR template#32100
Conversation
In last week's meeting we discussed maybe using one of the AI review bots and @melissawm is doing a survey. The reason I think we can get rid of the checkboxes all together is b/c I'm guessing the coding guidelines are more or less a skills document. |
| - Why is this change necessary? | ||
| - What problem does it solve? | ||
| - What is the reasoning for this implementation? |
There was a problem hiding this comment.
can this language maybe get moved to https://matplotlib.org/devdocs/devel/contribute.html#first-contributions b/c that's what it was aimed for
There was a problem hiding this comment.
Uh, oh that section has a verbatim copy of the PR template - will also need and upate, but not today anymore.
There was a problem hiding this comment.
Uh, oh that section has a verbatim copy of the PR template - will also need and upate, but not today anymore.
That dropdown is an include to this file specifically so that they're always in sync:
matplotlib/doc/devel/contribute.rst
Lines 328 to 332 in 102a1d2
There was a problem hiding this comment.
I have no strong opinions on this other than that it's too detailed for the PR template. Would you be ok with making a PR with your wording on that topic, or create an issue and assign it to me? I don't what to have the bikeshedding of the first-contribution changes in this PR.
| - [ ] *New Features* and *API Changes* are noted with a [directive and release note](https://matplotlib.org/devdocs/devel/api_changes.html#announce-changes-deprecations-and-new-features) | ||
| - [ ] Documentation complies with [general](https://matplotlib.org/devdocs/devel/document.html#write-rest-pages) and [docstring](https://matplotlib.org/devdocs/devel/document.html#write-docstrings) guidelines | ||
| ## PR quality check | ||
| <!-- Make sure to conform with the project standards. Please check the following box! --> |
There was a problem hiding this comment.
I don' t think this needs the free text explanation of the checkbox
| <!-- Make sure to conform with the project standards. Please check the following box! --> |
There was a problem hiding this comment.
Without explanation and with the shorted checkbox text, will users still understand that they should tick the box?
There was a problem hiding this comment.
I think the folks who aren't checking just aren't checking, but you can also make it sound like an attestation?
- [ ] I affirm that this PR complies with [matplotlib pull request guidelines](https://matplotlib.org/devdocs/devel/pr_guide.html#pull-request-guidelines)There was a problem hiding this comment.
I think if there are checkboxes with no explanation, it can be ambiguous whether the author or the reviewer is supposed to mark them off.
There was a problem hiding this comment.
- [ ] My PR complies with [matplotlib pull request guidelines](https://matplotlib.org/devdocs/devel/pr_guide.html#pull-request-guidelines)There was a problem hiding this comment.
Or going more formal but nothing gets stashed in a comment:
- [ ] I, the author of this PR, affirm that my PR complies with [matplotlib pull request guidelines](https://matplotlib.org/devdocs/devel/pr_guide.html#pull-request-guidelines)| the recommended next step seems overly demanding, if you would like help in | ||
| addressing a reviewer's comments, or if you have been waiting too long to hear | ||
| back on your PR.--> | ||
| - [ ] I am aware of and have followed the [matplotlib pull request guidelines](https://matplotlib.org/devdocs/devel/pr_guide.html#pull-request-guidelines) |
There was a problem hiding this comment.
| - [ ] I am aware of and have followed the [matplotlib pull request guidelines](https://matplotlib.org/devdocs/devel/pr_guide.html#pull-request-guidelines) | |
| - [ ] this PR complies with [matplotlib pull request guidelines](https://matplotlib.org/devdocs/devel/pr_guide.html#pull-request-guidelines) |
How does this relate to the PR template? Do you mean using it to evaluate the PR description? |
That it'd be doing the "this PR complies w/ project standards" check just like the CI already handles most of the other checks. I don't know who the checkbox is for that isn't handled w/ the nudge at the top. |
|
I think it is good to have a checkbox rather than just a nudge in the comments.
Removing the existing checklist probably means I will forget to add directives more often! |
Closes matplotlib#32093. This is radically reduced to the essence. We many discuss the single quality check box. But I felt ticking one box may still be a reasonable checkpoint to rethink the PR. If quality check was only informative text, it would likely be ignored much more. My fear is rather that people do not understand that they should tick the box. Note: this is a template I myself would be willing to use :)
|
Based on #32100 (comment) I have scaled back and left the original checkboxes for now. We can do bikeshedding on the checks later in a follow-up. It may also be a good idea to sync and mirror the checklist items from the PR guide(https://matplotlib.org/devdocs/devel/pr_guide.html#summary-for-pull-request-authors) here in an abbreviated form so that we don't have to have all the individual links here. Links are notoriously ugly in the PR template as it is read and edited as raw text. But that likely needs a synced rewrite in the template and PR guide, which is beyond the scope of this PR. |
Would you be opposed to something like the include we do for the new contributors guide? |
I would do different fomatting, and maybe even verbosity. The template should only have a single top-level link and short checkpoints, e.g.: The PR guide could have links and if suitable slightly longer explanations, e.g.:
|
| ## PR quality check | ||
| <!-- | ||
| Make sure to conform with the project standards: https://matplotlib.org/devdocs/devel/pr_guide.html#pull-request-guidelines | ||
| Please check the following box! |
There was a problem hiding this comment.
| Please check the following box! | |
| Please check the relevant boxes below! |
?
| non-numeric input to set_xlim" and avoid non-descriptive titles such as "Addresses | ||
| issue #8576". | ||
| ## AI Disclosure | ||
| <!-- Please describe if and how AI is used. See also our AI policy: https://matplotlib.org/devdocs/devel/contribute.html#use-of-generative-ai --> |
There was a problem hiding this comment.
Either here or in the AI policy I'd like to add a line about not having AI write or clean up / polish PR descriptions or comments
| --> | ||
|
|
||
| ## PR checklist | ||
| <!-- Please mark any checkboxes that do not apply to this PR as [N/A].--> |
There was a problem hiding this comment.
I think checkboxes without some direction on what to do when they don't apply is confusing.
| ## PR checklist | ||
| <!-- Please mark any checkboxes that do not apply to this PR as [N/A].--> | ||
|
|
||
| - [ ] "closes #0000" is in the body of the PR description to [link the related issue](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) |
There was a problem hiding this comment.
Would prefer to keep this.
| - [ ] "closes #0000" is in the body of the PR description to [link the related issue](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) | ||
| - [ ] new and changed code is [tested](https://matplotlib.org/devdocs/devel/testing.html) | ||
| - [ ] *Plotting related* features are demonstrated in an [example](https://matplotlib.org/devdocs/devel/document.html#write-examples-and-tutorials) | ||
| - [ ] *New Features* and *API Changes* are noted with a [directive and release note](https://matplotlib.org/devdocs/devel/api_changes.html#announce-changes-deprecations-and-new-features) |
There was a problem hiding this comment.
| - [ ] *New Features* and *API Changes* are noted with a [directive and release note](https://matplotlib.org/devdocs/devel/api_changes.html#announce-changes-deprecations-and-new-features) | |
| - [ ] *New Features* and *API Changes* have [release notes](https://matplotlib.org/devdocs/devel/api_changes.html#announce-changes-deprecations-and-new-features) |
| <!-- Please mark any checkboxes that do not apply to this PR as [N/A].--> | ||
|
|
||
| - [ ] "closes #0000" is in the body of the PR description to [link the related issue](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) | ||
| - [ ] new and changed code is [tested](https://matplotlib.org/devdocs/devel/testing.html) |
There was a problem hiding this comment.
| - [ ] new and changed code is [tested](https://matplotlib.org/devdocs/devel/testing.html) | |
| - [ ] New and changed code is [tested](https://matplotlib.org/devdocs/devel/testing.html) |
|
|
||
| ## PR summary | ||
| <!-- Please describe the pull request, using the questions below as guidance, and link to any relevant issues and PRs: | ||
| <!-- Please describe what issue is resolved and why you chose this solution. --> |
There was a problem hiding this comment.
| <!-- Please describe what issue is resolved and why you chose this solution. --> | |
| <!-- | |
| Please describe what problem this resolves and why you chose this solution. | |
| Write "Closes #00000" if this fixes [an existing issue](https://github.com/matplotlib/matplotlib/issues). | |
| --> |
I think this should remain either here or in the checklist.
There was a problem hiding this comment.
I suggested we use issue instead of problem b/c they're close enough synonyms but Issue contains the link back to issues.
Closes #32093.
This is radically reduced to the essence.
We many discuss the single quality check box. But I felt ticking one box may still be a reasonable checkpoint to rethink the PR. If quality check was only informative text, it would likely be ignored much more. My fear is rather that people do not understand that they should tick the box.
Note: this is a template I myself would be willing to use :)