<div dir="ltr"><a href="https://www.mediawiki.org/wiki/Phabricator/Project_management">https://www.mediawiki.org/wiki/Phabricator/Project_management</a> is the document to (help to) answer all these questions. It's a draft, but with your help it will eventually become a collection of useful guidelines.<br><div><br></div><div>The section "Organizing your projects" explains how teams are dealing with multiple projects. You are invited to add your own projects as examples.</div><div><br></div><div>"Setting up a Workboard or Sprint board" includes a list of real examples of column names in boards. Feel free to add your own.</div><div><br></div><div>"Maintaining boards" includes a list of open tasks popular among product owners / project managers like Anne, especially in the lines of preventing that people external to the team messes with your meticulously maintained boards.</div><div><br></div><div>Please keep sharing your questions and experiences that worked or didn't. This is the only sensible way to work on useful guidelines.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 3, 2014 at 8:39 AM, Subramanya Sastry <span dir="ltr"><<a href="mailto:ssastry@wikimedia.org" target="_blank">ssastry@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Top-posting since I have related but a more generic question about managing this in Phabricator.<br>
<br>
Given a set of tasks in a project, it looks like we can create different slices/views of the tasks along different projects:<br>
<br>
* via priority<br>
* via tags<br>
* via workboard columns<br>
* via saved search queries<br>
* via sub-tasks of a larger task<br>
* .. any other? .. (I am sure there are: for example, I can look at my assigned tasks across projects)<br>
<br>
There are redundancies here which is a good thing. For example, tags could clearly be used for setting custom priorities (not that it is a great use case).<br>
<br>
Tasks / sub-task view can be used to create well-defined tasks that can be broken down into smaller pieces that multiple members could collaborate on. But, tags can be used as well.<br>
<br>
But, perhaps tags are best suited for bugzilla components, not sure.<br>
<br>
The workboard, with its compact column view could be pretty useful to give a bird's eye view of the project along some axis. So, every project has to figure out what that axis is.<br>
<br>
So, my broader question is: what have people figured out about how to best use these project slicing capabilities in phabricator? I imagine it is largely determined by what kinds of UI is provided, and the semantics that these individual terms evoke in our minds. For example, workboard view with its UI seems particularly well-suited for a certain bird's eye view of the project that is not possible with other slices.<br>
<br>
Thanks,<br>
Subbu.<div class="HOEnZb"><div class="h5"><br>
<br>
On 12/03/2014 10:37 AM, Matthew Flaschen wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 12/02/2014 04:32 PM, S Page wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The default column in every workboard is "Backlog". With this approach I<br>
think it makes sense to rename that column in the team's project board<br>
to something like "Needs team triage" or "Consider for next sprint".<br>
</blockquote>
<br>
Hmm, this is an interesting question (whether to have a big backlog on the team board and allow essentially anything related to be tagged Core-Features, or limit it to things that are imminently considered for team work).  I think the first one may be simpler.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Should/can we lock a project tag down so only members of the project can<br>
add this project to tasks?  I don't think so, that makes inter-team<br>
dependencies (Scrum-of-scrums) harder.<br>
</blockquote>
<br>
Yeah, I don't think this is necessary (especially if the "big backlog" approach is chosen).  We have to remember that sometimes our team should be involved in tasks that aren't part of Flow or Echo per se, so the Core-Features tag is a good way to associate such tasks.<br>
<br>
Matt Flaschen<br>
<br>
______________________________<u></u>_________________<br>
teampractices mailing list<br>
<a href="mailto:teampractices@lists.wikimedia.org" target="_blank">teampractices@lists.wikimedia.<u></u>org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/teampractices" target="_blank">https://lists.wikimedia.org/<u></u>mailman/listinfo/teampractices</a><br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
teampractices mailing list<br>
<a href="mailto:teampractices@lists.wikimedia.org" target="_blank">teampractices@lists.wikimedia.<u></u>org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/teampractices" target="_blank">https://lists.wikimedia.org/<u></u>mailman/listinfo/teampractices</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Quim Gil<br>Engineering Community Manager @ Wikimedia Foundation<br><a href="http://www.mediawiki.org/wiki/User:Qgil" target="_blank">http://www.mediawiki.org/wiki/User:Qgil</a></div>
</div>