User:SD0001/Thoughts

From Wikipedia, the free encyclopedia

Verbosity[edit]

One of the fundamental problems at Wikipedia due to which new users are left uncomfortable is the tradition of user warnings and help pages that are too long. The CSD nomination notice produced by Twinkle that is posted on the author's talk page is so long and laced with links that I'd gamble to say that 90% of new users don't understand a word of it. The one produced by the Page Curation tool is only a bit more concise. In order to understand the notice, a new user has to read it, follow the link to see what that word means, then reread the sentence and check whether it makes sense... Isn't this process too cumbersome? In my view, CSD nomination notices should contain basic information about why the article may possibly not meet Wikipedia's criteria for inclusion, tips on what is to be done; properly and briefly explained within the notice itself, so that the user does not click on a million links to understand the message.

This is just an example; CSD notices are not the only things that are needlessly lengthy. Messages issued by the DPL bot, even if there is just one disambiguation link to be repaired, are no less than 65-70 words long. Actually, what prompted me to write this is the way the Page Curation tool sends feedback from new page patrollers to an article creator. The feedback that is written is disguised within a string of automatically generated text. When I used it for the first time, I wrote in the following message: Please provide additional references for verifying the contents of the article. But when I visited the talk page, I was surprised to see that the message that had been posted there was much longer. It began with: Hi, I'm SD0001. USER, thanks for creating ... ! I've just tagged the page, using our page curation tools, as having some issues to fix ... The one line of useful advice was mingled with four sentences of pointless crap. The user-written comment is not bolded, italicised, or otherwise emphasised in any manner to separate it from the automatically generated text. I don't see any need to keep saying thank you over and over again, except perhaps at the end of the message. New users are hardly going to feel warm or welcome by such messages as they would know fully well that these are computer-generated. On the other hand, one line of pointed, constructive advice would leave them inspired and welcomed. Links should be provided only so that a user can use it to know more about the subject, and not to know the subject itself.

Talking of emphasis, the only thing that ever appears in bold in the multitude of user warnings we have is perhaps the phrase "blocked from editing". There are better things to emphasise in messages: see Wikipedia:Requests_for_bureaucratship/Essjay, where the editor makes long and detailed explanations, but what is remarkable is his way of highlighting important points by bolding it, and in one instance, by increasing the font size and italicising. All this enables the reader to quickly take in the gist of what is being said. Regrettably, the use of emphasis in user warnings, project namespace information pages and help pages is done sparingly.

In today's fast moving world, it is important that new editors understand the mechanisms that make Wikipedia, and blend in to the community, with minimum time and energy expenditure. Only when this is assured can any attempt at editor retention succeed.

Administrators[edit]

It is well known that becoming an administrator in Wikipedia's early days was far more easier than it is now. RfAs before 2005 did not have any additional questions apart from the default three for candidates to answer. And there have been cases where RfAs were successful even when candidates replied to these questions in one line. And as for even earlier RfAs, such as the ones dating back to 2003, well, they are a joke. It was an entirely informal process back then with no questions, no support or oppose votes, but merely the type of discussion that one sees at WP:RFPE. Have a look at this one, for example. My mouth fell open when I visited this candidate's user page and saw that he was still an administrator.

What is bewildering is that once a person becomes an administrator, he's there to stay. Adminships are granted on an indefinite basis, and the only reason it is ever revoked is if the user does something really wrong, like deleting pages or blocking users without explanation. Of course, no sensible administrator would do such a thing. WP:Administrators tells us that an adminship is no big deal, but the reality is that administrators have really big powers.

Here's a (possibly incomplete) list of what admins can do
  • Block and unblock users, IP addresses and IP ranges
  • Delete pages (as long as they have less than 5000 revisions)
  • Protect (and unprotect) pages from being edited, moved or created
  • Edit fully protcted pages
This includes the ability to edit the main page
  • Edit Wikipedia's interface messages
  • Edit the style of the interface by changing the CSS at MediaWiki:Vector.css; as well as edit some of the site-wide and skin-specific JavaScript of the software
  • Edit the JS and CSS subpages of other users
  • Override the title blacklist
As a consequence of the above two: to move pages to any desired title
  • View content and history of deleted pages
This includes deleted revisions of pages and deleted contributions of users
  • Restore deleted pages
  • Perform revision deletions
  • Perform history merges
  • Move pages without leaving a redirect
  • Automatically move upto 100 subpages while moving a page
  • Import pages (with history) from other Wikimedia wikis
  • Override all rate limits
  • View private edit filters
  • Create, modify and delete edit filters (by just adding themselves to the Edit filter managers group)
  • Move files
  • Use Rollback
  • Review pending changes
  • Have pages created by them automatically marked as patrolled
  • Send mass messages
  • Create user accounts without the usual restrictions (create accounts with names similar to those of existing accounts, override the username blacklist)
  • Exempt themselves from their editing access being restricted by IP blocks
  • Grant and revoke various user rights (rollbacker, PC reviewer, autopatrolled, template editor, file mover, mass message sender, IP block exemption, account creator, edit filter manager, education courses volunteer, instructor and coordinator)
  • Access the list of unwatched pages
  • Hide the reverted instances of vandalism from Recent changes by marking them as bot edits

They also act as the 'default' user group to be entrusted with any new advanced right that comes along with changes. (For example, as per existing plans, only administrators will have the ability to edit others' comments in the "Flow"-styled talk pages that would replace the existing talk pages in some years. Also, administrators were given the right for granting and revoking the new template editor user right.) Becoming an administrator is also the first step in obtaining even more advanced rights like that of a bureaucrat, CheckUser and Oversighter. Of course, it can rightfully be argued that administrators act on behalf of the community, and cannot wield their powers on personal discretion. Decisions taken by them are taken in their capacity as an administrator and reflect the wants of the community, and are for the general good. But wait, is all this true for all administrators? Certainly, all this holds good only for those who have gone though an intense community review process, which we know as the RfA. The concern is that RfAs of old times were not intense enough. This leaves us in a dangerous situation of having administrators amongst us whose decisions may not reflect the wants of the community; and who may wield their powers improperly.

In this RfA, the candidate's answer to the first question is not even one line long, in addition to being grammatically improper. One look at the 'support' votes and you will see that hardly one or two of them provide a rationale. Most of these old folks may not even remember what it was like to not be an admin. In these cases, the question we need to ask is not whether they should remain an admin, but whether they should be an admin.

In summary, is it unreasonable to expect them to voluntarily give in the mop, and go through today's RfA?

Even though the prospective administrators are analyzed from hundreds of points of view before they are granted adminship, the only way editors can express their disapproval of their use of the tools is by contacting them directly on their talk pages! In my view, nothing can be more preposterous. There is no forum for requesting removal of adminships. As it is now, an administrator will remain an administrator even if they make a hundred deletions using the incorrect CSD criterion. (Some might argue here that they won't do that, since a person who would have done that would have been filtered by the RfA.) In cases when attempts to overcome issues on the talk page have supposedly failed, the issue may be taken to the Administrators' noticeboard for incidents (ANI). But it hardly appears to be a suitable forum. Such discussions there are typically surrounded by a hundred irrelevant discussions on various smaller issues. The ANI is a dynamic place and thus discussions inactive for more than 36 hours are archived, making it unsuitable for reporting long term issues. One advantage of using the ANI though, is that it generates a lot of attention. Even though threads are archived quickly, the ones against adminship become very long indeed, so long that they become inconvenient to browse through. These discussions are not hosted as separate pages, as with RfAs and RfC/Us.

The decision to discontinue the use of the RfC for comments on user conduct was justified, in my view, when used for newer and lesser users. But not for the more experienced users (the "unblockables") who may sometimes engage in misconduct. In my view, the scope of RfC can be expanded to include discussions for removing administrative privileges, as well as bureaucrat rights, if need be. (Actually, it was used for that purpose for a brief period of time in the past.) The misuse of this forum, which can be discouraging and embarrassing to the admins concerned and disruptive for the community at large, can be prevented by quick closure of the nominations that lack depth (the same way that we close RfAs as WP:NOTNOW or WP:SNOW). If not the RfC, then the Bureaucrats' noticeboard also appears to be a suitable forum. This is because matters regarding de-adminship (for inactivity) and bot requests are the only ones to be taken there. As a result, it is much less crowded, and threads can be allowed to stay there for much longer than 36 hours. The problem of low visibility can be solved by posting a notification to the ANI and AN every time a new discussion is started. Yet another alternative is the Administrators' noticeboard itself.

Recently, concerns have been about RfAs being an overly intense process, thus deterring many users from seeking adminship. There are also concerns that successful RfAs are yielding inactive admins. Reforms in the RfA process have been proposed many times, but no proposal has earned community consensus. There exists an entire category of user essays on RfA reforms.

The same is the case with the community review process for existing administrators. A great list of failed proposals regarding this can be found here. One opposing argument that I came across was that the problem of administrator abuse was nonexistent. There you are. What? How can anyone say that a problem is inexistent when there is no method to report the problem? As long as there are administrators, there should be a way to report administrator abuse. This is an essential safeguard in any open system.

The same is also true for the de-bundling of admin tools. While Trappist the monk's RfA sort of helped in the proposal for the template editor user right, some of the other commonly requested rights, including that for viewing deleted pages, have continued to fail, despite many RfCs, as well as RfAs like this one. All this forms yet another example of the community's startling resistance to change when it comes to admin tools.

The fact that WT:RFA has over 200 archives, unprecedented for any page of its kind, and more than the village pumps, administrators' noticeboard, and Jimbo Wales' talk page, reveals much.

Resistivity to change[edit]

During my strolls around Wikipedia's Village pump, I notice that a majority of the proposals made are opposed. This is worrying. Because even the good proposals seem to be opposed just because established editors, it seems, want things to remain as they are. Much to my bewilderment, a good number of proposals are opposed because they are accused of making things more complicated or confusing. Of course, everything new is confusing at first, just like the entire system appears confusing to a new user. A large number of things on Wikipedia already are complicated; modifying these processes without an intent to simply the process, even when it doesn't necessarily make it more complicated, it seems, almost never wins any support. All proposals at Wikipedia:Village pump (proposals) and Wikipedia:Village pump (policy) have got to be solutions to a particular problem. If you propose a change that doesn't seem to be addressing any issue in particular, it will be branded as a "solution looking for a problem" (isn't that a bit too derogatory to the proposer?) and will be unlikely to ever pass.

Many RfCs fail because of erratic methods of commenting and disagreements. If ten persons put forth ten opinions, then none of them can be implemented. On the other hand, if the similar opinions are grouped into some basic solutions, there are chances for eventually arriving at a compromise. It is also correct to say that a large number of editors don't want to compromise. Saying a simple thing like 'I agree' requires a major effort for them. It is only when editors are willing to agree to each others' opinions that something will actually come out of an RfC. Another thing that is commonly noticed is that some editors bring forth trivial issues that are not fundamentally a part of the proposal thus disrupting the discussion. This makes an RfC go off the track. Moreover, some editors like to engage in one-on-one duels against each other. This also can be seen as disrupting the process as other editors would be reluctant to air their own opinions in between, as they feel that the discussion is between the duelers only.

A number of proposals on the village pump are also opposed on technical grounds, ironically by editors who seem to have an incomplete or doubtful understanding of the technical aspects of the change being proposed. Besides, I hardly think that technical challenges should be a decisive factor in affecting the outcomes of potentially beneficial proposals because the Wikimedia Foundation has no dearth of resources at the moment. Technical issues that stand in the way can be resolved. But in order to obtain community-wide consensus on the usefulness of a certain change, the community must be willing to take bold moves. The lack of any leadership can be seen as a primary reason for such oppositions. As well as the policy of giving equal weight to everyone's comments.

Dictatorial regimes result in quick and effective decisions. Democracies produce accountable governments responsive to the needs of the people. But Wikipedia is neither a dictatorship nor a democracy (WP:NOT!). The government of Wikipedia has clearly emerged to be as slow as a democracy, and as unresponsive to the needs of editors as a dictatorship.

Village pumps[edit]

The village pumps are nothing of the sort of informal gathering places that the name seems to imply. I can only assume that they were named in line with their original intentions. (The very first edit to the village pump was saved with the edit summary "first drink from the pump".) But we do have one real village pump though – Jimbo Wales's talk page! That is the real village pump, with its informal nature and with a large number of IPs putting forth their suggestions and grievances, most of which are awkward. It is, as a matter of fact, more watched than the village pumps.

Mobile diffs[edit]

Anybody who has edited through Wikipedia's mobile view would have noticed the way mobile diffs are displayed.

  1. The editor's edit count is shown prominently at the bottom, encouraging editcountitis.
  2. Also displayed prominently are the user rights held by the editor. This promotes WP:Hat collecting. Users who edit mostly through mobile would be encouraged to collect user rights as they rightfully understand that these are prominently visible to other mobile editors.

In my view, these should be replaced with quick links to talk page and contribs. Probably, the devs must have felt that mobile editors won't be serious and thus showing them the edit count was a way of egging them on to continue making edits. That still doesn't justify the viewing of user rights, though.

Why portals?[edit]

The maintenance of portals on Wikipedia takes up valuable time of editors and essentially detracts from the work of creating an encyclopedia. WP:Portal tells us that portals are intended as a "gateway to Wikipedia's content". But Wikipedia is largely used as a reference encyclopedia. Articles are long enough for anyone to read them fully. So what exactly is the need for a gateway for contents when most of Wikipedia's page views are generated by external gateways. You know what I am referring to: Google Search, and similar services.

Portals are a rather mundane aspect of Wikipedia. Their absence will result in editors being able to devote more time to editing the articles. The number of editors on Wikipedia follows a declining trend; this necessitates the need to make sure that their valuable time is being dedicated to the more important tasks.

In particular, it would be useful if we could reduce the number of portals. In my view, we should do away with portals representing companies, brands, and products. These are of little use, except that of advertising. The very structure of Wikipedia's portals causes a promotional effect. This effect becomes open and visible when the subject is actually a business entity. We should be having portals only for broad subjects and generic and neutral topics, having a scope of at least, let us say, two thousand articles. Pages such as Portal:Google and Portal:Apple should simply be deleted.

What is really necessary is that the creation of new portals, in general, should be discouraged by imposing tight caps on portal-worthy topics.

Admins and free web hosting[edit]

Is it really not possible to use Wikipedia as a free web host? I don't think so. It is very much possible for one particular group of users – administrators – to use Wikipedia for hosting text content for viewing by themselves. The procedure is simple: an administrator creates a new user account, preferably using a different IP range as the one normally used for editing (by going to a cyber cafe, for instance). This eliminates any possibility of checkusers detecting the sock. Then, they create a new page with any amount unWikipedish content, preferably added in one single edit. Of course, it'll be immediately tagged and deleted. But then, administrators can view deleted content!

Usually, user accounts are not blocked for creating one inappropriate page, so the sock account can be reused many more times. Some may feel that there are better services for free web hosting. But many experienced users are too fond of wiki-markup to not consider this method. As someone once said, is there anything admins can't do?

The Test Wikipedia provides an even more suitable platform, as becoming an admin is less difficult, and IPs can be used to create pages, so that you don't have to create a sock. In fact, becoming an admin is a very simple two-step process on the The Test Wiki.

Block evasions and sockpuppetry[edit]

One disturbing aspect of the blocking policy is that accounts are blocked for block evasion even if no harmful or unconstrctive edits have been made through that account. Most editors here must have, at some point or the other in their careers, sat back and thought about it. The logic behind this is certainly reasonable – that block evasions are a mockery of the system. Of course, blocks mean nothing if they are to be evaded through sock accounts or IPs. What should be changed is not the policy, but the system itself.

Another interesting fact is that sockpuppetry isn't always detected, as the policy page will make you think. The only ways sockpuppetry can be confirmed is if there is CheckUser evidence or substantial WP:DUCK evidence. Duck would almost never suffice for those who contribute with an advanced level of English. And obtaining a CheckUser test requires some evidence to already be present. That is to say, if you use multiple accounts but avoid a similarity in editing pattern from creeping up, you won't be detected.

User warnings: new idea?[edit]

Why don't we have user warnings like this (for edits obviously made with malicious intent)?

Nice try... Your recent edit at [[PAGENAME]] looked awesome. Unfortunately though, it has been detected and reverted or removed. Please do not vandalise Wikipedia with edits like that one. You can be blocked from editing if you continue doing so.

To me, most of Wikipedia's user warnings look too boring and unnecessarily verbose. Do they really ever discourage users from editing disruptively again?

The thing with archiving[edit]

We come across so many places where section links to specific discussions are broken because they have been archived. This is especially common for discussions on pages like WP:ANI, WP:VPR, WP:VPP, and WT:RFA, which have hundreds of archives. Can't anything be done about it?

Of users and usernames[edit]

  • Don't confuse between users BDD and DGG. Apart from the similarity in their usernames, both are administrators on Wikipedia and librarians in real life!
  • The user Sandbox once existed. The account made two edits in 2004 - both unsourced and inconspicuous additions to articles Jesus and Money; both were reverted. The user page is now actually used as a sandbox. The talk page redirects to WT:Sandbox.
  • The user Wikipedia once existed! Was blocked indef on the account of a "confusing username".
  • The user WIKIPEDIA too once existed! What is surprising is that its user talk page is still intact! Although a block notice is there on the page, the block log shows nothing.
  • The account Main Page too existed. Was blocked indef by Essjay with the block summary reading: WOW.
  • The user account for Example appears to be the only one of its kind that has been admittedly created by another editor. The only edit made through it was the declaration.
  • The user Delete too existed. Note that Special:Log/delete takes you to the deletion log, while Special:Log/Delete takes you to the log of user Delete's actions.
  • The users Move and Merge were both serious contributors (though now inactive).
  • The user talk pages of Example, Delete, Move, Merge and Import have all been recently slapped with the same humorous serious message.
  • The users Wikibooks and Wikisource appear to have been reserved by someone in good faith, for they were never used.
  • User pages are considered an exception to WP:OWN. But Jimbo Wales is perhaps the only user who has no control over his own userspace, an irony considering the fact that he founded the project and thus should have had a control over the entire project. Most pages in his userspace were not created by him, and there are many which have never been even edited by him!