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(a)wikimedia.org> wrote:
+teampractices
On Thu, Jul 2, 2015 at 4:17 PM, Greg Grossmeier <greg(a)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(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l