Wikimedia Release Engineering Team/Phab process proposal

Chat log
(aka, "what made Greg type this up?")

17:57 <  csteipp> greg-g: Is there a phab team for QA specifically? hashar took releng off T89353, I wasn't sure if there's a better backlog to get that on.

18:01 <+  greg-g> csteipp: either is fine, we don't have a hard and fast rule on everything being in #releng

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

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.

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


 * Add any task you plan to work soon on to the #releng project
 * corollary: remove the #releng project to tasks we don't plan to work on any time soon
 * This implies that all tasks have a "home" project other than #releng
 * if one doesn't exist then it should probably be created (is Greg's guess).
 * Use the #releng project workboard to track work progress/status (eg: backlog, ready, in-progress, needs review, done)
 * Use the #releng board only for work tasks
 * we should use something like #releng-goals project for meta level tasks (eg: all the "[keyresult]" tasks and the [EPIC]-type tasks).
 * Use the individual software project workboards to track type of work only if and only if it helps organize the tasks in that project
 * iow: remove the "Next", "in-progress", etc columns (that'd be tracking work status ("in-progress) in multiple boards).
 * The exact makeup of the boards can be defined per-project. We can come up with best practices for these later if need be.
 * If needed there can be "to triage" and "ready/backlog" columns on the project workboard (iow: the triaging step between "new task we (maintainers of the software project) haven't looked at" and "on the #releng board")
 * See eg: https://phabricator.wikimedia.org/tag/wikimedia-log-errors/