Week of January 2, 2017: French Wikipedia and possibly other wikis that have requested it/we have consensus for. Not en:, de: or similar (perf)?

I can't speak for other Wikipedias, but the [[ https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Le_Bistro/13_d%C3%A9cembre_2016#Cartes_interactives_sur_la_Wikip.C3.A9dia_francophone | initial announcement to the frwiki community made on December 13 ]] so far got 23 people supporting it, out of 23, which makes it 100% support so far. Making a conclusion out of 23 people after a couple of days may be a bit hasty, that's why I'm willing to hear what we think are the next steps in gathering more community support. As we mentioned before, enabling <mapframe> on frwiki does not create any disruption, rather allow people to familiarize with the feature, start working on templates, and add maps within articles if they want to. And they seem to want it.

Yep. We are clearly not launching it this year. First days of new year sounds good to me, we could potentially even announce it to the frwiki unless anyone objects.

Personally, I would prefer that after each wave of rollouts, the team would pause to await feedback. And then to use that time either to fix various issues that have already been reported, or to reduce tech debt (if there is unhealthy debt).

The main benefit of quick/frequent releases is to have a tight feedback loop, and the main benefit of a tight feedback loop is to actually improve the product based on feedback.

Maybe that has already been happening, but my perception is that it has not.

@ksmith I agree that we should give pauses, but we haven't launched or enabled maps for several months - and even there it was just one ruwiki. We have launched structured data, but this is mostly a project that benefits graphs and on-wiki text/list/table content generation, and only marginally - maps. So in a way we have an overlap - while community looks at the structured data, we will jump back to maps deployment (very little technical involvement) and concentrate on the tech debt.

I would like to see mapframe rolled out to the two wikipedias that are currently very interested in that functionality: French and Finnish (T151591). This could be done in early January, as both wikis are excited and interested in the new functionality. I feel that with both of those wikis implementing mapframe - and letting us know of any issues - that'd be a great start to getting maps into a more polished state.

There is a significant amount of technical debt to be done for maps, along with the work that Paul is doing on the map style and disputed borders that can be concentrated on for the next quarter. Plus, we'll need to figure out what to do with the Flagged Revisions - so that if users on those wikis want maps to appear - they can - without having to change things for everyone on that wiki.

I'd like to see the Jan - Mar 2017 time period used to address technical debt and to get the new map styles tested on the wikis and projects that are currently using mapframe and maplink. Then, launch mapframe on additional wikis during the following quarter (April - June).

I think that we are moving with deployments too slow, not too fast and that delaying the deployments EVEN FURTHER would be a threat to the very existence of this project.

While I agree that we should work through solving the technical debt, especially with what Paul is doing, is there any reason to not enable existing map functionality for the other communities and wait additional 4-6 month?

The typical rollout of a new functionality has been done to exponentially grow availability - usually in 2-4 steps, to reduce the overhead with each deployment. We enable new functionality on a small wiki, wait, launch bigger, wait, launch everywhere. We did Wikivoyage, 3 tiny wikis, then ruwiki. By logic, we should now do something totaling 3-4 billion, and if all is ok, launch everywhere. I feel dewiki is not ready yet due to flaggedRev, and Spanish wiki is about the same size but has no flaggedRev, so might be a good substitute. Also, we might as well launch all tiny ones at once, as they tend to have very low traffic. Stats for August:

I would like to keep only fr and fi wikis for the week of January 2nd. It is going to be a short week for me, followed by dev summit / all hands, so limited availability to respond from the whole team (and from other teams as well). Let's keep what is already on track and not add any more wikis in early January (and let's try to launch as early as possible in January).

There is no known blocking issues from an operations perspective to release <maplink/> / <mapframe/> to more wikis. There are still a few considerations to take into account:

• communicate this plan to other Ops (there is an Ops meeting today - Dec 19, the next one with sufficient participation will be Jan 16)
• ensure that we have sufficient availability to react after the launch

I'll already communicate that we plan on activating fr / fi.

In T153158#2886890, @Gehel wrote:

I would like to keep only fr and fi wikis for the week of January 2nd. It is going to be a short week for me, followed by dev summit / all hands, so limited availability to respond from the whole team (and from other teams as well). Let's keep what is already on track and not add any more wikis in early January (and let's try to launch as early as possible in January).

After some more thinking and feedback from my follow Ops, it would make sense to wait until the January 16 week to ensure everyone is back to work.

I see deployments as a 2-step process:

• Initial deployment: little to no disruption
  • Contributors can experiment with the feature
  • Contributors can provide feedback and feature requests
  • Contributors can try to migrate existing templates, and report any flaws in the service, and we can help them do so.
  • Contributors can start inserting maps in articles
  • Traffic is low and easy to digest

• Full community adoption: major disruption
  • Community validates the new templates and accepts its deployment.
  • Thousands to millions of maps inserted in articles
  • Traffic is high and requires more attention

We are currently in the initial deployment of the feature. With this in mind, I think Max's schedule works great.

In T153158#2882496, @debt wrote:

I'd like to see the Jan - Mar 2017 time period used to address technical debt and to get the new map styles tested on the wikis and projects that are currently using mapframe and maplink. Then, launch mapframe on additional wikis during the following quarter (April - June).

I think this approach is too cautious. When a feature is safe and harmless we should aim at deploying it shouldn't we? This is how we will learn the best. I think we have passed the minimum viable product and the extension has already proven to sustain in production on several wiki projects. To my understanding, our technical debt is not a blocker from a user standpoint. However deploying the <mapframe> feature now allows us to gather wide feedback and validate the feature's continued development.

Question: should we do a quick risk estimation? Having a knowledge of what a bad scenario could look like and how we would react if it happens can help us feeling more secure about deploying to production.

In T153158#2882768, @Yurik wrote:

... I feel dewiki is not ready yet due to flaggedRev, and Spanish wiki is about the same size but has no flaggedRev, so might be a good substitute.

Innocent question: How did we get far enough down the line to post this only to discover that we had this incompatibility? Are we sure their are no other surprises before we approach eswiki? :)

I agree with @debt and @Gehel. French and Finnish first. With the holiday, dev summit, and all hands let's do it when we're all back and can respond to concerns/bugs. We can get it on the regular deployment train, communicate amongst ourselves and communities (and Ops), see how things are going with those communities that we enable and discuss the next phase.

This might even give us a chance to get documentation touched up and maybe even translated!

Semi-related: Do we need to schedule a planning meeting and discuss[[ https://www.mediawiki.org/w/index.php?title=File:Interactive_Roadmap_2016-2017.pdf&page=4 | our stated goals ]] for the next quarter(s) and how they reflect reality?

@CKoerner_WMF dewiki is certainly off the table until flagged revs is resolved, as well as any other flaggedrev enabled wikis. Discovering these kinds of cross-extension interactions is increasingly hard, as we have 30-50 of different extensions, and in theory any of them could cause issues. Most of the testing happens on beta cluster, yet some bugs always get through until someone stumbles upon it. Even community didn't catch this one, because most of the people who try new things tend to be trusted, or they experimented on talk pages and user pages (non-flagrev), thus avoided triggering this bug. I noticed it due to an unrelated investigation, and realized that it may cause issues, which was later confirmed.

BTW, this bug also exists for all of graphs, that have been in production for the past 2 years, without that many reports, so it is not that easy to catch.

I also agree about frwiki and fiwiki. The goal of this ticket is to establish a timeline and a pipeline - so that the whole team has a clear understanding of when we should start talking to which community, when we feel we need to slow down (e.g. many new blocking issues are discovered), or when we can speed up. This also means that while engineers are deploying one wiki, we can start talking to another wiki (pipelining).

I think this is a better approach than having one-off deployments, like "lets deploy frwiki and fiwiki, full stop", and then start the whole process of another deployment from scratch, without a clear planning ahead.

I think it'd be great if we can have a planning meeting to specifically spell out the steps needed to improve maps (bug fixes and feature enhancements) during Q3 (Jan - March 2017).

We talk a lot of deploying to various wikis but no real talk of fixing the things that we already know that the communities that have maps have been asking for.

Just deploying to more and more wikis to get wider usage - without fixing/updating the things that we need to do to make the maps great - isn't helping anyone.

In T153158#2891320, @Yurik wrote:

Discovering these kinds of cross-extension interactions is increasingly hard, as we have 30-50 of different extensions, and in theory any of them could cause issues.

146 :) https://phabricator.wikimedia.org/diffusion/OMWC/browse/master/wmf-config/extension-list

Most of the testing happens on beta cluster, yet some bugs always get through until someone stumbles upon it. Even community didn't catch this one, because most of the people who try new things tend to be trusted, or they experimented on talk pages and user pages (non-flagrev), thus avoided triggering this bug. I noticed it due to an unrelated investigation, and realized that it may cause issues, which was later confirmed.

BTW, this bug also exists for all of graphs, that have been in production for the past 2 years, without that many reports, so it is not that easy to catch.

If I understand your response correctly, we got here because it's impossible to keep track of incompatibilities in our software, that's ok (read: normal), and there's nothing to be done to prevent reaching out to communities prematurely?

I also realize this^ conversation is derailing the task at hand. I apologize for starting down that path in the first place. To the matter at hand:

In T153158#2891320, @Yurik wrote:

I think this is a better approach than having one-off deployments, like "lets deploy frwiki and fiwiki, full stop", and then start the whole process of another deployment from scratch, without a clear planning ahead.

I agree. So a regularly scheduled planning meeting then? Informed by our checklist, roadmap and stated goals, attended and agreed upon by all team members. I might even suggest we follow some advice that's worked well for me elsewhere in my work with teams: https://www.mediawiki.org/wiki/Good_meetings (Particularly #Roles)

I find a Phabricator task woefully incompatible for such discussions. I'd much rather spend an hour together with a clear agenda, a shared editable doc, and the expectation that we figure it out together vs piecemeal like this task. For example, I don't feel comfortable editing the task description with what I think we're all agreeing the dates should be. It's also not clear to me who (or when) decides that this proposed schedule is agreed upon.

@CKoerner_WMF hehe, yes, there is a big list there. And yes, there is no way to guarantee that there are no bug in production. I am pretty sure not a single piece of software makes that claim :) Look at our logs - there are tens, if not hundreds of error messages per second there, from all sort of systems, and we find this acceptable. The bigger ones get addressed sooner, the less frequent ones - not as fast if ever. It is a reasonable trade off between usability (works for 99.9% of the people) vs 100% no bug. It is a game of diminishing returns. Clearly we should go for that 99.9% vs 1%, so we try to automate the most commons code path testings, and we should do even more. But as I said before - I don't think actually stumbled upon this issue in production, it was caught by us.

@debt, could you schedule a meeting? Sounds like a good idea :)

My point here is that there are "blocking" tasks - those that must be done before we roll it out anywhere, and there are nice to have tasks - something that allows community to test and use the product in 90 / 99 / 99.9% of the cases, but fails completely, or requires a workaround (less severe) for some cases. We need to decide which bug is which, and either not deploy at all until blockers are fixed, or proceed with the deployment as it will benefit the 90 / 99 / 99.9.

In T153158#2891498, @Yurik wrote:

We need to decide which bug is which, and either not deploy at all until blockers are fixed, or proceed with the deployment as it will benefit the 90 / 99 / 99.9.

There is some possible middle ground, too. For example, a guideline might be that the number of reported but unfixed bugs should not grow (or not grow faster than X). In other words, keep moving forward, BUT also spend some effort cleaning up existing known issues, rather than just letting all the "non-blockers" pile up into a massive problem.

I don't know how this team should prioritize new deployments against new features against improvements against bug fixes. As a general rule, I trust the product owner to make those decisions.

@debt @Yurik please remember to keep this ticket updated.

Change 330311 had a related patch set uploaded (by MaxSem):
Enable mapframe on frwiki and fiwiki

https://gerrit.wikimedia.org/r/330311

A very surprising discovery: despite not having <mapframe> enabled, an experimental template that I built as a GRAPH demo (with some nice styling help from @JGirault in our spare time in Brussels) has spread out and now has ~400 in elwiki, ~30 in enwiki and euwiki, ~13,000+ usages in cawiki, and some more in other wikis. The template allows users to insert a map (street map snapshot) together with any icons or symbols, into any wikis. Also, users like it despite graph having the same flaggedRevs issue as maps (not a single complaint so far about this, which suggests its not as big of an issue as we thought it is).

• template itself
• enwiki usage examples

For others, follow the interwiki links and click "what links here".

I'd like to suggest being a bit more generous with tasks :-). I was wondering why https://de.wikipedia.org/wiki/Wikipedia:Technik/Werkstatt#Interaktive_Karten_auf_Wikipedia was never followed up, and after a lot of reading I understand that Kartographer doesn't play nicely with Flagged Revisions, and so dewiki is on hold ATM. It would be nice if there would be a task "Enable <mapframe> on German Wikipedia" (and others) with the relevant blockers to that, so that progress can be tracked more easily. If the issues with Flagged Revisions do not apply to <maplink> and that could be enabled independently of <mapframe>, it would be helpful if there was a separate task for that as well for gradual deployment.

In T153158#2995675, @scfc wrote:

I'd like to suggest being a bit more generous with tasks :-). I was wondering why https://de.wikipedia.org/wiki/Wikipedia:Technik/Werkstatt#Interaktive_Karten_auf_Wikipedia was never followed up, and after a lot of reading I understand that Kartographer doesn't play nicely with Flagged Revisions, and so dewiki is on hold ATM. It would be nice if there would be a task "Enable <mapframe> on German Wikipedia" (and others) with the relevant blockers to that, so that progress can be tracked more easily. If the issues with Flagged Revisions do not apply to <maplink> and that could be enabled independently of <mapframe>, it would be helpful if there was a separate task for that as well for gradual deployment.

Hey! Thanks for checking in. There's been a lot that's changed recently, and the tasks are in a bit of disarray as you noticed. That's my responsibility, so I apologise. I'll try to get them a bit more organised over the next few days. For now, the primary tracking task is T155601, so hopefully that should answer a few of your questions about where we're at. Hope that helps.

Given that Q3 2016-17 is now in the past, should we not close this as declined?

If we keep this open, we should rename it to Q4, Q1, or remove the specific dates from the title.

Keeping the wording approximately the same, but the title of this ticket has been renamed to reflect a more vague timeline.