Reading/Web/Phabricator

For project, workflow and task management the Reading Web Team uses Phabricator. Here you can find some documentation about how we use it, and which boards we're working with.

Projects/Boards

 * Team dashboard (For triaging and urgent tasks).
 * A board per software artifact (MobileFrontend, Gather, TextExtracts, etc. See dashboard for the list).
 * A general Reading Web backlog board for tasks or bugs that can't be classified in the other software projects.
 * A forever sprint board for work in progress

Workflow
We use project classification and setting the task's priority to organize our work (harnessing the power of Phabricator search). As a secondary method we use the project's boards to sub-classify tasks, but not on all boards, only in the biggest ones.

Tasks that need the team's attention to set a priority need to be on the Needs triage priority. Then the team will have a look and chime in, and assign a priority based on several factors (urgency, workload, need for discussion, etc). Priority should be set by people intending to work on the task or by product owners prioritizing for engineers to work on it.
 * Unbreak now! tasks will be moved to the current sprint and worked on as soon as engineers are available.
 * High priority tasks will be reviewed when planning following sprints and will likely be tackled soon.
 * Normal priority tasks will be reviewed when the backlog of High priority tasks is low, and will be promoted to High if we're planning to work on them next.
 * Low priority tasks likely need to be discussed or are not an immediate priority for the team.
 * Lowest priority tasks most probably need to be fleshed out and discussed or are far from getting in to the teams work load in their current state.

Triaging new tasks and sprint planning
For triaging we use the backlog. Cards that come from outside our workflow are picked up as part of a shared chore list. The backlog by default only shows cards that are priority normal or higher.

"To triage" is the default destination for new cards. Here they are assigned a priority and then moved to "needs analysis" for technical review or "tracking" if they are not priorities for the given time.

Needs analysis is primarily used by the tech lead who's job is to keep it empty. The tech lead is responsible for ensuring tasks leaving this column are well defined, scoped and ready to work on. The tech lead (possibly with help of others) will carry out a brief investigation of the task, ideally to understand which parts of the stack the task touches and if a bug whether the route cause of the problem can be identified. Developer notes are added to tasks to share information with the rest of the team that is necessary for them to discuss and estimate the task. When this has been done the task is moved to "Triaged but future". If a task needs input from the design lead, it will be moved into the design milestone.

Design (milestone) is used by the designer to track tasks that need their input. When the input has been completed the designer will pass to the tech lead via need analysis

Triaged but future is used by the product owner to choose work that should be worked on next, based on current priorities will move tasks that will be worked on soon to upcoming to signal an estimation is needed.

Upcoming is used during estimation meetings to ensure tasks are well defined, identify missing acceptance criteria and ultimate estimate. The tasks here can be used to populate the sprint board's todo column. The team strives to have all tasks in triaged but future and upcoming well defined and estimated, but will focus on the priorities in upcoming.

Current sprint: When tasks are moved into the sprint board, they are also added to the current sprint column which is archived periodically, with the aim to show what has been worked on in any given quarter.

Needs Reproduction column is seldom used, but can be used when during technical review an issue cannot be replicated and is therefore not actionable. It might also be used for general QA.

Product Owner column is used by the product owner. Sometimes, the technical lead will move tasks here when input or guidance is sought from the product owner, in particular where estimation/analysis will be quite expensive.

Tracking (milestone) is used for tasks that are of interest to the readers web team but are not being worked on by them. It will also be used to track work that will not be worked on in the near time future and reduce noise in the backlog. Tasks in tracking may move into needs analysis pipeline at any time based on team/community needs. Note the tech lead might use a user board tag e.g. User-Jdlrobson to track work relating to upcoming epics/projects.

High level overview
Inside our backlog there is a column "Epics/Goals". Epics that are currently being worked on are moved into the forever sprint board to signal that there is a commitment to complete them. Epics will have subtasks that live in either the backlog or the tracking column, providing easy access to related work.