Bastien Guerry, 11/11/2016 15:45:
> I built this website in 2013 with the support of the Wikimedia
> Foundation (thanks!) and playing with all these beautiful data
> was great fun.
Is there any usage data on this website, to understand its users etc.?
Forwarding in case some of the mapping experts on other mailing lists would
like to look at this.
---------- Forwarded message ----------
From: Jeroen De Dauw <jeroendedauw(a)gmail.com>
Date: Thu, Nov 10, 2016 at 2:39 PM
Subject: [MediaWiki-l] Maps 4.0.0-RC1 released
To: MediaWiki announcements and site admin list <
I'm happy to announce the first release candidate for Maps 4.0. Maps is a
MediaWiki extension to work with and visualize geographical information.
Maps 4.0 is the first major release of the extension since January 2014,
and it brings a ton of "new" functionality. This release candidate is meant
to gather feedback and not suitable for usage in production. The 4.0
release itself will be made one week from now if no issues are found.
For an overview of what's new, see
Jeroen De Dauw | https://entropywins.wtf | https://keybase.io/jeroendedauw
Software craftsmanship advocate | Developer at Wikimedia Germany
MediaWiki-l mailing list
To unsubscribe, go to:
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
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.
(I sent the message below yesterday, but it never reached the list because
of outdated user settings. Sorry for the delay. Here it is again:)
Hi all wikimappers!
I have made a proposal in IdeaLab to create a Wikimaps user group.
Do you think that would be a good way for this community to go forward?
Wikimaps activities have been focusing on historical mapping, but the user
group would be made for all mapping related activities. The goal is that
people with many different ideas for using the geographic component in
their projects would come together, share their expertise and help each
The user group would give the community an affiliate status within the
Wikimedia movement, while still keeping the group organic and without
If you think you can endorse or join, please visit the page and leave your
ps Let's get the list administration in shape, so that there will be a
notification if the message does not go through.
One of the parked issues in defining what a map is in Wikidata is the bounding box. This is
of course an extremely helpful attribute. It would allow queries like 'how many maps of
the americas were made in Genova in the 16th century'
Personally, I can live with reusing the existing NorthernMost etc. Properties: https://
www.wikidata.org/wiki/Property:P1332 P1333 P1334 and P1335 respectively.
But of course, we need to achieve a consensus. When we do, we can update the document
with all mapping properties and start thinking of writing a bot that syncs the warper and
This doc: https://www.wikidata.org/wiki/Wikidata:WikiProject_Visual_arts/Item_structu…
tel: +31 687 348 845
Not sure if this is the best place to ask, but it seems the Warper server went
offline this weekend (because of a big georeferencing party in Norway and
subsequently running out of diskspace).
Is there any timeline of bringing it back up?
tel: +31 687 348 845