[teampractices] Use cases for work tracking, sub-projects, etc in Phabricator

Tue Apr 5 07:19:38 UTC 2016

Hi,

On Tue, Mar 8, 2016 at 1:02 AM, Joel Aufrecht <jaufrecht at wikimedia.org>
wrote:

> Quim:
>>
>
>> Community Liaisons and Developer Relations have a much simpler process,
>> but I still wonder whether we could improve it by using subprojects.
>>
>> We have team projects to tag any tasks related to our teams, i.e.
>> https://phabricator.wikimedia.org/project/view/27/
>>
>> Then, we organize what we call monthly sprints but is actually not a
>> "Sprint project" but a tag that we add to tasks that we plan to work on a
>> certain month, without a commitment to finish them, no story points, no
>> burndown. See for instance
>> https://phabricator.wikimedia.org/project/view/1649/
>>
>> In theory, these monthly sprints could be subprojects of our team
>> project, right? If I understood the subprojects feature correctly, this
>> would mean that
>>
>> * Tasks in a sprint (subproject) would not appear in the main project
>> (team) workboard, which would be useful to see the tasks that haven't been
>> scheduled yet.
>> * Tasks in one subproject (i.e. #Liaisons-March-2016) could still be
>> added to other subprojects as well (April, May, etc).
>>
>> Do you think this approach makes sense?
>>
>
> I think that should work as you have described it.  Please let us know!
>

Done: expect that we went for quarterly milestones instead of monthly
milestones, in order to align better with quarterly goals:

Community Liaisons: https://phabricator.wikimedia.org/project/view/27/
Developer Relations: https://phabricator.wikimedia.org/project/view/33/

Pros:
* Milestones appear automatically in the project info page, so they are
easier to find even if you don't know they exist.
* Milestones appear automatically in the parent project workboard, with
their own column, at the right of the columns you have created manually (if
any). The header of that column links to the milestone's workboard so,
again, user can find them better even when they don't know they exist.
* Tasks moved from the parent project to a milestone project are really
moved: Herald with remove the task from the parent as it is being added to
the milestone. Less duplication and arbitrariety combining parent projects
and milestones/sprints.
* In the task there is only one tag with a clear description i.e.
"Developer-Relations (Apr-Jun-2016)". Again, cleaner and more consistent.

Cons:
* None found so far?

Neutral:
* Milestones have a sense of sequence: you create one milestone and then
the "next milestone". So far this semantic detail doesn't seem to be used
for much, other than sorting milestones in product info pages and
workboards.

I haven't played with "subprojects" yet. We might have a use case
considering i.e. the #Wikimedia-Developer-Summit-2017 a subproject of
#Developer-Relations. I wonder how subprojects and milestones play together
and with parent projects, but we are in no rush to experiment further, now
that we got the new milestones.

-- 
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/teampractices/attachments/20160405/3026947e/attachment.html>