Team Practices Group/Phabricator tips

Introduction
NOTE: This page is a sandbox. Once the content is developed enough to be usable, it will be copied, merged, folded, or migrated over to one or more of the existing WMF Phabricator documentation pages, such as https://www.mediawiki.org/wiki/Phabricator/Project_management

The goal of this page is to explain at a higher ("why") level how best to use Phabricator. Eventually this page should reflect the consensus opinions of the Team Practices Group. Step-by-step details for "how" to perform tasks in Phabricator can be left to other pages.

Major concepts
Phabricator has 3 main top-level objects: Users, Tasks, and Projects.

User
Each user has a profile. Users can Join or Subscribe to Projects, and can Subscribe to or be Assigned to Tasks.

Task
Tasks are the heart of the system, and mostly behave similarly to issues in other issue-tracking systems. Each Task is uniquely identified by its ID, which is in the form Txxxxx. Each task has a Title, Status, Assigned To, Priority, and Description, Visibility, Editability, and Security. Each also has a list of CC (Subscribers) and a list of associated Projects. Attachments can be added as part of a Description or Comment.

By conscious decision, Tasks in the WMF instance have very few fields, so for example they do not have "OS/Platform" or "See Also" fields. Requests to add additional fields are likely to be rejected, with the advice to instead include that information in the Description or in a Comment.

Project
Projects are unlike projects in most issue-tracking systems. See below.

Projects
Unlike most issue-tracking systems, Phabricator Projects are really a form of "tag". Whereas typically a Task is contained by a single Project, in Phabricator a Task can be in any number of Projects. This is fundamental to the way Phabricator works, so it is important to understand all the implications.

Phabricator does not yet support nested Projects, so all Projects are currently at the top level. Naming conventions are used to communicate the intention of hierarchical relationships.

Types of projects
Phabricator Projects can represent a "Project", in the normal sense of the word. But the Project feature is used in a variety of other ways. A Project can be any of:
 * Team (e.g. Security) (Purple)
 * Generally a sub-team would be handled as a Project or Component instead
 * Project (e.g. Android App) (Blue)
 * Can also be sub-projects
 * Component (e.g. Cirrus Search) (Blue)
 * Can also be sub-components
 * Sprint (e.g. ToolLabs-Q4-Sprint-1) (Green)
 * Note that a "Sprint" Project has magic powers (see below)
 * Release (e.g. MediaWiki 1.25) (Orange)
 * See below
 * Tag (e.g. i18n) (Yellow)
 * Can be a cross-cutting concern, such as Security or Design, or a category like Epic or Easy

Workboards
Workboards allow organizing Tasks in columns, and arranging them via drag-and-drop. Each Project can only have a single Workboard. Columns can be added, removed, and rearranged via the Manage button in the upper-right corner of the Workboard view.

Typical uses of Workboards

 * Workflow
 * Typical columns would be along the lines of TODO, DOING, DONE
 * This supports both Scrum-style sprint iterations, and Kanban-style continuous work
 * Roadmap
 * Each column might represent a target release, or general timeframe (e.g. "2016")
 * Categories
 * Columns might group Tasks by component, functional area, or even complexity

Workflow Workboards
Although the basic structure is TODO, DOING, DONE, there is a lot of flexibility as to the number of columns, and their names. Here are some possible examples with variations in wording:


 * TODO, To Do, Backlog, Product Backlog, Sprint Backlog, Inbox
 * Selected, Next, Ready, Ready For Work
 * DOING, Doing, In Progress
 * Needs Review
 * DONE, Done, Completed, Finished
 * Blocked, Waiting, In Discussion

Sprint Workboards
Phabricator has a special case of Workboard known as Sprint. Sprints behave like regular Workboards, but add functionality. Notably, Tasks in a Sprint have a new Story Points field, which can hold an estimate. Sprint Workboards add up these estimates per column, and these estimates are used in the Burndown Chart feature. Sprint Workboards would almost always be configured to represent Workflow.

Multiple Workboards
Although each Project can only have a single Workboard, a team might manage multiple Projects, and thus have access to multiple Workboards. For example, a team might have its Team Project, but might also own a few Component Projects. An example might be a Search Team that deals with both the Mediawiki Search Feature and also an experimental Wikidata Query Service. Or a Mobile Apps Team might have separate Android and iOS component Projects. Teams can also set up one or more Sprints to track workflow, outside the main Team Workboard.

The simplest model would be for a team to have a single Project, and thus a single Workboard. That Workboard would probably track workflow (TODO, DOING, DONE). If a team wanted this simple model, but also wanted to track estimates, they might hope to configure their Team Workboard to also be a Sprint. But as of 2015-04-06 it is not possible for a "Project" project to also be a "Sprint".

A team using Scrum would probably create a new Sprint Project (and thus Workboard) for each iteration. Each Sprint Workboard would track workflow for that iteration, and would get archived after the iteration had been closed off. That would leave the Team Workboard available to look like a Roadmap, or to be grouped into Categories. Or the Team Workboard could just have a single unmanaged column holding all that team's tasks.

A Kanban team would probably create a single Sprint Project (with Workboard) to track the workflow. Perhaps at some regular time interval, that Kanban Project would get archived, just to get rid of all of the resolved Tasks and get a fresh start.

A team could have a multi-level Project configuration. The Team Workboard might show a Roadmap, but they might also have a few Component Workboards which could be arranged by Category. Then, each Sprint Workboard would track workflow. Tasks might appear in Workboards at each level.

Tasks and workflow
Each Phabricator Workboard has a column flagged as "Default", and any new task added to that Project will start off in that column.

Blocking Tasks
Tasks can block, or be blocked by, any number of other tasks. This feature can be used to accomplish a few different things:
 * Blockers. A task might simply be blocked by another task, representing a dependency.
 * Subtasks. A parent task would be blocked by its subtasks. (There is no other way to mark parent/subtask relationships).
 * Tracking. A "workless" task blocked by several tasks might be tracking a collection of tasks within a release or other time period (see below).
 * Approval. Several tasks (such as draft team goals) might be blocked by a single task which represents the draft tasks getting approved, after which those draft goals are now real goals.

Prioritization
Each Task has an Priority field, which is reflected in the sidebar color of Tasks that appear in Workboards. Note that this Priority is inherent to the Task, and thus will be the same in every Project and Workboard that task appears in.

Within a Workboard, Tasks can be arranged in a priority order within a column. Choose "Natural" sort, and then drag and drop Tasks up or down within a column. This allows a groomed backlog to be sequenced by priority, or could indicate the urgency of items in a "Needs Review" column. Note that Workboard columns can also be sorted by the underlying Priority field, so while discussing a Workboard with someone not in the room, it is best to agree on and use the same sort order to avoid confusion.

Assignment
Each Task may be assigned to one person. As with Priority, this is inherent to the Task, and affects every Project that Task is in. So it is impossible to have a Task assigned to Robin in one Project, but to Kim in another. The assigned person is displayed as part of the Task card in each Workboard.

Some teams might choose to assign Tasks to people while the Tasks are in a TODO column. Others would have people assign Tasks to themselves only at the moment that they are moving them from TODO to DOING. Assigning a Task to yourself before you are ready to work on it is a form of "cookie licking".

After the main work on a Task is finished, there are 2 main patterns for assignment:
 * The Task remains assigned to whoever did the work, as that task's permanent owner
 * The Task gets reassigned to whoever needs to work on it next

So for example, after code has been written, it might needs a code review from some specific person. In the second case, the Task would be assigned to that person, making it clear who is responsible for moving that task forward. Obviously if there are multiple possible code reviewers, that model would not work. Later, if the issue were waiting for someone to test it, or deploy it, or to run some specific task necessary for the Task to be completed (like a re-index), the Task could be assigned to that person.

"Done"
Each Task has a Status field, which includes the state of Resolved. Resolved tasks are often hidden from Workboards, and when they are displayed, they appear grayed out and struck out. Other statuses include Open and Stalled.

Note that this Resolved status is inherent to the Task, and so will affect that Task's appearance and behavior in every Project (and Workboard) it is in. This is independent of which column a Task might be in, in any given Workboard. So a Task could be Open, and could be in the DONE column of one Workboard, but the DOING column of another. It could also be in the 2016 column somewhere else.

As a result, it is important not to mark a task Resolved until it is considered done by ALL of the projects it is in. It's fine to move a Task to your own Workboard's DONE column, but before you mark a task Resolved, ensure that no other project still wants to keep tracking its progress.

"Tracking" Tasks
This term was brought over from Bugzilla, where it had a specific meaning: A task which was blocked on other tasks, but which itself did not represent any work, and which was not tied to a specific release/date. An example might be a Task named "Clean up the documentation", which might then have a variety of subtasks, each of which would describe specific work to be done. These "Tracking" Tasks tended to stick around for a long time (or forever), as their subtasks would get resolved but new ones would get created. In Phabricator, it would be better to create a Project (tag) to categorize this type of work.

Note, however, that there are other types of work-less umbrella tasks which do still make sense in Phabricator. Notably, "Release" tasks. An upcoming release could be represented by a Task, which lists as subtasks (aka blocking tasks) all the actual work tasks which are targeted for that release. Once the release goes out, it can be resolved. A similar use would be to have a task which represents a teams overall goals for the quarter, and then each goal might (or might not) be a blocking subtask.

Other resources

 * Phabricator/Project_management
 * A multi-purpose page which seems mostly aimed at team leads or process facilitators. Of all the resources here, it is closest in intent to this page.


 * Wikipedia entry about Phabricator
 * Contains general information about the product.


 * Wikipedia entry about reporting Wikipedia bugs
 * Wikipedia-centric information on phab. Lots of links to other pages, although several have additional information as well (some of which might really belong inside those links).


 * http://phabricator.org/
 * Official product site.


 * Phabricator
 * This root page is still heavily focused on the WMF transition into Phabricator.


 * Phabricator/Help
 * Reference guide, focusing on “How”, not “Why”


 * Talk:Phabricator/Help
 * “The” place to ask the WMF phab team about how to use the tool. Technical problems/suggestions can be submitted as Tasks for the Phabricator project. Process questions could be addressed to the Team Practices mailing list.


 * Phabricator/FAQ
 * More than half of the questions relate to the migration, and much of the rest relates to getting set up initially. Very little information for existing phab users.


 * Phabricator/Creating_and_renaming_projects
 * Mechanical description of the nuts and bolts of getting a project created. “How”, not “Why”. Has a useful list of all the project types, which probably belongs (or at least should be duplicated) elsewhere.


 * Phabricator/Permissions
 * Good brief summary of phab user roles and what they can do.


 * Bug_management/Phabricator_etiquette
 * General bug-reporting etiquette, aimed primarily at end-users, and not so much at developers, product owners, or process facilitators. Not much information specific to Phabricator.


 * Bug_management/Bug_report_life_cycle
 * Mediawiki-specific description of the life cycle of a defect report in Phabricator. Includes some advice that I am currently skeptical about (specifically, that an issue should be Resolved as soon as the code is merged, rather than waiting until it has been released).


 * Bug_management/How_to_triage
 * WMF-specific guidelines for triaging bugs in Phabricator. Probably more useful for a global bugmaster than for individual team members.


 * How_to_report_a_bug
 * Mostly general advice on bug-reporting, but with Phabricator-specific HOWTO recipes.


 * Phabricator/Projects
 * A wiki page verion of https://phabricator.wikimedia.org/project/query/all/ which is generated by a script. It’s not (yet) clear how frequently it is updated.


 * https://wikitech.wikimedia.org/wiki/Phabricator
 * Internal highly technical details about WMF’s phab instance.


 * https://secure.phabricator.com/book/phabricator/article/remarkup/
 * Reference guide to text formatting commands available in phab descriptions and comments.


 * irc://irc.freenode.net/wikimedia-devtools
 * IRC channel where phab (and presumably other tool) issues are discussed.