[teampractices] Triaging bugs and managing task backlog in Phabricator

[Anne Gomez]

I'm just starting to look at moving fr-tech to phabricator and have been
wondering these questions to myself (along with the other thread about
teams). I'm wondering if it might make sense to have a project for bug
tracking that is public/open and a project for just the internal team to
work on that would include the sprint board and not allow editing by
others.

I worry that using 1 board for all bug tracking and sprints will end up
being way too complicated.



On Tue, Dec 2, 2014 at 2:57 PM, James Forrester <jforrester at wikimedia.org>
wrote:

> On 2 December 2014 at 13:32, S Page <spage at wikimedia.org> wrote:
>
>> (Are all WMF teams on this mailing list?)
>>
>
> ​Possibly not. :-(​
>
> ​[Snip]​
>
>
>
>> Do other teams have team boards in Phabricator?
>>
>
> ​Yes. In Editing land, the vast majority of our work is either on
> VisualEditor itself, or on things that touch it. Consequently, we use a
> pretty big workboard for the team's work, which has a default column of "To
> triage", a hidden-by-default "backlog" column, four columns for different
> fields of "next-up" tasks, and doing and sign-off columns:
>
> https://phabricator.wikimedia.org/project/board/483/?hidden=true
>
>
> Other areas of work generally have a very simple backlog/next-up/doing
> set-up – the Front-End standardisation project uses this, with a second
> one for the OOUI workstream more generally:
>
> https://phabricator.wikimedia.org/project/board/24/
> https://phabricator.wikimedia.org/project/board/697/
>
>
> The Performance project uses the same, with performance also being a key
> VisualEditor-land piece of work (principle tracking of the work is done in
> the Performance workboard as it's cross-team):
>
> https://phabricator.wikimedia.org/project/board/196/
>
>
> There's also the various extensions we care about, like Cite, WikiEditor
> and TemplateData; the work here is mostly VisualEditor-related, so to date
> we've not had an issue running things out of VE. However, I also line these
> up because we have volunteers who work on items and it's important to give
> them cues about priorities:
>
> https://phabricator.wikimedia.org/project/board/172/
> https://phabricator.wikimedia.org/project/board/342/
> https://phabricator.wikimedia.org/project/board/638/
>
>
> Similarly, the OOjs workstream is exceedingly lightweight:
>
> https://phabricator.wikimedia.org/project/board/748/
>
>
>
> The Beta Feature software workstream has a similar basic board for
> prioritisation:
>
> https://phabricator.wikimedia.org/project/board/741/
>
> … and also a project for software-that-provides-a-Beta-Feature, which
> doesn't feel like it needs a workboard at this point:
>
> https://phabricator.wikimedia.org/tag/beta-feature/
>
>
> Finally, there are the services on which the Editing team's work depends,
> Citoid, Parsoid, RESTbase and others, where we're a mixture of principal
> customer and driver of features:
>
> https://phabricator.wikimedia.org/project/board/62/
> https://phabricator.wikimedia.org/project/board/487/
> https://phabricator.wikimedia.org/project/board/833/
>
> J.
> --
> James D. Forrester
> Product Manager, Editing
> Wikimedia Foundation, Inc.
>
> jforrester at wikimedia.org | @jdforrester
>
> _______________________________________________
> teampractices mailing list
> teampractices at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>


-- 
Anne Gomez
Product Manager, Online Fundraising
https://wikimediafoundation.org/

*Imagine a world in which every single human being can freely share in the
sum of all knowledge. That's our commitment. Donate.
<https://donate.wikimedia.org/>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/teampractices/attachments/20141202/44832e7a/attachment.html>