User:Crath

Not a Wikideletionist!

My involvement with Wikipedia is one of an active contributor. By this I don't mean that I patrol pages and contributions looking for content I can flag for deletion (or simply delete) because of some imagined contravention of Wikipedia (WP) rules and conventions. Since my first contribution in 2007, it has become clear to me that many of the most active WP editors do not actually contribute to WP; rather, they have somehow come to believe that the deletion of content somehow adds to WP's value. Yes, there are many vandals who troll WP's pages and spray graffiti that needs to be scrubbed—and the cleaning up of this wanton destruction is of value to WP—however, very often well meaning individuals are adding to the body of knowledge contained within WP, and it is the mean-spirited deletion of this content to which I am referring.

For example, where a contributor has posted new materiel in the wrong location, rather than deleting the information and scolding the contributor, the editor should, instead, either work with the contributor in moving the information to the correct location, or simply move the information themselves.

I recently read the personal page of a WP editor who was a member of the New Page Police (NPP) team. That editor shamelessly espoused the behaviour of deleting pages instead of attempting to contribute to them so that they could remain. I am sympathetic to the idea that many new page are rubbish, but to go into each new page evaluation with no motivation to help contribute to the page's relevance is foreign to the way I believe that WP editors should behave.

Content vs. Organisation

An excellent example of this deletion of content is how WP editors have become confused about (a) content vs. (b) the organisation of content. The rules around what information may be captured in WP is centered on "pages"; which means that so-called non-notable information may be added to an existing page but may not have a page of its own. While this idea is sometimes valid, it just as often is not. For example, where a musician has released several albums over a long career, but only a subset of them have been million sellers, the WP notability rules state that only the million selling releases may have a "page" of their own; however, these same rules recommend that the non-notable content be added to the artists main "page". This results in the main page becoming inordinately long.

This thinking confuses organisation with content. If the content is not suitable for inclusion on a page of its own; then it shouldn't simply be moved elsewhere: it either qualifies for inclusion in WP or it doesn't. Note: in the interests of well organised content, the creation of mostly empty pages is counterproductive—and so as part of keeping WP well organised it makes sense to work towards each "page" containing a reasonable amount of information. But, this organisation motivation is very different than an evaluation of notability (which is an assessment of whether certain information qualifies for inclusion in WP).

Weaponisation

Recently, I have noticed that Wikideletionists have begun to deploy a new tactic in their zeal to impose their worldview on WP: the redirect. A Wikideletionist will replace an entire page's content with a redirect command. This results in the page being inaccessible to the average user for further editing. This weaponisation of WP pages is done to arbitrarily impose an outcome without allowing disputed content to exist for a period of time to allow wider discussion.

Use of Public Domain Text

This week, I used public domain text in a new WP page I created. Within a day I had the Wikideletionists marking my text as a copyright violation. The root issue was that copyrighted web-sites had also posted that public domain text, and so they (the Wikideletionists) classified my text as infringing those sites that had also copied the public domain text. To make matters worse, I had cited my text with a reference to the original public domain source of the text, but the Wikideletionists hadn't bothered to read my cites... such is their laziness. While I eventually prevailed and the text I posted was restored, it was an unnecessary waste of my time because the Wikideletionists couldn't be bothered to actually contribute to Wikipedia

Contribute or Criticise?

Another bad habit some Wikipedia users exhibit is to whine or criticise instead of contributing. For example, recently, on the HP-41C page a user noted on the Talk tab that a particular error message was incorrect: the user criticised the content instead of simply correcting the mistake. I have no way of knowing the user's motivation for not simply clicking on the [Edit] button and making the correction; but, this behaviour is (unfortunately) not unusual. In the time it took the user to whine in the Talk tab they could have made the correction and improved Wikipedia's content; instead, they wasted their time and created work for someone else.

Dates on Wikipedia

Recently, Wikipedia (WP) decided to no longer support the automatic formatting of dates. Instead, editors are now being asked to code dates in either a United States specific format, or a non-US format; where the month is spelled out in full as a word. Another WP editor was kind enough to point me to some of the historical discussions on this subject:

In reviewing the discussion, I was left with the conclusion that those driving this discussion have no interest in serving readers; rather, they hold their personal perspectives and preferences in higher esteem than the readers for which WP exists. Good UX design would both drive presentation of material in a reader-friendly format and use the power of the computers doing the presentation in support of that UX design. The WP sub-community who have driven the date decision consciously disregarded readers and the ability of computers to support good UX design.

In addition, in examining the ill-fated attempt the community made to support automatic formatting of dates, it is clear that the community failed to seek out expert input as to how the input mark-up should be constructed (that is, a computer language designer). The team chose to overload the double-square brackets link operator to indicate where dates needed to be formatted. Such auto-formatting should have been done using a new curly-bracket operator. The irony of the current situation is that this new rule which requires editors to manually type the date in full comes with a new curly-bracket operator that the editor is supposed to use to specify the format in which such manually typed dates should be entered.

It seems to me that the most rational and reader-friendly approach is to always specify dates in YMD format, and then have the WP compute engine reformat them (in real time as the page is displayed) according to the reader's preference. IMHO: since Wikipedia is an international encyclopedia, dates within it should be coded in conformance with ISO 8601. How those dates are presented to a reader should then be in control of that reader. After all, WP is not a static printed document: each page is dynamically formatted in real time when the user accesses the page. For WP to impose a date format on readers is impolite and disrespectful.

A WP editor expressed to me the opinion that, "ISO 8601 is a horrible choice for Wikipedia because it requires all dates be in the Gregorian calendar, and doesn't allow dates before 1583 without first asking permission from your readers, which is completely impractical in Wikipedia's case."

Re: "...doesn't allow dates before 1583 without first asking permission from your readers,..." This position is a complete misunderstanding and mischaracterisation of the standard's requirement. The standard requires that when two parties (or programs) are exchanging pre-1583 dates that the parties must agree upon a common understanding of how those dates will be handled; since the standard itself doesn't impose an understanding of those dates. This kind of misunderstanding is one that a non-technical person might take away from the reading of a technical standard. For WP to use ISO-8601 as its date standard, the only thing necessary for pre-1583 dates is for WP to document how such dates are handled so that readers know how to interpret such dates. This is no different than the current DMY/MDY use of dates: WP simply tells the reader how to interpret the dates that appear on a particular page.
Re: "dates before 1583..." Whether a WP editor writes "1 January 1500" or "January 1, 1500" or "1500-01-01", there is no semantic difference. The editor's objection doesn't make any sense. We all understand that there are different historical calendars; but the solution is simply to either state that all WP dates are in Gregorian format, or to allow a mark-up tag that provides for non-Gregorian dates to be added to pages (so that the WP formatting engine can reformat for readers per their preference settings).

Computers exist to reduce the workload of people. The last I was aware, WP pages were formatted by a computer; therefore, there is no rationale for the computer offloading work onto WP editors.

Auto-formatting of Dates

Over 10 years ago, some WP editors had discussions on the subject of auto-formatting dates. Those against continuing to allow auto-formatted dates argued that it was not possible to always correctly auto-format a date for the following phrase (where the date component is inside a formatting tag): "The September 11, 2001, attacks..." When using non-American, long format dates this phrase is, "The 11 September 2001 attacks...". This assertion being that a tag all on its own cannot properly format itself.

The flaw in the naysayer's logic is thinking that there should be one date-tag to rule them all. Anyone familiar with TeX will know that Donald Knuth allowed for some edge cases that had to be handled manually as TeX converted mark-up to human readable pages (e.g., no extra space after some periods). This same requirement for manual treatment of edge cases would also apply to auto-formatted dates in WP: for example, for exceptional cases where the trailing comma should be omitted from American-formatted dates, this would be indicated by the date-tag.

In the historical discussions, another objection raised to the auto-formatting of dates is that WP doesn't know how to format dates for users who are not logged-in. As with the other objections, this one is also specious: WP can easily use geo-tracking to determine a user's general location and then format dates according to the user's locale (just like Netflix determines from which country a viewer is watching). WP can fall back to YYYY-MM-DD if no location can be reliably established.

As I mentioned a few paragraphs above, the real issue seems to be that those making recommendations and decisions about computer language mark-up have no expertise from which to speak about the subject.

Ellipses

Like the presentation of dates, ellipses are another example of a broken Wikipedia "standard". Per MOS:ELLIPSIS, Wikipedia editors are to use three periods separated by a non-breaking space, instead of an ellipsis character. The rationale for this approach was explained in the WP Manual of Style and can be sumamrised as, "some typefaces contain a poorly drawn ellipsis character, so we'll use three periods instead". The author of the Talk post asserts that an ellipsis is not a single typesetting element; however, since every style guide mentioned on Wikipedia's own Ellipsis page either requires use a single character or of three dots that are kept together as though they are a single character, any suggestion that an ellipsis is not an atomic typesetting element is specious.

So, once again Wikipedia's approach is to eschew the use of compute cycles and use a manual method to implement a typesetting requirement. A better approach would be to ask Wikipedia editors to code ellipses as mark-up and then let the display engine decide how to render the character. The Wikipedia approach forgets that users are no longer using typewriters; in other words, the MOS:ELLIPSIS style decision is stuck in the pre-computer age.

One last remark: no one should suggest that use of an ellipsis mark-up tag creates a burden for Wikipedia editors: Wikipedia's article editor can easily be coded to transform three periods into the tag, just as MS Word automatically transforms three periods into an ellipsis character.

Section Headings and Capitalisation

Another unfortunate decision made by ignorant Wikipedia editors is documented in Manual_of_Style#Section_headings and is summarised by that page's opening sentence, "Section headings should … be presented in sentence case." The apparent justification for this decision is that "Wikipedia avoids unnecessary capitalization." As with the other badly informed decisions I've documented on this page, the decision to not use title capitalisation in titles serves only to make Wikipedia "less", and not "more". Title case capitalisation is, by definition, not an instance of unnecessary capitalisation; rather, it serves to provide another visual cue to the reader that the title is a title and not article text. Also, the very fact that Wikipedia uses the phrase "sentence case" means that the editors who made the decision understand that there is a difference between sentences and titles, and that they were consciously deciding to not format titles as titles (how bizarre is that!!).

This sentence case decision is yet another example of Robert A. Heinlein's observation that, "To assess the intelligence of a committee, divide the IQ of its stupidest member by the number of members."

An Example of Why WP Gets Labelled as Unreliable

Today, I had an unfortunate exchange with another WP editor. A large number of WP pages have used an image that claims to be a picture of a Big Mac that can easily be seen to NOT be a Big Mac (I won't link to it because that would give it legitimacy in the WP system). The image is certainly one of a hamburger; but, it's not an actual McDonald's Big Mac. I had edited several pages using that image and either removed the image or removed the words "Big Mac" from the image label.

The other WP editor reverted my edits and their rationale was that the image actually is a Big Mac — referencing the original uploader's statement that the burger was a Big Mac. The uploader's statement does not change the fact that the image does not show a Big Mac as sold by McDonald's: the burger's cheese and pickles are each on top of a meat patty instead of underneath it, which clearly shows the burger to NOT be a Big Mac.

Another Example

This week, I encountered another example of why WP gets labeled as unreliable: I corrected misinformation and cited with reliable sources (that is, the U.S. National Archives) yet editors continued to tell me that I was wrong. These editors all referenced a single YouTube video as their evidence that I was incorrect. Fortunately, the editors all eventually relented and allowed my text to stand; but, the fact that they all believed YouTube to be credible source is a real problem.

My Non-Wikipedia Face

See my home page for my public face.