Wikimedia Release Engineering Team/Phab process proposal

Current situation
We have a team project at #Release-Engineering-Team

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 (eg "in-progress" can be tracked in more than one project workboard).

Problems

 * 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, is saying that it is 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 this week

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

The projects

 * Planning related:
 * : to track all open tasks that are on our long term goal list (aka: epics).
 * Examples:
 * [EPIC] Run CI jobs in disposable VMs
 * "Migrate Gerrit to Differential"
 * : to track quarterly keyresults/outcomes/measures of success
 * These are explicitly not tasks you "work on". In the terminology of Agile it'd be something like a "theme". Theme's are blocked by/made up of other tasks that you do work on (iow: the pieces that get you to completion).
 * Examples:
 * [keyresult] subset of jobs run in disposable instances
 * [keyresult] Allow cloning of Phabricator hosted git repositories
 * Daily task tracking
 * : 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
 * 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.
 * These are the usual software projects, eg,  , or
 * 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  workboard.
 * The information is still visible to users/others interested. See the next section for further explanation.

The process

 * Add any task you plan to work "soon" on to the #releng team project
 * Corollary: remove the  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  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

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

Workboard Tips

 * 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.