Yuri,
Last half a year I am experimenting with rewriting some of the Commons
templates to take advantage of Wikidata, which recently allows arbitrary access
from Commons. Some of Commons templates and modules are used on 40M pages
(compare to 5M articles on English Wikipedia). Changes to such templates will
trigger refresh of all those pages so they should be kept to the minimum; on
the other hand large changes to templates or modules used on many pages are
more likely to break something and will be quickly reverted. As a result me and
others use approach of occasional medium size changes, which gradually change
the software. That also allows us to observe the results, and look for
potential issues, which we try to correct quickly, before millions of pages are
refreshed over a period of weeks.
One of the templates updated that way is Commons {{Location}} and {{Object
location}} templates, which are written in Lua [7], and which now have link to
Yuri’s Kartographer extension [1]. Enabling that and being able to work with
Kartographer maps immediately allow discovery of various issues [2] and
possible extensions [3] which would improve the software. Similarly, enabling
comparison of Commons and Wikidata coordinates allow us to find mismatches,
see [[Category:Pages with local coordinates and mismatching wikidata
coordinates]] [4] and working on resolving them quickly proved that it is
really hard to pinpoint true location of some object. For example Church of the
Exaltation of the Holy Cross in Yekaterinburg [4] where Commons location is 2
km away from Wikidata location. One of them is wrong but which one? Easy way to
find out would be to see map with geolocation of images in the church category.
Apparently {{Geogroup}} template does that, so now I hope to merge it with
{{Object location}} so one change naturally guides the need for the future
changes. I also proposed to extend Kartographer to be able to do the same so I
do not have to be switching between 2 OSM maps [3], but that might take longer.
Need for those changes would be really hard to predict if one was waiting for
the perfection before the final software release.
Hope that answers some of your questions. By the way, to other map enthusiasts:
I would appreciate help with fixing pages with mismatched coordinates between
Wikidata and Commons [4].
Jarek T.
User:Jarekt
[1] https://www.mediawiki.org/wiki/Extension:Kartographer
[2] https://phabricator.wikimedia.org/T149427
[3] https://phabricator.wikimedia.org/T149280
[4]
https://commons.wikimedia.org/wiki/Category:Pages_with_local_coordinates_and_mismatching_wikidata_coordinates
[4]
https://commons.wikimedia.org/wiki/Category:Church_of_the_Exaltation_of_the_Holy_Cross_in_Yekaterinburg
[5]
https://commons.wikimedia.org/wiki/Category:Church_of_the_Exaltation_of_the_Holy_Cross_in_Yekaterinburg#/maplink/1
[6] https://commons.wikimedia.org/wiki/Template:Geogroup
[7] https://commons.wikimedia.org/wiki/Module:Coordinates
From: Maps-l [mailto:[email protected]] On Behalf Of Yuri
Astrakhan
Sent: Saturday, November 05, 2016 2:26 PM
To: Discovery; Maps
Subject: [Maps-l] Maps, community, and enabling disruptive tech
TLDR: How fast should new content (maps) features be rolled out, and how ready
should they be? Constant but smaller improvements seems better.
As we gradually roll out maps to wider and wider audience, I would like to get
some feedback on how we approach new feature roll-outs.
Frankly, WMF has botched a number of releases in the past. In a way, this is
great, because it means both WMF and volunteers are still eager to improve
Wikipedia, we are still trying to make things better. On the other hand, it is
never a good thing to irritate the most important group - our community. So
there is always a compromise: when and what to roll out, how to make it least
disruptive vs how to improve the usability and the content quality.
For wikis, there are two types of improvements: user interface and content.
User interface features change how one views and edits site's content, so any
change immediately affects everyone. We try to mitigate it with "Beta features"
-- logged in users may enable new functionality before it is enabled by default
for everyone, but the vast majority of the readers are not logged in, so when
enabled, it is still a serious and instant change. Maps are not really a part
of interface because they only appear as part of the page content, which is
fully controlled by the community.
Content features allow editors to add new type of content - maps, graphs, sheet
music, text formatting or new types of templates. There is no way to hide a new
content feature behind a "beta flag" because everyone sees the same content,
but content features are not disruptive because they depend on the editors to
add them to the pages. Community has full control, and if it does not like a
feature, or if it feels the feature is not ready yet, it will not be used. The
only time content changes are disruptive is when the support for a widely used
feature changes or gets disabled. This is clearly not the case with the maps
roll out on Wikipedia.
The WOW effect, and marketing in general, have both positive and negative
effect on a feature roll out. If a feature is quietly enabled, only the more
engaged community members will experiment with it and discuss the feature's
best usage, give feedback on how to improve it, and eventually enable it at its
own pace. A massive marketing of a feature would attract a lot of attention and
expedite adaption, but may also create some amount of negativity if the
community feels the feature is not yet ready.
I also feel it is very dangerous to delay releasing new features until they are
perfect. We (developers/PMs/...) may think we know what feature is needed, but
most likely we are wrong. If we delay, we may spend a lot of resources on
polishing something that is not needed. Instead, by releasing early,
community's feedback would put us back on the right track. Yes, it may not be
as good, but at least we will quickly change direction, producing a truly
needed feature that can be polished later. Of course this is much easier to do
with the content features rather than user interface changes (hence the UI's
"feature flag").
In light of this, I feel it is better to continuously roll-out small
content-related features without much publicity (e.g. Village pump is OK, blog
might be less so), and continuously improve based on community feedback. Once
the feature has been out for some time and there is a general consensus that
the feature is good, we can start the marketing push. This approach creates
less stress on the community lesions, developers, and servers. Feedback is
received in smaller portions and can be properly acted on.
_______________________________________________
Maps-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/maps-l
