Skip to content

Instantly share code, notes, and snippets.

@nicolas33

nicolas33/swap.md

Last active March 28, 2016 17:14
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save nicolas33/b874747367fd7e877c8e to your computer and use it in GitHub Desktop.
Save nicolas33/b874747367fd7e877c8e to your computer and use it in GitHub Desktop.
Download ZIP
Serious games
Raw
swap.md

Swap Game

A role-playing game (2-8 players).

Pieces

  • A codebase
  • A wiki (optional)

Roles

  • maintainer: maintainer and gamemaster.
  • developer: a player who likes challenges!
  • reviewer: provide feedbacks on contributions. The maintainer is a reviewer.
    • gentleman: provides smart feedbacks.
    • nitpicker: provides nitpicks on contributions.
    • idiot: ask about code/contributions (either dumb or smart questions).

Rules

Coding phase

Round 1, admin

To be played in order:

  1. Players agree on participants, the beginning datetime, the end datetime, the codebase and the wiki. The time for a game should be from 1 to 4 hours.

  2. Depending on the allocated time for the game, players define a contribution goal to make on the codebase. This is the challenge.

  3. Players allocates roles to themselves. There must be:

    • One maintainer.
    • One developer.
    • As many reviewer as wanted.

Each player must have one role at least and at most. The maintainer provides the link to his public repository.

  1. The maintainer starts a wiki at his project and put all of the above in paper.

Round 2, challenge starts

Round 2 starts at the beginning time defined at 1.

The developer starts the challenge and implement the goal defined at 2. The other players drink coffee or enjoy a film with pop corn.

Round 2 stops at the end time defined at 1. The contibutions must be submitted to the maintainer at that time by PR.

Round 3, reviewing

  1. The reviewers make comments on the contributions. Each review must start with the name of the reviewer role (gentleman, nitpick, idiot). Each review is a new challenge for the developer.

    The developer takes a break! Interaction with the other players is forbidden.

    This should not take more than 1 hour.

    Hint: one can easily download a PR like this:

    • git remote add maintainer_name https://link/to/repo (if this repo is not already known locally)
    • git fetch maintainer_name pull/PR_ID/head:local_branch_name

  2. When all reviewers are done, the developer is called back and replies to the reviews (at the PR) but don't fix them.

  3. Once the developer is done, the maintainer announces which commits would either be merged, need a re-roll or would be applied. Nothing gets really merged at that time, though. Results are written to the wiki.

  4. Based on the maintainer decisions, the developers and reviewers announce if they would still contribute with this maintainer or would fork the project. They all must agree on this decision. Decision is written to the wiki.

Fix phase

Time to challenge the reviewers... and the maintainer!

Round 4, fix comments

  1. If the maintainer agreed on merging and the reviewers did not decide to fork (and leave the project), the maintainer merges the topic.

  2. Then, each reviewer fix all their own comments and make PRs to the maintainer. One PR per comment. The fixes must be based on latest head of the official branch.

    If the maintainer made comments, the dev address them and make the PRs to fix them.

Round 5, merge the fixes

  1. The maintainer merge all the fixes PR, one by one.

    HINT: Be care to do this job in good order to limit the number of merge conflicts!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment