GitHub User Guide

Lifecycle of a new requirement

Requirements and Design Phase

1. On receiving new requirements, a new issue is to be created and all the requirements should be added within the description.
2. Add suitable priority (critical, high, medium, low) and type (enhancement, question, feature, bug) labels to the issue.
3. When the team decides to begin exploring these requirements, the status of the issue should be updated to discussion with the label status : requirements and design.
4. The team can add PSDs, Architectural Diagrams etc. within the issue as comments.
5. Once, the Requirements, UI and Architectural Designs are finalised. The design and requirements phased ends and the status : requirements and design label is removed.

Development Phase

1. The developer adds the status : development label.
2. Coding begins, in a new branch created from latest snapshot of master branch. The branch is named issueNumber-short-description. For example 214-poc
3. On Completion of Coding, and the code is self reviewed and tested, a Pull Request should be created, add the label status : ready for testing, and assigne it to the tester.
4. On Completion of Testing, the label status : ready for testing is replaced with status : ready for review.
5. On Completion of Review, the label status : ready for review is replaced with **status : reviewed **.
6. Development Phase ends and the developer removes the label status : development from the corresponding Issue.
7. After the code is merged, if there are feedbacks, those feedbacks should be discussed within the issue as new comments, a new development phase loops again and continues until all feedbacks are resolved.
8. After all feedbacks are resolved, the issue can be closed.

Classification of Issues and Pull Requests with Labels

On the basis of Priority

• 
• 
• 
• 

On the basis of Current Status

• (for Issues)
• (for Issues)
• (for Issues)
• (for Pull Requests)
• (for Pull Requests)
• (for Pull Requests)

On the basis of Nature of Requirement

• 
• 
• 
•