waseem/process.txt

## process.txt
1. An issue popups in Github. A bug or a feature request.
2. Developer starts coding after understanding the issue. He makes sure to add issue number in the form of #XXX - XXX is issue number - to the commit message. This links issue with the commit that was made. It's important to know 'why the commit was made'.
3. A CI listens to pushes to the Github repo and runs all the specs and optionally deploys the code to one of the staging servers.
4. After developer is done with coding, s/he assigns the issue to another developer for code review.
5. Code reviewer makes sure that all the tests are passing along with presence of code and test coverage. Code reviewer can assign issue back to the developer if there is some issue with the code. Developer will start at step 1 again.
6. Code reviewer assigns issue to QA. If QA is not happy, s/he adds issues that were found as comment to the original issue or possibly create new issues depending upon severity of the problem s/he found out.
7. If QA is happy, she assigns the issue to a person - possibly original developer - to merge it with production branch.
8. Developer merges it with production branch and closes the issue. All specs are run again.
9. If all green, code is deployed to production.
10. A smoke test is carried out by QA. If something is broken on production, revert the specific commits from the production server. And start at step 1 again.
	1. An issue popups in Github. A bug or a feature request.
	2. Developer starts coding after understanding the issue. He makes sure to add issue number in the form of #XXX - XXX is issue number - to the commit message. This links issue with the commit that was made. It's important to know 'why the commit was made'.
	3. A CI listens to pushes to the Github repo and runs all the specs and optionally deploys the code to one of the staging servers.
	4. After developer is done with coding, s/he assigns the issue to another developer for code review.
	5. Code reviewer makes sure that all the tests are passing along with presence of code and test coverage. Code reviewer can assign issue back to the developer if there is some issue with the code. Developer will start at step 1 again.
	6. Code reviewer assigns issue to QA. If QA is not happy, s/he adds issues that were found as comment to the original issue or possibly create new issues depending upon severity of the problem s/he found out.
	7. If QA is happy, she assigns the issue to a person - possibly original developer - to merge it with production branch.
	8. Developer merges it with production branch and closes the issue. All specs are run again.
	9. If all green, code is deployed to production.
	10. A smoke test is carried out by QA. If something is broken on production, revert the specific commits from the production server. And start at step 1 again.