<div dir="ltr">Thanks, Mukunda! Good stuff. :)<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I try to very gently discourage using herald to tag everything with a 
parent project. It hasn't become a problem yet but ultimately herald 
rules do not scale.</blockquote><div><br></div><div>Thanks for the reminder. I definitely guilty of thinking about this stuff more theoretically sometimes, and it's easy to say "Herald will fix it" without acknowledging the practical aspects.<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">When something moves from backlog it can go into a future milestone, the
 current milestone or into the "debt" column for a future tech debt 
sprint.</blockquote><div><br></div><div>I really dig the idea of collecting tasks under a Tech Debt Milestone and then tackling it when it reaches a certain size. It's sort of like filling up a bucket with water from a leak, and then emptying it when it reaches your established limit. Works with existing mountains of debt, too, but I think it just requires more discipline.<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> So I would recommend scoping your milestones so that they are limited 
to whatever you feel is a manageable set of tasks that doesn't become 
overwhelming to look at.</blockquote><div><br></div><div>An analogy for many things in our line of work. :-D<br><br> <br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 5, 2017 at 5:27 PM, Mukunda Modell <span dir="ltr"><<a href="mailto:mmodell@wikimedia.org" target="_blank">mmodell@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"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Thu, Oct 20, 2016 at 7:42 PM, Max Binder <span dir="ltr"><<a href="mailto:mbinder@wikimedia.org" target="_blank">mbinder@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span class="m_1128857387784444036gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">For bigger 'epic' tasks, it might be better to collect them together under a milestone in the parent project.</blockquote><div><br></div></span><div>I agree with this. I think for sagas, you can have a whole dedicated project, and for epics, you can have Milestones. If the Milestones are a problem (they don't allow relative prioritization of tasks on the same board, they create #toomanycolumns, etc) then you can create a dedicated Milestone board, and Herald tag everything on that board with the parent project.<br><br></div></div></blockquote></span><div><br><div>I try to very gently discourage using herald to tag everything with a parent project. It hasn't become a problem yet but ultimately herald rules do not scale. The herald rules themselves are tedious to create and maintain and they are slow for phabricator to process. If we get too many herald rules then phabricator will be slow and fixing it will be tedious. The overhead is in the range of 10ms to 100ms per herald rule.<br><br></div><div>I didn't start out to be a naysayer though. I am really replying to to share some team practices with the group based on experience with the #Scap3
 project.<br><br><a href="https://phabricator.wikimedia.org/project/board/1449/" target="_blank">https://phabricator.wikimedia.<wbr>org/project/board/1449/</a>
 is the parent project. It could be a sub-project under our team project 
but it's currently a top-level project. The top level workboard is 
mostly for backlog and high-level categorization of the tasks. We have 
created milestones that approximately correspond to quarterly goals. 
When something moves from backlog it can go into a future milestone, the
 current milestone or into the "debt" column for a future tech debt 
sprint. Further prioritization and progress tracking happens within each
 milestones' workboard:<br><br><a href="https://phabricator.wikimedia.org/project/subprojects/1449/" target="_blank">https://phabricator.wikimedia.<wbr>org/project/subprojects/1449/</a><br><br></div><div>We
 still end up with epic tasks and the phabricator task graph helps with 
those but I think milestones are nice for this sort of thing. Milestones could represent any amount of work, not just quarterly goals, however, the key advantage in keeping them small is that you can easily see everything on one screen. So I would recommend scoping your milestones so that they are limited to whatever you feel is a manageable set of tasks that doesn't become overwhelming to look at.<br><br></div><div>The line between manageable and overwhelming is obviously subjective but I think it's useful to think of milestones in this way.<br></div><div><br></div>Anyway that's my $0.02 about milestones.<br><br></div><div>Happy Practicing,<br></div><div>Mukunda<br></div><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>This approach doesn't preclude Epics. Indeed, you'll find yourself with tasks that you didn't realize were as big as they turned out to be, or that get scope creep. That's fine. If that's the case, though, ruthless grooming into dedicated projects and Milestones seems appropriate.<br><br></div><div>Regardless, it seems like all of these approaches benefit from having someone who pays attention to the growing task list and constantly sorts and prioritizes.<br></div></div><div class="m_1128857387784444036gmail-HOEnZb"><div class="m_1128857387784444036gmail-h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 12, 2016 at 12:47 AM, Mukunda Modell <span dir="ltr"><<a href="mailto:mmodell@wikimedia.org" target="_blank">mmodell@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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="m_1128857387784444036gmail-m_6405525112375075991HOEnZb"><div class="m_1128857387784444036gmail-m_6405525112375075991h5"><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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div 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 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>I think this issue intersects with:<br><br></div><div>Should we "explode" tasks pro-actively/early? I am increasingly thinking the answer is "no". <br><br></div><div>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_1128857387784444036gmail-m_6405525112375075991m_-641595961238461688m_-1967660373359177177gmail_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="m_1128857387784444036gmail-m_6405525112375075991m_-641595961238461688h5">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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="m_1128857387784444036gmail-m_6405525112375075991m_-641595961238461688h5"><div dir="ltr"><div 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 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 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 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 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 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 style="font-family:georgia,serif"><h1 class="m_1128857387784444036gmail-m_6405525112375075991m_-641595961238461688m_-1967660373359177177m_2250241329371506560gmail-phui-header-view"><span class="m_1128857387784444036gmail-m_6405525112375075991m_-641595961238461688m_-1967660373359177177m_2250241329371506560gmail-phui-header-header"><span class="m_1128857387784444036gmail-m_6405525112375075991m_-641595961238461688m_-1967660373359177177m_2250241329371506560gmail-visual-only m_1128857387784444036gmail-m_6405525112375075991m_-641595961238461688m_-1967660373359177177m_2250241329371506560gmail-phui-icon-view m_1128857387784444036gmail-m_6405525112375075991m_-641595961238461688m_-1967660373359177177m_2250241329371506560gmail-phui-font-fa m_1128857387784444036gmail-m_6405525112375075991m_-641595961238461688m_-1967660373359177177m_2250241329371506560gmail-fa-exclamation-circle m_1128857387784444036gmail-m_6405525112375075991m_-641595961238461688m_-1967660373359177177m_2250241329371506560gmail-orange m_1128857387784444036gmail-m_6405525112375075991m_-641595961238461688m_-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_1128857387784444036gmail-m_6405525112375075991m_-641595961238461688m_-1967660373359177177HOEnZb"><font color="#888888"><br></font></span></p></div><span class="m_1128857387784444036gmail-m_6405525112375075991m_-641595961238461688m_-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 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" 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>
</div></div><br>______________________________<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>
</div></div><br>______________________________<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></div></div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 20, 2016 at 7:42 PM, Max Binder <span dir="ltr"><<a href="mailto:mbinder@wikimedia.org" target="_blank">mbinder@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"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">For bigger 'epic' tasks, it might be better to collect them together under a milestone in the parent project.</blockquote><div><br></div></span><div>I agree with this. I think for sagas, you can have a whole dedicated project, and for epics, you can have Milestones. If the Milestones are a problem (they don't allow relative prioritization of tasks on the same board, they create #toomanycolumns, etc) then you can create a dedicated Milestone board, and Herald tag everything on that board with the parent project.<br><br></div><div>This approach doesn't preclude Epics. Indeed, you'll find yourself with tasks that you didn't realize were as big as they turned out to be, or that get scope creep. That's fine. If that's the case, though, ruthless grooming into dedicated projects and Milestones seems appropriate.<br><br></div><div>Regardless, it seems like all of these approaches benefit from having someone who pays attention to the growing task list and constantly sorts and prioritizes.<br></div></div><div class="m_1128857387784444036HOEnZb"><div class="m_1128857387784444036h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 12, 2016 at 12:47 AM, Mukunda Modell <span dir="ltr"><<a href="mailto:mmodell@wikimedia.org" target="_blank">mmodell@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><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="m_1128857387784444036m_6405525112375075991HOEnZb"><div class="m_1128857387784444036m_6405525112375075991h5"><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_1128857387784444036m_6405525112375075991m_-641595961238461688m_-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="m_1128857387784444036m_6405525112375075991m_-641595961238461688h5">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="m_1128857387784444036m_6405525112375075991m_-641595961238461688h5"><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_1128857387784444036m_6405525112375075991m_-641595961238461688m_-1967660373359177177m_2250241329371506560gmail-phui-header-view"><span class="m_1128857387784444036m_6405525112375075991m_-641595961238461688m_-1967660373359177177m_2250241329371506560gmail-phui-header-header"><span class="m_1128857387784444036m_6405525112375075991m_-641595961238461688m_-1967660373359177177m_2250241329371506560gmail-visual-only m_1128857387784444036m_6405525112375075991m_-641595961238461688m_-1967660373359177177m_2250241329371506560gmail-phui-icon-view m_1128857387784444036m_6405525112375075991m_-641595961238461688m_-1967660373359177177m_2250241329371506560gmail-phui-font-fa m_1128857387784444036m_6405525112375075991m_-641595961238461688m_-1967660373359177177m_2250241329371506560gmail-fa-exclamation-circle m_1128857387784444036m_6405525112375075991m_-641595961238461688m_-1967660373359177177m_2250241329371506560gmail-orange m_1128857387784444036m_6405525112375075991m_-641595961238461688m_-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_1128857387784444036m_6405525112375075991m_-641595961238461688m_-1967660373359177177HOEnZb"><font color="#888888"><br></font></span></p></div><span class="m_1128857387784444036m_6405525112375075991m_-641595961238461688m_-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" 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>
</div></div><br>______________________________<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>
</div></div><br>______________________________<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>
</div></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>