🔀 Issues · branches · pull requests

Workflow

GitHub-style collaboration for the session. The project lead often keeps this page on their machine while the Scrum Master runs Play timers.

Guided workflow

Use Next and Previous to move through each phase.

1 / 7

Start here

This deck walks through the GitHub-style flow for LGTM: repo setup, planning issues, working on branches, pull requests, and closing the loop—plus what happens when the sprint ends.

  • Press Next to begin with repository setup.
  • The counter shows your position (seven steps including this intro).
  • You can jump using the numbered dots below.

Repository setup

  1. Create a repository for the session’s deliverable and invite everyone on the team as collaborators (or use an org team) so no one is blocked on access.
  2. Clone the repo locally on each machine you’ll use—verify git pull / git status before work starts.
  3. Optional: protect main so changes land only via reviewed PRs—match how real teams gate production branches.

Paste the GitHub browser URL or a git@github.com:… clone URL. We use it for the GitHub shortcuts in this deck.

Plan and prioritize

  1. Read the project requirements as a group. Break the brief into small, completable issues—each should be doable in roughly part of a sprint.

  2. Open issues with titles, descriptions, acceptance hints, and links to Trends or docs so assignees don’t have to hunt context.

    Open an issue in your session repo

    Create a new issue

  3. Agree on order: discuss priorities loud enough that the whole table hears the same ranking. Projects
  4. Assign owners: one person or a pair/trio (max three) per issue—avoid mega-groups so accountability stays clear. All issues

Research and develop

  1. Comment on the issue as you research—paste queries, URLs, screenshots, and decisions so reviewers and teammates see the trail.
  2. Create a branch per issue with a clear name (e.g. tied to the issue number). That’s where session work lives—not directly on main. Create a branch
  3. Add Markdown files in the repo on your branch: notes, tables, draft sections of the deliverable. Commit early and often with meaningful messages.

Review and merge

  1. Open a pull request into main when the issue’s slice of work is ready for review—describe what changed and link the issue. Create a pull request
  2. A different teammate (or team) reviews: ask questions, request edits, then approve when satisfied. All pull requests
  3. Merge after approval—respect branch protection if you turned it on.

Keep going until done

  1. When an issue is merged, grab the next open issue by team agreement—same cycle: branch → commits → PR → review → merge.
  2. Repeat until every issue you planned for this goal is closed or explicitly parked.

When the sprint ends

  1. Join the retrospective as a full group: what worked, what slowed you down, one change for the next sprint. The project lead and researcher sync per game rules; the Scrum Master keeps time using Play.

Celebrate wins—then reset for the next sprint.

Go to play Roles Game rules Project requirements Home