Hi all,
<quote name="Erik Moeller" date="2013-09-16" time="10:55:21
-0700">
On Sat, Sep 7, 2013 at 2:01 PM, Steven Walling
<swalling(a)wikimedia.org> wrote:
Weekly deployment plans/notes
This monthly roadmap spreadsheet/wiki page
Quarterly plans, as represented in
https://www.mediawiki.org/wiki/Wikimedia_Engineering/2013-14_Goals and other
places
Yearly/annual plans
This is too much.
Like you, I'd argue in favor of scrapping the roadmap as it exists
today, but I think we should do a better job making the Deployments
page more informative. For example, now that we're working towards a
proper beta mode on mobile _and_ desktop, it would IMO be useful to
summarize which features are currently in beta and planned to enter
production soon. We still have too many situations where people are
caught by surprise by a deployment, both internally and externally.
Sorry for my radio silence here until now.
In short: yes, let's scrap the current incarnation of the Roadmaps
update. It was a good solution for a while, to help keep everyone
abreast of what was coming/being worked on, but it, as we all agree,
wasn't a part of anyone's workflow (in a useful way). While the Roadmap,
as an independent product, was useful for some, it's creation wasn't.
== The future ==
As Erik alluded to, let's make the Deployments page[0] more
information/useful for everyone. This could supersede the current
usefulness of the Roadmap. Some ideas that have been thrown around to
make that happen:
* Include the tech/team/project leads, not director level people in the
meeting that produces the artifact. Not every team/project lead would
need to be in every weekly Deployments update meeting, of course. They
would come when it made sense for them (the week before a deploy, for
instance).
* Make the Deployments page know more about what is coming further in
advance. There will be an (obvious?) inverse relationship between how
soon something is and the exactness of it's date. In other words:
Things going out in the next couple weeks will have a day+time. Things
going out in the next month will have a day or range of days. Things
going out in the next quarter-ish will have a week or two range.
* Make the Deployments page know more about the deployments(!!!). This
has the same inverse relationship as the 'when' above. Things going
out in the next couple weeks will have a page, somewhere (preferably
on wikitech) describing what is going on in that deploy (who's doing
it (team and individuals hitting enter) and what it includes (bug#s,
changeIDs, etc)). Some teams are already doing this as it already is a
part of a good workflow for managing their deploys internally. See
Mobile:
https://www.mediawiki.org/wiki/Extension:MobileFrontend/Deployments
=== Benefits ===
* NO MORE GOOGLE SPREADSHEET!!!!!
* All on wiki, thus history and real diffs/accountability.
* We don't need all projects represented at every meeting.
* It'll utilize projects already in-use planning instruments (mostly, or
they can be exported to a wiki page easily, see eg Mobile above).
* More informative Deployments page which means hopefully no more
surprises.
== Next steps ==
The details still need to be worked out, and we'll discuss this at the
next Roadmap/Deployments update meeting (this Friday), but I hope we can
get this done quickly.
Greg
[0]
https://wikitech.wikimedia.org/wiki/Deployments - It lives on
wikitech.wm.org mostly because it should really be accessible in the
event that there is a production cluster outage to definitively answer
questions like "What the heck just deployed?" or "What deployed last
week that grew CPU usage so quickly?"
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |