[teampractices] "Roadmap" project in Phabricator

[Erik Moeller]

On Tue, Mar 10, 2015 at 12:49 AM, Quim Gil <qgil at wikimedia.org> wrote:

> What exactly are you missing? For what is worth, there is
> Assign due date to task and have tasks with due dates displayed on a
> calendar (similar to Trello)
> https://phabricator.wikimedia.org/T76094
>

The key time-related user stories I can think of are:
- As a PM or dev, I want to specify a projected due date, release date or
release window for a specific task.
- As a manager or stakeholder (incl. community), I want to see the
top-level roadmap, and specific project-level roadmaps.
- As a release manager, I want to see the deployments planned for the next
two weeks.

Right now we're addressing this by:
- managing a top level roadmap as workboards
- specifying dates/ranges in comments and workboard columns
- managing the main deployments calendar as a separate wiki page, and
additional deployment calendars on additional wiki pages

This means redundancy: I have to monitor the tasks for updates on ETAs and
then reflect those in the roadmap. It's also possible that there are other
workboard views that specify dates in column names which are impacted as
dates change, but not auto-updated.

It also means dispersal: For example, I have to know that the Language
Engineering team maintains its own deployments calendar and where to find
it ( https://www.mediawiki.org/wiki/Content_translation/Deployment_Plan ).

This isn't nearly as bad as the situation we had when we still used 20
different PM tools, but it seems like one of the next big project
management challenges to tackle. I'm not suggesting we solve it all in one
go. What I'd suggest is:

- Get the data structure right first. Make sure we have the ability to
specify what we want as a property of the task and query it. I can't speak
for Greg and whether he's interested in moving off wiki-based deployments
pages. For roadmap purposes, though, it's important to be able to specify
both a specific date _or_ a range.

This won't help with the redundancy yet -- though basic queryability would
speed things up a bit. I don't buy the argument that the field is clutter
in the default view -- I think it will actually push us to think a bit more
about when things hit, which is a good thing for everyone.

- Support upstream in specifying requirements for the calendar views we'd
ideally like to see. (I'd be open to sponsoring development and influencing
it -- but would advise against full-time WMF staff working on this.)

I would advise against "dates as projects". There are just too many
variants of date expressiveness that we need for this to work (ideally from
hour-level precision up to a large date range).

Erik

-- 
Erik Möller
VP of Product & Strategy, Wikimedia Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/teampractices/attachments/20150310/0f2d13d6/attachment.html>