In the following explanation, a task may refer to either a PR, an issue, or a card.

This document targets internal contributors.

The sprint backlog consists of multiple lanes.

To Do

Tasks that are not taken yet. This lane is broken into two parts:

• ToDo: Tasks planned to be done in the current sprint.
• Pending: Tasks not in the current sprint. May include unpolished ideas.

In Progress

Tasks that are taken. This lane is also broken into two parts:

• In Progress: Taken and someone is working on it.
• PR Ongoing: Being reviewed. Mainly issues that have separate accompanying PRs.

Needs Changes

Tasks (mainly PRs) that need changes. This includes PRs after review.

Ready to Review

Tasks (mainly PRs) that need a review.

Reviewing

Tasks (mainly PRs) that are being reviewed.

Waiting for CI

PRs that have been reviewed, approved and are waiting for CI to pass before being merged.

Done

Tasks that are merged or finished.

Product backlog items are broken into tasks. Those tasks are put into the ToDo lane.

You may also create arbitrary tasks that you think are needed. You should at the same time share the idea behind it with the team. It can depending on the emergency be placed in either of the ToDo or the Pending lane.

• Take a task from the ToDo lane.
  • If no task in the lane can be taken immediately, you may also take one from the Pending lane. In this case, share with the team that you're taking the task.
• If the task was a card, and it fits as a GitHub issue, convert it to an issue.
• Move the taken task (card or issue) to the In Progress lane.
• You may also submit a WIP PR. Put it in the In Progress lane.

• Submit a PR pointing to the issue.
• Put the PR in the Ready to Review lane.
• Move the issue to the PR Ongoing lane.

• Take a PR (either no one is assigned or you're already assigned) in the Ready to Review lane.
• Assign yourself.
• Move the PR to the Reviewing lane.
• After review,
  • If any changes are needed, leave comments and move the PR to the Needs Changes lane.
  • If it looks OK, trigger the CI and move the PR to the Waiting for CI lane.

• Once CI passes in a PR in the Waiting for CI lane, the assignee must merge the PR and move it to the Done lane (usually automatically done).

• PR dependency: If a PR depends on another,
  • Put the blocking label on the PR depended on.
  • Put a [depend #xxx] prefix to the title of the depending PR (where xxx is the other PR number).
  • Keep the depending PR in the Needs Changes lane, even if it's complete in its own.
  • When the depended PR is merged, remove the blocking label and the [depend #xxx] prefix. This should in general be done by the depending PR author.
• Long-standing tasks: In sprint review, we check every ongoing tasks to see if they're long-standing (more than 1 week after taken). We put chainerx-long label to such tasks.