ebooksgratis.com

See also ebooksgratis.com: no banners, no cookies, totally FREE.

CLASSICISTRANIERI HOME PAGE - YOUTUBE CHANNEL
Privacy Policy Cookie Policy Terms and Conditions
Wikipedia:Requests for adminship/Promotion guidelines - Wikipedia, the free encyclopedia

Wikipedia:Requests for adminship/Promotion guidelines

From Wikipedia, the free encyclopedia

✘ This Wikipedia page is currently inactive and is retained as a historical archive.
Either the page is no longer relevant or consensus has become unclear. If you want to revive discussion regarding the subject, you should seek broader input via a forum such as the proposals page of the village pump.

Contents

[edit] History of admin promotion

In the early days of Wikipedia, adminship was widely granted ("this should be no big deal"), and there was a belief that the project would eventually lose the admin distinction chiefly as a result of m:Deletion management redesign. Adminship was granted by acclamation, originally to anyone who had been with the project for about two months making solid contributions. There was also a requirement to subscribe to the mailing list. Nominations were made on the mailing list and there was no vote. Few nominations were turned down.

The RfA page began to be utilized on June 14, 2003. Then, adminship was judged and granted by the handful of people who had write access to the database as a result of their software development activities, along with Ed Poor, who was given write access to the database chiefly for the purpose of dealing with administrative matters for which there was no user interface.

Over the next few months, RfA became more and more vote-like, and the 75%-80% threshold developed mainly in imitation of the threshold used at VfD, which had already been in operation for some years.

The present system of "bureaucrats" who determine consensus and have the technical means and authority to grant adminship based on it began to be used on Feburary 17, 2004.

RfA requests gradually became more contentious. There were a handful of cases of good admins gone bad, and it became clear that only repeated, ongoing, egregious policy violation could lead to a suspension of sysop status. Requirements gradually crept up, with the tenure requirement increasing from two months to six, and the number of edits required increasing from 500 to 2000. New requirements were imposed, at least by some voters, including minimum daily activity levels, involvement in VfD and policy discussions, and editing in a broad range of areas.

[edit] Current status

At present, candidates undergo scrutiny of substantially all of their edits. Voters apply varying standards, since there is no lasting consensus on the requirements. The process is unpleasant for the candidate, who often ends up feeling undervalued by the community, even when adminship is ultimately granted.

While there have always been close votes, the number of these is increasing.

[edit] Categorizing adminship requests

  • About 50% of the adminship requests are from people who are clearly qualified and where there are relatively few objections.
  • About 40% of the adminship requests are turned down chiefly on tenure and experience grounds. These are rarely contentious, and in borderline cases the usual advice is that the candidate should try again in a few months.
  • The remaining 10% of the requests are from longtime contributors who exceed the experience and tenure requirements, but where there are some Wikipedians who oppose adminship due to mistrust. These requests are invariably acrimonious, and some (perhaps many) result in damage to the social fabric of Wikipedia.

[edit] Some proposals for RfA

  1. I believe that it would help candidates, bureaucrats, and voters alike to develop a set of tenure guidelines, achieve consenus on them, and stick to them. At present, each voter may vote using whatever yardstick they choose, and this is unfair. In particular, "oppose" votes made by someone who is pursing a policy agenda of stricter standards are unfair to the candidate. The tenure/experience requirements need not be immutable and may still allow for some judgement, but we should at least agree on whether the basic number of edits required in most cases is 1000, 2000, or some other number. In like fashion, we should agree whether 4, 6, or some other number of months is appropriate.
  2. m:Voting is evil. I see little attempt to achieve consensus. I believe that the decisionmaking process should involve more of an attempt by the community to resolve questions to the satisfaction of the "oppose" voters, especially in borderline cases. In general, I believe the candidate should stay out of it and other members of the community should work it out as this makes the matter less contentious.
  3. Bureaucrats should work as facilitators. They should ask oppose voters to clarify their position, where appropriate. They should ask supporting voters to respond to the concerns of the oppose voters. They should then ask oppose voters whether their concerns are satisfied.
  4. I believe that in contentious cases where trust is the issue, the request should be left open for a considerable length of time until discussion ceases, possibly several weeks. Voters should be encouraged to change their votes if they change their mind. Voters should be encouraged to ask the candidate questions and to give due consideration to the responses received.
  5. I think that bureaucrats should consider the rationale for votes, particularly of the opposition to a candidate. Some votes are ill-considered and should be treated as such, particularly those made to further a campaign of stricter standards for adminship than the community requires (see #1 above), and those that offer no explanation.

[edit] Related proposals

  1. There appears to be no community consensus for periodic review of existing admins. Instead, perhaps new admins should be given a probationary period (say, six months) with a review by their peers (other admins) at its conclusion.
  2. It may make sense to disallow probationary admins from blocking and unblocking users, since these actions cause the greatest amount of disagreement. This need not require a software change; we could simply make it policy and expect new admins to follow it.

uc 15:31, 13 Oct 2004 (UTC)


aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - bcl - be - be_x_old - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - co - cr - crh - cs - csb - cu - cv - cy - da - de - diq - dsb - dv - dz - ee - el - eml - en - eo - es - et - eu - ext - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gan - gd - gl - glk - gn - got - gu - gv - ha - hak - haw - he - hi - hif - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kaa - kab - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mdf - mg - mh - mi - mk - ml - mn - mo - mr - mt - mus - my - myv - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - quality - rm - rmy - rn - ro - roa_rup - roa_tara - ru - rw - sa - sah - sc - scn - sco - sd - se - sg - sh - si - simple - sk - sl - sm - sn - so - sr - srn - ss - st - stq - su - sv - sw - szl - ta - te - tet - tg - th - ti - tk - tl - tlh - tn - to - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu -