-
Notifications
You must be signed in to change notification settings - Fork 78
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
chore: update pr template #16297
base: master
Are you sure you want to change the base?
chore: update pr template #16297
Conversation
Jenkins Builds
|
- [ ] I have followed the architecture guidelines: [Architecture guidelines](../architecture-guide.md) | ||
- [ ] For bug fixes, I have written a new unit test case to prevent reintroduction | ||
- [ ] I have performed side impact testing for changes in shared components | ||
- [ ] A reviewer has Tested the PR during review |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these two might be better in a reviewer checklist, not sure if thats a thing though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is an overkill 👀
No way developers want to spend so much time on ticking every checkbox when opening the PR
- [ ] I have performed side impact testing for changes in shared components | ||
- [ ] A reviewer has Tested the PR during review | ||
- [ ] Given enough time for a thorough review | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A little bit of feedback here:
- Keep checkbox labels short, it's too much processing to read all of them
- Example:
Has unit tests
instead ofI have written unit tests for status-go and QML changes
Has user stories
instead ofI have created stories for this feature/rework
Has storybook page (create if not existing)
etc ...
- Example:
- The
I have followed the architecture guidelines
not sure this adds a lot of value here. While some of the points above can act as reminders (don't forget to add tests!) this one is more blurry. - Maybe instead of
I have performed side impact testing...
Add a section that says something like:
Side effects caused by these changes worth mentioning:
- The
A reviewer has tested this PR during review
is something that should just be tackled by GitHub's "Request Review" feature, which implies the result in this checkbox automatically - The
Given enough time for a thorough review
is far fro quantifiable. If you want to have this guaranteed, it probably makes more sense to agree on a rule like: "Leave PRs at least # days pending for review, don't merge before"
What does the PR do
update PR template to include some of the new guidelines