Skip to content

Alternative, concise PR template #2945

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.

Sign up for GitHub

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

Merged
merged 3 commits into from
Nov 4, 2025
Merged

Alternative, concise PR template #2945

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
fa3a198
Alternative, concise PR template
adutra Oct 30, 2025
32e266f
review
adutra Oct 30, 2025
35a35cb
review
adutra Nov 3, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
76 changes: 12 additions & 64 deletions .github/pull_request_template.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,65 +1,13 @@
<!--
Possible security vulnerabilities: STOP here and contact [email protected] instead!
Please update the title of the PR with a meaningful message - do not leave it "empty" or "generated"
Please update this summary field:
The summary should cover these topics, if applicable:
* the motivation for the change
* a description of the status quo, for example the current behavior
* the desired behavior
* etc
PR checklist:
- Do a self-review of your code before opening a pull request
- Make sure that there's good test coverage for the changes included in this PR
- Run tests locally before pushing a PR (./gradlew check)
- Code should have comments where applicable. Particularly hard-to-understand
areas deserve good in-line documentation.
- Include changes and enhancements to the documentation (in site/content/in-dev/unreleased)
- For Work In Progress Pull Requests, please use the Draft PR feature.
Make sure to add the information BELOW this comment.
Everything in this comment will NOT be added to the PR description.
-->

### What changes were proposed in this pull request?
<!--
Please clarify what changes you are proposing. The purpose of this section is to outline the changes and how this PR fixes the issue.
If possible, please consider writing useful notes for better and faster reviews in your PR. See the examples below.
1. If you refactor some codes with changing classes, showing the class hierarchy will help reviewers.
2. If you fix some IRC features, you can provide some references of other IRC implementations / IRC spec.
3. If there is design documentation, please add the link.
4. If there is a discussion in the mailing list, please add the link.
-->


### Why are the changes needed?
<!--
Please clarify why the changes are needed. For instance,
1. If you propose a new API, clarify the use case for a new API.
2. If you fix a bug, you can clarify why it is a bug.
-->


### Does this PR introduce _any_ user-facing change?
<!--
Note that it means *any* user-facing change including all aspects such as new features, bug fixes, or other behavior changes. Documentation-only updates are not considered user-facing changes.
If yes, please clarify the previous behavior and the change this PR proposes - provide the console output, description and/or an example to show the behavior difference if possible.
If possible, please also clarify if this is a user-facing change compared to the released Polaris versions or within the unreleased branches such as master.
If no, write 'No'.
-->


### How was this patch tested?
<!--
If tests were added, say they were added here. Please make sure to add some test cases that check the changes thoroughly including negative and positive cases if possible.
If it was tested in a way different from regular unit tests, please clarify how you tested step by step, ideally copy and paste-able, so that other reviewers can test and check, and descendants can verify in the future.
If tests were not added, please describe why they were not added and/or why it was difficult to add.
-->

### CHANGELOG.md
<!--
If the changes need to be included in CHANGELOG.md, please add a line here and in CHANGELOG.md.
-->
📝 Describe what changes you're proposing, especially breaking or user-facing changes.
📖 See https://github.com/apache/polaris/blob/main/CONTRIBUTING.md for more.
-->

## Checklist
- [ ] 🛡️ Don't disclose security issues! (contact [email protected])
- [ ] 🔗 Related issue(s): Fixes #
Copy link
Member

@snazy snazy Oct 31, 2025

Choose a reason for hiding this comment

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

Suggested change
- [ ] 🔗 Related issue(s): Fixes #
- [ ] 🔗 Related issue(s): Add `Fixes #` as a separate line

Copy link
Contributor Author

@adutra adutra Oct 31, 2025

Choose a reason for hiding this comment

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

Does it have to be on a separate line? I thought GitHub could find occurrences of Fixes # everywhere in the PR description.

Copy link
Member

@jbonofre jbonofre Oct 31, 2025

Choose a reason for hiding this comment

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

That's right, it could be in any place, including in the PR title.

Copy link
Member

@snazy snazy Oct 31, 2025

Choose a reason for hiding this comment

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

TIL

Copy link
Contributor

@singhpk234 singhpk234 Oct 31, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

This means every PR needs an issue ? The issue would contain motivation etc ?

- [ ] 🧪 Added/updated tests with good coverage
Copy link
Contributor

@singhpk234 singhpk234 Oct 31, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

[doubt] what does good means ? how is the user gonna describe manual testing done ?

- [ ] 💡 Added comments for complex logic
- [ ] ⚙️ Tested my changes with `./gradlew clean spotlessApply build`
Copy link
Contributor

@dimas-b dimas-b Oct 30, 2025

Choose a reason for hiding this comment

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

It might be preferable to mention this in the contribution guide (if not there already). CI will take care of that.... and I personally often prefer CI over complete local tests for small changes 😅

Copy link
Contributor Author

@adutra adutra Oct 30, 2025

Choose a reason for hiding this comment

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

Maybe suggest spotlessApply check in this case? We all often forget things like formatting or license headers.

Copy link
Contributor Author

@adutra adutra Oct 30, 2025

Choose a reason for hiding this comment

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

My point being: when someone opens a PR, several people get notified. It's a bit frustrating to be notified on a PR that doesn't even compile or pass the rat tests. I hope this TODO item could save us a few premature notifications :-)

Copy link
Contributor

@dimas-b dimas-b Oct 30, 2025

Choose a reason for hiding this comment

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

Contributors with than one PR get automated CI runs. First-time contributors do not get CI automatically, but I guess we need to balance the overhead of reviewing first-time contributions against the main stream of PRs from regular contributors. IMHO, having this checkbox is more of an irritation to regular contributors and I'm not convinced it is going to be effective in making first-timers actually run full tests 😅

In any case, I'm ok both the the current checkbox and with spotlessApply check.

Copy link
Member

@snazy snazy Oct 31, 2025

Choose a reason for hiding this comment

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

A relatively quick sanity check is ./gradlew spotlessApply compileAll jar, maybe with the --continue option.
But I'm open to other solution and don't wanna hold this PR. It's often quite opinionated. We can certainly nit-pick on this item for a long time ;)

- [ ] 🧾 Updated `CHANGELOG.md`
Copy link
Contributor

@dimas-b dimas-b Oct 30, 2025

Choose a reason for hiding this comment

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

nit: "Updated CHANGELOG.md if the change significantly affects users".... I believe internal changes / refactorings do not need to be mentioned in CHANGELOG.md

- [ ] 📚 Updated documentation (in `site/content/in-dev/unreleased`)