Jump to content

Wikipedia:Village pump (idea lab)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Kingturtle (talk | contribs) at 14:20, 1 July 2015 (→Bureaucrats?: reply). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at Village pump (proposals). Try to be creative and positive when commenting on ideas.
Before creating a new section, please note:

Before commenting, note:

« Archives, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61


Require an edit summary for edits by IPs and non-autoconfirmed users?

Since it is considered good practice to provide edit summaries, would it be a good idea to require IPs and non-autoconfirmed users to supply an edit summary when making edits to the article namespace? This would help prevent misunderstandings and make it easier to patrol edits, and encourage using edit summaries in general. Currently, many new users/IPs do not use edit summaries, even when making constructive edits. Tony Z. Tan · talk 22:55, 12 April 2015 (UTC)[reply]

It's an attractive idea, but my experience with developers who are paid to put summaries on source code checkins is that there will always be some who won't give a meaningful edit summary. If you introduce a mechanism to force a summary, they'll enter a single '.'. If you put a filter in requiring at least six characters, they'll put 'aaaaaa'. If, after a long-running battle, you implement a mechanism that somehow requires a meaningful English sentence in the summary, you'll end up with abuse directed towards the admin who implemented the mechanism. You can lead a horse to water, but you can't make him drink. GoldenRing (talk) 06:11, 13 April 2015 (UTC)[reply]
I also think that this would end up being a deterent from users to start editing here - and the same users who don't know about edit summeries probably need their edits to get extra scrutiny. עוד מישהו Od Mishehu 04:14, 14 April 2015 (UTC)[reply]
Why limit it to "IPs and non-autoconfirmed users"? I think having the edit summary as a required field for all would serve a useful purpose. While some may 'game the system' with glib entries many others will be nudged to take notice and give thought. And as 'required fields' are fairly ubiquitous in interfaces on many sites I don't see it as any sort of surprising impediment to new editors. Some sort of 'what is this' icon/link/hover-text/pop-up/etc.—such as the present "Edit summary (Briefly describe your changes)"—should suffice to aid those who may be particularly naive.
Hmm, a pop-up message with a link to the talk page when the edit summary field character count gets maxed out might be a complementary feature as well ... --Kevjonesin (talk) 10:31, 3 May 2015 (UTC)[reply]
This is a Good Idea. Require something in the Edit summary. It would get editors in the habit of using it. I suggest adding the word below to Briefly describe your changes. BeenAroundAWhile (talk) 06:10, 22 May 2015 (UTC)[reply]
Requiring something in the edit summary has been suggested before. If it were compulsory, we'd see a lot of edit summaries like "dvk", "h,jkwqlu" or "dfjkbvdhgblak;", which would not be an improvement. As it is, we get a lot more edits these days with what is tagged as a "canned edit summary" - if you look at the last fifty edits that are so tagged, you'll find that the edit summary is probably one of four: "Added content"; "Added links"; "Fixed grammar"; "Fixed typo", but you'll also find that the actual change is something else. This one, for example, claims "Added links" - but no links were added or even altered. --Redrose64 (talk) 11:34, 22 May 2015 (UTC)[reply]
Edit summaries are optional, so blank edit summaries are a good way to spot suspicious edits. Forcing everyone to give edit summaries is a bad idea because it would make vandalism harder to spot. But if you come across a goodfaith editor who isn't using edit summaries then a quiet word can be helpful. ϢereSpielChequers 21:43, 10 June 2015 (UTC)[reply]

YouTube Wikiproject Proposal and How Bold can I be?

So I've got a proposal on the go for a YouTube Wikiproject (Not blatant advertising) and I'm wondering how bold can I be with such an endeavour. I want to create a Template header and WP: project space to get the infrastructure going and an audit of all the articles. While WP:BOLD is a policy I don't want to find someone getting upset for some unforeseen reason.

--- :D Derry Adama (talk) 23:37, 28 April 2015 (UTC)[reply]

  • I would consider that generally not a good idea. Very little of what goes on on YouTube is supported by Independent Reliable Sources (by Wikipedia standards, anyway), and pages on people's YouTube accounts are often deleted as not being notable or verifiable enough. Even linking to YouTube is generally discouraged for spam and copyright reasons (and it can't be used as a source anyway). There is a YouTube specific wiki on Wikia here which might be a better fit for documenting YouTube stuff. Andrew Lenahan - Starblind 23:37, 29 April 2015 (UTC)[reply]
  • See I am personally of the opposite view point. YouTube personalities far outstrip traditional media personalities in terms of viewership and many of them are notable. The creation of a WikiProject Youtube sounds great. Re: how forward. Wikipedia was built on being bold to my understanding. JTdaleTalk~
  • YouTube is generally not considered a reliable source, so it would depend on what the goal of the project is. If it is just intended to be a place where people can go and ask "is this video reliable" and the people there say "it's a CNN news report, so yes" or "it's some person's blog, so no" and if there is interest by enough community members to monitor such a thing, then I suppose I wouldn't object. I can't see any other potentially useful purpose for such a project. — {{U|Technical 13}} (e • t • c) 16:31, 14 May 2015 (UTC)[reply]
  • Might this be better as a subproject of Wikipedia:WikiProject Internet culture? Sam Walton (talk) 21:10, 29 May 2015 (UTC)[reply]
  • What about Dailymotion, Vimeo and the many other video sharing websites? --186.50.114.232 (talk) 19:41, 10 June 2015 (UTC)[reply]
  • as proposed I would advise against it, the project would continually be mired in debates about people who are only known on youtube and therefore not yet notable under our current rules. Better to start with an RFC on those rules. Better still if you are interested in youtube we coould really do with more youtube videos explaining how to do various things on Wikipedia. ϢereSpielChequers 22:11, 30 June 2015 (UTC)[reply]

Age restrictions

I think we should introduce age restrictions to Wikipedia and Wikimedia projects. Vandalism, unwise selections and childish, non-encyclopedic content popping up is the reason. So the new bit is not allowing under-teens create accounts, and all Wikipedians must have a proper account while editing instead of editing from IP adresses. Is this a good way to prevent vandalism on Wikipedia? --Corsicanwarrah (talk) 10:53, 27 May 2015 (UTC)[reply]

@Corsicanwarrah: Impossible to verify, and against policy. See foundation:Privacy policy and WP:ANONYMOUS. --Redrose64 (talk) 11:56, 27 May 2015 (UTC)[reply]
How would you implement that? In order to validate the editor's age you would need to review some kind of proof of date of birth before allowing the account to be created. So even if it was a good idea I don't see it being feasible to operate. QuiteUnusual (talk) 11:58, 27 May 2015 (UTC)[reply]
Wikipedia is the encyclopedia that anyone can edit. That is the most important principle. Most minors are here are constructive. Some have even written hundreds of high-quality articles and/or gained administrator status. Furthermore, one good editor is enough of a net positive to balance out hundreds of vandals. You also couldn't prove it without forcing people to prove their identity. We know how well that works. So, no. An absolutely terrible way to prevent vandalism. Like chopping off an arm in response to a cut on one finger. --Jakob (talk) aka Jakec 12:05, 27 May 2015 (UTC)[reply]
Outing minors is absolutely unacceptable and in fact presents a potential threat to their security. Banning IP editing has been proposed many times, it will never fly as it violates the fundamental "anyone can edit" principle. Roger (Dodger67) (talk) 19:40, 29 May 2015 (UTC)[reply]
With the rise of smartphones and similar devices which are impractical to edit on Wikipedia has become much more of a broadcast media for children and teenagers. We probably still have some legal minors who edit, but far fewer than a decade ago, and we now have computer programs that remove most vandalism. So even less need to restrict minors than there used to be.
As for IP editing; Assuming the theories are true that most vandals do the minimum necessary to do their vandalism, that many perhaps most of our editors are recruited via IP editing, and that restricting IP editing would lose us some very privacy conscious editors; Banning IP editing would have two drawbacks, some goodfaith edits will be lost, and if vandals continue to do the minimum necessary to do their vandalism, we will have the same amount of vandalism but it will be slightly harder to spot. I'm not aware of any advantages to losing IP editing, and they'd need to be big to offset those disadvantages. ϢereSpielChequers 13:52, 9 June 2015 (UTC)[reply]
Also, it should be noted that although anonymous schoolchildren are responsible for some vandalism, there are sophisticated vandals who spend large amounts of time finding ways to vandalize Wikipedia in the most damaging ways possible, or without being noticed. These are likely not children (if they are, they're incredibly intelligent...). Secondly, prohibiting IPs from editing is a perennial proposal, and will almost surely never gain traction amongst the community. Finally, verifying identities and ages would very much complicate things on Wikipedia, and would, overall, probably end up causing more inconvenience than what it was supposed to prevent. There is actually a a website that does this, and has not produced good results at all. (17,000 articles vs. Wikipedia's almost 4.9 million.) It should also be noted that their articles are not of exceptionally high quality, even though they're supposed to be, and some well-known topics have either no article at all or a very short one. --Biblioworm 15:46, 9 June 2015 (UTC)[reply]

More stringent requirements on admin activity

There has recently been discussion of admins who perform a very low number of edits each year and thus retain their admin tools due to the inactivity desysopping requirement being zero edits or actions for one year. Additionally, primarily sparked by the recent desysopping of AntonioMartin, there has been discussion of those admins who received their tools in the early years of Wikipedia when adminship was viewed much more lightly than it is now. I'd like to request opinions on a number of related aspects of these two things.

  1. Should the inactivity desysopping requirement be changed? If so, what level of activity would be suitable? Some have argued that zero edits for a year is too relaxed; an admin can make one edit per year and retain their admin tools indefinitely.
  2. Should a review of those administrators who were elected in the very early years of Wikipedia take place? This could raise awareness of other admins like AntonioMartin who are not using their tools in line with current policy. Issues with this include it turning into a drama-fest and there potentially not being a way to actually desysop any admins who are deemed to not be acting the way they should.

This isn't an RfC and isn't a discussion for assessing new policy, rather I'd like to have a discussion about these points with the view of taking something actionable to WP:VPP for an official RfC once we've ironed out the details. Discussions on this topic are worth a read and can be found here, here, and here. Sam Walton (talk) 21:21, 27 May 2015 (UTC)[reply]

Inserting: WP:AN#On the brink of collapse and other discussions this year at WP:VPR seem relevant. Whenever all of this turns into one or more RfCs, it will be perfectly okay but not necessary to repeat any or all of this in those RfCs, we'll be reading everything relevant and taking it all into account. Just a reminder ... the goal of these RfCs will be to address everyone's concerns, not to decide who wins and who loses. To do that, we'll need to know what the concerns are, so guys, when possible, don't just tell us what solutions you favor, tell us what problem you're trying to solve ... even if it's just a possible problem, even if you're not sure. Of course ... even better is data that supports a claim, or an argument or position that's acceptable to a wide range of voters. - Dank (push to talk) 14:41, 29 May 2015 (UTC)[reply]
In my opinion, yes, the requirement should be changed. As you say, right now an admin can keep the tools indefinitely as long as they make a single edit a year. Not even a single admin action—a single edit. In my opinion, the "at least one edit or action" could safely be upped to "at least one administrative action or a substantial number of edits", be that substantial number 50 or 100 or whatever. Possibly even "at least 10 actions or a substantial number of edits". If they're not active in their role as administrator, then let them at least be active in their role as editor if they want to keep the mop. I can imagine some good reasons for an active editor-with-tools to want to keep the tools even if they barely use them, as well as good reasons for an admin to take a step back from administrative actions for a while without immediately giving up the mop. I can't quite imagine any good reasons to hang onto the mop for someone who makes less edits in a year than ClueBot NG makes in a minute.
As to the review-of-administrators, I don't really have a clear opinion of that at this moment. AddWittyNameHere (talk) 21:46, 27 May 2015 (UTC)[reply]
I just saw the post elsewhere directing people here, so I'll post here. I read Beeblebrox's comment and thought... so, the people in question rarely use admin tools and make the occasional bad call but don't make a habit of it. What was the problem again?
I am arguably biased, as a recently returned admin after long inactivity, but this feels like a "bad cases make bad law" situation. Nobody's yet offered up any other examples of "legacy" admins demonstrating plainly unsuitable behavior, but we have seen some evidence that RfA date is not correlated to desysop-worthy recent behavior. From my perspective, the degree to which Wikipedia has changed over time is usually overstated, but one thing that definitely hasn't changed is the tendency to react to an isolated bad situation with "We should have more rules and processes about that!" Opabinia regalis (talk) 21:53, 27 May 2015 (UTC)[reply]
  • Anyone proposing a requirement in terms of the number of logged admin actions ought to have a look at some statistics. Here are some stats for the number of admin actions over the last year. As you can see we have a lot of admins who rarely use the tools - a requirement of 10 actions per year would eliminate about half of our admins. Hut 8.5 22:02, 27 May 2015 (UTC)[reply]
Serious, non-snarky question here: If they aren't using their tools, why do they need to keep Admin status? What's the benefit to the project or the community? --IJBall (talk) 22:10, 27 May 2015 (UTC)[reply]
I'm presuming that was directed at my suggestion above, Hut 8.5? If so, I am aware of that, yes. Which is why I suggested 10 admin actions or a substantial-to-be-further-determined number of edits—and it was a secondary suggestion to one that required just one admin action or said to-be-determined number of edits. AddWittyNameHere (talk) 22:29, 27 May 2015 (UTC)[reply]
Not directed at you specifically, I posted that link at one of the discussions mentioned above and was directed here. Hut 8.5 06:50, 28 May 2015 (UTC)[reply]
  • Under the principle that "Admin privileges should not be a lifetime sinecure", yes to Question #1. My personally preferred standard would be the entirely reasonable, "use of Admin tools once a month" which works out to "use of Admin tools 30 12 (stupid simple math! [grumble, grumble...] ) times (or more) per year" to stay "active" status. Anything less than that, and I don't think an Admin is "active" enough to be all that useful, and it should be time to look for new candidates. And current rules can still apply – a simple request for "restoration of Admin" privileges for Admins labeled "inactive" will suffice to get Admin status back. That all seems entirely reasonable to me.... I'm also in favor of Question #2, but such a review should be non-invasive, and should include some of the suggestions that have been made elsewhere, in the topics linked to above in Sam's original post. --IJBall (talk) 22:08, 27 May 2015 (UTC)[reply]
I'm confused. Once per month = 30+ times per year? Do you mean 12+ times per year, or do I misunderstand something? Nyttend (talk) 22:26, 27 May 2015 (UTC)[reply]
(site crash conflict)Dang, Nyttend, you aren't supposed to catch my stupid math errors so easily! ...Fixing the above – and I think the actual "cutoff" level should probably be about 10–20 Admin tool uses per year. --IJBall (talk) 23:03, 27 May 2015 (UTC)[reply]
:-) I simply wondered if I'd misunderstood something, if you were somehow proposing something in addition than the one per month. Nyttend (talk) 23:06, 27 May 2015 (UTC)[reply]
More stats!! just to put some numbers in to this discussion – It's about what I figured: Wikipedia:List of administrators claims there are 599 active Admins (as of today), and based on this there are 591 Admins that have logged 12 or more Admin tool uses in the last year (May 27, 2014 – May 27, 2015), so that works out about perfectly. (Only 544 Admins used their tools 20 or more times over that year.) Other stats: 615 Admins have used their tools 10 times or more over the same period; 703 Admins used tools 5 times or more over the year; and 914 Admins used tools at least once in that time. And, yes – 471 Admins didn't use their tools at all over the past year. For a total of 1385 who are still logged as Admins (as of today). Actually, it's less that 1385, as anyone in the table who's missing an "A" next to their name is no longer an Admin, as of May 27, 2015... --IJBall (talk) 07:19, 28 May 2015 (UTC)[reply]
  • I'm not sure I see the point in making the activity requirement stricter. After all, big changes like this always end up causing boatloads of drama, and I really don't understand how any great amounts of harm could come about as a result of admins not using their accounts. --Biblioworm 22:29, 27 May 2015 (UTC)[reply]
  • Comment I think this is a solution looking for a problem. It has not been demonstrated that admin inactivity causes problems, until that happens this all seems pointless. As for the second question, the big question would be when the date would be called, but again it seems a bit pointless, with most "bad admins" having been admitted more recently. --Jules (Mrjulesd) 22:41, 27 May 2015 (UTC)[reply]
It is a problem because any time anyone quotes the "there are 600 active Admins" number, it's completely phony. As this discussion has demonstrated, the real core of "active Admins" is probably 200–300 currently, and they're doing almost all of the work... Which gets back to the other point – Admin status is a privilege not a "right", and if an Admin isn't using their tools to actively improve the project (not including straight-forward editing here, obviously – just Admin tools), there's no good argument that they should keep Admin status (esp. when they can make a simple request to get them back if they decide to become "active" again). Again, "Admin privileges should not be a lifetime sinecure". --IJBall (talk) 22:50, 27 May 2015 (UTC)[reply]
But you have not really demonstrated a real problem with admin inactivity. And if they can easily regain their tools why remove them in the first place? --Jules (Mrjulesd) 23:14, 27 May 2015 (UTC)[reply]
It's a pretty simple difference of opinion here – you think Admin status should remain in perpetuity unless some "defect in duty" arises; I think people should only have Admin status if they're going to (actively) use their tools for the betterment of the project. I don't think we're going to see eye-to-eye on this. But the "problem" on my end is that I don't see why someone should have "greater" status than the bulk of other editors and have unfettered access to potentially "dangerous" tools that they're not even using... --IJBall (talk) 23:20, 27 May 2015 (UTC)[reply]
Philosophically, I think admin status ought to be about trust. People who are reasonably believed to be trustworthy should have access to the tools to make this place better, whether or not they use them regularly. On the other hand, it should also be easier to remove access to people who violate the community's trust. That said, I also think we should appoint far more admins than we do (perhaps another 1000 from the current pool of active editors), so ultimately I'm more interested in encouraging more access to the tools rather than less. Dragons flight (talk) 00:34, 28 May 2015 (UTC)[reply]
There are 471 "active" admins who've done 0 admin actions. Why should they have the tools if they aren't using them? Liz Read! Talk! 01:04, 28 May 2015 (UTC)[reply]
Clarification: There are 471 "active" Admins who haven't used any tools in the last month year (in the other thread, they said the stats covered a year). That's an important distinction. (But I agree with your general point...) --IJBall (talk) 01:40, 28 May 2015 (UTC)[reply]
  • The possible elephant in the room is whether an enhanced activity requirement gets the less active administrators to engage and make more good administrative actions, or whether it encourages a quick burst of activity and bad administrative decisions. That said, if there is going to be any increase in the activity requirements, it needs to be a substantial number, so there's enough actions carried out to determine how good or bad each administrator actually is. 5, 12 or even 30 actions isn't really enough to make rational judgements on ability. Finally, I'd also say that there needs to be an easier way for administrators to be kept up to date with changes to policies, administrative guidelines, arbitration enforcement, discretionary sanctions etc. I'm 140 on the list and I'm fairly regularly left looking to see why the options for blocking, deleting etc have changed, or what policy change has been tweaked when reading through unblock requests or deletion reviews. Nick (talk) 22:59, 27 May 2015 (UTC)[reply]
  • In one of the other discussions, someone pointed out that existing processes (ANI, ArbCom) can catch those who are making a large number of admin actions, because they are statistically more likely to be called out on one of them if they are a bad admin. This new process should be designed to evaluate the admins who are not using the tools or using them both poorly and infrequently. Gamaliel (talk) 23:38, 27 May 2015 (UTC)[reply]
  • 7@Samwalton9:, with this proposal, do you intend to make such adminship removal permanent (i.e. they cannot re-request without an RfA) or temporary (i.e. the current system)? I ask because I'm not sure how the latter would work here; would the now-former admin have to be active again for, say, 2 months before requesting tools back? StringTheory11 (t • c) 00:40, 28 May 2015 (UTC)[reply]
    • Honestly, I'm not personally certain, I saw a few discussions going on about this, shared some of my own views, and agreed we needed a centralised discussion about this. I think that if, say, the community decides that one admin action per year is required or an admin is desysopped, it would make sense to me that they can still just re-request unless they're then inactive for three years, per the current wording of WP:INACTIVITY. I don't personally see a need for them to be active for some months before re-requesting, I think this would introduce an unnecessary barrier. Sam Walton (talk) 17:52, 28 May 2015 (UTC)[reply]
  • FWIW, I also agree with that – I'd keep the current systems that Admins deemed "inactive" (whatever the eventual cutoff ends up being – and, FTR, I still think the cutoff should be 10 or 12 Admin actions over a year) can simply request "active" status again. I don't see any need for "inactive" Admins to have to go through another RfA just to get tool backs (separate from the unrelated "Term Limits" proposal below...) unless they actually "resigned" their Admin status like Opabinia regalis did. --IJBall (talk) 19:41, 28 May 2015 (UTC)[reply]
  • I find I am having difficulty discussing this. I am also somewhat biased, for a number of reasons. As a result this is an issue that I have made a particular point of keeping an eye on and calling out problems when I see them. Sometimes they throw a fit and tell me what a whelp I am compared to them. Sometimes they undo their actions, and pledge not to repeat them. Or anything in between. And I don't wish to "name and shame" any of them, thus the difficulty in expressing how often I have come across abuses by old-school admins. There are new admins who do such things too, but as has been mentioned they also have a greater tendency to call tooo much attention to themselves.
I'm number 142 on that list, and it includes most of last year, when I was on arbcom and severely curtailed my use of admin tools. That isn't good. But these type of chamges are so hard to get through anymore, I really think we should start small and work the problem from both ends. Like little, incremental changes at RFA, I mean like really small and we'll see if the world ends or not. Beeblebrox (talk) 02:38, 28 May 2015 (UTC)[reply]
  • This feels a bit like a solution to the wrong problem. At the moment, admins desysopped for inactivity can regain the tools automatically upon request until three years of inactivity has passed. If you set a new requirement - such as must perform 10 edits - all they need to do is come back, ask for the tools, and they're in exactly the same place they would have been if they'd been desysopped for no edits. I presume the problem that you want to fix relates to lengthy inactivity, where the admin has to go through RfA to get the tools back, rather than simply inactivity, which is the 0 edits in a year desysop. - Bilby (talk) 07:36, 28 May 2015 (UTC)[reply]
  • I think WP should be like Meta, in that any admin who has not performed X number of admin actions in any given year should be automatically de-sysopped via bot. I also think any admin who makes less than a very substantial number of edits per any given 12-month period should be automatically de-sysopped by bot. Either someone cares about the project and keeps up with it, or they don't. There's absolutely no reason on earth to have the latter group running around with admin tools, and there's every reason not to. Softlavender (talk) 09:48, 28 May 2015 (UTC)[reply]
Sincerely, what are the reasons to remove rights from rarely active accounts? Of current admins, roughly 70% edited less than 100 times last month and roughly 50% edited fewer than 10 times last month. That sounds bad, but a large fraction of admins have been sparsely active for years without causing much harm. There are a few examples of bad behavior and hundreds of examples of basically nothing bad happening. However, there are also examples of admins returning from large gaps and being super active. For example, current #9 on the activity list took a 3-year break, #13 had a 2-year break, and #25 had a 5-year period of low activity. Creating barriers for those editors might have driven off some very useful admins today. Dragons flight (talk) 11:00, 28 May 2015 (UTC)[reply]
The flip-side to that, which I find more compelling, is why should inactive or rarely-active Admin accounts retain their "special status" as Admins? I really do get the feeling that some around here think that Admin status should be a "lifetime" appointment, and if I had to guess I'd expect that a substantial portion of the community would not agree with that view. --IJBall (talk) 19:41, 28 May 2015 (UTC)[reply]
No actual solution here, but some thoughts that have been rattling around my head: Activity requirements for advanced user rights is one of those things that requires us to either choose one of two bad options, or to have someone(s) human personally making decisions on each case, which is also a pretty bad option in realistic terms. In pure mathematical terms, it is of more use to have someone not-particularly-active take a handful of actions per year - assuming those actions are correct - than to have them taking none. Especially if you factor a number of not-particularly-active people into that equation, you'll find that actions taken collectively by not-very-actives still add up to a notable proportion of all actions taken. I ran the numbers recently for oversight actions, and if memory serves it was something like 30% of actions being taken by the long tail of people who, in any given time period, appeared to be doing almost nothing; I'm going to go out on a limb and assume admin actions have similarly significant chunks done by less-active admins. Objectively, that's a large chunk of work you don't want to lose by de-bitting those people. On the other hand, we have no way of knowing whether that long tail of people is keeping up with community discussions - it's very easy to, say, delete a page or two a year that you happen to encounter, in entirely good faith, without noticing that policy has changed around you.

So the initial choice would seem to be "lose good work done slowly" vs "keep poor work done under the radar"; in picking either of those, you'd be sweeping up a number of people doing the opposite as well. The only way I can think of to balance those is to have someone(s) individually looking at each privileged user's situation, to judge their competence. Not just a "if you see a problem, bring it to Arbcom", but a body that would be pro-actively analyzing admin logs and noticeboard discussions and judging whether a) the actions were, on the whole, reasonable, and b) whether the user participated enough in both action and discussion to evince competence with current policy. And that would be...let's just call it an extremely heavyweight process, at best. Not only in human-hours consumed, but in selecting those qualified to make the decisions, and selecting enough of those people to be able to check every, or at least a representative sample of, logged action. I'm not sure we have enough people left at that activity level to be both examiners and examined. Which, I guess, brings us back to having to choose between good work done slowly, including occasional not-good work, or no work done in that group, including good work. A fluffernutter is a sandwich! (talk) 06:42, 29 May 2015 (UTC)[reply]

To answer Dragons flight (Sincerely, what are the reasons to remove rights from rarely active accounts?), I've seen admins who are so sporadic they can't even take responsibility for the random appearances + admin actions they make, after which they disappear for days, weeks, or months. I've seen admins who return after several years and have no clue what WP is now like or what the protocols. policies, tools, and best practices are. And so on and so on. Either one believes in and supports the project and is up to speed, or one is not. All of the other wiki parts (meta, commons, etc.) have this automated de-sysopping when an account has made few admin actions per 12-month period. Softlavender (talk) 06:55, 29 May 2015 (UTC)[reply]
I have a somewhat different view to answer the same question – basically Admin tools are "special rights" that are granted by the community to specific editors to do specific (special) tasks on the project. The "granted by the community" part is important because, ultimately, Admins serve at the pleasure of the community (ArbCom handles this for the community, but they're supposed to represent us). If users with Admin "rights" are then no longer performing those tasks for the community, they are no longer doing the things they were given the special tools for in the first place, and thus should not keep those "special rights". I get the impression that some think that Admin privileges are more akin to a "very special gift" given out to the best and brightest editors on Wiki, like a prize, and it shouldn't be taken away short of malfeasance. That's not what it's about – certain editors are promoted to do very specific special jobs, and if they are no longer doing those jobs, then they should lose the tools and revert back to being just "regular old editors". --IJBall (talk) 07:15, 29 May 2015 (UTC)[reply]
  • I came here expecting to say that even a single good admin action a year to keep the tools is better than no admin action, and that "number of logged edits" is a very poor metric that doesn't adequately cover what an admin does (since not performing an action still requires judgement, but doesn't inflate your "score"). But then I looked at that chart, and it blows my mind that someone like myself, who is hardly prolific, is comfortably in the top 250 based on number of actions performed over the past year. I'd definitely be comfortable with a minimum activity requirement of say 100 actions a year, with a caveat that anyone just under the limit should have their contributions scrutinised and any administrative activity that is not logged considered before making a call to desysop. Lankiveil (speak to me) 10:36, 28 May 2015 (UTC).[reply]
  • How about at least ten admin actions per year, or else they get de-adminned? Sounds like a good call, since that'll get rid of the half of the admins that don't need their tools. Admin actions don't need to be blocks, protects, deletes, etc.; it can also include looking into hidden revisions or editing protected pages. Epic Genius (talk) ± 17:30, 28 May 2015 (UTC)[reply]
  • I would think that 100 logged admin actions per year would demonstrate a need for the tools and give us a history by which to judge the admin. Currently, someone who makes only a few logged admin actions per year can easily escape scrutiny even if every one of the actions is poor. Failing that, a minimum of ten logged actions per year would get rid of most of the hat collectors. It's frustrating to see a list 1000+ admins and know that only a fraction of them can actually be contacted for assistance. NinjaRobotPirate (talk) 19:00, 28 May 2015 (UTC)[reply]
  • It seems to me that inactive admins aren't causing a problem while they are not editing, really, but a possible problem may occur if an admin who has edited only rarely or not at all for some time becomes active again without realizing that some policies and procedures have changed. My suggestion is this: (1) a log page could be created (unless it already exists) on which substantive changes to policies and guidelines are listed by date, with links to the appropriate pages. (2) Once a year, or right away if a big change happens, admins could receive an automated boilerplate message on their talk pages, reminding them to check the log for the latest changes before performing admin actions. Admins returning after a period of absence would find this on their talk pages, and hopefully take a peek at what's new before resuming admin activity.—Anne Delong (talk) 09:44, 29 May 2015 (UTC)[reply]
  • There has been a good deal of discussion, but what I am not seeing is what problem this is intended to solve. Resolute 19:02, 30 May 2015 (UTC)[reply]


Term limits?

This is an idea I generally don't support in either the real world or WP, but if done right it could be the right solution here. Something like this:

  • Pass RFA, you are an admin for ten years unless desysopped before then through other means
  • Whatever activity standards the project maintains still apply
  • You're not fired after ten years, but you will need to go back and run at RFA again.
  • Mass messaging, a bot or some other notification process will ensure that all admins who are approaching said deadline will be notified on their talk page, and possibly by email as well, beginning six months before the deadline, which will open the period in which they may run for a second term at their convenience, and they will be notified at least two more times before they are desysopped, and once again when it is done.
  • Failing to re-apply during the prescribed period in no way prevents anyone from running again whwnever they choose, but there will be no automatic resysopping if it is past the deadline.

Or something like that.

I'm putting this in it's own subsection because it is not an alternate proposal and is totally compatible with the current process that desyspos for simple inactivity. This would simply be a second set of requirements, like a performance review after ten years. We can determine different thresholds for the success or failure of reconfirmation RFAs if needed. Beeblebrox (talk) 02:22, 28 May 2015 (UTC)[reply]

I think this puts good admins at risk of being subject to grudge voting based on past hard decisions they have made that people merely disagree with. A reconfirmation RFA would be particularly vulnerable to it, as presumably it would still have the same 70% or higher consensus threshold. RFA has a long history of oppose voting based on disagreement with the candidate, without regard for whether the candidate is trustworthy and willing to abide and enforce policy and consensus they happen to disagree with. I think it would be better if the threshold was either 50%, or even requiring a 70% consensus on the side of desysoping. If a particular admin is really a big enough problem to justify desysoping, we should be able to form a consensus to that effect. Monty845 02:56, 28 May 2015 (UTC)[reply]
@Beeblebrox: I would suggest calling it something other than term limits. It can confuse us Americans, as in American politics, term limits are limits on the number of terms someone can serve, not a duration limit on a particular term. Calling it something like "10 year terms" would avoid that confusion. Monty845 03:02, 28 May 2015 (UTC) [reply]
I think this puts good admins at risk of being subject to grudge voting based on past hard decisions they have made that people merely disagree with. You said it. No way I would gotten involved with Gamergate and other controversial issues I tackled during my tenth admin year if I had to stand for RFA again. We have few active admins as it is, let's not make it harder for them. The problem is barely active ones, leave the active ones alone. Gamaliel (talk) 03:05, 28 May 2015 (UTC)[reply]
Make it "5 years" instead of 10 (and add in some of Monty's points), and I'd agree with all of this. --IJBall (talk) 02:59, 28 May 2015 (UTC)[reply]
Only about 200 of the current admins were appointed in the last 5 years. Dragons flight (talk) 04:21, 28 May 2015 (UTC)[reply]
Were this ever instituted (which, let's face it, is doubtful...), I'd guess it'd be "grandfathered in" in such a way that new Admins would start with a new 5-year clock, and current Admins would... well, I don't know, but I doubt it'd be structured in such a way that 1000 Admins would all "come due" for reappointment RfA's at the same time. --IJBall (talk) 05:49, 28 May 2015 (UTC)[reply]

Re: "I think this puts good admins at risk of being subject to grudge voting based on past hard decisions they have made that people merely disagree with" I can only wonder why an admin should be protected from this but not an editor who does mediation at WP:DRN or even joins discussions at ANI and later runs for admin. Even editors who post a lot of AfDs or warn/revert/report a lot of spammers and vandals collect enemies, but they get none of the special protection that is being suggested for administrators here.

This gets us back to the basic problem that to pass an RfA one should spend a year or two engaging in pretty much nothing but content creation in noncontroversial areas, withdrawing and moving on to another page whenever anyone shows any sings of disagreement or opposition. In other words, prove that you are the kind of person who pretty much has zero interest in doing the sort of work administrators are asked to do. --Guy Macon (talk) 05:47, 28 May 2015 (UTC)[reply]

  • Blocking vandals and spammers might create enemies but not of the kinds that matter. A vandal or spammer doesn't know much about the internal processes of Wikipedia. They don't know what RfA is, probably wouldn't participate if they did, and nobody is going to take them seriously there. The areas which would be hit are those which involve annoying experienced editors, such as arbitration enforcement, closing complex or heated discussions, and anything which involves blocking experienced editors (especially if they have lots of friends). These are already the nastiest kinds of admin work and few people do them already. Some of this might potentially affect non-admin candidates at RfA as well, but it's very unlikely that such a person has been around for ten years. Hut 8.5 07:05, 28 May 2015 (UTC)[reply]
  • I definitely think there should be term limits, and admins should re-apply or be re-assessed after 5 years. I've seen too much admin abuse and also lording it over other people simply because they are admins; I've also seen admins who are so sporadic they can't even take responsibility for the random appearances + admin actions they make, after which they disappear for days, weeks, or months. In terms of existing admins who have been around a while, give them a 2-year window from now for re-assessment. If nothing else, this policy will keep admins on good behavior; whereas nothing much is doing that now, and we have an excess of admin abuse and a situation that is not that different from a totalitarian government where admins can't even be re-called or reviewed, and even ArbCom results in a pass unless it's something so outrageously rare, abusive, hair-raising and longterm as WifiOne. Softlavender (talk) 09:43, 28 May 2015 (UTC)[reply]
  • One thing not appearing in the stats is editing protected pages, or viewing deleted pages and files. However I would not expect a very different picture of inactivity with this either. Perhaps we copuld have something more like a continuous RFA, where each admin has a winge page, where people can pile on the dirt, or put in the praise. Then other can see what people have to say about that admin. The page could be restricted to comments on admin activity. It could be pretty ugly reading depending on who complains! Graeme Bartlett (talk) 10:08, 28 May 2015 (UTC)[reply]
    This is true: admin activity is not simply loggable actions like deletes, prots and blocks; besides editing protected pages, some reports can only be viewed by an admin, such as Special:UnwatchedPages using the "Page information" feature on a page with fewer than thirty watchers to find out the exact number or looking at which of my edits have been deleted. --Redrose64 (talk) 10:20, 28 May 2015 (UTC)[reply]
That's an interesting point. Is there any way that such stats could be added to the Admin stats output? (It would just be numbers, so I don't think these would violate any needed "secrecy".) It would probably be good if things like this could be included there... --IJBall (talk) 16:07, 28 May 2015 (UTC)[reply]
You people are aware that Special:UnwatchedPages hasn't existed for around a decade, right? (More accurately, it still exists but only shows the first 5000 hits in alphabetical order, which to give some idea of the scale of things takes you from "articles starting with 1" to the beginning of "articles starting with 2".)
The other type of admin action, which isn't going to show up in any kind of stats log, is negative actions: closing AIV reports as unfounded, declining unblock requests, issuing warnings which are acted upon so no action needs to be taken…). Unless they're regularly patrolling AIV, a good admin is measured on how well they resolve situations without the need to resort to the banhammer; introducing some kind of "must have made 20 blocks per year" quota is just going to drive out the people who try to take the time to resolve disputes, while retaining the shoot-from-the-hip Defender Of The Wiki types. (If the quota is just "any logged admin action", that's trivially easy to game; just head over to Category:Expired proposed deletions or Category:Candidates for speedy deletion and zap the first thing you come across.) – iridescent 16:37, 28 May 2015 (UTC)[reply]
Yes, it wouldn't be "12 blocks" per se – it would be, say, "12 logable Admin actions" per year, which includes plenty of other stuff like page protections. That is really not some unfair hurdle to overcome for any Admin who's doing any kind of steady Admin-like work. And it may be "gameable", but it would at least act as incentive for some Admins to occasionally go over to AIV or RFPP or something every so often. --IJBall (talk) 17:19, 28 May 2015 (UTC)[reply]
Can't we unbundle actions like viewing deleted pages (provided that the user has identified to the WMF or something)? And technically, any editor can write "decline" on an unblock request since it's not a software feature, like blocking, protecting, or deleting is. Should it become a software feature? There's no way to count actions like viewing deleted pages or declining unblock requests, Epic Genius (talk) ± 19:00, 28 May 2015 (UTC)[reply]
Declining an unblock request is visible (anyone can see it, and someone with a lot of time on their hands could in theory keep a count and hand-make a list). but as far as I know isn't logged anywhere. We could fix that by creating a log and asking admins to log their unblock declines. Viewing a deleted page isn't, as far as I can tell, visible to anyone. Should it be? There is a benefit to having an accurate count of how often an admin uses his tools, but is there any downside? If we decide that w want this we can request it from the developers at WMF. --Guy Macon (talk) 19:24, 29 May 2015 (UTC)[reply]
  • I don't support term limits either. Who's to say that a 10-year admin has lost his marbles and needs to sit the exam again? Also, it's highly likely that many of us wouldn't bother to go through that process again. Furthermore, resysoping would be a hayday for the anti-admin brigade (if they are still around - and some of them are still not showing signs of giving up). --Kudpung กุดผึ้ง (talk) 14:41, 30 May 2015 (UTC)[reply]
Again, I remain unconvinced that the Admin haters will, on their own, be able to sway a "reappointment" RfA. Recent RfA's have not been hurting for votes – the last several who've passed have gotten well over 100 votes. I don't think the "anti-Admin" brigade is powerful enough to sway that many objective voters – I am quite sure that most voters would be able to see through such tactics. I find it more likely that Admins who might lose reappointment votes are those who've been unnecessarily brusk (or hasty) in some of their Admin decisions – I don't think that's a particularly large population. --IJBall (talk) 16:18, 30 May 2015 (UTC)[reply]
  • If we go with five years, it will doom this to failure. This is what I was saying above about moving slowly. If we make it ten years, it will be a small bump in the number of RFAs as most admins from that long ago are already not admins anymore. If we make it five years that means every single admin who got their bits before 2010 will have to run again in the next seven months. That would be an unmanageable mess, and would probably cost us a lot of perfectly good admins as well. I was imagining a few extra RFAs a month, probably with lower thresholds for acceptance, not a wholesale purge of hundreds of admins. That's a terrible idea. Beeblebrox (talk) 18:52, 30 May 2015 (UTC)[reply]
  • I don't like term limits because it's a "one size fits all" approach, without regard to the individual characteristics of the admin. Far preferable is provide a better mechanism for removal of admins who shouldn't be admins, or limiting tool use among admins who are deficient in certain areas. In other words, treading admin tools as tools, subject to removal or reinstatement without much drama, and not treating admins as a higher caste. Coretheapple (talk) 13:45, 31 May 2015 (UTC)[reply]
  • Editing Wikipedia should ideally be a hobby, something you can spend an evening a month on and fit in with jobs, family and other hobbies. We already have a problem at RFA that "standards" have risen, not in terms of how civil or trustworthy someone is, but in the arbitrary areas of editcount and recent activity. There are hundreds of useful and uncontentious admins who don't have the excessively high activity level now required at RFA, and this is because RFA is broken, not because they aren't good admins. Term limits risk losing us most of our existing admin cadre as most existing admins simply wouldn't run. This has various drawbacks not least that the fewer admins we have and the more we depend on a few hyper active admins the more risk of them considering themselves or being considered a "higher caste". A ten year term limit would reduce the damage, but would still do more harm than good. ϢereSpielChequers 16:36, 9 June 2015 (UTC)[reply]

Beeblebrox, there is already a process to get rid of bad eggs. The process your suggesting would create huge, unnecessary bureaucracy and backlog. There are over 700 admins who have had the bits for 10 or more years. Even if only half of them ran their new RfA, that would still be 60 a month over the next half year. It's just impracticable, especially when nearly all the admins are doing a fine job. Furthermore, community standards for RfA passage become more stringent every year. We would be unnecessarily putting fine standing admins through the ringer. As I said, there is already a process. Kingturtle = (talk) 13:56, 1 July 2015 (UTC)[reply]

Bureaucrats?

What about bureaucrats? If we look down the list at Wikipedia:Bureaucrats, some of them haven't done anything bureaucrat related in years, and some are just making enough edits to hold onto the tools. --Rschen7754 04:06, 28 May 2015 (UTC)[reply]

Excellent point. In my opinion, anyone who consistently makes just enough edits to hold onto the tools is gaming the system, and should be treated the same way we treat editors who consistently revert just outside of the #RR time limit. --Guy Macon (talk) 10:23, 28 May 2015 (UTC)[reply]
This was attempted back in '09: Wikipedia:Bureaucrat removal. Since then, renaming has been removed from the bureaucrat's base toolset and there is far less work for bureaucrats (if you don't count renaming on the global system). –xenotalk 11:26, 28 May 2015 (UTC)[reply]
Of the functions left for bureaucrats, we have +admin, -admin, +crat, and +-bot, all of which require up-to-date knowledge on policy. I think there would be significant controversy for any of these long-inactive crats if they suddenly participated in these roles. Perhaps it might be a better idea to start with auditing the activity of crats, before trying to look at the 1000+ admins? --Rschen7754 13:37, 28 May 2015 (UTC)[reply]
-admin is effectively only done on instruction from Arbcom or strictly in line with the agreed inactivity policy so it can be considered to be +admin has become rather rare and +- bot is pretty much done on request of BAG. Maybe we should just get rid of crats altogether and assign the rights to the current Arbcom...! QuiteUnusual (talk) 16:01, 28 May 2015 (UTC)[reply]
Arbcom has enough on their plate. I think the current crat system is fine, but I agree with Rschen that some auditing needs to be done. Perhaps the much smaller group of crats would be an ideal testing ground for any proposed de-adminship or inactivity proposals. KonveyorBelt 00:10, 29 May 2015 (UTC)[reply]
While I don't feel strongly about this, I think some might object over "separation of powers" concerns. --Rschen7754 04:04, 29 May 2015 (UTC)[reply]
Since obviously, with global renaming, bureaucrats aren't needed for much anymore, can't we replace them with stewards? Opposite from the current paucity of administrators, we actually have more bureaucrats than we need at this point. And since crat actions happen very infrequently, I think stewards can do many of the same crat functions. Epic Genius (talk) ± 15:09, 29 May 2015 (UTC)[reply]
Requires up-to-date knowledge on policy but is purely administrative (i.e., requires no discretion)? That sounds like a job bthat should be assigned to the Clerks. --Guy Macon (talk) 19:30, 29 May 2015 (UTC)[reply]
@Epicgenius: Being a former steward, I don't think that would be a good idea; while I won't go into all of the reasons why publicly, it would be best to handle matters like this on a local level (we don't really have full control / accountability over stewards locally). --Rschen7754 01:05, 30 May 2015 (UTC)[reply]

My understanding was that when this user group was created, it was deliberately givent he most boring name possible in order to indicate that it is actually not a very interesting job. And with SUL there is even less for crats to do. However, piling those few tasks onto arbcom would basically guarantee they would not get done in a timely matter. Look at unblocks: onwiki unblock requests take minutes to hours in most cases, a day or two is exceptionally long. WP:BASC on the other hand, takes 2-6 weeks to handle each request. I don't think stewards should take it on either as they are not supposed to really use their powers on their "home wiki" so we would have to rely on folks who are by definition not very familiar with out policies.

All that being said, we probably don't need the largely inactive ones who appear to just be gaming to keep their rights intact as there simply is no benefit to anyone in theor continuing to retain those tools and the current crop of active crats is able to handle their diminished workload just fine. — Preceding unsigned comment added by Beeblebrox (talk • contribs) 19:00, 30 May 2015‎ (UTC)[reply]

OK.… Rschen7754's and this unsigned user's above comments are both convincing in the case against using stewards to handle crat tasks on enwiki. But we really don't need all these crats anyway—maybe eight to ten would be fine. Epic Genius (talk) ± 22:40, 30 May 2015 (UTC)[reply]
  • Maybe (and don't shoot me until you read this fully) give the current rights of bureaucrats to the functionaries? (as in Checkusers + Oversighters) I know it's not what they signed on for or what the community approved them for, but the workload is pretty low, the work technical and routine in nature, they already have to be familiar with policy, they're all trusted at at least the level of bureaucrats, and the room for abuse is already much smaller than the room for abuse of CU/OS? --L235 (t / c / ping in reply) 02:16, 1 June 2015 (UTC)[reply]
  • That would be giving the responsibilities to an appointed group (in terms of the functionaries) that are appointed for different reasons and motivations. I'm not sure why this thread has moved towards ideas on removing the bureaucrat role entirely; the current system is not broken and there are still important duties that lay with the bureaucrat team (especially tending to RfAs in progress and at conclusion).
    My comment above about the reduced responsibility was not to say the role is no longer necessary: simply that there is a reduced need for services and less "grunt" work (i.e. work requiring less discretion or need to keep up-to-date with community standards) that is available to a bureaucrat who is returning to the role from a long absence; such that the community may wish to revisit the 2009 discussion concerning bureaucrat activity levels if they are going to do the same with administrators. Ensuring the bureaucrat team as a whole is actively engaged and up-to-date would also make it easier for the community to grant additional roles to the team as desired. –xenotalk 14:19, 1 June 2015 (UTC)[reply]

Bureaucrats are all wise enough after an absence to review policies and procedures, neither of which are all that complicated. Also, there is already a procedure to remove a bureaucrat for tool misuse. And all those misuses are easily reversible. Is there any evidence that unlimited terms for bureaucrats is a problem? Kingturtle = (talk) 14:20, 1 July 2015 (UTC)[reply]

Is there a broader issue here?

With all due respect to Sam, and while I think that there definitely may be a problem with inactive or inept admins who were named years ago, I think that there is a broader issue that needs to be addressed: a lack of routine, non-drama oversight for admins.

AntonioMartin had serious WP:CIR issues. Yet even so, it was plain that until he clumsily sockpuppeted, nothing was going to be done. There is no mechanism for dealing with administrators who should not be admins. Perhaps, as in this case, they are clearly incompetent, without a clue as to content or deletion policies, and creating articles that they themselves admit do not have adequate sourcing. Yet nothing can be done, as he was not abusing his tools or committing gross misconduct (until the absurdly obvious sockpuppeting was uncovered by checkuser and behavioral evidence).

There are other admins with clear temperament issues. WP:NPA is only loosely enforced, but admins are supposed to set an example. "Abusive administrators" is one of the common themes at a certain off-wiki website. While I'm not a big fan of that website, it does provide an escape valve for complaints re administrators that might not be heard here. There is no method that ordinary editors can turn to, re an abusive admin, with any hope that it will be dealt with fairly and without undue drama.

Then there's the issue of retaliation. If you bring a case against an admin at ANI or arbcom, your own behavior will be scrutinized. I'm not against "boomerang" - it's essential in most cases. But the problem is that it can translate into what is known in the real world as "retaliation against the whistleblower." In the ANI on AntonioMartin, there was talk that if anything was done, Damiens (the editor who blew the whistle) might be blocked as well. It took considerable guts, considering that he already had a block history, for him to take this case against Antonio.

Perhaps what is needed is a committee of arbcom that can look into complaints against admins with a minimum of drama, without the threat of "boomerang" retaliation, and at the same time swiftly throwing out meritless complaints. Desysoping would be just one of the things such a mechanism would do. It could order mentoring, or simply admonish admins. I think you need this so that the community feels that being an admin is not a lifelong entitlement, and maybe if that happens RfAs will be less of a trial by fire, as they should be until admins get their house in order and consent to this kind of mechanism. Coretheapple (talk) 13:59, 28 May 2015 (UTC)[reply]

We already have a committee of ArbCom that can look into complaints against admins and handle those complaints in an expedited manner—we call it the ArbCom. In recent years, it's actually been much more common for admins to be desysopped by ArbCom motion or to resign 'under a cloud' (when faced with an ArbCom filing) than for a full ArbCom case to be opened and completed. Indeed, AntonioMartin was swiftly desysopped by motion with a minimum of fuss.
Historically, mentoring has not been a terribly effective remedy; either mentor or mentee tends to lose interest in the process relatively quickly. Recruiting mentors (either at the time of the case, or to replace dropouts) has been difficult. In the past, 'mentoring' has largely amounted to a way to implement a more nuanced or filtered sort of page, topic, or tool ban. Compelled "mentoring" isn't likely to be worthwhile.
Admonishment is something that can be done just as readily through AN/I. If an admin (however recently-minted) ignores credible admonishments and continues with unconstructive behavior, they then end up before ArbCom.
"Retaliation", meanwhile, has always struck me as a red herring and has a whole bunch of bad-faith assumptions wrapped up in it that I'm not going to get into. TenOfAllTrades(talk) 18:37, 28 May 2015 (UTC)[reply]
And yet this finely oiled, superbly functioning, magnificent admin-supervision machinery, time-tested and universally loved and admired, was about to do absolutely not a thing about an admin who was grossly incompetent - until he socked. How about that! Coretheapple (talk) 12:21, 29 May 2015 (UTC)[reply]
A common misunderstanding regarding arbcom is that they are not an investigative body, they are a deliberative body. By definition they do not go out looking for things to fix, you have to bring issues to them, with clear supporting evidence. Beeblebrox (talk) 19:16, 30 May 2015 (UTC)[reply]
Yes of course. But what's needed is to get rid of bad admins, so that the community can feel confidence to allow more new admins, that it's not a lifetime appointment to a special caste of wiki-royalty. I think the focus of this conversation is wrong; the fact that AntonioMartin was from a different era is a bit of a red herring. The problem that emerged at ANI is that he needed to be gone, and that the current criteria didn't allow for his removal. Until he socked, and then we had a demonstration of why so many users are cynical about the admin caste - they get desysopped where ordinary users get blocked, and they don't get desysopped for simply being lousy. Coretheapple (talk) 00:00, 31 May 2015 (UTC)[reply]

Identifying new admin candidates

As I said above, I think that adminship ought to be given out much more often than it presently is (and also be easier to remove). In my opinion there are probably many hundreds of active and experienced editors who would be helpful as admins if A) we could identify them, and B) we could promote them. Setting aside the mess that is RFA, I would like to solicit suggestions for ways to help identify users who would potentially be good as admins?

Personally, I tend to think the most important attributes are maturity, responsibility, and community trust, etc. Unfortunately, all of those are pretty hard to measure in any systematic, automated way. However, we can probably at least come up with a short list of possible candidates using automated tools that look at long-term active editors. For example, X total edits, averaging at least Y edits per month in the last six months, and has been active at least Z years. Do people have suggestions for what technical tests you'd prefer to help identify possible candidates? For example, edit thresholds, time commitments, patterns of editing by namespace, contributions in certain areas, etc. On the technical side, what characteristics does the current community think exemplify an ideal admin candidate? Obviously, not every good candidate would necessarily pass every possible technical test, but if we can make a short list of users who seems like good candidates then it might be easier to look at individual cases and encourage the best ones.

In the past there have been some other attempts to identify potential admin candidates on the basis of technical evidence, does anyone remember where those lists ended up and what criteria were used? Dragons flight (talk) 04:30, 29 May 2015 (UTC)[reply]

There was a discussion about this in the last six months – I remember reading it. Unfortunately, I can't remember where I read it – it might have been at one of the Village Pump forums (but when I searched for it recently there, I couldn't find it); it may also have been at WT:RfA (I didn't really search there...). I hope someone can remember what the discussion I'm referring to, because there was a discussion about using a Bot to do what you're describing, but I think it only came to "talk" and no one went further with it (as fat as I know)... Beyond that, the only thing I am aware of is Snottywong's (now broken?) Admin score tool. --IJBall (talk) 05:58, 29 May 2015 (UTC)[reply]
@Dragons flight: There was Snottywong's tool that IJBall is referencing; general thought at WT:RFA was that such a tool would make editcountitis worse for the purposes of that forum--I'm not personally of this opinion--but that it also could be useful for identification of candidates (and not necessarily the more full review necessary for nominating/!voting on a candidate).

@IJBall: this search for "Snottywong" prefix:Wikipedia talk:Requests for adminship/Archive will probably help you "bump into" the conversation in question, since I recall the same conversation and I'm fairly certain it was close in time to a reference made to the same tool. --Izno (talk) 14:26, 29 May 2015 (UTC)[reply]

Thanks @Izno:, but I still can't seem to find it! (I found something at WP:RfA was close to the discussion I was thinking of, but it didn't seem to include the part about the "bot" to look for Admin candidates... ). On a side issue, re: this discussion about Snottywong's Admin score tool – is there any desire or ability to fix the dang thing?! Or is it not possible now, post-migration?... (Pinging: @JackPotte:) --IJBall (talk) 17:18, 29 May 2015 (UTC)[reply]
I went to use the tool and did not have a problem (I happened to score a 230). You happen to score a 218.

Anyway, I think what you are looking for is Wikipedia talk:Requests for adminship/Archive 233#Bot to find candidates. --Izno (talk) 17:51, 29 May 2015 (UTC)[reply]

Re: this discussion only 4 of the original 11 inputs in to that tool currently work. You can see this if you compare current scores obtained from the tool vs. the 2013 list of scores – e.g. Carrite: 298 now vs. 945 in 2013 (there's no way his score could have dropped that much!!). (You can also see it doesn't work on mine either, as it's giving a "+0" score for "reviewer" status and I'm doubting it's supposed to...) P.S. thanks for the link to that thread!! --IJBall (talk) 18:28, 29 May 2015 (UTC)[reply]
Ah, yes, I thought that was odd. --Izno (talk) 18:31, 29 May 2015 (UTC)[reply]
Yes I was forced to inhibit some criteria because of the database replica performances. I tried these optimizations before asking for a merging into Xtools, which already uses some asynchronous functions. JackPotte (talk) 19:26, 29 May 2015 (UTC)[reply]
Is there somewhere that states the current scoring criteria and/or the criteria used in the past? Dragons flight (talk) 19:46, 29 May 2015 (UTC)[reply]
@JackPotte: (mostly) non-techie here – so is it hopeless to fix Scottywong's tool post-migration? Or are there potential workarounds to obtain the criteria that the tool currently can't access? --IJBall (talk) 20:07, 29 May 2015 (UTC)[reply]
@IJBall: I thought about rewriting these scripts in AJAX, or with an XML dump, but now I won't have the time before several months. Apart from that, cyberpower678 had a look to it. JackPotte (talk) 20:43, 29 May 2015 (UTC)[reply]
If I could get my hands on the original script, I can attempt to port it over to xTools. As for the old script that's residing on xTools, I recall not adding it because it was using outdated functions no longer used on the current xTools.—cyberpowerChat:Offline 05:49, 30 May 2015 (UTC)[reply]
 Done @Cyberpower678: Please find everything here. Thank you for your help. JackPotte (talk) 10:26, 30 May 2015 (UTC)[reply]
Well done, gentlemen! It would be nice if this tool, at least, can be put back into proper service. I look forward to whatever progress you make here. --IJBall (talk) 16:21, 30 May 2015 (UTC)[reply]
PS. In case it is unclear, I'm volunteering to make a list, though how quickly probably depends on how complicated a set of criteria are involved. Dragons flight (talk) 19:46, 29 May 2015 (UTC)[reply]
Specific technical criteria suggested in the previous discussion (in no particular order):
  1. >10000 edits, no blocks for at least 6 months, >50 AFD comments
  2. 1 year, >5000 edits, no blocks
  3. 6000 edits, 1 year tenure, no significant blocks, as well 50 AfDs or 100 AIV reports or 1 FA
There were also a number of non-specific suggestions in the prior thread. Dragons flight (talk) 19:46, 29 May 2015 (UTC)[reply]
I'm not sure about the AfD or AIV parts. I see AfD brought up a lot in these discussions, but as one of those editors that rarely participates in AfD (I have nothing against it... I just don't find AfD particularly interesting, and personally find RM discussions more interesting than AfD ones), the hidden assumption in using AfD as a "primary" criteria is that Admins are always going to do a lot of article deletions, and while some do, others don't. Similarly, with AIV, I think that would "bias" towards editors that use Twinkle, Huggle and STiki. So I'm not sure you can set arbitrary levels for AfD, RM, AIV, RFPP, and ANI, etc. – looks at those things may have to come in the "second cut", after Admins parse through the "first cut" list of editors that the bot (or whatever) generates for you. --IJBall (talk) 20:02, 29 May 2015 (UTC)[reply]
I think the idea is that these criteria should find promising on-paper admin candidates, and AfD/AIV are typical of good admin candidates, even if there are others who would be good but don't have AfD/AIV experience. Equally any of the other criteria aren't necessary for a good admin but should flag some promising candidates. Sam Walton (talk) 20:06, 29 May 2015 (UTC)[reply]
The reason that AfD gets so much attention is that deletion is one of the two major admin tools that people are the most concerned about being misused. (Blocking being the other) At AfD, you can evaluate the contributor's knowledge of a number of notability guidelines, reliable source policy, other guidelines and policies, and their general propensity towards deletion. Its also a relatively accessible place for non-admins to be involved in policy work. The other would be AN and AN/I, but everyone hates their necessary evil, so general candidates aren't pressed to show positive involvement there. Monty845 22:53, 30 May 2015 (UTC)[reply]
The main thing thats put me off running for adminship appears to be a big want on article creation and work along those lines. Im fine with a bit of copyediting and tidying up but I have not a single ounce of creative anything anywhere (apart from the ability to come up with typical british humor responses to vandals and sockpuppets on my pages). Its why I tend to stick to rolling back vandalism, making requests for page protection and filing reports at the drama boards (as well as closing the ones that can be closed). I wouldnt say no to being nominated though as this would let me know theres a few people out there who trust me enough without a string of articles. I know a few other users who seem to have the same line of work on here who might be useful but if theres still a want on articles being created then I have a feeling some suitable candidates might be put off. Amortias (T)(C) 19:54, 30 May 2015 (UTC)[reply]
While I wouldn't suggest that you, specifically, be the one to "bite the bullet" if you don't want to, I'm thinking someone like you needs to run under the current RfA zeitgeist as a kind of "test case" to see if RfA's have matured to the point to where it will accept a candidate with your kind of background. While some voters, I suspect, will still cling to the "you need 'X' Good Articles, and 'Y' Featured Articles to get a "support" vote", I think most will recognize that not every Admin candidate needs to have that kind of background to be a good potential Admin. --IJBall (talk) 20:27, 30 May 2015 (UTC)[reply]
@Amortias: The emphasis on article/content creation at RFA seems to have faded substantially in the last year or two. That said, even back when the opposes for lack of content creation were common it was possible to pass RFA even for us gnomish editors with some work. When I passed my RFA back in 2012, the furor wasn't at its peak, but was still a major factor at RFA, and I passed without really having any major article creations to my credit. Not to say I had never done content work, people who looked could fine places were I referenced articles, I had done a handful of GA reviews, had done some AFC work. But I had created basically no articles from scratch, had no GA/FA/Main page credits etc... What is really important is that you have demonstrated enough content work that it is clear you understand the right way to do it. It also doesn't hurt to emphasize your respect for the content work done by those who are focused on content.
If you are interested in running some day, my advice on how to prepare yourself for RFA would be to take the next 5-6 months (Your 13 month account age would be pushing the inside limit on account age at RFA, at 18 months old this would be a much smaller issue) and try to find some collaborative content work to add to your wiki-resume. (Just as a side project alongside your regular editing) Since you appear to be interested in copy editing, some GA reviews might be a good start, as it requires you have the understanding of content work, while being different enough that it may be enjoyable even if regular content work isn't your thing. Maybe helping improve some drafts at AfC at least far enough to qualify for article space, even if not to full B/GA/FA status. Based on my quick glance of your history, I'd probably support you at RFA even today given the strength of your gnomish work, but then my personal criteria to support at RFA aren't as strict as some people. I don't know if you would pass today but I think with a bit of work and you would be very like to pass in another few months. Monty845 20:46, 30 May 2015 (UTC)[reply]
Though we have had occasional opposes for lack of an FA, the de facto standard for content contributions has long been that anyone wanting to be an admin needs to show that they know how to cite content to reliable sources. Usually that means listing some examples where they've done that, either on their userpage, in the nomination or their answer to Question 2. GAs and FAs are great to have, and I doubt if you can get 100% support without them, but the pass mark is in the 70/75% range. ϢereSpielChequers 07:14, 9 June 2015 (UTC)[reply]
I had zero GA/FA and I was very explicit that I am not going to have GA/FA, and I still got 99% support, so that they are certainly not necessary.--Ymblanter (talk) 07:44, 9 June 2015 (UTC)[reply]
  • Sorry but I'm really underwhelmed by utilizing quantitative measures to identify admin candidates. I have observed some absolute idiots building up their edit counts in an apparent quest for adminship. Anyway I don't believe admin ranks should be expanded until the procedures for removing bad admins has been improved. Frankly I favor a moratorium on new admins until that has taken place. Certainly the community will continue to put new admins through a ring of fire as long as it a permanent elevation to Brahmin status. Coretheapple (talk) 14:55, 30 May 2015 (UTC)[reply]
    • Arbcom continues to desysop admins, if you have suggestions as to types of admin behaviour that the they should desyop for then why not make them there or in the Arbcom elections? In the meantime we need sufficient admins to keep the vandals and spammers at bay, and if you worry as to who we recruit as admins then may I suggest the worst scenario for you is that we reach the point where we have insufficient active admins to keep on top of AIV or G10 deletions and appoint a large batch of poorly scrutinised ones (I've tried several times to fix RFA and am increasingly resigned to this scenario - my bet is that as with the admins of the 2003/2006 era most will turn out just fine). ϢereSpielChequers 07:32, 9 June 2015 (UTC)[reply]
      • This discussion is becoming somewhat circular, as we're back to where we started, which was an admin (AntonioMartin) who came to ANI/I on WP:COMPETENCE issues and didn't have a hope of being desysopped on that basis. He was then desysopped, but not on the original grounds but for clumsily socking at ANI, when the usual penalty for that is a block. So we're back where we're started from I guess. The bottom line is that the process is broken and it's not going to be fixed. Coretheapple (talk) 15:46, 13 June 2015 (UTC)[reply]
        • Looking at Wikipedia:Administrators'_noticeboard/IncidentArchive886#Admin_User:AntonioMartin_repeatedly_adding_unsourced_information_on_a_BLP there was an active discussion as to whether to take the chap to Arbcom when it emerged that he was socking. Since the socking emerged when it did we don't know whether Arbcom would remove the bit from an admin for that alleged level of misuse of Rollback, BLP sourcing problems or editwarring. I suspect they would, but until someone takes such a case to Arbcom we don't know; Though it might make for an interesting question at the next Arbcom elections. In the meantime it has restarted the debate about our problems at RFA, and I doubt I'm the only editor for whom the problems at RFA seem a far greater issue than the theoretical possibility that Arbcom might decline to desysop a bad admin if a sufficient case was made. ϢereSpielChequers 16:36, 14 June 2015 (UTC)[reply]
          • No, it's not theoretical because the consensus at ANI, before the socking, was that bringing AntonioMartin to Arbcom would be a waste of time. And indeed, no one did, as it was obviously not going to be worthwhile. Coretheapple (talk) 13:30, 18 June 2015 (UTC)[reply]
            • The thread closed with "AntonioMartin has been desysopped by Arbcom--" not "no consensus to take this to Arbcom" let alone "ARBCOm has declined the case" so until we can peer into alternate universes we will never know whether ARBCOM would have desysopped without the socking. But as I said earlier if you doubt that this ARBCOM would have desysoped you are free to post a question in the next ARB elections. If the community then elects an ARBCOM majority that would not desysop in those circumstances then you could conclude that taking similar admins to ARBCOM would be a waste of time. But conversely if as I would expect the community elects a group of candidates who mostly would desysop in similar circumstances then you could have some confidence that they would have desysoped. ϢereSpielChequers 22:35, 30 June 2015 (UTC)[reply]

List of hoaxes on Wikipedia‎

I posted something to the talk page a while ago concerning this, but I now see that what interested users even look at that thing will probably never it.

Anyway, the list is unwieldy. My suggestion was to narrow the criteria for inclusion in the list, and also to possibly justify the list itself. The biggest reason I can see for which we want a list of hoaxes is to record any resultant infections: the utility whereby someone can study motivations behind the hoaxes is dubious, at best (it provides very little helpful information); reading some of the other comments on its talk page, I wouldn't go so far as to say that it promotes Herostratus, but it certainly looks like people are only interested in added to the list.

Hmm, however, encouraging people to find an undiscovered longest-standing hoax might be a good thing, too. So, that might be another, albeit superfluous, reason to keep it, but I digress.

What should be done with hoaxes that have no known repercussions? Should they be maintained in a list somewhere? That list?

What about those which are obviously not hoaxes, but mere vandalism which happened to escape beyond Wikipedia?

Again, I think the most important reason to keep a list of this stuff is for spin control and to try and regain some ethos when something does spill out.

JamesEG (talk) 11:14, 29 May 2015 (UTC)[reply]

It appears that you could separate the list by year of creation. Possibly the data could be used in the future for research purposes (whether for a human psychology study or some potential form of automated hoax detection), so it makes some sense to preserve the information. Praemonitus (talk) 17:03, 1 June 2015 (UTC)[reply]
I was trying to say that the list has value, but some of the content seems lacking useful info or even pertinence. We could file them apart for length, but what about eligibility and repercussions? I yet think that most of them could at least benefit from some perfunctory attempts at classification; i guess it's not of enough importance to gain much interest here. — JamesEG (talk) 06:09, 8 June 2015 (UTC)[reply]

An easier way to deal with RM

Requested moves has a backlog that just keeps on going; adding to just one more thing that admins have to do with. Hypothetically; what do people think about giving editors who have several RM closures the powers to:

  1. Suppress redirects
  2. Move pages over redirects
  3. Move move-protected pages
  4. Move large amounts of subpages

These permissions could only be used to either close move requests or fix obvious page-move vandalism. I fully realize that this is yet another unbundling of the tools; however it seems that it could be given to editors who perhaps aren't quite qualified for the mop, and that it could easily be removed from an editor if there was an issue. Thoughts? Kharkiv07 (T) 00:37, 30 May 2015 (UTC), amended 00:48, 30 May 2015 (UTC)[reply]

There isn't an admin level "move over redirect". If the redirect has exactly one revision, and its a redirect to the page being moved, anyone can move it. If the redirect has any history at all, a deletion must occur to make way for the move. As a result I don't think there is a good way to debundle this role, more than it already has been. However I think it would be interesting to explore the possibility of RM clerks, while it would be contrary to the long held NAC rule of only closing in ways you can technically implement, for something like requested moves, I think the stakes are such that we could have a trusted group of closers who could deal with determining consensus, and then just use tags to get an admin to do any part requiring the mop. (The time consuming part is judging consensus, not the technical move) The concern with this approach is always that the admin needs to be fully responsible for their own tool use, but I think we could bend that a bit here and let admins rely on the close of established and vetted non-admin RM closers, and only be required to use judgement for the technical stuff. Monty845 01:13, 30 May 2015 (UTC)[reply]
Current state of the backlog: The oldest discussion, which was re-listed, is about six weeks old. The oldest non-re-listed one is four weeks old. It would be interesting to know how this compares to past months or years. I've got a very vague impression that this is pretty much normal. WhatamIdoing (talk) 02:57, 30 May 2015 (UTC)[reply]
FWIW, earlier this year, there were some RM's that were months old (I mean at least 2 months...) IIRC. --IJBall (talk) 03:09, 30 May 2015 (UTC)[reply]
Just out of curiosity, and I'm in no way suggesting this, but would you support "closers" in XfDs, with admins that simply press the button when somebody judges consensus? Kharkiv07 (T) 03:43, 30 May 2015 (UTC)[reply]
At AfD, no, as its one of the deletion processes that people get really heated over, and where any mistakes or problems are likely to cause huge amounts of drama. For other XfD venues, I'd be willing to consider it if there was a sufficiently serious backlog problem. WP:CFD would seem to be the only plausible candidate on the deletion side. Monty845 13:36, 30 May 2015 (UTC)[reply]
Concurring with Monty above, at AfD, outside of non-admin closures, no. Any closures of even moderately controversial outcomes and unclear consensuses performed by non-admins are likely to cause drama and sticks. Esquivalience t 17:05, 30 May 2015 (UTC)[reply]
Related: Wikipedia:Administrators' noticeboard/Archive272#Backlog: Too few active administrators to handle the workload? --Guy Macon (talk) 17:52, 30 May 2015 (UTC)[reply]
I'm not aware of any technical reason why any editor can't move larger numbers of subpages. The massmove.js script currently checks for the sysop bit, but there's nothing stopping an editor from making their own script (which I had to do not too long ago to clean up a botched move of a Portal page out of Draft space for AfC). --Ahecht (TALK
PAGE) 01:39, 1 June 2015 (UTC)[reply]

Merging some processes

This idea has been churning in my brain for a while now, so I might as well throw it out here since it's related. My idea is to merge requested moves into redirects for discussion, and rename the process Article titles for discussion. Disambiguation pages would makes sense in this process too. Discussions about all three of these center around what titles should be and where they should point, so it seems to make some logical sense to put them together. And having fewer processes could hopefully reduce these backlogs we got. I'm curious what people think of this idea. Oiyarbepsy (talk) 04:08, 30 May 2015 (UTC)[reply]

RfDs often are trying to get a redirect created though, it's not a bad idea in principle but it could cause confusion. Kharkiv07 (T) 13:25, 30 May 2015 (UTC)[reply]

Example of complex nested referencing

I tried to upgrade the information in a company infobox by using the company's annual report. One thing led to another so my bold edit has now resulted in something that is too complex both as it appears to the reader and to an editor. The result probably uses the Footnotes/References section of the infobox totally incorrectly. It also probably over-references the source, which is a 300 plus page report with the data scattered all over it. I am unsure as to how to improve the style without cutting the referencing down to something that is not as friendly for someone who is checking the references. Maybe there is another template out there that can help me. I would have preferred to use a separate footnote list created with the Short Footnote template, but that would have meant changing the existing referencing style of the article. I am hoping that whoever reverts my edit can suggest a better alternative.My Gussie (talk) 14:38, 30 May 2015 (UTC)[reply]

Hey My Gussie . How about just changing the named reference from "AR2011" to the updated "AR2014", and then placing next to each place where you cite it {{rp}}, i.e., the first use would have ...</ref>{{rp|6}}, the next <ref name="AR2014" />{{rp|7}}, the next <ref name="AR2014" />{{rp|177}} and so on. Technically this template was created for situations where you are using a single reference so many times that even shortened footnotes would be a bit silly, but this would work here to make verifiability much easier and would solve your problem I think. Best regards--Fuhghettaboutit (talk) 21:21, 30 May 2015 (UTC)[reply]
Thanks Fuhghettaboutit, the {{rp}} template that you pointed me to is exactly what I was looking for, being both obvious and simple. In trying it in the article I encountered a formatting snag. In the company infobox, the note number and the page number are often separated from each other when the wraparound at the end of the line is reached. Is there a way to "glue" them together? A non-breaking space doesn't work so I was hoping for a template to enclose the whole thing in — or some such thing. My Gussie (talk) 11:01, 31 May 2015 (UTC)[reply]
@My Gussie: According to the template's documentation, you can add add the word joinder code &#8288; to avoid this. If that doesn't work, there always {{nowrap}} and the paired {{nowrap begin}} + {{nowrap end}}. I have had problems in the past using these though when trying to wrap templates with their own functionality inside them.--Fuhghettaboutit (talk) 13:38, 31 May 2015 (UTC)[reply]
Instead of the {{rp}} template, you can use the {{r}} template for second and subsequent references, like this: {{r|AR2014|page1=7}} . It saves some typing, and I used it quite a bit when tidying up much repeated references in The River War. That's where I go to now when I need to remind myself how to do it! Chuntuk (talk) 12:06, 1 June 2015 (UTC)[reply]
@Chuntuk: The name {{r}} is really minimalist, as is the amount of typing it needs to work! I decided to use the (marginally) more obvious {{rp}} template. Thanks for pointing out the article The River War. I'll take a look at it when I decide to improve my style to the next level. My Gussie (talk) 07:24, 13 June 2015 (UTC)[reply]
@Fuhghettaboutit: I decided on a final set of changes and I like the result, but I couldn't get any of the options to prevent the undesirable wrapping to work. I overrode all the line breaks in the ugliest wraparound failure (in the key people parameter) and left the rest. There is an opportunity for improving this formatting behaviour, but I guess that it requires someone with technical expertise to weigh in. My Gussie (talk) 07:24, 13 June 2015 (UTC)[reply]
PS I just realized that the problem I had originally (i.e. the note number and page number being separated from each other by the wraparound) seems to have magically disappeared. Maybe I was imagining it. The only real improvement in formatting I can see has to do with separating the note number from the preceding text. This is the behaviour that I can't seem to be able to fix, and it only shows up in the Key people section of the infobox. Maybe it's a browser-specific quirk. My Gussie (talk) 07:37, 13 June 2015 (UTC)[reply]
PPS Here is another example of the undesirable wrapping behavior (in the note numbers after the financial figures). It seems to be connected to the use of {{ublist}}. Does anyone else see it or could it be the way my two browsers show it (or just my stylistic taste that is telling me that it's not desirable)? My Gussie (talk) 09:34, 13 June 2015 (UTC)[reply]
It looks perfect on my browser (Firefox)! I don't know what you mean about the separation in the Key people section. It looks the same as all others, with the footnote number snugged up against the text it follows – which is the way it's supposed to be. Yes, in the Salini Impregilo article the footnotes in the infobox are wrapping. Haven't the foggiest idea for a fox except to avoid ublist.--Fuhghettaboutit (talk) 12:28, 13 June 2015 (UTC)[reply]

Article tags

Tags at the top of article-space are intended to encourage editors to correct an article's problems, but more often than not, they are just an eye-sore and a waste of time when petty edit-wars emerge over tags, where that energy could have been better-focused on actual article-content. It struck me that this could be done in a better way that's more focused on the tags' objective - encouraging editors to improve the article.

Something like this:

Then you click on it and it shows something like this:

Details aside, it seems like something roughly along these lines would be much more effective at fulfilling the tags' intended objective of encouraging editors to improve the article and even providing actionable next steps on how readers can get involved. Beckoning readers to become editors.CorporateM (Talk) 06:05, 4 June 2015 (UTC)[reply]

Would the change essentially be to reword the first line of Template:Multiple issues and make it default hide? Sam Walton (talk) 10:18, 4 June 2015 (UTC)[reply]
That would be a good first step and an incremental improvement over the current situation. CorporateM (Talk) 10:23, 4 June 2015 (UTC)[reply]
But another important function of tags is to warn readers that (1) there may be content in the article that's more problematic than usual or (2) in some significant way the article isn't up to the usual standards of a Wikipedia article (whatever those may be), in either case meaning readers may need to exercise extra caution in their use of the article. In those cases, it isn't desirable to reduce the tag's visibility.--Arxiloxos (talk) 23:18, 4 June 2015 (UTC)[reply]
Maybe that is a side function of the tags, but I don't think that is the actual reason the tags were created (prove me wrong if you must, though). Dustin (talk) 23:28, 4 June 2015 (UTC)[reply]
It's a fair concern, but I think the number of cases where that application is most relevant is small. When the problems are within normal range, tags only act as a "warning: Wikipedia isn't that great" and it's not sensible to place them on most articles. When the problems are significant enough to the point that the information is misleading to readers or not useful to an encyclopedia, this is a consistently successful argument at AFD, which is the right place to send articles we feel are so bad we would feel the need for a special warning for readers not to trust them. The range of articles that are bad enough such that the problems are not routine, but are not so bad to be deletable, but still bad enough to justify cautioning readers, is a very narrow set of articles. In comparison, finding a more compelling way to turn readers into editors and actually fix the problems of the article I feel are a much more compelling priority. CorporateM (Talk) 06:16, 5 June 2015 (UTC)[reply]
My experience with tags is the majority of them are useless complaints by drive-by editors. If these were constructive complaints, they would leave comments about what to fix, or better yet, since most of these complaints come from experienced editors, they would instead use their knowledge to fix the problems. But that would take time. Instead they simply vandalize the article, spray painting their Kilroy and moving on. I've looked at the histories of some of these abusers including the most prolific editor on wikipedia. They leave these tags, several times a minute, meaning they could not even taken the time to read, much less fix, the article in question. None of this is productive, but it increases their edit count. The majority of the tags are written to be broad and therefore easy to apply to multiple circumstances. The result is there is very little guidance given. Many are too jargonistic or oblique so inexperienced editors and the general public have no idea what they are talking about. All it really announces is something is wrong. It hurts the credibility of wikipedia and certainly the credibility of the articles it is seen on. A favorite is lede too short. That's just a word count and like many, a stylistic comment. Its like an art critic saying there is too little red in the picture. There is no wikipedia requirement, certainly not to the extent that the overall integrity of the article need be impugned. And perhaps the worst part, these tags are on the top of the article. They are the first thing a reader sees. Big and bold, they dominate the look of the article. One person's opinion, emblazoned across the top, vs the efforts of all the previous editors and other readers who would have the opportunity to edit and fix a problem if there really were something wrong. There should be a minimum requirement to leave a comment on the talk page. There should be a quota on usage, a minimum amount of time spent on a page (compared to the word count of the article). Abusers should be sanctioned. Trackinfo (talk) 07:23, 6 June 2015 (UTC)[reply]
@Trackinfo: There is some guidance at WP:TAGGING that "When it comes to confusing or ambiguous tags, such as npov or dead end, you should explain yourself on the talk page and/or in an edit summary." It also says "Anyone who sees a tag, but does not see the purported problem with the article and does not see any detailed complaint on the talk page, may remove the tag." Granted that is just an essay, and not a firm rule, it seems like there is technically already support for the idea that you should not apply ambiguous tags without explanation. So my instinct is that this is less of a policy problem and more of a - well, somebody has to confront the editors spamming thousands of tags, if that is the case. I know in my own experiences I went to cleanup articles that were tagged as adverts and most of them had been cleaned up ages ago without the tag being removed. CorporateM (Talk) 20:33, 7 June 2015 (UTC)[reply]
@CorporateM: What I am reporting is the almost constant abuse of Tags, including by the most powerful editors on wikipedia.Their actions are a real detriment to wikipedia. The existing rules serve no purpose to their abuse. Virtually none of the tags are positive or productive. I think the first thing we could do with tags, if we need to retain them al all which I am not convinced of, is to move them to the talk page and away from public view. That would eliminate the defacement, what I term vandalism, of the public view of an article. Trackinfo (talk) 08:44, 10 June 2015 (UTC)[reply]
I'd say that we need to consider visibility and audience. The goal being to attract attention of editors with interest and ability to contribute toward reviewing and revising. The second major concern here would be to keep such alerts, legitimate or otherwise, in places where they throw the widest possible net, so to say. We don't want merely a cabbalistic circle of conceited collaborators who all watch a worklist — not that i've seen any suggestions in that exact regard, but thought i'd mention it.
Anyway, from all the viewers of these tags, how many are
  • knowledgeable of the subject
  • considerate of the Wikipedia policies, especially the Socratic precautions
  • interested or capable of contribution (available time, resources)
as compared to those who visit an article seeking knowledge? Equally important: how many such editors might never view those tags because it never occurred to them that their contribution would be valued and appreciated?
Merely some thoughts. — JamesEG (talk) 05:58, 8 June 2015 (UTC)[reply]
With all due respect, this sounds elitist to me. If an article is already problematic enough to warrant tagging, any editor should be able to make improvements, even if they have no experience on Wikipedia or knowledge of the subject. If the tag provides a link to an essay that provides advice on how to correct the issue, this should make it even easier. We should welcome new editors, not discourage them from contributing because they are not experienced enough or knowledgeable about the subject. CorporateM (Talk) 19:58, 8 June 2015 (UTC)[reply]
And there is nothing wrong with elitism, in its place. There are things just about any editor can do. There are things that only some editors can do. And anyway, tags do many things (I have listed some of them in User:Martynas Patasius/Tags are useful). The one you mentioned - "encouraging editors to improve the article" - is by no means the only one. --Martynas Patasius (talk) 21:47, 9 June 2015 (UTC)[reply]
I was actually trying to sound un-elitist: the tags need to be somewhere that anybody can see, especially people who would be able to make a difference. I was also saying, as Martynas may agree, that just because someone reads a page doesn't always mean that they are the only ones who would be able to contribute to it — or even at all, but you can't make that determination out-of-hand et c. It occurs to me that some experts may never take interest in viewing articles in their field of expertise, to which is what I was alluding. — JamesEG (talk) 12:51, 10 June 2015 (UTC)[reply]
This sounds like what the Mobile Web site already does with those tags. WhatamIdoing (talk) 07:41, 10 June 2015 (UTC)[reply]

Proposals regarding the 'Preview' button

The 'preview' and 'show changes' buttons are redundant functions that could be merged. The new button would be called Preview Changes, and would highlight the changes inline. At the top middle of the screen there would be a Show difference button, which would expand into a comparison of the changed portions side-by-side with the previous version. (like in the Show Changes window)

• The new button could be on the left of 'Save page'.
• Also, pressing Enter in the Edit Summary box could do Preview instead of Save
• and both of these settings could be reversed by registered users, so edits could be saved quickly
85.211.105.223 (talk) 10:14, 4 June 2015 (UTC)[reply]
Oppose merging the buttons - each one will result in a certain amount of extra data to download; no need to force an editor to do both in order to get either one. And external tools (such as AWB) may use the preview feature but handle the changes internally. עוד מישהו Od Mishehu 20:32, 4 June 2015 (UTC)[reply]
@Od Mishehu: Please don't "Oppose" - per the box at the top, this page is not for consensus polling. --Redrose64 (talk) 21:03, 4 June 2015 (UTC)[reply]
@Od Mishehu: 'Show changes' uses a much smaller amount of data, compared to Previewing (=parsing) a page section (or the entire page!). And technical ability to perform 'Preview' can still be available to bots etc. - it's just the visible button that will perform a new combo function. 2 vs 3 buttons can also be set in Preferences for registered users; meanwhile, two buttons instead of three is friendlier to new users. — Preceding unsigned comment added by 85.211.105.223 (talk) 01:31, 5 June 2015
Where this would create an issue is during full page edits of a lengthy article, particularly one with many images. In that case I just want to see the deltas, rather than reloading a long page. Possibly you could add a 'show preview' checkbox instead? But that may be confusing. Praemonitus (talk) 16:44, 5 June 2015 (UTC)[reply]
@Praemonitus: On Show changes, one'd see changes in source code, but not what it does in action; (so you'd Preview anyway to see if the code works or not). Do many people use 'Show changes'? (Can we get stats?) Maybe people do it because the (wall of) text inside the edit box is hard to make head or tail of. 85.211.105.223 (talk) 13:09, 6 June 2015 (UTC)[reply]
I often use "Show changes", usually last thing before "Save page", just in case somebody else is editing the page. You're not always warned of an edit conflict, and I don't want to overwrite somebody else's post by accident. --Redrose64 (talk) 14:38, 6 June 2015 (UTC)[reply]
@Redrose64: wow I didn't know the edits manager system bugged out like that! I saw a weird 'edit conflict' note before someone's post on Village Pump... it must have been this. But then if the system knew of the edit clash, why didn't it just tell the poster instead?.. Wonder if this bug has been reported. 85.211.105.223 (talk) 09:13, 7 June 2015 (UTC)[reply]
It periodically gets mentioned at WP:VPT. But generally speaking, the system will warn of an edit conflict, but it's not 100% guaranteed to do so. --Redrose64 (talk) 15:03, 7 June 2015 (UTC)[reply]

I'd love to have a "Preview changes" button. Now, the merged button should be opt-in, as every major website redesign. --21:31, 8 June 2015 (UTC)~

Opt-in for registered, optout for unregistered, I think. (it's not redesigning the whole site and anyway, it's not as if the layout new users see is immutable)
Although it'd be a lot better if the edit clash bug were worked out first. 85.211.110.34 (talk) 20:52, 9 June 2015 (UTC)[reply]

Extra power for Check Users

You really need to stop with all of this. The functionaries are well aware of resource distribution and utilization, as well as what proposals are useful and what are not. There is plenty of cleanup and antivandalism work to be done on Wikipedia, and I suggest that you concern yourself with that instead of going on about something you clearly don't know that much about. NW (Talk) 20:52, 12 June 2015 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Some check users are very busy with SPI cases. I don't want to burden them. There are other users who have Check User powers but, I don't see them much in SPI. There are some sockmasters who have two three sock accounts. But there are some sockmasters who are socking for more than a year. After sometime they become inactive. But there is a huge chance that they might come back as a new user and pretend to be different. Check Users must be allowed to run surprise checks on known habitual sockmasters after months of the blocking of last sock account. Don't call this fishing.

I don't want that, they(sockmasters) should get vandalism hall of fame status, but we need to find their socks.--Cosmic  Emperor  10:37, 11 June 2015 (UTC)[reply]

The use of CheckUser is goverened by a global policy and cannot be locally varied, although it can be adapted as long as it does not extend the global policy - i.e., by allowing more reasons for checks. If you want to alter the policy, your best approach is an RFC at Meta. From a practical point of view, CheckUser data is only stored on the Wikimedia servers for 3 months, so running a check on an account that has been inactive for more than 3 months will return no data. QuiteUnusual (talk) 11:12, 11 June 2015 (UTC)[reply]
Global policy is more lax than local practice/policy. The standard in the Meta Policy is "There must be a valid reason to check a user." There has been rather little public discussion on what exactly constitutes a valid reason. While is of course debatable, I would suggest that a previous and still active block triggered by checkuser evidence within the technical lookback period should qualify as a valid reason to re-run the check in search of post-block socking. Monty845 12:40, 11 June 2015 (UTC)[reply]

link of RFC at Meta.?Cosmic  Emperor  12:28, 11 June 2015 (UTC)[reply]

(A former CU writes) This is impossible without a redesign of the Mediawiki software, which there's no possibility will ever happen. Checkuser data is only retained for three months. Even if it were possible to check further back, it would be meaningless given how often IP addresses are reallocated; I doubt one editor in fifty is still on the same IP address as they were a year ago. There would also be a glaring ethical issue if the WMF did choose to retain data for longer, given how leaky they've proven to be in the past. – iridescent 12:33, 11 June 2015 (UTC)[reply]
My impression is that this proposal is mostly aimed at the blatant socking that often occurs within that window, though many people don't know how short it is as many editors who do know avoid mentioning the exact time. Monty845 12:43, 11 June 2015 (UTC)[reply]
True, although I've never really understood the reluctance to discuss it as it is publicly documented. QuiteUnusual (talk) 16:10, 11 June 2015 (UTC)[reply]

This will not happen. We are not the NSA and are not going to be running surprise checks on IP ranges or random users. Reaper Eternal (talk) 00:46, 12 June 2015 (UTC)[reply]

Reaper Eternal (talk)Reaper, It's not about random users, but sockers.Cosmic  Emperor  05:34, 12 June 2015 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

You are an IP, too!

Please consider my reflection and challenge, found here. 74.127.175.164 (talk) 00:52, 12 June 2015 (UTC)[reply]

I do a lot of searching for citations to re-use, so I look for the citation title, edit the article, grab the citation template, then merge it into another article. Do others follow this practice much? I'm wondering how efficient it would be to consolidate the lot, so I search on a citation and it pops up a template to use? (Yes I'm familiar with {{cite doi}}, but sometimes those can result in inconsistent template layouts.) Praemonitus (talk) 21:51, 15 June 2015 (UTC)[reply]

Proposal for neutrality

Unfortunately most of Wikipedia shows a distinct affinity for US politics or military. The English Wikipedia is international therefore I propose that all items(images) relating to the military or political activity stay to articles strictly of military or of political activity. Eg.: Physical exercise 117.248.15.77 (talk) 11:55, 18 June 2015 (UTC)Inc[reply]

You're proposing that certain use of images be censored on the basis of anti-Americanism, despite the fact that they satisfy the Wikipedia criteria for use? Praemonitus (talk) 18:29, 18 June 2015 (UTC)[reply]
@117.248.15.77: Welcome and thanks for regurgitating the argument presented in Wikipedia:Systemic bias. We already know that there's an issue with our presentation and coverage. We're working on it. Hasteur (talk) 18:40, 18 June 2015 (UTC)[reply]
We already have a policy on neutrality. All that can be done is for users to try to make neutral articles on a case by case basis. I would agree that the photos on the Physical exercise article do not give a global view. Be bold and add/remove images to make it better. This is the encyclopedia that anyone can edit, which means you too. Try to fix the problem. Cheers, Jason Quinn (talk) 12:50, 22 June 2015 (UTC)[reply]

Adding section in a movie page

I request you to please add Sound Designer and Production Designer section in the page for movies. Thank you! — Preceding unsigned comment added by 1.187.110.160 (talk) 02:58, 19 June 2015 (UTC)[reply]

I'm not sure what you mean but Wikipedia talk:WikiProject Film is probably a must better place for you to discuss this than here. Jason Quinn (talk) 15:42, 23 June 2015 (UTC)[reply]

Expanding news section on the Main page

The news section on the Main page just gives a handful of recent news stories. Has consideration ever been given to having a blue link on the Main page news section to a longer news section (perhaps an article entitled "Recent news events"), which would cover more issues? This could make WP a better news resource than it is currently.OnBeyondZebrax • TALK 10:53, 24 June 2015 (UTC)[reply]

Portal:Current events is already linked. It's admittedly not terribly obvious. —Cryptic 11:33, 24 June 2015 (UTC)[reply]

Edit filter policy

The AbuseFilter is an extension that checks edits against a specified set of criteria with a primary aim of tagging edits and stopping abusive edits. Recent actions related to one user's use of the edit filter has called into question whether we should have some policies related to the use of this rather powerful tool, so I'd like to start a discussion with the view of then properly proposing specific policies that should hopefully reflect the community's feelings.

On the English Wikipedia the extension was added in 2009 and shortly thereafter renamed to the Edit Filter as, though it was originally designed to counter abusive edits, the more recent usage has broadened from that. In order to create a filter an editor must have the 'edit filter manager' user right, which has in all but a few rare cases only been available to administrators, who are currently free to assign it to themselves as required (new admins do not have the right by default). There are currently around 170 users with the user right, and I would estimate that around 10 actively contribute to filters.

Filters take a number of conditions in order to track edits that fit those rules in the log for that filter. As an example, Special:AbuseFilter/3 tracks new users (who are not confirmed), taking an article of over 300 characters and reducing it to less than 50, in the article namespace (with a few extras to avoid false positives). The output is stored in the abuse log for that filter, and the filter is currently set to warn the user with a message before tagging the edit ('blanking') if they choose to continue. New filters are usually left in 'log only' mode for at least a week before switching on any warning or tagging in order to check for false positives.

I'd like to start a few sections with areas that I think would be worth discussing, feel free to add more if there's something in particular you feel is important. Of course, if you feel that the current standing works fine, do say so. Sam Walton (talk) 00:41, 26 June 2015 (UTC)[reply]

Useful links:

Assigning the user right

As mentioned above, the user right is currently primarily used by admins who assign themselves the right if they're interested in contributing to filters. It has, rarely, been given out to competent non-admins in the past. Should there be a better process for assigning the user right? Should admins be able to give themselves the right with no oversight? Should non-admins be able to request the right with a realistic chance of obtaining it? Discuss. Sam Walton (talk) 00:41, 26 June 2015 (UTC)[reply]

  • I do not believe admins in general are capable of assessing someone's technical knowledge to the point of being able to determine if assigning the edit filter right is appropriate. I also believe that an editor should be able to attain that right without being an admin (though as an individual who has had such a right, I may be biased). Historically this discussion has been done at WT:EF and the people that frequent that area would be able to make a reasonable assessment of an individual's technical ability to determine if assignment of the edit filter tools are safe. I do not believe that changing this process would yield any benefit, and any attempt to make the policy anything more than that would result in an RFA-style assessment which would leave us to "why not just do an RFA?" --Shirik (Questions or Comments?) 01:19, 26 June 2015 (UTC)[reply]
  • There's two primary sides to this: For one, you are absolutely correct in saying that many of the admins that added the abusefilter right are not really fit to be creating, adjusting, or otherwise presenting themselves as someone capable of understanding complex regex and the theory behind edit filters. On the other hand, they're all admins. We've entrusted them with the most powerful of tools. They can edit the MediaWiki namespace, which is visible to all users and arguably could cause just as much damage as a filter blocking nearly all edits that come through. But my last point is there's no reason for admins to assign themselves the abusefilter user group, they can already see private filters and the only reason they'd need the user group is if they wish to edit them. So I guess it boils down to whether there's been actual disruption caused by newbie admins trying to do something they're not truly fit to be doing. I cannot off the top of my head present any evidence of this (other than a single recent incident), so perhaps for now it may not be worth adding another layer of bureaucracy with a request for abusefilter user group granted only by 'crats or stewards. — MusikAnimal talk 02:22, 26 June 2015 (UTC)[reply]
  • Given the insane WP:BEANS possibilities that the edit filter represents, we should really only grant the right to non-admins who we would basically trust to be admins. And if the larger community understood the potential for the edit filer, requests would receive far more scrutiny than they have in the past. Now its fair that some editors who would be trusted at RFA may prefer not to run, and want EFM, but we should still be as cautious as if it were an RFA. As an anecdote, the last person I opposed for EFM passed an RFA a number of months later and rightfully has EFM now, which is of course, fine having been subject to, and passed the heavy scrutiny of RFA. By default, I think we should suggest going through RFA for EFM, and really only consider granting the right separately if the editor has rejected the notion of becoming an admin. Monty845 14:12, 26 June 2015 (UTC)[reply]

Hiding filters

In some cases it may be sensible to hide a filter from public view. This is useful for long term vandals who may otherwise work out how to avoid the filter, but is generally not used unless deemed necessary. Should there be a policy regarding when a filter should be hidden from public view? If so, what should be the condition for hiding a filter, and how would that be enforced? Sam Walton (talk) 00:41, 26 June 2015 (UTC)[reply]

  • I can't imagine a scenario where you would want the filter and logs hidden completely from view unless it's for long-term abuse. We can't really say for sure, but I'm willing to bet some of these people are both fully aware when they are triggering the edit filter (e.g. not disallowed or warned) and know how to respond to it. For this reason alone I'd say the ability to hide the logs from public view could be a good thing, but beyond that I've also seen how non-admin/non-editfilterer patrollers see the filter log and may get confused by the ambiguity and intentionally vague names of the private filters. As for policy, I'd say so long as it's helpful to patrollers to see the logs it shouldn't be hidden – and this is almost always the case, I think. One could argue that a deceitful edit filter admin could deliberately create a fully hidden filter for abusive purposes, but we've entrusted them with the right to begin with so we should not worry. — MusikAnimal talk 02:35, 26 June 2015 (UTC)[reply]
  • I've always had an issue with that, there have been many times when, while patrolling something or another I've come across a need to view the hits for a private filter. In all honesty I can't think of a specific example off the top of my head, but I've picked a few just scrolling that I don't understand why they're private:
I can come up with a ton more, I just pulled a handful. Kharkiv07 (T) 03:37, 26 June 2015 (UTC)[reply]
  • I can fully understand hiding a filter so that a vandal can't find a way around it. But I think we need to make edit summaries available to all, the case in point being an edit filter I requested in January. Edit filter 656 - Driver 3 vandal was requested and created at the end of January (I'll give a fuller explanation about the vandal and their edits in the General section below) but the key point for this section is that the vandalism was stopped by the edit filter. The vandalism re-started this week, so I went to the edit filer to see if it's status had changed, it had, the problem is that there was no indication of why it was disabled. I can't even be sure who disabled it, only the last person to edit it is shown. Now, was the last editor the person who disabled the filter? or were they merely tidying up after the person who did disable it? What was the reason for disabling it? I've requested that it be re-enabled, and I'm waiting for a reply. But at the moment I'm effectively in the dark. - X201 (talk) 09:08, 26 June 2015 (UTC)[reply]
  • First, I think we are a bit too quick to hide edit filters. We should really only hide them when we are dealing with long term abuse from an editor that has shown themselves to be technically sophisticated, and thus likely to both realize the way edit filters work, and figure out a way around them. For the rest, they should be public, even if that slightly raises the risk of evasion. Given the number of people who report their own clear attempts at disruption to the false positives page (probably not realizing we will see exactly what they tried to do) I don't think the average vandal will figure out how to view and then avoid a filter. Second, we should either reduce the number hidden, or give rollback the view right, as many of the hidden filters are at a level where rollback would be more than sufficient trust to let people see the inner workings, and the more scrutiny the better. Monty845 14:25, 26 June 2015 (UTC)[reply]

Filter checks

When a user creates a new edit filter, should there be checks from other editors at any stage of the process? For example, should a new filter be checked over before it goes into log only mode, or perhaps only before it's switched to disallow edits? Or do we trust that edit filter managers know what they're doing and shouldn't require checks? Sam Walton (talk) 00:41, 26 June 2015 (UTC)[reply]

  • EVERY filter should be checked in log only mode. There is no excuse for this. I've made emergency filters (as in, when the Wikipedia is under active attack by a large botnet) and even then I would check it in log only mode. Doing anything else is equivalent to checking in software changes and deploying them to a live server before you even bother to test it. Any sane software developer will tell you this is ridiculous. And it doesn't matter whether or not we trust edit filter managers (I would hope we do) - everyone makes mistakes. Everyone. (Preferably there would be a review process, too, but sometimes this is simply not possible due to the urgency of some filters and the proportional lack of filter managers, but at a minimum you should be testing your own software.) --Shirik (Questions or Comments?) 01:23, 26 June 2015 (UTC)[reply]
  • I think a review process may be too much, and also build up a difficult to tackle backlog. If we trust the user to edit filters in the first place we should trust that they'll test them before enabling any action. It's the honour system, if you will. — MusikAnimal talk 02:39, 26 June 2015 (UTC)[reply]

General discussion

Bad cases make for bad law. Other than Kww's bad filter (as determined by consensus yesterday), how many other cases of problematic hidden filters have their been? I don't mean botched filters, we've had a few of those, but hidden ones that went for days/weeks/months that did something bad or simply skirted policy? Before we "fix" this problem, is it really a problem, and how big is it really? I hate adding bureaucracy if it is a problem that happens less than once a year, for instance. Could we just sweep the hidden filters once a month instead of preapproving them? Dennis Brown - 2¢ 00:48, 26 June 2015 (UTC)[reply]
This doesn't have to be a case of only adding policies designed to keep bad stuff from happening, in fact one of the side effects that I would be interested in is that tightening up the way in which the user right is assigned might allow more non-admins to help. Presently it seems as though there's the assumption of admins being competent at this and non-admins having to be outstanding in order to have the possibility of contributing. Maybe that's the way it should be, I can think of some arguments for it, but equally I can think of some arguments against, and I'm all for more editors being involved with edit filters. Sam Walton (talk) 00:54, 26 June 2015 (UTC)[reply]
As I wrote on ANI, this is a systemic problem. A huge proportion of recent filter changes have been by some definition "bad", but nobody seems to care (I have brought this up several times in the past few years). We have moved from tagging highly suspect edits to tagging unusual things, even when only 1% of those tags are actually problematic edits. That is the equivalent of assuming bad faith at the automated level. --Shirik (Questions or Comments?) 01:12, 26 June 2015 (UTC)[reply]
I would frame the issue differently. Right now, we have essentially no written guidelines about how filters should used, what they should be used for, what standards of accuracy should be expected, when to use the private setting / warnings / disallow / tags / etc. As a result, each edit filter manager essentially decides for themselves what they think is appropriate, and only in rare cases do conflicting interpretations actually get discussed. Equally bad, with no written guidelines, it makes it harder for other people to get involved in editing filters because they have no easy way to learn what is expected. For example, my personal opinion is that it is a waste of resources to have filters that target single articles, or that trip less often than a few times per week. I also think if a filter is going to issue a warning it needs to be pretty accurate (e.g. no more than 1 false warning per 20 real ones), and if it is going to disallow the edit it should be even more accurate (e.g. no more than 1 false disallow per 100 actually bad edits). Similarly, filters that target clear vandalism probably need to react differently than ones that aim to catch inadvertent bad edits (e.g. newbie errors). Right now most filters get little discussion at all, and those few that do get discussed need a new consensus for everything because we have no institutional memory to speak of. It would be good to frame a set of guidelines about how filters should be used so that we are all working from the same basic set of understandings. Dragons flight (talk) 01:38, 26 June 2015 (UTC)[reply]
I 100% agree with constructing some sort of guideline. There's simple base cases, such as vandalism trends (certain phrases, etc) that need no discussion, just a good edit filter manager to make sure it's working properly. Beyond that for SPIs and other complex scenarios perhaps there should be some guideline – even if not enforced. I still believe in the "honour system" as the power to edit filters is given only with utmost trust, inline with adminship. So we should assume good faith that the filters are well tested and intentioned, bound by a general guideline. Things like "good-faith filters should never disallow" and "no more than 1 false positive per 20 hits" is fairly straightforward and should expected from a regular edit filter manager, but it would be good to have it in writing, if not just for reference, and less so for enforcement. — MusikAnimal talk 02:51, 26 June 2015 (UTC)[reply]

I see filters as the surgical arm of Page Protection, so perhaps that may be a process to look at, as an example take edit filter 656. The Driver 3 article has suffered from repetitive vandalism by a single editor, the vandalism started in October 2014. The user would add links and text referring to a specific Disney franchise (Liv and Maddie), there is no link whatsoever between Driver 3 and Liv and Maddie, this is just pure repetitive vandalism. I requested an edit filter in January 2015 and it duly stopped the vandalism (The preceding 3 months had seen 88% of the article edits being vandalism by this one editor).

I saw the edit filter as the only sensible and fair way around the problem. An IP block wasn't an option as the vandal changed IP addresses. range block wasn't an option as thousands of innocent users could have been hit. Semi-Protection would have blocked genuine IP editors. Full protection would have been overkill, and probably not granted. But a single, specific filter that blocked this one repetitive vandal has resulted in no vandalism and the article being available for everyone else to edit.

The problem now, as detailed in the "Hiding" section above, is that someone has disabled the filter and the vandalism has re-started. I don't know who or why the filter was disabled, but I have a pending request for it to be re-enabled. At least with Page protection we're able to see the reasoning for protection removal and can be sure which admin was responsible for it, at the moment we're not able to see that with edit filters. - X201 (talk) 09:10, 26 June 2015 (UTC)[reply]

I've updated the Wikipedia:Edit filter to hopefully better reflect community consensus on these issues. If anything there doesn't seem right to you or could be explained more clearly, please do post on the talk page or change it yourself. Sam Walton (talk) 19:46, 30 June 2015 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(idea_lab)&oldid=669486054"