Community Wishlist Survey 2019/Maps/Fix bugs relating to map data stored at Commons

From Meta, a Wikimedia project coordination wiki

Fix bugs relating to map data stored at Commons

  • Problem: There are several bugs that mar the experience of creating maps at Commons.
  • Who would benefit: Editors storing maps on Commons. There are several possibilities that would open up if these bugs were fixed, allowing more data to be shared across projects.
  • Proposed solution: Fix the bugs listed below.
  • More comments:
  • Phabricator tickets:
    • Maps fast preview is broken on 2nd attempt (T151524) - needing to open a new tab and copy/paste GeoJSON code every second time you wish to check your work is no fun!
    • Maps that contain Wikidata ids and are stored on Commons fail to display when called via <maplink> or <mapframe> (T155927)
    • When called via <maplink> or <mapframe>, markers stored in a Commons .map page will display a broken image icon when the marker uses the "marker-symbol": "-letter" or "marker-symbol": "-number" properties (T207202)
    The following issues also affect tabular data stored at Commons:
    • Support appropriate documentation of CC BY SA data on Commons (T200968)
    • Add a data-page-only wiki markup header to datasets (T155290)
    • Track Commons Dataset usage across wikis (what links here) (T153966)
    • Support Data namespace redirects (T153598)
    The lack of support for redirects and what links here means that moving (or splitting) pages in the data namespace is liable to break stuff, with no way to know whether this has occurred – a really unacceptable situation for a repository that is supposed to be available across projects and languages.
  • Proposer: Gareth (talk) 06:18, 10 November 2018 (UTC)[reply]

Discussion

  • Thanks for contributing to the survey Gareth. The CommTech team has judged this ticket out of scope due to its being a list of loosely related issues. You can save this proposal by reducing your wish to one or two tickets that are your highest priority. I'm sorry to give you such short notice, but Wishlist voting begins November 16 at 18:00 UTC, so please don't delay or this proposal will be withdrawn. Thanks —JMatazzoni (WMF) (talk) 17:58, 15 November 2018 (UTC)[reply]
This proposal is entirely consistent with Community Wishlist Survey 2019/Search/Linksearch overhaul, Community Wishlist Survey 2019/Admins and patrollers/Page Curation and New Pages Feed improvements and Community Wishlist Survey 2019/Admins and patrollers/Feature parity for tools dealing with deleted revisions as proposals that request fixes for various problems that share a common theme or technology. This proposal was already spun off from the united maps proposal; meanwhile, the "Page Curation and New Pages Feed improvements" proposal (which is arguably the one most similar to this proposal) includes eighteen tickets. And this one is supposed to be cut to one or two tickets. (And how is a proposal with two "loosely related" tickets any less "out of scope" than one with seven tickets - less than half the number in the page curation proposal?) Some problems resist being packaged into "neat" proposals. So I'm sorry if the this proposal doesn't meet CT's aesthetic sensibilities or inconsistently applied sense of scope, but I won't be modifing it. Gareth (talk) 10:26, 16 November 2018 (UTC)[reply]
  • This can go forward to voting Gareth. Just know that if it wins, we can promise only to investigate these tickets and do as much here as is feasible, with community advice about which are the most valuable. I.e., there is not implied agreement to do this whole list. The value of reducing these or at least prioritizing them now is that people would have a better idea of what they might actually get if they vote for this. (The same is true for the other proposals you mention, which are also problematic. Some are the results of previous negotiations to reduce scope, however successful.) Good luck. —JMatazzoni (WMF) (talk) 17:03, 16 November 2018 (UTC)[reply]

Voting