Musings about unregistered contributors

(English) This is an essay. It expresses the opinions and ideas of some Wikimedians but may not have wide support. This is not policy on Meta, but it may be a policy or guideline on other Wikimedia projects. Feel free to update this page as needed, or use the discussion page to propose major changes.

Discrimination against unregistered contributors (also mistakenly called anonymous; you can be anonymous with a registered account, as well as establish a reputation while unregistered) is a phenomenon which makes unregistered contributors' life more difficult. The means of making it more difficult may be direct, by making fewer tools or rights available to them in principle, or indirect, by discriminating against their work as a result of unreasonable, albeit common, assumptions.

Rationale of this essay:

Unregistered contributors are how everyone begins. They're the ultimate source of knowledge. Roughly speaking, 80% of constructive edits come from unregistered contributors, as does 80% of vandalism, but the latter does not justify discrimination against such contributors when it comes to developing the software.

Examples edit

Direct edit

Direct “discrimination” shows, for example, in the shape of these observations.

Software limitations
  1. Echo, a friendly notifications tool, was not available to newcomers at all (2014-02-12) — patch under review (since 2014-05-26). Were it available, it would've made things easier for newcomers — granted they could tune it down to meet their needs. (It may nag too much or too little.)
    Hence the Thank button does not work for unregistered contributors.
  2. The mobile frontend is not enabled for anonymous contributors. (?) Tracking bug: bugzilla:53069 — Obstacles to enabling MobileFrontend for anonymous users.
  3. The preferences are not available to unregistered users (bug 20151), making them miss wonderful things which are not on by default, such as MathJax (bugzilla:48036), live preview, and others.
  4. The UniversalLanguageSelector provides unregistered users the possibility to set interface language, but this is disabled on WMF wikis (bug 56464), even though they are those who most need it due to the previous point.
  5. The beta features extension is unavailable to unregistered contributors. They can not participate or test these features before they're deployed.
  6. The watchlist is not available to unregistered users, nor communicated as a possibility as of bug 54730.
  7. No user rights for unregistered users. They can't become autoconfirmed, autopatrolled or whatever at all, no-matter how experienced they are.[1]
  8. The compact personal bar will be unavailable to unregistered contributors, as MGalloway noted at a discussion.
  9. The media viewer plans, in preliminary design notes, to show file Edit button only to logged in contributors.[2] (Currently the edit button is not shown at all until the reader visits the file page.)
  10. With Flow, IP contributors can't edit their own messages. Discussed here.
  11. The content translation tool is only available for logged in contributors. (2015-02-27)
Software configuration or project architecture limitations
  1. Gadgets framework needs some more nice things, such as standard means of notifying user of errors. Extension development lacks community involvement. There are no easily discoverable software feedback means even.[3]
  2. Unregistered contributors are unable to create pages directly on some wikis: (since 2005, "as an experiment", because of the Seigenthaler incident),, and es.books as of 2011.[4]
  3. Several wikis force unregistered users to extra steps before saving their edits via JavaScript hacks, for instance by forcing that they have a preview or an edit summary (examples). The unclear requirement for unregistered users to fill an edit summary, imposed on the German Wikipedia in 2007, was reversed a few months later after noticing a substantial drop of new editors, but the scale of the damage was apparent only around 2010 from some new charts made by Erik Zachte.
  4. Unregistered users can not customize their user interface through CSS or JavaScript code. Although custom code can be loaded through browser extensions, this needs to be done for each device individually, whereas code stored in the account settings is activated for all devices the user may contribute from.

Notes edit

  1. This has to go rather low, as an IP may be shared and password authentication is necessary at some point.
  2. [1] — «Acceptance Criteria:
    • Show "Edit this file on Wikimania Commons" tooltip to auto-confirmed editors (or editors who have made over 100? edits to date);
    • For readers and other non-editors, we would continue to show "More details about this file on Wikimedia Commons"), so this better fits their interests.»
  3. The software is scriptable — for use by everyone — through gadgets. However, those are hard to code, with no existing framework, with people doing some standard things over and over (coding a subroutine to check whether a page exists, for example, when they want a gadget to move a page). — Anyone can edit articles, more or less, but not the interactive tools of the interface. WMF does some, but shelled away in files on a server, to go through extensive code review by a team instead of collaborating together on-wiki and some gadgets as a part of MediaWiki distribution.
  4. Note that, «based on better social and statistical scrutiny of its effects» (?), the community has decided to stop expansion of this configuration to other wikis, see Limits to configuration changes... — See the main unregistered user and newly registered user pages.

Indirect edit

Indirect discrimination may take these forms:

  1. Special:NewPagesFeed — a tool to patrol recently created pages — displays contributor name and edit count at an early stage of the review, before the patroller viewed the page. This contributes to early impression of the article being made by a presumably inexperienced contributor.

See also edit

Alternatives edit

Cookies authentication edit

Implement automatic contributor name generation — such as User<random number here> — and cookie authentication, with the account being inaccessible after a user clears his cookies. (StackOverflow does this.) Regrettably some of such users would use a shared browser and hence a shared "account", and there would be potential of one sane contributor gaining a status for the user with another one making articles through it. Presumably the IP itself would still be exposed and there would be multiple 'user####' thingies per IP.

The #### bit could be the IP.

Such approach would pose confusion to users of shared IPs. There are the following question(s):

  • How many IPs are identified as shared and how many seem to be individual?
  • How, and at which point(s), to offer such unregistered contributors to register?
  • Any half-competent troll is very soon going to figure out that they can circumvent this block by deleting cookies or opening a new private/incognito window.

IP contributors page creation edit

IP contributors could create pages until a point when — as an experiment — it was disabled. It keeps being disabled, as of 2014, though increasingly questioned. Re-enabling it would address point 5, but leave other problems open.

Requiring autoconfirmation edit

Wikipedia:Autoconfirmed article creation trial was a proposal for trial which required both registering and getting autoconfirmed to address point 5. This solves the «If you don't trust me as an IP contributor in page creation, why do you after I take 5 secs to register?» problem; however, it does not solve other points.

Thoughts on unimportance of authentication edit

What is an anonymous contributor edit

An anonymous contributor is a contributor who, by design, is without a permanent identity on the wiki. Permanent identity includes:

  • personal biography: all-time action history (contributions, logs);
  • personal "properties": preferences, watchlist;
  • personal communication, outgoing (user page) and incoming (user talk).

Of course the differences are slighter in practice between a person who has a static IP lasting years and another who registers an account every week.

What an anonymous contributor is not edit

The IP address is not the point; nor is authentication.

For instance in UseModWiki the IP was not shown completely and the username was used "opt in" on every edit, simply by entering it, without any authentication. The username was just a pen name under a message: an author can use a single pen name, or a hundred.

Brion Vibber said in 2014:

In general I favor migrating away from publicly exposing IP addresses, but

not sure to what exactly would be best... I kinda like the idea of an anonymous-but-consistent "proto-account" that can be transformed into a named login if desired, but it needs to be thought out in more detail to resolve potential difficulties.

  Add your solution