Wikipedia:Wikipedia Signpost/2013-10-02/Arbitration report


 * Editor's note: To go beyond the mere facts of cases, the "Arbitration report" invited several editors who participated in the recent Infoboxes case to comment on infoboxes: what they are, where new users can go to find out about them, specifications and protocols, best practices, and how the upcoming community discussion recommended by the Committee in the case decision should be framed. 

The war is over, [//en.wikipedia.org/w/index.php?title=User:Smeat75&diff=prev&oldid=574003001 declared] one music editor preparing to return to editing classical music articles in the wake of ArbCom's Infobox decision. The editor had spent [//en.wikipedia.org/w/index.php?title=Wikipedia_talk:Arbitration/Requests/Case/Infoboxes/Proposed_decision&diff=568928992&oldid=568926257 two years] away from music topics, "I could see I would get involved in this long-running controversy on infoboxes and it would be an unproductive waste of time." Another music editor, who had stopped editing in June, and who asked not to be identified, told the Signpost that even though the current guidelines say infoboxes are neither required nor prohibited, and the committee cannot decide a content issue, the arbitrators did well with the case, by calling a halt to the disruption, and calling for a community discussion for clarification of the guidelines.

What was settled
"The decision to include an infobox in an article is a content decision," wrote arbitrator Worm That Turned. Worm further clarified the reasoning behind this, in a way that should put to rest any lingering questions about the role of WP:OWN in the debate:

Worm delineated the difference between "content creation" edits and "maintenance" edits. Maintenance tasks should not change the meaning of the article for the casual reader, he explained. These tasks include categorisation, stub sorting, adding wikilinks, formatting and stylistic changes such as number and position of headers or placement of images, and simple copy-editing such as grammar and spelling fixes.

Content creation would include addition and removal of text, images, tables, references and so on—and infoboxes—and should be done by an editor who has some knowledge of the subject.

Starter templates are fine, and general recommendations by a WikiProject are fine, says Worm, but editors should not go through a group of articles, adding infoboxes to each systematically.

A hasty RFC
Before the case had even been closed, a new RFC was started on the talk page of WikiProject Quality Article Improvement  by  Chedzilla, an alternate account of  Ched, who had initiated the original Infoboxes case request. The RFC drew immediate protests from music editors. The RFC should be in a neutral area, not on the pages of a project that was home to the two topic-banned editors, they said. The language of the proposal should be neutral. And the music editors were already exhausted by years of acrimony. Time was needed.

Arbitrator Carcharoth agreed: "My suggestion, for those who want to sort through their thoughts on this while they are still fresh, would be for people to make notes or mini-essays offline or in their userspace, and to leave articles and talk page discussions well alone for a bit. Don't rush into post-case discussions, but let things calm down, and find other things to do in the meantime. It's not like the issues are going to go away."

As a followup to this, the Arbitration report has compiled a partial listing of essays and previous discussion at the end of this report.

Framing the community discussion
"I don't think the discussions should be hurried", agreed Quiddity. The RFC should run for many months to avoid fatigue, he told the Signpost, and needs a large amount of preliminary research, adding that Sphilbrick and Kleinzach have some of the best ideas. "I believe that all of the objective problems with infoboxes can be fixed", he said, "and all of the subjective problems can be minimized." He added, "I do think WikiData needs to be taken into account; there will soon be more facts and stats than could reasonably fit in an infobox."

"Structuring the discussion is important", music editor Kleinzach told the Signpost. Kleinzach calls for a drafting committee of three or five members to structure the questions. Interested parties would submit topics to the committee and all meaningful questions would be included.

In the past, community discussions have been muddled, and issues have been conflated. The problems need to be separated, said Kleinzach, and detoxified, one by one. The discussion should distinguish between publishing issues and technical issues.

"Any future discussion needs to be much broader than that defined by ArbCom", Kleinzach told the Signpost. "Looking just at how infoboxes are ‘used‘ (i.e. inclusion/exclusion disputes on article pages), but not at how the templates are created, means concentrating on effects rather than causes. Fundamental issues about template design and MOS guidance should be faced."

Objections to infoboxes
Infoboxes have been controversial, explained Kleinzach, because they have often been edited behind the scenes, without content contributing editors being involved. The idea that there are two ‘stances', "pro-box" and "anti-box", is not really correct. "There is a spectrum. Objections to infoboxes have been localized, and focused on particular topics and particular infoboxes.

One particularly controversial infobox is the 'bio-box' or biographical infobox. Another infobox that received a particularly negative reaction from serious music editors was Musical artist infobox  with anachronistic, pop music derived fields such as 'birth name', 'genres', 'occupations', 'labels', 'associated acts', and 'past members' —misapplied to classical music articles.

An example of a positive response to an infobox was the Template:Infobox classical composer, which according to Quiddity was the result of a 2010 discussion which clarified problem areas in the documentation, and has been uncontentiously used in a few articles.

"Rather than trying to force them on the unwilling," recommends Brian Boulton, "improve them by returning to their original principles ('a few key facts'). I have recently added an experimental infobox to an opera article I have written." The sample infobox proposal was intentionally introduced in a relatively low-profile opera article, to minimize controversy.

Monsterboxes
While there are a few uncompromising ‘pro-box' editors who believe there should be a box on every article, no-one has taken up the opposite position: that there should be no infoboxes at all, says Kleinzach, a music editor who has added hundreds of infoboxes to articles. "Unfortunately many current boxes are not fit for purpose because of poor design."

In particular, some 'monsterboxes' have been created with far too many fields, unfamiliar abbreviations etc. that are actually longer, bigger, more prominent and more difficult to read than the articles they are supposed to summarise."

German Wikipedia in particular is known for its minimalist approach to infoboxes. They are particularly unpopular on biographies. Even the article for Angela Merkel has no infobox, only a photo and signature (see above). In contrast, the infobox for Merkel's English Wikipedia page (right) would extend well past the fold in most browsers.

Loss of nuance
One of the major criticisms of infoboxes is the loss of nuance, when complex information about a subject is forced into an abbreviated infobox format.

"I feel strongly that it is poor form to use an infobox entry, which almost by definition is extremely short, to summarize situations which might be too complicated for a one word or short phrase, says SPhilbrick. "That is exactly what well-written prose is for—to explain nuance, in as many words as it takes to explain the issue."

The articles best suited to infoboxes, says Smerus, in an essay provided to the Signpost, may be in scientific and geographical topics. "The arguments over infoboxes seem to have occurred in articles relating to history, biography and music." Infoboxes may be particularly unsuited to liberal arts fields when they repeat information already available in the lead section of the article, are misleading or oversimplify the topic for the reader, or include a vast amount of irrelevant or inappropriate information from the article.

Smart boxes?
The metadata question may well be obsolete. If you Google [//www.google.co.uk/search?tbm=bks&hl=en&q=%22La+traviata%22#hl=en&q=%22La+traviata%22 La traviata ], [//www.google.co.uk/search?tbm=bks&hl=en&q=%22La+traviata%22#hl=en&q=%22Giuseppe+Verdi%22 Giuseppe Verdi], and Johann Sebastian Bach, you will find that it now creates its own small infobox on the subject, even though none of the corresponding Wikipedia articles have infoboxes. [screenshot] Quipped one user, "The Google box is better than the WP ones!" Perhaps Google has spent time and money identifying what their customers want.

Appendix A: A crash course in infoboxes
Anyone who attempts to read any of the infobox discussions will quickly come up against some specialized terms.

What exactly is an infobox? A navbox? A template? A header or a footer? And where can new users turn to for assistance? Is there a place to "shop" for infoboxes, where you can see what is available and how it will look in a new article? The answer to the last question is no; apparently new users who are creating articles outside of a WikiProject have little to go on. According to Kleinzach and Smerus, an infobox offers a quick summary of the article, sometimes with an illustration. It is normally in the right hand corner position. A navbox (navigation box) offers links to related articles, and is often found at the bottom of the page. All infoboxes are templates, but not all templates are infoboxes.

Quiddity provides a crash course in all things infobox and navbox, along with examples and links to the help files:

Note: The natural place to look is Infoboxes, but that is a redirect to WikiProject Infoboxes which is of more interest to someone interested in designing a new infobox. There are also various options at Category:Infobox templates.

Infoboxes

 * Proposed Decision September 2013—the 66,392-word talk page, with proposals for framing the infobox discussion

Essays

 * THRC: An essay on infobox issues, particularly the "upper right hand corner", provided to the Signpost by Smerus.
 * Brianboulton, "Infoboxes: time for a fresh look?" Signpost, July 2013
 * Disinfoboxes: "The disinfobox offers a competitive counter-article, stripped of nuance."
 * Riggr Mortis's Wikipedia as database  "As long as Wikipedia drifts from its origins as a tool for human learning to a second-rate quasi-database—apparently to the benefit of ADD-inducing tech companies—I will no longer participate as a volunteer. Neither should you."
 * Quiddity: framing the discussion (Notes from Proposed Decision talk)
 * Design solution proposal from Vibhabamba at the WMF.

RFCs

 * April 2013 – discussion with multiple people in Ched's user space – machine readable data, advantages and disadvantages of infoboxes
 * 2010 RFC on microformats
 * Brianboulton's a sample infobox, a proposal introduced in a relatively low-profile opera article, L'Arianna, to minimize controversy. Discussion is ongoing.
 * Classical music infobox-related discussions 2007–2010

Template deletion discussions
All infoboxes are templates, but not all templates are infoboxes. People create new ones unnecessarily all the time, hence many editors bring them to TFD to get them merged.
 * Template Infobox journal, that generated a lot of discussion.
 * Infobox soap character 2
 * Infobox TaiLamTunnelENG
 * And most of the current contents of Templates for discussion