Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added a Pull Request Template #17856

Merged
merged 1 commit into from Mar 4, 2024

Conversation

erosselli
Copy link
Contributor

@erosselli erosselli commented Feb 14, 2024

Description

As discussed in this Django Forum thread, this is a proposal for a Pull Request Template for Django. Any feedback or comments are welcome!

Copy link
Member

@smithdc1 smithdc1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it bad that as a somewhat regular contributor, I see myself just deleting this 😬

@felixxm
Copy link
Member

felixxm commented Feb 15, 2024

Is it bad that as a somewhat regular contributor, I see myself just deleting this 😬

No, it's not 🤗 I'd be forced to do the same every time. We could put this in a comment (<!-- ... -->) to reduce inconvenience for regular contributors.

Link to the accepted Trac ticket for this PR. All PRs except docs or tests changes need an accepted ticket. New features need community consensus.

# Tests
Briefly describe any tests you have added or updated to test the changes introduced by the PR
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is that generally expected? I feel like having the tests in the checklist is good enough – asking people to describe the tests they've written feels like a sure-fire way to get the paragraph deleted entirely.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree 👍

Additionally when we're also draining people's cognitive resources by adding too much stuff to read so repetitive things should be removed.

Less is more :)

Briefly describe any tests you have added or updated to test the changes introduced by the PR

# Checklist
- [ ] I have updated the Trac ticket’s flags
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As Trac isn't super intuitive, I think it would be helpful to tell users what to do exactly (ie set "has patch" on the ticket).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- [ ] I have updated the Trac ticket’s flags
- [ ] I have updated the "has patch" Trac ticket

- [ ] I have added or updated tests to test the changes I made
- [ ] I have added or updated relevant documentation (if applicable)

# More details
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure this section is a good idea, tbh, for multiple reasons:

  • When you open a PR, GitHub shows you a sidebar linking to the contributing.rst, which in turn links to the contribution docs.
  • The "Working with git" documentation is probably not the most relevant once people are already about to open a PR
  • The PR template is opened in an editable text box, so using Markdown format is cumbersome, as you either have to manually select the link, or switch to the preview panel to click it
  • IME, the template should be as short as possible (so people don't just delete it entirely), and only contain things that should end up in the PR text – not least of all because you can search PRs, and leaving this section in would potentially clutter up the search.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure this section is a good idea, tbh, for multiple reasons:

* When you open a PR, GitHub shows you a sidebar linking to the contributing.rst, which in turn links [to the contribution docs](https://docs.djangoproject.com/en/dev/internals/contributing/).

While this link is helpful, I think it too broad and unspecific about the stage the author is at this point.

* The "Working with git" documentation is probably not the most relevant once people are already about to open a PR

Good point about the git docs, though there are a few sections at the bottom of that page that are very relevant for when proposing a PR and then following up during reviews. It describes rebasing and other relevant processes. I'm proposing that we tailor the link to these sections instead.

* The PR template is opened in an editable text box, so using Markdown format is cumbersome, as you either have to manually select the link, or switch to the preview panel to click it

* IME, the template should be as short as possible (so people don't just delete it entirely), and only contain things that should end up in the PR text – not least of all because you can search PRs, and leaving this section in would potentially clutter up the search.

We have many contributors not following the process of having a ticket, adding tests, adding docs, setting the trac flags for a PR. I believe that they are not following the expected procedure because they don't know about it (not because they ignore it). And I think that they don't know about it because they got lost in the contributing docs (I've been there!). More so, I think that while is likely that (new?) contributors are familiar with GH, they are not with other systems or may be discouraged by the need to jump between the docs site, the trac site, and this site.

With this information, do you think there is something we could do to improve the contributor experience and, consequently, help reviewers receive more complete PRs?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The PR template is opened in an editable text box, so using Markdown format is cumbersome, as you either have to manually select the link, or switch to the preview panel to click it

I think I agree with @rixx in that this information might be better placed elsewhere, since having doc links in a PR template can make the template overcrowded with info, and the fact that even opening the links from the template is a bit cumbersome is a good point.

I agree that it's easy to get lost in the contributing docs, but maybe that's something we need to fix separately?

@smithdc1
Copy link
Member

No, it's not 

OK great. So it sounds like the target audience of this is not regular contributors.

@erosselli could you help explain who's experience (or maybe persona of user) you are aiming to improve with this change? I think with that in mind it will aid review of the content. Thanks for your efforts here!

@LilyFoote
Copy link
Contributor

I think the checklist is a good thing to have and would also be useful for experienced contributors as a reminder.

Copy link
Contributor

@nessita nessita left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you @erosselli! I think this is a solid step forward improving the contributor experience and to help reviewers receive more complete PRs.

Please do not forget to wrap lines at 79cols!

.github/pull_request_template.md Outdated Show resolved Hide resolved
.github/pull_request_template.md Outdated Show resolved Hide resolved
Briefly describe any tests you have added or updated to test the changes introduced by the PR

# Checklist
- [ ] I have updated the Trac ticket’s flags
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- [ ] I have updated the Trac ticket’s flags
- [ ] I have updated the "has patch" Trac ticket

.github/pull_request_template.md Outdated Show resolved Hide resolved
.github/pull_request_template.md Outdated Show resolved Hide resolved
.github/pull_request_template.md Outdated Show resolved Hide resolved
.github/pull_request_template.md Outdated Show resolved Hide resolved
.github/pull_request_template.md Outdated Show resolved Hide resolved
.github/pull_request_template.md Outdated Show resolved Hide resolved
- [ ] I have added or updated tests to test the changes I made
- [ ] I have added or updated relevant documentation (if applicable)

# More details
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure this section is a good idea, tbh, for multiple reasons:

* When you open a PR, GitHub shows you a sidebar linking to the contributing.rst, which in turn links [to the contribution docs](https://docs.djangoproject.com/en/dev/internals/contributing/).

While this link is helpful, I think it too broad and unspecific about the stage the author is at this point.

* The "Working with git" documentation is probably not the most relevant once people are already about to open a PR

Good point about the git docs, though there are a few sections at the bottom of that page that are very relevant for when proposing a PR and then following up during reviews. It describes rebasing and other relevant processes. I'm proposing that we tailor the link to these sections instead.

* The PR template is opened in an editable text box, so using Markdown format is cumbersome, as you either have to manually select the link, or switch to the preview panel to click it

* IME, the template should be as short as possible (so people don't just delete it entirely), and only contain things that should end up in the PR text – not least of all because you can search PRs, and leaving this section in would potentially clutter up the search.

We have many contributors not following the process of having a ticket, adding tests, adding docs, setting the trac flags for a PR. I believe that they are not following the expected procedure because they don't know about it (not because they ignore it). And I think that they don't know about it because they got lost in the contributing docs (I've been there!). More so, I think that while is likely that (new?) contributors are familiar with GH, they are not with other systems or may be discouraged by the need to jump between the docs site, the trac site, and this site.

With this information, do you think there is something we could do to improve the contributor experience and, consequently, help reviewers receive more complete PRs?

@erosselli
Copy link
Contributor Author

erosselli commented Feb 17, 2024

No, it's not

OK great. So it sounds like the target audience of this is not regular contributors.

@erosselli could you help explain who's experience (or maybe persona of user) you are aiming to improve with this change? I think with that in mind it will aid review of the content. Thanks for your efforts here!

Hi @smithdc1 , I think that having a PR template can be helpful in different cases. The first case I thought of is to help new contributors, so they can know how to structure a PR & what kind of information to include in the description. The checklist can help make sure they have done everything needed (it's easy to forget things :) ). I'm a rather new contributor myself and when I opened my first PR I was surprised to see there was no template; it felt a bit daunting to write the whole thing from scratch.

The checklist also servers as a reminder for all contributors and I think could help reduce the number of contributors not following "due process" (marking flags in the ticket, adding tests or docs when needed, etc).

@smithdc1
Copy link
Member

Hi @erosselli, thank you for taking the time to write such a considered response!

I think the new contributor experience is super important.

On the topic of new contributors, they currently receive this message [1] when opening a new PR.

What's your thoughts on how these two interact? Just as a small example, I wonder about the duplication. I'd fill in the checklist in the template and then have a message to refer me to the checklist (which I've already filled in)?

[1] https://github.com/django/django/blob/main/.github%2Fworkflows%2Fnew_contributor_pr.yml

@nessita
Copy link
Contributor

nessita commented Feb 20, 2024

Hi @erosselli, thank you for taking the time to write such a considered response!

I think the new contributor experience is super important.

On the topic of new contributors, they currently receive this message [1] when opening a new PR.

What's your thoughts on how these two interact? Just as a small example, I wonder about the duplication.

From my experience, the "first time contributor" message, while valuable, has a few drawbacks:

  1. It appears a while after the PR is submitted. By then, the contributor has likely already closed or moved away from the tab, making it unclear if this message is read.
  2. Furthermore, it only appears the very first time a contributor creates a PR. For many of them, this occurs while submitting the "make toast" PR or while learning how to do a PR. I've observed many "first PRs" being opened and immediately closed (by the author) due to a mistake or missing information, resulting in the message being lost. Even if the PR is not closed, because they are absorbing a significant amount of new information in a short period, they might not (or can't) pay attention to this message, especially considering that it arrives some time after submission (as mentioned in item 1).

I'd fill in the checklist in the template and then have a message to refer me to the checklist (which I've already filled in)?

Do you mean in the "new contributor message"? If yes, this makes sense, do not duplicate the "branch review checklist".

[1] https://github.com/django/django/blob/main/.github%2Fworkflows%2Fnew_contributor_pr.yml

@erosselli
Copy link
Contributor Author

Hi @erosselli, thank you for taking the time to write such a considered response!

I think the new contributor experience is super important.

On the topic of new contributors, they currently receive this message [1] when opening a new PR.

What's your thoughts on how these two interact? Just as a small example, I wonder about the duplication. I'd fill in the checklist in the template and then have a message to refer me to the checklist (which I've already filled in)?

[1] https://github.com/django/django/blob/main/.github%2Fworkflows%2Fnew_contributor_pr.yml

Maybe the message can be updated to refer to the checklist in the PR, as a reminder, or simply remove that part of the message altogether?

@smithdc1
Copy link
Member

So should we remove the new contributor message if this is merged? 🤔

@erosselli
Copy link
Contributor Author

So should we remove the new contributor message if this is merged? 🤔

I think we can leave it, maybe rephrasing or removing some of the more repetitive parts (mainly the instructions to set the flag on the ticket & the reminder to link the ticket in the description, since the template already covers that?). There's parts of it that I think are still relevant, for example the part directing the person to ask any questions they may have on the forum :) I also think the "Welcome aboard ⛵ " message is nice :)

.github/pull_request_template.md Outdated Show resolved Hide resolved
.github/pull_request_template.md Outdated Show resolved Hide resolved
.github/pull_request_template.md Outdated Show resolved Hide resolved
.github/pull_request_template.md Outdated Show resolved Hide resolved
.github/pull_request_template.md Outdated Show resolved Hide resolved
@erosselli erosselli marked this pull request as ready for review February 28, 2024 20:22
@nessita nessita force-pushed the pull_request_template_proposal branch from 9f81f9f to 5493cba Compare March 4, 2024 13:59
Copy link
Contributor

@nessita nessita left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you @erosselli, this looks good! I pushed some edits, will land soon.

.github/pull_request_template.md Outdated Show resolved Hide resolved
Co-authored-by: Natalia <124304+nessita@users.noreply.github.com>
Co-authored-by: Paolo Melchiorre <paolo@melchiorre.org>
Co-authored-by: Adam Johnson <me@adamj.eu>
@nessita nessita force-pushed the pull_request_template_proposal branch from 5493cba to 8febdde Compare March 4, 2024 15:04
@nessita nessita merged commit 3fcef50 into django:main Mar 4, 2024
33 checks passed
@adamchainz
Copy link
Sponsor Member

I think I just became the first to fill in the template in #17936 🥳

@nessita
Copy link
Contributor

nessita commented Mar 4, 2024

I think I just became the first to fill in the template in #17936 🥳

Amazing! Any initial feedback about the template? How did it "feel"?

@adamchainz
Copy link
Sponsor Member

Overall good, it feels like the right length. Two things I noticed when using:

  1. I wrote “n/a” in the box for the UI changes checkbox because it didn't feel right to check it. Maybe different wording could fix that, like “I have attached screenshots in both light and dark modes for any UI changes.”
  2. The bolding of some words feels weird, I think that could be dropped.

@nessita
Copy link
Contributor

nessita commented Apr 23, 2024

Overall good, it feels like the right length. Two things I noticed when using:

1. I wrote “n/a” in the box for the UI changes checkbox because it didn't feel right to check it. Maybe different wording could fix that, like “I have attached screenshots in both light and dark modes for any UI changes.”

2. The bolding of some words feels weird, I think that could be dropped.

@adamchainz I finally got to this item in my ToDo! Here the PR: #18098

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
10 participants