<div dir="ltr"><div><div><div>For tasks with many tiny subtasks, I choose to outline them in the description and avoid creating separate subtasks.<br><br></div>For bigger 'epic' tasks, it might be better to collect them together under a milestone in the parent project.<br><br></div>For tasks with several interdependent sub-tasks I think the phabricator task dependency tree works pretty well for understanding the order and status of tasks. Sure the presentation could use a lot of improvement but it doesn't seem that terrible to me (especially after recent updates to fix horizontal scrolling issues)<br><br></div>The biggest failure in the subtask graph, IMO, is when you have more than say 10 direct subtasks and the thing starts to get really wide.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 7, 2016 at 3:59 PM, Kevin Smith <span dir="ltr"><<a href="mailto:ksmith@wikimedia.org" target="_blank">ksmith@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">If my years of programming taught me anything, it is the evil of duplication. There needs to be one authoritative source of information. Any copy is at high risk of being out-of-date or out-of-synch, either of which make it misleading. For me, misleading information is (much) worse than none at all. <br><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">In approach 1:<br><ul><li>Sequencing can be handled by creating sub/parent task dependency chains among the children. It's ugly, and the new phab terminology really sucks for this use case, but it is possible, if it's important. Or we could adopt a convention of putting sequence numbers at the start of each subtask title, in cases where sequencing matters and is not obvious. <br></li><li>I agree that the graphic presentation is horrible, although the more I stare at the little spaghetti mazes, the more I start to believe that I might be starting to understand them. <br></li></ul></div><div style="font-family:verdana,sans-serif" class="gmail_default">I think this issue intersects with:<br><br></div><div style="font-family:verdana,sans-serif" class="gmail_default">Should we "explode" tasks pro-actively/early? I am increasingly thinking the answer is "no". <br><br></div><div style="font-family:verdana,sans-serif" class="gmail_default">Should we use phabricator as our primary tool for learning the status and next steps of an epic? I'm also leaning toward "no", because the epic owner/shepherd should serve as a reasonable source of that information. <br><br></div><br></div><div class="gmail_extra"><br clear="all"><div><div class="m_-1967660373359177177gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><span><font color="#888888"><br>Kevin Smith<br>Agile Coach, Wikimedia Foundation<br></font></span><font><font><i><font color="#888888"><br></font></i></font></font></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote"><div><div class="h5">On Thu, Sep 29, 2016 at 11:13 PM, Joel Aufrecht <span dir="ltr"><<a href="mailto:jaufrecht@wikimedia.org" target="_blank">jaufrecht@wikimedia.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div class="gmail_default" style="font-family:georgia,serif"><span><font face="georgia, serif"><span style="vertical-align:baseline;white-space:pre-wrap">TPG is struggling with practices for having lists of sub-tasks within Phabricator tasks. So far we have used two approaches, neither fully satisfactory, and we are looking for approaches that solve all of the problems with none of the drawbacks.<br><br></span></font></span></div><div class="gmail_default" style="font-family:georgia,serif"><span><font face="georgia, serif"><span style="vertical-align:baseline;white-space:pre-wrap">The most common example of this problem is a complex piece of work, e.g. an "Epic" task, which has many subcomponents and which may take months to complete in full. We generally create a Phabricator task to track this work as a whole, tagged as "Epic". Then, we have two different approaches to decomposition.<br><br></span></font></span></div><div class="gmail_default" style="font-family:georgia,serif"><b><span><font face="georgia, serif"><span style="vertical-align:baseline;white-space:pre-wrap">Approach 1: Pure subtasks<br></span></font></span></b></div><div class="gmail_default" style="font-family:georgia,serif"><span><font face="georgia, serif"><span style="vertical-align:baseline;white-space:pre-wrap"><br></span></font></span></div><div class="gmail_default" style="font-family:georgia,serif"><span><font face="georgia, serif"><span style="vertical-align:baseline;white-space:pre-wrap">For each divisible piece of work within this Epic, we create a separate Phabricator task as a subtask of the Epic. The Epic task itself has a brief description. An example of this is </span></font></span><a href="https://phabricator.wikimedia.org/T137479" target="_blank">T137479: [EPIC] Provide support to people in design-related roles</a>.<br><br></div><div class="gmail_default" style="font-family:georgia,serif">What works well:<br><ul><li>All divisible work is tracked as subtasks, so they can be properly tracked (status is clear, responsibility is clear, history is logged, etc.)</li></ul><p>What works poorly:</p><ul><li>All work must be decomposed into sub-tasks (as opposed to being left in outline form)<br></li><li>The relative order of sub-tasks cannot be modified.<br></li><li>The list of subtasks is presented in the Task Graph, which is not as familiar or legible as an indented bullet list</li><li>Sub-tasks may have multiple parents, which is confusing to users expecting pure trees. For example: <br></li></ul></div><div class="gmail_default" style="font-family:georgia,serif"><h1 class="m_-1967660373359177177m_2250241329371506560gmail-phui-header-view"><span class="m_-1967660373359177177m_2250241329371506560gmail-phui-header-header"><span class="m_-1967660373359177177m_2250241329371506560gmail-visual-only m_-1967660373359177177m_2250241329371506560gmail-phui-icon-view m_-1967660373359177177m_2250241329371506560gmail-phui-font-fa m_-1967660373359177177m_2250241329371506560gmail-fa-exclamation-circle m_-1967660373359177177m_2250241329371506560gmail-orange m_-1967660373359177177m_2250241329371506560gmail-phui-header-icon"></span></span><span></span><img src="cid:ii_itoy1q9k1_157782d4f31ff8a9" width="415" height="121"><br><font size="2"><b>Approach 2: Manual subtask tree</b></font><br></h1><p>The work comprising the Epic is documented in the Phabricator Description field as a list or tree of subcomponents, which may be either lines of text or links to Phabricator sub-tasks. Example: <a href="https://phabricator.wikimedia.org/T122839" target="_blank">T122839: A documented and agreed upon definition of ‘core work’ exists</a>.<br></p><p></p><p>What works well:</p><ul><li>The order of subtasks can be edited</li><li>Small pieces of work can be documented as lines of text instead of complete Phabricator tasks</li><li>The work breakdown is more legible to those expecting a checklist or tree</li><li>Sub-tasks can be documented using the {T######} shortcut, which auto-updates title and status.</li><li>Changes to the Description are well-highlighted in update emails.<br></li></ul><p>What works poorly:</p><ul><li>The subtasks in Phabricator inevitably get out of sync with the list of subtasks in the Description.</li><li>The status of checkboxes in the description inevitably gets out of sync with the status of subtasks</li><li>The history of text-only tasks in the description is not easily accessible in the web interface.<br></li></ul><p>Example:</p><p><img src="cid:ii_itoydn9c2_1577835c8cb3f3af" style="margin-right:0px" width="415" height="156"></p><p>Should we commit to Approach 1 or 2, or are there other approaches which provide the benefits of both?<span class="m_-1967660373359177177HOEnZb"><font color="#888888"><br></font></span></p></div><span class="m_-1967660373359177177HOEnZb"><font color="#888888"><span><font face="georgia, serif"><span style="vertical-align:baseline;white-space:pre-wrap"></span></font></span><span><font face="georgia, serif"><span style="vertical-align:baseline;white-space:pre-wrap"></span></font></span><div class="gmail_default" style="font-family:georgia,serif"><span><font face="georgia, serif"><span style="vertical-align:baseline;white-space:pre-wrap"><br></span></font></span></div><div><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><font color="#888888"><div><b>-- <br>Joel Aufrecht<br></b></div><div>Team Practices Group<b><br></b></div><div>Wikimedia Foundation<br></div></font></div></div></div></div></div></div></div>
</font></span></div>
<br></div></div>______________________________<wbr>_________________<br>
teampractices mailing list<br>
<a href="mailto:teampractices@lists.wikimedia.org" target="_blank">teampractices@lists.wikimedia.<wbr>org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/teampractices" rel="noreferrer" target="_blank">https://lists.wikimedia.org/ma<wbr>ilman/listinfo/teampractices</a><br>
<br></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
teampractices mailing list<br>
<a href="mailto:teampractices@lists.wikimedia.org">teampractices@lists.wikimedia.<wbr>org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/teampractices" rel="noreferrer" target="_blank">https://lists.wikimedia.org/<wbr>mailman/listinfo/teampractices</a><br>
<br></blockquote></div><br></div>