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 <[email protected]> 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 | _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
