Wikimedia Release Engineering Team/Phab process proposal

Purpose of this document

edit

The WMF Release Engineering team does not have a single/unified process for how we manage tasks across/within projects in Phabricator. The current situation was a combination of organic growth and best efforts/ideas. It is also not documented (because it's practically undocumentable)

This document attempts to do two things:

  1. Propose a unified process/description, and
  2. document it on wiki.

Current situation

edit

We have a team project at #Release-Engineering-Team (aka: #releng)

We have a ton of software projects we maintain (#beta-cluster, #deploy-tooling, #browser-tests, etc, etc etc)

A task can be in any of:

  • Just #releng
  • Just some software project (eg: #beta-cluster)
  • Both in #releng and a software project

There is no consistency and status of a task, for example, a task can be in the "in-progress" column on one or more workboard.

Problems

edit
  • Other teams don't know if we're working on something or if we plan on working on it any time soon.
  • It's hard to see what the entire team is working on (or at least, what people are saying they are working on based on assignee status).
  • It's hard to see what the team is blocked on in one place.
  • We're tracking status (eg: "in-progress") on multiple workboards.
  • It's hard to plan the future without mudding up workboards that track shorter term work.

Proposal

edit

Generally, be more "people focused" than "software focused".

The projects

edit
edit

Daily task tracking

edit
  • #releng: Our team board to track work progress/status, eg, the board where the "in-progress" column lives
    • Use this board only for work tasks
    • Examples:
      • "Scap3 should break up remote deploy tasks"
      • "Phabricator needs to expose ssh"

Software projects

edit
  • These are the usual software projects, eg #beta-cluster, #deployment-systems, or #MediaWiki-Vagrant
  • All tasks should have one of these associated with it. Think of it as the primary home of the task.
    • If one doesn't exist then it should probably be created (is Greg's guess); there are of course corner cases.
  • Do not use those boards to track daily work in progress. In other words, remove the "in-progress" column from these projects (unless otherwise needed) and only worry about dragging a task into an "in-progress" column on the #releng workboard.
    • That information ("in-progress") is still visible to users/others interested. See the next section for further explanation.

The process

edit
  • Add any task you plan to work "soon" on to the #releng team project
    • Corollary: remove the #releng project to tasks we don't plan to work on any time "soon"
    • "soon" here is not precisely defined, and that's OK. Let's just not have tasks rotting in #releng that haven't been touched for months
  • Drag the task into the "in-progress" column on the #releng team workboard when you start working on it
    • Take task T97464 as an example.
    • Right now the users/others interested in the work see that it is in the "backlog" column of our team project: see this screenshot.
    • When someone begins work on this, they will drag it into the "in-progress" column, which will do two things:
      • 1) it will email all subscribers that someone moved it in the team "in-progress" column
      • 2) Be clear at the topic of the task for new people that it is in the "in-progress" column because of the "(in-progress)" next to the RelEng team project.

What this gives us

edit
  • One place to look for who from RelEng is working on what right now (the #releng team project "in-progress" column)
  • Clear areas for planning tasks (#releng-epics and the #releng-201516-Q2 etc projects)
  • Corollary to above: No longer cluttering up our #releng team workboard with planning tasks

Workboard Tips

edit

NB: expand as needed

  • Sometimes a "watching/externally blocked/stalled" column is useful
  • Having the default column be something like "To Triage" and then a "Triaged" column tends to be useful.