Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia
  (Redirected from Wikipedia:VPPRO)
Jump to: navigation, search
  Policy   Technical   Proposals   Idea lab   Miscellaneous  

New ideas and proposals are discussed here. Before submitting:

« Older discussions, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118
Centralized discussion
Proposals: policy other Discussions Ideas

Note: inactive discussions, closed or not, should be archived.

RfC: Simple easing of RfA[edit]

There is clear consensus against this proposal. Non-admin closure. Oiyarbepsy (talk) 00:04, 22 January 2015 (UTC)

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.

Various proposals for major RfA reform have failed. I propose a simple easing of existing guidelines. The RfA page currently says "Consensus at RfA is not determined by surpassing a numerical threshold, but by the strength of rationales presented. As a rule of thumb, most of those above 80% approval pass; most of those below 70% fail; the judgment of passing is subject to bureaucratic discretion (and in some cases further discussion)". I propose simply lowering the guidelines by 5%. This would not alter the fact that RfA's are closed primarily based upon the strength of rationales presented. This change would reflect the fact that we have plentiful votes to block inappropriate candidates, and it would encourage a slight easing of when a close should consider applying default-pass or default-fail. Alsee (talk) 14:45, 9 December 2014 (UTC)

Discussion (easing RFA)[edit]

What fraction of past RfAs would fall into this newly-broadened range? How many RfAs – from, let's say, the last couple of years – would have landed in the new 65-70% window?

And of those, how many of those RfAs did not present legitimate concerns that might incline a 'crat to reject the candidate anyway? If the intent is to extend the window over which 'crats can exercise discretion (practically speaking, to allow 'crats to exercise significant discretion which they were strongly discouraged from doing before) how many candidates would actually have been 'saved'? TenOfAllTrades(talk) 16:02, 9 December 2014 (UTC)

Can you clarify how this would change anything? The current wording states that bureaucrats typically pass users with above 80% approval, not that they always approve candidates above 80.00% approval regardless of anything else. Changing this by 5% would appear to just be misrepresenting what actually happens. Sam Walton (talk) 23:21, 9 December 2014 (UTC)

The idea is that closers still apply the same evaluation of arguments and weighing of merits (with the ability to reject based on a single powerful argument), but that when numbers inevitably do get looked at it would gently shift the thought process on what did or did not constitute a borderline case. Alsee (talk) 08:55, 11 December 2014 (UTC)

This would hardly make any difference in numbers passing. Graeme Bartlett (talk) 03:51, 10 December 2014 (UTC)

The proposal is deliberately small, intended to be as unobjectionable as possible. And my thinking was that an increase in the number of applicants might be more significant than any direct effect from the pass-rate itself. Alsee (talk) 09:13, 11 December 2014 (UTC)

Goodness. In the real world, some elections for much more important, influential positions than Wikipedia admin are decided by a simple majority vote. I've always felt that 80% is much too high for a rather minor position on the broader scheme of things. --Biblioworm 23:00, 24 December 2014 (UTC)

Plenty of people pass below 80%. It is a rule of thumb. Chillum 23:09, 24 December 2014 (UTC)

Support (easing RFA)[edit]

  • Support as RfC author. Alsee (talk) 14:45, 9 December 2014 (UTC)
  • Support. This is probably the most straightforward way to increase the number of sysops. I have not noticed a particularly strong correlation between the level of support candidates receive and the quality of their subsequent performance. James500 (talk) 23:17, 9 December 2014 (UTC)
  • Contrary to what is suggested below, the appointment of five new admins in November might be a statistical blip. The overall number of admins appointed this year is still down more than 35% on last year, with less than 19 days to go. November was preceded by an unprecedented two month period during which no admins were appointed. Unless another six admins are appointed in the next 18 days (plus a number of hours), we will have a worse performance than 2012, our previous nadir. To say there has been a miraculous recovery may be premature. James500 (talk) 07:35, 13 December 2014 (UTC)
  • Weak support. Per James, I don't think that those numbers matter much. It would be interesting to see, however, a list of proposals that failed in the range of 65-70%. --Piotr Konieczny aka Prokonsul Piotrus| reply here 08:42, 11 December 2014 (UTC)
  • (Previous comment retracted by author) Support. I'm not really sure why people are making such a big deal out of lowering the requirements by a mere 5%. --Biblioworm 23:47, 2 January 2015 (UTC)
  • I could go for this. Stifle (talk) 16:27, 13 January 2015 (UTC)

Oppose (easing RFA)[edit]

  • Oppose – Ideally, we'd move completely away from this idea of numerical approval numbers. These should be like any other Wikipedia discussion, not determined by percentage, but by the strength of what people say. The idea of "reducing the threshold" implies we should have a numerical threshold at all, and I'm opposed to that. RGloucester 23:20, 9 December 2014 (UTC)
  • Oppose per RGloucester. — {{U|Technical 13}} (etc) 23:48, 9 December 2014 (UTC)
  • Oppose. I agree with Samwalton9 and RGloucester. This proposal appears to be based on a misunderstanding of the numbers' significance (which the suggested change would promote). —David Levy 23:58, 9 December 2014 (UTC)
  • Oppose A rule of thumb should not be made authoritative which while not perhaps the intent of this proposal, would unfortunately be it's impact. I've seen an RfA with 69% go to bureaucratic discussion not that long ago, there is some flexibility in the system. PaleAqua (talk) 00:10, 10 December 2014 (UTC)
  • Oppose per RGloucester. Steel1943 (talk) 03:53, 10 December 2014 (UTC)
  • Oppose - I think RfA is currently doing a grand job and that the bar is not too high. A lot of people claim that the worst admins were those who were appointed pre-2007, the watershed year. Therefore, if the criteria have got tougher since then, those who regularly complain so loudly, bitterly, and oft uncivilly about admins in general should be content. Even with the higher post-2007 criteria, some unsuitable editors scrape through the process and then have to be relieved of their tools again later; even those who have aspired to Arbcom membership or who are WMF employees. The thing that people fear most is the discipline at RfA which for many years was regarded by the community as a place where one could be as nasty as possible, Ignoring All Rules of common decency with impunity. Reaching its peak around 2010-2011, the polution has slowly but surely abated with November 2014 showing a bumper crop of new admins - almost a miraculous recovery. No, I don't think for a moment that we need to lower the bar. --Kudpung กุดผึ้ง (talk) 11:32, 11 December 2014 (UTC)
  • Oppose There is nothing wrong with the current process, as witnessed by the five successful RfAs in the last month.  Philg88 talk 08:59, 13 December 2014 (UTC)
    • That's five out of six, and the sixth editor stopped editing entirely after being subjected to RFA. I'm not happy about a process that has lost us yet another experienced editor (this one with 25,000+ edits). Are you happy about that outcome? (Oh, wait, now that I've read your own comment at that RFA, maybe you actually are happy that we've lost another long-time editor.) WhatamIdoing (talk) 02:48, 16 December 2014 (UTC)
      • Admins need to be open to criticism. If someone leaves the project because they failed RfA then the community made the right decision. I failed my first RfA, badly. I took it okay. A few months later I was accepted. Chillum 22:57, 24 December 2014 (UTC)
    • This is just what I expected. There was a lot of talk about RfA inactivity and that led to a flurry of activity. Well, that flurry is over now. There are problems with the current process, as witnessed by the fact that periods of activity are brief. Mellowed Fillmore (talk) 16:03, 16 December 2014 (UTC)
  • Oppose especially in the absence of an easier de-sysopping process. Bureaucrats can already make someone an admin even if the overall support percent is lower than the minimum. Ca2james (talk) 16:39, 16 December 2014 (UTC)
  • Oppose I think that the current numbers, with the key point of bureaucratic discretion in making the ultimate decision, is a good standard. I support keeping it that way.--Slon02 (talk) 22:37, 24 December 2014 (UTC)
  • Oppose The current bar is reasonable. I think that closers of RfAs should consider the quality and basis in policy in each argument just like closers at AfDs do, the numbers would be far different. This is done to some degree but I would like to see "votes" be based in policy and defended if needed before counted. Chillum 22:50, 24 December 2014 (UTC)
  • Oppose Admins cannot be easily removed, so they should not be easily appointed. Townlake (talk) 00:15, 25 December 2014 (UTC)
  • Oppose The standards to be an admin need to stay high. To much can go wrong if the wrong person is given the responsibility. It is very hard to take away admin powers so the standards need to be high. AlbinoFerret 21:22, 26 December 2014 (UTC)
  • Oppose I'm unconvinced that lowering the % bar would produce a better outcome. First of all, I don't think the number is all that relevant. Bureaucrats have historically been granted ample discretion in promoting users with lower % than the usual based on their own judgements. That's why we don't have bots closing RfAs... Second, I think it is important that new sysops are promoted with ample community consensus. While we absolutely need more administrators, new administrators should still have to obtain ample support from the voters to be granted the bits. If we as a community decide we're being too picky with admins and need to lower the bar in some way, we should do so by being more forgiving to candidates in our voting, rather than lower the bar. Simply put, if the community doesn't fully trust a user to be a good admin, as determined by 'crats after a RfA, the user should not be promoted, period. If we're being too harsh, we should just stop doing so. Snowolf How can I help? 17:04, 27 December 2014 (UTC)
  • Oppose – I also believe that there is nothing wrong with the current passing standards. We can't make it too easy. United States Man (talk) 17:28, 1 January 2015 (UTC)
  • Oppose per Townlake: We need to make it hard to grant adminship to avert administrator corruption. --Mr. Guye (talk) 23:48, 7 January 2015 (UTC)
  • Oppose - RfA is flawed, yes, but the solution is most certainly not lowering the bar to entry. That would be putting lipstick on a pig in order to make things appear marginally better. Lukeno94 (tell Luke off here) 19:50, 14 January 2015 (UTC)

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.

Proposal to auto-transclude /doc subpages[edit]

There are two fundamental components of a Wikipedia article:

  • content page, and a
  • talk page for discussion.

This pattern applies to most namespaces. But for a Wikipedia template, there are instead three (sometimes five) fundamental components:

  • template code, which is the actual wikitext and parameters, etc, to be transcluded into any number of articles
  • template documentation, which describes the template, why it's needed, how to use it
  • the talk page for discussion
  • occasionally, sandbox and testcases pages, the location of which I do not object to

Somewhere in the development of this encyclopedia, these three unique components have been squished into space for two components: the code-and-documentation, and the talk page. The template documentation is not given much of any actual accomodation in the Mediawiki software, instead being treated as just another template (a template that in reality will be transcluded into exactly one page). To accomodate this double function of the Template: namespace, we use lots and lots of nasty include rules: noinclude, onlyinclude, includeonly. This category applies to the host page, this category to the template itself. Virtually every major template has documentation, but still we don't think it's ubiquitous enough for an implementation more universal than pasting {{Documentation}} and include rules on every template page.

I want to propose that we automatically transclude /doc subpages. That is, make {{Documentation}} obsolete: it's used on pretty much every major template anyway, ubiquitous enough that it ought to be automatic. This would legitimize template documentation and also, I feel, encourage the composition of template documentation.

I don't know anything about Mediawiki on the software level, but implementing this seems like it should be easy enough:

  1. A knowledgable programmer makes an extension that inserts the contents of the /doc page at the bottom of the template page
  2. The extension is installed on Wikipedia AND at the same time, the {{Documentation}} template is blanked to remove redundancy
  3. A bot can remove all the calls for {{Documentation}} over time; this can be done at a leisurely pace because the calls are now nonfunctional

Moving forward[edit]

I would fancy that this move would occur as part of a larger change in Wikipedia's templates. I believe that the current squished two-namespace system is not the natural one. I believe that it involves unnecessary code, for implementing documentation, categories, and the like. I believe we should move toward a three-namespace solution, or at least some sort of Mediawiki software acknowledgement of a template documentation as something other than just another template. This could greatly simplify the code. Maybe some day, if we plan it right, some of the biggest and best templates, fully documented, with categories transcluded and non-transcluded, could have zero include rules.

I have pursued this movement in the past, culminating in a Village Pump proposal about a year ago which did not reach a positive consensus: maybe it was too much too soon, and not enough time to develop the idea before sending it out for approval. Here are a few relevant links:

I suggested "Template documentation:" as the name for a new namespace, but not everyone agreed that would be the way to go. Here were a few layouts suggested:

  • Template:Foo/doc (unchanged, ofc)
  • Template documentation:Foo
  • Documentation:Template:Foo
  • Help:Template:Foo
  • Template code:Foo (move the code here; the documentation would remain at Template:Foo)

The single measure I have proposed today (for which I can credit User:Anomie in the last proposal) would be a single step toward a three-namespace solution, however much discussion is needed as to if or how that solution would be implemented. But still, I believe what I have proposed today would be a beneficial move, even if no further changes are made. I ask that you vote on whether this single measure would be beneficial or not, and also give your opinion on whether we should start talking about reorganizing the documentation system as a whole.

Support (documentation)[edit]

  1. As proposer: − Thisismyrofl (talk) 06:29, 15 December 2014 (UTC)
  2. Support. The current system is unnecessarily clunky. Swpbtalk 14:49, 16 December 2014 (UTC)
  3. Support Cleans up template code to do what everyone template should do anyway. Oiyarbepsy (talk) 05:58, 18 December 2014 (UTC)
  4. Support Though prefer a slightly different implementation. I'd rather see a system which in namespaces where it was enable would when generating the page for the templates would automatically include the contents of the document subpage if it exists and wasn't already transcluded. This means that other places that used the documentation template wouldn't break and if documentation needed to included a special way it still could. The existing documentation template wouldn't even need to change, just be removed over time from places it was no longer needed. If the automatically included contents had a CSS style applied it would be easy for editors that didn't want to see the documentation to hide it. Likewise some sort of magic word that disables automatic inclusion would be nice. This would make documentation very much like <reflist>. It in theory should also speed of transclusions of templates because the noninclude stuff for documentation wouldn't need to be parsed; granted it should be only a small amount of memory / time — but when considered with highly used templates probably adds up. I'd also actually like if an add/edit documentation button appeared in any namespace where an auto-include-documention feature was enabled. PaleAqua (talk) 18:30, 18 December 2014 (UTC)
    Technical 13 pointed out to me use of the Documentation template outside of Template and Module namesapces. I suppose now you're right that we can't "kill" the template entirely, as we have to keep it for those purposes, but couldn't we gracefully blank the template only in the namespaces we're modifying? Through wikicode namespace checks, or CSS if nothing else? Then we could delete all the calls for the template in those namespaces, and at a leisurely pace, to work toward the goal of less crap code. − Thisismyrofl (talk) 20:52, 18 December 2014 (UTC)
    It's one of the reasons I suggested a different approach. I don't know that modifying Template:Documentation would be necessary to stage out. As it is currently transcluded by a large number of templates not sure what churn that would cause, when it would be simplier just to slowly remove based on whatlinkshere etc. existing templates, preferable when other changes are made to the template. By using the approach I suggested there is no rush to switch everything all at once; if the document template is used there won't be duplicated docs as the automatic inclusion wouldn't trigger. PaleAqua (talk) 21:05, 18 December 2014 (UTC)
    You might be right. That's probably for the best. The documentation template has a few parameters that must be used at least some of the time. Best not to chuck it all at once. − Thisismyrofl (talk) 08:42, 20 December 2014 (UTC)
  5. Support a system that automatically transcludes /doc subpages in Template namespace, similar to what is already done for the Module namespace, but adding a check for existence of the /doc page in both namespaces. Weak oppose moving documentation pages to a separate namespace, as you propose in your user subpage. SiBr4 (talk) 18:40, 18 December 2014 (UTC)
  6. Support the general concept; but with the implementation more along the lines PaleAqua suggests - Evad37 [talk] 14:52, 20 December 2014 (UTC)
  7. Support the general principle. Templates as they are now are crammed and confusing. Gizza (t)(c) 07:21, 21 December 2014 (UTC)
  8. Support. This progresses Wikipedia as an encyclopedia. --Mr. Guye (talk) 23:53, 7 January 2015 (UTC)
  9. Support. Should have been done already; great idea. APerson (talk!) 14:41, 20 January 2015 (UTC)
  10. Support The number of templates that have no documentation is startling, so having it automatically transcluded would go a long way to improving this. --Ahecht (TALK
    ) 15:02, 20 January 2015 (UTC)

Oppose (documentation)[edit]

  1. Oppose adding this directly to core; Oppose adding it as an extension; Support a gradual process resulting in an on-by-default gadget. — {{U|Technical 13}} (etc) 20:04, 15 December 2014 (UTC)
    Oppose making display of content (any content) rely on JavaScript. Pathore (talk) 22:39, 24 January 2015 (UTC)
  2. Oppose, that suggestion should be vetted on a project where folks are supposed to grok /layout, /langs, /en, /ru, /he, /ar, /doc, etc., with a /doc managing its own zoo of translated documentations. Plus /sandbox and /testcases for hopeless imports from w:en: (red links, of course.) –Be..anyone (talk) 16:37, 31 December 2014 (UTC)
    @Be..anyone: I genuinely don't understand your statement in the slightest. Oiyarbepsy (talk) 00:52, 1 January 2015 (UTC)
    These are common template subpages on commons (partially also on meta), lots of languages, with a shared layout, a doc subpage as here, but also with lots of languages, and only rarely a sandbox + testcases (but working demos in the doc.) It gets rather bizarre, when the template data for the visual editor is also translated. Brion wrote that we are mostly not more using templates in 2017, so maybe this suggestion here isn't necessary for less than two years with templates... –Be..anyone (talk) 01:28, 1 January 2015 (UTC)
    We're not talking about doing it on Commons at the moment, just here. And it sounds like Brion is talking about templates being different in the future, not eliminated entirely. Oiyarbepsy (talk) 19:09, 1 January 2015 (UTC)
    If it's only here, it could be a case for WP:BROKE, maybe mw:Thread:Help_talk:Subpages/Wrong_MW_defaults is also/still relevant. –Be..anyone (talk) 23:44, 1 January 2015 (UTC)
  3. Lets not make this any more complex than it needs to be --Guerillero | My Talk 03:24, 13 January 2015 (UTC)
    Guerillero, how would this increase the system's complexity? Doesn't the current system of having to insert a template just to make documentation visible seem more complex? APerson (talk!) 14:42, 20 January 2015 (UTC)

Comment (documentation)[edit]

Comment Your proposal declares information as fact that is false. There are not three fundamental pages for a template, there are five possibilities. There are:

  1. The template itself
  2. The template's talk page
  3. A sandbox for the template for making modifications to a template that aren't expanded across all Wikipedia
  4. A test cases page to see how the sandbox reacts in relation to how the "live" template reacts.
  5. A documentation page

I actually started working on a userscript that added tabs for each of these components once upon a time but it fell into my stalled projects category due to other "more important" projects and real life issues. I'm still way too busy at the moment to pick that project back up, but would happily contribute what I have and help develop further if someone else wanted to take over the project. This is not something that I think should be done in core, but I fully support a userscript (which may eventually become a gadget if people find it useful, and may eventually even be a default gadget if there are enough people to support such a thing adding the appropriate extra tabs to those pages where respective sub-pages exist. — {{U|Technical 13}} (etc) 07:04, 15 December 2014 (UTC)

I am aware of /sandbox and /testcases but I don't feel that they're terrifically relevant because there is no clumsy inclusion in the main Template: page as is the case with /doc. Furthermore they are far less ubiquitous. Since you seem to take such strong issue, I will point them out in the proposal though. − Thisismyrofl (talk) 07:11, 15 December 2014 (UTC)
  • Okay, next question, what about the 650 uses in the Wikipedia: namespace? Wouldn't transluding them automatically in one namespace but not in others be confusing? What about the 740 uses in the Module: namespace?I've fixed the Wikipedia: namespace count; and made the links use 1 less than the actual count, so users can see that the number is right. עוד מישהו Od Mishehu 16:18, 15 December 2014 (UTC) Will we be forced to have to look at the documentation while editing the templates? I would be strongly opposed to that as some templates have documentation that is three pages long and having to scroll up and down through that for no reason is excessive. — {{U|Technical 13}} (etc) 07:36, 15 December 2014 (UTC)
I would absolutely not seek to have documentation and template code on the same page. That's completely contrary to the general movement I am endorsing. I want for there to be less garbage code on the template code page to look at. I know very little about modules, but I am sure their documentation could be transcluded as well. You raise a good point about the Project namespace, though. Perhaps a system by which the /doc subpage is transcluded if it exists, in any namespace - however as most pages outside of Module: and Template: would not require documentation, we could have a message "This template lacks documentation. Click here to write it!" in only those most relevant namespaces. I hope that makes sense. − Thisismyrofl (talk) 16:26, 15 December 2014 (UTC)
  • This proposal sounds a lot like my User:Technical 13/SandBox/Gadget-extraTabs project I was working on. I'll wait to see how this discussion develops further, but I'm still thinking a userscript for those that want this feature is best at this point. — {{U|Technical 13}} (etc) 16:46, 15 December 2014 (UTC)
13, this isn't the same. This is to automatically transclude documentation even if the {{documentation}} template isn't present. It wouldn't create any tabs. Oiyarbepsy (talk) 17:53, 15 December 2014 (UTC)
  • Part of the plan for the script actually. The script just adds navigation tabs to make it so the documentation transcluded can be simplified and remove those links that are not conclusive or productive. I suppose I should work on developing that script some more. I have a lot of tasks on my plate and this is finals week and I'm boarderline on passing a couple classes. So I need to focus on that (why am I even here talking about it *sigh*), but would be happy to work on that script more after. — {{U|Technical 13}} (etc) 18:26, 15 December 2014 (UTC)
But that only works if people actually activate the script. The proposal here is to make this auto-transcluding universal, which is something a user script just can't do. Oiyarbepsy (talk) 19:57, 15 December 2014 (UTC)
  • It actually can do that, if it is an on-by-default gadget. The process of completing the script to do what is wanted, testing it for a bit locally amongst a small group of tech savvy editors, promoting the script to a wider group of editors, proposing it be made an off-by-default gadget, and eventually switching it to an on-by-default will ensure that it does exactly what it is suppose to and there is community support for it. — {{U|Technical 13}} (etc) 20:02, 15 December 2014 (UTC)
Allow me to raise a concern with your on-by-default gadget: if it has the function of auto-transcluding /doc, then if we implement that gadget and then make use of it by removing every {{Documentation}} on every template, the gadget becomes, well, pretty coercive. If a user chooses to turn it off at that point then every template will have no visible documentation, and no visible links to documentation; the user's kinda screwed. At that point, why even make it optional? − Thisismyrofl (talk) 18:29, 16 December 2014 (UTC)
  • There may be experienced editors who don't want to be bothered with template documentation, at all, ever. It's currently forced upon them, but I'm sure they would greatly appreciate a way to turn it off. I wouldn't be opposed to being more clever about how it could be turned off in those scenarios if a problem arises where inexperienced users are accidentally turning it off. It would be adjusted to be an always on for everyone script imported from MediaWiki:Common.js (if the community so deemed it necessary) and have an optional toggle parameter that a user that really wanted it off could add to their custom.js to disable it. — {{U|Technical 13}} (etc) 18:47, 16 December 2014 (UTC)
Well, you do raise a scenario where optionality would be useful, but I feel that the documentation-hating population would be tech-savvy enough to CSS div#template-documentation { display:none; }. And of course, rare enough to warrant that not-quite-one-click solution. − Thisismyrofl (talk) 19:25, 16 December 2014 (UTC)
  • That solution does not completely eliminate the documentation as can be seen in File:Documentation not completely hidable.png. — {{U|Technical 13}} (etc) 20:06, 16 December 2014 (UTC)
    @Technical 13: The "The above documentation is transcluded from..." box has the ID "documentation-meta-data" and therefore can be hidden using #documentation-meta-data {display:none;}. SiBr4 (talk) 20:15, 16 December 2014 (UTC)
    • Seems excessive amount of work having to use two separate ids to hide one box:
div#template-documentation, #documentation-meta-data{
at most there should be one id or one class that hides them both. Either way, it's still more work than unchecking a checkbox on Preferences → Gadgets or adding var hideDocs = true; to my custom.js. — {{U|Technical 13}} (etc) 20:29, 16 December 2014 (UTC)
I only used "div#template-documentation" in my example CSS because that was the ID used in the current documentation template. A sort of "you know what I mean". If my proposal goes through in the form of an extension, then whoever writes the extension can code a single div ID to surround the entire documentation, with simple CSS hiding in mind. But I will maintain that people who object to seeing template documentation are probably extremely rare at best, and can accomodate themselves anyway. I don't know how one would best verify it, but can we even think of one person so inclined? − Thisismyrofl (talk) 22:36, 16 December 2014 (UTC)
  • Note that the {{documentation}} template can take documentation from any page using the first unnamed parameter (e.g. for templates with shared documentation), or the documentation can be embedded within the |content= parameter. Any deprecation would need to take this into consideration. - Evad37 [talk] 10:45, 15 December 2014 (UTC)
I am sure that could be arranged. − Thisismyrofl (talk) 16:26, 15 December 2014 (UTC)
Easy to address - create a documentation page that redirects to another documentation page. Oiyarbepsy (talk) 17:23, 15 December 2014 (UTC)

Comment If your making comparisons, I'd compare this to the recent change that {{reflist}} automatically functions on all articles, whether the template is there or not. I like the idea, but excess unneeded detail in your proposal is confusing the matter (above comments suggest that people don't understand what you're proposing) and it gives me the impression that it's not quite yet specific enough to be formally proposed. Please provide a more specific proposal without unneeded detail so I'm clear what I'm commenting on. Oiyarbepsy (talk) 17:48, 15 December 2014 (UTC)

A proposed specific proposal: Automatically transclude the documentation subpage in template and module namespaces. Oiyarbepsy (talk) 17:51, 15 December 2014 (UTC)
I don't know the extent to which I am allowed to change a proposal once it's on this page and votes have come in, but what you have written is pretty much what I'm saying for right now. Sorry for the unneeded detail ("Moving on"), I'm just ranting.
I do wish we could make a move in the direction I have described; the problem is there's a potential for a lot of changes at once and I don't have enough knowledge of the software to formulate an extremely specific plan. I just don't know how else to start a discussion on the matter. − Thisismyrofl (talk) 18:38, 16 December 2014 (UTC)
Perhaps it would be better to have a multipart discussion: First establish whether there is consensus for the core idea (automatically transclude documentation), and afterwards discuss implementation methods (subpage/namespace, extension/gadget, easy-to-hide/not-too-easy-to-hide). - Evad37 [talk] 09:08, 18 December 2014 (UTC)
Absolutely! I tried to suggest a rather complete implementation here at the Pump about a year ago, but people had too many differing ideas to vote in favor. I'm going to try to write up two complete plans at User:Thisismyrofl/Templates proposal. For the moment they aren't complete, but I'll fill it out, see which is the most logical, and maybe we can base our discussion on one of those (though if someone has a radically different and better idea that can be considered as well). I do feel, though, that any plan might take a few steps to implement, and automatically transcluding /doc and killing {{Documentation}} would probably be an uncontroversial first step to any plan. − Thisismyrofl (talk) 17:56, 18 December 2014 (UTC)

Proposal to include a link to the Wikipedia Adventure in the Welcome template[edit]

After a short discussion at Template_talk:Welcome, I think it's time to formally put this forward. While you can see some of my reasoning there, let me also explain it here.

The Wikipedia Adventure is an interactive tour designed to help new users learn the basics of editing Wikipedia "in under an hour". Although I have never taken it myself, since I'm a mostly self-learned editor (with the exception of my CVUA course), I gather that many new editors think that the adventure is good. Therefore, I think we should add a link to it in the Welcome template. Assuming that it is used, putting a link to this in such a widely used template will hopefully help new users settle in to Wikipedia faster. What does everyone think? (A proposed version of the new template can be seen here. --Biblioworm 21:07, 24 December 2014 (UTC)

Discussion (TWA)[edit]

That welcome message with all those links is a bit of a mess - does anyone know how many "tutorials" there are? (Just click on intro and getting started) - Perhaps some person or people can be bold in this regard and reverse a bit of the years of encrustation or rationalize organization. Alanscottwalker (talk) 21:29, 24 December 2014 (UTC)

One thing to consider when implementing this would be that there are many different welcome templates; see Wikipedia:Welcoming committee/Welcome templates for example. It would need to be decided which templates TWA should be added to. BethNaught (talk) 16:26, 26 December 2014 (UTC)

Doesn't TWA leave breadcrumbs on the user's account showing that they used it? If so, I'd argue that renders TWA more than a mere tutorial, and I'd be skeptical about pushing users toward it in the template without more disclosure about the record of its use that it leaves. (I'm refraining from opposing Biblio's idea wholesale because I have no problem with TWA itself; it looks useful on some level, though I would at least want a choice about being permanently labeled as a "TWA user" before jumping in.) Townlake (talk) 16:59, 26 December 2014 (UTC)

When you begin TWA, it warns you that it makes automated edits on your behalf, though indeed it does not specifically warn you that it will place badges on your user page. I don't think it's a problem, because the badges can be removed as with any other template. However, it may be worthwhile asking the TWA maintainers to modify it, say, such that you get a choice each time like: "Add badge to my user page" / "No thanks". BethNaught (talk) 17:07, 26 December 2014 (UTC)
Thanks for that. If the automated edits stay in the rookie's "User contributions" list, of course, they cannot be removed from there. That could be objectionable for some. Townlake (talk) 17:10, 26 December 2014 (UTC)
That's true, of course; they do stay in the contributions log. (See for example Special:Contributions/BethOne, where I did a test run. The whole process takes about 50 edits.) It does warn you that it makes edits before beginning, as I say. I don't think I would judge any TWA player adversely if their subsequent contributions were good (and I don't see why anyone should), but I can understand why you say what you do. BethNaught (talk) 17:15, 26 December 2014 (UTC)
Right, thanks for verifying. I wouldn't judge adversely either, but a real new user won't fully understand that warning and would wind up with a permanent "n00b Badge" in their contributions. In some corners of this project, wrongly or wrongly, that could cause the new user to be treated with kid gloves and pats on the head. Townlake (talk) 17:58, 26 December 2014 (UTC)
You have a good point, Townlake. That's actually one reason why I've never used it myself, since I don't want to be labeled as "the user who took that childish TWA when he was a newb". When I read Wolfowitz's MFD, I actually understood his point a little bit, namely the part about not wanting to attract immature children to this site. Despite the fact that there are some exceptionally mature ones, I've seen enough of them in my relatively short time here to know that it would not be in the best interests of the site to mass attract them and make them think this is some utopian MMORPG. --Biblioworm 18:08, 26 December 2014 (UTC)
Yes, Biblio, we're on the same page. To be clear, I like your proposal, and I don't want to overblow my concern here (honestly the "n00b Badge" would not be that big a deal), but I don't want there to be whiplash if the proposal is implemented and then new users are surprised. It only takes one or two malcontents to waste a lot of editors' volunteer time here. Townlake (talk) 18:13, 26 December 2014 (UTC)
  • It's not "the welcome template"; there are well over 100 welcome templates: Category:Welcome templates. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:41, 26 December 2014 (UTC)
  • FWIW, Twinkle has a link to TWA within its welcome menu under "WikiProject welcomes". Cheers.--John Cline (talk) 18:20, 26 December 2014 (UTC)
  • Since I'm the one proposing this, I might be a good idea to know what TWA actually looks like. I'll test it out on a special alt account. --Biblioworm 16:55, 3 January 2015 (UTC)
    • All right, I've finished testing. While I am a little concerned that the TWA gives the impression that Wikipedia is this perfect place where everyone cooperates perfectly and always apologizes whenever they're uncivil (any person who's been around for a little while knows that's not the case ;)), I think it's a good introduction for those are complete newcomers. --Biblioworm 19:00, 3 January 2015 (UTC)

Support (TWA)[edit]

  • Support: I have tested TWA myself. While I have reservations about the extent of gamification, presenting it as one of a set of ways to learn about Wikipedia is appropriate because it allows people to choose the style of tutorial they like. I think it provides an adequate primer to the key skills for Wikipedia. BethNaught (talk) 16:26, 26 December 2014 (UTC)
  • Support: I've used TWA on several new editors for the purposes of training, and I only see it doing good for new editors to get started with syntax, article work, and productive communication with other editors. It seems very appropriate to include on then Welcome template. I, JethroBT drop me a line 09:14, 10 January 2015 (UTC)
  • Support Pretty good idea, it would generally help with helping users learn the "Ropes" of sorts of Editing. And if they did it would show that they generally had a motive to edit constructively LorTalk 09:24, 10 January 2015 (UTC)
  • Support Good idea Doc James (talk · contribs · email) 02:26, 14 January 2015 (UTC)
  • Support I like the approach, there are certainly some new editors who will benefit from this --Kim D. Petersen 01:28, 16 January 2015 (UTC)
  • Support I see no problems. Definitely a good idea IMO. Cheers, --ceradon (talkcontribs) 01:35, 16 January 2015 (UTC)
  • Support. This is a helpful, entertaining, and fun way to introduce the project to new users who want to jump-start their learning curve right out of the gate. GenQuest "Talk to Me" 07:07, 16 January 2015 (UTC)
  • Support A link is a good idea. It may prove useful to new users and will make them aware that TWA exists. Sometimes it hard for new users to find what can help them and where things are. AlbinoFerret 14:30, 17 January 2015 (UTC)
  • Support I don't see any problems. The link would be useful because Wikipedia Adventure is a program that could teach editors how to edit and other things. I believe it could fit perfectly in the template because it would be beneficial for editors who never worked on Wikipedia before. I see that some opposing view points realized that registration may be required, but a link from the template would take editors directly there. (talk) 21:10, 20 January 2015 (UTC)

Oppose (TWA)[edit]

  • Oppose because it requires users to register or login. (talk) 23:55, 29 December 2014 (UTC)
    • Well, in that case, we can just make sure we don't add a link to TWA on IP welcome templates like {{welcome-anon}}. That's no reason not to add a link on registered user talk pages, which is evidently what is being discussed here. — This, that and the other (talk) 01:34, 30 December 2014 (UTC)
  • Oppose unless and until it is converted to use the wikitext editor. There's no reason to encourage newcomers to use an inadequate tool.—Kww(talk) 02:48, 30 December 2014 (UTC)Apparently my conditions have already been met while I wasn't looking.—Kww(talk) 14:53, 31 December 2014 (UTC)
    • Kww, I don't understand this complaint. How do you think that edits like this and this happened, if not with the wikitext editor? WhatamIdoing (talk) 19:18, 30 December 2014 (UTC)
    • I'll confirm that all the editing took place through the standard wikitext editor. BethNaught (talk) 19:23, 30 December 2014 (UTC)
      • It might submit things through the API, so maybe that's what he meant. WhatamIdoing (talk) 20:27, 30 December 2014 (UTC)
        • The last time I played with TWA, it only demonstrated the use of Visual Editor, even though all edits it made were simulated and included edits that were impossible to accomplish using the actual Visual Editor. It even ran under Internet Explorer when VE couldn't execute under Internet Explorer. If that's changed, let me know, and I will withdraw my opposition.—Kww(talk) 22:11, 30 December 2014 (UTC)
          • I just tried it yesterday for the first time. If I remember rightly, it had me do a bunch of editing in the non-VE normal edit page (and didn't mention VE) — I'm running IE and have disabled VE, and nothing seemed unusual as far as I remember. I think the situation has changed. Nyttend (talk) 05:57, 31 December 2014 (UTC)
          • I believe that different projects have requested different default settings. I don't see anything in the non-talk-page edits that can't be done in VisualEditor, however. They're really quite basic. WhatamIdoing (talk) 00:42, 1 January 2015 (UTC)
            • Which isn't my point. VE is certainly capable of performing trivial edits, and can even do some moderately complex editing these days. Until it's complete, it shouldn't be taught to newcomers as the normal way to edit.—Kww(talk) 00:48, 1 January 2015 (UTC)
  • Oppose this is the only welcome template I use because I find it succinct and not terribly overloaded with links like almost all the others. It's short and to the point and currently doesn't include anything frivolous. Could we please keep it that way and add links to silly stuff like this to one of the other welcome templates instead? Beeblebrox (talk) 22:47, 24 January 2015 (UTC)

Curtailing Maintenance Template Spam[edit]

In the last few years I've noticed a profusion of maintenance template spam. At first we had maintenance templates that would warn readers about serious article defects, such as {{COI}}, {{NPOV}} and {{notability}}. These warnings served a purpose: to help prevent readers from placing too much reliance on questionable articles under development. Over time, more and more maintenance templates have appeared, such as {{Lead too long}} and {{lead too short}}. I propose that we establish a guideline that maintenance template should only be placed on articles for serious problems. Minor style issues, such as length of the lead, should be noted on the article talk page. There's no problem if the talk page suggestions are free form text or a predesigned template. The important thing is that we don't damage the user experience by cluttering articles with maintenance templates about relatively minor issues. Jehochman Talk 17:33, 2 January 2015 (UTC)

Interesting thought, though it would beg the question of what constitutes a major vs. minor issue. DonIago (talk) 18:49, 2 January 2015 (UTC)
It would be a great idea to cover that in a Wikipedia:Maintenance tags guideline. We don't need to presuppose the results. When there is a disagreement among editors, they can discuss it and then record the result in that one place for all to see. Jehochman Talk 20:57, 2 January 2015 (UTC)
  • I'll also note, after the attempt to move {{Orphan}} tags to the talk page, it gathering consensus, and then consensus being overturned because it has been established that maintenance tags can not feasibly be moved and maintained on talk pages. None of our bots or tools support it, and it has already been stated that since a major rewrite of the tools and bots would be required to do so, it isn't likely that is going to happen.
This doesn't mean I'm saying that reducing these tags are a bad idea or changing the way they are show is a bad idea. It shouldn't be very difficult to make the same kinds of adjustments to other templates as the ones made to Orphan so that they will be hidden with css after a certain amount of time so that they aren't seen in general most of the time except those users that want to see them such as WP:GOCE members perhaps.
Which makes me think, I'd really like to hear from the WikiProjects that use these tags. I've no idea which projects use which tags, but if someone can post a "please see" on the talk page of any project that might be interested, that would be great. I'll get WP:GOCE. :)
Another possible idea to filter these tags is to have some kind of WikiProject that is focused on the user experience (does one already exist?) that ideas for new maint tags could be proposed to. The project could assist in proper development or try to explain why the proposal would never work in a friendly manner. — {{U|Technical 13}} (etc) 14:16, 3 January 2015 (UTC)
Since when were maintenance templates supposed to "warn" the reader? I always thought the purpose was to identify issues for interested people to fix (if the tagger doesn't feel able to fix it themself), and to point out to readers something they might be able to do and so possibly get them to become an editor. Anomie 01:03, 4 January 2015 (UTC)
  • I thank Jehochman for bringing this up, it's something that's been obthering me ever since our community driven initiatives to clean up and improve New Page Patrolling were wrested from us by the Foundation. Admittedly they then gave us the excellent new New Page Feed and its associated Curation Tool, but after nearly 2 years of empirical operation some tweaks and improvements are desirable. The downside is that while occasionally the WMF devs will step in to repair bugs that cause downtime or malfunction, the Foundation considers this suite of software to be complet(ed) and will apparently not entertain according dev time to it.
As one of the most experienced users of it and well aware of its deficiencies, if I were a programer I would simply boldly rationalise those tags myself. Many of them are hardly ever used and the number of them originally grew when WP:Twinkle (and before that, WP:Friendly) was still the standard script for tagging at NPP and new things were added to it in GF on simple request to Azatoth who, if I correctly recall, is/was the main developer of Twinkle. I would gladly work with Jehochman or someone together to reduce these templates to a sensible and manageable number. I seem to remember doing some work on this some years ago with DGG but I can't locate the project it was part of. There may be something to be gained by looking at this. --Kudpung กุดผึ้ง (talk) 04:34, 4 January 2015 (UTC)
@Anomie: & @Technical 13:: Maintenance tags serve both purposes: to alert regular maintenance editors/projects to address the issues, and to warn readers that the content may not be factually accurate and invite them to do some editing. WP:NPP is quite extensive as a tutorial for patrollers ({{U|Scottywong and I wrote/rewrote most of it) but at the expense of keeping it as short as possible - and it's already long - we didn't address the use of the many maintenance tags, concentrating mainly on training the patrollers to get their CSD tagging correct and accurate. There was a project some time ago, again with DGG to make the texts of various tags less bitey, and we rewrote many of them. There was also some AB testing but I don't believe it was ever conclusive.
The solution to all of this of course is to improve the quality of patrolling and that may ultimately mean introducing some criteria of competency and experience such as we have for AfC and even uniforms to wear for rollbackers and PC reviewers. IMO, NPP is by far the most important of all our quality controls. --Kudpung กุดผึ้ง (talk) 04:50, 4 January 2015 (UTC)
  • Thank you all for your comments, especially Kudpung. I'd be happy to work on a list of the issues that we do need to warn our readers about. Mere style issues, such as length of the lead, sections that need expanding and so on could be relegated to the article talk page. We exist for the reader. We want to provide them a good experience. We shouldn't distract the from their reading with warnings about non-critical issues. How to best accomplish this I do not know, but defining the list of critical issues would be a good place to start.
This discussion is interesting, but let's not limit ourselves artificially. We have other choices beyond "display a big box in the article" and "display a big box on the talk page". For example, there could be a small indicator somewhere on the article page when an article has been tagged as "having issues". Clicking on this indicator could inform a reader that the article is out of date, that it is in need of copy editing, or that it is poorly referenced (these are just examples; we may want big boxes for some kinds of problems and a smaller indicator for minor problems). A regular non-logged-in reader of Wikipedia might not bother with clicking on, or even noticing, the indicator, but the tags behind the indicator would properly place the article in (hidden?) maintenance categories. Maintenance-oriented editors could use a Gadget to make the issues appear in a more visible way within articles, just as we can use CSS to display various errors that are not visible to civilians. – Jonesey95 (talk) 06:00, 4 January 2015 (UTC)
I agree here, but I would regard such things as being out of date as significant. Perhaps all the templates could be redesigned with a little less visual emphasis. I think moving "orphan" should be revisited, but at least this should be the sort of thing which could go into a problems section. I'll try to give a more specific proposal in a day or two. DGG ( talk ) 06:06, 4 January 2015 (UTC) .
I'm liking this alternate proposal too. Rather than changing the tags just change the display to be less "frightening" or "bitey" to newbies. (talk) 20:28, 4 January 2015 (UTC)
Perhaps the maintenance templates could be reconfigured to be collapsible, with a brief messge by default and a fuller explanation available should one choose to view it? DonIago (talk) 15:55, 7 January 2015 (UTC)

Thanks for pinging the Guild of Copy Editors, with its never-ending backlog :-). There's an excellent essay on tagging (particularly the overtagging section) that would work as a guideline. All the best, Miniapolis 15:23, 4 January 2015 (UTC)

Responsible tagging is another good essay which discusses particular tags. Miniapolis 15:27, 4 January 2015 (UTC)
  • Personally, I would prefer to have all problem tags on the article page itself. This makes it much more likely that someone will do something to fix the problem (certainly I have been motivated to fix problems in articles because I have been embarrassed to see tags on them) and also much more likely that when the problem is fixed the tag will be removed. Yeah, a finished, polished publication shouldn't have such glaring tags on it, but if an article is a work in progress, then I think the motivational benefit outweighs whatever frowny faces are made by people who remain readers but not editors. Some people appreciate the transparency and a peek behind the scenes, anyway. I don't mind the idea of making the tags a little less glaring as a compromise between the ugly factor and the helping-out factor. -- Beland (talk) 16:24, 12 January 2015 (UTC)
  • Bringing back the {{wikify}} template would help here - sure, it's vague, but it's better than a bunch of minor issues being spelled out at the top of the article. – Philosopher Let us reason together. 00:43, 21 January 2015 (UTC)

Revisiting past proposal – Viewdelete userright[edit]

I know that this idea has been around since the proverbial dawn of time, and a past discussion from 2008 flatly rejected this kind of userright. Almost seven years have passed, yet the reasons for opposing at the time are every bit as relevant today as they've ever been (with the caveat that RfA has become much harder to pass, a reality that I consider irrelevant to the merits of this proposal). Nevertheless, I figured it might be worth another shot – with some modifications.

Speaking as a non-admin, there have been a number of instances where I’ve wanted to review deleted material for research purposes. For instance, one time I was thinking of creating a replacement article for this one, based largely around its negative counterpart (but with stricter inclusion criteria). This has since been done, so the point is moot. At the time however, I faced a conundrum. In order for me to assess whether that was a good idea, I needed to know what the page looked like beforehand so as to develop a better understanding of why it was deleted. Having the ability to view these pages myself would have been far more convenient than asking an administrator for assistance. This is just speaking for myself; I’m sure there are many editors who would use that ability responsibly were it granted to them, but are not interested in full adminship or would not pass an RfA due to a lack of relevant experience. Another example would be Carrite. In 2013, he was nominated for adminship by Dennis Brown on a temporary basis so he could have the ability to review evidence in the Richard Arthur Norton ArbCom case without the tedium of having to consult administrators in order to do so.

The foundation has come out in opposition to any sort of initiative that aims to increase access to deleted (and therefore, sensitive) material. I'd imagine that their strong reservations still stand today, perhaps even more so than at the time. This brings me to my next point, and the major alteration to the 2008 proposal: what I’m proposing is not a tool that would be given out at an administrator’s discretion to any old editor asking for it via WP:PERM. Viewdelete would be granted following a community discussion similar to RfA, wherein the basic question being asked is: “do I trust this user with the ability to view deleted content?” Or, to put it in another light: “will granting this particular user viewdelete cause the WMF legal issues, put anyone’s information at risk, open the flood gates to obvious abuse on their part, or make a mess for administrators to clean up?” After a lengthy discussion (say, 4-7 days, depending on what is agreed upon by the community), either an administrator or a bureaucrat (whoever is tasked with the granting of this tool) will assess the consensus and come to a decision. The threshold for granting viewdelete would therefore be quite high.

Additionally, the restrictions placed on the application of viewdelete would be stringent. In particular, it must not be used for the following purposes:

  • Restoring content after it has been speedily deleted per CSD
  • Restoring content that was deleted based on community consensus at any XfD page
  • Revealing sensitive information for any reason whatsoever, whether publicly or privately

Ideally, administrators would have the authority to automatically revoke viewdelete in the event that it has been misused. I've still not worked out all the fine details of its implementation, which is something I figured could be handled by the community were this to go forward.

I feel that my proposal addresses most of the opposing points that were raised in the RfC from seven years back. Viewdelete would not be a userright that is given out to just anyone, but to people who are sufficiently tenured and thoroughly vetted by the community. The only question that remains for me is whether or not the WMF would be open to this particular suggestion; does this proposal address the question of legality to a sufficient extent for it to be implemented? If the community and the WMF are willing to consider this idea as it is phrased, then I propose we put it to a test run lasting around three months or so. Specifically, we would be looking to see whether or not the workload for the WMF and the oversight team is significantly increased. As this would not be given to just anyone who asks for it, but only to editors deemed trustworthy enough by broad consensus, I do not feel that the exposure of sensitive information would be an issue.

Thoughts? Kurtis (talk) 16:37, 4 January 2015 (UTC)

  • I'm in favor of it, obviously, but it's hard to see too much traction for creation of such a specialized user right. Carrite (talk) 00:53, 5 January 2015 (UTC)
  • Strong Oppose for the same reasons this usually gets opposed: would create legal issues with minimal-bordering-on-zero benefit to offset them. Think of it this way: Viewdelete is the most "dangerous" of the admin tools, at least in the legal sense, as revealing libelous or personal deleted info can't simply be reversed the way a bad protection or block can be. Therefore, the threshold for granting that right would be just as high as RFA itself. Anyone interested in it should just go through RFA. Andrew Lenahan - Starblind 01:33, 5 January 2015 (UTC)
(edit conflict × 2) Why should a perfectly capable and trustworthy individual be forced to undergo a full RfA and all the garbage associated with it to be able to see deleted pages? Say I don't want to be able to protect a page, I don't want to be hassled by other editors asking me to undertake admin tasks, or I don't care about the block status of other users. Why can this not be an option? Dustin (talk) 01:45, 5 January 2015 (UTC)
For the same reason you can't access a police station's evidence room without being a cop, or a bank vault without being a banker: you want keys to the kingdom, you get the scrutiny that comes with them. Hell, if anything passing an RFA is a pretty low bar for the all-you-can-eat buffet of libel, copyvio, and weird details of highschoolers' sex lives that comes with it. Really it would make more sense for Viewdelete to be available not to every admin but admins who have an understanding of libel and intellectual property laws in the US. Andrew Lenahan - Starblind 02:18, 5 January 2015 (UTC)
Admins are supposed to be janitors, not cops. they certainly don't undergo the rigorous (albeit occasionally flawed) training, supervision and vetting of the latter. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:03, 12 January 2015 (UTC)
It is the most "dangerous" of the admin toolbox, yes, but it is also the one least likely to be abused in the hands of a responsible editor. "I want the ability to view deleted pages and revisions" is not going to fly at an RfA – period. If you're not expressing any interest in dispute resolution, XfD, or really anywhere you'd expect to find an administrator, then the community would see no point in granting the bit. Being an administrator requires more than just being responsible; it requires discretion (as in, good judgment). The only real discretion I would expect from viewdelete is the good sense not to be going around and revealing sensitive information. Remember, I did say that the threshold would be very high. Kurtis (talk) 02:20, 5 January 2015 (UTC)
"it is also the one least likely to be abused in the hands of a responsible editor" Kind of by definition, in the hands of a responsible editor no tool is likely to be abused. But for a deceitful editor, I would say it's the most likely to be abused - because unless you actually undelete the page, it's not logged anywhere. So if someone was giving deleted information out off-wiki, it would be nearly impossible to trace. RFA looks at competency because that's really all we can measure. We generally just assume trustworthiness. Unless someone is actually caught lying or something, I don't know how we could have a community discussion purely about the trustworthiness of an editor that's not just a grudge-airing and is more reliable than a coin toss. Mr.Z-man 04:11, 5 January 2015 (UTC)
I can definitely understand your concern about the possibility of gaming the system, and about the difficulty of passing such a process. I'm not suggesting that viewdelete should be easy to obtain. Really, such a system would not be much easier to game than the one that exists now, assuming someone really wants to get access to that kind of information. I see people opposed at RfA for all kinds of reasons that have nothing to do with competence or trust: in this RfA, for example, an editor who is clearly trustworthy was denied access to the tools because he did not demonstrate sufficient experience in administrative areas to sway a large enough portion of the commentators into supporting him. If someone with a similar tenure to his were to apply for viewdelete, I'd imagine that they would pass. Kurtis (talk) 05:09, 5 January 2015 (UTC)
  • (edit conflict) My short answer would be: 'If you want to view deleted pages, then you must run for adminship.' I appreciate the time you have taken to post the above suggestion but I'm fairly sure that the Foundation would not allow it. Perhaps Philippe (WMF) could chime in here. Secondary issues are that creating yet another user right would create more bureaucracy - it would almost certainly need an RfA style application (with all its issues) for the right (so again, why not apply for adminship?). I'm not personally aware that the demand for such a right is sufficiently compelling, particularly as all proposals for unbundling admin tools are perennial failures.
Finally, I reject the notion that RfA has become much harder to pass:
The RfA system has increased its level of maturity since the watershed year of 2007 prior to which the tools were handed out following RfAs of very low !voter participation. We now have a very high turnout at each RfA and even the revered 100+ 'Support' RfA are now perectly commonplace. That said, the !voters at RfA are still very much a transient pool of users, so in reality the criteria are set anew for each RfA depending on who turns out to !vote. By 2014 RfA was also no longer quite the humiliating process it was when I started WP:RFA2011 and Mr Wales supported tha initiative with his famous "horrible and broken process" statement. --Kudpung กุดผึ้ง (talk) 01:42, 5 January 2015 (UTC)
The most important part of my proposal is where I outlined the hypothetical process as being community-driven. This is not like being granted rollback rights; it's much more akin to adminship. As I've said above, an administrator is not only someone who has proven themselves trustworthy enough to be granted access to a certain degree of sensitive information, they must also demonstrate an ability to make tough judgment calls and a willingness to partake in maintenance work or dispute resolution. No one is going to be granted adminship just because they would like access to deleted revisions, even if they were trustworthy enough to have such permissions, as that would be a virtual waste. Kurtis (talk) 02:20, 5 January 2015 (UTC)

I think this a bad idea. If a view-deleted editor later decides to become an admin, they basically would have to go thru a second RfA. If you want to unbundle admin tools, a better approach would be a user right to place limited blocks and semi-protects. Oiyarbepsy (talk) 04:51, 5 January 2015 (UTC)

I think the researcher permission only applies to seeing the revision history, as opposed to the content itself. The whole point of this proposal is so that ordinary editors don't have to go to an administrator to view deleted pages. If they are deemed trustworthy enough, they can do so themselves. Kurtis (talk) 15:46, 5 January 2015 (UTC)
Correct, it is much like a RevDelete where only the text is deleted. — xaosflux Talk 19:37, 5 January 2015 (UTC)
  • I agree with the sentiment of unbundling viewdelete from the mop and bucket for purposes of article creation. Wbm1058 already made the excellent point of using REFUND for that purpose. I oppose the nomination's idea of an RfA-like process because RfA is probably too stringent. I don't think the flag should be given out by any single admin, either. Whatever the process, I'd recommend the permission be temporary and responsive to a specific request. "In order to write an article on X I'd like to see the deleted versions of Y and Z.". If the flag automatically hits sundown we can limit contempt for the permission. My question would be, how often does anyone really need to see a deleted version? Chris Troutman (talk) 20:24, 5 January 2015 (UTC)
  • Strong oppose per my concerns voiced at the debate at Commons. This is a solution in need of a problem. --Tom (LT) (talk) 22:35, 5 January 2015 (UTC)
    There is or might be a real problem in need of a simple solution: Some days ago I stumbled over two files on commons arriving there as thumbnail of what still was or used to be a decent image here. I think that license reviewers (folks with this right, a bot if that's all what it takes to figure out that 100KB on commons cannot match a deleted 1MB here) should have the right to review what exactly happened here years ago. –Be..anyone (talk) 07:51, 6 January 2015 (UTC)
  • I've read all this and I simply do not believe there is a real problem that needs solving here. As creating this user right would be a long and contentious process it does not seem worth the effort. Beeblebrox (talk) 23:33, 6 January 2015 (UTC)
  • Oppose per all the usual reasons. Let's just keep it as a package deal. -- œ 02:58, 7 January 2015 (UTC)

From what I can see, most of those in opposition appear to be sysops. Not to say sysops' opinions don't hold equal weight, but I think it would be best to do more discussing before going into all of that !vote stuff. Dustin (talk) 03:04, 7 January 2015 (UTC)

  • Oppose, IIRC the WMF has explicitly said that users must go through RfA or an equivalent process to get this, so there's really no point in having it separate. ansh666 05:58, 7 January 2015 (UTC)
  • Oppose as a solution in search of a problem. Stifle (talk) 14:04, 7 January 2015 (UTC)
    • This isn't personally directed at you Stifle, but I'm really beginning to hate this sentiment. It's used to rebut just about any proposal, and it says very little. Proposers spend a long while typing detailed descriptions of why a change might be beneficial, only to be dismissed with such a flippant and nearly meaningless sentiment as "solution in search of a problem". In this particular case, the proposer even outlined a very specific situation in which this restriction was a problem for him. Stifle, please don't feel personally obligated to reply to this, as like I said, this isn't directed at you as much as a general comment on the proliferation of proposals getting shot down on these grounds which boil down to "the status quo is just fine, change is scary and unnecessary". Gigs (talk) 17:09, 7 January 2015 (UTC)
  • Oppose - First, there have been successful single bit need RfAs in the past, so the current RfA process can be used in that case. And since RfA-esque community support is needed for the viewdelete right anyways I don't see the benefit of breaking it out as compared to say something like template editor. I disagree that RfA's have gotten harder having !voted in them over the years except for the edit count inflation they seem less contenious these days although fewer in number. I can see myself possibly supporting other bits being split off ( and have done so in the past ); but—especially given the requirements from legal—not viewdelete. PaleAqua (talk) 17:30, 8 January 2015 (UTC)
    • "there have been successful single bit need RfAs in the past" - When was the last? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:06, 12 January 2015 (UTC)
      • Most recent such request that I recall was [Wikipedia:Requests for adminship/Trappist the monk]], but I didn't comment in all the RfAs this last year so might have missed another. PaleAqua (talk) 22:50, 12 January 2015 (UTC)
  • Oppose - the {{cent}} headline for this discussion asks whether we should "grant highly trusted users with the ability to view deleted content through a consensus-driven process". WP:RFA is the "consensus-driven process" by which the community "grant[s] highly trusted users" with this ability. The Wikimedia Foundation have also stated that there are legal issues with this kind of change. I'd certainly be happy to vote support in an RfA that sought to have time limited access to deleted revisions and pages if I trust the user in question: if someone were to propose allowing bureaucrats more latitude to, say, close an RfA as "promoted for a temporary period of X months" rather than either promoting or not promoting, then the RfA process could accommodate this kind of request. The only reason I can see to have a non-RfA process to grant this right is so that there is less participation and consideration given to a request for the unbundled right rather than the full administrative toolset. I'm not comfortable with this user right being granted with less participation than an average RfA gets. None of that changes the fact that RfA does suck in a lot of ways. The answer to that is to try and find ways to fix RfA rather than short circuit the valuable democratic oversight function that RfA provides. —Tom Morris (talk) 16:04, 11 January 2015 (UTC)
I was actually thinking that "viewdelete" requests could take place on the same page as RfAs and RfBs. I wasn't intending to suggest that this be a process where scrutiny could be evaded. Kurtis (talk) 16:51, 11 January 2015 (UTC)
  • Oppose in three points. First, I don't really see how it would be useful to create a bureaucracy to give out view-delete rights. Going based on my own experience, I can only think of one deleted article in the nine years I have participated on Wikipedia that I have ever wanted to view post-deletion. And that was only because the result of the discussion was merge and delete, but the merge was botched and a citation was lost. How many times can any editor really say they've needed to access content from a deleted article? Is it really that many times to justify having this ability enabled indefinitely? I don't believe it is.
Secondly, I believe WP:Requests for undeletion and CAT:RESTORE provide perfectly valid options regarding deleted content (CAT:RESTORE is a list of admins who are willing to provide deleted content). If an editor believes they are justified in viewing deleted content, then it shouldn't be too difficult to justify that at WP:UND. And to that point, as I've been thinking about this issue, one question comes to mind: does an editor need access to deleted content urgently? As the title of the essay WP:NORUSH goes, "There is no deadline."
Lastly, and above all else, there is a legal dimension to this proposal. If a representative of the Foundation can no longer say to a client's lawyer that sensitive deleted content is only viewable by "trusted administrators," then the project appears to be weaker. No matter how much trust we can invest in these certain editors who would be approved for the view-delete right, they are still not administrators. I believe it is in the best interest of the project that those people with view-delete be administrators. --hmich176 17:52, 11 January 2015 (UTC)
  • Oppose. I gave my main thoughts in my earlier comment. Now that voting has begun, I'll just reiterate that Adminship is about trust and competency. If you give a user only one of the tools and not all three, is it because you only have 33% trust and s/he is only a third as intelligent as a full admin? Anyone who wants one tool should be clever and industrious enough to convince the community that s/he would be competent with all three. --Kudpung กุดผึ้ง (talk) 20:07, 12 January 2015 (UTC)
    • If we refuse to give a user the tools, that says something about our trust. But if the user specifically asks for only one, that says something about the user. Maybe it says he doesn't expect a successful request. Maybe it says he doesn't want to be hassled by requests to block people. Maybe it even says that he doesn't want French spy agencies to arrest him and demand that he delete the article on Radio station military Pierre-sur-High again. The other editor's choice doesn't say anything about my trust in that editor. WhatamIdoing (talk) 22:35, 14 January 2015 (UTC)
  • I support the unbundling of the viewdelete and undelete user rights in the circumstances that I outline below and also the creation of some new user rights that I outline below.
    • I am under the impression that unbundling the viewdelete and undelete user rights would be acceptable if the rights were granted by a process that is practically identical to RfA (ie a community !vote, conducted over several days, with the opportunity to pose questions to the candidate etc). I think this would allow the same level of scrutiny that presently takes place at RfA.
    • We might also consider implementing multiple levels of deletion to avoid the problem that some deleted material is considered sensitive. What I propose to call "deletion level 1" would be for articles that are deleted for legal reasons or are otherwise considered to be sensitive (eg articles deleted as copyvios or for WP:BLP issues). What I propose to call "deletion level 2" would be for articles that are deleted for harmless reasons (such as possibly an article about a person who died in the year 1800, or a book published in that year, that was deleted solely on grounds of notability, which contained substantial content verifiable with reliable sources, and not sensitive in any way). It seems to me that the viewdelete and undelete for such a hypothetical "deletion level 2" could be handed out more freely, possibly at PERM or perhaps even given to all logged in users. This would be useful in that we frequently make very bad mistakes about notability (because GNG is so subjective and the SNG are incomplete in their coverage) and certain aspects of WP:NOT, such as failing to transwiki content to sister projects or deleting articles which ought instead to be rewritten or merged per WP:PRESERVE, and so forth. (And some of our exclusionary criteria are questionable, and consensus can change, and we might from time to time abolish particular exclusionary criteria, necessiting review of possibly large numbers of deletions done under them).
    • WP:REFUND is an extremely inefficient means of reviewing or restoring large amounts of deleted content, because it uses two people to do the work of one person and requires discussion between them that may be unnecessary. It is therefore not a viable alternative.
    • Since anyone can remove a PROD for any reason, and removed PRODs cannot be restored, it is not clear why only an admin can undelete an article deleted as an expired PROD. WP:REFUND appears to be an innefficient process for doing this. James500 (talk) 15:44, 14 January 2015 (UTC)
I indented your points to make it clear at first glance that it's one full statement instead of multiple unsigned comments. ansh666 21:45, 18 January 2015 (UTC)
  • Oppose - this is maybe a bit stale but I'm adding comments here anyway. I think that viewdelete is a right best left with admins. It's not terribly difficult to get an admin to help with access to or review of deleted content when the situation is appropriate, and whether or not such a request is appropriate is a decision best judged by admins, in my opinion as a non-admin. If a proposal to unbundle the deletion rights nonetheless requires candidates to be subjected to a process identical (or reasonably similar) to RfA, then it's not better than just making them run the RfA gauntlet. And I do think that such an unbundling should require such a process. Ivanvector (talk) 20:27, 23 January 2015 (UTC)

Proposal to address Admin misconduct[edit]

Hello all. I am proposing this based on the recent ARBCOM case talk page statement 3.Administrator misconduct is our responsibility because the community has failed to come up with a workable community recall process. If a call is made to make it editor business I think we should heed that call.

My proposal is simple; essentially we would run a reverse RfA (60% threshold) for the community to decide if conduct is severe enough to remove the admin from their position. The filer would be given 500 words and 50 diffs, the admin 500 words and 50 diffs and any additional individuals may submit 100 words or 10 diffs if they feel something is overlooked, with judicious hatting of irrelevent material. Any users that would be considered involved with regards to the admin would not be counted in any consensus phase.

I believe this will help in two ways. First the community has a greater ability to hold people accountable, and the exception to involved individuals will curb the axe to grind concept. Second RfA should become easier, since the individuals who are in that slot can be removed much faster if the community is shown issues with the actions taken. Granted the actual removal of tools will still need someone with rights but I think this would be a positive step for the community. Thoughts? Am I off my rocker and should I climb back to my hole? Tivanir2 (talk) 17:55, 12 January 2015 (UTC)

This is a perennial proposal and if you want to get it off the ground proposing solutions the issues of the possibility for abuse and requirements for filing would be the best way to go about it. Sam Walton (talk) 19:37, 12 January 2015 (UTC)
It might be helpful to look at how they do it over at the Spanish Wikipedia. (The translation is clunky, I know, but it's readable.) In my opinion, it seems like a sensible and fair system, although a few minor modifications could be made. Apparently, they haven't yet fallen apart, so it is possible. I think we just need to be bold and take a few chances. --Biblioworm 20:22, 12 January 2015 (UTC)
In due course it could do with some qualifiers re bad-faith or needlessly repeated recall attempts, and some indication of who determines the consensus. But i like the basic principle. -- Euryalus (talk) 21:23, 12 January 2015 (UTC)
Seems like a good proposal. (talk) 22:11, 12 January 2015 (UTC)
An Arbitrator, speaking for himself alone, doing a bit of off-the-cuff people don't appreciate our behind the scenes work enough whinging (in response, to be fair, to some non-Arbitrator whinging) as part of a multi-part comment isn't a solid basis for a major shift in policy. It's probably not a good idea to frame your proposal that way.
In any case, can you actually think of any real examples of admins who would (or should) be desysopped by this process that you can't deal with through existing processes? I mean, if you can clearly state your case in 500 words and 50 diffs, then congratulations—you can file a request for arbitration. If it's a clear-cut case – and it doesn't involve misconduct by other editors that the ArbCom properly needs to address – then the ArbCom can deal with it expeditiously by motion. (Indeed, it has done so on a number of occasions.) Heck, cases don't even need to reach the stage of acceptance or motion—admins faced with such filings may also resign their bits without being compelled by ArbCom action. (This has also occurred a number of times.)
The solution to the mistaken perception that we cannot desysop admins who behave badly isn't to (re)invent a noisy, flawed, unpleasant new process. It's to better educate editors who hold this misconception about how to use existing processes. TenOfAllTrades(talk) 22:45, 12 January 2015 (UTC)
As the whinging arb in question, my remark was specifically about off-wiki backchannel stuff. Public cases involving a single admin and their misconduct are no more difficult than any other (and can often be handled summarily by motion). The issue is that, absent a community process, we get a large amount of email making all kinds of accusations about admins and these really need a process, perhaps with an investigative element, that falls short of a case, to handle them.  Roger Davies talk 09:03, 13 January 2015 (UTC)
The emails and accusers should be redirected to WP:TEA or /dev/null as appropriate. Stifle (talk) 10:18, 14 January 2015 (UTC)
If we need to modify the amount of text and diffs we can. This proposal is mostly to get the ball rolling, and if it can be handled without having to rush to ARBCOM each time we feel there are admin issues I think that will help both ARBCOM and the community. RfA is so difficult because the community is handing you tools and it is harder than it should to revoke them if the person abuses it. As always if requested we can always allow extended requests, 500 and 50 were just arbitrary numbers I used from the initial filing request for ARBCOM. I will be checking on the spanish wiki to see how they do it at the request of another editor. Tivanir2 (talk) 11:38, 13 January 2015 (UTC)
Would it be possible to get rid of the "discussion" portion entirely? Frankly, the interminable and prejudicial chatter is off-putting to many/most. Could we not invite only the posting of diffs and allow uninvolved members of the community to decide for themselves whether an abusive pattern worthy of desysop exists? • Astynax talk 18:56, 14 January 2015 (UTC)
  • This is a sensible and simple proposal to address this issue in a community-centric way. --Guerillero | My Talk 00:00, 13 January 2015 (UTC)
  • Support I usually don't touch these pages, but this seem like a wholly sensible proposal. I'd often wondered how sensible it for an administrator to define their own recall criteria. --ceradon (talkcontribs) 09:23, 13 January 2015 (UTC)
  • Support tweaks perhaps needed to length limits to evidence, timeline before !voting, threshold. Support in principle. Hipocrite (talk) 12:59, 13 January 2015 (UTC)
  • Oppose — We have a RfA system which a huge segment of the Wikipedia community feels is broken and this is a proposal to allow it to be revisited for any administrator again and again and again. Having ARBCOM continue to do it is infinitely more preferable to this idea. Regards, TransporterMan (TALK) 14:50, 13 January 2015 (UTC)
Two responses. First, I think a lot of editors would be more likely to support candidates for admin if they knew they could lose the right more easily. Second, it seems that requests for admin is not the disaster it used to be. The trolls who post useless garbage are mostly gone and the atmosphere isn't all that nasty anymore. Oiyarbepsy (talk) 15:48, 13 January 2015 (UTC)
  • I'm willing to support if someone can convince me that the process won't become a lynch mob like WP:CSN, WP:QP, etc. Stifle (talk) 16:26, 13 January 2015 (UTC)
That was the reasoning behind not counting involved parties. Also I figure people could move to hat sections if it clearly looks like someone is trying to get revenge, which would be a quick link to conduct problems for refusing to drop the stick over at ANI. Tivanir2 (talk) 16:34, 13 January 2015 (UTC)
Even so, you would need to look art everty dispute the admin ever dealt with to find all involved parties. Some users may have long memoriy when it comes to things like this. עוד מישהו Od Mishehu 15:56, 15 January 2015 (UTC)
  • First of all, I have to call bullshit on the idea that "Administrator misconduct is [ArbCom's] responsibility because the community has failed to come up with a workable community recall process". I'm old enough to remember this fiasco, in which an admin was properly recalled by the community, but refused to step down. ArbCom ruled that recall was a strictly voluntary process, and that the rest of us were suckers for believing in a campaign promise which they refused to enforce. Every thinking person realized at that point that no community process was workable—no de-adminship process is workable unless ArbCom is willing to enforce it. So what really happened is that the community had a process (albeit an imperfect one), but when the rubber hit the road ArbCom didn't back it up and the credibility of the community process collapsed. Granted, this was many years ago—ArbCom has changed a lot, as has Wikipedia—but the current state of affairs was very much created by the actions of previous iterations of ArbCom.

    As for solutions, I'd certainly be open to some kind of community process. I guess I'm pessimistic about the current community—I've noticed that the quality and cluefulness of input at noticeboards like WP:RS/N and WP:BLP/N has sunk to the level of "useless and probably dangerous", so I'm not sure how productive a massive community de-adminship discussion would be. A different option would be to appoint/elect an Admin Review Board consisting of experienced admins and non-admins, who would hear and screen admin-abuse cases. This Board could either be given authority to desysop people themselves, or could decide which complaints had enough substance to pass on for review by ArbCom. Either way, this sort of delegation would likely reduce ArbCom's workload. I think that similar ideas have been proposed in the past and not enacted, so there may well be a fatal flaw I'm overlooking, but those are my 2 cents. MastCell Talk 19:46, 13 January 2015 (UTC)

    The simplest thing may be to make Recall compulsory then? Cas Liber (talk · contribs) 19:52, 13 January 2015 (UTC)
    Do you mean in the sense that all admins would have to be open to recall, or that admins who are recalled would be compelled to step down? MastCell Talk 20:02, 13 January 2015 (UTC)
    I believe they meant both. If a smaller subsection of editors and admins are selected for the duty that would also be fine though declaring who is fit and unfit to hold such a position will be an interesting process. I essentially meant with the original proposal that once it was discussed by the community there would be a single person or perhaps even ARBCOM that would enforce the decision. This process I was putting forward is by no means suppose to be voluntary, if someone can show how an admin is abusing their power it would act similar to ARBCOM with immediate removal of tools. Granted identifying the enforcing individual (hell even if we appoint a single individual in the capacity that this is all they do) will cause some issues, but I never envisioned this proposal to lack teeth. I don't like playing useless merry go round. Tivanir2 (talk) 20:14, 13 January 2015 (UTC)
    I agree with MastCell's first paragraph. Stifle (talk) 10:17, 14 January 2015 (UTC)
      • I also agree with MastCell's first paragraph & the first two sentences of the second paragraph, though my pessimism is not based on those two noticeboards alone. Ncmvocalist (talk) 14:32, 14 January 2015 (UTC)
  • comment - Could start with a community ban for 1 week. If that works nicely make it a month etc (talk) 08:20, 14 January 2015 (UTC)
  • Oppose - I believe that the type of admin who, if such a vote started, would have the lowest chances of remaining an admin - is the type who enters heated conflicts and tries to solve problems - as the solutions would tend to satisfy no one - or the type who deals with highly controvertial issues, where any solution would xeem wrong to many users. Unfortunately, these are also the most important types of admin we need to retain. עוד מישהו Od Mishehu 10:44, 14 January 2015 (UTC)
    True but there is also a difference between an admin that makes tough calls and one that actually violates usage of tools. As a community I like to think that the average editor can do the "well I think they have made questionable calls, but they didn't violate usage of tools." I think the smaller subset discussed by mastcell might be a better plan; also it is possible we could have a rotating pool of people that can deal with this so if anyone would be considered involved with the admin they can recuse and we have more available for decisions. The hardest part is vetting people to ensure they actual know the policies, since that is something that is hard to quantify. Tivanir2 (talk) 13:55, 14 January 2015 (UTC)
    The editor who feels wronged by this admin would probably be more likely to voice his/her opinion than the average editor - partly because the average editor would need to look into the background of the complaint and decide whether or not there was actually a violation, while the editor who feels wronged already knows what the answer is (remove the adminship) and just needs to read the other opinions of users who said so (there will always be at least one, the nominator) and word the reasoning. עוד מישהו Od Mishehu 17:58, 14 January 2015 (UTC)
    I don't think so. MastCell certainly fits all of your criteria (enters conflicts, deals with controversial areas, tries to solve problems), and I really can't see anyone trying to recall him. Perhaps the kind of admin who not only works in heated areas but does so abrasively and offensively might be at risk, but perhaps it would actually be better for us if admins without good social skills didn't work in the most difficult areas, no? WhatamIdoing (talk) 22:57, 14 January 2015 (UTC)
    I didn't say that admins like MC would be nominated for recall all the time; I said that should such a request be made, they would be at a distinct disadvantage. No admin would be immune to having a recall request made against them; the question is, how likely are they to retain their adminship once such a request is made - and even the civil admin with good social skills, if they handle these areas, are at a disadvantage, while those are the admins we have the highest need to retain. עוד מישהו Od Mishehu 05:45, 15 January 2015 (UTC)
  • Leaning toward support but only leaning because I can see too many ways for such a system to be gamed too easily if there are not additional, very well defined rules in place before a system is actually implemented. John Carter (talk) 15:34, 14 January 2015 (UTC)
  • Tentative support speaking for myself only, though a new member of arb com, (and based on only what I have seen from the outside) I see this as dealing not with cases of gross misuse of tools in a specific incident, which as far I can judge arb com has handled adequately, but with generally subpar administrative behavior, which I doubt that arb com handles at all--nor would I personally want it to. That's the sort of judgment the community should be making, just as it makes the decision to appoint new admins. DGG ( talk ) 16:39, 14 January 2015 (UTC)
  • Tentative support Seems good in generalities, but not sure if the specifics would hang us up too much. --SarekOfVulcan (talk) 17:03, 14 January 2015 (UTC)
  • Support. As the user who initiated the old case where ArbCom refused to validate the community process, I applaud User:MastCell's first paragraph above.[1] I didn't think anybody remembered, but it was a proper disgrace, and disinclined me for many years from having any truck with the committee, whinge whinge. (Though I made an exception for RFAR'ing Jimbo.) It's for sure not easy to desyspop misbehaving admins. I wish it was easier. I understand the risks of an anti-RFA process being flooded by users with personal grudges, but I think it's worth trying. Note the support above from three arbitrators, Euryalus, Guerillero and DGG, who apparently understand the need for a community process. If it's reasonably easy to yank the tools in cases where they don't work out well, even without blatant long-time abuse of the arbitrable type, it would be less dangerous to create new admins to "give them a chance", and then we could lower the bar for new admins. We sorely need new admins. A process which can be discontinued if it turns out not to be useful is a fairly cheap experiment, surely. We should stop eternally talking about de-adminning processes and try something for once. Bishonen | talk 18:58, 14 January 2015 (UTC).
    In my last RFA, there were only 3 or 4 opposes out of 37 that I'd put in the "personal grudges" category, and I would expect that most would be lower than that. --SarekOfVulcan (talk) 19:45, 14 January 2015 (UTC)
    I can personally think of at least 3 people in the last year whom I did not support at RfA, but whom I would have supported had a process like this been available. DGG ( talk ) 19:49, 14 January 2015 (UTC)
  • Weak support I suspect there will be some conflict in power since only ArbCom has the authority to desysop admins who do not wish to give up the tools. Though I suppose that'll be remedied if ArbCom just follows the community will on this sort of thing. I also don't want this to purely be for desysopping. Admins should get warnings not to do X, or that Y is in violation of Z policy and that they should generally not do it. I'd rather not shoot them with a shotgun on first attempt, plus that would just lead a lot of !oppose votes to the anti-RfA. Though the oppose !vote did make a great point; Wikipedia is full of ideological battles, users who have felt wronged, and the like. Some person getting involved in a dispute with an admin may, after losing said dispute, watchlist the page for Anti-RFA and latch onto the first complaint against the admin. An unpopular admin decision isn't always one that went against the rules and policies following. Granting that, I weakly support it because I can see some future abuse in the future, but that yes, we shouldn't have to go through a 3 month long ArbCom case to get rid of bad admins. To add, there once was a proposal for an 'admin review' board where you could request outside input on an admin's actions and see if community consensus affirmed such. Maybe this could be a sequential step to that. Tutelary (talk) 20:01, 14 January 2015 (UTC)
  • Information The German Wikipedia has a recall system that mostly seems to work out for them, on balance. I believe that the rules run something like this: if any 50 experienced editors (defined in detail; de.wp has actual votes, and you must meet certain requirements to be able to vote) vote in the space of 30 days to have your admin bit removed, then you are de-sysopped. Any de-sysopped editor is permitted to be re-elected again, through the normal RFA process, immediately. If you survive a de-sysopping vote, then a second vote cannot be opened again for another 365 days. It's not perfect, and I can think of at least one way to game it, but they seem to be satisfied with it. WhatamIdoing (talk) 22:57, 14 January 2015 (UTC)
  • Oppose. Comparing Reverse-RfA with RfA is like comparing apples with oranges. While I am constantly deliberating over the issue of desyoping or sanctioning poorly performing admins (I recently launched an RfC myself), I oppose reverse RfA in any shape or form. As Od Mishehu points out, truly active 'front-line' admins would certainly be subjected to mob rule and kangaroo court much in the same way that 'oppose' votes on RfA are often vindictive. While the comments of Roger Davies are absolutely valid, here or anywhere else, the only solution, IMO, is a rotating committee of respectable and highly regarded users and/or 'crats who can adjudicate without the background noise of the anti-admin brigade and the peanut gallery, and without the monumental red-tape of the Arbcom. --Kudpung กุดผึ้ง (talk) 07:48, 15 January 2015 (UTC)
    The "monumental red-tape of the Arbcom" is an oft-stated but seldom-examined issue. If we look at the most recent 8 instances at Wikipedia:Former administrators/reason – about a year's worth, going back to December 2013 – where editors' bits were removed under circumstances where there were issues with their conduct (as opposed to lapsing due to inactivity), we find:
    • 4 instances where an editor resigned "under a cloud": Nikkimaria, Kaldari, Jclemens, and Eloquence. (Of those, Jclemens resigned after an ArbCom case request was filed but before it was accepted. Eloquence resigned after a case had been opened; the case was suspended with a motion taking formal notice that the resignation occurred under a cloud.)
    • 2 instances where an editor was desysopped by ArbCom motion: Secret and Toddst1. (Technically, Toddst1 wasn't desysopped, though the effect was the same. He announced his departure from the project, and the ArbCom barred him – by motion, on pain of desysopping – from using his tools without ArbCom's explicit permission should he ever return.)
    • 2 instances where an editor was desysopped after a full arbitration case: Kafziel and Nightscream.
    Some interesting features start to pop out. In the majority of instances now, desysoppings aren't the result of standard-issue, complete, month(s)-long Arbitration cases. Former admins are often capable of reading the writing on the wall when faced with strong community disapproval and well-formed objections to their conduct. The pressure of an ArbCom filing – potential or actual – or the opening of a case is often sufficient to bring about a resignation. (Worth noting is that under-a-cloud resignation has been a specific, codified bar to re-sysopping for only a few years; as far as I can tell, the relevant language was added to WP:ADMIN sometime in 2012. It seems to be a very constructive and useful way to avoid or terminate more cumbersome or formal processes of any flavor.)
    Among the instances that do demand a formal finding by ArbCom, some significant fraction are handled rapidly, by motion. The desysopping of Secret took 15 days from his misuse of the tools to enacting the motion. For Toddst1, it was 7 days from the filing of the first request on RfArb to the motion barring Toddst1 from using his tools.
    Overall, in the last 8 instances of problematic admin conduct, 6 had the tools removed without requiring a full ArbCom case. The perception that the only way to see a 'problem admin' desysopped is through a lengthy arbitration is mistaken, and it would be an error to promulgate new policy predicated on that misconception. Desysoppings through full ArbCom cases are now a minority. TenOfAllTrades(talk) 19:05, 15 January 2015 (UTC)
  • Support. At this point, I support any community-driven desysop process, no matter what the details are. If we finally get a critical mass of people and a proposal is adopted, then it can be tweaked if there are problems with it (i.e. if it turns out it can be too easily co-opted by trouble-stirrer-uppers). But if we wait until we have a perfect proposal, nothing will ever happen. It so happens that I like Mastcell's idea of an admin review panel thingy best, but that doesn't alter the fact that I also support the OP's proposal. --Floquenbeam (talk) 14:17, 15 January 2015 (UTC)
  • Without controls, this proposal will mean that admins can no longer block for disruption or patrol venues like Arbitration Enforcement. Otherwise, once they have sanctioned a critical mass of editors, they will be subject to interminable, retaliatory desysop proposals. If you do something like this, there needs to be at last one restriction: (1) editors may not propose or comment on desysop proposals for any admin who has ever sanctioned them. Probably there should be a second restriction: (2) any editor sanctioned within the last year, and the sanction was not lifted as an error, may not propose or comment on desysop proposals. We can not let editors prone to disruption use a desysop process to create more disruption. On balance, I think our system using ArbCom is lousy, but the best one possible. Jehochman Talk 14:52, 15 January 2015 (UTC)
  • Oppose as written - Multiple editors have noted that, without significant restrictions, a community-based recall system would mean that admins who take part in activities such as blocking for disruption would face recall from disruptive editors. A community-based recall system that had restrictions sufficiently strong to avoid that problem might be so complicated that it didn't work. Unless I see a community-based recall system that already contains provisions that protect active admins from being desysopped by disruptive editors, I have to oppose. As it is, without seeing what the fixes are, community-based recall gives the lunatics the keys to the asylum and puts the employees in straitjackets. (In a few cases, "lunatic" isn't a figure of speech. A few disruptive editors really are crazy. Most just act in good faith and don't understand collaboration) Robert McClenon (talk) 16:04, 15 January 2015 (UTC)
  • Support; an actually sensible and workable admin recall proposal! I would agree with DGG's sentiment that there is at least one editor who I recently opposed at RfA who I would have certainly supported had a binding community recall process been available. I trust that the bureaucrats will discount obviously invalid or grudge votes at a recall. That is why they are elected to the position they are: they should know how to judge consensus when promoting admins, and should know how to judge it when removing admins as well. StringTheory11 (t • c) 20:24, 15 January 2015 (UTC)

All of these are good points. I am trying to improve the overall setup in the below posts, and I hope I encapsulated everything. If I did miss something let me know. I mainly put this here to get the ball rolling; I think this proposal is doable with the right input and caveats, which will give us a much better community process. Tivanir2 (talk) 16:16, 15 January 2015 (UTC)

I was actually inclined to support the above, but the tweaks below lead me to a rather different inclination - so I don't think I have a view. You might be getting ahead of yourself with the tweaks maybe. Ncmvocalist (talk) 12:20, 17 January 2015 (UTC)
  • Oppose i used to be strongly in favor of a community-based binding recall process for admins, but I have come to realize that such a thing would inevitably have a chilling effect. We would see good, bold admins who deal with problems head on being constantly challenged by the vocal minority who basically hates all admins and thinks we are all corrupt. Good admins would end up walking away rather than facing these constant challenges, and we'd be left with milquetoast admins scared to do anything real. (yes, these do exist, in larger numbers than you may think)
Additionally, having participated in arbcom desysyopping proceedings both as a filing party and an arbitrator I find that this process actually works pretty well. In the case I brought to the committee I came correct, I had evidence of recent misuse of the tools and evidence that said misuse was part of an ongoing pattern going back some time. It is only when you have such evidence that an admin should be removed, and they were. And during my term as an arb we removed several other admins who showed a pattern of poor judgement. Is it a perfect system? No, but it is better than this idea. Beeblebrox (talk) 21:05, 18 January 2015 (UTC)

Tweaks to the above[edit]

Given input and good information people have brought up I propose the following to help streamline it a bit more. The new system will require:

  • 60% threshold to remove an admin
  • will consist of at least 30 (down from 100) editors who have contributed at least 1,000 main space and conduct related boards
  • no individuals may vote in any decision of an administrator that has performed a block or other administrative action towards them within the last six months (down from one year) (they may include evidence for reference to establish a timeline)
  • the boards will be 200 (down from 500) words and 20 (down from 50) posts for the originator
  • 200 (down from 500) words and 20 (down from 50) diffs for the admin plus additional space to rebut any other individuals that present evidence
  • 100 (down from 200) words and 10 (down from 20) diffs for any additional people presenting evidence

If it appears that administrators are being targeted for action due to a dispute the community may vote to nullify the request. This will take:

  • 15 editors that have not interacted with either party
  • The discussion shall be closed by a group (at least three) editors that have not weighed in, and only after a minimum of 7 (down from 14) days. Unless the clear consensus is landslide (90%+) at 7 days, the process should run 14 (down from 30) days to allow the maximum number of particapants to weigh in on the behavior discussed.
  • If the admin has participated in areas with WP:DS all editors for that article shall be unable to vote in the current proceeding. This applies to all articles within the last six months. These editors may still present evidence.

The filer will be sent to ANI for disruption and/or tenditious editing. No events with fewer than 30 participants will be considered passed (so we have a threshold of at least 100 editors) and IP users will, unfortunately, not be able to vote due to SPI concerns though they still may offer evidence and comments for others to consider. Thoughts on the slightly updated and more defined process? Tivanir2 (talk) 16:06, 15 January 2015 (UTC)

I actually think 60% is too high. 50% would be better, and I could probably get behind 40%, with proper convincing. :-) After all, if only 40% of the community is behind you, you probably shouldn't be an admin, and even if it's as much as 60%, that's significantly under the discretionary range for passing an RFA. I think a year is too much -- 6 months would be better. I'd also suggest cutting out the hard limits here - they're either too high or too low, and I'm not sure which. --SarekOfVulcan (talk) 19:47, 15 January 2015 (UTC)
We can always modify the numbers as people weigh in. If 6 months seems more reasonable than a year on consensus we can always modify that. If people can come up with hard numbers that meet consensus I am more than happy to modify my tweaked version. I view this entire process as draft and revision not necessarily a finished product as it needs more input before put into motion, since at a minimum I think we need to have a larger community input altogether before we declare it a viable process. Tivanir2 (talk) 20:20, 15 January 2015 (UTC)
I would add something, although I'm not at all sure of the phrasing, regarding not allowing participation by individuals who have been on "one side" of an argument in which an admin acted to block or ban a problematic editor. Some of our most contentious disputes really are of an "us vs. them" type, at least at some level, and allow reprisals from friends of a blocked individual would be very likely. John Carter (talk) 20:31, 15 January 2015 (UTC)
Would an expansion to include editors that have been in any articles under DS being disqualified except for evidence phase as well alleviate these concerns? I am trying to keep this as unrestricted as possible while making sure we don't have gaming of the system. Or we could put that any specific matters that happen in DS articles are referred to ARBCOM, which would prevent us eliminating their load but it should still reduce it significantly. Tivanir2 (talk) 15:06, 16 January 2015 (UTC)
But what color will you paint the bikeshed? And have you reviewed the dozen or so previous, similar, and rejected or failed proposals listed at WP:RFDA, to see which wheel you're reinventing? TenOfAllTrades(talk) 21:08, 15 January 2015 (UTC)
For the most part I can see that people want some sort of process, it is hammering out the process that is the problem. Overwhelmingly it seems from the last few attempts that the idea of a select commity is a bad plan, and I have avoided that thus far. There does need to be a way to limit the battleground attempts which will be worked on in the near future. I am willing to spend time on this for the sole fact that people know there is a problem, figuring out how to tackle it is harder. Compromise and weighing which ideas are considered the most acceptable are going to be key with this I believe, which is why I fully expect this draft to change multiple times before it becomes a full up idea. Tivanir2 (talk) 14:58, 16 January 2015 (UTC)
The community has been around this merry-go-round many times before. When you say that "people know there is a problem", can you be specific about what the problem actually is?
  1. Is the problem actually that the existing procedures for desysopping don't work (or can't easily be made to work)?
  2. Or is the problem that many editors aren't aware of the flexibility and power of existing procedures, and are just failing to use them appropriately?
  3. Or is the problem a perception that not enough editors are running/succeeding at RfA, and a new desysopping procedure is hoped to be an effective scheme to recruit more admins?
  4. Or is the problem that admins are too big for their britches, and we need a new process to threaten them a bit more often?
  5. Or is the problem that writing policy is fun, and there aren't very many opportunities to do that now that this project is relatively mature?
I have a strong suspicion that problem #2 is being too-frequently mistaken or misunderstood as being problem #1. Problem #3 – RfA isn't turning out enough new admins – is often mooted as being a consequence of #1, but it might constructively be fixed by solving #2. (And it doesn't address the effect that a loud and unpleasant new desysopping process will have on the number of RfA candidates.)
While almost nobody will admit to being motivated by #4 and #5, they make their own contributions to the pro-desysopping-scheme faction. (Before someone jumps in to say that I'm not assuming good faith, I will note that #4 has been specifically asserted as a valid justification during previous discussions of desysopping schemes. As to #5—well, you have to admit that anyone who hangs out at at the Village Pump has at least a bit of policy wonk in them.)
I'm just going to leave you with a link to User:TenOfAllTrades/CDAresponse. It's a critique that I wrote four (almost five, now!) years ago of another failed desysopping proposal (community de-adminship: Wikipedia:Guide to Community de-adminship). Not all of those criticisms apply directly to your new proposal, but it's going to hit a bunch of them. Some of the criticisms are actually more potent today. Fundamentally, I believe it very likely – and history supports me – that any open-voting-based desysopping scheme is going to have insurmountable flaws with respect to fairness and function. I hope that the community will continue to recognize that when faced with these types of proposals.
Time would be much better spent educating editors who are concerned about hypothetical (or even real, specific) "problem administrators" about their existing options under current policy. Solve the real underlying problem, Problem #2, rather than constructing an elaborate, unpleasant, and destructive new process. TenOfAllTrades(talk) 00:57, 17 January 2015 (UTC)
I went through the proposals of the past and it seems with all the recent ones the community as a whole liked the idea of having more control and ownership of the process, as long as it didn't boil down to another small subset of editors like ARBCOM calling the shots. Responses to the above 5 points
  1. It isn't so much that the current system doesn't work; the original schema design was that ARBCOM wasn't suppose to handle admin problems, there just wasn't an alternative.
  2. Again not so much an issue but when an ARBCOM member themselves brings up that they took the role because the community couldn't deal with it under what existed at the time, doesn't mean you stop trying to fix the process. It means you spend more time getting it right to me.
  3. I think it would help for recruiting but that is more a by product than an actual no kidding priority.
  4. I don't think I have ever truly had a negative experience with an admin, and the only time I was even warned was from a technical problem on my end and not behavioral. Threatening other people is bad so not sure what you were going for on this one.
  5. I find writing policy to be excrutiatingly painful (disclosure I am a mid rank in the military - policy crap is my life) so it is by no means fun. This actually came about because I am following the ARBCOM case for the gamergate article. I saw it on the ANI boards when I took a gander at them, started reading the article (which was a mess, but the draft is getting better), and wanted to help contribute to cleaning up readability and overall setup which of course led me to taking an interest in the case. It was the proposed decision talk page that had me land here, I don't watch this section routinely. Tivanir2 (talk) 21:00, 19 January 2015 (UTC)
I'm not a big fan of the whole "presenting evidence" thing. That just sounds too much like an ArbCom case. If you need 50 diffs to explain what someone did wrong, then it's probably too complicated an issue for the community as a whole to handle. With the originator, plus rebuttal, and other evidence, you're talking about the equivalent of 3-4 printed pages of single-spaced text, not counting all the diffs. And with a process that can last as long as a month, it barely even resembles a "reverse RFA" anymore. That's longer than an ArbCom motion would take, and only a couple weeks shorter than a full case. At this point I don't see any benefit to this vs ArbCom and I'm struggling to think of a situation where a process like this would be useful. Blatant abuse can usually be handled quickly by an ArbCom motion. And for more subtle or long-running issues, I'm not sure I really have confidence in 100+ uninvolved users to individually research everything themselves. The only thing I can think of where this might be desirable would be a parallel to the US justice system where defendants can choose a bench trial (ArbCom) or a jury trial (community). But whether anyone would actually want to go through a community process rather than ArbCom or this would just be bureaucracy for its own sake, I'm not sure. If people had the choice between ArbCom or WP:CSN, I can't imagine many would have actually chosen the latter. Mr.Z-man 15:03, 17 January 2015 (UTC)
The big thing is that there are a limited amount of words that convey the right information for what is being presented. Evidence is as good a word as I can think of for proving misconduct. The numbers are of course flexible. I will modify numbers and see if that presents better overall. Tivanir2 (talk) 21:00, 19 January 2015 (UTC)
The problem isn't the terminology, it's the process. You're calling it a reverse-RFA, but except for the vote, it doesn't really resemble RFA at all. And as I said, I'm not really sure where this fits in. Obvious cases of abuse can be handled by AC motion quickly and non-obvious cases probably need more nuance than a simple support/oppose vote. ArbCom also has the benefit of considering the wider issues. You mentioned in another comment that you became interested in this as a result of the GamerGate case, but that's exactly the kind of case that would be a poor fit to this type of process, as the issues go far beyond admin misconduct. Mr.Z-man 03:01, 20 January 2015 (UTC)
  • Oppose - this is a solution looking for a problem, and while it's a good idea in theory, by the time the details are hammered out, it will be inferior to the existing process. ArbCom is very rapid to remove admin access when there's evidence of abuse. We should not create additional bureaucracy. If there's a problem with an admin, post the complaint to WP:AN to get feedback, and if there's a solid basis, somebody will file for arbitration. Jehochman Talk 17:48, 18 January 2015 (UTC)
With the removal of RFC/U it is somewhat easier but it still is a relatively long and painful process, especially with long term problems. I am not trying to turn this into a mess, more like a vote of no confidence if the community deems that an admin should be removed. If enough people weigh in against the proposal we can always regulate it to the dust bin of proposals. Tivanir2 (talk) 21:00, 19 January 2015 (UTC)
  • Oppose First it seems like this proposal has changed slightly every time I look at it; not sure I can support a proposal that hasn't fully settled down yet. While I used to be be in favor of such a system, I actually am no longer convinced of the benefit. We do have ways to remove admins already that work. If necessary we can go the community ban or just launch an RfC on a specific case. Even if a recall procedure has builtin guards against frivolous removals it also has to guard against taking the time for nominations from enemies that can force stress, inconvenience on a target admin. Giving such attacks a chance to wear and tear on an admin even if they will never directly succeed in getting a bit removed is something I worry about with any recall process. This approach seems to have a lot of the flaws of the former RfC/U process without all of it's protections, for example certified nominations etc. I'mu also not convinced that it will help much with the admin shortage issue. I don't recall that many close call RfAs lately, so any shift in vote because of the existence of a recall procedure would not change the outcome that much. I also worry that a recall system might get in the way when the removal of admin bits required greater speed. PaleAqua (talk) 23:25, 19 January 2015 (UTC)
  • Oppose for many of the reasons given above, but mostly because, as Jerichoman said, it is a solution in search of a problem. – Philosopher Let us reason together. 00:39, 21 January 2015 (UTC)

Alternatively, Facilitation Group[edit]

ArbCom is an elected group of trusted users. They reliably desysop admins who have committed abuse. However, the typical user is reluctant to file an arbitration case. How about we create an informal group of experienced users who would review complaints of admin abuse and then file arbitration cases when warranted? This could be a WikiProject dedicated to improving admin conduct. It would not create any new hats or mandatory bureaucracy. It would simply help users navigate existing process which works well when used correctly.

As an example, I recently found several users complaining about and admin Wifione. There were counter complaints of personal attacks, hounding, etcetera. To resolve the dispute I wrote up a request for arbitration. That was accepted and is being heard. This process has been smooth and relatively stress free. Parties on all sides of the issue seem to be happy with the process. Jehochman Talk 14:18, 17 January 2015 (UTC)

I support such a proposal as long as it doesn't add any bureaucracy, such as requiring users to use this vwenue for filing an ArbCom case. עוד מישהו Od Mishehu 16:54, 17 January 2015 (UTC)
To be clear this is not mandatory. Anybody can go directly to ArbCom if they wish. Jehochman Talk 17:02, 17 January 2015 (UTC)
This suggestion – while well-intended – makes me rather twitchy. The community did not have a good experience with the Association of Members' Advocates (WP:AMA, 2004-2007ish)—a volunteer group that nominally provided assistance to editors navigating the arbitration process. Wikipedia:WikiProject Administrator (2009-2011ish) – which nominally had admin improvement as its goal – never really managed to complete anything concrete beyond filling up WP-space talk pages.
The recurring problem is that these sorts of projects and groups tend to attract editors who variously have a fondness for process-wonking, hat-collecting, ax-grinding, and/or shit-stirring. Historically, the editors who enthusiastically volunteer to participate in this sort of thing often aren't the editors with the skills, temperament, and inclinations that are called for to have productive, constructive output. Editors volunteer in good faith without realizing the level of skill or commitment of time required to follow through, and then drift away.
The number of admins who are desysopped (or credibly, plausibly considered for desysopping) in any given year is currently quite small. As I noted above, we had maybe half a dozen instances in the last year that involved an ArbCom case, motion, or filing (causing a resignation). Not all of those are going to involve parties that need or want the assistance of whatever new group is formed. If there's a case only once every couple of months (at 'best') then what? Does this group become a shoal of circling hammers, desperate to pounce on any nail – or screw, or thumbtack, or confused marshmallow – that comes along? Will there be a pressure (internal or external) to increase the number of desysoppings considered, advanced, or attempted just to maintain the interest and activity of the group?
Speaking generally and as a matter of principle, I applaud and wholeheartedly approve of providing assistance to good-faith editors who have difficulty navigating Wikipedia's more arcane processes. In practice, we've long seen that such assistance often comes with hidden costs —to which the project and, in particular, inexperienced good-faith editors may be vulnerable. TenOfAllTrades(talk) 22:06, 17 January 2015 (UTC)

Typhaine Case User:Panam2014/Typhaine Case[edit]

Hi Can you help me to translate [2]. It could be a good article for our encyclpedia. Regards. --Panam2014 (talk) 09:46, 16 January 2015 (UTC)

Stub created at Typhaine case for any Francophone who wants to tackle this: Noyster (talk), 16:05, 18 January 2015 (UTC)

Get rid of jpeg progressive load[edit]

hurts eyes, please ! I can see it or I can't , progressive its just a placebo no new/relevant information is there while loading an image — Preceding unsigned comment added by (talk) 23:52, 19 January 2015 (UTC)

I believe that's down to the file being uploaded; is the thumbnail progressive? Or am I missing something? Adam Cuerden (talk) 11:05, 20 January 2015 (UTC)
Have you tested this with GPRS speed for a "mobile broadband" plan at modem speed after, say, 5GB/month are eaten up? –Be..anyone (talk) 11:44, 20 January 2015 (UTC)
I believe that progressive loading is used in Media Viewer. It does not seem to be an especially popular feature.
Media Viewer does not exist on the mobile website (en.m.wikipedia), only on the desktop site (en.wikipedia). Whatamidoing (WMF) (talk) 18:45, 23 January 2015 (UTC)
My laptop is connected to the Internet over "mobile broadband" (UMTS), I just got the "you are at 95% of 5GB" SMS (one week at commons, the next three weeks at GPRS speed.) But if the issue discussed here affects only the media viewer I'm off topic, sorry. –Be..anyone (talk) 19:20, 23 January 2015 (UTC)
You would presumably be getting the desktop website, if you're using your laptop. You can tell by looking at the URL. If there's a ".m." in the middle, then it's the mobile site. I've heard that there are a lot of readers who have switched to the mobile website for reading, even on their desktop/laptop machines, because they find it easier to read, and the preference is "sticky", so the only want to find out it to check your own system. (A link to either Mobile or Desktop view is at the very bottom of the page, if you ever want to see what the other looks like.) Whatamidoing (WMF) (talk) 23:40, 23 January 2015 (UTC)

Social space[edit]

Awhile back, I complained at WP:VPP about what I saw as misuse of Reference Desk. Too often, I felt, responders engaged requests for opinion, and my attempt to hat one such thread resulted in a minor shit storm. I was told, basically, to relax, which I did.

Additionally, RD threads often digress into tangential banter that has little to do with the OP's question. In that respect RD is often a local Facebook or chat room. This has also been a problem for me in the past, but I have mellowed there, too (and have occasionally participated myself, especially recently).

I now feel there's nothing wrong with a desire to engage in unproductive conversation with fellow Wikipedians, provided one doesn't overdo it. It would provide a needed release valve and allow us to interact outside the "work" environment (same concept and purpose as a happy hour). It would likely reduce such activity at RD, which would be good for RD. As far as I know, there is no talk space specifically designed for that purpose. Could there be? Should there be?

Please don't refer me to something off-wiki, such as an IRC channel, or suggest the creation of one. Very few people would bother going there, they just need a quick break from editing and click on RD in their watchlist. I certainly wouldn't. ―Mandruss  22:47, 20 January 2015 (UTC)

@Mandruss: I've noticed this sort of thing happens on some user talk pages as well in discussions that start off about some article or topic. Here's an example between myself, Crisco 1492, and Curly Turkey. I generally agree that it's healthy to occasionally engage in a little banter or joking around to loosen things up from the sometimes serious and taxing work of building an encyclopedia. I think many editors would acknowledge these kinds of interactions happen on a lot of spaces on-wiki, not just user talk pages and on the reference desk. I guess the question is, would it be so different or disruptive if we formalized a place for this kind of interaction? I anticipate some folks will argue WP:NOTFACEBOOK and say that such a space is a distraction. And I get that-- we don't want folks to come here simply to socialize. But we've been allowing these discussions happen on the ref desk and talk pages for a long time, and I still see a lot of these same editors doing the hard work. I, JethroBT drop me a line 23:46, 20 January 2015 (UTC)
Yes. If we're going to allow it, and I think we should allow it, then provide a space where it's legitimate, obviously subject to WP:NOTHERE. That's pretty much the thrust of my comments. ―Mandruss  00:05, 21 January 2015 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────Struck the beginning of my comments, which had nothing to do with this issue. (Sigh. I need a break at Wikipedia:Happy hour!) ―Mandruss  01:07, 21 January 2015 (UTC)

Wikipedia:Wikipedia is a community bears on this question. Those short on time could read just the Jimbo quote near the top. ―Mandruss  01:07, 21 January 2015 (UTC)

  • I wouldn't hold my breath waiting for any sort of change to the way the refdesk works. I tried to talk about changing it in 2013, see Wikipedia:Reference desk/Refdesk reform RFC. The overwhelming response from those that are regulars there could be best summed up as "if it ain't broke don't fix it". They didn't even want a notice on the page clarifying that it isn't really part of the encyclopedia and apparently not subject to the same rules as every other part of WP. Some people like that it is often a free-for-all that bears little to no resemblance to an actual library reference desk, in that librarians will refer you to the relevant material to answer your question instead of just making stuff up or taking wild guesses at what the answer might be. Beeblebrox (talk) 01:48, 21 January 2015 (UTC)
I hear you. But I think this is worth doing even if it has no effect at all on RD. Any improvement to RD would be gravy. At the very least, one would have a new option when a thread degenerated into nothing but banter - Take it to Happy hour!. Anyway my main motivation here is not to reform RD. That's an important issue, but a separate one. ―Mandruss  02:04, 21 January 2015 (UTC)

Proposed user right: Vandal fighter[edit]

There has frequently been discussion about making some of the administrator tools available to a lot more editors, and User:Jackmcbarn presented a great idea at Wikipedia:Village pump (idea lab)/Archive 15#New "vandal stopper" user group. The proposed vandal fighter user right would have the following rights:

  • Blocks:
    • Can block unconfirmed accounts for a maximum of 48 hours
    • Can soft-block IP addresses for a maximum of 48 hours
    • Can unblock users blocked by other vandal fighters
    • Can NOT unblock users blocked by administrators
  • Page protection:
    • Can semi-protect a page for a maximum of 48 hours
    • Can Pending Changes 1 protect a page for a maximum of 48 hours
    • Can unprotect pages that were protected by other vandal fighters
    • Can NOT unprotect pages that were protected by administrators
  • Notes:
    • All vandal fighters would also be granted Pending Change reviewer status
    • All vandal fighter actions will be viewable on one or more special pages
    • An administrator can turn a vandal-fighter action into an administrator action, which would prevent other vandal-fighters from removing it.
  • Requirements:
    • Vandal fighter rights would be granted by administrators after requests at Wikipedia:Requests for permissions
    • Rights would only be granted to user who meet the requirements of both roll back and pending changes reviewer
    • Vandal fighter rights must only be used for obvious spam and vandalism. Anything else will be considered abuse of the tool and the right will be revoked.

I look forward to your comments. Oiyarbepsy (talk) 23:57, 21 January 2015 (UTC) Pinging editors at previous discussion: @Biblioworm:@LT910001:@TheGeneralUser:@TenOfAllTrades:@Technical 13:@Cenarium:@Scalhotrod:Oiyarbepsy (talk) 23:57, 21 January 2015 (UTC)

The very early votes are indicating that this might pass, but people have several questions and objections. In light of that, I have a request for the voters: if it's still looking like this might pass after a week or two, then please check back at the end of this RfC in case the closers need help in determining consensus on the various suggestions and objections. - Dank (push to talk) 23:22, 22 January 2015 (UTC)

Support (vandal fighter)[edit]

  1. Support - Best idea I've seen in awhile. Give me the right and I'll contribute a lot more to fighting vandalism, taking some of the load off admins. If I abuse it, take it away. Unless admins spend more time granting and revoking the right than they currently spend responding to vandalism, which seems very unlikely, it's a clear net gain. I would ask for some kind of vandal fighter summary page covering the necessary tools and procedures, with links to more detailed information (unless something like that already exists). ―Mandruss  00:11, 22 January 2015 (UTC)
  2. Support. As long as the right can be easily removed by an admin, I see no reason why we shouldn't have this right. --Biblioworm 00:18, 22 January 2015 (UTC)
  3. Support - I agree. this one just might go somewhere. Mlpearc (open channel) 00:53, 22 January 2015 (UTC)
  4. Not incredibly into vandalism patrolling but can definitely see where this right would be useful, so I support it. --ceradon (talkcontribs) 01:05, 22 January 2015 (UTC)
    Support, provided that the restrictions of the tool are limited to the original specifications in this proposal. If anything else gets added to the function of this user right after this comment, assume that I'm neutral. Steel1943 (talk) 01:20, 22 January 2015 (UTC)
    Moving to "oppose" after giving this some thought. Steel1943 (talk) 16:35, 24 January 2015 (UTC)
  5. Support This is a great opportunity to both empower the editors confronting vandalism while relieving the need to push more editors through RfA, where XfD and content creation become required. Chris Troutman (talk) 02:05, 22 January 2015 (UTC)
  6. Support I'd much rather see accounts be indeffable, as I mention in the discussion section below, but we can always do that later. Jackmcbarn (talk) 03:50, 22 January 2015 (UTC)
  7. Support, but with one reservation: I'm opposed to calling it vandal fighter as that would seem to promote a battlefield mentality. How about vandal control, vandal abatement, or even vandal extermination. The proposal is good one though, and would streamline the normal process of reporting to AIV or RPP and sometimes waiting hours for action to be taken.- MrX 04:05, 22 January 2015 (UTC)
    Well, fighting vandals (especially the sockfarm-creating ones who come back to harass you) does sometimes feel like a battle, but I see your point. --Biblioworm 04:43, 22 January 2015 (UTC)
    • Also support changing maximum 48 hour block to maximum indef block to address some of the objections from opposers.- MrX 01:00, 24 January 2015 (UTC)
  8. Support - I know that (assuming I had these rights) I could all but stop reporting IPs at WP:AIV, would usually have better and easier damage control over the user accounts I'd still report there. I'd also probably not have to post at WP:RFPP again. Freeing up those pages would probably help take care of the backlog at WP:SPI (now if only we had some similar demi-adminship to help with that), and resolve issues at WP:ANI quicker. I suspect this would also help with the admin shortage while reducing the risk of abusive admins, as would-be admins would have a vandal-control record to show that they can at least be trusted with that (something that honestly probably better demonstrates admin ability than article creation). Ian.thomson (talk) 04:16, 22 January 2015 (UTC)
  9. Support but with some notes. I trust that Jackmcbarn wouldn't propose this sort of thing if he hadn't already determined that it were technically feasible, so I am not concerned about that. What I am concerned about is the automatic granting of other user rights which we already have processes for. I would prefer that granting of those rights were prerequisites for this one, since they are all related and those are better established, rather than potentially granting those more mature rights through what could turn out to be a back door. But I'm not terribly concerned about it - these are fairly weak user rights. I think the benefits outweigh the risks; I'm in to try it. Ivanvector (talk) 04:32, 22 January 2015 (UTC)
  10. Support. I think having this right would be a great idea, as blocking vandals could be faster- there will be no need to wait for the administrator- the vandal fighter can block the vandal immediately, without a report to AIV. This is one of the best ideas I have seen. pcfan500talk|my contribs 10:51, 22 January 2015 (UTC)
  11. Support - if given out carefully and sensibly, and if it can be easily removed by a full admin or community consensus. Quite frankly, the number of times I've had to report an obvious vandal to AIV, only for the request to sit there for hours - with the vandal still working their way through many articles - due to the lack of any administrators being active at that point is quite depressing. Sometimes this can also come from a topic area being poorly covered by admins, and thus they lack the understanding of what might be a fairly obvious piece of vandalism to someone with some experience in that topic (I can think of some examples of this as well.) Lukeno94 (tell Luke off here) 21:00, 22 January 2015 (UTC)
  12. Conditional support As I've said in opposing other admin bit split outs, I could see supporting blocking and think this could be useful. I do have a few restorations. The first is the 48 hour limitation. I'm opposed to any such split out that would just make more work for the admins and agree with a bunch of the concerns on it that have already been. While technically I suppose that makes my !vote an oppose at this time, I see enough disagreement that I'm hopefully that it will change. I also worry about the name but not enough to oppose on that. At the risk of bikeshed'ing how about something like "Wikipedia Watch" or "Sentries"? I'd also like to see some pretty strong removal guidelines in the event of abuse or even careless misuse, for example once someone that has gotten this user right loses through abuse or marked carelessness the only way for them to get similar rights in the future would be a full RfA. Since the right should be somewhat easier to get it needs to be balanced by being easier to strongly revoke. PaleAqua (talk) 23:12, 22 January 2015 (UTC)
  13. Support – There is so much rubbish lying around, and so few administrative hands to deal with it. We need some housekeepers to keep an eye on things, so that simple messes can be mopped up. Save administrative time for severe and complex problems. Such a distribution of power will greatly improve the encylopaedia. A right that is easy to give and take away for this purpose is exactly what we need. If a housekeeper fails to carry out his or her duties appropriately, sack him or her on the spot. RGloucester 01:09, 23 January 2015 (UTC)
  14. Support. Great idea, if an admin is going to be able to remove it. APerson (talk!) 06:45, 23 January 2015 (UTC)
  15. Support Nothing is more infuriating than giving a vandal the standard four warnings then making a report to AIV which goes unread for hours, all the while the vandal continues to vandalize articles. I think that this user right would be very useful as a stop gate measure since it would give trusted non-admins the ability to prevent further vandalism by a user until an actual admin can step in. Spirit of Eagle (talk) 07:05, 23 January 2015 (UTC)
  16. Support in principle. Some of the issues brought up below (standards for giving out the right, possibility of indeffing unregistered users, whether 48 hours of PC is useful, etc) can be ironed out later. I dislike seeing good proposals opposed on technicalities that really aren't important to the broad idea, and I think that broadly speaking this is a good idea. Sam Walton (talk) 11:01, 23 January 2015 (UTC)
  17. Support a perfectly reasonable suggestion that will undoubtedly be torpedoed by this community's utter inability to ever agree on a major change. Mellowed Fillmore (talk) 17:33, 23 January 2015 (UTC)
  18. Conditional support - Initially I was going to oppose, but all of my concerns could be put to bed with a trial; so, I support a trial rollout of this user right. However, it needs a different name, 'vandal fighter' is too combative — to the point it is likely to exacerbate vandal behaviour. I suggest "Moderator", as the proposed abilities roughly reflect what a moderator does in other places on the Internet, or "Sentry", per PaleAqua. Bellerophon talk to me 20:19, 23 January 2015 (UTC)
  19. Support This could help reduce some backlogs. Though indefinite block may be better than a 48 hour limit. Graeme Bartlett (talk) 22:56, 23 January 2015 (UTC)
  20. Let's give it a test run and see how it goes. Kurtis (talk) 00:50, 24 January 2015 (UTC)
  21. Support Know what, lets try it out. At the very least it would maybe speed up actions at WP:AIV and some other areas. LorTalk 07:40, 24 January 2015 (UTC)
  22. Support With maybe a few more restrictions (voting?) to make sure that these rights don't go to unknowledged/abusive editors. Avono (talk) 14:58, 24 January 2015 (UTC)
  23. Support as a measure that would give broader access to useful tools to editors for whom some form of review exists to determine that it would be useful for them to have the tools. Per Kurtis, above, we can always test this out for a limited time, and then evaluate the results to see if it is worth keeping. Cheers! bd2412 T 21:43, 24 January 2015 (UTC)
  24. Support. This would be useful for experienced recent changes patrollers without much in the way of content creation. I would also like to see the limit on block lengths and protection lengths removed, and the requirements tightened up. Perhaps users who have X many successful requests to AIV and RFPP, and no unsuccessful requests in the last Y months. — Mr. Stradivarius ♪ talk ♪ 13:31, 25 January 2015 (UTC)
  25. Partial support. To me, the most important part of this proposal is "Can semi-protect a page for a maximum of 48 hours". We have a problem with the length of the process to combat libellous additions to WP:BLP pages. Giving vetted users the right to protect pages that are early in a BLP war would give the full administrators time to examine the problem and decide what to do. Serpyllum (talk)
  26. Support. Should, however, need more than simply rollback+reviewer, as those are given extremely liberally. --L235 (talk) Ping when replying 19:16, 25 January 2015 (UTC)

Oppose (vandal fighter)[edit]

  1. Oppose. I understand the motivation here, but I don't think this solves a necessary problem. Even assuming that we need more people capable of blocking obviously disrupting IPs and throwaway accounts (and I'd like some hard data regarding backlog rates at, say, RPP or AIV on that issue), the sort of accounts and IPs that this is intended to target frequently necessitate longer than 48 hour blocks, which means this doesn't actually save administrators an action except in fairly narrow cases. Also, the ability to apply even temporary semi-protection is fairly significant, since it restricts access from good-faith IP editors as well; the implications of this might best be reserved for those who have demonstrated more community trust than needed for the current "vandal fighting" tools like rollback. But, perhaps most importantly, I don't think this is likely to be technically feasible. My understanding of the mechanics of the project holds that in order to create a (semi-)protection level that this right can interact with, without granting the ability to interact with that protection level in general, would require creation of a new protection level (mini-semi-protection, or something). Likewise, something similar would be needed to create blocks that can be issued and undone by this user right without permitting interaction with "real" blocks (if that is even deemed possible to implement, as there are not, so far I am aware, "block levels"). A marginal net gain for substantial software development cost is not something to get hopes up about being implemented. Squeamish Ossifrage (talk) 02:28, 22 January 2015 (UTC)
    For what it's worth, Jack McBarn and others seem pretty sure that this is technically possible and feasible. Oiyarbepsy (talk) 03:20, 22 January 2015 (UTC)
    It saves editors having to chase around vandals while an AIV reports sits there at 4 a.m. EST when most of the North American admins are asleep. It might not save an admin action but it stops disruption quicker. --NeilN talk to me 03:35, 22 January 2015 (UTC)
  2. Oppose. At the time this was proposed at the idea lab, I noted several problems. As well, there was a discussion at Wikipedia talk:Blocking policy#Duration of blocks that is illuminating.
    • Having a group that can block only IPs and non-autoconfirmed accounts creates (or exaggerates) a power disparity in any conflict involving new (or unregistered) editors and more established accounts.
    • Most blocks of IPs and non-autoconfirmed accounts are for periods of time much longer than 48 hours (as are most semiprotections). This leaves a trail of incomplete tasks that regular admins may or may not eventually clean up.
    • Blocking vandalism-only accounts for just a little while doesn't actually work very well. A significant fraction of them come back (days or weeks later) to make more of a mess. Some of them will be autoconfirmed at that point. Virtually none return to make positive contributions (it's far easier, and more sensible, for them to create a new, clean account).
    • We actually don't do a good job of blocking vandalism-only accounts. Issuing short-duration blocks means that even the vandals that we catch once will still get one or more chances to do damage after their blocks expire.
      In other words, this toolset is likely to encourage newbie-biting while failing to effectively deal with vandals. (It just creates double the effort for each administrative action—once from the baby admin/"vandal fighter", and then again from the real admin who has to review the situation and issue a block/protection of adequate duration.) Also, what's with the "vandal fighter" name? It reminds me of the early WP:Counter-Vandalism Unit and its paramilitary ranks, badges, and officious obnoxiousness. We're not fighting a war, we're writing an encyclopedia. TenOfAllTrades(talk) 03:50, 22 January 2015 (UTC)
  3. Oppose - At least until the requirements for granting are tightened up substantially. I didn't even have to dig through the history - looking at AIV and RFPP right now, I see bad reports (no vandalism since final warning, not enough vandalism to justify protection) by users with rollback and reviewer rights. Like the AFD stats tool used on RFA, I'd like to see something similar for AIV/RFPP to make sure that the people requesting the right actually know when it should be used. Simply knowing what vandalism is (basically the requirement for rollback/reviewer) does not indicate sufficient understanding of the block/protection policies. Mr.Z-man 05:00, 22 January 2015 (UTC)
  4. Oppose I must admit this is better than a lot of unbundling proposals I've seen, but I have a few issues with it:
    • Granting the ability to block anyone, ever should be a community decision, not a single admin decision (ironic, an unbundling proposal that would actually give admins more power)
    • My standard objection to most unbundling proposals: The admin tools form a kit. Giving only some of them to some users will mean they can only deal some of the problem. Deletion, blocking, and protection are all tools used by admins specifically to combat vandalism. If you don't have any one of them you will inevitably have to go find an actual admin to finish the job. Why have two users doing something that one admin could easily do in a matter of just a minute or two?
    • Applying PC protection to an article for 48 hours or less seems silly. In my opinion and I believe in practice, PC is generally more for long-term problems, semi is for short-term ones.
    • Most actual vandals get indef blocked. Having them automatically unblocked after two days gives them an easy way back, and then a real admin will have to deal with that, so what's the point?
    • Rollback and even PC reviewer are low-level content tools. Judging whether a using them responsibly is only one of many prequisites for more powerful tools, and all these tools, even with these time limits, can easily be abused if granted to users who aren't really ready for them.
    • And finally, I don't see any concrete evidence that this is something we actually need. Beeblebrox (talk) 23:49, 22 January 2015 (UTC)
      • "Granting the ability to block anyone, ever should be a community decision" - What? Users get blocked constantly without any community input at all. Oiyarbepsy (talk) 05:05, 23 January 2015 (UTC)
      Yes they do. By people who were granted the right to block through a community based process. Beeblebrox (talk) 06:31, 23 January 2015 (UTC)
  5. Oppose WP:RFA is thataway. If you feel like the community can trust you to block people, then go and ask them to let you do so. --Jayron32 01:08, 23 January 2015 (UTC)
    What do you suppose are the chances of me getting full admin rights so that I might better help fight vandalism? Absolute zero. Something like this, far from a shoo-in but a lot better chance than that. How much do I want full admin responsibilities? Not in the slightest. ―Mandruss  02:13, 23 January 2015 (UTC)
    Mandruss: based on what I saw while reviewing your request for rollback rights today, you have a much higher chance of passing RfA than absolute zero. You may not want to be an administrator, but I don't see why an RfA would be that contentious in your case. —Tom Morris (talk) 04:32, 24 January 2015 (UTC)
    It would be contentious because I've created exactly zero articles (despite the fact that the required skill sets are very different). It should be contentious because I'm eminently unprepared for that job. But I'm more than capable of handling this new right, and there are a lot more like me around. Anyone who opposes because of the potential for damage by abusers of the right, who says that downside is likely be greater than the upside, is making a very negative statement about the Wikipedia community over all. I'm not prepared to make that statement. I know Jimbo wouldn't. Adequate vetting is the answer to any such objections, and it could include elements that have not been used before, such as interviews and references. In other words, the evaluation for this right could be, and should be, somewhere between rollback and RfA. ―Mandruss  17:38, 24 January 2015 (UTC)
    • It would be contentious because I've created exactly zero articles (despite the fact that the required skill sets are very different). is exactly why I haven't run as well. — {{U|Technical 13}} (etc) 18:39, 24 January 2015 (UTC)
    • I've written some articles (I have a GA and two upcoming DYKs), and I would like to do more work with content, if I can find other topics that have good coverage in other sources (which is becoming increasingly difficult). While the role of content workers/creators is indisputably very important, I still don't understand those who think it is necessary to become an admin. After all, if all the anti-vandals left, the content creators would be on their knees begging them to come back, as they wouldn't have time to create any content if they were forced to constantly protect their articles. --Biblioworm 18:50, 24 January 2015 (UTC)
    I suspect admins, over all, have a very cynical view of the community because they see the worst of us on a daily basis, like cops. Dear admins, your view of reality is skewed. ―Mandruss  21:37, 24 January 2015 (UTC)
  6. Oppose, blocking is too contentious. Guy (Help!) 01:47, 23 January 2015 (UTC)
  7. Weak Oppose, I agree with JzG. Weak only because I don't deal with vandalism on a regular basis and I'm unsure how badly it's needed. Hobit (talk) 03:49, 23 January 2015 (UTC)
  8. Weak Oppose, per reason given by Jayron. The power to block is a huge power, one that I am even concerned that some Admins have power to use. If some editor were to be given that power, they should have to go through a RfA like process, stronger than the request for permissions preocess. Therefore, unless such a vetting process is created, I cannot support this proposal at this time.--RightCowLeftCoast (talk) 06:40, 23 January 2015 (UTC)
  9. Oppose What's the differences with sysop? It is too powerful (especially blocking). — Revi 07:27, 23 January 2015 (UTC)
  10. Oppose: Largely as per Beeblebrox's arguments above, but the last paragraph of TenOfAllTrades's contribution expresses something important about the potential negative consequences. AllyD (talk) 07:39, 23 January 2015 (UTC)
  11. Oppose - anybody trusted with this would pass RFA, so this is just more of the "RFA is difficult, so let's have two!" silliness. And, of course, labelling someone a "fighter" is just an open invitation to ignoring WP:NOT#BATTLEGROUND. WilyD 10:01, 23 January 2015 (UTC)
    • Not strictly true, if they have little content creating experience but are an experienced anti-vandal patroller, they stand no chance of passing an RfA. Lukeno94 (tell Luke off here) 13:27, 23 January 2015 (UTC)
  12. Oppose gamification of blocking and risk of even more drama and contention among established users (who are left to argue over and vet these blocks and their use/abuse) is too high. Alanscottwalker (talk) 14:03, 24 January 2015 (UTC)
  13. Oppose - As per Beeblebrox and TenOfAllTrades. Since the vandal-fighting powers of vandal-fighters would be limited, actual vandals would find ways to game the system and get a second chance. Robert McClenon (talk) 01:58, 24 January 2015 (UTC)
  14. Oppose - as it stands now. Reiterating what's said previously, the requirements are very weak. Both the userrights rollbacker and reviewer are the easy come, easy go userrights. IMO, much stricter requirements are needed. Elockid (Talk) 02:11, 24 January 2015 (UTC)
  15. Oppose - ansolutely 100% per Beeblebrox who has once again beaten me to a discussion , saving me from having to do the typing. And thanks also for the analogy by TenOfAllTrades and reminding us how I finally cleaned up the camp-fire and badges brigade activities at the after-school activities hut. More to come in the 'Comments' section below. --Kudpung กุดผึ้ง (talk) 07:26, 24 January 2015 (UTC)
  16. Oppose - we rightfully require a good deal of community scrutiny before providing an editor the responsibility of using the blocking et. al. tools. Anyone who's earned the trust of the community to be blocking other editors needs to be given the trust to do so effectively; we're short admin-time enough without adding the burden of having to vet "mini-admin" actions. NE Ent 13:48, 24 January 2015 (UTC)
  17. Oppose' Ability to block and unblock is a crucial part of admin tools. If anyone meets the required criteria for vandal fighter, I presume he'd most likely pass an RfA as well. In simple words: there ain't any need to create further complexities. EthicallyYours! 14:41, 24 January 2015 (UTC)
  18. Oppose The ability to block can be very damaging and should require that the editor is scrutinised by the community before being given the right - i.e. by RFA or equivalent. As noted by others, being able to block ips/new users only will be divisive, and will potentilly drive off editors who could be redeemed or have been caught in the backlash of a bad block.Nigel Ish (talk) 14:50, 24 January 2015 (UTC)
  19. Oppose, after giving this more thought. I can see this discouraging non-autoconfirmed good faith editors or "vandals-that-eventually-become-constructive" editors if they get a block on their record during the time they are not autoconfirmed. That clean block log is like a perfect score on a report card, and ruining that report, no matter what the circumstance, is something that should only be trusted in the hands of an administrator. Steel1943 (talk) 16:38, 24 January 2015 (UTC)
  20. Oppose per Beeblebrox - Being blocked can ruin your chances of becoming admin so it should be done carefully, Personally I think it's best we stick to RFA as that way there wouldn't be any wars nor blocks. –Davey2010Talk 21:04, 24 January 2015 (UTC)
  21. Oppose - Completely wrong headed. Officially - for any of the good, sensible reasons set out elsewhere in this section. Leaky Caldron 21:11, 24 January 2015 (UTC)
  22. Oppose: The main tools available to nonadmins are tools that (when used correctly) have no potential to be contentious. PC reviewing and rollback are for more effective frontline stoppage of obvious vandalism, not discretionary action. Blocking and protecting, tools that have the most potential to be incendiary, should only be performed by those who the community has determined have the tact and cluefulness to be able to do so, not those determined by Joe Admin who happened to be clearing the RFPERM backlog that day. The short-term nature of the actions doesn't mitigate the discretionary nature of the tools. Deadbeef 07:17, 25 January 2015 (UTC)
  23. Weak Oppose - I support such a right on paper. I feel that it's a decent idea. But WP:PERENNIAL sums up what I think. The people qualified for such tools should might as well just go for full adminship. Narutolovehinata5 tccsdnew 09:41, 25 January 2015 (UTC)
  24. Oppose Our biggest issue is retaining new editors relaxing the requirements and increasing the number of people who can do this through the creation of yet another subset of editor rights is fraught with danger of increasing the biting of new editors so with out some documented imminent disaster to avert I dont see a need Gnangarra 11:54, 25 January 2015 (UTC)
  25. not a good use of our time per above --Guerillero | My Talk 22:34, 25 January 2015 (UTC)
  26. Oppose Per Guy. If we're unbundling some admin rights, blocking should be the last one to be considered, not the first. BMK (talk) 22:41, 25 January 2015 (UTC)

Discussion (vandal fighter)[edit]

@Oiyarbepsy: In my original idea, vandal stoppers could indefinitely block users who are registered but not autoconfirmed, so that admins wouldn't have to reblock all vandalism-only accounts. Was this change on your part intentional? Jackmcbarn (talk) 00:51, 22 January 2015 (UTC)
@Jackmcbarn:It was not. I misunderstood. I'll can revise if you like, but I like the 48 hour idea better. That way, admins are only necessary for those who come back after their 48, which I suspect is a small minority. Oiyarbepsy (talk) 00:58, 22 January 2015 (UTC)
@Oiyarbepsy: I would like that to be revised. While it's true that admins would only be necessary for those that returned with the limit, they wouldn't be necessary at all without the limit. Jackmcbarn (talk) 01:01, 22 January 2015 (UTC)
If this passes, and after being in place for a month or two, we can change it. Best to start out kind of conservative. Oiyarbepsy (talk) 03:19, 22 January 2015 (UTC)
@Oiyarbepsy: I note that a lot of oppose reasons mention that vandalism-only accounts would get unblocked after 48 hours, which would be bad. Would you consider changing it now to alleviate some of them? Jackmcbarn (talk) 01:24, 23 January 2015 (UTC)
@Jackmcbarn:I'm gonna be honest, I don't think changing that would alleviate anything. The opposers who mentioned that had it as one small item in a laundry list, and I frankly think that change would change anyone's mind. Also, I'm not entirely comfortable to let non-admins block users essentially forever, and it's certainly better for vandals to come back with their original account rather than sock puppets. Finally, enough votes have been made that changing it now would generate a lot of confusion of what exactly people are supporting or opposing. Oiyarbepsy (talk) 05:08, 23 January 2015 (UTC)
  • (edit conflict) Comment/question: Could someone explain to me how this proposal's function would be technically possible? I mean, from what I understand, there is a drop-down menu that administrators can use to select how long an editor is blocked for, and as far as I know about this, that cannot be adjusted for a special new user right. (However, I bet improbably wrong, and there's probably some way to edit a page in the "MediaWiki" namespace to allow only certain timeframes to this user right.) So ... can this be done? Steel1943 (talk) 01:03, 22 January 2015 (UTC)
    @Steel1943: This will require software changes to implement, which I plan to start work on once this proposal is closed (assuming it passes). Jackmcbarn (talk) 01:05, 22 January 2015 (UTC)
  • @Jackmcbarn: That's what I suspected. It's possible. I was, more or less, wondering since if the only option to make the software allow non-admins the option to block other users would give the non-admin access to the "indefinite block" option, then this would seem more like a tool-unbundling request (and I think that enough of the admin toolset is unbundled already.) Steel1943 (talk) 01:12, 22 January 2015 (UTC)
  • Jackmcbarn, please add me as a gerrit reviewer and CC me on the Phab ticket when you're working on this. Thanks. — {{U|Technical 13}} (etc) 01:25, 22 January 2015 (UTC)

Just to be clear, I don't interpret this as meaning the right-holder would be expected to spend most of their time fighting vandalism. I would simply use it to save myself and admins some time, while cutting off the offender sooner, when I run across a vandal while in the usual course of editing business. If that's not the intention, I would still support but wouldn't apply for the right. ―Mandruss  01:34, 22 January 2015 (UTC)

That's the intention. Jackmcbarn (talk) 01:39, 22 January 2015 (UTC)

Given that the bars for rollback and PC reviewer aren't that high, I'd like to consider more stringent qualifications, like a demonstrated track record at AIV & RFPP to the granting admin's satisfaction. It would require a little bit more due diligence but given the level of access I think that's OK. I also think the name is a little too bombastic; my first thought was "patroller" but that's already used elsewhere. Regards, Orange Suede Sofa (talk) 01:58, 22 January 2015 (UTC)

That would probably count me out. I've hit AIV once (appropriately) and RFPP once (appropriately). Not much of a track record. But I would still be a very good vandal fighter and I certainly know the difference between a clear vandal and a disruptive editor. ―Mandruss  02:08, 22 January 2015 (UTC)

Right now there are two AIV boards - one for humans and one for bots. Can a third be added that would contain entries that would automatically be added when a vandal stopper blocks someone? Admins could review this board and lengthen blocks if necessary or remove these rights if an incorrect block was made. --NeilN talk to me 03:41, 22 January 2015 (UTC)

There will be something like that. Jackmcbarn (talk) 03:44, 22 January 2015 (UTC)

Why not give them full blocking ability, only to be used on vandal accounts. Just like roll back can onlt be used in certain situations. Any abuse or use out of scope can be dealt with by removal of the right. It would be much easier to implement and understand. Sincerely, Taketa (talk) 03:55, 22 January 2015 (UTC)

FWIW, I intend to be one of the closers. Similar discussions happen roughly once a year, and I can't detect a pattern; every discussion has had different voters and closers. The most common question for closers is whether we're going to settle it by vote-count or by weight of the arguments ... I can't speak for anyone else, but the best I can tell, most closers approach it the same way. We don't want to take away people's right to speak up and be counted, so if there are a bunch of votes in either direction, that side is going to get the nod ... unless there's a credible argument that people are voting multiple times or being canvassed, but so far, that's never been even a factor. If it's not clear from the numbers which way to go, then we look hard at the arguments ... not with the intention of nullifying votes, but with the intention of listening to what the voters are really asking for. We can't assume that any "no" vote to a new user-right implies that voter wants to see Wikipedia go over a cliff, nor can we assume that a "yes" vote means the voter wants the new user-right to stay in play even if it's not working out. Here's some free advice to both sides: make your case. Present some data. Present some good arguments. Some Wikipedians are kind of dug-in on these issues, but many aren't, and most will listen to you if you listen to them and make your case. One last thing: please check back at the 30-day point or whenever the RfC has run ... if it's not clear which way the RfC is going to go, it would really help if we (the closers) could ask the voters to clarify what you meant or what kind of compromise you'd be willing to settle for. - Dank (push to talk) 04:39, 22 January 2015 (UTC)

Suggest that we have clear rules for removing this access such as with other advanced permissions, including for inactivity or for any actions that lead to a block. — xaosflux Talk 04:30, 22 January 2015 (UTC)

Strongly agree here. We should remove for inactivity for the same reason as for admins with the option of giving it back when they return. I think most under-a-cloud type removals ( wheel warring, abuse, careless use that causes too much work, etc. ) should remove the ability to get this right back except for getting the equivalent powers by passing an RfA and becoming an admin. PaleAqua (talk) 01:59, 23 January 2015 (UTC)

Without commenting on the substance of this package, can we please lose FIGHTER from the name. Fighting terminology is not very helpful or welcoming. Patrollers, Blockers, Fixers, Minions, .. open to any other suggestions.. but nothing aggressive please. -- zzuuzz (talk) 12:33, 22 January 2015 (UTC)

Antivandal ―Mandruss  12:42, 22 January 2015 (UTC)
That's what I was thinking. It sounds more professional than most of the other ones. --Biblioworm 13:09, 22 January 2015 (UTC)
How about sergeant-at-arms? Personally I don't like the word "vandal" in the name any more than I like the word "fighter" - it just sounds deliberately confrontational. Ivanvector (talk) 16:55, 22 January 2015 (UTC)
Another closer note: even if the vote is 100 to 5 to to approve "vandal fighters", that doesn't mean it's not possible to call them anything else ... it's reasonably clear that people are supporting the creation of a role, and not necessarily every detail of the proposal. That's another reason it would be helpful for people to stick around at the end of the RfC, to work these things out, if needed. - Dank (push to talk) 20:44, 22 January 2015 (UTC)

I have no opinion about the current specific proposal as advanced for the purpose stated, but just want to comment that this is just the most recent attempt to create a user group holding a subset of the rights currently held by administrators. The proposal has, in the past, most frequently been advanced a form of trial period or apprenticeship as one of the various methods advanced to fix or replace the RFA process. Something like it was also advanced as a means of controlling incivility at disputatious article talk pages. The community has, up until now, never supported these ideas. While I express no opinion about the current proposal for its stated purposes, I support it as a form of creating "junior administrators" for the purpose of working around the current RFA system. Because my support is not for the stated purpose of this proposal, however, I do not feel that it should be considered in evaluating consensus on this proposal unless the "junior administrator" purpose is substantially advanced as a reason for this user right change in addition to its current stated purpose. Regards, TransporterMan (TALK) 15:27, 22 January 2015 (UTC)

In the user-rights RfCs, closers have been asked to comb through all the comments to see if there are people who actually supported or opposed but didn't record a vote in the proper section. I'd appreciate it if you could talk a little more about what you'd like to see happen with this proposal; I can't quite tell if you're supporting, even though you say "support". - Dank (push to talk) 16:07, 22 January 2015 (UTC)
  • "Anti-vandal patroller" could be a decent alternative if people have issues with the name (zzuuzz alluded to it in their comment above). I don't think there are many sensible names for this type of userright that don't include "vandal" somewhere; as cool as sergeant-at-arms may sound, or something like Keeper of the Peace, they aren't the most self-explanatory things (although that being said, nor is autoconfirmed!) Lukeno94 (tell Luke off here) 21:06, 22 January 2015 (UTC)
  • I have to agree on the name. While it is an accurate description of what the package would be for, it seems overly confrontational. Beeblebrox (talk) 00:47, 23 January 2015 (UTC)
  • I like the idea of referring to the proposed user right as a "Housekeeper" right. That's exactly what they'll do. They'll keep the house, and clean-up simple messes on a day-to-day basis. RGloucester 01:06, 23 January 2015 (UTC)
  • Something vague like sentry could work. But as has been mentioned, the choice of name is really a separate issue and shouldn't bear on one's !vote, and it could easily be a separate discussion. As we all know, getting hung up on details is what kills far too many proposals. For purposes of this discussion we could say rightX or something and get on to more important questions. Any takers? ―Mandruss  01:14, 23 January 2015 (UTC)
Changing the proposal to a "right X" for the time being seems appropriate, allowing it to be resolved later. I really am fond of the cleaning analogy. It is meaningful without being antagonistic. RGloucester 01:16, 23 January 2015 (UTC)
I didn't mean to have implied that I would not support based on the name. I support the proposal, full stop. You can change the name to "bloodthirsty vandal-murdering gravyweasel" and I'll still support it on principle. (but please don't) Ivanvector (talk) 20:10, 23 January 2015 (UTC)
  • Question Would the user have to have rollbacker and pc reviewer already, or simply meet those requirements? KonveyorBelt 01:27, 23 January 2015 (UTC)
Since no one is rushing to answer this, I'll offer my take. It says, Rights would only be granted to user who meet the requirements of both roll back and pending changes reviewer. I'm taking that literally. If rollbacker and pc reviewer were prerequisite rights, I assume they would have said that instead. The writer seems articulate enough. FWIW,―Mandruss  08:02, 23 January 2015 (UTC)
  • Questions. This would obviously need software changes, so do any developers here know how likely it would be to get the resources to do it, and would such software development require the WMF's approval? Squinge (talk) 09:14, 23 January 2015 (UTC)
    • User:Jackmcbarn has already offered to do it. I think we can implement new user rights named rblock and rprotect (as in "restricted" block and protect) that allow users with this right to block and protect only within a specific timeframe defined in a wg variable. Zhaofeng Li [talk... contribs...] 09:21, 23 January 2015 (UTC)
      • OK, thanks! Squinge (talk) 09:54, 23 January 2015 (UTC)

Comment – I hate to say it, but it isn't fair that the majority of you are sysops who may look at it differently because you had to go through RfA. This isn't really fair. You all act in good faith, but it really is bad to see the lack of user distribution between admin and non-admin users on the oppose vs support. Some of you bring up legitimate concerns, yes, but some of you don't. Dustin (talk) 03:50, 23 January 2015 (UTC)

How is it not fair for us to oppose something? You can say some of us are wrong, or don't make good points but that doesn't make it "unfair".
I would suggest that you consider the fact that admins who got their tools post-2007 managed to make it through a very difficult process that, despite it's flaws, is designed to weed out those who do not have suitable levels of policy knowledge or the wrong attitude to be going around blocking other users. And even then, we still sometimes fail and the wrong person gets the tools. To shortcut that process so severely so that all anyone has to do is find one sympathetic/gullible admin and -bam- they have half the tools themselves and can cause all kinds of trouble with them is frankly a frightening prospect.
Vandal fighting is important and I think most admins really appreciate the work that is done by non-admin users in detecting and reporting vandals, but without a real test of their judgement and ability to keep their cool, such as RFA, we should not be granting powerful tools like blocking and page protection, which prevent users from editing. We get enough complaints about these things when they are done by qualified admins. Letting anyone with a few good AIV reports just start hammering away would be a serious mistake, and would not ease the workload of current admins. In fact it might make it significantly worse with unblock and unprotection requests getting jammed due to a few trigger happy pseudo admins. Beeblebrox (talk) 06:47, 23 January 2015 (UTC)
can cause all kinds of trouble with them - Yes - for all of about an hour, until their right is revoked. Either permanently, or for a very long time. Sorry, but I'm calling hyperbole and alarmism. I can easily produce five or six experienced, respected editors to attest to my integrity and ability to keep my cool. Just say the word. This process should be about fairly and objectively weighing potential benefits against potential costs, not zeroing in on potential costs and blowing them way out of proportion. ―Mandruss  07:34, 23 January 2015 (UTC)
Blatant abuse isn't really the main problem (IMO). The biggest problem I can foresee with the proposal as-is is misuse due to inexperience/overzealousness. I'm sure any admin who regularly handles AIV or RFPP can attest to the number of non-actionable reports. At AIV: the worst case is users making low-quality, but good faith edits reported as a vandal. At RFPP it's usually just people requesting semi-protection on a page that's only been vandalized twice in the last month, or only vandalized by 1 user. Improper blocks can easily drive away potential new contributors and overuse of semiprotection goes against one of our core principles - that anyone can edit. I think there's a lot of value to the current system in which most vandalism blocks and page protections are independently reviewed before they're done. Reverting a couple extra vandalism edits because a report sat on AIV for an hour is easy. Convincing a good-faith user to give WP another chance after he's mistakenly blocked as a vandal isn't. Mr.Z-man 14:15, 23 January 2015 (UTC)
But anyone can post at AIV or RFPP. Do you even have to be registered? Obviously the admin is going to spend 15 minutes or so looking the candidate over before granting the right, checking out their history, maybe even engaging them in a brief interview or asking for references. I can't imagine enough bad ones getting through that to offset the benefit of the good ones. If they did, we simply raise the bar a little. No reason to oppose here. Nothing like this will be perfect out of the gate. ―Mandruss  15:07, 23 January 2015 (UTC)
As I said in my comment further up in this section, without even having to look through the history, I found rejected reports at both pages by (different) users who had both rollback and reviewer. You're assuming that admins will do a thorough job, but that's not what the current proposal says they have to do. It says it will be given to people who meet the requirements for rollback and reviewer, which have fairly low standards. Mr.Z-man 15:39, 23 January 2015 (UTC)
Fair enough. @Oiyarbepsy: Any problem with adding something about vetting? ―Mandruss  15:45, 23 January 2015 (UTC)
I wrote some fairly detailed suggested text for the above (see page history if curious), then decided it would start us down a path of neverending quibbling over details. Could we simply say something like, Reviewing administrator will vet the applicant and may reject, details to be established separately? ―Mandruss  17:07, 23 January 2015 (UTC)
On the other hand, it was running into semi-protection that finally convinced me to make an account. Pathore (talk) 05:50, 25 January 2015 (UTC)
  • I realize it is kind of late for this, but considering the requirements to be added to this group seems to be the biggest stumbling block, I would support removing the criteria all together and see if there is consensus to create such a group with details about acquiring the right to be determined upon completion of this RfC as successful in determining that such a group that can do these things is needed first. — {{U|Technical 13}} (etc) 02:18, 24 January 2015 (UTC)
Seems this could also work well with obvious UPOL violations. Mlpearc (open channel) 05:22, 24 January 2015 (UTC)
  • Comment (I've placed my oppose vote in the voting section above). Some of the supporters make some good arguments but the two main objections I have are 1)The hat collecting, and 2) the fact that rather than reduce admin workload, it will increase it. Any admin who has worked the WP:PERM pages, expecially Beeblebrox and I who have held the fort there for years, will be aware of the extent of hat collecting, and grabbing these rights as trophies, and like many admins in fact, once they've got thier bit they tinker with it for a while then leave their new toy aside. If such a right gets created and if it's up to admins to accord it at PERM, there will literally be a stampede for it. If such a right must be subjected to an RfA style debate, then the cadidates should be sufficiently competent to stand a good chance for the mop. Such a right would simply keep the admins on their toes checking on its use, much in the same way that I patrol the patrolers at NPP who ironically for such an important task, need no qualifications whatsover - and it shows. I don't go to AIV much but when I do I linger there to clear up the backlog and I'm frankly staggered by the number of totally incompetent listings - are those from the 'vandal fighters' the supporters want turned into mini admins? --Kudpung กุดผึ้ง (talk) 08:33, 24 January 2015 (UTC)
  • Comment. Many in the oppose section complain that this would increase admin workload. (There seems to be blue highlights scattered everywhere in that section; it could just be coincidence, but it might be something else. [Just kidding; we need some humor around here.]) If that is really the case, why is it that the introduction of the template editor right didn't have the same effect? TE and the proposed antivandal right are similar; both unbundle very potent admin tools. For example, a template editor could ruin the appearance of many pages with a single edit, but when that does happen, an admin can simply remove the right immediately. Not to mention that TE has a strict granting standard. So, TE pretty much disproves the argument that people will "stampede" for the right, create a monumental amount of admin work, and create chaos. --Biblioworm 17:19, 24 January 2015 (UTC)
    • The differences between this and template editor, to me at least, are:
      1. TE requires a demonstration of competence through experience with template editing and work on sandbox versions of protected templates. The proposal here requires only that they meet the requirements for rollback and reviewer, which are often given to people with only a few hundred edits and a couple months of editing experience. That these are insufficient requirements should be plainly obvious. Looking at the last few days of rejected requests for SP/PC in Wikipedia:Requests for page protection/Rolling archive, 13 out of 23 requestors had rollback and/or reviewer.
      2. We don't encourage template editors to make bold, unilateral edits to protected templates. The only edits we tell people to make without discussion are fixes to broken markup and edits that don't actually affect the output. So in practice, most edits to protected templates are still discussed in advance. That's kind of the opposite of the intention here, which is to bypass the pre-action independent review at AIV and RFPP.
      3. No one is going to give up on Wikipedia because they saw a broken template in an article, they might if they're mistakenly blocked as a vandal.
    • Mr.Z-man 20:07, 24 January 2015 (UTC)
      • Why, then, don't we get rid of the rollback right and restrict CSD/PROD/AfD tagging to users who have gone through an approval process? If you're new, having your good-faith edit reverted and your article put up for deletion can be very hurtful, but we have generally low standards for rollback and none at all for NPP. If we tried to institute more strict requirements for any of the things I just mentioned, it would be swiftly rejected by the community. The point here is that there are many things that a regular user can do that can drive away new editors. --Biblioworm 20:35, 24 January 2015 (UTC)
        • Yes, there obviously are things that anyone can do to drive away new users, but that doesn't mean we should ignore that as a concern and give them more ways to do it. You don't need special rights to out someone, should we give everyone checkuser too? If you assume every vandal gets 4 warnings before they're blocked, there are 5 times as many vandalism edits to revert than there are vandals to block (probably more when you consider that many stop before they're blocked and many get more than 4 warnings), so we need a lot more people with the ability to revert than we need with the ability to block. And of the 3 main admin tools, page protection is the least used – RFPP usually gets less than 50 requests in a day. Editing protected templates isn't done very frequently, but TE still solved an actual problem in that the vast majority of admins don't actually have the technical knowledge to review edit requests to templates and modules. Don't get me wrong, I'm not fundamentally opposed to unbundling these tools, but absent a demonstrated problem to solve or a proposed process that won't result in users with 1 month of editing experience being granted the ability to block users, there's no way I can support this. "Backlogs" aren't really a serious problem because backlogs are relative. CAT:CSD is considered backlogged when it has more than 50 requests, WP:AIV is considered backlogged when it has more than 5. Mr.Z-man 21:20, 24 January 2015 (UTC)

@Mr.Z-man: The proposal here requires only that they meet the requirements for rollback and reviewer It doesn't seem particularly fair to keep making that argument when I have proposed a solution to it (see "vetting", above) and the proposal is still pending a response. I'll ping Oiyarbepsy again. ―Mandruss  22:13, 24 January 2015 (UTC)

MandrussI read it again, and I don't understand what your proposed solution even is, aside from the word vetting. Vetting by who and when and what exactly is being vetted? Oiyarbepsy (talk) 02:59, 25 January 2015 (UTC)
@Oiyarbepsy: Sorry if I wasn't clear. Several opposers have cited as one reason the fact that the bar is no higher than that for rollback and reviewer. That seemed like a reasonable concern to me, and I proposed that the reviewing admin perform vetting of the applicant, to a greater extent than they do for rollback and reviewer. I initially proposed some specifics, here, and then decided that specifics would only bog down this discussion and a consensus on them could be reached later. So I proposed a more general statement to be added to this RfC, which is above. If you think something more specific is needed, that's fine, but I feel that some response to the concern is needed. ―Mandruss  03:13, 25 January 2015 (UTC) Note that I have now added something about specifics below, per Mr.Z-man's suggestion.―Mandruss  08:01, 25 January 2015 (UTC)
How is it "unfair"? Lots of people have suggested tweaks to the proposal - letting blocks be indef, changing the name, doing a trial period - but until they're incorporated into this proposal or a new one, I can't just pretend that the issue has been solved when the proposal hasn't incorporated the solution. I even tried to clarify my comment by saying "the proposal here" to specify that it only applies to this proposal. But I would disagree with having a proposal with no specifics. How would that even work? Say we agree to create the new group, but can never come to a consensus on standards - then what? Would people who are opposed to the group in general be forbidden from participating in the discussion for standards? Mr.Z-man 04:48, 25 January 2015 (UTC)
Points taken. Ok then, I think the main specific points should be:
  • Interview - The admin could discern a lot about the applicant's suitability for the right by asking them some questions. Some of this goes on at Requests for permissions, but it's ad hoc and not a formal part of the process. It could be done on the applicant's user talk page.
  • References - Require at least three references. This could be done in either of two ways. The applicant could provide at least three usernames, and the admin could contact each reference on their talk page. Or, the applicant could ask each reference to post a statement with the request for permission. The main thing here is that the admin should weigh not only what the references say, but also who they are. An applicant who provides three quality references from experienced and respected users should stand a far higher chance of passing vetting than one who provides six references from yearlings, some of whom have some behavior issues of their own.
  • History - The admin who reviewed me for rollback apparently took a fairly thorough look at my history, judging by some of the things he noticed. I don't know how common that is for rollback, but it should be done for every request for rightX (my code word for the right proposed in this RfC). A block within the previous year could be an automatic disqualification. There are tons of ways this could be tuned and refined.
It's inconceivable to me that enough bad apples could get through this to make this right a net negative. If a person is going to use the right to make trouble, that should show up in the history review alone, never mind the interview and references. I hope this helps. ―Mandruss  06:20, 25 January 2015 (UTC)
Enough bad apples used to get through RfA in pre-2007 times, Mandruss, and some still do in spite of our screwing the bar as high as we dare. --Kudpung กุดผึ้ง (talk) 11:26, 25 January 2015 (UTC)
Unless it's done "live" via IRC or Skype, an interview is useless. It's basically an open-book test. People can take hours looking up the "right answer" to questions. All that does is filter out the people who are so clueless they don't even know where to look up the answers. References aren't really any better. No one ever writes a bad reference for someone. At worst they might refuse, but no one will see the refusals, just the positive references from the people who agreed to do it. Looking at history is really the only practical way and is basically what I suggested in my oppose comment. RFA uses an "AFD stats" tool to determine how many AFD !votes a candidate has made and what % were actually in line with the outcome of the debate. If the latter number is too low, it suggests their interpretation of WP:N and WP:NOT aren't in line with what the community expects. If we decided to implement this proposal, I'd like to see similar tools for AIV and RFPP - how many reports have they made and what % are acted upon. If we wanted to get really quantitative, we could establish minimum numbers for both, combined with "general experience" criteria like for Template Editor (1 year+1000 edits, no recent blocks). Looking at a random sample of their rollbacks and PC reviews would also be useful. Leaving too much up to individual discretion is a recipe for inconsistency and standards creep (either getting stricter or more relaxed). Mr.Z-man 16:22, 25 January 2015 (UTC)
  • Comment: Comparing Template Editor with Rollback & Reviewer makes a very poor analogy. TE is not a 'power right' - it does not give an editor power over another editor, it just confirms a level of technical competency like getting a driver's licence or a PPL. Rights that give power over users' edits and/or behaviour are magnets to the hat collectors, brownie point seekers, and the power hungry for whom the Wikipedia backroom is just another MMORPG. At the fear of repeating myself, those of us (sorry only admins) who have worked the WP:PERM pages are only too aware of all this.
CSD/PROD/AfD tagging most certainly should be restricted to users who have gone through an approval process, and the fact that NPP doesn't need a right is evidenced by the poor understanding of deletion, the biting of newbs, and the picking of low hanging fruit at the New Page Feed leaving us with a 31,000 backlog. Ironically, WP:AFC - a far less important process - has a bar of 500e/90d that has proven time and time again to be far too low although I proposed it myself in GF knowing that the community would reject a higher one.
To those who are evoking Wikipedia:TINC, all I can say is that such groups exist only among non-admins, namely either those who are sysop wannabes, or those who are so resentful that they will never be given the mop, do all they can to disrupt our processes and bring the very encyclopedia they 'so love' to contribute to into disrepute both on-Wiki and in other places. We certainly don't want to create easier-to-obtain minor rights that will give them a tool to vent their spleen. --Kudpung กุดผึ้ง (talk) 03:46, 25 January 2015 (UTC)
I'll say two things again, in the diminishing hope that someone is actually considering what is being said here. How much spleen can be vented before the right gets revoked? And why are you looking only at the downside? ―Mandruss  04:01, 25 January 2015 (UTC)
I looked at the 'upsides', Mandruss, and if I thought the idea were a net positive I would be up there in the 'support' section. I'm not. But I haven't suggested that this proposal was made in bad faith, nor criticised anyone's rights to express themselves. --Kudpung กุดผึ้ง (talk) 11:34, 25 January 2015 (UTC)
Ok. Well I've contributed about all I can to this, if I've contributed anything, so I'll just lurk from here on out. May the best side win. ―Mandruss  11:56, 25 January 2015 (UTC)
Although I certainly respect your opinions, Kudpung, we will obviously disagree on some points. First of all, it's really difficult to overlook the pessimistic tone of your comments concerning non-admins and "newbs". They always seem to assume that the newbies are clueless, cause trouble, and need to be restricted and monitored, while non-admins are portrayed as power-hungry hat collectors who are dedicated to making war and troubling the noble admins. (I'm certainly not suggesting that admins are not noble, but I think people know what I'm trying to say.) Also, the reference to TINC was intended to be a joke, and I clearly marked it as such. (Aside from dragging me to ANI and passing some sanction which says, "Biblioworm is hereby forbidden to use humor and must forever be a serious stone-face", I suppose that people will have to learn how to live with my general light-heated attitude. ;)) In any case, I generally like to think that I'm a fairly well-respected editor who isn't on anyone's "dislike" list, so I'm not going to blow it by getting into some argument over something so minor in the larger scheme of things. --Biblioworm 05:42, 25 January 2015 (UTC)
Of course my comments sound pessimistic, Biblioworm. After six years of campaigning to improve NPP, improve RfA, improve the image of adminship, and four years of seeing life from the perspective of a busy admin, it's clear that I have accumulated a different outlook from that of the non admins. Rather than 'pessimistic' however, I would have preferred my line of thinking to be labeled as 'pragmatic'. --Kudpung กุดผึ้ง (talk) 11:13, 25 January 2015 (UTC)
  • I've been thinking a bit about this proposal a put together my thoughts on an alternate version in my sandbox that attempts to at least address some of the opposes and concerns raised. ( FWIW I have zero interest in getting this right myself, similar to how I offered input for the proposal for TE but did not seek/want that right. ) Thoughts? PaleAqua (talk) 08:03, 25 January 2015 (UTC)

Bots (vandal fighter)[edit]

Another interesting component that hasn't been touched on in this discussion here that just occurred to me, what about bot accounts. Certainly no-one can deny that one of our best anti-vandal contributors is Cluebot, so I'm wondering if such a new user-right is created, should there be bots that are allowed to have it and make use of it which would certainly be beneficial to the encyclopedia by stopping potential vandals quickly and allowing admins to check through the list at their leisure to confirm or increase the problematic ones. Just food for thought, and I think it is worth discussing. — {{U|Technical 13}} (etc) 16:30, 24 January 2015 (UTC)

  • I'm not at all comfortable with allowing bots to decide when to block users or protect pages, so I would oppose this idea. Beeblebrox (talk) 16:33, 24 January 2015 (UTC)
    • I'm expecting there are many who feel the same, which is why I felt it needed to be discussed. If the OP decided to not remove the above requirements (as I suggested would be a good idea) for another RfC to iron that out exactly, then those above requirements would allow for bots if there was no subsection discussion on the matter. I could try to make a case for allowing bots to do this, but will hold off at this time. — {{U|Technical 13}} (etc) 16:56, 24 January 2015 (UTC)

Bots? Are you crazy? Did I actually need to specify that bots can't block, since it seems really obvious that they shouldn't. Has block-bot ever been approved? I seriously doubt it. Oiyarbepsy (talk) 03:02, 25 January 2015 (UTC)

Yes, we have bot-blocking, but under very strict guidelines (c.f. User:ProcseeBot) - there would need to be a strong community consensus established to allow anything like that, the operator would need to qualify for the permissions first, then the community would need to decide it is a task that should be done, finally WP:BAG would need to review the operations -- a steep hill to climb. — xaosflux Talk 03:09, 25 January 2015 (UTC)
And ProcseeBot blocks based on purely technical reasons. Vandal and spam blocks require human judgement. Oiyarbepsy (talk) 03:15, 25 January 2015 (UTC)
There was AntiAbuseBot (talk · contribs). Elockid (Talk) 03:19, 25 January 2015 (UTC)

Search everything - including time search[edit]

Search "everything" does not yet include the possibility to include older versions of articles into the search. The search "everything" should allow this IMO (i.e. query the entire database). (talk) 05:04, 23 January 2015 (UTC)

Well, I have some concerns about this. This would, for example, make copyright violations and spam searchable. Some of the stuff removed from articles and other pages was removed for good reason. Oiyarbepsy (talk) 04:07, 24 January 2015 (UTC)
Would probably also make search times insanely long. ansh666 07:00, 24 January 2015 (UTC)

You know, something like this might make sense as a script, or something that isn't inherently part of Mediawiki. Not needed most of the time, and I think Ansh is right about excessive search times, but there are certainly cases where it could be useful. Oiyarbepsy (talk) 07:09, 24 January 2015 (UTC)

Wikipedia:Lock down (WP:LD) and Wikipedia:Deadline (WP:DL) proposals[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
The result of this discussion was NO SUPPORT... Closing per WP:SNOW Mlpearc (open channel) 22:22, 23 January 2015 (UTC)

Please place this proposal on the appropriate page if this page is not the right one for it or merge it with another discussion if there is one for this (not that I could find one).

Wikipedia:Lock down (WP:LD)[edit]

Seeing many pages and topics on wiki that need no further editing; especially topics on things and people that are outdated and/or diseased, the article just sits there in it's complete form without being needed to be edited any further. The only editing it would need is reverting vandalism or the removal of false information/nonsense which is really just another form of vandalism. All this is time consuming for editors who could be doing something else to improve Wikipedia.

Articles/pages like these in my opinion need to be permanently protected and saved. I am proposing this because let's face it: We can't rely on bots to always revert vandalism. Bots don't have the same capacity as a humans common sense to keep or remove content in an article.

I am also proposing this because when I leave Wikipedia for good, I don't want the risk of my work being destroyed. I put in a lot of time to Wikipedia creating and updating pages and dread the idea that it's prone to being destroyed. I'd have wasted my time and the same is true for many, many other editors.

But at the same time I (and most certainly the rest of the community) want to be very careful in going about this procedure. Suddenly locking an article when there are dozens out there with the intend of updating/improving it are denied it.

So this is how I'd propose a procedure to permanently save an article or any other page that no longer needs updating. For example an article about a film produced in say 1950. All there is that needed to be known about the film is there, including cast and crew, presumably retired or diseased and there is absolutely nothing more to add to (or remove from) the article. The article has had no activity for months or years besides vandalism and/or trolling. No discussion on the talk page has been made in months or years. The article has a history of having been given nothing but positive reviews for it's quality of info (not necessary, but highly recommended). A user seeing it in it's most complete form places a WP:LD tag, similar to a WP:AFD tag and proposes it be to be locked. A discussion in the proposal entry follows and if there is absolutely no objection from any party, then it should be locked. A user opposing an article or page's lock should give reasoning as to why he/she believes it will need updating in the future. This one opposition, if legitimate, should be sufficient to block any upcoming lock.

Similar to a protected or semi-protected article, there should be an icon on a page that has been locked after meeting the lock down criteria, so anyone wondering why it's not editable will see any discussion that followed and how to request a temporary unlock. If an article gets too many unlock requests in a short time span, say a few times every few months (for any legitimate edits keep in mind), a discussion should be started and the article proposed to be unlocked. This is in case an article has been mistaken to meet the lock down criteria. It's a mistake we can reverse.

Overall, locking article should become part of Wikipedia's greater lock down procedure. Because if an encyclopedia has met it's goal to keep the most reliable and best quality information, I see no reason to it being senselessly prone to vandalism or being open to edits; especially if people are too busy to guard it.

I don't edit wikipedia as often as I used to when i was here previously, so I won't be able to participate in this discussion very often but hope to see some contributions when i return here. --Nadirali نادرالی (talk) 20:27, 23 January 2015 (UTC)

  • Strong oppose - This is the same as full protection which is used sparingly and with a time limit. Articles are never finished. Just because you're done does not mean a brand new editor can't improve the article a couple years from now. There should be no barrier preventing this. --NeilN talk to me 20:58, 23 January 2015 (UTC)
  • Totally oppose. I can't envisage any article that couldn't potentially be improved, and I challenge you to think of one. Your existing example, of a 1950s film, would need to be updated every time someone wrote a book about 1950s movies, for instance. I can see a case for preserving "last clean version" links (which is already done for FAs and GAs - on the talkpage of each you'll find a link to the version that passed FA/GA), but certainly not to prevent anyone making changes. Your idea that there are articles that lie untouched for years is just not true - a very few articles have been untouched since 2008, but they're a tiny minority, and you won't find a single example on that list that doesn't need improving. Mogism (talk) 21:00, 23 January 2015 (UTC)
  • Again this is with regards to pages that need no further editing. It's not to prevent anyone from contributing, but for protective purposes. Besides the decision can always be reversed as proposed above. Besides who's going to look after so many things at once? Don't forget to comment on the second proposal. Thanks.--Nadirali نادرالی (talk) 21:05, 23 January 2015 (UTC)
    • Nadirali نادرالی, I'll be blunt. This has zero chance of being accepted. --NeilN talk to me 21:09, 23 January 2015 (UTC)
      • To echo NeilN, please drop this. There is no such thing as "pages that need no further editing", and never will be. Mogism (talk) 21:11, 23 January 2015 (UTC)
    • Nadirali نادرالی, purely out of curiosity, which articles out of the ones you've worked on do you consider to be done? --NeilN talk to me 21:24, 23 January 2015 (UTC)
  • Oppose: Re "pages that need no further editing", that can never be determined in any objective way. It's utterly impossible to foresee what good ideas for change people might have in the future, what things we think we know now might turn out to be wrong, or what further developments might happen that are relevant to what we might think today is "finished". Squinge (talk) 21:16, 23 January 2015 (UTC)
  • Absolutely not. Townlake (talk) 21:17, 23 January 2015 (UTC)
  • Oppose - However. In my less-than-vast experience, a typical article goes through a hot development phase, with multiple experienced editors massaging, refining, hammering out the tiniest of details. The article is polished. Then they move on, and I've yet to see an article see a net improvement from that point. Instead it's almost all casual drive-bys who prefer nice quiet articles where their chances of being reverted are far smaller. They "improve" a phrase that the experienced guys spent three days honing to a sharp edge, and the result is decidedly not an improvement. Even if I'm still watching the page, do I want to revert when I know I have no support around? When there's a real good chance I'll have to template the person two or three times and then take them to ANEW? No thanks, I'm busy doing something else and the cost/benefit just isn't there. So why should the experienced guys bother working so hard on it in the first place? This needs some kind of a solution if not this one. End rant. ―Mandruss  21:42, 23 January 2015 (UTC)
  • Oppose To echo the above, we already have an equivalent procedure in place, which is protection (semi- or full protection), and also something new may come up related to an article that is outdated. I'll give an example, an building structure related article has been abandoned because it is determined that nothing has happened with the building that the article was referring to, but suddenly, the structure has been given a new upgrade along with the rest of the city. Then the "abandoned" article is updated o finally reflect the new changes to that building. Not sure if this is the best example I've got, but I think you'll understand where I'm coming with this. Again, this is a work in progress because lots of things happen that would require updates to this particular site. Thanks. (talk) 21:50, 23 January 2015 (UTC)
  • Oppose I, too, would love to know which articles you consider "finished", and no longer in need of editing. Because I have yet to run across one. DoctorJoeE review transgressions/talk to me! 22:01, 23 January 2015 (UTC)
  • Strong oppose - a noble proposal, but misguided. The encyclopedia is never complete; articles are never finished. It would be frankly arrogant of us to say that we have all of the knowledge on a particular subject and can never conceivably improve it further. Ivanvector (talk) 22:07, 23 January 2015 (UTC)
  • (edit conflict × 2) Strong Oppose. An article can always be improved. This would just add extra complication to the process of making a few tweaks to a "locked" article. If this were to be implemented, we should change our "The free encyclopedia that anyone can edit" slogan to "The free encyclopedia that admins can edit". This reminds me of the "approved articles" over on Citizendium (which are supposedly "finished"), and although I'm sure Sanger set it up with good intentions, that project has been a relative failure in comparison to Wikipedia, probably because of the numerous restrictions and expert approval system. (See, for example, Citizendium's article on Italy, and compare it to our's.) Although this is not exactly the same thing, I feel that making editing more difficult would have similar results. (By the way, I suggest that this proposal be closed/withdrawn per WP:SNOW. I think this will probably go the same route as my "no oppose section RfAs" proposal turned out.) --Biblioworm 22:08, 23 January 2015 (UTC)
  • Oppose - We have WP:RFPP so not really seeing any need for this at all. –Davey2010Talk 22:11, 23 January 2015 (UTC)

Wikipedia Deadline (WP:DL)[edit]

Knowing that a lot of discussions/proposals on articles to be moved or POV/accuracy templates etc. don't get as many responses as they used to or the person placing these tags don't bring it up on the discussion page, I propose a deadline template be placed so people will know that proposals don't have forever. So say a person places a proposal tag to merge an article or rename it, he/she can also place a deadline timer with it that is no longer than three months long. Which means in three months if there is no response that user may go ahead with his/her proposal. This will help speed up thing on wikipedia. The deadline timer template on each day will tell how much time is left to oppose/endorse the proposal. Once a discussion is in progress, the timer may be switched off. And if the opposing party or parties ended the discussion without providing any sufficient reasons, then the timer can be re-instated.--Nadirali نادرالی (talk) 20:46, 23 January 2015 (UTC)

This is basically WP:BOLD with added unnecessary processes. Sam Walton (talk) 21:27, 23 January 2015 (UTC)
  • Oppose again. There is no deadline. Nothing is really stopping an editor from declaring that they will close a discussion and do some indicated action at a given time, but equally (and importantly!) there is nothing stopping some other editor from objecting to the action at some later time (even indefinitely later) and reverting it. This is fundamental to our collaborative process, per WP:BRD. Ivanvector (talk) 22:11, 23 January 2015 (UTC)
  • Oppose - Anyone is free to improve/merge/redirect at any given time, Plus we have cats like "Category:Articles to be expanded from January 2015" so they can and do get done eventually, Again I'm not seeing any point to this. –Davey2010Talk 22:20, 23 January 2015 (UTC)

The above discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.