[teampractices] Duplication of information in Phabricator workboards?

Tue Feb 10 20:03:20 UTC 2015

Prateek and I have been having a conversation about the utility of
workboards in Phabricator which came out of some questions he had during
the Team Practices Group collaboration techniques session at the Mediawiki
Developer Summit a couple weeks ago. Some good stuff came up in the
conversation, which is forwarded in entirety below with Prateek's
permission :)

Forwarded conversation
Subject: Duplication of information in Phabricator workboards
------------------------

From: *Prateek Saxena* <psaxena at wikimedia.org>
Date: Fri, Jan 30, 2015 at 12:05 PM
To: Arthur Richards <arichards at wikimedia.org>, Quim Gil <qgil at wikimedia.org>

Hey,

Our conversation during the DevSummit was too short :) I'd love to
lear more about the work of the team practices group and improve the
way I approach my work remotely.

One of the main problems I've encountered with Phabricator workboards
is the duplication of information. Most workboard have the following
columns-

 1. Backlog
 2. In Dev
 3. Needs Review
 4. Done

If we follow the conventions that have been suggested, people only
assign tasks to themselves when they are ready to work on it, making
[2] redundant. The #Patch-for-Review tag makes [3] redundant and
closing tasks makes [4] redundant.

Am I using workboards incorrectly. Is there something I am missing?

—prtksxna

----------
From: *Arthur Richards* <arichards at wikimedia.org>
Date: Wed, Feb 4, 2015 at 6:43 PM
To: Prateek Saxena <psaxena at wikimedia.org>
Cc: Quim Gil <qgil at wikimedia.org>

Hey dude,

One of the biggest values of a workboard is its ability to quickly, at a
glance, convey a lot of information. Information that can be really
valuable to that engineering team, other teams, other stakeholders, the
communities, etc etc.

I like to think of a workboard as a snapshot at the current moment of the
state of all work in the system (where 'system' can mean many different
things - like a project broadly speaking, a particular chunk of time in a
project [eg a sprint or iteration], etc). Structurally, the workboard
should reflect the workflow of the team. On the teams I've worked with,
we've set up workboard columns to reflect handoff points in the team's
workflow - eg 'ready for dev' to 'in dev', 'in dev' to 'needs review', etc.
Different teams have different workflows and handoff points, and I think
their workboards should reflect that.

Given the scenario where you describe:

> Most workboard have the following
> columns-
>
>  1. Backlog
>  2. In Dev
>  3. Needs Review
>  4. Done
>
> If we follow the conventions that have been suggested, people only
> assign tasks to themselves when they are ready to work on it, making
> [2] redundant. The #Patch-for-Review tag makes [3] redundant and
> closing tasks makes [4] redundant.

I am curious, do you know of another way in Phabricator to be able to
visualize the current state of all of the work in a team's workflow at a
glance?

One more thing I am curious about - what does 'Done' mean on your team?
Teams like the former mobile web team used 'Done' on their workboard to
indicate that the code relevant to the task was merged and to the best of
the task owner's knowledge, the acceptance criteria for that task was met.
A task in the 'Done' column on their board signaled to their product owner
(the person who was responsible for deciding whether or not the work
completed did in fact meet the acceptance criteria) that the work was ready
to be accepted, or punted back to the team. If after review the work was
accepted, the task was then closed. I think the teams that spun out of the
mobile web team still do this, but I'm not positive. The point being -
depending on what 'Done' means for your team and your team's workflow,
maybe 'Done' is not an appropriate column for your workboard. At the end of
the day, the columns should be reflective of your team's workflow and
actually make sense for your team's way of working.

And if you're willing, please forward this to or cc
teampractices at lists.wikimedia.org (our public mailing list), I'm sure
others would find this valuable :)

Great seeing you last week!
Arthur

-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687

----------
From: *Prateek Saxena* <psaxena at wikimedia.org>
Date: Thu, Feb 5, 2015 at 11:26 PM
To: Arthur Richards <arichards at wikimedia.org>
Cc: Quim Gil <qgil at wikimedia.org>

Thanks for replying in such detail Arthur. My replies are inline.

On Thu, Feb 5, 2015 at 7:13 AM, Arthur Richards <arichards at wikimedia.org>
wrote:
> One of the biggest values of a workboard is its ability to quickly, at a
> glance, convey a lot of information. Information that can be really
valuable
> to that engineering team, other teams, other stakeholders, the
communities,
> etc etc.

I understand and agree.

On Thu, Feb 5, 2015 at 7:13 AM, Arthur Richards <arichards at wikimedia.org>
wrote:
> I like to think of a workboard as a snapshot at the current moment of the
> state of all work in the system (where 'system' can mean many different
> things - like a project broadly speaking, a particular chunk of time in a
> project [eg a sprint or iteration], etc). Structurally, the workboard
should
> reflect the workflow of the team. On the teams I've worked with, we've set
> up workboard columns to reflect handoff points in the team's workflow - eg
> 'ready for dev' to 'in dev', 'in dev' to 'needs review', etc. Different
> teams have different workflows and handoff points, and I think their
> workboards should reflect that.

Right, this covers almost the same columns as the ones I suggested. It
adds the 'ready for dev' column which for me is the difference between
the tasks that have been triaged or not.

On Thu, Feb 5, 2015 at 7:13 AM, Arthur Richards <arichards at wikimedia.org>
wrote:
> I am curious, do you know of another way in Phabricator to be able to
> visualize the current state of all of the work in a team's workflow at a
> glance?

Dashboards! I really like that Phabricator lets you put different
kinds of queries in multiple columns on your dashboard. Panels can be
mixed to form tabbed interfaces, I use this to manage personal tasks -
open tasks, tasks with #patch-for-review, tasks I am subscribed to
etc.

It would be cool if projects could design their own dashboards too but
I am not sure is Phabricator lets you do that. Maybe Quim knows :)

On Thu, Feb 5, 2015 at 7:13 AM, Arthur Richards <arichards at wikimedia.org>
wrote:
> One more thing I am curious about - what does 'Done' mean on your team?
> Teams like the former mobile web team used 'Done' on their workboard to
> indicate that the code relevant to the task was merged and to the best of
> the task owner's knowledge, the acceptance criteria for that task was
met. A
> task in the 'Done' column on their board signaled to their product owner
> (the person who was responsible for deciding whether or not the work
> completed did in fact meet the acceptance criteria) that the work was
ready
> to be accepted, or punted back to the team. If after review the work was
> accepted, the task was then closed. I think the teams that spun out of the
> mobile web team still do this, but I'm not positive. The point being -
> depending on what 'Done' means for your team and your team's workflow,
maybe
> 'Done' is not an appropriate column for your workboard. At the end of the
> day, the columns should be reflective of your team's workflow and actually
> make sense for your team's way of working.

Unfortunately, I haven't yet worked on a team that follows structure.
I've been using workboards for the Hovercards and UI Standardization
projects and I don't think to many people apart from me look at it. I
close a task when all the patches that meet its criteria are merged.
After that if someone else feels that the patch was buggy or there are
things that haven't been addressed they are welcome to reopen the bug.

I think I also once experimented with a separate Done and Archive
(hidden) column. Tasks move from Done to Archive only once I am sure
that people are happy with the patch. The issue with this is that
sometimes people close tasks if they see a patch merged, and then, I
have to make sure that I am seeing closed tasks on the workboard too.
Seeing closed tasks is not a setting that can be saved in a preference
and I have to do it every single time. Or maybe there is, Quim would
know :)

On Thu, Feb 5, 2015 at 7:13 AM, Arthur Richards <arichards at wikimedia.org>
wrote:
> And if you're willing, please forward this to or cc
> teampractices at lists.wikimedia.org (our public mailing list), I'm sure
others
> would find this valuable :)

I don't mind having this conversation on list. I am subscribed to it
too, it just slipped my mind when I was emailing you. I am unsure of
how to forward the message, now that we've snipped each other's
messages and replied inline. You can forward it to the list as you see
fit :)

On Thu, Feb 5, 2015 at 7:13 AM, Arthur Richards <arichards at wikimedia.org>
wrote:
> Great seeing you last week!

Indeed! Your session was great too! As a remote worker I constantly
worry if I am getting enough done. I sometimes even wonder if I'd be
more productive if I were in SF (No no no! I am happy here :D)

—prtksxna

-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/teampractices/attachments/20150210/2fb27cde/attachment.html>