[teampractices] Triaging bugs and managing task backlog in Phabricator

Subramanya Sastry ssastry at wikimedia.org
Wed Dec 3 07:39:05 UTC 2014


Top-posting since I have related but a more generic question about 
managing this in Phabricator.

Given a set of tasks in a project, it looks like we can create different 
slices/views of the tasks along different projects:

* via priority
* via tags
* via workboard columns
* via saved search queries
* via sub-tasks of a larger task
* .. any other? .. (I am sure there are: for example, I can look at my 
assigned tasks across projects)

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).

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.

But, perhaps tags are best suited for bugzilla components, not sure.

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.

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.

Thanks,
Subbu.

On 12/03/2014 10:37 AM, Matthew Flaschen wrote:
> On 12/02/2014 04:32 PM, S Page wrote:
>> The default column in every workboard is "Backlog". With this approach I
>> think it makes sense to rename that column in the team's project board
>> to something like "Needs team triage" or "Consider for next sprint".
>
> 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.
>
>> Should/can we lock a project tag down so only members of the project can
>> add this project to tasks?  I don't think so, that makes inter-team
>> dependencies (Scrum-of-scrums) harder.
>
> 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.
>
> Matt Flaschen
>
> _______________________________________________
> teampractices mailing list
> teampractices at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices




More information about the teampractices mailing list