Work flow of posting issues

Jack Yin edited this page Aug 16, 2013 · 5 revisions

In order to collect the bugs, features, questions and security problems in the github in an orderly manner, we have to follow the following standard work flow of posting issues:

1. Check whether the issue is already in the issues list

-- Please make sure if you post into GitHub that you have checked that your problem is not there already. otherwise there will be to many problems that addresses the same problem.

-- If we find any duplicated issue, we will mark it with Duplicate label to remove the duplication.

2. Choose a label to mark your issue

-- If you think it is a bug, please label it with Bug label. For the features, questions or security issues, please label them with** Feature, **Question or Security label separately.

Label issue

-- In addition, you have to show attach the TomatoCart version(1.1.8, etc) in the issue name as follow:


-- And then describe the issue in great detail. It is useless to just say that it doesn't work. Be as clear as possible which steps you did.

3. Team member to check the issue

-- Now, the team member will check the issue you posted to confirm whether it is a real issue. At this pointer, we will mark the issue with Check label.

4. Issue is accepted

-- After checking the issue, we confirm it is a real issue and need to be resolved. At this pointer, we will mark the issue with Accept label.

-- If the issue is not existed, we will label it with Reject and close the issue.

5. Create a milestone for the issues and assign the issue(s) to the available team member

6. Issue is in progress

-- As one team member start to deal with the issue, it will be marked with In process label.

7. Issue is solved

-- After the issue is solved, it will be marked with Solved label.

-- A thread will be posted in the community team team board in the community. So, the community users could know the issue is solved and go to test it.

-- Issue poster, Community QA Team and community users could check the issue and the developer will continue to deal with the other issues

-- If there isn't any user who prefer to test the issue, we will test the issue again before publishing the beta version.

8. Issue is closed

-- After testing by the community QA team, the issue will be closed. It mean the issue is really fixed.

9. A beta version will be released in the community

-- If all the issues in a milestone are closed, one beta version will be released to be tested by the community.

10. A stable new version is released for all of the users

In this way, we could ensure the stability of the feature version. If you are interested to join in the community test team to do contribution for this project, please add the following Skype account into your contract, we will contact you later:

Skype Account for community test team: tocjack