[teampractices] [Engineering] The end of the Roadmap Phabricator project

Fri Jul 3 18:02:02 UTC 2015

Hi Gergo,

First: Thanks for your reply. I always appreciate your ability to point
out things people have missed/forgotten.

<quote name="Gergo Tisza" date="2015-07-02" time="17:47:20 -0700">
> I don't think all (or even the main) use cases of #roadmap are covered by
> the proposal.
> 
> * #user-notice is much more noisy. A #roadmap task is "describing a
> significant new piece of user-facing functionality or the launch of a new
> API or service", while #user-notice should be put on any small bugfix that
> might affect somebody's workflow.[1]

It is more noisy; you're right. And there was a difference between the
two projects. IOW: not everything in #roadmap made sense in #user-notice
and vice versa.

I believe that the use of the [[wikitech:Deployments]] calendar will
provide enough of a safety net for "significant new piece of user-facing
functionality or the launch of a new API or service". I could be wrong
with this belief, but I think it's worth trying.

> It also does not have any time
> component; #user-notice is typically put on some task so that a newsletter
> entry can be made when the task is closed. There is no telling beforehand
> when that will happen. It has proven a great mechanism for making sure that
> users learn of change right before it happens. It is not useful at all for
> getting a high-level overview of what's going to happen (i.e. a roadmap).

Agreed. And honestly, neither was #roadmap. Or, at least, it was so
horrible of an exercise to maintain that the benefit was diminishing for
me. See, for example, what it looks like when I add a new "week of"
column and have to re-order them on the workboard:
https://phabricator.wikimedia.org/F188488

That shows you that each "week of" column stays around forever and front
loads the list of columns when you add a new one making you scroll all
the way down (which will just continue to get longer and longer over
time) to move any new "week of" column to the right position.

We can't just delete or reuse columns either. Deleting isn't possible in
Phab and reusing means we lose all historical context ( tasks previously
in "July 6-10" will, at some random point all of a sudden be in "Jan
5-9" or whatever).

Basically: workboards aren't calendars and forcing them to be one really
sucks :) See below for a proposal for a better way of tracking things
with a time component.

> * the deployment calendar is completely useless for non-developers. (For
> developers, it's just mostly useless, and time-consuming to use.) It also
> only shows the next 1-2 weeks .

And this is the "who's the audience?" question.

1) #roadmap was never advertised very widely nor communicated as "the
place to go for things" (other than it's project page description, which
is pretty well hidden in Phab now that the default page for projects is
the workboard. I really believe that #user-notice is the best tool for
non-developers. We also have #dev-notice for... developer notice :)
People should be using that, regardless of the status of #roadmap.

2) Also, the deployments calendar does show longer term than just 1-2
weeks:
https://wikitech.wikimedia.org/wiki/Deployments#Long_term_callouts

We'll also never rid ourselves of the Deployments calendar for things
that need specific windows of deployment (eg: SWAT deploys or the train
or risky deployments) until we figure out how to mimic that in
Phabricator (which we can't yet, see also: that stupid looking
screenshot above).

> * #release is used by products which have a version number, which the
> majority of Wikimedia software does not. And they don't have a time
> component either. (In general the tag seems fairly useless to me.)

Sure, but it is useful (or will be when people start to use it more;
it's pretty new).

Sidenote: no one thing is a replacement for what #roadmap professed to
be for a couple reasons: 1) #roadmap said it did things that it didn't
do (it never really tracked progress towards a quarterly goal, except
indirectly) and 2) it was very inconsistently used.

> The main use case for #roadmap, as I understand it, is to keep track of
> work towards quarterly goals. Erik's original proposal for the roadmap tag
> said: "this could ultimately replace some of the detail in the on-wiki
> goals pages, and ensure we have a single calendar type view into expected
> deliverables". None of the proposed replacements comes even close to
> fulfilling that role.

Agreed, and my contention is that #roadmap wasn't actually going to
fulfill that goal. It hasn't done that so far and the quarterly goals
reporting/tracking process is still in flux (still primarily drafted in
slide decks and wiki pages, with links to phab tickets, at best).

HOWEVER, if we decide that this part of the #roadmap project is needed,
we can simply revive it. As is right now, #roadmap isn't/wasn't
providing it and keeping it going pretending it is just confuses/lies to
people, unfortunately. :(

For the record: If we want to use something like #roadmap for tracking
quarterly goals, I don't think a single #roadmap project is the way to
go. See the above screenshot for what it is like dealing with
long-lived yet high churn in column name workboards; it's horrible. Phab
(and workboards, really) aren't made for that.

I would prefer, instead, to have canonical eg #201516-Q1 projects that
are for tracking quarterly goals across teams (with columns for either
ETA month or status (in-progress/done)). I know some teams already do
something like this either through projects or tracking tasks:

https://phabricator.wikimedia.org/tag/releng-201516-q1/
https://phabricator.wikimedia.org/T102306

Thanks again, Gergo, for your feedback. I think for now I'm not
convinced we're actually losing anything by not having #roadmap, but,
I'm open to continuing the conversation and revisiting when we know
more/learn more.

(For the record: I'm going on vacation this weekend until July 12th,
which is why I'm working today; getting last minute things done before
taking that week off. If I don't reply soon, you know why now ;) ).

Greg

-- 
| Greg Grossmeier            GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg                A18D 1138 8E47 FAC8 1C7D |