Skip to content

Development Coordination Process

C Custodio edited this page Jan 16, 2015 · 17 revisions

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

  1. 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. Assign Issues to Developers
  3. Make a branch off of the "master" from the main code base or fork the SEED code to a new repository.
    Difference betwen branches and forks
  4. Make a branch in individual dev environment
  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.
  8. Issue pull request to test repository
  9. Develop acceptance tests
  10. Start review process to accept the branch into the main code 3. Unit tests (included in code) if possible (some issues will be easier to do than others) 3. UI testing + Manual testing, walk through the GUI + Selenium (screen capture feature) - Firefox only - + Jasmine 3. Visual code review + Minimum of one person, can bring in another person if needed 3. Documentation 3. Make sure changes are well documented + In code + PyDocs for Readthedocs
  11. Comments on pull request
  12. Review process concludes
  13. Merge code into "master" branch in seed repository
  14. Accept pull-request
  15. Continuous Integration testing

Repository branch (inside SEED code)
Used by internal SEED developers making direct changes to seed and seed-test, especially for a major issues. A branch is made from the master and named after the issue being resolved (e.g. “FixforMissingBuildingRecords”). A pull-request is made after testing the issue fix.

Tags can be used to indicate the current working version of the code.

Repository fork (clone of SEED code)
Used by independent developers for their own versions of SEED and for plug-ins/features that will be part of the official SEED code. Stand-alone stable versions of SEED repository.

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