[teampractices] Phabricator Project Types -> Sprint Extension

[Christopher Johnson]

There has been a good bit of dialogue in the past about the association of
time windows in the Phabricator project model.  The Sprint extension
requirement for start and end dates assignments to a project has been a
recurring bother for many teams who would rather not associate a time
window to their projects, but would like to use the Points field.

For the next Sprint extension and Phabricator update, a proposition exists
to show the start and end dates on as default fields on the project
creation form.  This is seen as a remedy to the confusion with these
parameters being "required" for Sprint projects.  We are looking for
consensus on whether this is OK.  Please chime in so that we can move
forward.

In thinking about this a bit more, however, it occurs to me that another
simple default solution exists that could also help alleviate this pain
point.  This is a constantly "floating" time window.  Basically, if the
dates are not set for a Sprint, the default values could be set to *now - 2
weeks* for start and *now + 2 weeks* for end.  This allows for the two
primary "perspectives" for a Sprint Type project, retrospective analysis
and projection.  This also essentially eliminates the need to create a new
project for every Sprint, which seems to me a bit cumbersome. Nevertheless
a "floating window" does not really jibe with the Agile method, which sets
a fixed end date target for each development iteration.  But not all
software development projects require the Agile method.

It is my general observation that the Sprint extension seems too limited
for the variety of project management that occurs at WMF.  Clearly, a "one
size fits all" solution is not the best option.  The implementation of a
more abstract "Project Type" application I think would be a logical step
towards greater flexibility for PM in Phabricator. Basically, a "Project
Type" interface could allow teams to assign custom fields to their unique
Project type definition  These Project Type to custom field associations
would be static, but could be broad enough to fill more than just one need,
like Agile.  Perhaps brainstorming these possibilities at the Hackathon
would be useful.

For a global progress view for longer retrospection (without forecasting),
for example, a new project type could be created, the "Backlog" project.
This type of project allows point assignments, and could offer new analysis
reports on progress over extended periods.  Assigning a project as a
"Backlog" type, could then offer a different reporting interface, etc.

Upstream may eventually implement a similar option.  So waiting to see what
they do is also an alternative.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/teampractices/attachments/20150427/98e2c132/attachment.html>