On 31/05/2010, Abd ul-Rahman Lomax <abd(a)lomaxdesign.com> wrote:
> As to regular deletion, an admin is assessing
> arguments and consensus at an AfD, and, if doing this well, doesn't
> delete unless there is consensus for it, or, alternatively, the
> arguments are clear and evidenced.
Actually it's not supposed to be about consensus at AFD.
If you use consensus it's far, far too easy to stuff the vote; people
can email their friends or use socks, and in common cases it's almost
completely undetectable.
Too many AFDs I've seen, in practice, work as a straight vote; that
just doesn't work at all.
That's why it's supposed to be about who has identified the valid
policy for deletion or keeping it. You can't stuff the vote by
identifying valid policy.
--
-Ian Woollard
At 01:58 PM 5/30/2010, Thomas Dalton wrote:
>On 30 May 2010 11:43, David Gerard <dgerard(a)gmail.com> wrote:
> > Indeed. The first - and, I would have thought, jawdroppingly obvious -
> > result would be that no-one at all would go near such work in any
> > circumstances.
>
>Exactly. The big problem with community desysoppings is that any admin
>doing their job properly will have enemies. The longer you do the job,
>the more enemies you will have. Whenever you block someone, you annoy
>the blockee. Whenever you delete an article, you annoy the creator.
>Whenever you protect an article, you annoy the person whose version
>you didn't protect on. If you let those people be in charge of the
>desysopping process, we won't have any good admins left doing even
>slightly controversial work (which, as I've explained, is pretty much
>all admin work).
These are the arguments that have maintained the dysfunction. But:
(1) most legitimate admin work is not controversial to any degree
that would affect an admin's status in the active community, which is
what counts. Blocking an IP vandal isn't going to harm that, and it
will only help it. If the IP vandal then registers an account and
goes after the admin, sure. But, then, as to proposals that those who
supported an RfA might retract that, or cause adminiship to be
suspended pending examination, are concerned, this would be useless.
Legitimate administration is indeed like janitorial work. Can we
imagine a good janitor getting into an argument with other employees
of a school or office as to what should be thrown away? Adminship was
supposed to be "no big deal." When an administrator is asserting
personal power over an editor, something has gone awry. Police have
no power to punish, they may arrest on probable cause, but they then
step aside and let the community make decisions on sanctions or
release. A police officer who has become personally involved and
insists on pursuing an individual might well be removed or ordered to
work in other areas.
"Whenever you delete an article, you annoy the creator." Well, it
might seem that way. But admins aren't supposed to be deleting
articles in the presence of the creator's objection, unless there is
a critical issue, and, by the rules of adminstrative recusal, they
should only do this once, personally, absent true fire-alarm
emergency. It better be good! For anything further, they'd go to the
community and not use tools to gain an advantage. And I've seen
admins violate this, causing a lot of unnecessary disruption because,
indeed, the editor then gets seriously pissed off. That's as to
speedy deletion. As to regular deletion, an admin is assessing
arguments and consensus at an AfD, and, if doing this well, doesn't
delete unless there is consensus for it, or, alternatively, the
arguments are clear and evidenced. And if the creator objects, the
admin politely considers the objection, and, if the admin can't
reverse, suggests DRV and is done. Seriously done. Probably not a
good idea to even argue for deletion at the review, the admin's
reasons should have been given with the original closure. Being
reversed should be no shame.
(2) good recusal policy requires an admin to stand aside and not
pursue an individual editor. An example of how this could work was
what happened when Iridescent blocked me in 2008. It was indef, but
she wrote, "indef as in indefinite, not as in infinite," or something
like that. And then she made no attempts at all to *keep* me blocked.
She presented her reason, and that was that. It was then between me
and the community, not me and her. As a result, I had no sense of
serious opposition to or from her, and no enmity. I still think she
made a mistake, but administrators are volunteers and will make
mistakes. Am I unusual? Maybe. But if an editor is, say, blocked for
a day by an administrator who then leaves unblock template
instructions and even wishes the editor well, and does it all
politely and correctly, it's going to be very visible if this editor
then embarks on a crusade against the admin -- unless the admin truly
was involved and shouldn't have touched the block button. Sure, it
happens. And it's very visible if anyone looks! Indeed, this editor
is likely to stay blocked or to be seen as seriously biased against
the administrator and possibly as genuinely dangerous to the project.
"I was blocked by a horrible monster" is very much not a way to get
unblocked, it rarely works.
(3) "community desysopping," per se, is a really Bad Idea. It should
be and must be much easier, and community discussions tend to be very
much a popularity contest, and waste huge amounts of editor labor.
Rather, some kind of administrative recall, as an easy process that
could result in *suspension* of administrative privileges, and even
without some presumption of actual misbehavior, merely in undoing,
temporarily, what was done with the RfA, makes much more sense.
Involving those who approved the adminship in the first place, and
who supported it, seems like a possibility that could be quite
efficient and quite clearly fair. I'm not detailing a process here,
but it would presumably be appealable. Suppose you approve my
adminship and I then find it necessary to block you. Under these
conditions, I'm probably not biased! But suppose it pisses you off.
If you can convince some number of other supporters to ask for
suspension, that might be automatic. I.e., there would be, perhaps, a
consent and request, in advance, part of the original RfA, that a
bureaucrat remove privileges under stated conditions, as verified by
the bureaucrat. This removal could then be undone through some
process, which might simply be a new RfA, but without the presumption
of a supermajority being needed. Indeed, I'd think a majority for
unsuspending should be enough (really, it would be the judgment of a
neutral bureaucrat, because of the possibility of pile-on from a
faction). And beyond that, if something was awry (such that pile-on
of a faction offended that the administrator was enforcing overall
policy), the matter could go to ArbComm on request, which might look
at the behavior of all parties. I've opined that ArbComm should
effectively suspend admin privileges for any admin if they accept the
case on a showing of probable cause of abuse; it might well do this
by issuing an injunction against use of tools in some area, not by
actual removal. And, as well, the "removal" I'm suggesting by a
bureaucrat might simply start with the admin abstaining from tool use
as instructed by the "recalling" editors, according to an original
promise, and it would only become an actual request to a bureaucrat
and then actual unsetting of the bit if the promise was violated.
Note that any administrator should probably recuse from use of tools
in an area when reasonably requested by a few editors, at least
pending discussion, I get into this more below. If I recuse on such
request, say on request by some process involving those who granted
me admnisthip in the first place, I may still be able to serve the
project in almost all the ways I'd be using admin tools anyway. It's
only when an admin uses tools, consistently in some area, and having
become involved in some way, personally, that there is a problem.
Often an abusive admin in one area still does good work in another,
if they can stay away from controversial use.
Would people approve of an admin just to gain an ability to torpedo
the admin later? I doubt it. It would be too easy and too visible to
shoot down, and the situation of an admin blocking someone who had
supported the admin gaining tool access would tend to look like "It
must have been necessary!" rather than the reverse. Frivolous
interference, or interference that has the effect of harming the
project, with an administrator especially, should be a sanctionable
offense. On the other hand, making a complaint that is considered
reasonable when reviewed should not be sanctioned, and that it
sometimes is, in effect, is chilling. Personally, I was appalled when
I filed an RfAr over administrative abuse, which was effectively
confirmed by ArbComm, it really was abuse, and the sysop lost his
bit, but ArbComm allowed the case to be massively broadened into a
"Whatever Abd Ever Did That Could Look Bad" mess. If I'd done so
much, there should have been an RfC on my behavior, and then a case
if conflict remained, a separate case, where I'm the topic, not
complicated by administrative abuse.
Indeed, that sysop mentioned had been causing problems with his tool
use and general editorial behavior for years, and I saw
administrators back off from confronting it because it was so
"expensive" because of the faction (a small but active minority)
backing him. It's still going on, but it now looks more like an
end-game, because some highly privileged and connected administrators
finally figured it out and how factional support was allowing it to continue.
Calling better process "getting rid of admins' is not a fair
statement of what decent proposals would look like. The structure
should make it easy to *restrain* administrative abuse, which would
start with much less drastic process than removal, it would start
with normal dispute resolution, at least at a low level. If a dispute
over tool usage continued, the actual usage might be examined, as
usual. In addition, my view, continuing to use tools where a user,
with anything even remotely reasoanble, objects, is not a good
practice, it should only be done in emergencies. Normally, with
respect to a registered user, an admin should recuse, practically, at
the drop of a hat. When I've suggested this, it's been claimed that
this would result in vast wikilawyering, but that objection is
clearly preposterous. If I block you and you scream that I'm biased
and should recuse, I'd respond. "Of course. I regret that this has
distressed you. I'm recusing. Bye." Actually, I'd do even better than
that, I'd provide a biolerplate set of instructions on how to appeal
an unblock. Naturally, when I blocked, I should already have provided
the block reason and the important evidence, or, if I hadn't, I'd
provide that. And then drop the whole matter. Unless I thought the
project would benefit from the unblock, I wouldn't unblock. But I'd
step aside from objecting to an unblock by any other administrator.
And then, in the future, if I saw a threat to the project from this
editor, I'd go to a noticeboard like anyone else, but I'd disclose
the prior request for recusal and acknowledge the claim of bias.
There are administrators who detest recusal policy, and they've been
very explicit about it, and if ArbComm were awake, it would order
their admin privileges suspended until it assured them that they "got
it." Instead, they practically have to dismember an unfortunate
editor right in front of ArbComm for it to be noticed. As long as
they avoid that, they're cool! They object that an editor could then
avoid being blocked by requesting recusal from admin after admin.
Given that recusal doesn't unblock, and even if they get an unblock,
are they going to claim that the unblocking admin was biased? That's
going to look really, really bad. I think within three such requests
or so, they would almost certainly be looking at an indef block with
no admin willing to unblock. I.e., a defacto ban, only with minimal
fuss, and they'd have only ArbComm to appeal to, and ArbComm is now
denying even some reasonable appeals, as far as I've seen. They don't
want the hassle.
Adminship should be "no big deal," as was claimed at the beginning.
And thus it being suspended, in part or even in toto, should be "no
big deal." Rather, some administrators very much think it's a big
deal, clearly. And this "big deal" concept, enforced by them when
they vote in RfAs, keeps people from volunteering and being accepted,
far more than some idea that allegations misbehavior might result in
a relatively harmless suspension. Someone who could not accept that
probably has the wrong idea in the first place about adminship and
thinks it is of some personal advantage. It isn't. It's an
opportunity to do some boring, relatively unrewarding work. But some
think of it as an opportunity to exert more power than regular
editors. What is wrong with this picture?
Re the theory that making it easier to get rid of admins could be a
solution to the decline in their active numbers. This is one of those
perennial theories that often sidetracks any attempt at WT:RFA to
reform the process; But has at least once failed to get consensus for
change - not least because many of its proponents seem unaware of how
easy desysopping can now be and are therefore hazy as to how much
easier they want it to be.
I like counterintuitive theories, and the idea that to get more admins
you should get rid of some of us and put the rest under greater
stress is IMHO counterintuitive. But I see the following flaws.
1 Concerns about the difficulty of desysopping admins long predate
the RFA drought that we've been in for the last couple of years.
2 It may have been true in the past that desysopping was difficult
and always traumatic for the community, but the reality of the last
few months is that whilst some desysoppings are highprofile and
dramatic, others are almost discrete and are only noticed by those who
watch Arbcom or those like me who keep an eye on the total number of
admins. I suspect that perceptions of the difficulty of desysopping
are based on the highprofile and contested cases, not the barely
noticed ones.
Any theory to explain the RFA drought needs to account for the
phenomenon of standards inflation at RFA, and explain why those
arbitrary expectations have continued to rise whilst desysopping has
if anything become easier. I've approached a number of possible
candidates in the last few months, several have declined to run either
because the standards are so arbitrary or because they don't want to
be treated the way they've seen others treated at RFA.
As for the idea that we should move to "Hi, I noticed that you
speedy-deleted some files that do not appear to meet the CSD criteria;
your SysOp staus has been removed _while we discuss it_". I've done
over 4,000 speedy deletions, and very probably there are more mistakes
amongst them that I know about, but if someone thinks I've deleted
something in error I'd expect a first approach along the lines of
"would you mind having another look at [[deleted article]], I don't
see how it was an attack page". Maybe I've made a mistake, maybe so
much has been oversighted that it no longer looks like an attack page,
maybe there are words involved that have very different meanings to a
Yank and a Brit. But a desysop first and ask questions later strategy
would in my view generate far more drama than would be justified by
the results.
WereSpielChequers
>
> IMHO, etc...
>
> The fundamental problem is the difficulty in *removing* SysOp, which *makes* it a big deal.
>
> If it really was no big deal, RfA wouldn't need to be such an ordeal; if a user is competent, reasonably experienced and no DRAMA, we should +SysOp them (AGF). If they fuck up, remove it (No big deal).
>
> We block our precious new users at the drop of a hat, but an admin has to do something pretty damned horrific to even consider removing their status, and even then it takes months.
>
> Imagine if it worked more like blocking - if an admin fucks up, remove their SysOp and have a chat about it. "Hi, I noticed that you speedy-deleted some files that do not appear to meet the CSD criteria; your SysOp staus has been removed _while we discuss it_". No big deal, the admins shouldn't mind.
>
> If that were the case, there would be no need for the depth of analysis and horrible trial that is our current RfA.
>
> Sadly, AGF is missing from RfA.
>
>
IMHO, etc...
The fundamental problem is the difficulty in *removing* SysOp, which *makes* it a big deal.
If it really was no big deal, RfA wouldn't need to be such an ordeal; if a user is competent, reasonably experienced and no DRAMA, we should +SysOp them (AGF). If they fuck up, remove it (No big deal).
We block our precious new users at the drop of a hat, but an admin has to do something pretty damned horrific to even consider removing their status, and even then it takes months.
Imagine if it worked more like blocking - if an admin fucks up, remove their SysOp and have a chat about it. "Hi, I noticed that you speedy-deleted some files that do not appear to meet the CSD criteria; your SysOp staus has been removed _while we discuss it_". No big deal, the admins shouldn't mind.
If that were the case, there would be no need for the depth of analysis and horrible trial that is our current RfA.
Sadly, AGF is missing from RfA.
> Date: Thu, 27 May 2010 15:38:09 -0700
> From: Matt Jacobs
> Subject: Re: [WikiEN-l] declining numbers of EN wiki admins
> To: wikien-l(a)lists.wikimedia.org
> Message-ID:
>
> Content-Type: text/plain; charset=ISO-8859-1
>
>> Date: Wed, 26 May 2010 20:04:43 -0400
>> From: Gwern Branwen
>> Subject: Re: [WikiEN-l] declining numbers of EN wiki admins
>> To: English Wikipedia
>> Message-ID:
>>
>> Content-Type: text/plain; charset="utf-8"
>>
>> On Wed, May 26, 2010 at 7:34 PM, David Goodman
>> wrote:
>>> Are you saying that a _declining_ number of administrators means a
>>> _growth_ in bureaucracy? ?It would normally mean the opposite, either
>>> a loss of control, or that the ordinary members were taking the
>>> function upon themselves. ?What I see is a greater degree of control
>>> and uniformity, not driven by those in formal positions of authority.
>>
>> If you assume that administrators are identical to the bureaucracy or
>> some non-shrinking proportion thereof, then that does look like a
>> falsehood.
>>
>> If you assume that administrators reflect rather the number of
>> committed long-term contributors, and their numbers wax and wane
>> pretty independently of the need for administrators, then that makes
>> sense. Little kills enthusiasm and participation as surely as
>> bureaucracy. Why are so few even trying for adminship?
>>
>
> My guess is that it's because the bureaucracy has become too intimidating.
> I suspect many editors do not want to commit the time and effort to learning
> it all.
>
>
> ------------------------------
_________________________________________________________________
http://clk.atdmt.com/UKM/go/197222280/direct/01/
We want to hear all your funny, exciting and crazy Hotmail stories. Tell us now
The good news is that after dipping below the 1720 peak, admin numbers
are on the rise again and we currently have what I believe is a new
record of 1724 admins. However if one were to exclude adminbots then I
think we are still below peak levels, and even if we are now
appointing admins faster than they are resigning, the key metric is
the number of active admins, and that is currently about 170 below
peak levels, as less than half our admins are now active.
Apart from admin bots we only have 24 admins who created their
accounts in the last 24 months, and at least a couple of them were new
accounts for returning admins.
http://en.wikipedia.org/w/index.php?title=Special:ListUsers&dir=prev&group=…
What few RFAs we have are largely mopping up stragglers from years
back, so wikipedia may still be getting lots of new editors, but very
few are becoming admins
We had a step change after rollback was unbundled in early 2008, and
there was a big fall in RFAs, Things have since deteriorated further,
there were fewer successful RFAs in 2009 than 2008, and the 2010
results so far are continuing the trend. It used to provoke comment
whenever there were no RFAs on the board, now such events have become
normal.
My fear is that if these trends
http://en.wikipedia.org/wiki/User:WereSpielChequers/RFA_by_month
continue, we will have a growing gulf between admins and non-admins,
as the defacto requirements for RFA are becoming out of reach for most
editors.
We may still have enough admins to do the urgent admin tasks for quite
some time to come; But I can see us becoming more dependant on the
occasional admin who can clear a 100 article backlog at CSD in an
hour or two, and I fear a growing divide between admins and others.
WereSpielChequers
> Date: Wed, 26 May 2010 17:02:06 -0700
> From: Howie Fung <hfung(a)wikimedia.org>
> Subject: Re: [WikiEN-l] declining numbers of EN wiki admins
> To: English Wikipedia <wikien-l(a)lists.wikimedia.org>
> Message-ID: <4BFDB67E.4000003(a)wikimedia.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Here are some numbers I pulled a few months ago regarding the number of
> admin requests over time:
>
>
> successful unsuccessful total requests % successful
> 2004 177 63 240 74%
> 2005 387 213 600 65%
> 2006 353 543 896 39%
> 2007 408 512 920 44%
> 2008 201 392 593 34%
> 2009 121 234 355 34%
>
>
> I can't comment on the reasons, but I thought I'd share the data in case
> people are interested.
>
> Howie
>
> Source:
> http://en.wikipedia.org/wiki/Wikipedia:Successful_requests_for_adminship
> and related pages.
> Note: 2004 is incomplete as unsuccessful candidacies were tracked
> starting April 2005
>
> On 5/26/10 3:51 PM, Ryan Delaney wrote:
>> Pretty much. That's more or less why I quit the project.
>>
>> On Thu, Mar 25, 2010 at 1:51 PM, The Cunctator<cunctator(a)gmail.com> wrote:
>>
>>
>>> By all measures, en.wiki has been in decline for years as an active
>>> project.
>>> It's just the typical death by bureaucracy that most projects like this
>>> undergo.
>>>
>>> On Thu, Mar 25, 2010 at 4:45 PM, Kwan Ting Chan<ktc(a)ktchan.info> wrote:
>>>
>>>
>>>> WereSpielChequers wrote:
>>>>
>>>>
>>>>> What are the likely results of a dwindling number of admins, and a
>>>>> growing wikigeneration gap between admins and other editors?
>>>>>
>>>>>
>>>>>
>>>> Well, they're not dwindling since admin rights don't get taken away on
>>>> inactivity. ;-) But to the general question, because the standard
>>>>
>>> expected
>>>
>>>> of a candidate for RfA has gone up over the years?
>>>>
>>>> KTC
>>>>
>>>> --
>>>> Experience is a good school but the fees are high.
>>>> - Heinrich Heine
>>>>
>>>> _______________________________________________
>>>> WikiEN-l mailing list
>>>> WikiEN-l(a)lists.wikimedia.org
>>>> To unsubscribe from this mailing list, visit:
>>>> https://lists.wikimedia.org/mailman/listinfo/wikien-l
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> WikiEN-l mailing list
>>> WikiEN-l(a)lists.wikimedia.org
>>> To unsubscribe from this mailing list, visit:
>>> https://lists.wikimedia.org/mailman/listinfo/wikien-l
>>>
>>>
>> _______________________________________________
>> WikiEN-l mailing list
>> WikiEN-l(a)lists.wikimedia.org
>> To unsubscribe from this mailing list, visit:
>> https://lists.wikimedia.org/mailman/listinfo/wikien-l
>>
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 26 May 2010 19:03:40 -0500
> From: MuZemike <muzemike(a)gmail.com>
> Subject: Re: [WikiEN-l] declining numbers of EN wiki admins
> To: English Wikipedia <wikien-l(a)lists.wikimedia.org>
> Message-ID: <4BFDB6DC.6020407(a)gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> We need to remember that correlation does not imply causation here,
> which I think is what David is slightly hinting at. There are probably
> many other factors in admin decline as well, including increased
> popularity of Wikipedia (which leads and has led to a lot more problems,
> good and bad), increased questioning of literally every decision made,
> increased criticism (general and specific) of adminship and
> administrators, higher RfA standards, etc. The list goes on.
>
> -MuZemike
>
> On 5/26/2010 6:34 PM, David Goodman wrote:
>> Are you saying that a _declining_ number of administrators means a
>> _growth_ in bureaucracy? It would normally mean the opposite, either
>> a loss of control, or that the ordinary members were taking the
>> function upon themselves. What I see is a greater degree of control
>> and uniformity, not driven by those in formal positions of authority.
>>
>> On Wed, May 26, 2010 at 6:51 PM, Ryan Delaney<ryan.delaney(a)gmail.com> wrote:
>>
>>> Pretty much. That's more or less why I quit the project.
>>>
>>> On Thu, Mar 25, 2010 at 1:51 PM, The Cunctator<cunctator(a)gmail.com> wrote:
>>>
>>>
>>>> By all measures, en.wiki has been in decline for years as an active
>>>> project.
>>>> It's just the typical death by bureaucracy that most projects like this
>>>> undergo.
>>>>
>>>> On Thu, Mar 25, 2010 at 4:45 PM, Kwan Ting Chan<ktc(a)ktchan.info> wrote:
>>>>
>>>>
>>>>> WereSpielChequers wrote:
>>>>>
>>>>>
>>>>>> What are the likely results of a dwindling number of admins, and a
>>>>>> growing wikigeneration gap between admins and other editors?
>>>>>>
>>>>>>
>>>>>>
>>>>> Well, they're not dwindling since admin rights don't get taken away on
>>>>> inactivity. ;-) But to the general question, because the standard
>>>>>
>>>> expected
>>>>
>>>>> of a candidate for RfA has gone up over the years?
>>>>>
>>>>> KTC
>>>>>
>>>>> --
>>>>> Experience is a good school but the fees are high.
>>>>> - Heinrich Heine
>>>>>
Hi everyone,
After much debate, we've settled on a name for the English Wikipedia
implementation of FlaggedRevs: "Pending Changes". This is a slight
variation on one of the finalists ("Pending Revisions") which has the
benefit of using the less jargony term "changes" instead of "revisions".
The MediaWiki extension will continue to be named "FlaggedRevs", but the
greatly simplified subset of functionality that editors and readers on
en.wikipedia.org will see will be referred to as "Pending Changes" in the
user interface, help documentation, and other places that we'll talk about
this feature for non-developers working on English Wikipedia.
Thanks everyone for weighing in! We'll be updating the message strings on
flaggedrevs.labs to reflect the new name:
http://flaggedrevs.labs.wikimedia.org/wiki/Wikimedia:Message_updates
Rob
On Wed, May 26, 2010 at 3:27 PM, Rob Lanphier <robla(a)wikimedia.org> wrote:
> Hi everyone,
>
> It looks like the discussion on the name is dying down, so I'd like to
> summarize what I think we've heard here:
> 1. There's no clear favorite out there. In addition to the two ideas we
> put forward ("Pending Revisions" and "Double Check"), there's been quite a
> bit of discussion around alternatives, for example: "Revision Review" and
> "Pending Edits".
> 2. There's are still some that aren't comfortable changing the name away
> from "Flagged Protection", but that doesn't appear to be a widely held view.
> 3. Some people like "Double Check", but some people dislike it a lot. The
> people who like it seem to be comfortable with the colloquial use of it,
> whereas the people that dislike it don't like the lack of precision and the
> possible confusion created by the use of the word "double".
> 4. "Pending Revisions" seems to be something most people would settle for.
> It's probably not the hands down favorite of too many people, but it
> doesn't seem to provoke the same dislike that "Double Check" does.
> 5. "Pending Edits" is a simplification of "Pending Revisions" that seems
> to have some support, as it replaces the jargony "Revision" with the easier
> "Edits"
> 6. "Hyperion Frobnosticating Endoswitch" seems to have gathered a cult
> following. Yes, we have a sense of humor. No, we're not going there. :-)
>
> A little background as to where we're at. "Double Check" had an
> enthusiastic following at the WMF office, but we're not inclined to push
> that one if it's going to be a fight (it's far from the unanimous choice at
> WMF anyway). "Revision Review" seems to be heading a bit too far into
> jargon land for our comfort. "Pending Revisions" is the compromise that
> seems to stand up to scrutiny. A variation such as "Pending Edits" or
> "Pending Changes" also seems acceptable to us.
>
> That's where we stand now. If you haven't spoken up yet, now is the time,
> since we're only a couple of days from making a final decision on this.
> Please weigh in here:
>
> http://en.wikipedia.org/wiki/Wikipedia_talk:Flagged_protection_and_patrolle…
>
> Thanks
> Rob
>
>
> Date: Wed, 26 May 2010 20:04:43 -0400
> From: Gwern Branwen <gwern0(a)gmail.com>
> Subject: Re: [WikiEN-l] declining numbers of EN wiki admins
> To: English Wikipedia <wikien-l(a)lists.wikimedia.org>
> Message-ID:
> <AANLkTilwKLP_WoGqQAW9dZZDqGukSWbCUT-RtzvBVV0u(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Wed, May 26, 2010 at 7:34 PM, David Goodman <dgoodmanny(a)gmail.com>
> wrote:
> > Are you saying that a _declining_ number of administrators means a
> > _growth_ in bureaucracy? ?It would normally mean the opposite, either
> > a loss of control, or that the ordinary members were taking the
> > function upon themselves. ?What I see is a greater degree of control
> > and uniformity, not driven by those in formal positions of authority.
>
> If you assume that administrators are identical to the bureaucracy or
> some non-shrinking proportion thereof, then that does look like a
> falsehood.
>
> If you assume that administrators reflect rather the number of
> committed long-term contributors, and their numbers wax and wane
> pretty independently of the need for administrators, then that makes
> sense. Little kills enthusiasm and participation as surely as
> bureaucracy. Why are so few even trying for adminship?
>
My guess is that it's because the bureaucracy has become too intimidating.
I suspect many editors do not want to commit the time and effort to learning
it all.
So I decided to fill in a red link I saw on the community portal:
[[List of Rivers of Egypt]]. I started creating the article, then
reached the amusing realisation that perhaps there is only one. Yep,
that one.
So, do we just have a pathetically short list? It seems for
completeness etc, that would be the right thing to do.
http://en.wikipedia.org/wiki/List_of_rivers_of_Egypt
Steve
As requested, here's the weekly Flagged Protection update.
The loose-end tidying and rollout prep proceeds apace. This week's
rollout prep includes preparing for an emergency rollback, something
that we don't expect will be necessary but for which we nonetheless need
to be ready.
We've been working diligently on the text, which is a key component of
the user interface. You can see the enwiki-specific parts of that here:
http://flaggedrevs.labs.wikimedia.org/wiki/Wikimedia:Message_updates
As part of that text work, we are also, as readers of these lists know,
considering changing the name of the English Wikipedia deployment from
Flagged Protection to something more easily comprehended by the general
public. If you'd like to weigh in on the many options, here's the place:
http://en.wikipedia.org/wiki/Wikipedia_talk:Flagged_protection_and_patrolle…
The main thing standing between us and being able to give a release date
is some trouble with part of the UI. If you're a HTML & CSS guru, we
could use your help:
http://lists.wikimedia.org/pipermail/wikitech-l/2010-May/047916.html
We also fixed a bug this week. Thanks to Sonia, who found and reported
that bug. Want to emulate her? Start here:
http://flaggedrevs.labs.wikimedia.org/wiki/Main_Page
To see the upcoming work, it's listed in our tracker, under Current and
Backlog:
http://www.pivotaltracker.com/projects/46157
We expect to release to labs again next week, and each week thereafter
until this goes live on the English Wikipedia.
William
Hi everyone,
As William alluded to, a bunch of us have been studying the user interface
for Flagged Protections and figuring out how to make it more intuitive.
In trying to solve the user interface problems as well as generally figuring
out how we're going to talk about this feature to the world at large, it
became clear that the name "Flagged Protections" doesn't adequately describe
the technology as it looks to readers and editors. It's a tough name to work
with. This iteration of the technology is very different from the German
implementation, and there's no "flagging" in the proposed configuration.
Additionally, "protection" in our world implies "no editing" whereas this
feature actually opens up pages currently protected so that everyone can
edit.
So, we would like to make a change to the name of the "Flagged Protections"
feature prior to deploying it to en.wikipedia.org. Under the hood, we would
still be using the "FlaggedRevs" extension (no change there), but the name
that we talk about in the user-visible portions of the site and
documentation would be something new.
Here were some criteria we're using to find a name:
- Must not introduce obsolete terminology (e.g. there's no "flagging" in
our proposed deployment)
- Terminology should be consistent with terms we want to use in the user
interface
- Must not make too strong of a statement of quality/consensus or terms
that make us out as publishers approving content from the mountaintop
- Should not imply we're creating an elite new classes of users
- Should not convey a strong sense of restriction. The feature, as
proposed for the trial [1], is less restrictive than semi-protection
- Should not be too geeky/too technical/too jargony
- Should not be too slick/too cutesy. We're not doing this in the name of
creating glossy brochures with pictures of a conference room full of people
in formal business attire nodding with approval at a projection of a pie
chart - we just want a name that won't be confusing.
It turns out that filters out quite a few names (including "Flagged
Protection" among other things). Here's the alternatives that made the cut:
- "Pending Revisions" - this name is very consistent with what everyone
will see in many parts of the user interface, and what it will be used for
(i.e. providing a queue of pending revisions)
- "Double Check" - this was a late entrant, but has the distinct
advantage of clearly communicating what we envision this feature will be
used for (i.e. enforcing a double check from a very broad community).
A protracted debate on the name will likely delay the eventual launch on the
feature, so we're hoping we can have a quick, respectful discussion on the
merits of the different proposals so that we can make the change quickly and
move on. We really need to have a name fully locked down no later than
Friday, May 28. Please let us know your thoughts here:
http://en.wikipedia.org/wiki/Wikipedia_talk:Flagged_protection_and_patrolle…
We're in the process of working on a lot of terminology tweaks in the user
interface in anticipation of the launch. If you're interested in that detail
work, I'll post more information about that on wikitech-l (hopefully by
end-of-day Monday), as well as on the talk page above.
Rob
[1] - See the proposed configuration for trial phase:
http://en.wikipedia.org/wiki/Wikipedia_talk:Flagged_protection_and_patrolle…