User:Ziko/Viennese diary

From 19th to 21st of May, 2017, the international Wikimedia Hackathon took place in the Austrian capital Vienna. The Hackathon is an event that gathers mostly software programmers in order to exchange ideas and work together on little projects that improve the software that makes Wikipedia (and other wikis) possible. This year, the organizing host was the Austrian Wikimedia chapter, Wikimedia Österreich (WMAT).

Myself is no programmer, no 'coder'. I use software a lot and am interested in improvements, but for programming I just make too many typos, as I found out at school. Texts are much more forgiving; even missing words don't ruin the whole sentence or text thanks to the principle of redundancy. So I became a historian and, in the Wikimedia movement, mainly write Wikipedia articles and explain Wikipedia-related subjects to others.

What follows is a report of the Hackathon from the point of view of someone who sees himself as an 'outsider' with one foot 'inside'... or at least a toe. I hope you'll enjoy, or find something useful in, my Viennese diary.

Thursday

Thursday started with a city tour to the central cemetery with its many celebrity graves, and a tour to the historic centre, a Unesco world heritage. While some participants came together in a 'mentor meeting', others watched presentations at the 'Vienna Open Data MeetUp' close to city hall. In the 'Metalab' venue Wikipedians and non-Wikipedians saw first glimpses of the topics of the Hackathon.

The evening ended with drink on the house and dinner for a smaller group in a nearby restaurant. Someone of us looked at the menu and informed the reluctant rest of the group: The place looks expensive, but it is actually cheap. As if the waiters understand no English...

Friday

How to show in which wikis and topics you are interested?

Friday morning, I arrived that the Jufa Wien, a 'youth and family hotel' some metro stations from the inner city. The programme started at ten with the opening in the largest hall. Claudia from WMAT and Rachel from the WMF elucidated the programme and the organizers' approach how to reach out to participants who have never been to a Hackathon. In a 'open mic project' many participants shortly presented what they were going to do in the weekend. Took some time, indeed.

Introductory sessions

At the introduction of the Mentoring Program

In one of the five tracks then the mentoring programme saw its official introduction. Sonja, hired by WMAT for the Hackathon, explained the concept. Experts wrote their expertise about several topics on a large piece of paper, then stood next to it. New people could approach the experts and ask them about the topics or who could help them with a related one. Actually a nice concept, and I talked to some experts about specific and less specific subjects.

The next session in this track was initiated by myself; a discussion group about the humanities and social sciences with regard to wikis. The participants gave an account of what they were doing in their fields, and I shared some thoughts on the three different dimensions with regard to wikis (technical, cultural, social).

The areas of 'Wikimedia tech'

Srishti Sethi from the WMF Technical Collaboration team then gave an overview of 'Wikimedia Tech (code areas, infrastructure tools, communication venues)'. It was an excellent introduction that should have been at the beginning of the day. Srishti went through her list of areas with some comments and explanations what kind of software skills you need in order to join the efforts.

For example, the MediaWiki Core is the basic wiki functionality. You need PHP, MySQL, Maria DB, jQuery, Javascript, CSS/LESS. MediaWiki extensions expand the functionalities, such as the Visual Editor extension, the Content Translation and now, in an experimental phase, a new newsletter extension.

Templates are standard wiki pages designed to be embedded inside other pages. Relevant skills: HTML, Javascript, CSS, Lua. Somebody asks whether there is an editor for templates. Quiddity answered that someone works on an editor for wikitext in general which highlights the relevant parts.

There are gadgets and user scripts, mobile apps and desktop apps, analytics and quality assurance etc. Bots: That is something a lot of people here do, small programs for automatic edits. But only a few are maintained well. Site operations: this is about the infrastructure of the servers, like the allocation of resources and MediaWiki on different wiki sites. The Wikimedia movement has by now more than 800 individual wikis.

Fantastic MediaWikis

Richard Heigl from Hallo Welt! GmbH. He was first to concede that his company had a vested interest in the development of MediaWiki, in the direction of providing more features useful (also) for small organizations (profit or non profit).

I finally changed to the track of „Fantastic MediaWikis and how to manage them“, organized by the MediaWiki Stakeholders' Group and partially powered by the people from Hallo Welt company. Richard Heigl compared MediaWikis, such as Hallo Welt's own BlueSpice, to the big competitor Confluence. He pointed out that Confluence is for internal use within an organization, but that also MediaWiki is used in only 25 percent of the cases in public. Confluence has always been a proprietary software for corporate wikis and has links to Google. It is about usability, rights management, connections to Microsoft Word, and to provide a portal solution for intranets. Their mission is team collaboration (collaboration made possible in small, closed teams).

The BlueSpice MediaWiki from Hallo Welt on the contrary is about bringing the experiences from the Open Source Software world into companies and other organizations. Their mission, explains Richard, is to collect centrally, contextualize, share knowledge, know-how. In MediaWiki wikis you want to find everything immediately, which is not the case in Confluence. MediaWiki is great in creating large, open spaces, and in structuring content.

But Richard would like the Wikimedia and MediaWiki movement to learn from Confluence. Sometimes it is simply necessary to have closed spaces, within an organization. Think about: the majority of MediaWiki users want to use a wiki also for non public use. What do even Wikimedians do when they work on a project? They turn to Google Docs or Etherpad, for the real time collaboration. A lot of small non profit organizations only use Google Docs.

Markus Glaser from the same company explained how to install the Visual Editor on self hosted wikis. Although this should be basic knowledge according to Markus, only two hands were lifted when he asked how many people in the room already did install the Visual Editor. He showed that the client and the web server are linked to the MediaWiki, and the MediaWiki to Parsoid on the MediaWiki server. There is no direct link with the client which makes it tricky.

Our Fantasticks in Vienna: panelists discussing what the WMF does wrong, mainly.

The Fantastic MediaWiki track ended with a panel 'Promoting MediaWiki', or the future of our software. Mark Hershberger from the MediaWiki Stakeholder's Group confronted the panelists with three questions: where are we now, where we want to be, how do we get there.

Brion Vibber had good news: MediaWiki works. The bad news is that it is not as well supported as it might. It has been programmed for Wikipedia, something quite specific. It is nice that people think that Wikipedia is a working project, and they want something 'like wikipedia'. But if you do different stuff, MediaWiki does not work so well. The active support for third party users is quite limited. If they use customizable extensions, or their own skin... the update later becomes difficult, the things no longer work. The backwards compatibility should be better.

Bryan Davis: MediaWiki is an Open Source Software project with a relatively healthy ecosystem, compared to others. 20-60% of the code is written by volunteers.

Sabine Melnicki from WikiAhoi worked together with Wikimedia Österreich. MediaWiki presents itself in a way that it is difficult to see where we are now, especially for those who are not insiders. We need to figure out better what MediaWiki is actually used for now. It was created for Wikipedia, and that's what defined the features.

Richard Heigl: We have seen many good developments. The Visual Editor is a great step. But we loose ground every day, Confluence wins and wins. It is the largest MediaWiki company right now. It took so much time and investment to create MediaWiki. One should indeed focus on usage. Even in the Wikimedia context there are a lot of usages.

The panelists expressed quite some criticism about the Wikimedia Foundation. It seems that to the WMF it is not relevant to promote the use of wikis. They miss the discussions and connections, they don't attend the conferences where people talk about life long learning and digitalization. There should be a change in the government structure in the WMF, with a shared government model. It is not enough to add features, the process must be more public that it is now. The WMF board must be convinced that the distribution and development are important.

But use cases from outside the Wikimedia movement have no priority for the WMF. But who has the resources if not the WMF? The WMF must understand that MediaWiki is a part of their mission. Such learnings usually don't come from the inside but the outside.

Table soccer skills at the Hackathon were excellent. Yeah, most of us have work at an Internet start-up in their curriculum vitae...

How about "change aversion“, someone from the audience asked. Isn't it just the WMF but above all the Wikipedia community that kills innovation? The panelists agreed there is a 'community problem' in a way you don't know it in the enterprise world. Many people love it when they are given nice tools, but not so on Wikipedia.

Brion Vibber had the last word: Don't be afraid to say that we need something from the WMF. As long as it is specific and does not use too many resources. So that the communication lines stay open. A healthy community of supporters must have a chance to put their hook into the system. How to support that? People could blog about their use cases. Recently we saw something like that about the NASA wiki. Great if we got more about that.

Pizza night! this sounds like a casual Friday evening in a start-up with a significant decline in table manners, but actually the pizza was part of the excellent food served (or self served) in the cantina of the Jufa. The evening saw also a rather noisy Karaoke session, with contributors showing a vast range of vocal talent.

Saturday

Documentation sprint

'Documentation sprint', photo from Friday when the elements of the help section of Wikidata were mapped

On Saturday the hackathon sessions of Friday continued. Though having missed the first day, I still joined the 'Wikidata documentation sprint'. Its goal was to 'improve the beginners documentation' of our third most active wiki. Part of the 'sprint' was a presentation of Jan Dittrich from WMDE about screen shots and their use in presentations and online documentation. How to make a screen shot in Linux, Windows or on the Mac? How to embed it via Wikimedia Commons, how to write something on the screen shot? Best practice is to put numbers on the picture so that you can refer to them in the caption, in any language. As Andrew Lih supposed: Wikidata people seem to avoid the use of screen shots because of the multilingual approach of Wikidata. That's why they prefer to explain something via text.

Jan also presented personae he and his team came up with. What kind of people use Wikidata? For example, 'Niels', an active Wikidata editor who 'gets a kick out of seeing his data and queries being used'. 'Eloise', on the other hand, is active on the French Wikipedia and only occasionally on Wikidata, while 'Alex' is a 'data user in a small startup' and 'Mahdi' a Wikipedian in a small Wikipedia language version. Sandra Fouconnier announced that she considered writing a persona representing a GLAM collaborator.

Andrew Lih and Sandra Fouconnier worked on the main page of Wikidata which is, with all due respect, quite a mess. They found out which links are actually clicked on and what should be on the main page at all.

Jakob Voss is one of the first persons to write a master thesis about Wikipedia; the information scientist and I radically changed the Wikidata:Glossary. We thought that the current structure and the translation system prevented any improvement. We made it possible, via a table, to have the entries in alphabetical order as you'd expect it for a glossary. Also, we wrote guidelines about the glossary and the entries and already rewrote some entries. An entry should always be three to seven sentences long and have this internal structure: a definition, placement in the larger context, example and finally the link to the most relevant help page.

With Jens from WMDE I had a longer conversation about the whole 'beginners documentation' thing. In my belief, the term is poorly chosen, or we need something different. A 'documentation' is a manual for the expert to analyze and maintain Wikidata and its software. It is used to look something up, by programmers with a lot of previous knowledge. But someone who is no programmer and only wants to apply the software needs a more educational approach.

Most likely, we need three introductions for three different personae, with a larger 'deep space documentation' for Wikidata specialists. And such an introduction does not have to be voluminous, on the contrary, 'just' suitable exactly for that target group, for example people from cultural institutions.

GLAMs and Wikidata

Sandra Fouconnier in Vienna

Sandra also arranged an ad hoc 'group discussion brainstorm about GLAMs and their data needs'. She gave 3-4 examples and encouraged an open discussion, without recording. The participants reported about their experiences with museums and other institutions. Typically, an institution is funded to build up a database, wiki or other platform of their own, with their logo on it. The institution is not interested in cooperation and certainly not in Wikidata. But when funding ends, and the platform is dead, the attitude changes.

GLAMs are afraid that 'their' data can be changed on Wikidata, without them being informed about. They want to protect their data and be seen as an important source. And they want statistics: what is the use of the data, the re-use, how many Wikipedia articles incorporate them etc. Also, they find it strange that they have to upload files to Wikimedia Commons, as they have their own data servers. Possibly a 'snap shot' of the data, when they first enter Wikidata, could be a mean to give the institution a better feeling.

The Atrium of the Jufa became our meet and greet space.

The legal department of large government institutions say that a free license is not possible. First, because the data are 'official' and must not be changed, second, because the GLAMs have invested money in data, so they want no free license. One participant said: I have worked on this for 10 years, it is hopeless. Another: It was the same in my country, but then suddenly one institution stimulated the free license, and then the situation changed. Maybe it could be a useful strategy to wait until the end of the funding, and then approach the institution (laughter).

The participants knew of many smaller and larger problems: most GLAM employees stop working at 5 pm, that makes it difficult for Wikidata volunteers to cooperate. You must know a specific person in the institution, not send a mail to a general address. Above all, we need a lot of show cases so that GLAMs understand what the benefits can be. On the other hand, Sandra wondered what the Wikidatans think of all those data coming from GLAMs...

In the late afternoon, a little too close to dinner, the organization made us happy with the 'sweet taste of Austria': the country is famous for its cakes.

Sunday

'Showcase and closing' on Sunday

The Sunday programme saw new sessions, mainly for new developers of MediaWiki, but most of the participants continued with their projects from the earlier day(s). A city tour guided by Regiomontanus and Plani provided some 25 with a glimpse of the Altstadt with its Stephansdom and government buildings.

In the afternoon dozens of Wikimedians presented in a 'Showcase and closing' session their projects and products of the weekend. As there is a list and a video of the show cases (thanks to Andrew Lih), I am not going to repeat them here. For example, I was very impressed by Rowan's efforts to enable real time editing in the Visual Editor. But those improvements usually are in an early phase, and it may take considerable time until we see them at least among the beta features of our Wikimedia wiki accounts.

I left Vienna with gratitude for the chance to meet all these people with their different skills and approaches. Many of them spent considerable time to patiently explain to me this and that about software and the people who make and use it. Software is coded experience, someone said at the Hackathon. I hope that my report contributes to spread this experience.

Travelling back to the Netherlands, in the Intercity Express, some strange brain waves transformed an old Cole Porter song into... well, something one could use in a future Karaoke session:

The folks of modern society

Go for software – propriet'ry.

So to win their hearts your site must provide

Real time edits and one good guide

But the software of them all

That they simply find too tricky

Is the software people call

The sum of MediaWiki.

Brush up your software,

Start debugging now.

Brush up your software

And the users you will wow.

Just provide it with charming extensions

And the users will love your inventions.

If they want to look things up on mobile,

Without app you'll appear more than fossil.

If for Internet failure there's no fix

Just remind them we still have this Kiwix

Brush up your software

And they'll all kowtow.