Chore: add prerequisites checklist to PR template #12790
Conversation
eslint-deprecated
bot
added
the
triage
kaicataldo
changed the title
kaicataldo
added
chore
| ESLint adheres to the [JS Foundation Code of Conduct](https://js.foundation/community/code-of-conduct). | ||
| --> | ||
|
|
||
| **What is the purpose of this pull request? (put an "X" next to item)** | ||
| #### Prerequisites checklist |
There was a problem hiding this comment.
These were changed because markdownlint now warns on using emphasized text as headers (MD036/no-emphasis-as-heading/no-emphasis-as-header). This should look the same to the end user.
.github/PULL_REQUEST_TEMPLATE.md
Outdated
| #### Prerequisites checklist | ||
|
|
||
| - [ ] I have read the [contributing guidelines](https://raw.githubusercontent.com/eslint/eslint/master/templates/bug-report.md). | ||
| - [ ] The team has reached consensus on the changes proposed in this pull request. If not, I understand that the process will begin with this pull request and won't be merged until it has been accepted. |
There was a problem hiding this comment.
Not critical, but could this say "I understand that the [evaluation/consensus] process will begin with this pull request and won't be merged until it has been accepted"?
Also, I think we're conflating "team has reached consensus" with "issue is accepted". This is correct from the perspective of our process, but a newcomer may not understand that intuitively. It would be great if we could use the same verb phrase throughout the sentence, to the extent it is feasible.
There was a problem hiding this comment.
Good idea! Updated - please let me know what you think.
kaicataldo
removed
the
evaluating
|
Removing the evaluating label since this is a chore. |
* Chore: add prerequisites checklist to PR template * Add friendly message at top * Address feedback
eslint-deprecated
bot
added
the
archived due to age
What is the purpose of this pull request? (put an "X" next to item)
[ ] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[ ] Add something to the core
[X] Other, please explain:
Updating our PR template text
What changes did you make? (Give an overview)
I've been noticing that we're getting an increasing number of PRs that do not have a corresponding accepted issue. While we have a process in place to handle this, I can imagine it doesn't feel great as the PR author to make a PR that then doesn't get merged. This is a proposed solution to hopefully make it clearer to PR authors what the team's process is and what expectations we have of them as well as what they can expect from us.
Is there anything you'd like reviewers to focus on?
Thoughts on this solution? Do you think something else might work better?