Reading/Web/Phabricator

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

Projects/Boards

Roadmap (a high level overview of the work the team has committed to)
Team dashboard (For triaging and urgent tasks).
Backlog board for tasks or bugs that can't be classified in the other software projects.
Essential work board organized into columns of possible workstreams which have clear goals and represent a common theme. In some cases essential work becomes unexpectedly important (e.g. something broke and needs attention), strategic (e.g. if not done the site will stop working), or needed to resolve an OKR (either belonging to team or others). The columns are prioritized with the most important streams of work at the left. The work on this board may or may not be in our backlog but reflects units of work that the team might deem important in future. When a column is empty, it is done and the column is archived.

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.

Priorities

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. This priority will also ping other teams (notably Release Engineering) to let them know that this bug may impact a deploy. If the task is not time sensitive, use "High".
High priority tasks will be reviewed when planning following sprints and will likely be tackled soon.
Medium 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 a priority for the team. They may be re-prioritised during quiet periods, or are far from getting in to the teams work load in their current state.

Status

Stalled We need more information or are waiting on something else to work on the task.
In progress We are in the process of understanding the task and assigning it an estimate.
Open We have not started looking at the task
Resolved we believe the task is done. If follow up work is needed please create a new ticket.
Declined the team doesn't think we should do the task
Invalid the task was based on a misunderstanding or describes expected behaviour.

Backlog columns

The backlog is where we store work that we plan to work on in the future. It also contains a tracking column for tracking work that impacts the team or is the responsibility of the team that we do not plan on working on in the near future. Tasks that are marked low priority are hidden from view. We hope to review low priorities on a regular basis. The tasks in the backlog may or may not be evaluated. If a task has been evaluated and is ready to go, it will have a points estimation on it.

The backlog does not contain all the open bugs that belong to the team, it should reflect the current capacity of the team and the tasks it deems the most important to complete.

By keeping the backlog a manageable size we are more likely to resolve tasks in the backlog.

The web team will move tasks back into the backlog as they align with team priorities.

Incoming

Tasks are swept in via the Web dashboard. The dashboard should be manageable by all team members. Click manage panel on any panel to edit it (and if you can't see manage it - ask someone in the team for that privilege!). Click customization to see the complex query that powers the dashboard. This query is dictated by Reading/Component responsibility#Extensions.

Requests for us to do work should be filed via the "Request" form in the menu at the left hand side of the page.

For triaging we tag with the backlog. Tasks that come from outside our workflow are picked up as part of a shared chore list. The backlog by default only shows tasks that are priority Medium or higher.

"Incoming" is the default destination for new tasks. Tasks are expected to move from this column in the following manner:

Anything that we aspire to do in the quarter will move to the associated quarter
Anything else is moved to freezer.

Q1/Q2/Q3/Q4

This column is updated every quarter and tracks the work we aspire to monitor and hopefully resolve during the quarter. This typically relates to tasks that relate to any of the active team projects or essential work to keep the site running.

Tasks that have active patches from volunteer, or people outside the team will also move here for triage.

Importantly: Presence in this column does not mean we will guarantee to do the work this quarter.

Sprint backlog

Tasks that have been estimated AND are proposed candidates for our next sprint can be moved here.
Any member of the team can nominate a ticket
If a nominated ticket is not part of a KR, a comment clarifying why the ticket is a good candidate should be added

Sprint column

Our current active sprint.

Freezer

Tasks that we do not plan to work on in the current quarter as they do not currently relate to our current projects but think are relevant and hope to get to one day. Patches from volunteers are often welcome here.

Every quarter when creating our new quarter column we will review this column, reviewing tickets older than 6 months . When doing this we will either:

Untag tickets that are no longer in line with the team's strategic plan
"Thaw" tickets that fit into the current plans of the team.

When tickets are thrown out of the backlog, we appreciate messages from outsiders to reconsider our evaluation.

Sprint columns

The sprint board is a milestone of the backlog. It has its own columns and process. The sprint board is the single source of truth for what the team is currently working on.

Team sprints run for 2 weeks and the expectation is that when the sprint is started, all work on the board has been committed to with the expectation that it can be completed during the timeframe.

Tasks that enter the sprint board are expected to move along the sprint board to the right hand side quickly and then get resolved (closed).

Ready for Development

Fully evaluated and estimated tasks that people can pick up and work on and have committed to . Generally tasks are picked from the top, but depending on estimations and time available, it is fine to pick from other smaller tasks.

Doing

Tasks here being worked. This encompasses development, code review and QA. We use assignee and other assignee fields to identify the current team member that is "responsible" for the next action in the task that moves it closer to completion.

Sign-off

When a task moves here, someone (typically the product owner) signs off that everything has been done that has been asked for and that a certain level of quality has been achieved. The signer-off will scrutinize the task and check that it matches the work done. New tasks can be created if necessary on the back of work and sometimes a task will be pushed back to "Doing" if it is deemed incomplete. Some tasks have signoff steps which must be followed before resolving the task.

Signoff Criteria

The following guidelines apply for the successful completion of a single task:

Did testing flag any problems that we want to address either now or later
Review description - make sure all the boxes are checked off in acceptance criteria, signoff criteria, etc
Check for subtasks - if there's subtasks open, can we move them to a different task or are they a blocker for signoff?
Check if follow-up tasks need to be created and create them if necessary

During refinement, we identify important work, or work where there has been volunteer activity and assign a team member to understand the issue, describe the work involved to the team and to gather estimations asynchronously. When refinement is complete the team member moves the task to the "Sprint backlog".

A refinement link appears in the backlog that lists all the tickets currently in refinement.

Refinement can:

deem a task as unnecessary. Our investigation might reveal that the issue is not related to our team, an upstream issue or working as expected or was not understood correctly. e.g. This bug only impacts 1 person! Why is this important? OR this is a bug in X component owned by Team Red not us!
deem a task not ready to be worked on, this might result in spikes to learn information that is necessary to work on the task, or to split the task into multiple steps.
result in an estimation
Make sure a task has mocks

Things to think about when evaluating:

Spend at most one hour looking at a task.

If it's a bug, can you reproduce it? Can you explain to somebody else how to reproduce it?
Is the task clear that you could explain it to somebody else? I.e. which context was missing when you started looking at it?
Do we know everything we need to know? If not, should it be/does it need a spike?
If it is a bug, is the source of the bug known? Can you reproduce it? Can you isolate it to a particular browser/module? Even better.. can you find a minimal test case that fails?
If a feature, is it clear how we might build it? Can you write a strawman proposal? Do others in the team agree?
Are any mocks needed?
Can the task be expanded to make the task easier to understand?

Possible outcomes of evaluation

You might find it's super easy and solve the issue. Post a patch and get an estimation. We can seek to fasttrack it into the next sprint.
You might discover its priority is wrong - for example if a bug impacts 0.001% of page views there's probably not so much urgency to fix it.
You might discover it's a bigger problem than we first thought. Bump the priority.
You'll make the task easier for whoever ends up working on it
You may determine the work is better suited to another team and should not be in our backlog.

What do when evaluation has completed

When you have finished an analysis and the estimation has been agreed upon the task is moved to the "Sprint backlog" column.

Sprint lead guidance

Inactivity

If an in-progress task has not had any update or moved column in 24 hrs, the sprint lead will take this as a signal to investigate why. The team understands that there are valid reasons for this (vacation, illness, work is slightly harder than expected, etc), and simply wants to make sure the assignee of the ticket has what they need to proceed.

There are various reasons a task may be blocked and it's worth asking the following questions:

Has scope creeped?
- It's possible the task was not well defined up front, and/or new information has emerged. This happens. However, it might indicate one of several things:
  - The task is not understood
  - New tasks need to be created, including spikes
Is another team not prioritising this task as highly as us?
- In some cases, we will work with another team and it might be the case that they are not prioritising the work as highly as us. In this situation we might want to consider rescheduling the work or finding other ways to make progress that are not blocked on others.
- We'll probably want to move the task out of the sprint board and pursue it separately in a way that doesn't distract the rest of the team.
Is the task actually an epic?
- If various subtasks are being creating (or related tasks that are not associated with the task), this has probably happened. Label it as an epic and move it to the epics column (or backlog if the product owner doesn't thing this is something we should commit to).
Is there a misunderstanding of what done means for the task?
- If a task lacks acceptance criteria, it's possible this has happened.
- Understand the expectations/confusions in the task.
- Consider splitting out into multiple tasks if different disciplines are expecting different things.
- Example: A task is created to create a prototype, and assigned to the designer but there has been no update. An engineer may have expected "done" to mean "deploy the prototype" whereas the designer may be running some design research on the prototype and expect "done" to mean "run and finish the design research". In this case, we might amend current tasks/create two tasks "Deploy the prototype" and "Perform design research on the prototype" so it's clearer.