You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Echoing #569, I would like if we could talk about our project management and lay out some guidelines here, in order to streamline the releases and be able to deliver new versions more quickly.
Here's my take on the subject:
Deprecate milestones
In order to avoid confusions, we should only be using the GitHub project management interface to handle releases.
Milestones should be removed.
Project management usage
Only issues should be referenced in cards, no pull-requests.
Proposed columns:
Proposed: Issues proposed for the release. Inclusion to be discussed.
Todo: Issues approved & pending for this release
In progress: Issues that were Todo and now have a WIP PR
Ready for review: Issues that were Todo and now have a ready PR
Completed: Issues that were Todo and are now merged in
Release manager
I think it would be really nice if we designate a release manager by release, to ease things up on @housseindjirdeh.
The RM responsibility would basically be:
Discuss & move items from "Proposed" to "Todo" or other when a consensus have been reached
Make sure the project management interface stays up to date for his release
Revive pending PRs/Issues that needs to be addressed when they go silent for too long
Release QA
Either the RM, or another person should be tasked for QA during the release development.
This person would regularly test the app for regressions and post comments / new issues if needed.
@housseindjirdeh would be responsible for the last QA testing before the new version is pushed to stores.
The QA should be performed on both Android & iOS. (and we can have multiple QA members).
Here, I'm not sure if we want to change the QA team for every release, or if some people may want to take this role more permanently.
Releases branches
This have been discussed on gitter, but I'm not sure we have decided yet how we could better use our git branches or tag to help with this. I personally lack the git-project management knowhow to propose something.
This needs to be addressed in order to be able to have real semantical releases (no more new features in patch releases)
How do you feel about this? What would you change?
The text was updated successfully, but these errors were encountered:
I like the idea of having all those columns as part of the project. Right now I've set it up so that the next minor, major and version releases are on there. Do you think that's alright? Or would you rather we only triage issues for the next coming release and nothing more?
Either the RM, or another person should be tasked for QA during the release development.
This person would regularly test the app for regressions and post comments / new issues if needed.
@housseindjirdeh would be responsible for the last QA testing before the new version is pushed to stores.
Thank you :) I definitely don't mind having someone take the lead as a release manager but until then - more than happy to take the reins myself.
Releases branches
@lex111 mentioned it might be a good idea to always have a next branch created for the next release and then merging only tested and triaged PRs into the branch. Since we're extremely close to v.1.4.0, we can make sure to do this for every release after moving forward
Echoing #569, I would like if we could talk about our project management and lay out some guidelines here, in order to streamline the releases and be able to deliver new versions more quickly.
Here's my take on the subject:
Deprecate milestones
In order to avoid confusions, we should only be using the GitHub project management interface to handle releases.
Milestones should be removed.
Project management usage
Only issues should be referenced in cards, no pull-requests.
Proposed columns:
Release manager
I think it would be really nice if we designate a release manager by release, to ease things up on @housseindjirdeh.
The RM responsibility would basically be:
Release QA
Either the RM, or another person should be tasked for QA during the release development.
This person would regularly test the app for regressions and post comments / new issues if needed.
@housseindjirdeh would be responsible for the last QA testing before the new version is pushed to stores.
The QA should be performed on both Android & iOS. (and we can have multiple QA members).
Here, I'm not sure if we want to change the QA team for every release, or if some people may want to take this role more permanently.
Releases branches
This have been discussed on gitter, but I'm not sure we have decided yet how we could better use our git branches or tag to help with this. I personally lack the git-project management knowhow to propose something.
This needs to be addressed in order to be able to have real semantical releases (no more new features in patch releases)
How do you feel about this? What would you change?
The text was updated successfully, but these errors were encountered: