Page MenuHomePhabricator

Deploy Kartographer extension to Wikivoyage
Closed, ResolvedPublic


Once Kartographer is stable in the labs, deploy it to production for Wikivoyage

Event Timeline

Yurik raised the priority of this task from to High.
Yurik updated the task description. (Show Details)
Yurik added projects: Maps, Maps (Kartographer).
Yurik added subscribers: Yurik, MaxSem, greg and 3 others.
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Aklapper renamed this task from Deploy Kartographer extenion to Wikivoyage to Deploy Kartographer extension to Wikivoyage.Mar 2 2016, 11:00 AM
Aklapper set Security to None.
Aklapper added a subtask: Restricted Task.

Is there a (vague) date for this deployment?
Will this be announced in Tech News (via Notice) one week before this deployment happens?

@Aklapper, we were planning to enable it today. Thanks for the link to the technews, I will post something there too. The extension will be almost invisible to the regular usage because it simply adds a few new tags: <mapframe>, <maplink>, and <mapdata>.

@MaxSem and I agreed on next week when he asked me in-office, why the change?

And it's not on the calendar for today: So, next week it is, and the reason we agreed was to get it in TechNews.

@greg, thx, I was not aware of the change to next week.

Btw, please propose a date/time next week, kthxbai :)

scheduled - monday at 14:00 Pacific

I would -2 this based on the fact we still have <mapdata>. Once that feature has been deployed it will be nearly impossible for us to remove it from the extension and it is a bad architectural direction.

Esanders added subscribers: ssastry, Jdforrester-WMF, Catrope.

Adding T125686 as a blocking task, which is not resolved. Until that is resolved the extension is not stable.

An email to ops@ talked about also deploying to but I can't find any Phabricator task mentioning that?
(In general, I appreciate transparency of plans by updating related venues.)

I've removed it from the schedule as there are blocking tasks that will take some time to resolve.

Johan moved this task from Backlog to Keep track of on the User-Johan board.
Johan moved this task from To Triage to Not ready to announce on the User-notice board.

Bumping this to a later issue of Tech News if we're not sure about the time frame.

(Thanks for adding it, @Yurik! Makes my life easier.)

Update (Copying from T125686)

@Esanders and I spoke today about the potential way forward. Our tentative agreement (Ed please correct) is that if we address these issues, the deployment may proceed as planned.

  • (done) Kartographer will remove the <mapdata>, as it implies there is a page-level data scope vs tag-level. If needed, the same functionality can be achieved with the hidden <maplink> tag.
  • For T125301, Kartographer will for now implement the <mapframe> as right-aligned (left-aligned on RTL) by default. @Esanders will suggest the best way to specify alignment with the <mapframe ...> attributes for the future version.
  • Kartographer on Wikivoyage will run under a scary™ flag, e.g. $wgKartographerWikivoyageMode = true;
  • For non-Wikivoyage, we should have an additional, wider discussion. For now, non-Wikivoyage mode will not support cross-tag data sharing, so any data defined inside one mapframe or maplink will have no affect on any other map tags.

For the very first version, we will only support right alignment and only wikivoyage, thus won't be a blocker.

Don't re-schedule the deployment until all the blocking tasks are resolved and thoroughly tested. There's no need to rush this out on Monday.

Specifically finalising the default layout (frame and caption + right align) as subsequent changes will break content (T125301)

@Esanders, I plan to deploy it to just one small wiki (Ru Wikivoyage) so that community can experiment with it and give us feedback. I prefer to release early and release often -- I'm sure there will be plenty of changes regardless of how "polished" we make it. It will be a while until any significant amount of content will be using it, so any changes will be OK at first.

There are breaking changes we have lined up compared to the current state (e.g. captions). Enabling on a production wiki, however small, is a big step because we immediately start accruing content we need to support, so it won't hurt to not rush it.

I tend to agree with the argument that @Esanders is making, fwiw. My vote is to wait until that blocker is resolved correctly.

@greg, @Esanders, this is NOT a blocker. Neither @MaxSem nor I see an immediate need for the caption - maps are different from images. Map is a map, especially for wikivoyage. This feature could be added, and it might be "nice to have", but it bears nearly not the same weight as a caption for an image.

P.S. please take a look at wikivoyage - the only caption that maps are using are the links like "View full-screen map for Salzburg" (see here) -- and full screen have built in into the map itself, so its not needed.

Once again: adding captions is not a breaking change. It's 100% b/c.


Ok, I misunderstood the severity. What's the timeline for rectifying the issue?

@greg, b/c = backwards compatible. Severity is minimal simply because we don't know if/how we want it done. Its absolutelly not critical (or might not even be needed) for wikivoyage. I think we will still add it because in Wikipedia it would be good to mark things like "the map of the oil spill" in the article about the disaster. Still contemplating it to provide the MVP so that we won't have to remove the features later.

It is if we get rid of the inline mode, or change whether inline/captioned in the default mode that is a breaking change. Let's just give ourselves the time to work it out properly, instead of creating an arbitrarily tight deadline.

@Esanders, we do NOT have the inline mode. As we discussed yesterday, we will only provide right align frame by default (left for RTL), and we will provide a way to specify left/center/right alignment for that frame. Since we won't have captioning from the beginning, it won't be a breaking change to add it later if we choose to do so.
The deadline is not tight, but I will be going on vacation soon. So the earlier we release it, the more time we will have to address community-raised issues, which I suspect will be much more severe than the lack of caption. And again, this is being deployed for a very small community at first, so not an issue regardless.

My apologies, I realized the reason for the confusion - we still had the "inline" mode as a blocking task, even though we already decided not to do inline for the MVP. The issue has been updated and resolved.

If the wiki's users decide they need a frame and therefore implement them using wrapping divs, making the map framed by default later would be a breaking change.

@Esanders of course we will need to speak with the community about the visual aspects of the map's frame, and for that the community needs to experiment with it, decide how it should look, and tell us what they think. Once decided, we can easily add some gray frame around the map, or however it is needed. But this won't happen until the community plays with it first. This won't be a big deal - the map will simply change from no-frame to a small frame, just a minor visual adjustment.
As for wrapping in a template - wikivoyage already wraps all their maps in templates, and we will try to provide enough functionality for this not to happen with the new tags. VE geojson editor should be a good-enough incentive for that. But initial migration will use a template regardless, simply because it is easier to modify one template than to update every page on the wiki.

OK, so conflicting information here.

Will this be deployed this week? Yes/no/don't know?

@Johan, from IRC today:

19:36:36  <yurik> edsanders, i still don't know if we should have captions for WV or not, and it is a minor issue that can be added later, right? So are we on the same page? Or is there a blocker?
19:39:07  <edsanders> we should base that decision on WP, not WV, but yes - I am OK with you proceeding

@Esanders please confirm.

I added that blocking task based on the IRC discussion, let me know if that is incorrect. Once that's resolved we can go ahead (per discussion with Ed and Yuri).

@greg, i don't think its a blocker. @Esanders +2ed the 275543, and we spoke about it in IRC:

<yurik> edsanders, sure, i can rename it, but i'm not sure how to make tests with non-default config
<yurik> it will be set to false in commonsettings
<edsanders> I think we do it in VE
<edsanders> I'll have a look
<yurik> edsanders, its in both php and parsertests
<edsanders> ok - if you can't work it out, mark it with a TODO and create a bug
<yurik> ok

It's not a blocker from my point of view.

Change 275622 had a related patch set uploaded (by MaxSem):
Deploy Kartographer on testwiki

Change 275624 had a related patch set uploaded (by MaxSem):
Add Kartographer

Change 275671 had a related patch set uploaded (by MaxSem):
Add Kartographer

Change 275622 merged by jenkins-bot:
Deploy Kartographer on testwiki

MaxSem claimed this task.