Hello all,
I have a mea culpa: I haven't been doing the Roadmap update emails lately. The short of it is: it is dang hard and not time-efficient for me to try to parse Google Doc's 'revision history' in a big spreadsheet. That's why we (Robla) created a script to download and convert to wikitext (and upload to mediawiki.org) the Roadmap. Then we get real diffs.
My laptop was stolen a while ago and on it was my local modifications to that script to make it work for me (committed to git, but not push anywhere because the project wasn't in gerrit yet..., laziness on my part).
With that:
Please take a look at he latest version of the Roadmap at: http://ur1.ca/felvl (Google Doc spreadsheet, my apologies)
Some things to look at (ie: have been updated recently): * Flow * Language-team related items * TechOps September column * Platform/Site Architecture * Wikidata * QA sept/oct columns * ECT's sept/oct/nov columns
Sorry about the lack of specificity.
Any questions, please don't hesitate to ask,
Greg
Greg Grossmeier wrote:
Please take a look at he latest version of the Roadmap at: http://ur1.ca/felvl (Google Doc spreadsheet, my apologies)
Oddly, in Chrome, I can't access the spreadsheet (Google insists that I need to sign in); in Safari, it loads just fine.
What do the grey cells indicate?
It's a bit worrying to see so many blank boxes in the Analytics section. It's, by far, the area of Wikimedia tech engineering that needs the most guidance and direction. I see a note about "Hadoop infrastructure revisit (AndrewO/Leslie/Asher)" in a separate section, but no links to any docs for this work. This is unfortunate. There's an entire Analytics team at the Wikimedia Foundation, yet most of the stats that users are interested in are still incredibly limited and come from the work of two volunteers (Domas and Henrik). This entire area of Wikimedia is pretty sad. I'd really like to see more focus on how we can either improve or eliminate the analytics team. As it is, it simply seems wasteful.
The entire "TechOps" section could use more links. (Who's Ceph?)
For "Central code repository (very tentative)", I hope someone will first look at https://meta.wikimedia.org/wiki/Special:Permalink/5497282. There are a lot of global "bits and pieces" that need further thought.
The Flow section seems pretty ambitious and pretty ambiguous. "Full production release to select WikiProject discussion spaces" on which project(s)? Quite a few projects are very hesitant to try any new discussion system given the past abandonment of LiquidThreads, leaving their projects without any meaningful support. Other projects are highly skeptical of a discussion system that won't be able to support wikimarkup.
For account creation, there's no planned work, yet we still have a giant Toolserver (soon to be Tool Labs) dependency, don't we (cf. https://toolserver.org/~acc/)? Are there any plans to address this? Surely this crosses the "in use in production" threshold, meaning it needs to be migrated into a MediaWiki extension or into MediaWiki core.
I don't see any mention of "SUL finalisation" on the roadmap. What's going on there?
This whole chart would be easier to view, edit, and comment on if it were on a wiki page. I'm not sure what stolen laptops and scripts in Git have to do with anything. Just stop using a Google Doc spreadsheet and use the wiki. If the wiki is insufficient, document why (using Bugzilla or an RFC on mediawiki.org) and we can work to address any shortcomings.
MZMcBride
Hey,
Currently, we have...
- 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. I say we get everyone to sprint on filling out https://www.mediawiki.org/wiki/Wikimedia_Engineering/2013-14_Goals, and then abandon this spreadsheet nonsense. We don't need this much duplication at the week/month/three month/year level.
On Fri, Sep 6, 2013 at 2:49 PM, Greg Grossmeier greg@wikimedia.org wrote:
Hello all,
I have a mea culpa: I haven't been doing the Roadmap update emails lately. The short of it is: it is dang hard and not time-efficient for me to try to parse Google Doc's 'revision history' in a big spreadsheet. That's why we (Robla) created a script to download and convert to wikitext (and upload to mediawiki.org) the Roadmap. Then we get real diffs.
My laptop was stolen a while ago and on it was my local modifications to that script to make it work for me (committed to git, but not push anywhere because the project wasn't in gerrit yet..., laziness on my part).
With that:
Please take a look at he latest version of the Roadmap at: http://ur1.ca/felvl (Google Doc spreadsheet, my apologies)
Some things to look at (ie: have been updated recently):
- Flow
- Language-team related items
- TechOps September column
- Platform/Site Architecture
- Wikidata
- QA sept/oct columns
- ECT's sept/oct/nov columns
Sorry about the lack of specificity.
Any questions, please don't hesitate to ask,
Greg
-- | 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
On Sat, Sep 7, 2013 at 2:01 PM, Steven Walling swalling@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.
Agreed, let's rationalize this a bit. Part of the point of the Roadmap with monthly breakdowns was to create an overview where people can more easily anticipate e.g. architectural conversations and inter-team sync-ups that need to happen. It's not working for that, because it's not part of anyone's workflow.
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.
Erik
On Mon, Sep 16, 2013 at 10:55 AM, Erik Moeller erik@wikimedia.org wrote:
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.
The mobile web team has been trying to summarize what's going out in our weekly deployments: https://www.mediawiki.org/wiki/Extension:MobileFrontend/Deployments
We've found this tremendously useful both from a pre- and post- deployment perspective. Michelle Grover has been doing some work around automating the generation of these reports, though I believe it's still a WIP.
On Mon, Sep 16, 2013 at 10:55 AM, Erik Moeller erik@wikimedia.org wrote:
On Sat, Sep 7, 2013 at 2:01 PM, Steven Walling swalling@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.
Agreed, let's rationalize this a bit. Part of the point of the Roadmap with monthly breakdowns was to create an overview where people can more easily anticipate e.g. architectural conversations and inter-team sync-ups that need to happen. It's not working for that, because it's not part of anyone's workflow.
For what it is worth, *reading* it is a part of my workflow. But it does appear to this outsider that (based on the ebb and flow of updates) it doesn't look like *updating* it is part of anyone's workflow.
Luis
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@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?"
On Sep 16, 2013, at 10:55 AM, Erik Moeller erik@wikimedia.org wrote:
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.
I assume we're still at the "as is" stage? with some plan to normalize around:
1) Engineering goals for quarterly and yearly: https://www.mediawiki.org/wiki/Wikimedia_Engineering/2013-14_Goals 2) Deployments for weekly and monthly: https://wikitech.wikimedia.org/wiki/Deployments 3) Intra-team documentation
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.
To get there, I assume?
* We'd probably actually have to update (1) and commit to keeping up to date (at least every quarter, preferably more often) * We'd need to add some sort of monthly view into (2). It's a pity it's on Wikitech when the actual project pages are mostly on mediawiki, so some sort of template transclusion is out, I assume * a beta mode column? to be in (2) * Some sort of historical record a la Mobile Web https://www.mediawiki.org/wiki/Extension:MobileFrontend/Deployments as suggested by Arthur sounds like a good idea for (3) * If that is the case, mating that with status updates for the teams is probably work saving for monthly engineering report statuses: e.g. https://www.mediawiki.org/wiki/Category:Wikimedia_engineering_reports * I assume we should link (3) to (1) and (2) somehow.
Is that about right?
<quote name="Terry Chay" date="2013-09-18" time="10:50:09 -0700">
Is that about right?
From my perspective, yep. What I was thinking in just different words :)
Greg
wikitech-l@lists.wikimedia.org