Introduction

We use GitHub’s projects functionality for maintaining a kanban-style workflow.

Both the build and core teams will use similar workflows when it comes to working with issues on git. Core projects can have small differences in the workflow, always check a project’s README for more details.

In the start of every sprint, a milestone for the sprint is created. A doable amount of issues is included in the milestone. If all issues aren’t completed before the milestone (sprint) ends, they will be moved to the next milestone or back to the project backlog.

You should always be working on an issue if you are developing a project.

Working on projects

Project boards

The main project is called “Release”. This project collects all work that will be included in the release of an app. Once the app has been released, the project will be renamed to “Constant improvement”.

Every project has 5 columns:

‘Backlog’

• Contains all issues regarding the project and also future ideas.

‘Todo’

• Contains all issues accepted to be part of the release or accepted to be taken under development if ‘Constant improvement’ is already in progress.

‘Doing’

• Lists all open pull requests which address issues in ‘Todo’.

‘Waiting’

• Lists all issues that cannot be currently completed.

‘Completed’

• Contains all closed issues previously listed in ‘Todo’.

Build team workflow

1. Select an issue that is assigned to you from ‘Todo’ column to work on by priority
   • If you need to start working on a project but there are no assigned issues, you can also assign yourself issues. Select them by the priority tags but only from the ‘Todo’ column
     • If there are no issues -> Ask project’s dev contact whats the deal
     • If you need to create issues, check the guide below on how to create them
2. Move your issue to ‘Doing’

3. Create a branch for new issue off the dev branch (issue/n):

   1	$ git checkout -b issue/n

4. Develop on your branch, commit your work

5. Push your branch to GitHub:

   1	$ git push origin issue/n

6. Fetch origin changes that were done by others:

   1	$ git fetch origin

7. Update local dev

   1 2	$ git checkout dev $ git pull origin dev

8. Rebase issue/n branch on top of the origin dev:

   1 2	$ git checkout issue/n $ git rebase dev

9. Conflicts may arise here. If so, git rebase will stop and allow you to fix the conflicts. After fixing conflicts, use git add . to update the index and then just:

   1	$ git rebase --continue

10. Push your branch to GitHub again (never force push to a common branch btw. ;))

    1	$ git push origin issue/n --force

11. Create a Pull Request

    • Use a descriptive title for the PR, add “closes #N, #N” in the title to automatically close related issues
    • NOTE! Look over your changes in the diffs, make sure they’re what you want to submit:

      1	$ git diff issue/n origin/dev

12. The project’s dev contact or core team leader reviews the PR, merges it and accepts the issue by moving it to ‘Completed’.

13. Remove your issue branch when it has been merged

Creating issues

Step 1: Create the issue

• Use a descriptive but short title
• Describe the issue the best you can
  • If the issues is a bug, please provide steps to reproduce, eg:

Actual result: The shadow is displayed over Waitlist confirmation pop-up. Also check buttons

Steps to reproduce:
1. Open site
2. Log in
3. Open Waitlist
4. Select Party size
5. Fill waitlist form
6. Submit
7. Check pop-up

Expected result: The shadow is displayed under Waitlist confirmation pop-up. Buttons should much the design.
[screenshot, video, doc etc]

Step 2: Tag the issue

If the issue is going to the project backlog, don’t assign it to anybody or tag it with a milestone yet.

Use labels to best describe the issue. Add at least a priority label. These labels should be already created for every repo. If not, use this script or ask Juuso to do it.

• Project management labels:

  • waiting for core
  • waiting for review

• Priority labels:

  • priority: low
  • priority: medium
  • priority: high

• Size labels
  • epic
  • major
  • minor

• Platform labels

  Is the issue related to a specific platform?

  • ios
  • android
  • web

• Problem labels
  • bug
  • security

• Mindless work labels
  • chore eg. adding test data

• Experience labels

  • design
  • ux

• Improvement labels

  • feature
  • enhancement
  • tweak

• Environment labels
  • prod
  • dev

• Inactive labels
  • invalid
  • wontfix
  • duplicate

Step 3: Add the issue as a card to the project board backlog

Priorities explained