New PR template #1248
New PR template #1248
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## develop #1248 +/- ##
========================================
- Coverage 17% 16% -0%
========================================
Files 229 229
Lines 6961 7161 +200
========================================
- Hits 1154 1139 -15
- Misses 5807 6022 +215 |
.github/pull_request_template.md
Outdated
|
|
||
| ## Documentation | ||
|
|
||
| - [ ] Properly adds an entry in `changelog.md` with the change |
There was a problem hiding this comment.
This is currently not used, I'm not sure we should keep it...
There was a problem hiding this comment.
Not used indeed. It could be automated by an action. That's a discussing
There was a problem hiding this comment.
Unless we force everyone to use Conventional Commits and therefore we can use Conventional Changelogs there's no real way to automate this in a good enough way.
I think that just appending the PR name/link to the CHANGELOG is not good enough.
There was a problem hiding this comment.
All the commits are too overwhelming
There was a problem hiding this comment.
That's the advantage of conventional commits: you can, for example, exclude chore: commits from the changelog or even exclude fix: commits, and it makes the changelog more readable. The bad thing about conventional commits is that you need to enforce it on every developer to work properly.
There was a problem hiding this comment.
Is there a way to force changesets before merging?
There was a problem hiding this comment.
changesets seems to be more annoying for the devs. The @LuisDuarte1 approach seems more automatic, but yes, requires forcing a rule
There was a problem hiding this comment.
@LuisDuarte1 yes, the action can force a PR to have a changeset
There was a problem hiding this comment.
And like @LuisDuarte1 said, Conventional Commits can be used but, in my experience with trying to get other people to use conventional commits, they are not trivial to start using...
Another aspect is that I think Conventional Commits are more tailored to technical projects with more technical changelogs, whereas changesets are more tailored for user-facing projects.
There was a problem hiding this comment.
Ultimately, in my opinion, this comes down to whether we want to make it easy for developers and generate mid-quality changelogs, possibly having to tweak them a little bit, or whether we want to make it slightly harder for developers and generate high-quality changelogs that don't require tweaking.
thePeras
force-pushed
the
refactor/pr-template
branch
from
d2cacc0
to
d91f57f
Compare
| # Review Checklist | ||
|
|
||
| - [ ] Writes a summary in `whatsnew/whatsnew-pt-PT` of the new changes | ||
| - [ ] Terms and conditions reflect the changes |
There was a problem hiding this comment.
Terms and conditions should be updated on every PR, if necessary. The reason is the app will be used by beta testers, which are also subject to the terms and conditions of uni.
There was a problem hiding this comment.
I think it can be a little annoying and pushing the responsibility to the person who made the release and its reviews, will allow taking a preoccupation from each PR
|
UI/UX Test with diferent text zoom levels |
|
Add something responsive |
Closes #997
Let's open the debate!!