Development Coordination

This is a proposed workflow for fixing issues and adding features to SEED.

1. Collaborators of SEED use Github Issue Tracker to report the bug or request a new feature. Include as much detail as possible and screencaps, if it helps.

2. QA Lead assigns issues to Developers.

3. Assigned developers make a branch off of the "develop" from the main code base or fork the SEED code to a new repository.
   Difference between branches and forks

4. Make a branch in individual dev environment with a descriptive name (e.g. FixforMatching).

5. Change code and push changes to branch.

6. Test on individual development environment.

7. For large or long-running changes, periodically merge master down to branch and re-test available unit tests.

8. Developers, with finished bug fixes or new features, issue pull request to SEED repository against the "master" branch. Include the name/number of the issue being fixed in the title.

9. Repository manager merges the developer branches into "develop" branch and pushes the code into the testing environment.

10. QA Lead and additional internal SEED developers start review process to accept the branch into the main code.

11. Develop acceptance tests.

12. Unit tests (included in code) if possible (some issues will be easier to do than others).

13. UI testing

    • Manual testing, walk through the GUI
    • Selenium (screen capture feature) - Firefox only -
    • Jasmine

14. Visual code review

    • Minimum of one person, can bring in another person if needed

15. Make sure changes are well documented.

    • In code
    • PyDocs for Readthedocs

16. Discuss testing on pull request thread. The pull request should document the progress of the fix. Any comments by reviewers should ideally go here, even though they could go in the issue itself, if there are further refinements to the fix. The recommended action is to reference the issue by adding '#<ISSUE ID>' in your comments.

17. If there are things that need addressing, make changes to your branch and make a new pull request. If the branch/pull request is too dirty(i.e., too many changes have been made so the issue does not resemble how it started out), ignore the pull request, open atomic issues and start off clean again.

18. QA Lead tags the pull-request with "Ready for Production" tag.

19. Repository manager accepts pull-request. The fix/feature is merged into "master" branch in seed repository. The pull request automatically closes when merged with a branch.

20. SEED server owner pushes the updated "master" branch to the production environment.

21. QA Lead and additional internal SEED developers test the updated code in the production server.

22. QA Lead closes the issue thread.

---

Pull-requests are confirmed by the repository owner and should be tested first in the developer version of SEED before being merged with the official public version.
https://guides.github.com/activities/forking/#making-a-pull-request