User:BCornwall/Traffic task workflow

This workflow is specific to the Traffic team. Other teams' definitions, expectations, and workflows will differ. Policies more broadly applicable to all teams (such as how to handle security tasks) still apply.

Priorities

"Priorities" are a combination of severity/priority on the following:

• Running services
• Progress on work
• Security coverage

Unbreak Now!

As per usual urgency with UBN!

High

Actively impeding

Medium

Potentially impeding

Low

Not impeding and can be worked around, but should be fixed

In general, work on high-priority tickets before medium; medium before low. However, time estimating is also worth consideration: If one high-priority task would take a long time to complete yet a low-priority task a day then it's understandable to choose working on the low-priority task. These are guidelines, however: To borrow from a phrase from that one weird cult, "people over process".

Ticket priority can arbitrarily be raised/lowered by managers for goals and iniatives.

Status

While it's common for Phabricator projects to utilize kanban boards to organize task statuses, these best left to the Status field. The Status field is permanent; Adding the optional kanban board duplicates work and opens up the possibility of confusing, conflicting information as to the status of the ticket.

Closing unserviced tickets

Traffic has attempted to wrangle the task queue a number of times before (be that extreme amounts of categorization, prioritization of ticket stacks, inclusively keeping tickets around in hopes that someone will eventually service them, etc.) Long-term, the results were always the same: An accumulation of zombie tickets that were never going to get serviced.

The traffic team is incredibly small. It's an unfortunate reality that we will be unable to service most tickets that come our way. To both keep our team efficient and maintain reasonable expectations from external parties we must make sacrifices to tickets we think will not be realistically serviceable. See #External communication for how to gently communicate this subject in an appropriate way.

Low priority bugs come with an expiration. Routine task list pruning may provide opportunity to close tickets if:

• systems/progress continue to function long enough without completing a task
• it feels like servicing will likely not occur

If a task ever becomes important to service later then the team can always re-open/re-prioritize it.

External communication

Traffic publishes a roadmap to show our pursued goals to any interested parties.

Public engagement is tricky due to both unending workloads and limited personnel. The unfortunate reality is that some tasks will never be serviced. It may be tempting to merely leave a task open: "Eventually someone will get to it", one might say. Truthfully, the task will rot (and often become irrelevant). To uphold transparent internal/community communication, routine pruning of our task pool will keep expectations clear and workload expectation more realistic.

When closing a task filed by the general public use gentle, humanistic language (or at the very least a canned response) to provide the user(s) transparency on why the task is closed. Closing tasks without action can initially cause disappointment or hurt, so approaching the realities of work prioritization with empathetic engagement is important.

Tags

It's common practice for teams to add their team's tags for "radar" visibility. While the intentions are sound, this gives rise to a overflowing bin of tasks. If individuals want to follow a task, they can subscribe to the task. If the ticket does not require action by the Traffic team, remove/do not add the Traffic tag.

Task review

During our weekly sync-up the team will spend a few minutes "pruning" our pile of tasks:

• Prioritize any tasks with Needs triage status.
• Review low-prioritized tasks to determine whether they should be kept around or closed.
• Review scheduled/active kanban columns and move them around as needed.

Milestones

Phabricator has the concept of milestones. Using milestones gives us the advantage of setting specific quarterly goals as well as maintaining a historical record of work timelines. Each new quarter will have its own milestone. Tasks will be evaluated and selected for that quarter's work.

Each quarter in the fiscal year has a corresponding milestone. The naming scheme follows the format FYXX-QX, where the first XX placeholder represents the fiscal year and the second X placeholder represents the quarter. For example, the first quarter of fiscal year 2024 would be represented with FY24-Q1.