Methodology

Based on Mr. Mortensen’s methodology concept, we wanted to make sure that branches, pull requests and merging made up the backbone of our progress, since it’s especially useful for organizing work in a cross-period group.

(Starting from our already-existing frontend and backend repos…)

  1. Work in VSCode, commit frequently (but don’t sync)
  2. Prepare to Sync/Push to shared repo when you make an improvement a. Commit changes b. Pull before you Push/Sync c. Resolve merge issues and test
  3. Sync/Push
  4. Prepare a Pull Request a. Make an Issue in base repo to describe work, should agree with requirements/ideas outlined on the corresponding assignment on the Scrum Board b. Resolve merge issues and test in repo c. Create Pull Request and add “Issue” to the Request d. Maintainer (currently Scrum Masters) approves request and merges
  5. IMPORTANT: Link pull request issue to the Scrum Board where the assignment is. This is used as proof of completed work.

Additional Strong Habits

  • When a valuable commit is made/something valuable is learned during a process, save a link to the commit on GitHub in an issue on the relevant assignment. This is good for reflection and will help when looking for key commits in the long run. Having evidence of strong group contributions shows and reinforces good group etiquette.
  • Communicate (particularly over Slack, which remains very active) before making a Pull Request. This allows other members to look over changes that may affect their area of focus (negatively) and makes sure at least one of the Scrum Master figures sees the request in a timely fashion, even outside of class.
  • Ideally: In weekly issues, link commits and show contributions. Document work time if possible (if not, estimate).