<div dir="ltr"><div>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 :)</div><br><div class="gmail_quote"><span style="font-size:large;font-weight:bold">Forwarded conversation</span><br>Subject: <b class="gmail_sendername">Duplication of information in Phabricator workboards</b><br>------------------------<br><br><span class="undefined"><font color="#888">From: <b class="undefined">Prateek Saxena</b> <span dir="ltr"><<a href="mailto:psaxena@wikimedia.org">psaxena@wikimedia.org</a>></span><br>Date: Fri, Jan 30, 2015 at 12:05 PM<br>To: Arthur Richards <<a href="mailto:arichards@wikimedia.org">arichards@wikimedia.org</a>>, Quim Gil <<a href="mailto:qgil@wikimedia.org">qgil@wikimedia.org</a>><br></font><br></span><br>Hey,<br>
<br>
<br>
Our conversation during the DevSummit was too short :) I'd love to<br>
lear more about the work of the team practices group and improve the<br>
way I approach my work remotely.<br>
<br>
One of the main problems I've encountered with Phabricator workboards<br>
is the duplication of information. Most workboard have the following<br>
columns-<br>
<br>
 1. Backlog<br>
 2. In Dev<br>
 3. Needs Review<br>
 4. Done<br>
<br>
If we follow the conventions that have been suggested, people only<br>
assign tasks to themselves when they are ready to work on it, making<br>
[2] redundant. The #Patch-for-Review tag makes [3] redundant and<br>
closing tasks makes [4] redundant.<br>
<br>
Am I using workboards incorrectly. Is there something I am missing?<br>
<br>
<br>
—prtksxna<br>
<br>----------<br><span class="undefined"><font color="#888">From: <b class="undefined">Arthur Richards</b> <span dir="ltr"><<a href="mailto:arichards@wikimedia.org">arichards@wikimedia.org</a>></span><br>Date: Wed, Feb 4, 2015 at 6:43 PM<br>To: Prateek Saxena <<a href="mailto:psaxena@wikimedia.org">psaxena@wikimedia.org</a>><br>Cc: Quim Gil <<a href="mailto:qgil@wikimedia.org">qgil@wikimedia.org</a>><br></font><br></span><br><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Hey dude,<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Given the scenario where you describe:</div><span class=""><div><div><div class="gmail_extra"><div class="gmail_quote">  </div></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Most workboard have the following<br>columns-<br><br> 1. Backlog<br> 2. In Dev<br> 3. Needs Review<br> 4. Done<br><br>If we follow the conventions that have been suggested, people only<br>assign tasks to themselves when they are ready to work on it, making<br>[2] redundant. The #Patch-for-Review tag makes [3] redundant and<br>closing tasks makes [4] redundant.</blockquote></div></span><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>And if you're willing, please forward this to or cc <a href="mailto:teampractices@lists.wikimedia.org" target="_blank">teampractices@lists.wikimedia.org</a> (our public mailing list), I'm sure others would find this valuable :)</div></div></div></div><div><br></div><div>Great seeing you last week!</div><span class="HOEnZb"><font color="#888888"><div>Arthur</div><div><br></div>-- <br><div><div dir="ltr">Arthur Richards<div>Team Practices Manager</div><div>[[User:Awjrichards]]</div><div>IRC: awjr</div><div><a href="tel:%2B1-415-839-6885%20x6687" value="+14158396885" target="_blank">+1-415-839-6885 x6687</a></div></div></div>
</font></span></div></div>
<br>----------<br><span class="undefined"><font color="#888">From: <b class="undefined">Prateek Saxena</b> <span dir="ltr"><<a href="mailto:psaxena@wikimedia.org">psaxena@wikimedia.org</a>></span><br>Date: Thu, Feb 5, 2015 at 11:26 PM<br>To: Arthur Richards <<a href="mailto:arichards@wikimedia.org">arichards@wikimedia.org</a>><br>Cc: Quim Gil <<a href="mailto:qgil@wikimedia.org">qgil@wikimedia.org</a>><br></font><br></span><br>Thanks for replying in such detail Arthur. My replies are inline.<br>
<span class=""><br>
On Thu, Feb 5, 2015 at 7:13 AM, Arthur Richards <<a href="mailto:arichards@wikimedia.org">arichards@wikimedia.org</a>> wrote:<br>
> One of the biggest values of a workboard is its ability to quickly, at a<br>
> glance, convey a lot of information. Information that can be really valuable<br>
> to that engineering team, other teams, other stakeholders, the communities,<br>
> etc etc.<br>
<br>
</span>I understand and agree.<br>
<span class=""><br>
<br>
On Thu, Feb 5, 2015 at 7:13 AM, Arthur Richards <<a href="mailto:arichards@wikimedia.org">arichards@wikimedia.org</a>> wrote:<br>
> I like to think of a workboard as a snapshot at the current moment of the<br>
> state of all work in the system (where 'system' can mean many different<br>
> things - like a project broadly speaking, a particular chunk of time in a<br>
> project [eg a sprint or iteration], etc). Structurally, the workboard should<br>
> reflect the workflow of the team. On the teams I've worked with, we've set<br>
> up workboard columns to reflect handoff points in the team's workflow - eg<br>
> 'ready for dev' to 'in dev', 'in dev' to 'needs review', etc. Different<br>
> teams have different workflows and handoff points, and I think their<br>
> workboards should reflect that.<br>
<br>
</span>Right, this covers almost the same columns as the ones I suggested. It<br>
adds the 'ready for dev' column which for me is the difference between<br>
the tasks that have been triaged or not.<br>
<span class=""><br>
<br>
On Thu, Feb 5, 2015 at 7:13 AM, Arthur Richards <<a href="mailto:arichards@wikimedia.org">arichards@wikimedia.org</a>> wrote:<br>
> I am curious, do you know of another way in Phabricator to be able to<br>
> visualize the current state of all of the work in a team's workflow at a<br>
> glance?<br>
<br>
</span>Dashboards! I really like that Phabricator lets you put different<br>
kinds of queries in multiple columns on your dashboard. Panels can be<br>
mixed to form tabbed interfaces, I use this to manage personal tasks -<br>
open tasks, tasks with #patch-for-review, tasks I am subscribed to<br>
etc.<br>
<br>
It would be cool if projects could design their own dashboards too but<br>
I am not sure is Phabricator lets you do that. Maybe Quim knows :)<br>
<span class=""><br>
<br>
On Thu, Feb 5, 2015 at 7:13 AM, Arthur Richards <<a href="mailto:arichards@wikimedia.org">arichards@wikimedia.org</a>> wrote:<br>
> One more thing I am curious about - what does 'Done' mean on your team?<br>
> Teams like the former mobile web team used 'Done' on their workboard to<br>
> indicate that the code relevant to the task was merged and to the best of<br>
> the task owner's knowledge, the acceptance criteria for that task was met. A<br>
> task in the 'Done' column on their board signaled to their product owner<br>
> (the person who was responsible for deciding whether or not the work<br>
> completed did in fact meet the acceptance criteria) that the work was ready<br>
> to be accepted, or punted back to the team. If after review the work was<br>
> accepted, the task was then closed. I think the teams that spun out of the<br>
> mobile web team still do this, but I'm not positive. The point being -<br>
> depending on what 'Done' means for your team and your team's workflow, maybe<br>
> 'Done' is not an appropriate column for your workboard. At the end of the<br>
> day, the columns should be reflective of your team's workflow and actually<br>
> make sense for your team's way of working.<br>
<br>
</span>Unfortunately, I haven't yet worked on a team that follows structure.<br>
I've been using workboards for the Hovercards and UI Standardization<br>
projects and I don't think to many people apart from me look at it. I<br>
close a task when all the patches that meet its criteria are merged.<br>
After that if someone else feels that the patch was buggy or there are<br>
things that haven't been addressed they are welcome to reopen the bug.<br>
<br>
I think I also once experimented with a separate Done and Archive<br>
(hidden) column. Tasks move from Done to Archive only once I am sure<br>
that people are happy with the patch. The issue with this is that<br>
sometimes people close tasks if they see a patch merged, and then, I<br>
have to make sure that I am seeing closed tasks on the workboard too.<br>
Seeing closed tasks is not a setting that can be saved in a preference<br>
and I have to do it every single time. Or maybe there is, Quim would<br>
know :)<br>
<span class=""><br>
<br>
On Thu, Feb 5, 2015 at 7:13 AM, Arthur Richards <<a href="mailto:arichards@wikimedia.org">arichards@wikimedia.org</a>> wrote:<br>
> And if you're willing, please forward this to or cc<br>
> <a href="mailto:teampractices@lists.wikimedia.org">teampractices@lists.wikimedia.org</a> (our public mailing list), I'm sure others<br>
> would find this valuable :)<br>
<br>
</span>I don't mind having this conversation on list. I am subscribed to it<br>
too, it just slipped my mind when I was emailing you. I am unsure of<br>
how to forward the message, now that we've snipped each other's<br>
messages and replied inline. You can forward it to the list as you see<br>
fit :)<br>
<span class=""><br>
<br>
<br>
On Thu, Feb 5, 2015 at 7:13 AM, Arthur Richards <<a href="mailto:arichards@wikimedia.org">arichards@wikimedia.org</a>> wrote:<br>
> Great seeing you last week!<br>
<br>
</span>Indeed! Your session was great too! As a remote worker I constantly<br>
worry if I am getting enough done. I sometimes even wonder if I'd be<br>
more productive if I were in SF (No no no! I am happy here :D)<br>
<br>
<br>
—prtksxna<br>
<br></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Arthur Richards<div>Team Practices Manager</div><div>[[User:Awjrichards]]</div><div>IRC: awjr</div><div>+1-415-839-6885 x6687</div></div></div>
</div>