Re: [teampractices] Triaging bugs and managing task backlog in Phabricator

2014-12-09 Thread Arthur Richards 
On Tue, Dec 9, 2014 at 3:22 PM, Jared Zimmerman <
jared.zimmer...@wikimedia.org> wrote:

> Arthur, at Autodesk we use "for Review" and "Waiting Approval" (depending
> on team) for this state, and "Done" was used only when something was
> integrated into production.
>

This makes sense. At the end of the day, it's up to individual teams to
figure out what 'done' means for them, and whether or not it makes sense
for 'done' to be category on their workboard. The bigger points I was
trying to make with my previous email are that the swim lanes/categories on
one team's workboard may be entirely different from another team's, and
that 'done' means different things for different teams. To wit, teams
should have swim lanes/categories on their workboard that make sense for
their workflow, and teams should have a shared definition/understanding of
what 'done' means to them.

-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Triaging bugs and managing task backlog in Phabricator

2014-12-09 Thread Jared Zimmerman 
Arthur, at Autodesk we use "for Review" and "Waiting Approval" (depending
on team) for this state, and "Done" was used only when something was
integrated into production.



*Jared Zimmerman * \\  Director of User Experience \\ Wikimedia Foundation

M +1 415 609 4043 \\  @jaredzimmerman 


On Tue, Dec 9, 2014 at 2:15 PM, Arthur Richards 
wrote:

>
> On Tue, Dec 2, 2014 at 10:03 PM, Matthew Flaschen  > wrote:
>>
>> I have been wondering why people have a Done/Completed column in
>> Phabricator.  Phabricator, unlike Trello, has a Resolved concept built-in.
>>
>
> When I used to work on the mobile web team, a 'Done' column was to
> indicate that a piece of work was completed, as far as whoever was working
> on it was concerned. But the card wouldn't get fully closed (in this case,
> marked as a resolved), until the person with final say (eg the product
> owner) verified that it was indeed fully complete.
>
> --
> Arthur Richards
> Team Practices Manager
> [[User:Awjrichards]]
> IRC: awjr
> +1-415-839-6885 x6687
>
> ___
> teampractices mailing list
> teampractices@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Triaging bugs and managing task backlog in Phabricator

2014-12-09 Thread Arthur Richards 
On Tue, Dec 2, 2014 at 10:03 PM, Matthew Flaschen 
wrote:
>
> I have been wondering why people have a Done/Completed column in
> Phabricator.  Phabricator, unlike Trello, has a Resolved concept built-in.
>

When I used to work on the mobile web team, a 'Done' column was to indicate
that a piece of work was completed, as far as whoever was working on it was
concerned. But the card wouldn't get fully closed (in this case, marked as
a resolved), until the person with final say (eg the product owner)
verified that it was indeed fully complete.

-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Triaging bugs and managing task backlog in Phabricator

2014-12-08 Thread Matthew Flaschen 

On 12/03/2014 02:39 AM, Subramanya Sastry wrote:

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


There are already many examples of tags besides components, including 
https://phabricator.wikimedia.org/tag/core-features/ , 
https://phabricator.wikimedia.org/tag/verified/ , and 
https://phabricator.wikimedia.org/tag/wmf-deploy-2014-12-10_%281.25wmf12%29/ 
/


So tags are useful for many different use cases.

Matt Flaschen


___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Triaging bugs and managing task backlog in Phabricator

2014-12-03 Thread Quim Gil 
https://www.mediawiki.org/wiki/Phabricator/Project_management 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.

The section "Organizing your projects" explains how teams are dealing with
multiple projects. You are invited to add your own projects as examples.

"Setting up a Workboard or Sprint board" includes a list of real examples
of column names in boards. Feel free to add your own.

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

Please keep sharing your questions and experiences that worked or didn't.
This is the only sensible way to work on useful guidelines.

On Wed, Dec 3, 2014 at 8:39 AM, Subramanya Sastry 
wrote:

> 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@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/teampractices
>>
>
>
> ___
> teampractices mailing list
> teampractices@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>



-- 
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Triaging bugs and managing task backlog in Phabricator

2014-12-02 Thread Subramanya Sastry 
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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices



___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Triaging bugs and managing task backlog in Phabricator

2014-12-02 Thread Matthew Flaschen 

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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Triaging bugs and managing task backlog in Phabricator

2014-12-02 Thread Matthew Flaschen 

On 12/02/2014 04:49 PM, Bryan Davis wrote:

We are using these columns today:
* To Do
* In Dev/Progress
* Needs Review/Feedback
* Done
* Archive (hidden)

Rather than create a new board for each iteration/sprint/whatever we
are using the archive column as a storage area for things that have
been completed in past iterations. After each retrospective (weekly
meeting) somebody will move all of the items from the Done column into
the Archive column to reset the board.


I have been wondering why people have a Done/Completed column in 
Phabricator.  Phabricator, unlike Trello, has a Resolved concept built-in.


I take  it from this explanation that you go over completed tasks in 
retrospective.  The Core Features team mainly uses retrospective as an 
opportunity to discuss things that worked well/didn't work and how we 
can improve our processes.  There is much less focus on individual 
cards, though broad product areas (and how we did on them) are discussed.


For teams that work like this (including Core Features), I don't think 
there is any need for a Done column (the default of showing only Open 
tasks should be sufficient).


Matt Flaschen

___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Triaging bugs and managing task backlog in Phabricator

2014-12-02 Thread svetlana 
On Wed, 3 Dec 2014, at 12:18, Bryan Davis wrote:
> On Tue, Dec 2, 2014 at 5:06 PM, Anne Gomez  wrote:
> > 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'd personally like to see everyone default to open rather than closed
> groups.

+1

> If there is significant spam or griefing then closed groups
> might be the only recourse, but assume good faith and embrace the
> openness that we are allowed in our organizational structure.

Spam should not be an issue - there's plenty of volunteers who'd be happy to 
offer a hand.

What is «griefing»? Sounds like something out of the ordinary (bottom line, it 
would force people to make things read-only and invite-only), but not hide them 
from the public view.

___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Triaging bugs and managing task backlog in Phabricator

2014-12-02 Thread Bryan Davis 
On Tue, Dec 2, 2014 at 5:06 PM, Anne Gomez  wrote:
> 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'd personally like to see everyone default to open rather than closed
groups. If there is significant spam or griefing then closed groups
might be the only recourse, but assume good faith and embrace the
openness that we are allowed in our organizational structure.

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

I think it's completely reasonable that anyone doing scrum or another
management system with well organized sprints can choose to use a new
board (project as project == board in phab) for tracking each sprint.

Bryan
-- 
Bryan Davis  Wikimedia Foundation
[[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
irc: bd808v:415.839.6885 x6855

___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Triaging bugs and managing task backlog in Phabricator

2014-12-02 Thread 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 
wrote:

> On 2 December 2014 at 13:32, S Page  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.
>
> jforres...@wikimedia.org | @jdforrester
>
> ___
> teampractices mailing list
> teampractices@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.
*
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Triaging bugs and managing task backlog in Phabricator

2014-12-02 Thread James Forrester 
On 2 December 2014 at 13:32, S Page  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.

jforres...@wikimedia.org | @jdforrester
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Triaging bugs and managing task backlog in Phabricator

2014-12-02 Thread Kevin Leduc 
Our boards are a WIP too and we're eager to use burndown for Phabricator
once it's deployed (https://phabricator.wikimedia.org/T153)

Our main backlog board is here:
https://phabricator.wikimedia.org/project/board/840/
It's where we groom our tasks, prioritize and point them.  Many of these
tasks cover our various platforms which each have their own project
(Analytics-EventLogging, Analytics-Wikimetrics, etc)

At our sprint planning meeting, we create a new project (type sprint) and
move the item to that new board.  It helps keep distinct what the team has
committed to from the backlog:
https://phabricator.wikimedia.org/project/board/848/




On Tue, Dec 2, 2014 at 1:54 PM, Antoine Musso  wrote:

> Le 02/12/2014 22:32, S Page a écrit :
> >   Do other teams have team boards in Phabricator?
>
> Sure!
>
> MediaWiki-Core-Team:
> https://phabricator.wikimedia.org/project/board/37/
>
> Release-Engineering:
> https://phabricator.wikimedia.org/project/board/20/
>
> The later being my team.  Among other projects, we are responsible for
> the Beta cluster (staging area) and Continuous Integration which have
> their own boards:
>
> CI: https://phabricator.wikimedia.org/project/board/401/
> Beta cluster: https://phabricator.wikimedia.org/project/board/497/
>
> CI uses software components such as jenkins and zuul which might well
> have their own boards. I merely load the default page which list opened
> task, ex for 'zuul': https://phabricator.wikimedia.org/tag/zuul/
>
>
> For both beta cluster and CI, only parent / tracking tasks are marked
> with the team project.  That helps keep the team workboard light weight
> for our weekly team check-ins.
>
>
> As the lead for CI, I open the workboards several times per day and move
> cards around as needed. I even created my own dashboard which I have
> 'installed' as the default Phabricator homepage:
>
>  https://phabricator.wikimedia.org/dashboard/view/6/
>
> It has:
>
> - a text box with links to the board / projects that matter to me
> - tasks assigned to me by priority
> - tasks I authored
> - team related searches
> - all tasks I am subscribed to
>
> That let me look for a task using my browser search.
>
>
> Some troubles I have:
>
>
> I often end up closing tasks without moving to the appropriate column.
> That is merely to save a few page loads and clicks. Once closed, a task
> disappear from the workboard, so it is imho not much of an issue.
>
>
> Often tasks are blocked by another team / project. I am considering
> opening sub task for the other team so they can assign/set priority
> according to their rule / triage workflow.  So I would end up with:
>
>  T42 install more servers for CI
>   project: continuous-integration
>   assignee: me!
>   priority:  high
>   column: externally blocked
>
>  T43 install servers for CI
>   project: operations
>   assignee: none
>   priority: need triage
>   column:  backlog
>
> This way it is clear that CI wise I am responsible for that action, on
> the other hand it is clear that ops need to acknowledge it.
>
> Potentially each card could have a per project assignee/priority much
> like they have a per project column.
>
>
> We are still iterating / figuring out a good workflow. I guess it would
> take us all a few more weeks to refine.
>
>
> --
> Antoine "hashar" Musso
>
>
> ___
> teampractices mailing list
> teampractices@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Triaging bugs and managing task backlog in Phabricator

2014-12-02 Thread Antoine Musso 
Le 02/12/2014 22:32, S Page a écrit :
>   Do other teams have team boards in Phabricator?

Sure!

MediaWiki-Core-Team:
https://phabricator.wikimedia.org/project/board/37/

Release-Engineering:
https://phabricator.wikimedia.org/project/board/20/

The later being my team.  Among other projects, we are responsible for
the Beta cluster (staging area) and Continuous Integration which have
their own boards:

CI: https://phabricator.wikimedia.org/project/board/401/
Beta cluster: https://phabricator.wikimedia.org/project/board/497/

CI uses software components such as jenkins and zuul which might well
have their own boards. I merely load the default page which list opened
task, ex for 'zuul': https://phabricator.wikimedia.org/tag/zuul/


For both beta cluster and CI, only parent / tracking tasks are marked
with the team project.  That helps keep the team workboard light weight
for our weekly team check-ins.


As the lead for CI, I open the workboards several times per day and move
cards around as needed. I even created my own dashboard which I have
'installed' as the default Phabricator homepage:

 https://phabricator.wikimedia.org/dashboard/view/6/

It has:

- a text box with links to the board / projects that matter to me
- tasks assigned to me by priority
- tasks I authored
- team related searches
- all tasks I am subscribed to

That let me look for a task using my browser search.


Some troubles I have:


I often end up closing tasks without moving to the appropriate column.
That is merely to save a few page loads and clicks. Once closed, a task
disappear from the workboard, so it is imho not much of an issue.


Often tasks are blocked by another team / project. I am considering
opening sub task for the other team so they can assign/set priority
according to their rule / triage workflow.  So I would end up with:

 T42 install more servers for CI
  project: continuous-integration
  assignee: me!
  priority:  high
  column: externally blocked

 T43 install servers for CI
  project: operations
  assignee: none
  priority: need triage
  column:  backlog

This way it is clear that CI wise I am responsible for that action, on
the other hand it is clear that ops need to acknowledge it.

Potentially each card could have a per project assignee/priority much
like they have a per project column.


We are still iterating / figuring out a good workflow. I guess it would
take us all a few more weeks to refine.


-- 
Antoine "hashar" Musso


___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Triaging bugs and managing task backlog in Phabricator

2014-12-02 Thread Bryan Davis 
On Tue, Dec 2, 2014 at 2:32 PM, S Page  wrote:
> (Are all WMF teams on this mailing list?)
>
> "Core features" (aka the Flow team) is responsible for several extensions
> (Flow, Echo, Thanks, ...). We have a team board we're going to use to manage
> the current sprint.
> And we have a lot of bugs to triage.
>
> I'm thinking rather than having a separate team backlog board, a triager
> will nominate a bug for consideration by adding our team board to the task's
> Projects field.
>
> 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".
>
> Also, our team board appears to be editable by anyone. How can we lock it
> down so that only members of the project can add columns and move tasks
> around on it?
>
> 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.
>
> Comments?  Do other teams have team boards in Phabricator?
>
> This approach is in
> https://www.mediawiki.org/wiki/Flow/Team/Processes#Bug_triage , I will move
> it to https://www.mediawiki.org/wiki/Phabricator/Project_management if
> there's consensus (or no response :) ).
>
> Thanks. Interesting times!

MediaWiki-Core has been experimenting with a Phab board for about a
month [0]. We are hoping to get "more serious" about using it now that
the bugzilla migration is complete. We are mostly trying to do a
Kanban inspired process to help us visualize our work in progress and
bottlenecks. Arthur helped us come up with the columns and their
associated work in progress limits during a team training retreat in
October.

We are using these columns today:
* To Do
* In Dev/Progress
* Needs Review/Feedback
* Done
* Archive (hidden)

Rather than create a new board for each iteration/sprint/whatever we
are using the archive column as a storage area for things that have
been completed in past iterations. After each retrospective (weekly
meeting) somebody will move all of the items from the Done column into
the Archive column to reset the board. Originally we intended the Done
column to be final and just resolve the tasks after the retrospective.
This however turned out to be difficult as helpful people would find
the various tasks in the products they are associated with and close
them for us. :)

The one thing I think we may end up wanting in the future is a
separate board/project to track larger work items (themes/epics) that
are being groomed for our next quarterly planning.

[0]: https://phabricator.wikimedia.org/project/board/37/
-- 
Bryan Davis  Wikimedia Foundation
[[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
irc: bd808v:415.839.6885 x6855

___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

[teampractices] Triaging bugs and managing task backlog in Phabricator

2014-12-02 Thread S Page 
(Are all WMF teams on this mailing list?)

"Core features" (aka the Flow team) is responsible for several extensions
(Flow, Echo, Thanks, ...). We have a team board
 we're going to use to
manage the current sprint.
And we have a lot of bugs to triage.

I'm thinking rather than having a separate team backlog board, a triager
will nominate a bug for consideration by adding our team board to the
task's *Projects* field.

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

Also, our team board appears to be editable by anyone. How can we lock it
down so that only members of the project can add columns and move tasks
around on it?

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.

Comments?  Do other teams have team boards in Phabricator?

This approach is in
https://www.mediawiki.org/wiki/Flow/Team/Processes#Bug_triage , I will move
it to https://www.mediawiki.org/wiki/Phabricator/Project_management if
there's consensus (or no response :) ).

Thanks. Interesting times!
-- 
=S Page  Features engineer
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices