The introduction of Vector 2022 skin into en.wiki

[This started out as a response for [[Wikipedia:Requests for comment/Evaluation of Vector 2022]] but turned out to be expansive and too-broad-scope for there. It's intended for those familiar with the basics of en.wiki and WMF. ]

The introduction of Vector 2022 skin into en.wiki was a disaster by pretty much any metric.

Huge amounts of heat but very little light was generated on public-facing wikis (mainly en.wiki) and tools (mainly phabricator) and reading between the lines the process was very unpleasant for WMF staffers and the en.wiki admins. The end result was that a new skin containing modest improvements (mainly maintenance fixes) was adopted at the cost of huge ill-will.

Given that regular UI changes in web-based SaaS systems have been de rigueur for more than a decade, how did we get to the point where this change was so contentious?

1. It wasn’t about the technical content of the change. The changes were technically boring, competently implemented and worked reliably in the overwhelming proportion of situations for the overwhelming proportion of editors.
2. It wasn’t about the intention of the WMF staffers directly involved in the process. All the WMF staffers appeared to behave professionally and appropriately.
3. It wasn’t about the intention of the en.wiki admins. All the en.wiki admins appeared to behave appropriately.
4. It may have been partly about the huge pool of en.wiki editors who are deeply invested in the project, each of whom with their own point of view, set of priorities and fields of expertise. This, however, is a fundamental strength of the project (both Wikipedia as a whole and en.wiki specifically).

Systematic issues

en.wiki is a volunteer-edited information system running on systems provided by the professionally-staffed WMF. The volunteer side, while not explicitly a social-media forum, certainly shares aspects with social-media fora including, unfortunately, pile-ons. The en.wiki response to Vector 2022 was a classic pile-on: a community responded to a technical event in an emotionally charged manner with many people expressing very similar strongly-held views in such a way that emotive content completely obscured any informative content.

Indeed, the en.wiki policy WP:!VOTE policy encourages on-wiki pile-ons by explicitly prohibiting votes and vote-like processes unless each voter makes a substantive argument. Those substantive arguments can get very emotive.

Causes

1. The boundary between the volunteer-run and professionally-staffed portions of en.wiki is brittle, current processes and arrangements ensure that making technical changes to en.wiki is an all-or-nothing big-bang operation which is very costly to all concerned.
2. Technical changes to the en.wiki platform are seen by en.wiki editors as coming from “elsewhere” and being done to them, setting up an in-group and an out-group, with the WMF consistently being the out-group.
3. en.wiki continues to allow pile-ons.

Concrete ideas for WMF

Some of these ideas aim to 'soften' the boundary between the volunteer-run and professionally-staffed portions of en.wiki, increasing the proportion of editors the skills, knowledge and insight to better understand the underlying infrastructure and technologies. Other ideas aim to increase to availability of relevant academic studies in related areas.

1. Consider recasting wiki infrastructure updates to make WMF tech teams arbiters of technical quality rather than sources of disruption. This might be by funding (and providing infrastructure for) commercial or academic teams to build, debug, test and evaluate skins (and similar) which are then promoted to wikis by WMF based on quality.
2. Consider sponsoring academic research and a theme or track at a usability conference or journal on wikipedia usability (reading and editing; across language and culture textual practices; design for avoiding pile-ons; etc).
3. Consider sponsoring science communication in fields relevant to the wikipedia project: web UI; information systems; multilingual web usability; readability; etc.; etc. By promoting awareness of the academic consensuses in these fields there is hope that we steer discussion along evidence-based lines rather than “I don’t like X, don’t do it”
4. Consider sponsoring the creation and maintenance of wikibooks on each of the technologies wikipedia relies on, prioritising those usable by non-privileged wikimedians within the project (javascript, css, SQL, etc). Boosting access to such resources and aligning the versions and examples with the broader project would promote these skills across the project and enable motivated volunteers to engage with these technologies much more easily.
5. Consider using the volunteers who were actively involved in discussions related to one update as candidates for notification / testing of related updates. My participation in discussions related to Vector 2010 apparently didn’t qualify me for notification about Vector 2022; it should probably have. 12 years may seem like a long time to the WMF, but non-trivial numbers of active en.wiki users have been editing since before WMF was founded, embodying significant institutional knowledge. [Service awards can be used to find veteran editors.]
6. Consider processes to rollout changes to only portions of a wiki at once for testing purposes.
7. Consider moving to rolling updates of significant features as is common in SaaS. A new mainline skin appearing every January on all wikis, being made the default in May and marked as deprecated 48 months later. A new alternative skin appearing alongside it, with more innovative changes and more radical changes to the visual aesthetic might be deprecated earlier, with successful features appearing in a future mainline.
8. Consider publishing explicit design criteria for future wikimedia skins (and similar) built / commissioned by the WMF. 
9. Consider ‘introspection into the wikimedia system’ to be a design criteria for future wikimedia skins built / commissioned by the WMF. ‘Introspection into the wikimedia system’ in this context means enabling and encouraging users to reflect on the wikimedia install before them and might include: consistent visual differentiation between UI elements created by wikimedia core functionality, installed gadgets and /wiki/User:<user>/common.js; links from preference options to the respective tags in phabricator; etc.
10. Consider publishing formal technical evaluations of skins, to provide evidence and motivate change and progress. If editors can see that one skin fails on 25% of browsers used globally and one fails on 1% of browsers used globally, that's hard evidence the the second fulfills the WMF's mission better than the other. 

Concrete ideas for en.wiki

1. Consider better ways of handling contentious issues which don’t result in pile-ons and bordering-on-unclosable RFCs.
2. Consider a policy requiring complaints of specific technical issues in WMF infrastructure (broadly construed, but including skins) to be required to include a link to a relevant phabricator ticket (or a statement of why one can’t be created) if instructions for doing so are already on the page. Driving people who complain about WMF tech stuff to phabricator to create a bug report should be obvious, but it is apparently not.

Thoughts on the NDFNZ wikipedia panel

Last week I was on an NDFNZ wikipedia panel with Courtney Johnston, Sara Barham and Mike Dickison. Having reflected a little and watched the youtube at https://www.youtube.com/watch?v=3b8X2SQO1UA I've got some comments to make (or to repeat, as the case may be).

Many people, including apparently including Courtney, seemed to get the most enjoyment out of writing the ‘body text’ of articles. This is fine, because the body text (the core textual content of the article) is the core of what the encyclopaedia is about. If you can’t be bothered with wikiprojects, categories, infoboxes, common names and wikidata, you’re not alone and there’s no reason you need to delve into them to any extent. If you start an article with body text and references that’s fine; other people will to a greater or less extent do that work for you over time. If you’re starting a non-trivial number of similar articles, get yourself a prototype which does most of the stuff for you (I still use https://en.wikipedia.org/wiki/User:Stuartyeates/sandbox/academicbio which I wrote for doing New Zealand women academics). If you need a prototype like this, feel free to ask me.

If you have a list of things (people, public art works, exhibitions) in some machine readable format (Excel, CSV, etc) it’s pretty straightforward to turn them into a table like https://en.wikipedia.org/wiki/Wikipedia:WikiProject_New_Zealand/Requested_articles/Craft#Proposed_artists or https://en.wikipedia.org/wiki/Enjoy_Public_Art_Gallery Send me your data and what kind of direction you want to take it.

If you have a random thing that you think needs a Wikipedia article, add to https://en.wikipedia.org/wiki/Wikipedia:WikiProject_New_Zealand/Requested_articles  if you have a hundred things that you think need articles, start a subpage, a la https://en.wikipedia.org/wiki/Wikipedia:WikiProject_New_Zealand/Requested_articles/Craft and https://en.wikipedia.org/wiki/Wikipedia:WikiProject_New_Zealand/Requested_articles/New_Zealand_academic_biographies both completed projects of mine.

Sara mentioned that they were thinking of getting subject matter experts to contribute to relevant wikipedia articles. In theory this is a great idea and some famous subject matter experts contributed to Britannica, so this is well-established ground. However, there have been some recent wikipedia failures particularly in the sciences. People used to ground-breaking writing may have difficulty switching to a genre where no original ideas are permitted and everything needs to be balanced and referenced.

Preparing for the event, I created a list of things the awesome Dowse team could do as follow-ups to they craft artists work, but we never got to that in the session, so I've listed them here:

1. [[List of public art in Lower Hutt]] Since public art is out of copyright, someone could spend a couple of weeks taking photos of all the public art and creating a table with clickable thumbnail, name, artist, date, notes and GPS coordinates. Could probably steal some logic from somewhere to make the table convertible to a set of points inside a GPS for a tour.
2. Publish from their archives a complete list of every exhibition ever held at the Dowse since founding. Each exhibition is a shout-out to the artists involved and the list can be used to check for potentially missing wikipedia articles.
3. Digitise and release photos taken at exhibition openings, capturing the people, fashion and feeling of those era. The hard part of this, of course, is labelling the people.
4. Reach out to their broader community to use the Dowse blog to publish community-written obituaries and similar content (i.e. encourage the generation of quality secondary sources).
5. Engage with your local artists and politicians by taking pictures at Dowse events, uploading them to commons and adding them to the subjects’ wikipedia articles—have attending a Dowse exhibition opening being the easiest way for locals to get a new wikipedia image.

I've not listed the 'digitise the collections' option, since at the end of the day, the value of this (to wikipedia) declines over time (because there are more and more alternative sources) and the price of putting them online declines. I'd much rather people tried new innovative things when they had the agility and leadership that lets them do it, because that's how the community as a whole moves forward.

BIBFRAME

Adrian Pohl ‏wrote some excellent thoughts about the current state of BIBFRAME at http://www.uebertext.org/2014/07/name-authority-files-linked-data.html The following started as a direct response but, after limiting myself to where I felt I knew what I was talking about and felt I was being constructive, turned out to be much much narrower in scope.

My primary concern in relation to BIBFRAME is interlinking and in particular authority control. My concern is that a number of the players (BIBFRAME, ISNI, GND, ORCID, Wikipedia, etc) define key concepts differently and that without careful consideration and planning we will end up muddying our data with bad mappings. The key concepts in question are those for persons, names, identities, sex and gender (there may be others that I’m not aware of).

Let me give you an example.

In the 19th Century there was a mass creation of male pseudonyms to allow women to publish novels. A very few of these rose to such prominence that the authors outed themselves as women (think Currer Bell), but the overwhelming majority didn’t. In the late 20th and early 21st Centuries, entries for the books published were created in computerised catalogue systems and some entries found their way into the GND. My understanding is that the GND assigned gender to entries based entirely on the name of the pseudonym (I’ll admit I don’t have a good source for that statement, it may be largely parable). When a new public-edited encyclopedia based on reliable sources called Wikipedia arose, the GND was very successfully cross-linked with Wikipedia, with hundreds of thousands of articles were linked to the catalogues of their works. Information that was in the GND was sucked into a portion of Wikipedia called Wikidata. A problem now arose: there were no reliable sources for the sex information in GND that had been sucked Wikidata by GND, the main part of Wikipedia (which requires strict sources) blocked itself from showing Wikidata sex information. A secondary problem was that the GND sex data was in ISO 5218 format (male/female/unknown/not applicable) whereas Wikipedia talks not about sex but gender and is more than happy for that to include fa'afafine and similar concepts. Fortunately, Wikidata keeps track of where assertions come from, so the sex info can, in theory, be removed; but while people in Wikipedia care passionately about this, no one on the Wikidata side of the fence seems to understand what the problem is. Stalemate.

There were two separate issues here: a mismatch between the Person in Wikipedia and the Pseudonym (I think) in GND; and a mismatch between a cataloguer-assigned ISO 5218 value and a free-form self-identified value. 

The deeper the interactions between our respective authority control systems become, the more these issues are going to come up, but we need them to come up at the planning and strategy stages of our work, rather than halfway through (or worse, once we think we’ve finished).

My proposed solution to this is examples: pick a small number of ‘hard cases’ and map them between as many pairs of these systems as possible.

The hard cases should include at least: Charlotte Brontë (or similar); a contemporary author who has transitioned between genders and published broadly similar work under both identities; a contemporary author who publishes in different genre using different identities; ...

The cases should be accompanied by instructions for dealing with existing mistakes found (and errors will be found, see https://en.wikipedia.org/wiki/Wikipedia:VIAF/errors for some of the errors recently found during he Wikipedia/VIAF matching).

If such an effort gets off the ground, I'll put my hand up to do the Wikipedia component (as distinct from the Wikidata component).

Prep notes for NDF2011 demonstration

I didn't really have a presentation for my demonstration at the NDF, but the event team have asked for presentations, so here are the notes for my practice demonstration that I did within the library. The notes served as an advert to attract punters to the demo; as a conversation starter in the actual demo and as a set of bookmarks of the URLs I wanted to open.

---

Depending on what people are interested in, I'll be doing three things

*) Demonstrating basic editing, perhaps by creating a page from the requested articles at http://en.wikipedia.org/wiki/Wikipedia:WikiProject_New_Zealand/Requested_articles

*) Discussing some of the quality control processes I've been involved with (http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion and http://en.wikipedia.org/wiki/New_pages_patrol)

*) Discussing how wikipedia handles authority control issues using redirects (https://secure.wikimedia.org/wikipedia/en/wiki/Wikipedia:Redirect ) and disambiguation (https://secure.wikimedia.org/wikipedia/en/wiki/Wikipedia:Disambiguation )

I'm also open to suggestions of other things to talk about.