#37093: Adjust GitHub PR description template + bot check error emoji
-------------------------------------+-------------------------------------
     Reporter:  Stephanie Goulet     |                     Type:
                                     |  Cleanup/optimization
       Status:  new                  |                Component:
                                     |  Uncategorized
      Version:  6.0                  |                 Severity:  Normal
     Keywords:  PR, GitHub           |             Triage Stage:
                                     |  Unreviewed
    Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------
 The below suggestions are based on the forum discussion,
 [https://forum.djangoproject.com/t/bot-checks-for-typo-prs-some-
 considerations/45028 Bot checks for typo PRs (some considerations)].

 **Suggestion 1: Adjust GitHub PR description template**
 When opening my first [https://github.com/django/django/pull/21195 PR for
 a typo fix], I ran into a little confusion which resulted in an auto-
 closed PR that might've been avoided with some small adjustments.

 I propose the following edits to the PR description template to improve
 clarity, particularly for new contributors.

 The full current and proposed templates are below, however for
 convenience, you can see the differences more easily in this
 [https://www.diffchecker.com/Eba3oc1t/ saved diff].

 Current template:
 {{{
 #### Trac ticket number
 <!-- Replace XXXXX with the corresponding Trac ticket number. -->
 <!-- Or delete the line and write "N/A - typo" for typo fixes. -->

 ticket-XXXXX

 #### Branch description
 Provide a concise overview of the issue or rationale behind the proposed
 changes.

 #### AI Assistance Disclosure (REQUIRED)
 <!-- Please select exactly ONE of the following: -->
 - [ ] **No AI tools were used** in preparing this PR.
 - [ ] **If AI tools were used**, I have disclosed which ones, and fully
 reviewed and verified their output.

 #### Checklist
 - [ ] This PR follows the [contribution
 guidelines](https://docs.djangoproject.com/en/stable/internals/contributing
 /writing-code/submitting-patches/).
 - [ ] This PR **does not** disclose a security vulnerability (see
 [vulnerability
 reporting](https://docs.djangoproject.com/en/stable/internals/security/)).
 - [ ] This PR targets the `main` branch. <!-- Backports will be evaluated
 and done by mergers, when necessary. -->
 - [ ] The commit message is written in past tense, mentions the ticket
 number, and ends with a period (see
 [guidelines](https://docs.djangoproject.com/en/dev/internals/contributing
 /committing-code/#committing-guidelines)).
 - [ ] I have not requested, and will not request, an automated AI review
 for this PR. <!-- You are welcome to do so in your own fork. -->
 - [ ] I have checked the "Has patch" ticket flag in the Trac system.
 - [ ] I have added or updated relevant tests.
 - [ ] I have added or updated relevant docs, including release notes if
 applicable.
 - [ ] I have attached screenshots in both light and dark modes for any UI
 changes.
 }}}

 Proposed template:
 {{{
 #### Trac ticket number
 <!-- Replace XXXXX with the corresponding Trac ticket number. -->
 <!-- Or delete the line and write "N/A - typo" for typo fixes. -->

 ticket-XXXXX

 #### Branch description
 <!-- Provide a concise overview of the issue or rationale behind the
 proposed changes. 5 word minimum. -->


 #### AI Assistance Disclosure (REQUIRED)
 <!-- Please select exactly ONE of the following: -->
 - [ ] **No AI tools were used** in preparing this PR.
 - [ ] **If AI tools were used**, I have disclosed which ones, and fully
 reviewed and verified their output.

 #### Checklist
 <!-- Please leave non-applicable items unchecked. -->

 - [ ] This PR follows the [contribution
 guidelines](https://docs.djangoproject.com/en/stable/internals/contributing
 /writing-code/submitting-patches/).
 - [ ] This PR **does not** disclose a security vulnerability (see
 [vulnerability
 reporting](https://docs.djangoproject.com/en/stable/internals/security/)).
 - [ ] This PR targets the `main` branch. <!-- Backports will be evaluated
 and done by mergers, when necessary. -->
 - [ ] The commit message is written in past tense, mentions the ticket
 number (if applicable), and ends with a period (see
 [guidelines](https://docs.djangoproject.com/en/dev/internals/contributing
 /committing-code/#committing-guidelines)).
 - [ ] I have not requested, and will not request, an automated AI review
 for this PR. <!-- You are welcome to do so in your own fork. -->
 - [ ] I have checked the "Has patch" ticket flag in the Trac system.
 - [ ] I have added or updated relevant tests.
 - [ ] I have added or updated relevant docs, including release notes if
 applicable.
 - [ ] I have attached screenshots in both light and dark modes for any UI
 changes.
 }}}

 ----

 **Suggestion 2: Remove the stop sign emojis from the bot check error
 messages**

 I propose replacing the [https://emojis.wiki/stop-sign/ :stop_sign:] emoji
 that is shown in the PR bot check error messages with the
 [https://emojis.wiki/right-arrow/ :right_arrow:] emoji to keep the list of
 errors eye-catching while neutralizing the color so as to reduce the
 likelihood for contributors (especially new contributors) to read the
 bright red stop sign as a little harsh. I believe the inclusion of "Error"
 before each error description as well as the fact that the PR is
 automatically closed is sufficiently clear to communicate that those
 errors need to be addressed for the PR to be reconsidered.

 Alternatively, if the specific emoji replacement of [https://emojis.wiki
 /right-arrow/ :right_arrow:] is undesired, I propose removing the
 [https://emojis.wiki/stop-sign/ :stop_sign:] emoji without a replacement
 for the same reasons as above. This alternative might be more appropriate
 if we highly value errors only ever being exclusively associated with the
 color red, but still see value in reducing the harshness factor. The trade
 off is that this loses the eye-catching factor of having an emoji next to
 the error titles which is particularly helpful when first seeing the auto
 response because the list is automatically expanded  (rightfully so, in my
 opinion) despite each error header being expandable/collapsible.

 For the record, I'm also open to other emoji options as an alternative to
 the stop sign but tried to pick the one I thought was best keeping in mind
 the feedback in the forum comments (e.g. staying away from yellow/orange,
 etc.) to make this a clearer proposed edit to review.

 See this
 [https://github.com/django/django/pull/21195#issuecomment-4352103892 bot-
 closed PR comment] as an example of where the stop sign emojis appear.
-- 
Ticket URL: <https://code.djangoproject.com/ticket/37093>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion visit 
https://groups.google.com/d/msgid/django-updates/0107019e17365805-b762c5a1-48fb-44b2-b2ba-b603f597bc97-000000%40eu-central-1.amazonses.com.

Reply via email to