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

github: Add pull request template. #1071

Merged
merged 1 commit into from
Jul 10, 2021
Merged

Conversation

neiljp
Copy link
Collaborator

@neiljp neiljp commented Jul 8, 2021

What does this PR do?

Adds a pull request template, like I'm using here :)

Take a look at the raw and rendered versions to get a full idea of the contributor experience.

Tested?

  • Manually
  • Tests adapted (if necessary)
  • Tests added/changed for any new behavior
  • Passed linting & tests (overall PR)
  • Passed linting & tests (each commit)

Notes/Doubts/Concerns/Questions

This is more detailed than others I've seen, eg. https://raw.githubusercontent.com/zulip/zulip/master/.github/pull_request_template.md

Do we need the top title? Or feature/bug boxes? (except for suggesting what it may fix?)

Do the testing boxes help? Do they just take up space?

@neiljp neiljp added the area: infrastructure Project infrastructure label Jul 8, 2021
Copy link
Member

@zee-bit zee-bit left a comment

Choose a reason for hiding this comment

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

Thanks for getting this done, Neil. It already looks amazing. 👍

This is going to be very helpful, particularly, for new contributors. It will also be helpful for reviewers in getting to know what the PR does (abstractly), and how ready it is - is it properly tested, does the linting pass are the test added yet. Reviewers can also provide suggestions for any "Notes/Concerns" that the author has mentioned in the PR template without looking at the code - if possible too.

Overall description goes here!

- [ ] New Feature?
- [ ] Fixes Bug? [Fixes <issue>; Partially <issue> | Fixes point <n> of <issue> | Resolves an issue that's not filed]
Copy link
Member

Choose a reason for hiding this comment

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

Perhaps also include the discussion link, if there's no issue filed for the fix?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Good point, though I think that's a separate entry to suggest including.

Comment on lines 13 to 14
- [ ] Tests adapted (if necessary)
- [ ] Tests added/changed for any new behavior
Copy link
Member

Choose a reason for hiding this comment

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

Does the "adapted" and "changed" carry the same meaning here? Then we could remove the first check-box?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

The intent is to ensure that existing tests still pass, via slight changes if necessary - which is distinct from covering different new behavior. Perhaps the two should be explicitly "Existing tests pass (adapted if necessary)" and "New tests added (if new behavior)". Maybe they're too long though.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Maybe we could follow the same wording as in the commit style guide?
Tests added (new feature)
Tests updated (refactor/feature that needs minor amending in existing tests)

Copy link
Member

Choose a reason for hiding this comment

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

@Rohitth007 I think that'd require the contributor to explicitly write details in parenthesis? I believe we're keener on the tests in the PR in general, and specific additions/amendments are addressed in commits in any case.

Copy link
Collaborator

Choose a reason for hiding this comment

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

@Ezio-Sarthak No, I just used the parenthesis for explaining added vs updated here

Comment on lines 18 to 20
<!-- See https://github.com/zulip/zulip-terminal#commit-style -->
**Commit flow** <!-- if more than one commit; add/delete/fill-in as appropriate -->
* first commit doing some thing
Copy link
Member

Choose a reason for hiding this comment

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

Although I've used this field in some of my own PR's, I wonder if it's really necessary?
The "Commit flow" is essentially just the commit headers, as we have documented in that link, which can be easily accessed from the commits tab at the top?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I agree the commit list can be seen in the PR itself - and does change over time, often, and it's not necessary to keep updating the text here as that happens.

I do feel we could benefit from having something here though - maybe others would like to weigh in.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Even I feel it's redundant sometimes. Maybe it's could be summarized in the summary section if needed, like the first few are related to this, the others are related to that and so on.

We could always implement and see how people use it.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@Rohitth007 That's what the examples are intended to indicate, ie. that it's a summary. I meant to include that they're only ~ commit titles, but I don't want to motivate just copy and pasting those either.

* maybe multiple commits doing similar things
* ...

**Notes/Doubts/Concerns/Questions** <!-- if any; add/delete/fill-in as appropriate -->
Copy link
Member

Choose a reason for hiding this comment

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

This field is great. 👍
Can we simplify the title to just "Notes/Concerns"?
Doubts/Concerns/Questions sounds pretty similar to me.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I agree 4 is too many. Maybe just "Notes" and push the possible content into the examples.

Of course the titles are editable/removable, but people may not think that, so simple titles may be easier as users are more likely to think to at least fill in their own content I hope :)

@neiljp
Copy link
Collaborator Author

neiljp commented Jul 8, 2021

I'm more inclined to remove the first 3 checkboxes as GitHub includes them as a list of tasks - which they are not. I'm not sure there's an easy alternative, but we can simply hint at these elements in the description prompt, or in the commit flow perhaps too?

Copy link
Member

@preetmishra preetmishra left a comment

Choose a reason for hiding this comment

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

@neiljp Thanks for working on this! 👍 This looks great. I have left a minor in-line comment.


**Interactions** <!-- if any; add/delete/fill-in as appropriate -->
- Waiting on other PR(s)? What numbers?
- Blocks other PR(s)? What numbers?
Copy link
Member

Choose a reason for hiding this comment

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

Should these two points exist as a comment like the above two sections?

@neiljp neiljp merged commit a3ca1a5 into zulip:main Jul 10, 2021
@neiljp neiljp added this to the Next Release milestone Jul 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants