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