Page Comparison

...

1. Install WSL2 from the Microsoft Store and VS Code. You don’t need anything else! ✨

   • Docker Desktop is not necessary if you have WSL2 version 0.67.6 or higher (check wsl --version)

2. Setup docker in WSLPrepare WSL for docker. This may not be necessary in recent versions of Windows 11

   1. Enable systemd by updating /etc/wsl.conf to add:

      Code Block
      [boot] systemd=true

   2. Restart WSL (via cmd)

      Code Block
      language bash
      wsl --shutdown

3. Install Docker. Follow Docker’s instructions to install docker-ce and docker-compose-plugin

   1. Once installed, add your user to the docker group for later convenience

      Code Block
      language bash
      sudo apt update sudo apt install docker.io -y sudo usermod -aG docker $USER

4. Clone the Play repository

   Code Block
   language bash
   cd ~ git clone git@github.com:Spordle/Play.git play

5. Open it in VS Code

   Code Block
   language bash
   code ~/play

6. Relaunch in the devcontainer

   • You’ll see a notification in the bottom-right corner suggesting this

   • You can also relaunch via the Ctrl-P menu by searching for ‘dev containers’

   • This might take some time as it’s pulling and building a few docker images for the first time

   Check

   • If it fails to launch, the bottom-right notification lets you open the logs to see what the error is exactly. The error popup is usually vague and super misleading.

7. Follow README.md for further instructions on how to install and build Spordle Play

8. Create a branch and open your first pull request! 🎉

...

• Daily standups

  • This is a quick opportunity to share what you’re up to, flag any blockers, and ask for help. This keeps everyone in sync and also provides visibility to everyone as to what the team is actively working on.

  • Since we’re distributed across timezones, we use a daily Slack thread for async updates instead of having a meeting later in the day

• Backlog refinement

  • Prior to sprint planning, we regularly review the backlog to ensure stories are still relevant and to give us an idea of what’s coming so we can plan the upcoming sprint

  • We use planning poker for all developers to assign points to each story using a Fibonacci scale, which indicate the amount of effort (not time) that each story requires to develop

• Sprint planning

  • Before starting a sprint, we have a meeting to determine what everyone will be working on for the next two weeks. Stories from the backlog are selected by each developer based on the point assigned to them during refinement

  • Developers are encouraged to have autonomy over the stories they choose from the backlog. This process is guided by the number of points they feel they can successfully deliver within the sprint timeframe and priorities set out by stakeholders as determined during other meetings

• Retrospectives

  • We continuously deploy our work and continuously improve our process. Retrospectives are an important step in the agile process to determine what works and what doesn’t work. Most importantly, this is a blameless process and faults no one as we seek to improve things for everyone

  • We hold a formal meeting at the end of each sprint and an quick informal one midway through the sprint as a health check

• Sprint review

  • This is a We have an internal review weekly to keep developers in sync and share what’s going on. More eyes on each other’s work often helps find issues before users do.

  • We have an meeting near the end of each sprint to showcase our work to stakeholders and gather some feedback to make sure business and developers are still in sync

...