All new issues should have at least the 3 tags bellow.
- Type tag: all new issues should inform its type BUG or ENHANCEMENT
- Platform tag: all new issues also should have only one platform tag MIDDLEWARE, IOS, ANDROID, WINDOWS PHONE or WEBAPP. If the issue have impact in more than one platform, create another issue and add a relationship between them.
- New tag: all new issues should have a NEW indicator tag to be able filter issues create but not initiated.
- An issue is never assigned to someone from the beggining.
❗ Type Tag and Platform Tag should never be removed, even after closed. ❗
Type tags are used to classify issues by severity and type of priority for development team members. An issue marked as ENHANCEMENT has a low priority compared to a issue marked as BUG.
- BUG: anything that crash the app or is not according to the scope documentation.
- ENHANCEMENT: anything that can be improved in the app or even fixed but it was not specified in the scope documentation.
An issue can also be marked as CRITICAL for prioritization purposes. See Acessory Tag section for more details.
-
The first step is assign the issue to yourself, mark it with the tag IN PROGRESS and remove the tag NEW.
-
If there is a definition problem* or the description is not enough to understand the problem and the information lost is mandatory to solve the issue, remove tag IN PROGRESS, add a tag IN DEFINITION and change the assigee to the responsible for the solution.
❕ IN DEFINITION status is already implied in hold to development.
-
If there is a definition problem but you are able to develop it, just add a comment (with user tag @user) and keep the issue as IN PROGRESS status. Any time that the definition cause a development break, should change status to IN DEFINITION.
-
If you have an issue IN PROGRESS but will not conclude it, or will leave it to another time, remove the IN PROGRESS tag, assignee and return to the NEW tag.
-
If during the execution you realize that the issue should not be do, mark the issue as REFUSE, remove tag IN PROGRESS and add a tag DONE.
-
After finish the issue, add a relationship between the issue and pull request using
fix #999(999 is the number of the issue). Also remove the tag IN PROGRESS and mark the issue with the tag DONE.
(*) possible definition problems include: business process, layouts, transitions, keys and access, user messages, disclaimers.
- Check if all issues related to a pull request (PR) is marked as DONE.
- Verify Travis CI log and test the branch changes in local.
git checkout <branch-name>
git reset --hard origin/<branch-name>
- If everything is ok, merge PR into develop.
- after merge all PR into develop, publish the new version to staging. Mark all issues as STAGING and remove the tag DONE.
git checkout <platform>-staging
git reset --hard origin/<platform>-staging
git merge --no-ff origin/<platform>-develop
git push origin <platform>-staging
-
Only validate issues marked as STAGING.
-
If the issue is not ok, add a comment explaining why still not working, remove STAGING tag, add NEW tag back and remove assignee information. Only on this case, the assignee information should be removed.
-
When the issue is not ok and you would like to return it to the same person that executed before, remove STAGING tag and add IN PROGRESS tag back. ❕ Do not remove Assignee.
-
After validate, remove accessories and STAGING tags from the issue and close it.
❗ Do not remove Type tag, Platform tag and the Assignee.
Accessories tags can be added any time to indicate additional information useful to filter or for something specific to the project that it was not covered by the rules above.
- DESIGN: to indicate something pending with the design team (any time - should remove before close)
- REFUSE: to indicate a issue that should be canceled by the owner
- CRITICAL: see details in the bellow section
The CRITICAL acessory tag is a special tag for prioritization purposes. Any issue marked as CRITICAL (BUG or ENHANCEMENT) have a top priority and should be done first by the development team.
A CRITICAL issue is anything that can block the user to do a core business function in the app. For instance, in a mobile commerce app the user should be able to: choose a product; add to cart; identify himself; inform an delivery address; input payment information; and finish the purchase order.
