Hello all,
First, some history and context:
The #roadmap project[0] in our Phabricator instance was set up by Erik M as a trial way of tracking upcoming releases, deployments, and generally "new things of note", as these previously weren't tracked in one place. It has a workboard[1] that is is broken up into: * one column for each week for the current month * one column for each remaining month in the current quarter * then "not soon"
The scope of this project covered both "things that might break the site or are otherwise risky" and also "things people might expect to be notified about". At the time things got released quite often without a standard way for people to find that they were coming.
I helped Erik with maintaining this project because it was also useful for our weekly "roadmap and deployments update" meeting where most WMF engineering managers got together for about 15-30 minutes to go over: * What, of note, is going out next week? * What, of note, is going out in the near term (i.e.: next few weeks)? * Anything else we should know about?
Outcomes of this meeting were: * An updated outline of upcoming deployments on the Deployment Calendar[2] ** This helped inform the work of the WMF RelEng and Ops teams, especially * A time/space for people (especially Erik or others with intimate "community knowledge/intuition") to object to something going out at all, or at the proposed time
Since this project was set up, Guillaume started the #user-notice and #developer-notice projects [4][5], which cover the "things to tell people about" a lot better, are much more general covering incidents and planned outages as well as code deployments, and are communicated out via volunteer translators to dozens of community notice boards every week.
== Current world / Assessment ==
We are still using the #roadmap project for a lot of things that don't risk deployment/stability disruption, and also updating the Deployments Calendar on wikitech. It is my opinion that there is not enough gain from maintaining both work products to justify the effort, especially as #user-notice and #developer-notice have become so valuable.
== Proposal ==
I propose that we discontinue the use of #roadmap.
Potential gaps created by the deprecating of #roadmap and my proposed solutions:
* Lack of a project that tracks big upcoming software/product releases ** The #release[3] project was created for this
* Lack of a time-scale perspective of upcoming releases/deployments ** I believe that the Deployments Calendar[2], while imperfect (wiki templates), fulfills this
* Users aren't informed of upcoming changes ** the #user-notice[4] project in Phabricator should be used for that
== Expectations ==
To successfully do this (deprecate #roadmap) I expect all WMF Engineering teams (as the group of developers I have more influence over versus the Wikimedia engineering community) to pro-actively communicate out their plans, in public, with the appropriate use of the Deployments Calendar and the #user-notice Phabricator project. This means engaging with the Community Engagement/Liaison team when appropriate.
In no small way this is me, as Release Manager, showing trust in the work of the WMF Engineering teams (which includes the product managers). Do good things with it :-)
Let me know if you have any concerns,
Greg
[0] https://phabricator.wikimedia.org/project/profile/1109/ [1] https://phabricator.wikimedia.org/project/board/1109/ [2] https://wikitech.wikimedia.org/wiki/Deployments [3] https://phabricator.wikimedia.org/project/profile/1333/ [4] https://phabricator.wikimedia.org/tag/user-notice/ [5] https://phabricator.wikimedia.org/tag/developer-notice/
On Thu, Jul 2, 2015 at 4:17 PM, Greg Grossmeier greg@wikimedia.org wrote:
Let me know if you have any concerns,
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 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). * 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 . * #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.)
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.
[1] which, as we know, is a rather low bar. https://xkcd.com/1172/
+teampractices
On Thu, Jul 2, 2015 at 4:17 PM, Greg Grossmeier greg@wikimedia.org wrote:
Hello all,
First, some history and context:
The #roadmap project[0] in our Phabricator instance was set up by Erik M as a trial way of tracking upcoming releases, deployments, and generally "new things of note", as these previously weren't tracked in one place. It has a workboard[1] that is is broken up into:
- one column for each week for the current month
- one column for each remaining month in the current quarter
- then "not soon"
The scope of this project covered both "things that might break the site or are otherwise risky" and also "things people might expect to be notified about". At the time things got released quite often without a standard way for people to find that they were coming.
I helped Erik with maintaining this project because it was also useful for our weekly "roadmap and deployments update" meeting where most WMF engineering managers got together for about 15-30 minutes to go over:
- What, of note, is going out next week?
- What, of note, is going out in the near term (i.e.: next few weeks)?
- Anything else we should know about?
Outcomes of this meeting were:
- An updated outline of upcoming deployments on the Deployment Calendar[2]
** This helped inform the work of the WMF RelEng and Ops teams, especially
- A time/space for people (especially Erik or others with intimate "community knowledge/intuition") to object to something going out at all, or at the proposed time
Since this project was set up, Guillaume started the #user-notice and #developer-notice projects [4][5], which cover the "things to tell people about" a lot better, are much more general covering incidents and planned outages as well as code deployments, and are communicated out via volunteer translators to dozens of community notice boards every week.
== Current world / Assessment ==
We are still using the #roadmap project for a lot of things that don't risk deployment/stability disruption, and also updating the Deployments Calendar on wikitech. It is my opinion that there is not enough gain from maintaining both work products to justify the effort, especially as #user-notice and #developer-notice have become so valuable.
== Proposal ==
I propose that we discontinue the use of #roadmap.
Potential gaps created by the deprecating of #roadmap and my proposed solutions:
- Lack of a project that tracks big upcoming software/product releases
** The #release[3] project was created for this
- Lack of a time-scale perspective of upcoming releases/deployments
** I believe that the Deployments Calendar[2], while imperfect (wiki templates), fulfills this
- Users aren't informed of upcoming changes
** the #user-notice[4] project in Phabricator should be used for that
== Expectations ==
To successfully do this (deprecate #roadmap) I expect all WMF Engineering teams (as the group of developers I have more influence over versus the Wikimedia engineering community) to pro-actively communicate out their plans, in public, with the appropriate use of the Deployments Calendar and the #user-notice Phabricator project. This means engaging with the Community Engagement/Liaison team when appropriate.
In no small way this is me, as Release Manager, showing trust in the work of the WMF Engineering teams (which includes the product managers). Do good things with it :-)
Let me know if you have any concerns,
Greg
[0] https://phabricator.wikimedia.org/project/profile/1109/ [1] https://phabricator.wikimedia.org/project/board/1109/ [2] https://wikitech.wikimedia.org/wiki/Deployments [3] https://phabricator.wikimedia.org/project/profile/1333/ [4] https://phabricator.wikimedia.org/tag/user-notice/ [5] https://phabricator.wikimedia.org/tag/developer-notice/
-- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Engineering mailing list Engineering@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/engineering
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
As an outside observer, I'm a bit concerned about the deprecation of one of the few tools used to give a "big picture" overview of what is coming, who is scheduling what, and the ability to identify conflicting or competing priorities. Engineering has done some outstanding work, but there have also been major work collisions that have had serious and widespread negative effects (e.g., releasing major changes to language tools and VE at the same time in late June/early July 2013 which directly and negatively impacted on customer satisfaction with the entire project as well as both extensions). In old-school management systems, this is called a silo effect and is one of the more serious outcomes of a lack of requiring co-ordinated planning and sharing of information. Not only does the information need to be shared, but it needs to be able to be easily visualized, repeatedly referred to, and its impacts understood. Sending more emails to each other is not going to replace the visual benefit of the roadmap board.
From what I read here, the current roadmap software is difficult to use and
is not being used consistently; nor is it all that effective at tracking progress toward goals. Before getting rid of it, though, I would urge the team to identify and implement an alternative to track this information in an easily accessible, centralized location that is well-publicized and is considered the 'bible' for this information. There are all kinds of tools out there that do just this kind of tracking; none of them will be perfect. (You're engineers, you know that.) It's really important that the left hand know what the right hand is doing.
Good luck in your choices.
Risker/Anne
On 3 July 2015 at 13:30, Arthur Richards arichards@wikimedia.org wrote:
+teampractices
On Thu, Jul 2, 2015 at 4:17 PM, Greg Grossmeier greg@wikimedia.org wrote:
Hello all,
First, some history and context:
The #roadmap project[0] in our Phabricator instance was set up by Erik M as a trial way of tracking upcoming releases, deployments, and generally "new things of note", as these previously weren't tracked in one place. It has a workboard[1] that is is broken up into:
- one column for each week for the current month
- one column for each remaining month in the current quarter
- then "not soon"
The scope of this project covered both "things that might break the site or are otherwise risky" and also "things people might expect to be notified about". At the time things got released quite often without a standard way for people to find that they were coming.
I helped Erik with maintaining this project because it was also useful for our weekly "roadmap and deployments update" meeting where most WMF engineering managers got together for about 15-30 minutes to go over:
- What, of note, is going out next week?
- What, of note, is going out in the near term (i.e.: next few weeks)?
- Anything else we should know about?
Outcomes of this meeting were:
- An updated outline of upcoming deployments on the Deployment Calendar[2]
** This helped inform the work of the WMF RelEng and Ops teams, especially
- A time/space for people (especially Erik or others with intimate "community knowledge/intuition") to object to something going out at all, or at the proposed time
Since this project was set up, Guillaume started the #user-notice and #developer-notice projects [4][5], which cover the "things to tell people about" a lot better, are much more general covering incidents and planned outages as well as code deployments, and are communicated out via volunteer translators to dozens of community notice boards every week.
== Current world / Assessment ==
We are still using the #roadmap project for a lot of things that don't risk deployment/stability disruption, and also updating the Deployments Calendar on wikitech. It is my opinion that there is not enough gain from maintaining both work products to justify the effort, especially as #user-notice and #developer-notice have become so valuable.
== Proposal ==
I propose that we discontinue the use of #roadmap.
Potential gaps created by the deprecating of #roadmap and my proposed solutions:
- Lack of a project that tracks big upcoming software/product releases
** The #release[3] project was created for this
- Lack of a time-scale perspective of upcoming releases/deployments
** I believe that the Deployments Calendar[2], while imperfect (wiki templates), fulfills this
- Users aren't informed of upcoming changes
** the #user-notice[4] project in Phabricator should be used for that
== Expectations ==
To successfully do this (deprecate #roadmap) I expect all WMF Engineering teams (as the group of developers I have more influence over versus the Wikimedia engineering community) to pro-actively communicate out their plans, in public, with the appropriate use of the Deployments Calendar and the #user-notice Phabricator project. This means engaging with the Community Engagement/Liaison team when appropriate.
In no small way this is me, as Release Manager, showing trust in the work of the WMF Engineering teams (which includes the product managers). Do good things with it :-)
Let me know if you have any concerns,
Greg
[0] https://phabricator.wikimedia.org/project/profile/1109/ [1] https://phabricator.wikimedia.org/project/board/1109/ [2] https://wikitech.wikimedia.org/wiki/Deployments [3] https://phabricator.wikimedia.org/project/profile/1333/ [4] https://phabricator.wikimedia.org/tag/user-notice/ [5] https://phabricator.wikimedia.org/tag/developer-notice/
-- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Engineering mailing list Engineering@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/engineering
-- Arthur Richards Team Practices Manager [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
From what I read here, the current roadmap software is difficult to use and is not being used consistently;
In fact, until this thread, I didn't even know that people were making a roadmap in phab...
-- bawolff
On Fri, Jul 3, 2015 at 11:02 AM, Greg Grossmeier greg@wikimedia.org wrote:
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:
I am inclined to support this proposal. These quarterly goal projects could be of type "Goal" (orange, with a checkered flag icon).
Kevin
wikitech-l@lists.wikimedia.org