Wikipedia:Village pump (proposals)

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

New ideas and proposals are discussed here. Before submitting:

« Older discussions, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114


Centralized discussion
Proposals: policy other Discussions Ideas

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

Media Viewer RfC Question 1[edit]

We have a previous RfC consensus that Media Viewer should be default off. That RfC was never implemented due to the Superprotect controversy and a WMF Community Consultation process on Media Viewer. That community consultation process has ended and the outcome can be viewed here. I think it is time to review that outcome and determine whether we still want Media Viewer to be disabled by default. Alsee (talk) 17:33, 3 October 2014 (UTC)

(Note: There is a second question further down the page.) Alsee (talk) 17:53, 5 October 2014 (UTC)

Question One. Should we reaffirm and implement the previous RfC: WP:Media_Viewer/June_2014_RfC#Consensus.2Fdisapproval_has_been_established There is a clear consensus that the Media Viewer should be disabled by default for both logged-in (section link) and non-logged-in users (section link).

Support (Media Viewer RfC Question 1)[edit]

  1. SUPPORT as RfC author. The WMF's Community Consultation Process on Media Viewer resolved essentially none of the objections raised in the previous RfC. I believe our original image page is better than Media Viewer. Alsee (talk) 17:41, 3 October 2014 (UTC)
  2. Support Obviously nothing has changed, the default should still be off unless specified by editors (i.e. if an editor wants the mediaviewer used for galleries, etc). Not that it matters. I have zero confidence in the WMF's respect for consensus at this point. 0x0077BE [talk/contrib] 16:01, 5 October 2014 (UTC)
  3. Support as the attribution problem has still not been sufficiently addressed. This is a show stopper. --AFBorchert (talk) 16:13, 5 October 2014 (UTC) P.S. I think that is an inherently difficult problem, take File:Carentan Église Notre Dame Vitrail Baie 07 2014 08 24.jpg as example with a very complex copyright case which cannot be represented in any simplified manner.
  4. Support. Unless the consensus has changed, we should not allow the WMF to continue to avoid the issue of enablement, and at any rate we should not leave them with the impression of acquiescence. BethNaught (talk) 16:33, 5 October 2014 (UTC)
  5. Support - I still prefer the old one and probably always will, - At the end of the day the community decided it should be off, Period. –Davey2010(talk) 16:52, 5 October 2014 (UTC)
  6. Per AFBorchert.--Aschmidt (talk) 17:28, 5 October 2014 (UTC)
  7. Support, although this wasn't needed; community consensus has already been formed to disable it. Consensus-changing attempts are appropriate, but that would be the only reason for having such a discussion. Let me remind the closer that "no consensus" defaults to pre-discussion, which is unambiguously "off". Nyttend (talk) 19:29, 5 October 2014 (UTC)
  8. Support: The most frequent piece of feedback that WMF removed was "turn this to opt-in" and the WMF intentionally and purposefully ignored all such feedback [1][2][3]. Since the consultation was a sham, I see no reason to wait for any results.—Kww(talk) 20:09, 5 October 2014 (UTC)
  9. Support. It seems to me to be common sense that WMF should care what the editing community says. --Tryptofish (talk) 20:15, 5 October 2014 (UTC)
  10. Support. It's inherently inferior to the existing file page, and the community spoke after due examination of the two. Yngvadottir (talk) 21:06, 5 October 2014 (UTC)
  11. Support. I don't know why we are having this discussion again. We already know that 1 a large majority of editors prefer the pre-existing system, and 2 WMF people ignore and misrepresent our views. Maproom (talk) 21:46, 5 October 2014 (UTC)
  12. SUPPORT. It has already been demonstrated that a majority of the community do not like or want the new Media Viewer, so continuing to debate the subject only proves that WMF does not really care what the community thinks, and will keep asking the question until they get the answer they want. To repeat what I (and many others) have already said: The use of this new Media Viewer should be "Opt-IN" only -- it should never be on by default for anyone. FireHorse (talk) 22:20, 5 October 2014 (UTC)
  13. Support. Looks like they made a prototype ([4]) and I don't see anything important that has changed. The page seems to imply (meta:Special:PermanentLink/9840243 - "Screenshot of the Media Viewer's new design prototype") that that's how things will look. And we know that is what has been rejected. I doubt there is much point in giving WMF more time - it is pretty clear that they are not going to do anything else with it. Also, "Consensus can change" - if a miracle happens and they create something good, we can simply change our minds. But let's let them develop something good first and deploy it afterwards, not vice versa... --Martynas Patasius (talk) 22:29, 5 October 2014 (UTC)
  14. Support BUT - I want that Media Viewer on Commons On Commons should be left there. It is a great help on commons, but there is no text there. Please do not disable it on Commons. On Wiki it is kind of irritating. Hafspajen (talk) 23:24, 5 October 2014 (UTC)
  15. Support. WP:Consensus can change, but it is up to someone else - and WMF is certainly invited to do so - to make a new RfC to see if that's the case. Until then, we have a consensus, and it needs to be implemented properly. VanIsaacWScont 00:06, 6 October 2014 (UTC)
  16. Support. Absolutely. Nothing but an irritant (on the plus side, though, I must say that its combination with the typography change makes it impossible for me to ever forget to log in). Double sharp (talk) 01:33, 6 October 2014 (UTC)
  17. Support. Even the most optimistic reading of recent poll data, which shows that a plurality of users find media viewer userful for viewing images, only had 49% choosing that option. Note that the question is not "Is Media Viewer better than previous image pages", but is it useful for viewing images. If less than half, or even half, or even only two thirds of people find that it is useful in serving it's main purpose, that is to view images, then it is seriously unready to be the default. If only 50% of people that used a car found it "useful for getting from place to place" it would be seen as a lemon, but somehow 49% of people finding media viewer "useful for viewing images" is a good thing. The performance of the media viewing is still seriously lacking on underpowered hardware and older browsers that many people are forced to use, and the unlabeled icons are extremely difficult to figure out for a casual user of the site that doesn't want to have to learn a new UI just to view the details on an image. --Ahecht (TALK
    ) 02:30, 6 October 2014 (UTC)
  18. Support. I understand the need to make images easier to view, but I'm not convinced that MediaViewer is significantly better than the existing system at even that. And, as almost everyone can agree, it is far worse for viewing and editing image descriptions. As a reader of news websites, I'm not a huge fan of images that, when you click on them, occupy the whole screen against a black background. -- King of ♠ 02:38, 6 October 2014 (UTC)
  19. Support. — al-Shimoni (talk) 03:45, 6 October 2014 (UTC)
  20. Support: All the reasons above, my own gripe is that not only does it make editing a pain, and is hard to turn off, it also is SLOW; I can stream video faster than load a photo on the theing. Montanabw(talk) 04:15, 6 October 2014 (UTC)
  21. SUPPORT Assuming lowly anonymous readers are allowed to vote. MediaViewer is still an ugly, intrusive, invasive kludge. It does _nothing_ better than the old Wikimedia Commons webpage. — Preceding unsigned comment added by (talk) 01:50, 6 October 2014
  22. Support: Even after all the changes that have been made Media Viewer is a a clear step backwards in functionality, usability, and performance. Despite the WMF's assertion that this is a feature for the so-called "readers", every IP that chimed in was against keeping Media Viewer enabled by default. The WMF's own survey showed that fewer than 50% of English-speaking respondents who never edit found Media Viewer useful for its intended purpose. CONEXCEPT does not apply as the obvious intent of the policy was to check actions that went against the philosophy of the movement or that presented technical issues. Neither apply. For all all the aforementioned reasons, the RfC should be affirmed and Media Viewer should be returned to opt-in by default. Furthermore, if the WMF refuses to implement this consensus, I support administrators taking any technical or legal actions to make sure the consensus is in fact implemented. -- (talk) 06:38, 6 October 2014 (UTC)
    Not sure where you're getting your statistics, but they don't seem to agree with the ones I've seen, which show over 60% approval by English readers. Kaldari (talk) 07:24, 6 October 2014 (UTC)
    The 60% number is if you cherry pick the last two weeks of the survey, where responses trickled down to nothing. I was rather disappointed to see the Multimedia team be so dishonest with their data. I can't find the spreadsheet at the moment with the final results, but the cumulative reader approval rate over the whole survey was a smidgen below 50% at that time. I seem to remember looking very hard for it because the Multimedia team didn't post it in an obvious place. The last full results I can find right now puts reader approval at 37% in English, but I know I saw a similar spreadsheet that had the final results. I've removed your plots because they're misleading. The English reader plot only shows the last two weeks. The two global plots predate the English Wikipedia rollout and don't represent the opinions of readers and editors of the English Wikipedia. -- (talk) 08:00, 6 October 2014 (UTC)
    Discussion of the statistics is worthy of an entire section. Please take it to the discussion area. This is a bad place to debate what numbers are valid and what numbers are misleading.
    Notice: Three images added by Kaldari were removed by I consider it it entirely appropriate to remove images from this section. The diff and images can be viewed here. Alsee (talk) 10:11, 6 October 2014 (UTC)
  23. Support--Oursana (talk) 09:15, 6 October 2014 (UTC)
  24. support -jkb- (talk) 09:19, 6 October 2014 (UTC)
  25. Support Ealdgyth - Talk 12:35, 6 October 2014 (UTC)
  26. Support: Awful tool, unwanted, unwarranted and a technically backwards step that worsens the experience for editors, whether logged in or not. - SchroCat (talk) 12:36, 6 October 2014 (UTC)
  27. Support. I think that MediaViewer is promising—in the long term it can become a useful functionality. However, it's not ready. In particular, it does not reliably render information from the file pages in ways that are easily predictable, and when it fails, it fails in ways that disadvantage the reader—especially the casual reader who may not know about the old-style file description pages, which are problematically obscured in its design (a "More details" button does not suffice). This disadvantage comes about because the underlying functionality—semantic file metadata—isn't properly available yet (as far as I know). Redesigns will not solve that fundamental problem. My distaste for lightboxes means I don't plan to ever enable MediaViewer personally, but I would like to be able to support its use by default. However, I can't support it until those problems are fixed.

    I am separately disappointed with the community for being oppositional to the WMF, and the WMF for the shameful "superprotect" fiasco. The community and WMF need to work together. The WMF needs humility—if the community says no, that should be enough to shelve a feature, despite the time and money and emotions invested in it. On the other side of the coin, the community needs to trust the WMF's good faith, because the situation in which the WMF isn't trusted by the community is nothing short of toxic. Hopefully this RfC will help smooth both over. {{Nihiltres|talk|edits}} 13:38, 6 October 2014 (UTC)

  28. Support The ignorance from the WMF regarding the valid RfCs from enwiki and dewiki and corresponding bug reports is rather telling and I doubt that they will respect them now. However, substandard software with which the Foundation knowingly supports license violations is not something that should be ignored, no matter how bad the relationship with the editorial communities. Please fix this now, review your senior staff's behaviour and competence (or rather lack thereof) and get back to all negotiating tables with the communities. That is of course, only if the Foundation's goals are still aligned with the core principles (recent comments from board members suggest they are not). --Millbart (talk) 14:19, 6 October 2014 (UTC)
  29. Support: At present it is hideous to look at, worse to work with; it may improve over time. Even if we accept good intentions, it was insensitive and arrogant on the part of WMF to impose this on editors without prior discussion, trial or feedback. In a recent phone interview with the WMF politburo I formed an impression that addressing editor concerns was high on their agenda; I hope I was not misled. Brianboulton (talk) 15:04, 6 October 2014 (UTC)
  30. Support – It is an utter disaster, at present. It is awful, and is completely outside the spirit of Wikipedia. It is our job to be no frills, bare-bones, like a encyclopaedic Gandhi, dressed in simple white cotton garb. This is emblematic of our goals, our mission, and all of our principles. To implement such technology as this is, useless and badly designed as it is, is to forsake what Wikipedia does right. RGloucester 16:16, 6 October 2014 (UTC)
  31. Support although WMF doesn't recognize community consensus. Chris Troutman (talk) 17:17, 6 October 2014 (UTC)
  32. Support, per AFBorchert, Kww, Nihilres, & others.

    In an ideal world, what would happen is that Media Viewer would be made opt-in for all users, the staff at WMF would prioritize the defects described & fix them, & once it was shown it was solid & useful, the community would then agree to set it back to opt-out for all users. But based on experience, what will happen is that the WMF will dismissive to the community's objections as if we were all children, do their utmost to force an alpha-stage software upon us, then six months later wonder at reports about increased numbers of veteran Wikipedians leaving. As Nyttend points out, this second RfC should be unnecessary, but certain people at the Foundation insist on ignoring what the volunteers on the ground have been telling them. -- llywrch (talk) 06:00, 7 October 2014 (UTC)

  33. Support. It doesn't work. What I am usually looking for is the file name, and it doesn't show you that. Worse, they don't tell you how to disable it. Even if you do figure out how to disable it, it is not disabled across all wikipedias, only the English one, so you if you are browsing images in a language you don't speak, and where the media viewer is enabled, you will not be able to find the file name or disable the media viewer in that language. —Neotarf (talk) 23:20, 7 October 2014 (UTC)
  34. Support, But let's face it! -- there have been several RfC's, Notice board issues and Media Viewer's own feedback page showed a clear disapproval. Further, their own statistics revealed that MV was not wanted nor needed, on English and German Wikipedia (it's redundant, a glorified 5th wheel and something of a flat tire, given all the bugs -- and here we are months later and they're still tinkering around with this thing). They continue to misrepresent approval. Here is what their own findings say:
    approval breakdown by language: French 71%, Spanish 78%, Dutch 60%, Portuguese 81%, Hungarian 63%, English 29%, German 26%.
    (The numbers fluctuate, but overwhelming disapproval on English and German (most of) WP remains constant.) They admit that approval is very low for English Wikipedia. What they don't want you to know however is that the number of articles, editors and readers for English (and German) Wikipedia dwarf all other such numbers in the other Wikipedias. Look at the numbers at the bottom of the Wikipedia main page. ( ! duh ? ) Since English and German Wikipedia are the largest by far, then it goes that there is overwhelming disapproval overall. All this redundant/buggy viewer is really doing is wasting server resources while amusing certain individuals on the software development team. Their "approval", such that it is, is largely based on the feedback of naive, uninformed and occasional visitors to WP. i.e.How does anyone who is familiar with all the faults and bugs in MV lend their approval?? Easy math. I know I speak for (very) many editors when I say I have lost almost all faith for certain individuals in the WMF. Apparently they see consensus as an invasion of their turf and a challenge to their authority. Get a load of the TOC on one of the archived M.V. talk pages. Good luck guys. -- Gwillhickers (talk) 22:18, 9 October 2014 (UTC)
  35. Support. I dislike it, but could live with it. However, when last I used it it was a non-starter because every image viewed through it violates our duty to provide proper, accessible copyright information, in a manner that is well suited to inform third-party re-users of their attribution obligations. Everything else is secondary.--Fuhghettaboutit (talk) 00:14, 10 October 2014 (UTC)
  36. Support. I don't object to MediaViewer in principle, but as currently implemented it has so many issues - unlabelled buttons, no copyright info, inability to view full-size - that it's unfit for purpose. Mogism (talk) 00:20, 10 October 2014 (UTC)
  37. Support, this new thing is quite clunky and unwieldy and slows down efforts to contribute and edit. — Cirt (talk) 12:50, 10 October 2014 (UTC)
  38. Support - I have disabled MV on and, so I can see images as it used to be before MV was launched. Whatever the improvements are which supposedly have been made, anytime I read Wikipedia while not logged in, and want to see an image I get reminded by MV that it still doesn't function properly. Kraxler (talk) 18:51, 10 October 2014 (UTC)
  39. Support, again, no evidence has been presented that Media Viewer is an improvement from the file page. Either way, the reader sees a larger version of the file after a single click on the file. The Media Viewer eliminates important information about the files and about the context of the surrounding text. On the other hand, the file page gives all of this info. One thing I would support is making files automatically open in a new tab, since 9 out of 10 times a reader will want to go back to the article after viewing the file. StringTheory11 (t • c) 19:07, 11 October 2014 (UTC)
  40. Support. Especially the brutal force to implement such a buggy, unwanted bling-thing was absolutely disgusting. --♫ Sänger - Talk - superputsch must go 10:32, 12 October 2014 (UTC)
  41. HELL YES Never have so many been so upset at so few, but in this process - which I'm sure will ultimately be devoutly ignored - we have a chance to right a wrong, and maybe, just maybe, get back to the way things were: happy editors, happy readers, and happy fact checkers for articles and images. TomStar81 (Talk) 11:37, 12 October 2014 (UTC)
  42. SupportWasell(T) 19:40, 12 October 2014 (UTC)
  43. Suppport (everything has been said already above and elsewhere). Ca$e (talk) 19:56, 12 October 2014 (UTC)
  44. I'm more of a reader than an editor these days, and I turned the thing off as soon as I figured out how to do so. The file pages are informative, and educate readers about how images are contributed to an open-source educational project. It wasn't broken, it shouldn't be fixed. It shouldn't take umpteen RfCs to get Mr. Möller's department to roll this back. --SB_Johnny | talk✌ 23:51, 12 October 2014 (UTC)
  45. Support. This entire affair has been unhappy for many people, and has certainly left me severely disillusioned. I have cut my contributions to Wikipedia as a result of the events surrounding the Media Viewer, and am unlikely to return to my earlier contribution level unless their is clear evidence that the WMF are paying more attention to editors' concerns. RomanSpa (talk) 05:38, 13 October 2014 (UTC)
  46. Support keeping Media Viewer disabled by default for both registered and unregistered editors. Anyone who wants it can turn it on. As several previous editors have said, it isn't an improvement on the existing situation. Robert McClenon (talk) 18:58, 13 October 2014 (UTC)
  47. I support the RFC as a sub optimal response. But I'd prefer not to have media viewer available as an option on sites that allow Fair use images. Either that or stop hosting Fair Use images. The idea behind Media Viewer seems to be dropping the boring stuff about copyright as a large proportion of humanity doesn't take that seriously. That's annoying to those of us who contribute photographs and especially those who take copyright seriously and think that this site should continue to do so. But it isn't likely to get people in trouble, except where Fair Use images are concerned. We regularly bite newbies for misuse of Fair use images, others are entitled to bite them for it in real life. If we are going to continue to allow Fair Use images the least we can do is leave the warnings about them in place, rather than on a separate link. You could of course amend Media Viewer so that it gave appropriate licensing info when displaying a Fair Use image, but then why have Media Viewer at all? ϢereSpielChequers 13:43, 14 October 2014 (UTC)
  48. Support Progress has been made with the Media Viewer, however I still prefer the non-Media Viewer page. Also, it's difficult using the back button because I can't tell when I'm "on the same page" versus when I'm "on a new page". Overall, at this time I don't believe it's ready. Crazycasta (talk) 01:08, 15 October 2014 (UTC)
  49. The Community Consultation Process on Media Viewer was a sham. I get the feeling we are bashing our heads against a brick wall here though. MER-C 01:54, 15 October 2014 (UTC)
  50. Support - Media Viewer has only gotten worse since it was first released. What used to be a minor inconvenience has become a moderate inconvenience to the editing process. Carrite (talk) 13:54, 15 October 2014 (UTC)
  51. Support. Everyking (talk) 03:42, 19 October 2014 (UTC)
  52. Support. People who like it can opt in. They should not be forced into using it by default. A later RFC could establish that there's consensus to enable it by default, but we are clearly not there yet. NinjaRobotPirate (talk) 00:19, 20 October 2014 (UTC)
  53. Support. Ahsoous (talk) 11:30, 20 October 2014 (UTC)
  54. Support. The media viewer is broken by design. It removes the context and presents the images of an article like a slide show. Did any user ever ask for such a feature?-----<)kmk(>--- (talk) 03:20, 26 October 2014 (UTC)
  55. Support Coming out of retirement just to say how much I hate the new Media Viewer software. It merely slows down my ability to get to the actual image. It was terrible when Wikia implemented it and it is just as bad here on Wikipedia. Please, get rid of it, as a reader I really don't like it. Best, Alpha_Quadrant (talk) 20:31, 27 October 2014 (UTC)
  56. Support and let me say, I wish the Foundation would work on solution that made it easy for users to simply switch from to the other on the fly (ie: a cookie for unregistered viewers), then they can decide for themselves. Until then, utility trumps "cool feature", and the old way is more intuitive and simple to use, as it is more like the pages of an article. From the reader's perspective, this is the best starting point. Dennis - 20:29, 30 October 2014 (UTC)

Oppose (Media Viewer RfC Question 1)[edit]

  1. Not really clear why this RFC is required at the current time. Development work is still ongoing to make Media Viewer more acceptable to communities and respond to feedback. A better time for an RFC would be when a planned deployment is put on the table, and the version of Media Viewer that is proposed for deployment is available for evaluation. At the moment, there isn't really anything more to discuss beyond what was already said last time.
    On another note, I'm not sure that RFCs of this kind are helpful. They feel somewhat antagonistic to me, and seem to bring out a vocal minority of technical Luddites within this community who don't always understand the subtleties of the issue at hand. — This, that and the other (talk) 11:35, 5 October 2014 (UTC)
  2. Not within the framework of WP:CONEXCEPT, section 1 and/or 4. I will add that any legal objection regarding attribution is incompetent, as coming from persons without verifiable credentials or responsibility. It is also absurd to make such claims, when practically every page on Wikipedia (eg. Main Page) has no visible origin information for images. Alanscottwalker (talk) 16:26, 5 October 2014 (UTC) I also agree that this is just a VOTE, the only practical rationale offered by the RFC is, 'if you do not like it, vote support for confronting the WMF.' Alanscottwalker (talk) 16:16, 6 October 2014 (UTC)
  3. This is the wrong time. According to the outcome of the consultation process, as referenced above, We plan to complete all “must have” improvements by the end of October and deploy them incrementally, starting this week (that was on 11 September 2014). The end of October will be the time to start a thorough discussion, which may go better if editors aren't weary from a long RFC now. NebY (talk) 17:53, 5 October 2014 (UTC)
  4. What TTO said. Also this really isn't an RfC, it's just a WP:VOTE. Legoktm (talk) 18:31, 5 October 2014 (UTC)
  5. Per NebY. If they're currently working the feedback they have from us into the software and will have that done soon, a random RfC now on the basis of old discussion and an old software version is pointless. Discussion about the tool's future status should happen when there's actually something new to discuss. A fluffernutter is a sandwich! (talk) 18:44, 5 October 2014 (UTC)
  6. It's long past time to deploy this improved file-page interface, especially for non-logged-in readers who likely don't care about the cruft that we editors do. Powers T 19:21, 5 October 2014 (UTC)
  7. It looks like improvements are still being made and many of the problems of the initial version have already been fixed. Kaldari (talk) 19:54, 5 October 2014 (UTC)
  8. Per NebY. Wait until they get it fixed, and then if we still don't like it, turn it off. Jackmcbarn (talk) 20:20, 5 October 2014 (UTC)
  9. The WMF have made an attempt to address some of the concerns of the community, we should at least wait until they are addressed before holding an RfC. I also agree with Legoktm that this is not an RfC, it's a vote. --Tom (LT) (talk) 22:57, 5 October 2014 (UTC)
  10. The concerns expressed in the original RFC are already pretty much resolved. An actual RFC on this topic would review the work that has been done, and discuss it, not just have a vote for the sake of voting. And editors who don't like it can change their preferences. Risker (talk) 01:49, 6 October 2014 (UTC)
  11. Keep media viewer The media viewer is a significant benefit to our readers. Yes, it does get in the way of editors, but editors have the ability to turn it off, and they do just that. Our defaults must be oriented for readers, who don't have such options. Oiyarbepsy (talk) 02:16, 6 October 2014 (UTC)
  12. Oppose I agree with most of the comments above. PaleAqua (talk) 15:07, 6 October 2014 (UTC)
  13. Per Risker, and the fact that this isn't an RfC. Ed [talk] [majestic titan] 19:56, 6 October 2014 (UTC)
  14. The media viewer is a useful tool for readers, and readers don't have the ability to adjust their preferences. --Carnildo (talk) 02:15, 7 October 2014 (UTC)
  15. Good enough. Not perfect, but helpful to readers and usable for editors. And I see the WMF is doing active development in a useful and rapid manner. DGG ( talk ) 07:16, 7 October 2014 (UTC)
  16. For an image editor or reviewer the additional clicking and disorganized image information makes efficient and quick work simply impossible. No feature should cater only to one portion of the community, be it readers or editors. All features need to be usable efficiently by all parts of the community and readership. However this RfC is too early, it's better to wait for the results of the current improvement drive. GermanJoe (talk) 08:17, 7 October 2014 (UTC)
  17. Keep Mediaviewer. Improvements are ongoing, think of MV as an extended thumbnail view. Viewers will be able to go to the file description page easily. Even if the attribution does not work perfectly, I do not consider this a "showstopper". The complex cases, where MV fails are almost impossible to grok for human as well, so not much is lost here. We should rather focus on making the meta data more accessible for humans and software alike. --Dschwen 16:18, 7 October 2014 (UTC)
  18. Per Risker this can be changed in preferences.This appears to more of an vote rather than an RFC.Pharaoh of the Wizards (talk) 02:47, 8 October 2014 (UTC)
  19. Keep Mediaviewer per all the comments above. MV isn't perfect but it is an improvement, especially for readers, and the WMF is still working on MV to address the concerns of the community. If people don't like it, they can opt out individually. It is clear to me that the issue isn't MV itself but the relationship between some of the community and the WMF. Unfortunately, this RFC does not appear to be an attempt to improve that relationship or to collaborate with the WMF, instead coming across as antagonistic and unhelpful. Ca2james (talk) 16:05, 10 October 2014 (UTC)
  20. Oppose. Since something has to be default, I don't see it shouldn't be the media viewer. It is quite possibly true that it's not the best way to view image details for editors or heavy readers, but that has little to do with anything -- those people can just disable the default (I myself have it disabled, partly because I just don't like change). For casual readers -- which is what we're mainly talking about here, I think -- my uneducated guess is that when they click on an image they probably mainly want to see a larger version or at any rate a full-screen view. And I'm not convinced that the Media Viewer isn't, or can't be made to be, just as good if not better for that than the old way. I'd like to see an actual study of casual readers and new readers and see what they like, and it shouldn't be too hard to run one. Absent that, I'm opposed to the question. Herostratus (talk) 17:43, 12 October 2014 (UTC)
  21. Keep Mediaviewer I still don't understand the big fuss about all this. Seems to me, most readers would want to see an expanded view of the media when they click on a thumbnail – it's standard practice all around the internet. For the people who don't like it, namely editors, it's very easy to figure out how to disable it (the "disable media viewer" link at the bottom of the media viewer). I'm a fan myself, and had it enabled before it went live to all users. Like the reader, I more often than not just want to see media, not work with it. I can't say I've ran into any bugs either. — MusikAnimal talk 18:31, 12 October 2014 (UTC)
  22. Oppose Even in its current imperfect state the MV already seems an improvement for the readers, whose interests should be central to our efforts. Additionally, editors who don't like the MV can simply opt-out, so where is the problem? Given that the improvement process of the MV will last through the end of October the timing of this vote is ill-considered and not constructive. --Wolbo (talk) 21:29, 12 October 2014 (UTC)
  23. Oppose June was 4 months ago and that's quite a lot of development time. No doubt MV has changed quite a bit since then and in any case consensus can change. Therefore the results of that 4-month-old RfC should not stand. WaggersTALK 09:49, 13 October 2014 (UTC)
  24. Oppose Per WP:CONEXCEPT, software development is beyond the purview of the community. Confronting WMF is unproductive, unhelpful and unnecessary. Hawkeye7 (talk) 19:51, 13 October 2014 (UTC)
  25. Oppose. The Media Viewer is intended for improving the experience of the millions of silent readers out there, and a consensus of a very small self-selected set of editors here can not possibly be representative of those people. For situations like this, I think Wikipedia's consensus model is not appropriate and such decisions should not be made this way. For better or for worse, the decision should be left to the Wikimedia Foundation. Neatsfoot (talk) 07:57, 14 October 2014 (UTC)
  26. Oppose Yes, it was a pain to have to find and click on that button to get to the original screen. But the arguments that it benefits new and non-editing users, and that it's still being tweaked, are enough for me to put aside my own selfish considerations. Drop the stick. Carolmooredc (Talkie-Talkie) 13:15, 14 October 2014 (UTC)
  27. Oppose The Media Viewer appears to be good enough for default use and can be disabled by users who do not want it. Making it opt-out rather than opt-in gives it the exposure necessary for testing and improving it. Kind regards, Matt Heard (talk) 01:15, 16 October 2014 (UTC)
  28. Oppose per Risker and the RfC format concerns. Mike VTalk 18:19, 19 October 2014 (UTC)
  29. Oppose. Media Viewer certainly has rough edges (which the WMF is addressing), but on the balance I think it's already a real step forward, particularly for readers who just want an easier way to see large versions of images—and personally, I'm a big fan. For those who find it bothersome, opting out is pretty easy.—Neil P. Quinn (talk) 16:56, 20 October 2014 (UTC)
  30. Oppose - time to just let this controversy die, and let anybody who doesn't like the media viewer just disable it for themselves only Smallbones(smalltalk) 15:03, 25 October 2014 (UTC)
  31. Oppose - The viewer should be improved quickly, but it works well enough to be enabled by default. --NaBUru38 (talk) 21:57, 25 October 2014 (UTC)

Neutral (Media Viewer RfC Question 1)[edit]

  1. I dislike Media Viewer and disabled it wherever it irritated me, but I see the point of those who say "Let's see the new improvements first." LynwoodF (talk) 18:42, 5 October 2014 (UTC)
  2. Abstain Please review the WMF's mission statement. The question of whether MV "empowers" people or not is a matter of opinion. The role of the WMF with respect to RfC's is not. Lila, the Board, and anyone under employment with the WMF has no obligation whatsoever to make decisions based on a community RfC alone. In this case, Lila is following what is widely considered a best practice for online services: if there is a workaround to new issues (clearly there is here in disabling the feature), then avoid creating new problems with a roll back. The path Lila has chosen is to work with the community in improving MV, instead.
    Some may dismiss this as the WMF prerogative with a rock-solid argument behind them using the founding documents of the WMF. I won't. I recommend taking Lila and her team directly to task by demanding answers in to what went wrong here. Let's demand something we might actually get: a post mortem on the initial MV rollout. What changes have been made to prevent this happening in the future? I can get things started by mentioning that we have a new VP of Engineering at the WMF, for example. What forward-looking promises can we get from the WMF and Lila that we can actually hold them to? And, more importantly, how can we help them back up these promises up for the good of the entire community and our users? There's been so much talk around MV; it's time for everyone to start walking the walk. I'm going to start by getting back to editing WP with time I'd otherwise waste on these pointless petitions. -wʃʃʍ- 20:48, 7 October 2014 (UTC)
  3. I am pretty much neutral on Media Viewer itself, but one of the many who are put off by the condescending comments of people such as User:Fabrice Florin (WMF), and more generally the WMF as a whole. The WMF should listen to the community, rather than consistently dismissing it by referring for instance to "self-selected RFC discussions." Like it or not, RFCs have long been among the principal ways in which the Wikipedia community seeks consensus on important issues. And if you don't like it, it's not the community that should fork (per User:Wllm), it's the WMF employees who have lost the plot. --jbmurray (talkcontribs) 16:34, 8 October 2014 (UTC)
I'm confused. Are you suggesting that the WMF fork instead of the community? I'm not sure that's even possible, but it would follow the pattern of people at the WMF actually doing stuff while some disgruntled members of the community waste everyone's time on toothless petitioning that puts nobody's skin in the game.
As I've said many times before, people should start walking their talk. If that means part of the community leaves to work on their own fork, I believe that would be for the best for their personal well-being and the Wikimedia projects as a whole. Why waste your time complaining about the WMF in these ridiculous petitions? Put your time and effort in to a new encyclopedia if you think you can do it better. I'm gonna stick around to see where the WMF is taking this story. -wʃʃʍ- 00:38, 9 October 2014 (UTC)

Reserved for official comments by WMF employees (Media Viewer RfC Question 1)[edit]

(Please do not edit here if you are not WMF)

Hello @Alsee: Thanks for following up about Media Viewer. As stated last month, we are now making a range of improvements to Media Viewer, based on the results of the recent community consultation and our usability research.

For example, we just released these new features, which were announced last week:

Early indicators suggest these improvements are working:

  • Enlarge feature: You can now click on an image to enlarge it in Media Viewer, to support a frequently requested zoom function. We now log about 1 million clicks/day for that feature across all sites -- a dramatic 20x increase from ~50K clicks/day for the previous ‘View original file’ button (see metrics dashboard).
  • File: page button: You can now click on a more prominent ‘More details’ button to go to the File: page, a frequent community request. Since this feature was launched last week, global usage has tripled, surging up to ~60K clicks/day (from ~20K clicks/day on two separate links)
  • Download button: You can now click on a separate download button that's easier to find. Since launch, global usage has tripled to ~66K clicks/day on the new icon (from ~20K/day for 'Use this file' downloads)
  • Disable rates: Since these improvements were launched, global opt-outs by anonymous users have decreased by 60%, down to ~800 disable actions per day (from ~2K/day before new features).

This is consistent with our expectations, based on the latest round of usability research for the recent prototype.

Next, we plan to work on these other improvements:

This incremental improvement process will last through the end of October, using this standard development cycle: 1) design features based on data and user feedback; 2) prototype them; 3) validate them through usability studies; 4) build the features; and 5) measure their impact.

Once we have collected and analyzed those metrics in November, we can discuss next steps based on that information. As a rule of thumb, self-selected RfC discussions are not an effective way to determine default configurations about software -- and without usage data for the latest versions of the features, they are largely based on speculations, rather than factual observations.

Finally, we are also preparing a metadata cleanup drive to address remaining issues with missing machine-readable data that result in Media Viewer (and other tools) displaying incomplete information. This is the first time the Wikimedia Foundation has taken on this type of project -- and we invite community members to contribute to this cleanup work.

You can track our progress on the Media Viewer Improvements page, where we will post regular updates in coming weeks. Sincerely, Fabrice Florin (WMF) (talk) 12:33, 7 October 2014 (UTC)

Discuss and comment (Media Viewer RfC Question 1)[edit]

Yes check.svg Done: Sending notifications to everyone who participated in previous discussions on the same topic. Alsee (talk) 15:49, 5 October 2014 (UTC)

  • I see some comments about this RfC being too early, that the items in the Media_Viewer_consultation outcome have not yet been implemented. I based my personal position on the assumption that everything in that list does get implemented. I guess I assumed other people would interpret it the same way, but I'm not going to re-write the question. The RfC clearly asks people to review that consultation outcome, and people can intelligently respond based upon that consultation outcome. It was determined four three months ago that "There is a clear consensus that the Media Viewer should be disabled by default". I see no point is stalling this another 4 months 3 months... or stalling this another 999 months in "eternal development" if there exists a consensus against Media Viewer regardless of the proposed development. We do not allow someone to shove bad content into an article and then engage in tendentious discussion about "improving" that content when there is a clear consensus that no amount of "improvement" is going to permit it stay in. Alsee (talk) 22:11, 5 October 2014 (UTC)
I don't know where you get 4 months, Alsee, it was closed on July 9, which is less than three months ago. Risker (talk) 02:01, 6 October 2014 (UTC)
My apologies, I accidentally my used the July-RfC-start instead of the June-RfC-end in my quickie mental count. I corrected my comment above. Alsee (talk) 08:52, 6 October 2014 (UTC)
I think this makes it clear there is no claim of WP:CONEXCEPT here. The WMF withdrew it's hasty and unconsidered application of Superprotect, and explicitly asked that we not disable Media Viewer. Alsee (talk) 21:10, 5 October 2014 (UTC)
Clear Conexcept issue: 'WMF: don't do it'. They do not need to apply superprotect that they still have, as long as it's not done. Like the community, which does not apply protection, when it does not need to, either. That is why it's never been applied on EnWP. Alanscottwalker (talk) 22:48, 5 October 2014 (UTC)
Can we agree that we disagree, and agree not to battle on a hypothetical? The issue is moot if this RfC doesn't pass, and the issue is moot if the WMF doesn't assert Conexcept as ground to reject it. The WMF decided that Superprotect as a Bad Idea, and perhaps they will decide that trying to claim Conexcept here is also a Bad Idea. Alsee (talk) 09:05, 6 October 2014 (UTC)
No. The WMF has already said where they stand. [6] ("MV" stands for Media Viewer) [7][8]. So, the only Bad Idea is this RfC, which is actually a WP:VOTE, and which is contrary to Policy. Alanscottwalker (talk) 23:17, 6 October 2014 (UTC)
  • No idea who added the Files from the Media Viewer Survey (I can find it in the history, but can't be bothered to check), but files from a survey with so many errors shouldn't be used to influence an RfC. Just look at the survey. The second graph has 100% of editors who never edited Wikipedia, and then additional percentages of people who did, going way over the number of respondents and over 100% obviously. The summary at the top ("Media Viewer Survey results from English readers in the last 2 weeks of the survey show significant increases in the percentage of users who find Media Viewer useful, compared to the first results right after launch. From June 24 to July 8, more English readers found Media Viewer useful (62%) than not (25%), based on 496 responses for that period.") also contradicts the box at the top right, "496 responses - 201 days (March 20, 2014 - now)". And of course, the survey says nothing about Mediaviewer as compared to standard File views, so even if a majority things it is useful, we don't know whether they actually find it any better. Please don't add such files without the necessary caveats, and please indicate who added them. Fram (talk) 08:20, 6 October 2014 (UTC)
The images can be viewed here. Images do not belong in the SUPPORT/OPPOSE section. The figures in the image are based on the last two weeks of limited survey data, and I distinctly recall seeing the WMF explaining that data was exceptionally unreliable due to dismal response rates. I will say [citationneeded] in the hopes that someone can provide the cite.
The complete survey data can be viewed in this spreadsheet. The WMF summary of that data is "A majority of global respondents find the tool useful for viewing images (56% response average, 60% average across surveys), as shown on this spreadsheet. Cumulative approval by language: English 36%, French 70%, Spanish 78%, Dutch 59%, Portuguese 81%, German 30%, Hungarian 63%, Catalan 71%"". I added bolding on the English results. Furthermore their claim of "A majority of global respondents find the tool useful" is (probably unintentionally) extremely misleading. If you survey 900 bald people and 100 not-bald people you do technically obtain "90% of respondents say combs are not useful". That is also a flagrantly warped result. I recalculated the survey results to, as best as possible, accurately represent the results for global Wikipedia visitors. When weighted to match global Wikipedia readership for each language I get 39% found Media Viewer "useful", 50% found it wasn't, and 10% were not sure. Anyone who wants to check my results can see the analysis I posted at mw:Talk:Multimedia/Media_Viewer/Survey#Survey_Renormalization_To_Match_Our_Readership 6 weeks ago. And of course the survey question itself is garbage. For example mw:Talk:Multimedia/Media_Viewer/Survey#Bias: "I actually hate the interface, but I answered yes. Because it is "useful." Had I known they were using this as an approval survey I would have said no." I saw a similar comment in one of the survey text-field responses, and I have no doubt that many of the other negative text-responses would paired with "useful" votes if we could view the text-responses matched up with "useful/not useful" responses.
The WMF also has this lovely Media Viewer - English Opt-in and Opt-out Events Graph - June 27 - July 20 2014.png. The rate of opt-outs is nearly five times as high as the number of opt-ins. And I have to wonder if those opt-in results are badly inflated. When I was testing Media Viewer I toggled it off, on, off, on, off, on, off. Realistically that should be one opt-out, but it sounds like that sort of thing triggered three bogus opt-in events. Alsee (talk) 12:20, 6 October 2014 (UTC)

If I may ask: Why do people who personally would prefer to use the traditional file description pages oppose making this new media viewer an opt-out feature? Surely setting a preference once and never needing to worry about it again is a small price to pay? Powers T 14:17, 6 October 2014 (UTC)

My reasons: 1) Because all the data we have shows that the feature isn't liked by a majority of all English-speaking groups. 2) The opt-out, at least for anons, is broken. 3) Even if the opt-out for anons worked, I'd have to set it on every computer I used. 4) Even if the opt-out worked, people now link to the media viewer when linking to images, so I can't avoid the damned thing, even if the opt-out worked. 5) There is a clear consensus that it should be disabled by default. -- (talk) 14:45, 6 October 2014 (UTC)
In my case: all of that plus the fact it is inferior—making something inferior the default serves only those who developed it—it gives me an actual headache when it does its jiggling, flickering load; and I have been having to disable it on multiple-language Wikipedias, finding my way to and through the preferences in Kannada, Finnish, Latin ... it's a hassle and a half. Yngvadottir (talk) 15:38, 6 October 2014 (UTC)
It is also almost always unnecessary (it was clearly designed with galleries in mind, and most images in an article are not galleries), and actively defeats user expectations about what will happen when they click an image as well as messing with the web history. It muddles both navigation and attribution, reducing the quality of the site overall. After a few revisions, it's a lot better than it was, but the fact of the matter is that it's the wrong tool for the job. It would work much better if under image thumbnails there were a little icon you could click for something like, "Preview image", while clicking the image still brings you to the image file page. This wouldn't re-define existing behaviors, but it would allow MediaViewer as an option without enabling it in preferences. Of course, we have no leverage for a compromise, because WMF has shown that they don't give a fuck about what we think. It's really making me re-assess my monthly donation. 0x0077BE [talk/contrib] 16:25, 6 October 2014 (UTC)
Well, among other reasons, why should majority "pay the small price" instead of minority..? Also, if you really think this is no big deal, why are you still arguing instead of giving up and letting the ones who think it is somewhat bigger deal win..? I'm afraid I don't see much merit in reasoning behind your rhetorical question... --Martynas Patasius (talk) 19:31, 6 October 2014 (UTC)
  • Should we have a third RfC that; there would be an RfC after WMF completes the implementation of the outcome of community consultation? --Fauzan✆ talk✉ mail 17:25, 6 October 2014 (UTC)
  • @Fabrice Florin (WMF): Thanks for commenting. What I see missing from your thoughts is what, exactly, "Once we have collected and analyzed those metrics in November, we can discuss next steps based on that information" means. That is, let's say it's November. You've made your changes and collected your metrics. You have new numbers in hand. Now...what do you plan to do? Will you present them to the community and say "now, based on these, decide whether you want the software"? Will you have a point in mind where, if the metrics don't rise to X% of Y group, the software will be withdrawn and reworked again? What people here want to see in the discussion, I think, is a concrete course of action from the WMF. "We're reworking and re-evaluating" is great to hear, but it means little if it can't or won't be followed up with "...with X goal in mind, and if X doesn't happen, then we do Z".

    Similarly, you say that self-selected RfCs are "not an effective way to determine default configurations about software". I pretty much agree with you on that...but but but. If this type of RfC isn't going to work for you, in what manner do you want the community to comment on and support or oppose software changes in regards to this project, in particular? Petitions? Letter-writing campaigns? Skywriting "Enwp wants the WMF to change Product Q" over San Francisco? People are fighting to find, in these software deployment cases, what will get the WMF to listen to the community's will (or to their own personal opinions), and so far the WMF's response to that has been mostly of the type "Oh, you want to know how to get software recalled or paused? Well, let me tell you about the next deployment date and changelog instead!" Interesting stuff to hear, but not actually an answer to the question the community is asking, you know? I think you'd get fewer people willing to die on this hill if you gave them a sense of what they can do to change things other than dying on this hill. A fluffernutter is a sandwich! (talk) 13:49, 7 October 2014 (UTC)

@Fluffernutter:: Good to meet again, and thanks for your interest in this project.
In response to your question, our goals for Media Viewer in the next few weeks are to:
1) complete the 'must-have' tasks we identified from our community consultation;
2) verify through user research and metrics that they are working as intended (using the same methodologies as reported in previous Media Viewer updates, such as the above response);
3) fix any critical bugs for Media Viewer and these features;
4) review these results with the community;
5) wrap up development on this project.
So far, about half of the 'must-have' tasks have been released, as listed in my previous response. Here are the ones that are still in development, which we plan to release in coming weeks:
  • Easy Disable/Enable Settings from Media Viewer (#836)
  • Re-enable Media Viewer from a File Page (#719)
  • Show caption above the fold in Media Viewer (#589)
  • Pre-render thumbnails in all sizes on the back-end (#301)
  • Move license label after source (#833)
  • Make MediaViewer text larger in Monobook (#876)
You can track our progress for these tasks on our current sprint wall.
As for your other question (how the community can comment on software changes), that was the primary purpose of our widely-promoted Media Viewer consultation. We asked for community feedback, we received a lot of great suggestions, we prioritized them and developed the 'must-haves'. This consultation process seems effective for limited releases like this one. (Note that we are also exploring other ideas for community participation, as described in my response to Alsee below.)
However, please keep in mind that our multimedia team is urgently needed on other high-priority projects like Upload Wizard and Structured Data. Once the most critical tasks listed here are done, we will switch our attention to these critical projects, which have been explicitly requested by the community. But we will continue to share our Media Viewer findings with the community in coming weeks, and look forward to reviewing them together in mid-November. Thank you. Fabrice Florin (WMF) (talk) 23:22, 9 October 2014 (UTC)

  • Thanks Fabrice Florin (WMF) for your friendly and helpful post in the WMF section. I fully trust the WMF to implement 100% of the improvements that the WMF says it plans to make, and my intent with this RfC was for people to take into account all of those promised improvements. I encourage people to fully consider your post before responding to this RfC.
Nonetheless, I am very troubled that the Community Consultation process was deaf by design to any community input that did match what the WMF wanted to hear. The WMF director, Lila, promised a Community Consultation process "with no predetermined outcome". The consultation outcome looks pretty predetermined to me. If this RfC passes I think it means the consultation was a failed, broken process. The nontraditional bottom-up wiki governance and the traditional top-down WMF governance models are clashing. I sincerely hope that all of us can find a better way to bridge that gap. Alsee (talk) 18:38, 7 October 2014 (UTC)

@Alsee: You make a reasonable point that there is some tension between the community’s bottom-up governance model and the more structured decision-making process of a software development organization like ours. But as you can tell from the comments above, it is not possible to design software that will satisfy every point of view. As much as possible, we strive to make our designs consistent with evolving user interface standards, easy to understand, and responsive to the needs of our broad user base.
We have already invited community feedback, extending our development time by an entire quarter to address the most important requests. The consultation outcome was not at all pre-determined and we carefully evaluated every community suggestion before making a final selection. We focused on specific calls for improvement where we could make a difference, based on some great suggestions from our community. And we were very clear from the outset that requests to turn off the software were outside the scope of this consultation.
Going forward, we are building a more robust, quantified process for measuring the success of our projects and for gathering feedback early in the planning cycle, based on some of the ideas discussed in this separate consultation about process. We look forward to evaluating all these suggestions with our product group in coming weeks, and you should be hearing from us soon. Fabrice Florin (WMF) (talk) 23:22, 9 October 2014 (UTC)
"The consultation outcome was not at all pre-determined [...] And we were very clear from the outset that requests to turn off the software were outside the scope of this consultation." These two statements are inconsistent. In light of the latter statement, the former is mendacious. It's clear from your statement that it was a predetermined outcome that Media Viewer would remain enabled no matter what happened with the "consultation." The WMF has never given a compelling reason for insisting on imposing this predetermined outcome despite a clear consensus to the contrary. A consultation isn't a consultation if you're going to declare anything you don't want to hear as out of scope. A question that has been asked many times before but never answered: "What would it take for the WMF to disable the Media Viewer in conformance to the clear consensus on the English Wikipedia, the German Wikipedia, and the Commons?"-- (talk) 23:36, 9 October 2014 (UTC)
@Fabrice Florin (WMF): The IP address beat me to it, but I still need to say it. "The consultation outcome was not at all pre-determined" combined with "clear from the outset that requests to turn off the software were outside the scope of this consultation" is insulting. It's offensive. Statements like that just inflame the situation. Alsee (talk) 07:42, 10 October 2014 (UTC)

To people saying that since people can opt out, this isn't an issue: wrong. People on other sites are now linking to media viewer pages, not the file page. Even if you never want to see media viewer, it's thrown in your face if you browse the web with any regularity. Also, if you don't have an account, the opt-out periodically breaks. You also have to opt out on each computer that you use. There is also the issue that a lot of people don't know how to get to the file page. Some people don't even know what they're missing, with the version history and the full description. And finally, stop talking about the readers. Not a single reader has chimed in to support media viewer. -- (talk) 03:00, 8 October 2014 (UTC)

@Fabrice Florin (WMF):"The consultation outcome was not at all pre-determined [...] And we were very clear from the outset that requests to turn off the software were outside the scope of this consultation" is just a short way of saying "we will only listen to people that agree with our predetermined outcome". Do people at the WMF wonder why we consider the statements from WMF staff to be intentionally deceitful, or do you just sit back and laugh after you write nonsense like that?—Kww(talk) 04:54, 12 October 2014 (UTC)

Media Viewer RfC Question 2[edit]

The WMF made this statement when deactivating Superprotect:

Dear German Wikipedia community,

We’ve been talking a lot with many of you and at the WMF about the current situation regarding Media Viewer and site-wide JavaScript changes.

Restricting edits to MediaWiki:Common.js was a difficult decision for us. We regret that we missed opportunities to do our part in avoiding a conflict that no one wanted. At the same time, we cannot fulfill our responsibilities as the site operator when users take it upon themselves to disable functionality by editing site-wide JavaScript that is executed for all users.

We learned that the use of superprotection unintendedly created the impression that we don't trust the community. This is not the case, so we have therefore removed the restriction.

In doing so, we are investing our trust and goodwill in every community member that you will work together with us before making changes to site-wide JavaScript. And we are specifically asking you to not change site-wide JavaScript to deactivate Media Viewer or to make it opt-in.

Our commitment to you is to address open technical issues with Media Viewer based on a global community consultation process beginning tomorrow. The consultation page will address the scope, intent, and timelines of the consultation will be announced on all projects and will be open-ended. We will update here with the details when the page is live and will support German language participation.

We ask you to work with us in good faith in the upcoming month and through this effort define a better, closer way of working together in support of our common goals.

Sincerely, Lila & Erik

Question Two. In light of the statement above, should Question One carry the following implementation terms:

  • Place a 7 day hold against Community action to implement this RfC.
  • Officially deliver the closing results to the WMF.
  • Express our desire to work together with the WMF before making changes to site-wide JavaScript.
  • Express our desire to work with the WMF in good faith, and our hope for a better closer way of working together in support of our common goals.
  • Formally request the WMF to implement this configuration change for English Wikipedia.
  • 7 days after this RfC closes our JavaScript experts and other admins are directed to take any steps necessary to implement this RfC, if such steps are still needed.
NOTE: Question two shall have NO EFFECT if question one fails. You can oppose question one and still support question two, just in case question one passes.

Support (Media Viewer RfC Question 2)[edit]

  1. SUPPORT as RfC author. I want to make every effort of develop a more collaborative relationship between the community and the WMF. Alsee (talk) 18:01, 3 October 2014 (UTC)
  2. Support. First we should try to work with them, FWIW. Then, when that will fail, fiat justitia ruat caelum. BethNaught (talk) 16:36, 5 October 2014 (UTC)
  3. Support. The seven days give WMF sufficient time to implement this. Features that are switched on by default and problematic in regard to copyright law (two clicks to access complete copyright information) lie within the domain of the community. How can we with good conscience use images at en:wp if, by default, this feature hides essential copyright info? This is a problem of the community as many of them work with their real names and have consequently a different perspective than the WMF who sits in the safe harbour. --AFBorchert (talk) 17:58, 5 October 2014 (UTC)
  4. Support. This seems a reasonable proposal. LynwoodF (talk) 18:47, 5 October 2014 (UTC)
  5. Support. I can't see why this would controversial at all. Powers T 19:23, 5 October 2014 (UTC)
  6. Of course. We should try to work with them, but community consensus must be enforced as long as it's technically possible. Nyttend (talk) 19:31, 5 October 2014 (UTC)
  7. Support. I don't know about all the details, but I'm coming from a position that we, editors and WMF, are all in this together. --Tryptofish (talk) 20:17, 5 October 2014 (UTC)
  8. Support per BethNaught. Double sharp (talk) 01:40, 6 October 2014 (UTC)
  9. Support. We should try to work with the WMF since we're all in this together. -- King of ♠ 02:43, 6 October 2014 (UTC)
  10. Strong Support -- CONEXCEPT clearly was never intended to apply to this kind of situation. This does not implicate any basic principle of the movement, nor is there a compelling technical reason to oppose a return to how things were for over a decade. I disagree with the time frame. We've been stuck with this terrible, shoddy, ill-conceived software for what, five months now? It needs to be returned to opt-in immediately. The anonymous opt-out is broken and it keeps on returning. This has gone on far, far, too long. -- (talk) 06:42, 6 October 2014 (UTC)
  11. support -jkb- (talk) 09:21, 6 October 2014 (UTC)
  12. Support. It would be nice to have more options, but no one suggested anything else and this option does seem to achieve some balance between conciliatory and antagonistic approaches... If WMF wants to reconcile with us, they have 7 days to do something, and if they do not, why should we give up just because resisting makes their life harder? If they do not act as friends with us, why should we act as if we were friends with them? Of course, it is to be understood that simply turning off Media Viewer for everyone is perfectly acceptable - if WMF doesn't like it, they are free to offer us an alternative we would prefer. Or, if they really want to use their legal rights (that some opposers discuss), they are free to ban everyone at the price of a public relations disaster (I'm pretty sure the editors will survive, I am not so sure about WMF). Somehow, I doubt they will actually do so, thus legal rights seem to be a red herring here... --Martynas Patasius (talk) 21:45, 10 October 2014 (UTC)
  13. Support. The putsch by WMF against its employers, the communities, that generate all donations with their content creation and maintenance, was extremely hostile and must never happen again. --♫ Sänger - Talk - superputsch must go 10:35, 12 October 2014 (UTC)
  14. Support And also go so far as to request that certain of the provisions such as official presentation of results be made regardless of question 1. — Preceding unsigned comment added by Crazycasta (talkcontribs) 01:14, 15 October 2014 (UTC)
  15. Support per the mission statement of the WMF: "(...) to empower and engage people around the world to collect and develop educational content (...)" — Preceding unsigned comment added by KaiMartin (talkcontribs) 03:34, 26 October 2014 (UTC)

Oppose (Media Viewer RfC Question 2)[edit]

  1. Per my my oppose and policy (WP:CONEXCEPT section 1 and 4) above, and to repeat AFBorchet's argument [9] (and similar) shows a misunderstanding or incompetence regarding law, and does not accord with current layout. Moreover, if you think the Foundation is doing something illegal, than the remedy is not an RfC or a WP:Vote, per WP:LAWSUIT. Alanscottwalker (talk) 18:43, 5 October 2014 (UTC)
    While I don't agree with many of the things the WMF is doing, when it comes to legal issues I think it is always best to defer to them. They have a team of professional lawyers working for them who were hired for their expertise. If they believe that MediaViewer does not violate licensing requirements, then I trust them. -- King of ♠ 02:43, 6 October 2014 (UTC)
  2. I'd support this if only the first 5 bullet points were present, but I can't support it given "7 days after this RfC closes our JavaScript experts and other admins are directed to take any steps necessary to implement this RfC, if such steps are still needed." Jackmcbarn (talk) 17:50, 5 October 2014 (UTC)
  3. The WMF is supposed to serve the projects, not the other way around. Their removing the super-protection is too little, too late, and they should not be setting conditions. Their forcing software changes on the projects that impair our ability to execute our mission here is indefensible and is yet another indication that they have forgotten what we are here for and what they are supposed to exist for. No negotiation. Throw this thing out. Yngvadottir (talk) 21:11, 5 October 2014 (UTC)
  4. Per Jackmcbarn I agree with all but the last bullet. While I think Mediaviewer should not be the default, I don't think that we should be tempting the WMF to reinstate something like super-protection. Whether we like it or not, these are still their servers, and while WMF policy gives users wider latitude for making major site changes than just about any website I can think of, I don't think we should push it. There has to be a better diplomatic solution before we declare war. --Ahecht (TALK
    ) 02:34, 6 October 2014 (UTC)
  5. The 6th bullet point seems like the wrong approach. The others would be okay if the first passes ( granted I am opposed to that at this time as well ). PaleAqua (talk) 15:12, 6 October 2014 (UTC)
  6. Bullet 6 as it stands is a bad idea; we should not commit to this until we know it will work. That is to say, we shouldn't hold this RfC until we've already written and approved a JS script that will accomplish this. Frankly, I'm not sure that any solution we come up with will be good enough. This is putting the cart before the horse. Writ Keeper  21:50, 7 October 2014 (UTC)
  7. A declaration of war against the WMF if they fail to comply will just lead to the return of superprotect or mass blockings. This isn't a major enough issue to justify an internal civil war. Mogism (talk) 00:24, 10 October 2014 (UTC)
  8. Per Jackmcbarn, Mogism, etc. There's no need for any party to be antagonistic here. — This, that and the other (talk) 10:12, 10 October 2014 (UTC)
  9. Per the above comments. Giving the WMF 7 days to do what you want isn't collaborating; it's tantamount to a declaration of war. A war is a waste of energies and will end up damaging the project, which seems a little like cutting off one's nose to spite one's face. Ca2james (talk) 16:21, 10 October 2014 (UTC)
  10. Not only is the sixth bullet point not technically feasible (see below), but it is also absurd and objectionable to talk of directing all admins and Javascript experts to take any steps necessary to implement this. What will we do to any that don't snap to attention and rush into action - denounce them as enemies of the Party? NebY (talk) 19:24, 13 October 2014 (UTC)
  11. Per WP:CONEXCEPT. This whole proposal is muddle-headed and wrong. Hawkeye7 (talk) 02:12, 15 October 2014 (UTC)
  12. Per Hawkeye7 and NebY Smallbones(smalltalk) 15:02, 25 October 2014 (UTC)
  13. I disagree with the proposal of "placing a 7 day hold against Community action to implement this RfC; 7 days after this RfC closes our JavaScript experts and other admins are directed to take any steps necessary to implement this RfC". As a community we should try to keep a cautious approach. --NaBUru38 (talk) 22:02, 25 October 2014 (UTC)

Neutral (Media Viewer RfC Question 2)[edit]

  1. I don't care how the WMF is informed, how Media Viewer is disabled, or what schedule is followed. I just want Media Viewer disabled by default for all users (including anonymous readers) within a month of the RFC being closed. Assuming, of course, that the decision is "disable by default" or "remove it entirely". Or even "kill it with fire" but that last one presumably violates the rules about civil discourse. — Preceding unsigned comment added by (talk) 01:54, 6 October 2014
  2. "Good faith"? This is not a question of "faith". The community disabled the media viewer AFTER they saw what it was doing. —Neotarf (talk) 23:38, 7 October 2014 (UTC)
  3. Neutral - The hostility is unfortunate. It may be that the WMF started out by taking a hostile attitude toward the community, but we don't need to perpetuate that hostility. Robert McClenon (talk) 19:08, 13 October 2014 (UTC)
  • Abstain. This is pointless. First off, there is no obligation implied or otherwise that the WMF comply with any RfC in their charter or bylaws. Second, there have been many highly substantive changes at the WMF, including a new Executive Director that has yet to oversee a full development cycle and a brand new VP of Engineering that has yet to oversee anything at all.
Please, consider this; is it the community's will that we don't give them a chance? I would like to see what these leaders at the WMF can do before everyone dogpiles on them- especially Lila. 2-3 months should be more than enough to see which direction they plan to lead the community in. Or maybe we'd prefer the immediate gratification of cutting off our nose to spite our face? Here's an alternative plan: as a community, let's give them the support they need to accomplish our mutual goals. If we step up; they will either step up with us or fall down the staircase. So how bout we step up and see what happens? -wʃʃʍ- 00:36, 8 October 2014 (UTC)
  • "...see what happens"? This is what we've been doing for months now. And thanks for lending support to the nose thumbing directed at consensus by your pat referral to "by laws". Most governments of the free world are subject to the same laws as are the people -- but evidently not here at Wikipedia, something that is supposed to be a pillar of community team work. -- Gwillhickers (talk) 23:55, 9 October 2014 (UTC)
By "months," you're talking about the 4 months the new ED has been on the job? Sure. And while we're at it, I'd like a full list of substantial changes the VP of Engineering has made in the several days we've been waiting after he started.
This is absurd. It took years for these problems to build up. The community demanded change, and it got it. Now you expect the new management to clean things up yesterday? Give them a little time. Or continue to push these half-cocked RfCs while everyone else gets back to work with renewed vigor as the true benefits of the changes the Board and Lila have made become apparent. Worst case scenario, change doesn't happen fast enough or goes the wrong way, and you can get back to these toothless and skin-free RfC's in 6 months or so. Why not give them a chance and see where they take things? -wʃʃʍ- 21:23, 14 October 2014 (UTC)
Wllm, please stop discussing things as if you are "from the community" and not "from the WMF". If you want to see what the leaders of the WMF can do, just go home, where you have every opportunity to observe that. Don't pretend to be "one of us" with your "we" for the editors here, and "they" for the WMF, when all you are is a WMF mole. Fram (talk) 10:42, 10 October 2014 (UTC)
I'm a WMF mole? No, Fram, I'm a human. Just like you. And I show you the respect that every human deserves. I'd appreciate it if you would reciprocate by not trying to exclude me from community debates.
I am part of this community, whether you like it or not. On the flip side, I am not part of the WMF and don't represent them in any way. No doubt many WMFers would find your suggestion that I'm some sort of mole as ludicrous as I do, considering my outspoken criticism of certain aspects and actions of the WMF in the past. I'll go toe to toe with you about the "merits" of these silly petitions, and I can do it without resorting to bad-faith attempts at discrediting you. -wʃʃʍ- 21:02, 14 October 2014 (UTC)
  • Erm, I dunno. If I'm reading this correctly, the general thrust is "Let's see if the community is OK with the Media Viewer as default, and if it is, nothing much happens, but if its not, we'll make it the not-default using Javascript, OK?". Right? I think I'm reading the intent right. Hrm, don't know about this... I'm a little unsure if the community should be doing this, and here's why: the community that is voting on Question 1 is basically editors, mostly long-term heavily involved editors. Not entirely but skewed in that direction. It's only human nature for people to want to have an environment that is best for them personally and to conflate that with the best environment generally, and also only human nature for people to have difficulty getting inside the shoes of people who are very different from them. "'It's a good thing we don't all like the same things', said the Scotsman -- 'think of what a shortage of oatmeal there'd be!'" is, after all, funny because there's a kernel of truth in there.
To avoid the first and do the second takes effort, practice, and the proper mindset. It's not something that everyone can do. That is why they don't just grab the nearest programmer to do the user interface design and so forth. So I guess one of the questions on the table is: Who is best qualified to suss what Mrs Pinckney Pruddle of Sandusky, Ohio, probably expects to happen when she click on an image.. Is it the community of experienced Wikipedia editors? Is the WMF? Is it someone else? I don't know, but I'm not confident that it's the community of experienced Wikipedia editors as opposed to the WMF. Herostratus (talk) 15:01, 13 October 2014 (UTC)

Reserved for official comments by WMF employees (Media Viewer RfC Question 2)[edit]

(Please do not edit here if you are not WMF)

Please see our response to the first question above.

Discuss and comment (Media Viewer RfC Question 2)[edit]

(The following thread was split off of #Neutral (Media Viewer RfC Question 2) by Alsee (talk) 14:54, 9 October 2014 (UTC))

We've given the WMF months. We're still stuck with the shoddy, ill-conceived software that is Media Viewer. We've told them we don't want it. They responded by saying, "Hey, we're listening to you. Give us suggestions." And then when they summarize what we said, they ignore the dominant feedback that people don't want Media Viewer, instead focusing on little details but pretending they've made vast improvements. It still stinks. It shouldn't be replacing the file page for anyone. The community is the project, not the WMF. The WMF is a useful legal entity to do the things that the community can't. But they've deluded themselves into thinking they're the boss and they aren't. This is unacceptable. They absolutely are bound to abide by an RfC of this nature. Their whole purpose is to serve the community, like it or not. The community has given the WMF months to do the right thing. It shouldn't give them even another hour because it looks like the WMF still doesn't get it. Disable Media Viewer immediately. And if the WMF pulls another Germany, ask the stewards, on behalf of the community, to lock the WMF out so that community consensus is honored. The WMF has burned all their good faith. It's time that the nightmare that is Media Viewer ends. -- (talk) 02:56, 8 October 2014 (UTC)

I doubt that most of those who don't like MV would support such a dramatic approach to the issue. And, when it comes to WMF being the boss, there are very few assets in this project that aren't given away for free. Those assets include the domain names. The WMF and the domain names are not sold separately. If you don't like the way the WMF is running things, and you feel you've given an organization with a new chief executive just 4 months on the job enough time to fix everything, your most productive path is to fork the project. Please. There are plenty of people who want to get back to building a great encyclopedia on, and I venture to say that anyone who isn't interested in working constructively with the WMF won't be missed much.
It's time to call all bluffs: work with us or fork off already. In either case, please stop wasting people's time on these silly and ultimately toothless petitions and RfCs. -wʃʃʍ- 06:34, 8 October 2014 (UTC)
You're not calling any bluffs. I have no interest in working with anyone on Wikipedia and as evidenced by my refusal to actually create an account. I've never expressed any interest. You've lost nothing no matter what I do. I'm not pretending otherwise. I'm not at a point in my life where writing or editing an encyclopedia—or working on any wiki—holds any attraction for me. I'm just sick of the disaster that is Media Viewer being justified in the name of people like me who just read. I'm sick of the complete deafness in the WMF to any feedback about Media Viewer that doesn't fit with the "Multimedia vision" some middle-manager at the WMF came up with one day and now it's the plan, hell or high water—without any any meaningful community consultation. All this, while pretending they're listening. I'm incensed that the community that is actually the heart of the project is being ignored by the legal organization created to serve them when the community spoke with a clear and unambiguous voice that they didn't want this product. And I'm livid that the organization which no longer represents the community it was supposed to is raising funds in the name of that community in order to do more of the same but implying that the money is needed for infrastructure. This is deeply misleading and offensive.
Lila had plenty of opportunity to deal with this better at a very early stage. The negative feedback after the initial rollout was swift and overwhelming. It would have been a good time to rollback and reevaluate. Instead, delay, delay, delay. Let's lock a community out of its wiki when it does something we disagree with—and let's write an emergency software patch on a Sunday morning to do it. Oh, it's been out for months now... we can't roll it back now. It's a rigged game and it's bullshit. And I can't believe Lila, no matter how new she was, had no idea what she was doing.
I'm sick of Media Viewer. I can't get rid of it. Broken opt-out for people without accounts—supposedly the people that this was written for. Media Viewer showing up in external links to the site which I can't fix, even when the opt-out is working. If I cared about the mission, I might be upset about forcing this down the throats of other people similarly situated. But realistically, never show it to me again, and while I'll still think the WMF is rotten, I won't think of it until I see a stupid, misleading advertising banner asking for money the WMF doesn't need. Or the next stupid piece of software that nobody outside the WMF asked for is rolled out and makes the site more annoying to use. -- (talk) 07:40, 8 October 2014 (UTC)
@Wllm: Supporting this IP. They are bang-on right. I have actually raised the issue of forking. I believe it's long past time. The WMF is a ridiculously inflated appendage that is swinging the project around - WP:FLOW will be even more of a disaster, and yet the WMF refuses to stop. The train of mistrust of the WMF left a long time ago thanks to this string of unjustifiable and mismanaged software changes. Yngvadottir (talk) 19:03, 8 October 2014 (UTC)
@Yngvadottir: I'd like to hear your reasoning in the current context, not that of "a long time ago". The Board realized there was a problem. 4 months ago Lila took over as Executive Director. Just days ago a new VP of Engineering was introduced to the community. We already see things changing, although we haven't yet seen a full product cycle in which communication and trust is established from the get-go as they should be under these 2 leaders. This is the current context, and it's quite different from previous situations. Please explain why it makes more sense to fork during this period of great change, rather than giving these people and the Board a chance to fix what's broken. -wʃʃʍ- 00:22, 9 October 2014 (UTC)
I've seen no evidence of even a single change, just lots of marketing mumbo jumbo. I tend to agree with Yngvadottir that the time for a fork may be fast approaching, particularly as Jimbo has said that he's prepared to pay for the necessary server(s). Eric Corbett 00:28, 9 October 2014 (UTC)
I've got to agree with Eric here - if there is institutional change going on as far as how the WMF will plan, deploy, and approach the community about software, that change hasn't come through to the community yet that I've been able to see. I don't doubt that they're probably trying to change, but if you're saying "But things have already changed for the better, and will keep changing like that", and we can't see any change...I dunno. Maybe they need to change harder? A fluffernutter is a sandwich! (talk) 00:39, 9 October 2014 (UTC)
I've been spending a lot of time on the wikimedia servers and even talking with the WMF director. She hasn't had the job very long, and she was honestly blindsided by the community reaction to Superprotect. In her last job as Chief product officer it was perfectly natural for management to lock down the javascript like that. She's been getting a crash course in who we are and how we work. She is planning some change in MWF approach to things, but I can't tell yet whether she plans to collaborate with us or whether it's going to be more bogus "Community Consultation" like they had on Media Viewer. I suggest lowering the pitchforks until we see what happens next. Alsee (talk) 03:57, 9 October 2014 (UTC)
But it's well beyond time for things to change, hence the pitchforks. Eric Corbett 04:23, 9 October 2014 (UTC)
I started this RfC, I'm lugging around the biggest heaviest pitchfork here. I suggested lowering the pitchforks, not dropping them. I don't want to get jabby if we can avoid it. Within a week of RfC closing, probably sooner, we'll know whether the WMF is escalating or de-escalating the situation. Alsee (talk) 16:24, 9 October 2014 (UTC)
Here are two examples of changes of a very different nature. Let's start with something very concrete. Lila hired a new VP of Engineering. If we're talking about change WRT the software the WMF develops, it doesn't get much better. Now for something a bit less tangible. I just skimmed over Lila's talk page. It looks nothing like Sue's. Lila is clearly listening, asking questions, and taking action on the feedback, which is apparent in what she's said there about the Flow project.
I think you guys are talking about not seeing the benefits from change yet. Well, big changes have happened with more to come, no doubt, and they will turn in to results in a few short months. Is it really unreasonable to suggest we wait that long before we pick up the pitchforks and light the torches? -wʃʃʍ- 00:51, 19 October 2014 (UTC)
The only concrete change I want here is Media Viewer being disabled by default, as per consensus. This ugly baby needs to die and the people who forced it down our throats need to find new employment. That would be concrete change, not the organizational lip service you've talked about. -- (talk) 02:14, 19 October 2014 (UTC)
@Wllm: First I've heard of anything except the change in Executive Director. Of course you intend to stay around and see what the WMF does - you came in with her, into the WMF. The thing is, the WMF is not the management of the projects - it is a service adjunct to them. We are the ones who do the work. If your partner was "blindsided" as Alsee says, then she did not research the job. The Visual Editor debacle and before that the community's response to the removal of OBOD without providing IP editors with any replacement notification of posts to their talk pages should have provided ample history regarding the community's response to their work environment being mucked up in the name of - full employment for programmers? poorly defined change for change's sake? - and the manner in which the volunteers here reach decisions was surely in the briefing sheet (this is the second time I see you referring here to "wasting time"). For that matter, I understand the WMF refused some time ago to implement a change in respect to creation of new pages that had been decided upon by English Wikipedia. And preparations to force WP:FLOW on us are still barreling along. No, I don't see any changes on the WMF's part. The one recent piece of news I am aware of is that Jimbo insulted all of us at the latest con. Yngvadottir (talk) 04:11, 9 October 2014 (UTC)
I'm sure Jimbo did so thoughtfully and with kindness though. Eric Corbett 04:38, 9 October 2014 (UTC)
Was that when Jimbo said something to the effect that those who aren't here to build an encyclopedia in good faith should find something else to work on and leave the rest of us to do what we love to do in a constructive environment? I can't say I agree with everything Jimbo says, but I'm 100% on board with that. The petty politics and nastiness that is apparent in all too many comments on this page has got to go. -wʃʃʍ- 21:35, 14 October 2014 (UTC)
  • Which "javascript experts" are we talking about here? The self-appointed ones? The ones who took a class once and totally know what they're doing? The ones who have admin rights, and thus must know what they're doing? The ones who heard about this piece of js from someone who totally knows what they're doing, so the code must be ok? The whole reason the js-editing debacle turned into such a disaster last time is because we don't have a designated team of "javascript experts" in the lay community; instead we have a team of admin-type people who have the technical ability to edit mediawiki pages but who may or may not have the slightest idea what they're doing. If a mediawiki dev(s) or other actually-provably-qualified-to-edit-mediawiki-code person is willing to write javascript that will a) enact the community's will and b) not be buggy, prone to breaking things it shouldn't, or otherwise degrade site performance, then yeah, let's talk about the cases where the enwp community will use that code, and how we're going to limit the ability to edit that code to that person or people. But unless you're going to limit this implementation to those qualified people only (perhaps through limiting editing of mediawiki space to those actually responsible for the mediawiki software? oh, wait...), we're just going to land back in a case where a well-meaning person throws in a hack, breaks things sitewide, and has to be reverted while everyone gets very angry and shouts rude words. A fluffernutter is a sandwich! (talk) 18:57, 5 October 2014 (UTC)
If I'm not mistaken there's significant precedent of community management of Javascript, and I trust we have competent people for the job. Nonetheless, this RFC already explicitly designed to address your concerns. You can OPPOSE question one and SUPPORT question two. Alsee (talk) 21:29, 5 October 2014 (UTC)
Well no, this isn't addressing any of my concerns, because my concern in this case is that Question Two is written in a way that's just unworkable, and I'm worried to see people voting either way on it without thinking about that. The last time around, we had someone who didn't know javascript "fix" mediawiki to match the community's will by breaking it, and there's nothing in this proposal that stops the same thing from happening again: "The community said to do X, so even though I don't know if this patch will work, I'm going to put it into our local setup, because the community's will must be done, and right now!" If we want to play hardball in this way - forcing through software changes to do what the WMF won't, taking responsibility for producing our own code that supplements or replaces theirs - then those software changes had better be absolutely bulletproof and implemented according to best practices, not hacked together by whoever happened by and volunteered themselves, whether they knew what they were doing or not. The "our javascript experts" in this proposal will end up being "whoever shows up" unless you have actual mediawiki or javascript experts who have pre-emptively signed themselves up to be in charge of this software change. A fluffernutter is a sandwich! (talk) 22:22, 5 October 2014 (UTC)
    • I think instead of focusing on the "who" and instead on the "what" would be helpful here. I think it would be good policy that soon after starting an RfC that you send a notice to the WMF developers that there is an RfC, and that X is the code we currently will use to implement it. This means the initiator of the RfC needs to either supply the code or find someone who can write it fairly early in the process. If there's anything wrong with the particular code - will it break something else - then we'll gladly work with any feedback from the developers. But it's not an invitation for WMF to overturn or alter the results of the RfC, but rather is an invitation for them to give feedback and help the community implement the RfC without disrupting anything else. VanIsaacWScont 00:01, 6 October 2014 (UTC)
I think it's safe to say that the WMF has been notified, chuckle. I'm a programmer, but I haven't worked with Javascript specifically. During the Superprotect event German Wikipedia made a very hasty change which fully disabled Media Viewer rather than setting it to Opt-In. I'm sure that javascript has been widely examined and the opt-in version is well known by now. I did consider adding something to the RfC setting up public review process, but I didn't want to complexify the RfC. Alsee (talk) 19:41, 7 October 2014 (UTC)
Do you know of a JS solution to this? I don't know if I'd be considered a Javascript expert or not, but I am also a programmer, and I have worked with Javascript quite a bit, including here on Wikipedia; I haven't heard of a JS solution yet, and I don't really think one is possible that will be good enough. The problem is that the current MV opt-out preference is in a place where we can't really do much to it. We can look up its value, or change it with an API call, but the problem is that it is on by default right now, and we can't change that directly through JS (since it's not a gadget). We also can't distinguish through JS between people who have deliberately checked it and people who just haven't touched the setting at all(I think we can through the DB itself, but both cases look the same to the JS), so we have no way of telling the difference between someone who has slready opted in and someone who has just registered and has simply not changed the default setting. We could create our own on-by-default gadget to physically disable the MV, but then there are two different settings on two different pages that both have to be enabled to use MV, which is bad (though undoubtedly the two-key approach will appeal to some in the audience...). I'm not sure there's any good way to do this without something more heavy-duty than JS. Writ Keeper  21:50, 7 October 2014 (UTC)
Yeah, I wasn't referring to this matter specifically, but to a general principle of conducting RfCs in the future. If an RfC will require a change to site code or settings, we should have that code established early on, so that the developers can submit any feedback on unintended consequences of the proposed code or settings changes. VanIsaacWScont 05:10, 12 October 2014 (UTC)
I'd say we should consider more than one option... For example, what is going to happen, if the answer to this question will be "No."? Will nothing be done, or will someone disable MV without informing WMF? Also, perhaps we have more "creative" ways to do something (like, just to "brainstorm", showing a link to the "Open letter" whenever a request for donations is shown)? --Martynas Patasius (talk) 22:48, 5 October 2014 (UTC)
Oppose getting into stupid pissing contests with WMF. The terms of Use we all agreed to make it clear WMF controls and decides what the technical infrastructure is. There's nothing wrong with having discussions about how software features impact our editorial work and conveying the consensus of such discussions to WMF, nor in criticizing there actions collectively or individually (as allowed by the "good faith criticism that does not result in actions otherwise violating these Terms of Use or community policies" clause of those terms). But intentionally making edits to alter the function of the software in a manner known to be contrary to WMFs wishes is wrong. NE Ent 21:38, 13 October 2014 (UTC)
Could you, please, cite the actual text to that effect? I don't see anything that could be interpreted as a promise to obey WMF on software matters without question. Of course, I might have missed it... Or, perhaps, I have looked at a different version ([10])... --Martynas Patasius (talk) 22:02, 13 October 2014 (UTC)

Proposal Trusted Tester user group[edit]

On 20:39, 14 May 2013 (UTC) I suggested WMF to create "trusted testers" user group. Someone from WMF called that a good suggestion. After that, I don't know what happened.

I can see someone has started an RFC in this page on MediaViewer. I clearly support that RFC, but, I am too reluctant to write there. Does WMF care?

Anyway, currently when WMF makes a change (call it VisualEditor, MediaViewer etc.), it is forced on all/thousands of editors and for next many weeks, hundreds of editors report dozens of errors, and WMF keep on fixing/improving those.

Can't we create a "trusted tester" (TT) user group like Google or Microsoft? The trusted testers (TT) will be the first editors to test a feature and report good" or "bad" or anything. --TitoDutta 17:41, 13 October 2014 (UTC)

I don't think there was any shortage of people testing MediaViewer - the complaints about it started when it was in beta and have not stopped to this day. One of the biggest problems with MediaViewer is that it's been imposed not without consultation with the community, but rather over the community's vigorous protests. I'm not sure why we need a separate "Trusted Tester" user class when people can always opt in to the beta features from the WMF labs. 0x0077BE [talk/contrib] 17:53, 13 October 2014 (UTC)
Agree, no need for a usergroup that gets forced features that can just be handled by opt-in. I don't see a problem where "unauthorized" testers were using beta features that caused harm. — xaosflux Talk 18:11, 13 October 2014 (UTC)
The reply said:
"That's a good suggestion :). I know that Erik (Eloquence) is very keen on the idea of deploying things in a beta on enwiki, in future, rather than testing elsewhere; hopefully this will allow us to discover problems 'natively' before they become a problem for many users. Okeyes (WMF) (talk) 20:49, 14 May 2013 (UTC)"
Beta came six months later: Wikipedia:Village pump (technical)/Archive 120#Introducing Beta Features and Media Viewer. PrimeHunter (talk) 00:31, 17 October 2014 (UTC)
I see no benefit from a user right here. There is already far too much software-enforced hierarchy. If a group of "neutral" testers is to be identified so that "people who just want to find fault in everything" can be ignored, you can do that socially. To deny random users the opportunity to test and comment on beta features before they are made mandatory would be yet another major step backward in terms of community input. Wnt (talk) 21:36, 17 October 2014 (UTC)
This is not a user right. This is a user preference. Add a checkbox to the preferences panel "Always enable new experimental features." Oiyarbepsy (talk) 00:48, 23 October 2014 (UTC)
The term "trusted testers user group" is confusing. I agree with having an option to "always enable new experimental features", and I disagree with adding a new MediaWiki user permission group. --NaBUru38 (talk) 22:03, 25 October 2014 (UTC)
Are you aware that a checkbox "Automatically enable all new beta features" already exists? It's at the top of the beta features tab. — HHHIPPO 15:19, 26 October 2014 (UTC)

"Notable residents"[edit]

I suggest that any person who is listed as a "notable resident" (or similar) in any article should be removed from the article unless that person has an article named for them. There are far too many of these "notable residents" who are mentioned in many articles without justification. If they don't have an article named for them then they are not notable and therefore not "notable residents". Jodosma (talk) 19:27, 14 October 2014 (UTC)

I'm amenable to a third-party source discussing the individual as an indicator of notability, but if there's no article or sourcing, I can't imagine why they'd be listed. DonIago (talk) 19:36, 14 October 2014 (UTC)
All over Wikipedia individuals are mentioned as if they are "notable", e.g. in articles about colleges or schools or minor authorities (councils and the like), the tutors and senior members of the staff (or council) are often mentioned, in many cases stated in the article as being "notable", as if the statement that they are notable makes them notable. I would like to remove all of these if they don't have an article named for them. When these people are named then the person naming them should first of all create the article about them. This kind of thing also occurs in many articles about businesses or companies, with no justification. Jodosma (talk) 19:57, 14 October 2014 (UTC)
I think it is fine if a no-article notable resident is listed along with a third-party reference that establishes their notability. This sort of entry aligns with WP:REDLINK, the expansion of the encyclopedia. Binksternet (talk) 22:13, 14 October 2014 (UTC)
I agree with Binksternet. We do not tell WP:VOLUNTEERs that they must first create an article to be permitted to make a small improvement to another article. Your definition of WP:Notable is wrong: a person is notable when s/he qualifies for a separate article on the English Wikipedia. You can be notable for decades before anyone actually starts writing the article.
If there's no source for such an entry, then please find one yourself. If you're not willing to make that much effort, then add a {{fact}} tag, and check back in a couple of months (yes, months, not days) to see whether anyone has done so. Don't just blank them because you don't like them and can't see the value in them. WhatamIdoing (talk) 22:19, 14 October 2014 (UTC)
If red links obviously merit an article leave them. In most cases they do not and should be removed there and then.Charles (talk) 22:26, 14 October 2014 (UTC)
Comment: Red links in articles are different than those found in links lists. The ones in articles probably have a chance of being expanded someday, probably by the person who put it there to begin with. Lists are different, however. Any name can (and repeatedly are) added to lists that are never, ever going to be notable, or are actually tagging/vandalism. If they are in a list, the name, item, or whatever needs at least a reliable source citation if there is not an existing article in Wikipedia. Red links in wiki-lists are meaningless. PS: "Notable Residents" sections are, imo, list sections. GenQuest "Talk to Me" 23:30, 14 October 2014 (UTC)
The Notability standard only applies to creating an article. The standard for including information in an article is a lot lower. Alsee (talk) 10:32, 16 October 2014 (UTC)
On the other hand, many of these additions are supposedly living people. I say supposedly because they could be someone's boyfriend, dog, worst enemy, whatever. With no sources we simply don't know and such entries may be WP:BLP violations if not simply promotional. A fact tag isn't enough to prevent a BLP violation. Dougweller (talk) 16:10, 16 October 2014 (UTC)
I agree that they are essentially lists, which on Wikipedia are advised to have inclusion criteria so they don't become indiscriminate, and all content on Wikipedia is required to be verifiable. Often content in lists is verifiable via the bluelink, so if an entry in this sort of list is redlinked or not linked at all, it is probably non-verifiable and should be flagged; however Dougweller is right that such entries in lists of people are likely enough to be information about living persons (who are alive unless confirmed deceased) which is to be removed immediately if not verifiable. You may also be interested in WikiProject Laundromat which is aimed at cleaning up such lists. Ivanvector (talk) 16:28, 16 October 2014 (UTC)
If someone wants to put a non-linked name in a list, it is incumbent on them to show why that name belongs on the list. Otherwise, it is OR and should be immediately removed as such. Lists inclusions are different from inclusions in articles; per the the comments above. GenQuest "Talk to Me" 01:20, 17 October 2014 (UTC)
No, that's not OR. "Original research" involves material that has never been published, anywhere on the planet, at any time. "Uncited" is what we call material that someone has added without showing why that name belongs on the list. WhatamIdoing (talk) 19:31, 17 October 2014 (UTC)
I should've also included "Uncited" above, as both apply. In either case, those entries can be removed immediately, no tagging necessary, per BLP. GenQuest "Talk to Me" 22:41, 17 October 2014 (UTC)
The above discussion appears not to consider the situation where a good, referenced source document says "Bloggs, Smith and Jones did a very important thing (X)" but only Bloggs and Smith have WP articles, AND Jones was otherwise so non-notable that no WP article for him is even likely. IMHO his name (without a redlink) belongs in the articles for Bloggs and Smith (and for X if it has one) It also belongs (with ref but no redlink) in a list of people related to X, or of people in an occupational group etc related to X. Downsize43 (talk) 10:37, 19 October 2014 (UTC)
I think in a case like this it belongs in the article; it does not belong in a list of people associated with the subject. Article content does not have to be notable. The best rule for people in such a list is that they either have to have an article or be obviously qualified for one--with a reference. DGG ( talk ) 18:31, 20 October 2014 (UTC)
I propose to remove the term "notable" and just write: "City/town residents include Alicia and Bob". --NaBUru38 (talk) 22:05, 25 October 2014 (UTC)
No, no, no. That would result in a random list of self-publicisers who happen to have heard of Wikipedia. It would not be useful to our readers. DGG has it right - people in the list should either have an existing article, or be demonstrably notable in Wikipedia's sense, with a reference to prove it. JohnCD (talk) 11:14, 30 October 2014 (UTC)

Tables with collapsible columns[edit]

I would like to be able to collapse (hide) certain columns of tables, sometimes. For example, when I (double-)click on the third column on the following table ("Motor vehicles"), to hide the fourth and the fifth column, because the third column is the sum of the fourth and fifth. And then, if I click it again, to show them. Sometimes tables can have too many columns and then, when you first look at the table, some columns would be better to be hidden, in order for the reader to see the essential. Then, if the reader wants, they should be able to able the not-so-essential columns.

Did anyone think about implementing such a feature?

Vehicle production of SouthVulcania (millions):

Year Bicycles Motor vehicles Trucks Cars
2010 30 100 80 20
2009 29 90 70 20
2008 28 80 65 15

 Ark25  (talk) 22:23, 17 October 2014 (UTC)

Judging from MediaWiki:Common.js, section Collapsible tables, it should be possible with a little Javascript, but implementation will need a fair bit of testing. Adam Cuerden (talk) 10:35, 18 October 2014 (UTC)

I would find it useful. Keep in mind, per MOS, that columns should be open initially, but I could see value in giving the reader the option to close some columns. Please also note that in the case of a sortable table, one sorts simply by clicking on the column heading, so it the table is to be sortable and allow column hiding, one have to think through how to do each option separately.--S Philbrick(Talk) 21:56, 19 October 2014 (UTC)
More often than not I find collapsed by default content obnoxious. If an information relevant to the topic of an article, then it should be presented openly. Please don't play hide and seek and make me look for magic buttons to click on.-----<)kmk(>--- (talk) 03:44, 26 October 2014 (UTC)

Shortcut T for Template namespace[edit]

I see in this previous RFC there was a rejection of using "pseudo-namespace shortcuts" such as T: for Template: namespace. I didn't read the whole RFC but I do know that I get tired of typing "Template:" into the search box each time I want to find a template. The name space "T" is unused so I don't see why there can't be a change made where this could be implemented. Comments? ~Technophant (talk) 03:35, 20 October 2014 (UTC)

More reading material for you: Wikipedia:Perennial proposals#Create shortcut namespace aliases for various namespaces. When re-making a proposal for something that has already been repeatedly rejected, you really should address the reasons for it being rejected previously. Anomie 10:38, 20 October 2014 (UTC)

Better idea[edit]

How about changing the search box so that if I type in {{infobox}}, the search box is smart enough to suggest Template:Infobox? That would address @Technophant:'s issue - they could just copy and paste it from the wikicode. Oiyarbepsy (talk) 01:03, 23 October 2014 (UTC)

How about alowing any page to be included/transcluded with parameters? If there is none, then it would render without any extra computing. --NaBUru38 (talk) 22:09, 25 October 2014 (UTC)
I'm not sure how that would help anything. Oiyarbepsy (talk) 21:05, 28 October 2014 (UTC)

Creation of the "Special talk:" namespace[edit]

It's not obvious where to discuss Special pages, but it seems the typical place for them is Wikipedia:Talk:Special:Foo. On the other hand, sometimes they are at Help:Talk:Special:Foo, so it's not even consistent. In my view, this should instead be Special talk:Foo, and Special:Foo should have a discussion tab just like any other page. This would give a place for people to discuss special pages that they would actually be able to find. Oiyarbepsy (talk) 18:48, 18 October 2014 (UTC)

Note: Please see Wikipedia talk:Criteria for speedy deletion#Proposal to update R2 criterion for "Special talk:" redirects for the discussion that prompted this one. Steel1943 (talk) 18:52, 18 October 2014 (UTC)
  • Per my comment in the other discussion Steel linked to (please respond there), creating a NSA for the "Special talk:" to point to "Wikipedia talk:Special:" is pretty easy. To get a "discussion tab" on Special pages would be more difficult to do in core because, as I understand it (which isn't always the way it is), special pages aren't normal pages in a normal namespace (hence the NS number of -1); that said a gadget could be created that would simulate a "discussion tab" on most special pages (there are a couple where .js won't run for security reasons). — {{U|Technical 13}} (etc) 21:41, 18 October 2014 (UTC)
Struck-out text that is no longer pertinent to the current discussion, but has been retained here for historical purposes. Steel1943 (talk) 15:31, 22 October 2014 (UTC)
I wonder if the Special_talk.php from this very old bug report [11] is still a going concern? This was referenced in Wikipedia:Village pump (technical)/Archive_61#Enable Special talk.php. jni (delete)...just not interested 20:33, 20 October 2014 (UTC)
  • As I said below in the discussion before this became a RfC: "Special:" is a technical namespace, and it will be easier to create a technical solution (which had this RfC not been started could have been implemented within a week or so I'm sure, but now should wait until this has concluded) than it will be to add this exception and then enforce it. As such, I oppose the creation of this CNR where a NSA[disambiguation needed] would do a much better job. For those that might not be clear on what this alternate proposal is exactly: I'm proposing to make an actual namespace alias that will load "Project talk:Special:" when "Special talk:" is given for a namespace just like "Wikipedia talk:" and "WT:" both take us to "Project talk:" themselves. Doing this means there will be no redirect involved at all and none of that hassle or issues that come with it.

Support the creation of the "Special talk:" namespace[edit]

  1. As proposer. — {{U|Technical 13}} (etc) 14:56, 22 October 2014 (UTC)
    Support, as above. Steel1943 (talk) 15:22, 22 October 2014 (UTC) I would rather see this as an actual functional namespace than an alias. I don't know why this discussion has had to be reconfigured as so. Now, the fine line between an actual functional namespace and an alias has been totally blurred. Steel1943 (talk) 19:51, 22 October 2014 (UTC)
    • It will be as much of an actual namespace as the Wikipedia namespace (which is an alias of Wikipedia:Project namespace). It can not be configured any other way. Since "Special:" is Namespace -1, there cannot be an actual "Special talk:". Before you say it could be -2, that is already taken by "Media:" (allows you to link to a file instead of using ":File:". — {{U|Technical 13}} (etc) 21:17, 22 October 2014 (UTC)
    • @Technical 13: I get how it works, and I still have my preference for an actual namespace. The "NSA" is my option in the event that it can't be done, but it's definitely not my first choice. Steel1943 (talk) 21:23, 22 October 2014 (UTC)
  2. Support Oiyarbepsy (talk) 00:45, 23 October 2014 (UTC)
    • Comment The use of abbreviations is excessive and completely out of hand. I have no idea what NSA is (a bunch of spies? Don't insult yourself?) Please write stuff out, and also, check your links, since I'm pretty sure that NSA does not mean No Self Attacks. Oiyarbepsy (talk) 00:45, 23 October 2014 (UTC)
  3. Support --Fauzan✆ talk✉ mail 05:11, 23 October 2014 (UTC)

Oppose the creation of the "Special talk:" namespace[edit]

  • Oppose as basically useless. You can't add Special pages to watchlists, severely reducing the chance of anyone seeing your comments. Comments about special pages can go to VPT or something similar, where they will get a lot more attention usually. Fram (talk) 09:32, 28 October 2014 (UTC)

Discussion about the creation of the "Special talk:" namespace[edit]

Alternate proposal 1: update speedy deletion R2 criterion for "Special talk:" redirects as exceptions[edit]

I propose that that the wording of the R2 criterion be updated to include this wording at the end as an exception to the criterion:

...and redirects titled "Special talk:Foo" that target the "Wikipedia talk:" or "Help talk:" namespaces.

I'm proposing this since the "Special talk:" namespace does not exist, and I have on multiple occasions found myself in a situation where I wanted to discuss the function behind a tool in the "Special:" namespace, but could not find its discussion page. I recently discovered that the naming convention for these talk pages seems to be "Wikipedia talk:Special:Foo". It makes sense for the talk page to be in the non-existent "Special talk:" namespace, but since the namespace doesn't exist, creating a page in that namespace defaults it into the main namespace, which would currently make it eligible for speedy deletion for this criterion if the "Special talk:" title was made a redirect. Steel1943 (talk) 16:49, 18 October 2014 (UTC)

Support the wording of the R2 criterion be updated to add an exception for CNRs from "Special talk:" to "Wikipedia talk:Special:"[edit]

Assuming Steel1943, as proposer. I'd rather see the creation of the namespace as a whole, as stated in the above sections. Steel1943 (talk) 15:22, 22 October 2014 (UTC)
  1. Assuming Thryduulf, per discussion below.

Oppose the wording of the R2 criterion be updated to add an exception for CNRs from "Special talk:" to "Wikipedia talk:Special:"[edit]

  1. Oppose creating as a CNR. Please see alternate proposal. — {{U|Technical 13}} (etc) 14:56, 22 October 2014 (UTC)
  2. Assuming Jni, per discussion below.
  3. Assuming Oiyarbepsy, per discussion below.

Discussion about the wording of the R2 criterion be updated to add an exception for CNRs from "Special talk:" to "Wikipedia talk:Special:"[edit]

  • Exactly, which is why I'm trying to propose that it be made an exception. And as for this being a pseudo-namespace, if that's the case, then essentially "Wikipedia talk:Special:" is a pseudo-namespace in an actual namespace. The fact that these redirects currently don't exist is essentially harmful. The only other option I see is a proposal to actually create the "Special talk:" namespace. (I'm trying this route first, since it doesn't require an update to the actual function of the Wikimedia software built on the English Wikipedia.) Steel1943 (talk) 18:11, 18 October 2014 (UTC)
    • I'd actually rather see it implemented as a NSA. This is a technical solution that doesn't require a namespace to be created (that really can't exist as I understand it). Prevents all drama. @Steven (WMF):, can we get a little input from the developers, please? I'm sure Jackmcbarn could put this up for merge in Gerrit (or phab, if we are using that now).  :) — {{U|Technical 13}} (etc) 19:59, 18 October 2014 (UTC)

I'm okay with this temporarily, but for the long term I oppose, since this exception is a hack. The real solution is a Special Talk namespace, which probably should exist. I'll bring it up at Village Pump Technical. Oiyarbepsy (talk) 18:43, 18 October 2014 (UTC)

Wikipedia:Village pump (technical)#Special talk namespace. Oiyarbepsy (talk) 18:48, 18 October 2014 (UTC)
@Oiyarbepsy: Essentially, I agree with your reasoning. Thanks! Steel1943 (talk) 18:50, 18 October 2014 (UTC)
I think that the exception to R2 should be something along the lines of "other than approved pseudo-napespaces", and not mention any true namespaces; at the same time, we approve the CAT:, H:, MOS:, Special talk:, etc. Any subsequent discussion about topics like this would then go to WT:Shortcut. עוד מישהו Od Mishehu 19:46, 18 October 2014 (UTC)
  • Support this exception. Such redirects can still be nominated at RfD and discussed on their individual merits (or lack of merits) balanced against any harm that it does (or doesn't) do. Just because many CNRs are harmful, does not mean that all CNRs are or that being a CNR is harmful in and of itself (hence the need to have exceptions in the first place). Thryduulf (talk) 01:15, 19 October 2014 (UTC)
  • Oppose this exception. This is just WP:BURO rule creep. Not needed in practice. No harm is done if we just wait for Special talk: namespace (the correct solution). All admins already know about "Wikipedia talk:Special:Foo" talk pages and therefore can make a smart decision on the spot, if there is a need to speedily delete a redirect pointing there. It was recently noted in Template_talk:Db-r2 that the R2 warning template had had inconsistent namespace applicability instructions compared to CSD policy itself for over four years, and nobody noticed or cared. We will get more inconsistencies like that if start inventing detailed rules and exceptions for every marginal use case of our wiki-editing tools. jni (delete)...just not interested 10:45, 19 October 2014 (UTC)
  • How is this instruction creep? The basis of this proposal is the usefulness of the creation of such redirects that are intended to target the talk pages for the discussion of pages in the "Special:" namespace. At the present time, there are no redirects titled "Special talk:Foo" that exist, (obviously, given my statement in the nomination.) Also, just because administrators, in practice, should know about the existence of the "Wikipedia talk:Special:" titles (I'm certain that several administrators do not know about that standard naming practice), the ability to find these pages should be easy to find by all editors who may need to discuss a page in the "Special:" namespace, admins and non-admins alike. However, I do agree that I'd rather just see the creation of the "Special talk:" namespace; however, as stated above, there is the possibility that it would not be technically possible due to how the "Special:" namespace is programmed in the English Wikipedia. Steel1943 (talk) 16:40, 20 October 2014 (UTC)
  • I agree that it is instruction creep actually. It's an attempt to introduce wording to a social method of moderating what does or does not happen on wiki when there is a much simpler technical approach. I see no objection to adding the NSA here, and will request it added on bugzilla tomorrow afternoon (about 28 hours from this post) if it remains unopposed for the simple technical solution. The technical solution makes adding it to policy unnecessary and moot. — {{U|Technical 13}} (etc) 17:01, 20 October 2014 (UTC)
  • It's not necessarily instruction creep if the technical resolution is not possible. Steel1943 (talk) 17:12, 20 October 2014 (UTC)
  • In regards to if the technical resolution is not possible, I assure you the technical resolution is not only possible, it's easier than trying to impose a change to existing social sanctions. Since your if clause is false, then it is reasonable to assume that it is indeed instruction creep. I can't see a use case where "Special talk:" shouldn't take the user to a talk space where they can talk about a "Special:" page (even in cases where "Wikipedia talk:Special:Foo" for "Special:Foo" where "Wikipedia:Special:Foo" doesn't yet exist). I welcome cases I may not have thought of, if you have any. :) — {{U|Technical 13}} (etc) 18:45, 20 October 2014 (UTC)
  • It is instruction creep because exactly 7 such pages have ever existed (at least after last time the deleted revisions were purged from database - and last time that happened was before I was made admin here close to 10 years ago!). No redirect with prefix "Special talk:" targeting the Help talk namespace has ever existed. 3 of the deleted pages were not redirects at all and were deleted per G2 (or close to it) reasons. Details are in User:Jni/Special talk redirects review, for benefit of non-admins participating to this discussion. For the 4 redirects, some of which were deleted multiple times, 2 deletions were done without citing a specific criteria, R2 was cited 2 times and G6 was given as reason 3 times. Note the prominence of G6; I would use it instead of R2 for deleting this kind of weird artifact relating to pseudo-namespaces myself. Your proposal seems to silently limit applicability of G6, making the already convoluted and somewhat arbitrary set of CSD rules even harder to remember or apply correctly. There have indeed been some misunderstanding about this matter - see logs for Special talk:Cite where Rossami makes a circular argument, claiming that his invalid use of admin's restore tool (assuming R2 was the same as today in 2007) invalidates a later G6 CSD as well. Overall, there has not been any need for this exact kind of redirect because only 4 were ever created during last decade. If something has hardly ever existed, there is no need to make special rules for it's deletion! jni (delete)...just not interested 19:04, 20 October 2014 (UTC)
  • Rossami's argument is not circular and actually is the heart of speedy deletion - if it's controversial, it should not be speedy deleted, period. Oiyarbepsy (talk) 19:34, 20 October 2014 (UTC)
  • Oiyarbepsy, I called his argument circular ("dubious" would have been a better word), because there was a five year gap between the two deletionsrestores. The controversy, if any, cannot last for that long and later day admins are allowed to take a fresh look and are not bound by some very old actions of their peers. Besides, a really detailed analysis would require understanding the deletion policies, CSD rules and unwritten conventions as they were during each and every of the events in the log. jni (delete)...just not interested 19:53, 20 October 2014 (UTC)
  • On taking a closer look of several speedy restores Rossami did ~7 years ago (we all have important investigations like this going on from time to time, right?), it seems the then-controversial matter was eventually settled in RfD and consensus that "Special talk:Foo" redirects are not needed was established. Now it is proposed here to override this earlier consensus, but is this talk page or exception to CSD R2 really even the right forum or mechanism for this? jni (delete)...just not interested 19:50, 20 October 2014 (UTC)
  • (edit conflict) @Jni: I did not see it above, so would you be able to provide a link to the RfD discussion where consensus was formed (in one way or another) deeming the usefulness (or lack thereof) of "Special talk:" titles? (I'm, more or less, quite curious to see it, given that I had no idea that any form of consensus was established for this very matter in the past. I'm in no way saying that this changes my opinion at the present time.) Steel1943 (talk) 20:10, 20 October 2014 (UTC)
By the way, your question about if this is the right forum for this discussion, I'm actually wondering that as well, given that this discussion has turned into something more than just trying to add an exception to the R2 criterion; this discussion is turning into a discussion about whether or not a "Special talk" namespace (or an pseudo-namespace namespace alias, as Technical 13 has eluded above) should exist. If this discussion continues as it has, I'm thinking the whole discussion may need to be moved, and maybe even converted to an RFC if it continues to gain as much momentum as it has in the past day alone. Steel1943 (talk) 20:24, 20 October 2014 (UTC)
  • I've never said it should be a PNR, and I would oppose it being a PNR. What I've said, multiple times, is that it should be a NSA. A pseudo-pagename is a case sensitive combination of a Cross-namespace-redirect and a shortcut; A namespace alias is an actual case-insensitive virtual namespace just like WP or WT or Image. — {{U|Technical 13}} (etc) 21:01, 20 October 2014 (UTC)

Looking at the deletion logs for those seven pages, it's pretty much adds a lot of strength to the idea that we need Special talk. Almost all of them were either redirects to a corresponding Wikipedia talk page or were the type of material that you'd expect to see on a talk page. The fact that these pages are so rare is because the special pages don't link any talk pages, so the majority of users just get lost and give up trying to discuss them. Others guess Special talk and either post a comment or make redirects. Oiyarbepsy (talk) 20:02, 20 October 2014 (UTC)

Black (or dark) Wikipedia template[edit]

I was looking for a while if a black or dark design of Wikipedia has been ever proposed. Like I was not able to find it, I start a proposal.

I think this is not something I only thought about. There is many people who suffer from white backgrounds. Most of the web services I use can be configured in black background (DuckDuckGo, Gmail, Google, etc.). Moreover, dark backgrounds help to save energy, which is better for everyone.

I was wondering if it is possible to set Wikipedia with a dark template. Cerilet (talk) 12:33, 24 October 2014 (UTC).

(Note: This is my first edit on Wikipedia. I would appreciate if someone can move this to a more convenient place or edit it if there is something that should be changed.)

Set Preferences → Appearance → Skin = MonoBook and save, then check Preferences → Gadgets → Use a black background with green text on the Monobook skin. --  Gadget850 talk 12:42, 24 October 2014 (UTC)
However, the energy savings are an urban legend, I'm sure a Google search can confirm this.--S Philbrick(Talk) 12:56, 24 October 2014 (UTC)
Yep. Unless you're using a cathode ray tube monitor where black is a result of the screen actually being off, and the green is the type that requires very little energy to be read (same reason night vision goggles are usually green). If your monitor was made this century (well, this side of the century mark), chances are that displaying a black screen uses as much energy as a white screen, plus the additional work of diffusing the light so it looks black. Now, I do recall that if you turn the overall brightness down on an LCD monitor, that can chew up less energy (and have experienced this with my phone).
Still there are lighting conditions where I have an easier time reading white or green on a black background, and could understand how some people would have trouble with black on white. Ian.thomson (talk) 13:06, 24 October 2014 (UTC)
LCD displays work by blocking/unblocking the backlight. Their energy consumption is basically independent of the pattern they display. In theory, there is a small energy cost when switching images, but that is very marginal. For OLED displays, the energy used does depend on the brightness of the image, and the effect is significant enough to affect battery life for portable devices. --Stephan Schulz (talk) 13:14, 24 October 2014 (UTC)
Old-school LCD screens (like Amazon Kindle) work the other way around, am I right? --NaBUru38 (talk) 22:12, 25 October 2014 (UTC)
Old-school LCD's (as in digital watches or many alarm clocks) work without a backlight, only see the light reflected from behind the liquid crystal pane. Most Kindles use fancy e-ink displays that work on a very different system - there the display itself reflects or absorbs light. But both don't need energy just to maintain a static picture (modulo minor technical losses, as always in real systems). --Stephan Schulz (talk) 07:29, 26 October 2014 (UTC)


I was looking for a place where I could list my bookmarks on Wikipedia. I couldn't find one, so I propose that we make a bookmarks bar along the top of the page. It should go with the compact personal bar, so it would make the screen less cluttered with all of the bookmarks one might have.


Articles or any other Wikipedia pages can be linked from your userpage. Also, they can be placed on your watchlist to flag up when any changes are made. By the way, please sign your posts to talk pages with four tildes (~~~~): Noyster (talk), 09:40, 25 October 2014 (UTC)

Time to replace RfA[edit]

It's not to be tolerated!
RfA, the "ritual center of the English Wikipedia", has been allowed to remain a failed process for too long. For many years, new admins have been promoted far too slowly to replace those lost to desysoping or inactivity. Various discussions, charts and graphs showing this can be seen over at RfA_talk. Highlights include:

  • Back in the growth years of 2005 - 2007, we promoted on average over 30 admins per month. So far this year, we are averaging barely over a single promotion per month.
  • During the past two months there have been no promotions at all.
  • As per this recruitment thread several skilled veteran editors refused to consider running, blaming RfA's "vicious character assassinations" and "toxic atmosphere".
2008 2009 2010 2011 2012 2013 2014 (projected)
Active admins 943 870 766 744 674 633 570
Admin promotions 201 121 78 52 28 34 21
Admin attrition (actual, not net) 263 194 182 74 98 75 85

It's been suggested that the plummeting number of active admins tracks the general decline in active regular editors. This is not true. Numbers of active admins has been falling at a far faster rate than the decline of active editors. According to these wikimedia stats , there has been an increase in the number of active editors this past year ( 31,616 in Aug 2014 , compared with 30,403 back in Aug 2013). There is no good reason to expect further declines in active editorship providing there are sufficient admins to help maintain a collegial environment. The world is generating new notable topics faster than ever. By some measures, since 2008 the world's total knowledge has increased more than tenfold. In 2008 there were only 1.5 Billion internet users. Now there is almost twice that number. The world depends on Wikipedia for information more than ever.

A more convincing reason for RfA's failure is the way the process allows a minority of users with unrealistic quality expectations to block promotions. A too high quality threshold for individual promotions is a sure fire way to lower the quality of the admin corps as a whole. This paradox is explained on RfA talk with a comparison to what would happen if New York city insisted on not allowing new hires to its police force unless they're good enough to be an inspector Morse or Colombo.

There has been over 7 years of failed RfA reform efforts, even after cases where a clear majority of editors agreed the process was in need of change. Editor Townlake has therefore suggested the essential first step is to close the current process.

Once the current RfA process is closed, design of the replacement process can commence. Goals for the new process might include:

  • Facilitating a greater rate of promotions so the admin corps can replenish its ranks.
  • Ensuring any rejected candidates are not subject to character assassination.
  • Restore the editor > admin progression path, which Sue Gardner and others have said is important for editor retention and for good morale.
  • Perhaps design the process so a mix of different candidates can be promoted, for example specialist content writers, specialist vandal fighters, perhaps even editors who most prominent attributes are friendliness and helpfulness.

It may be that a new batch of RfA runs will soon begin. Due to recruitment efforts by multiple editors, possibly the existing process could see as many as half a dozen promotions in November and December. Recruitment efforts have been attempted many times in the last 5 years and are demonstrably not an effective alternative to radical reform. At best, they produce a brief blip in activity.

Trying to solve the RfA problem with recruitment efforts alone is like refusing to send a man with a gaping chest wound to hospital so you can apply some sticky plasters.

A possible model for the new RfA might be elections based on the arbitration model where votes are not public, and a fixed number of candidates are promoted each quarter. Or perhaps a form of promotion that does not need voting at all. These and other new designs for RfA can be proposed and discussed in detail once the current process is marked as historical.

Timeline for RfA reform

Milestone Date Notes
Open proposal to close RfA for voting 30 October A brief delay before the initial vote allows time for any editors who favor maintaining the current process to make their arguments.
Close the vote, with a crat to announce the result 05 November Regardless of the result, any open RfAs can continue as normal.
Open discussion for designing RfA's replacement 05 November Any editor will be welcome to propose desirable qualities for the replacement, suggest new processes , or to discuss the existing proposals. At this stage, we should also seek one of the best RfC designers such as Beeblebrox, to help ensure that once we are ready to narrow down the field, we get the best decision possible for the new RfA.
Open an RfC to determine which proposed new RfA process is best 12 November It should be understood that going back to a modified form of the existing RfA process is not an option, if the initial consensus is to close RfA, then this is also a decision for a whole new process.
Close the RfC and open the new RfA process 19 November Based on the outcome and the role crats are to play, we could also open a new discussion about replacing RfB, or possibly restoring the original process, as RfB is perhaps less obviously a failed process. Alternatively, discussions about restoring RfB could wait until the new year.
Achieve the first wave of promotions with the new process 14 December Let's give the whole word a Christmas present by taking this important step to restore our community to full health!

— Preceding unsigned comment added by FeydHuxtable (talkcontribs) 09:20, 28 October 2014 (UTC)


So, what if the first vote decides to abolish RFA and RFB (no idea why RFB is added, we have enough Burocrats since they have very little left to do in general)? IF you then don't find a consensus on any new proposal, you are left without any RFA process. How would this help with the declining number of admins? First decide on a new process, then replace the old one with a new one. Fram (talk) 09:39, 28 October 2014 (UTC)

I totally agree there is no need to change RfB - I included this per editor Townlake's original proposal to end both RfA & RfB. Also, another editor didn't agree with ending RfA, but said just RfB could be ended! Funny how some see things so differently. If you want to modify the above proposal to remove mentions of changing RfB, that's fine by me.
The risk of not finding consensus for any one new replacement can be avoided by skillful design of the final decision making RfC. I can do this myself if need be, per my edits to Deliberative democracy, Im quite familiar with the science of voting and consensus. Much better though if someone like arbitrator Beeblebrox took the lead in designing the RfC, as they have a good track record in doing that sort of thing on Wikipedia before. FeydHuxtable (talk) 09:54, 28 October 2014 (UTC)
Just to add, a big part of the problem with reforming RfA is the 7+ years history of failed reform efforts. If we don't end the current process first, there would likely not be sufficient impetus to decide on any one replacement, and therefore we'd revert to the status quo by default, as has happened time and time again in the past. If it takes a little longer to decide on the replacement than predicted, it's not like having no RfA process for a few weeks will make things worse, considering the current rate of promotions. FeydHuxtable (talk) 10:02, 28 October 2014 (UTC)
I don't think you really understand "deliberative democracy" if you believe that using that system will avoid a situation where you end with no proposal getting a majority (or consensus). Only if you present two alternatives and force the people to support either the one or the other can you be sure that you end up with a consensus (barring a perfect 50-50 vote of course). But such a thing will not be acceptable to many people here. While a well-crafted RfC can increase the chance of getting some consensus on one proposal, there is no guarantee at all that this will happen. Any proposal to abolish RfA without having a new or improved process agreed on already is doomed IMO. Fram (talk) 10:11, 28 October 2014 (UTC)
Indeed - this proposal is completely back-to-front. Establish a new process first, then get consensus to replace the old one. The idea that "turning off" RFA is the first step is simply ridiculous. In addition, the timeframe above is hilariously over-optimistic in its assumption that a new process can be developed before the end of the year; RFA alternatives have been debate at Talk:RFA for years now, with no perceptible movement towards agreement.
While I'm ambivalent about whether or not we need a new process to replace RFA, I'm pretty sure that removing the only method we have for promoting admins and then blindly hoping that an alternative will present itself is not the way to go about it. Yunshui  10:54, 28 October 2014 (UTC)
Some strong adjectives there Yunshui. It precisely because we've had years of reform attempts with "no perceptible movement towards agreement" that we should first end the existing process before starting detailed discussions of the alternatives. Im surprised even someone like Fram doesnt seem to see that ending RfA as we know it would supply far greater impetus to design a new one. Its not like a few weeks with no live process would make much different to the current rate of promotions. Granted there will be no way to ensure everyone is happy with the replacement, but surely only a tiny fraction of editors would prefer to have no RfA process at all if they can't have their first choice? FeydHuxtable (talk) 11:21, 28 October 2014 (UTC)
If this proposal is approved, I see the almost inevitable consequence being a prolonged debate for about six months over what should replace the RFA process, with no guarantee that any consensus will develop, and no functional way of promoting admins during that time. Call me a cynic, but I expect that after about six months, the need for a process would be sufficiently great that we'd end up setting RFA back up again in pretty much its current form. I'm sorry if I come across as harsh, Feyd (it's not my intent), but I feel this is a very badly designed proposal - to offer a parallel, if I'm not happy with the service I get from my gas provider, am I better off using them while I find a better service, or turning off the heating in the hopes that the onset of hypothermia will spur me to spend more time on Yunshui  12:41, 28 October 2014 (UTC)
Thanks for using more gentle wording, which is appreciated. All other things being equal, it certainly makes sense to decide on a replacement before terminating an existing gas supplier. However, what if for whatever reason you and your partner had been arguing about the best replacement for years, making no progress even though the existing supplier is now only providing gas for one hour per day. In such a case, would some not eventually consider cancelling the existing contract to force a decision for a better one?
Having seen how folk like Beelbebrox can structure a RfC, (e.g. for Pending changes) I think it could be set up so the new RfA process would be decided on in a finite amount of time. FeydHuxtable (talk) 13:54, 28 October 2014 (UTC)

The problems with RFA are threefold and interrelated. First, it doesn't address our real need, which is editors with admin tools willing to deal with other editors having problems with each other. Admins don't want to make controversial decisions or wade into volatile situations. For example, I've had to wait so long to get an admin to pull the trigger on a topic ban appeal that I actually had to unarchive it. Yes, we get backlogs behind the scenes from time to time but we have no critical shortage of mop and bucket type admins. Second, the community (or at least a very large minority of it) clearly disagrees with the idea that adminship is no big deal; as long as the RfA process doesn't reflect that reality then we're setting people up to fail. Lastly, most people take deletion related tools and the ability to fairly and competently render decisions on dispute very seriously, especially in the context of imposing restrictions on other editors, but most people aren't seeking the tools in order to engage in that work. We should retain RfA for all tools not involving deletion and placing restrictions on other editors ability to contribute (banning/blocking/etc). This will get RfA back to a "no big deal" environment. The "new process" should be one for tools involving deletion/deleted material and the ability to place restrictions as RfA works when it's truly no big deal. GraniteSand (talk) 10:02, 28 October 2014 (UTC)

The "real need" isn't dealing with inter-editor relations. In general, no admin tools are needed for that, just people willing to spend time at AN, ANI and the like. Admins may be needed to implement the solution (e.g. a block), but you don't need admin tools (or the admin "title") to discuss things. What admins are most needed for is deletion/undeletion, protection/unprotection, and blocking/unblocking. Other things, like editing through protection, are relatively minor. Wikipedia:ADMINSTATS gives you an idea of what admins do with the tools (although editing through protection isn't included). Fram (talk) 10:16, 28 October 2014 (UTC)
I wasn't clear. It's not dispute resolution I'm talking about, we have options for that all over the place; it's being willing to be the admin that takes up a problem, renders a meaningful and competent decision, and then acts upon it in a tangible and appropriate way. Never mind, I'm getting off topic. My basic point is that only RfA works for 80% of the tools it grants. Let's keep it for that 80% and reassess for the other 20%. GraniteSand (talk) 10:23, 28 October 2014 (UTC)
I like GraniteSand's proposal and analyses, though I think the time to discuss it in detail is once the existing RfA is marked as historical. If however you guys want to change the timeline so that we try to get consensus for this (or another) proposal before marking RfA as historical, I would not object. However, it's my strong opinion that doing could quite likely doom this discussion to follow the precedent of all other reform attempts, and fail completely. Huh, even the massive amount of work that went into WP:RFA2011 , led by Kudpung himself, did not achieve a single tangible change. I guess the bright side of this reform attempt failing, even in the face of the overwhelming evidence that RfA is broken, is that it might encourage Jimbo or the Foundation to step in and implement reform by force majeur, setting a useful precedent. (Jimbo did suggest he was thinking this might be needed a few years back.) Not all would see abandoning the hope of community led reform as a bright side of course. FeydHuxtable (talk) 10:47, 28 October 2014 (UTC)
Jimbo can propose anything he wants, and it will be judged on its merits. Stepping in and imposing anything is a very good way to piss off even more people than he has alreday achieved though. His last attempts at imposing anything by force (his attempts to make Commons "better" by repeatedly deleting old works of art) backfired badly. I don't think that hoping (or threatening, depending on your point of view) that anything will come from that direction is useful or realistic.Fram (talk) 11:04, 28 October 2014 (UTC)
Can't argue with that Fram. In that case I guess we should pray that some sort of community led reform finally takes place. FeydHuxtable (talk) 11:21, 28 October 2014 (UTC)

Has WP:NOTVOTE been revoked, then? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:30, 28 October 2014 (UTC)

Nothing here is intended to violate NotVote. It's suggested the initial decision process include an element of voting as per common practice. We'd put a request for a crat to close on their notice board once the discussions end is approaching, and they would very likely close based on strength on argument, not purely a vote count.FeydHuxtable (talk) 13:54, 28 October 2014 (UTC)

Just wanted to note that I'm changing the header of the whole section, so that it can be linked properly from {{Cent}}. For whatever reason, headers with question marks don't seem to work properly. Nyttend (talk) 12:39, 28 October 2014 (UTC)

I'm beginning to take a good deal of interest in the RfX processes, and you can guarantee my participation in the discussions and the RfC pertaining to these proposals. I have a few comments, though.

  • Like Yunshui, I at least suggest that you come with some proposals as to what might replace RfA. It doesn't have to be a rock-solid plan just yet, but at least an idea. If you want, I might be able to present an idea or two.
  • If this proposal succeeds, RfA will be abolished. If the new system results in more admins being promoted, we'll start needing more 'crats. RfB is especially selective in the ones it promotes, and with some of our older 'crats retiring and going inactive, we'll need more. Have you thought about RfB reform, as well?
  • In any new system, one thing I'm really hoping for is that all candidates will be appreciated for their area of specialty. In the current RfA system, the fact of the matter is that it's near impossible to please the !voters unless you perfectly balance everything (with no mistakes). If you specialize in content, they'll say you don't have enough experience in "backstage" work. If you specialize in "backstage" work (like anti-vandalism, which is what my specialty is), they'll say you don't have enough content creation. Do have any ideas as to how this could be avoided in a future system? (Assuming, of course, that this proposal succeeds.)

Best regards, --Biblioworm 15:47, 28 October 2014 (UTC)

Couldn't agree more that it would be good to promote more specialist admins, and did hint at this above. There's almost no chance the community will settle on my ideal RfA, but to outline for you, it would be a quarterly Arbcom style election with non public votes, and a briefer period of questions before hand. There would be 3 or more tranches, say 15 places for generalists, 15 for veteran content writers, and 20 for backstage Gnomes & Vandal fighers, who would not have to have experience in content creation or XfD. I like GraniteSand's idea too.
It might be preferable to postpone detailed discussion of RfB reform until after the new RfA process is decided upon. Possibly RfB would not need to be changed. It could be crats would play a somewhat different role in the new RfA. Thanks Biblioworm for your thoughts, and if you wanted to outline your ideas for possible new RfA processes that would be great. FeydHuxtable (talk) 16:15, 28 October 2014 (UTC)
Thanks for your reply. I was just thinking about the election system you suggested, and I have a question. If a person were elected under a specific section, would they be forced to stay in that one area of work for the entirety of their adminship, or would they be permitted to branch out into other areas as they gain experience? (For example, let's say that a vandal fighter wanted to get involved with XfDs.) --Biblioworm 17:02, 28 October 2014 (UTC)
You're welcome. IMO, it would be fine as long as they branched out cautiously. I don't think this would need to be formalized, but if they rushed into a new area making bold decisions left right and center, they'd be signing a warrant for their own desysop. FeydHuxtable (talk) 18:11, 28 October 2014 (UTC)
After asking my questions, I've pretty much formulated my opinion. While I'm completely on board with the overall idea of a new system, I think it's quite realistic to say that this RfC will fail unless you present a good idea of what might replace the current system. So, I'd recommend postponing this RfC and opening a separate thread to discuss alternative methods for promoting new admins. Thanks, --Biblioworm 20:47, 28 October 2014 (UTC)
Thanks Biblioworm. That's probably good advise. Im not going to make that change, as I agree with SMarshal and others that there's been too many such attempts in the past. Literally thousands of editor hours have been lost in the time sync of trying to agree on a new RfA process, only for us to default back to the increasingly broken existing system. As I keep saying though, if someone else wants to change the initial vote motion so that we simply vote to agree the current systems needs replacing and then move on discussing a new system, Id not object. FeydHuxtable (talk) 22:04, 28 October 2014 (UTC)
  • People have been complaining about RFA since 2006 when I started, so the idea that people are still complaining the in face of a few failed RFAs isn't shocking. As Fram said, replace it with what, exactly? This looks like a vote against RFA, not a vote for anything. And I haven't seen real proof that the lack of people running at RFA is due to the RFA process itself. I've made a number of nominations for admin, and have talked to many, many editors about a possible run. No one loves the process, but it isn't the only or main reason they don't run. There simply isn't any convincing evidence that the RFA process is the reason we have so few running for admin. I don't care what process we use to promote admin as long as it is consensus based, but I don't see an actual proposal here. What I see is a proposal to end a system that at least works, for something that hasn't been determined, because it is the problem, even though that hasn't been proven, or even substantiated. Dennis - 17:25, 28 October 2014 (UTC)
I think there is proof that people are not running because of the process itself. At the recent discussion at AN, many veteran editors stated that they would not run because of the "character assassinations" and "the toxic atmosphere". Even more, some good editors who have gone through RfA and failed have said that they will never go through another RfA again, for the same reasons mentioned above. --Biblioworm 17:56, 28 October 2014 (UTC)
Have to agree with Biblioworm here. Dennis, maybe for whatever reason you have a bias to talk to folk who don't want further responsibility, and that's why you get the answers you do. For the vast majority of prospective admins, the hostility and randomness of the process is the sole reason they don't want to run. Non anecdotal evidence of this has been posted several times. If you don't want to be convinced you won't be convinced. But in the words of Henry Kissenger "Only very strong [or insensitive] personalities are able to resist the digitally aggregated and magnified unfavorable judgments of their peers." And when someone like Kissenger says 'very strong' , he's talking about a very exceptional person indeed. Huh, many of those declining to run for RfA may be strong enough to have a DGAF attitude, but still decline as they see the current process as a waste of time. FeydHuxtable (talk) 18:11, 28 October 2014 (UTC)
FWIW I agree with Dennis and came here to say as much. The process itself has remained essentially unchanged for a long time yet the number of successes decrease year-on-year… It's hard to reconcile those two facts with the idea that the RfA process is the one key we should focus on for healthier admin recruitment. benmoore 20:41, 28 October 2014 (UTC)
Plus the excuse "I don't want to go through RFA" is easy to throw out, even if it is only part of the reason someone is afraid. That could also mean "I'm afraid I wouldn't pass at RFA", and isn't always a damning statement on the process itself. The process isn't perfect, I'm not here to defend it, I'm just saying you have to understand human psychology a bit when looking at what is being said. Plus, being afraid of a process doesn't mean it is broken. So before we throw this baby out with the bathwater, tell us what BETTER idea you have to replace it. If you don't have something better, then this is academic and a waste of time to discuss. Dennis - 21:27, 28 October 2014 (UTC)
I strongly object to the ultrashort period for voting on such an important proposal. The process as proposed lacks consensus. Maybe it is this proposal which should be marked as "Failed" and "Historical." If it is to go forward, then at least run it for 30 days, so that all who might be interested in the issue have an opportunity to learn about it and register their views. If the proposer of some such radical change on his own initiative can specify 5 days, then what would would prevent him from specifying 1 day or 1 hour, so that a few like-minded individuals could rush in and endorse the desired outcome, when in fact it represented a view held by only a very small portion of the community of editors? I agree that RFA is too often an abusive process of character assassination, wherein a few cranky editors seek to settle old scores by dragging up the candidate's worst couple of edits, and argue that we mustn't give the tools to such a horrible editor, while ignoring the other 99.99% of their excellent work on the project. I also strongly disagree with ending the old process and banning anything like it ever being reinstated. Perhaps after due deliberation, nothing better is found, so the community will decide on some improved version of the present RFA, such as a term limit with a renewal vote after a year or two, making it less of a big deal. Instead, propose a better process, and make a smooth transition. We could be stuck in limbo indefinitely with no way of authorizing new admins. This proposal is like burning the bridges behind our army so that they will win a victory rather than retreating. This has sometimes ended badly. It is like feeling that one should get a better paying job than his present crummy one, so he up and quits, in the belief that only thus will he be motivated to apply for and get a better job. This also could end badly. What about Wikipedias in other language communities? What about other online communities? Have any of them come up with a better process for creating admins? Edison (talk) 17:33, 28 October 2014 (UTC)
I thought the suggestion to end the current process first was a stroke of visionary genius. But many others feel as you do; perhaps it's just too innovative. The other language Wikipedias mostly follow our lead in these matters, AFAIK. I think we have to seek our own salvation. If you wanted to amend the above timeline, (or even mark the whole thing as failed as long as you present an alternative reform approach) then no objection from me. FeydHuxtable (talk) 18:11, 28 October 2014 (UTC)
The OP has it right, RfA serves no useful purpose beyond promoting those who should have become admin long ago. And the replacement is quite obvious to me, it is WP:RFPERM. That's exactly the venue where I would request permissions that might come handy and are no big deal. All we need is a The Lord giveth, the Lord taketh away procedure which would mean gathering stewards to watchlist RFPERM. --Pgallert (talk) 19:49, 28 October 2014 (UTC)
Added after User:S Marshall's +1: Not sure how RFPERM rights are generally removed, all I remember is AN/I threads. What I meant was, we would need bureaucrats to watch RFPERM to actually grant admin rights, and stewards to watch whatever forum of admin misconduct to take the bits off if necessary. What we would also need is a rule like 'Don't take away a right that has never been abused, and do take it away if it was.' --Pgallert (talk) 20:13, 28 October 2014 (UTC)
If by an RFPERM process you mean that someone (presumably a bureaucrat) checks length of service, block log and edit count against some checklist, I don't think that is nearly adequate. We all know people with a long editing history who would be temperamentally quite unsuitable to be admins. If you mean approval after the sort of investigation of the candidate's editing history, interactions with others, and contributions to discussions like AfD and ANI which RFA voters undertake, that is a heavy responsibility for a single bureaucrat to take. Also, RFA allows non-admins a voice: there are already some who complain that existing admins make promotion difficult so as to maintain their grip on power, and selection by bureaucrat would only add to suspicions of a self-perpetuating elite. JohnCD (talk) 16:58, 29 October 2014 (UTC)
  • I agree with Pgallert. If we intend to fix RfA we have to kill the current process first. Trying to find a solution without killing the current process first has failed many times before, and it's certain to fail again. We should start with the thing that most editors will agree on: that RfA is broken. Once we've marked it historical, a new method or combination of methods will appear. If we don't mark it historical then there will be no change.—S Marshall T/C 19:54, 28 October 2014 (UTC)
It Seems to me that most people who don't want to run for RFA don't want to run because of how ugly they can turn and how fast it can happen. To be honest, and maybe I'm just short sighted here, I don't see a new system that would prevent that. Even if the consensus is to shut down RFA, which I personally am on the fence about. What would the replacement be? What would happen to current admins who went through RFA? Would that system still be honored even after the death of the thing that gave them their mop? Forgive me for rambling, I just have a lot of thoughts on this and I'm not sure how to formulate them out.--Church Talk 20:27, 28 October 2014 (UTC)
You're probably right there would always be some potential for an unpleasant experience. But we should be able to make that much less likely, for example by replacing the current process with an Arb style election. Nothing at all would happen to existing admins. If anything, a few might see old school admins as having a slightly higher status than those who pass with the new and easier process, but the distinction would fade in time. FeydHuxtable (talk) 20:57, 28 October 2014 (UTC)
Just out of curiosity: why do you think an ArbCom style election would be better than the one we have right now? --Biblioworm 21:08, 28 October 2014 (UTC)
Three reasons. 1) in past RfAs most hurtful remarks seem to have been made in the oppose vote comments. If we had non public votes or at least comment-less votes, that would cut of that form of attack. (There would still be a risk of attacks in the question phase, which btw would probably be more light weight than an existing arb election. As it would be a new process, we could maybe introduce more effective clerking to prevent loaded questions etc.) 2) The much lower pass threshold would help increase the promotion rate, and also any flak the candidates take would be easier to shrug off it it's not coupled with formal rejection. 3) We could have tranches for specialist admins. FeydHuxtable (talk) 22:04, 28 October 2014 (UTC)
The answer is going to depend one exactly what you mean by "ArbCom-style elections". If you mean "secret votes", then eliminating the ability to post comments about why you vote against someone would reduce some of the nastiness that keeps candidates away. Alternatively, if by "ArbCom-style" you mean getting a bunch of candidates and taking the top 10 vote-getters (where "10" is however many we think we need to elect during the next X months), then it's possible that more people would be willing to run because losing wouldn't be so personal. You wouldn't lose because you personally were horrible; you would only lose because you happened to run when 10 even better people did. WhatamIdoing (talk) 22:17, 28 October 2014 (UTC)
At the same time though, most people would probably also be curious of what they could do better. I know during my RFA's many years ago I got a lot of good advice from my opposes that I took to heart. I agree that some of the nastiness needs to be kept away, but I think a new system should also allow the "candidate" (so to speak if that's how it happens) to know how they can improve and give them something to work forward if they don't happen to get the bid. Reading more of the discussion I'm starting to lean towards maybe splitting some of the tools.--Church Talk 22:42, 28 October 2014 (UTC)
While not a bad idea, proposals to unbundle the admin tools have always failed. I think one major issue is that the WMF has made it clear that any person with access to deleted material (and admins, of course, can access deleted material), must have gone through thorough community scrutiny. Really, I don't think any unbundling proposals will ever succeed (just my opinion, of course).
Church does make a good point. It can be good to see why people !voted against you, so that you can work on those issues and improve next time around. As of now, however, the ability to freely (and publicly) voice your opinion on a candidate is being abused, as a person can make an editor look terrible by picking out a diff or two and saying, "Look! He made a mistake/got angry/etc.! He'll surely misuse the admin tools, so I oppose." (Of course, any human occasionally makes mistakes and gets angry.) I think a good solution (assuming that we adopt the ArbCom style election) would be to give !voters a place to make an optional comment when casting their !vote (while making it very clear that the comment should be reasonable and professional), and when the elections are all said and done, the comments could be sent to the candidate so they would have a chance to look over them. --Biblioworm 23:24, 28 October 2014 (UTC)
Proposals to unbundle admin tools have not always failed. Rollback used to be admin-only. WhatamIdoing (talk) 02:02, 29 October 2014 (UTC)
That is true, but I'm talking more about the "bigger" tools like blocking, protection, deletion, etc. --Biblioworm 02:34, 29 October 2014 (UTC)
The question is what would be unbundled and what would be the deciding factor for who gets what tool? Some people may request the ability to block others to help out at AIV or one of the other boards but may not be trusted to delete articles. The problem is that all of these tools would require significant trust from the community which is what RFA was supposed to determine if there was. --Church Talk 02:22, 29 October 2014 (UTC)
  • Let's get this right: to solve the problem of not having enough admins you want to prevent any more admins from being created? And this on the very uncertain assumption that the community will agree on a replacement? I could spend time to argue the wider points others have mentioned, but I don't have it right now. If you have a good idea for RfA reform, propose it and see what we think. Otherwise, we need some process for this, faulty as it may or may not be. BethNaught (talk) 23:16, 28 October 2014 (UTC)

I am highly sympathetic to the theory that nothing new will arise, nothing will get better, until we kill the existing process. --j⚛e deckertalk 02:21, 29 October 2014 (UTC)

What happens if we do decide to kill RFA and then no consensus can be reached in it's replacement? What would we do then?--Church Talk 02:23, 29 October 2014 (UTC)
I suppose that would mean we would be forced to re-institute the old process. --Biblioworm 02:34, 29 October 2014 (UTC)
I do not believe the community will long tolerate a process that does not allow for new admins, and I would hope consensus in the new process would be developed in a process that started from "We have to do something, which is better, something like X, or something like Y, or something like Z", and recurse into specifics. It'll take a little time, but I'm confident we'll have a lot of motivation to settle on a mechanism. --j⚛e deckertalk 02:42, 29 October 2014 (UTC)
I think you over prescribe the community's sense of urgency. That same community, myself included, is far more concerned about limiting the active damage of bad admins than it is about the procedural decay of being understaffed. GraniteSand (talk) 09:28, 29 October 2014 (UTC)
RfA application progression (pie chart).png
RfA application progression (projected until 2015).png
Percent of successful RfAs (projected through 2020).png
It's clear to me that not only is the current system not working, but it's driving away users and people are refusing to even run because it is so broken. We need to get rid of this system driving users away... Simple. — {{U|Technical 13}} (etc) 14:18, 30 October 2014 (UTC)
Active administrators on May 12: 592.
Active administrators on July 2: 590.
Active administrators on October 30: 591. Dekimasuよ! 21:03, 30 October 2014 (UTC)

The case for retention[edit]

OK, let's try to assemble a case for retaining the current RfA system. (1) It's what we're all used to, (2) we know WMF are OK with it, (3) any shortcomings could be addressed by reforms, not wholesale abolition: Noyster (talk), 10:18, 28 October 2014 (UTC)

It is (4) based on consensus, which is how most potentially controversial decisions are made around here. (5) It gives everyone a chance to express their opinion. Graeme Bartlett (talk) 11:25, 28 October 2014 (UTC)
  • It isn't based on consensus. It's a popularity vote, with there only being a small margin within which bureaucrats exercise some decision making. Any stretch beyond that becomes instantly controversial. --Hammersoft (talk) 13:34, 28 October 2014 (UTC)
I disagree; it is based on consensus; the fact that, in this one case, well over two thirds of participants need to agree on a course of action for it to be taken does not deny that it is still a consensual issue. As for calling it a popularity vote, i'm inclined to assume that the majority of !voters at RfA have given some thought to the candidate and are not simply voting based on whether they like him or not. I may be naïve and forgetful, but i do not remember seeing a lot of comments/!votes i'm not willing to make that assumption about. Cheers, LindsayHello 14:46, 28 October 2014 (UTC)
And (6) it has proven in practice to be more or less effective in eliminating bad candidates for Administrator. That is, potential bad actors are not gaining tools, they are being weeded out. Carrite (talk) 11:03, 29 October 2014 (UTC)
Until the replacement is agreed to and has the blessing of WMF I do not endorse any process that closes down the current regime for promoting Admins. Closing down the current shop and then holding us hostage to come up with a new process is dangerous and only going to cause more stress for the already stressed admin corps. Hasteur (talk) 16:31, 28 October 2014 (UTC)
  • I don't think the WMF is going to bless any process. They do not get involved here. So in effect, they hold us hostage in reverse. --Hammersoft (talk) 20:33, 28 October 2014 (UTC)
  • Personal hat on: yes, they do. RfA is a process LCA are likely to care about, given the implications it has for accessing deleted content. There have been discussions around granting OS permissions to non-admins in the past that made this clear. Ironholds (talk) 20:36, 28 October 2014 (UTC)
@Ironholds From remembering what Sue had to say on deletion matters when we met her at the Pendell arms back in 2010, and from Phillipe's post ...any permission which includes the ability to view deleted content must be identical in style and substance to the RFA process of the time. As long as that requirement is met, we're unlikely to object... I'd have agreed with Hammersoft that there would be no risk of WMF vetoing a community led change as long as the new process retains at least some element of vetting. As staff you'd know better than me. If you're saying it would be advisable to seek pre approval from WMF for any replacement before proceeding, I think we ought to close this thread right now, so as to avoid wasting community time. FeydHuxtable (talk) 20:57, 28 October 2014 (UTC)
I'm a research-monkey, not a lawyer ;p. I think you should certainly throw the idea off Maggie or James or Philippe just to ascertain what vetting they'd require, as due dilligence. I'm not qualified to say if it'd be pre-approval or post-approval or..what. Ironholds (talk) 21:09, 28 October 2014 (UTC)
Ta. I have some experience with lawyer speak, and Im not going to ask at this stage as it wouldn't feel respectful of their time. If we pass the initial motion to mark current RfA as historical, that would be the point when I'd ask Philippe. I've a feeling they might unfortunately rule out Pgallert's suggestion of WP:RFPERM due to insufficient vetting, but I'd eat my hat if they vetoed most other alternatives. FeydHuxtable (talk) 22:04, 28 October 2014 (UTC)
Even on RFPERM any particular thing to look for in future admins could be documented and implemented. After all, only the 'crats can hand out this permission. They are so few they could be informed by personal messages ;) Pgallert (talk) 05:35, 29 October 2014 (UTC)
Noyster and Graeme Bartlett have it right. Adminship will continue to be a big deal until desysopping gets easier. Only the draconian RfA process currently in place gives me a reasonable belief that the candidates can be minimally trusted. Chris Troutman (talk) 00:35, 29 October 2014 (UTC)
I can't really argue with that logic either. I'd give up half the active admins we have from the promiscuous days of '05-'07 for a quarter of their number in contemporary peers. Bad, entrenched admins have left such a nasty taste in people's mouths that RfAs have become something resembling a security clearance investigation. GraniteSand (talk) 09:25, 29 October 2014 (UTC)
I agree that part of the reason the present system is draconian is that we are creating a life tenure for the new admin, unless his behavior is so egregious that there must be a de-sysopping. One solution is to have an easy-peasy process for desysopping, but that would allow some abusive group who were dedicated fans of some fringe theory, some proud nation, some walled-garden subject, some hobby or some religion to eliminate any admin who follows Wikipedia guidelines and policies and gets in their way of creating vanispamcruftisements or of slanting articles to suit them. We would just have to make sure that a broad enough portion of the community participated in any recall election to keep in place good admins who had stepped on the toes of bullying publicists, nationalists, partisans or loons. I've also suggested having the election to adminship be for a set term such as one or 2 years. That said having 500 or 1000 discussions and votes a year would be tedious and it would be hard to get enough eyes on each one to prevent some entrenched group from block-voting out those those get in their way, or to prevent machine politics from backing offline a slate of amenable admins. The present system does seem to get a number of editors to look at each candidate. Unfortunately some cranky editors seem overrepresented and spend too much time opposing RFA candidates than contributing otherwise to the project. In summary, I suggest keep something like the present RFA, but somehow improve the level of discourse, as well as making it easier to desysop those who turn out not to be good admins. There are probably cases where an editor walks on eggs to avoid controversy and build up unobjectionable edits until get gets the bit, then lets his true feelings become clear and acts harshly toward others. Edison (talk)

The "system" is fine, we're just using it wrong. Take a look at how other projects do it - this Wikinews "requests for permissions" archive is a great example. The system they have is the same as ours, they just don't go in for the full scale interrogation of every candidate. That's what we need to change. When there's an RfA the question we have to answer is simple: can/do I trust this editor? We should do so on an WP:AGF basis; not assume there's some dirt to dig up on them and bombard them with questions until it comes out. Frankly it's the attitude of the community of editors that frequent RfA that needs to change, not the methodology itself. WaggersTALK 12:09, 29 October 2014 (UTC)

Cast a wider net[edit]

One thing that might help is to cast a wider net. Some people watch RfAs, some just coincidentally notice an editor they know is running, and apparently there are allegations of off-wiki canvassing, which only brings in the negatives. With the current load, we could put a notice on people's watchlist, which would bring in more editors who have had positive relations with the candidate, and increase the amount of qualified admins passing. Oiyarbepsy (talk) 21:02, 28 October 2014 (UTC)

Not a bad thought, although notification fatigue could set in, especially with the NOTNOWs gumming up serious candidacies. As it stands, participation isn't broad and is prone to serious selection bias. Alternately, but along the same vein, we could accept and list nominations all month long and then have a set period of every month when active questions with the candidate and !voting is accepted. This would expand exposure, allow for persistent banner notifications (it's RfA time!) as well as allow for people to assemble their thoughts on candidates and perform coaching in the Talk space without votes dragging out. Something like the last five days of every month? The last ten days of every quarter? GraniteSand (talk) 21:58, 28 October 2014 (UTC)
Alternatively, add the notice only if 24 hours have passed since the beginning of the RfA. This weeds out most NOTNOWs. -- King of ♠ 00:36, 29 October 2014 (UTC)
Participation isn't broad, but I don't remember the last time I saw someone post a note saying "So-and-so is at RFA now" (e.g., at a WikiProject or project page) without promptly being accused of canvassing. I eventually concluded that only people who had no idea who the candidate was were welcome to respond. If you want to bring in more voters, then you have to find ways of letting them find out about it. WhatamIdoing (talk) 02:07, 29 October 2014 (UTC)
I think a yellow top banner used by the WMF for project-wide announcements would be perfect. GraniteSand (talk) 02:53, 29 October 2014 (UTC)
Wouldn't that be seen by EVERYONE on Wikipedia? Including the readers who don't care at all who admins this site or not? To me, if I didn't know or care anything about Wikipedia I wouldn't want to see a notification about it.--Church Talk 03:19, 29 October 2014 (UTC)
Yes. We're talking about a "crisis" here, right? Staffing the project with an adequate number of competent administrators is essential to the functioning of the project. Furthermore, admins affect everyone who edits here, one way or another. Much like fundraising or ArbCom elections or meetups, if editors choose not to acknowledge the broad call to participation then so be it, that's up to them. The imposition of passive notification is not arduous or unreasonable if conducted five out of every 30 days or 10 out of every 90. GraniteSand (talk) 03:28, 29 October 2014 (UTC)

Since I started this...[edit]

I'm the editor Feyd cited as proposing to close RFA. I stand behind the idea. The current RFA system is laugh-out-loud stupid -- the population of potential admins has voted with its feet to verify that -- and there are many potential alternatives. But those alternatives will only be seriously considered by this shortsighted community if the current system closes. As long as the current system exists, our resident process wonks will insist everything is fine because the project hasn't exploded yet. Keep defending RFA, and it may well be the hill this project dies on. Townlake (talk) 02:38, 29 October 2014 (UTC)

Why not? I say it's worth a shot. If things don't go so well, we can always revive what we currently have until another solution can be found.

Yes, the reason RfA is so difficult to pass is the fact that editors are held to an unrealistically high standard; they are expected to be well-rounded and have a breadth of experience in their professed areas of interest, as opposed to a demonstrated knowledge of how processes work and a willingness to think things through before acting. In my book, qualifications are far more important than credentials when assessing potential administrators. I also think that we should try to distance ourselves from this trend towards rejecting specialist administrators, or those that only wish to use the tools on a limited basis.

So how would an altogether different community process produce different results? In theory, it wouldn't. And in theory, a light object in free fall would descend at a slower pace than a heavier object. It wasn't until someone (often believed to be Galileo, but it probably wasn't) tested this hypothesis by dropping two objects of different masses in a controlled setting that this long-held belief was ultimately disproved; barring other factors (such as air resistance), acceleration due to gravity on Earth remains pretty much the same. It is always going to be roughly 9.81 m/s2. This person's experiment meant that we had to change the way we looked at gravity. These observations were made from a different perspective, and the results deviated from conventional thought. Perhaps an alternative to the current RfA process will actually bring about a change in community perspective; then again, it may not. But unless it is tried, we'll never know for sure. Kurtis (talk) 04:45, 29 October 2014 (UTC)

  • The problem I keep pointing out is simple: you can't get rid of the existing system until you have a replacement, or you make the problem worse. If you ditch the existing system, NO ONE can run for admin until a new system is put in place. That could take weeks or months, and if the Foundation comes in and says the new system is inadequate (and they do have a vested interest in whether or not the system properly vets or not), then you start over. You effectively prevent anyone from becoming an admin for a while. Resorting to ad hominem and calling people wonks and such isn't helpful or persuasive. Many of us are already on the record being critical of the system, and here with open minds about a replacement, but if there is a better way to do RFA, show us before you kill off the only avenue we have for appointing new admin. Saying "kill it and we will figure out a better system later" is a very weak argument, particularly since people have been barking up that tree for years and no one has come up with a better way that the community agrees on. And if the current RFA system is the silver bullet that kills this project, then it needed to be put out of its misery anyway. That whole statement is nothing but hyperbole, which really doesn't add to the discussion. Dennis - 13:49, 29 October 2014 (UTC)
    "You effectively prevent anyone from becoming an admin for a while" - That would only be marginally worse than the current system, which has promoted only 2 admins in the last 4 months. Mr.Z-man 14:56, 29 October 2014 (UTC)
    Dennis cheerfully ignores the reality that years of efforts to fix the current system have yielded absolutely nothing. I'm trying to address the real problem; whether he realizes it or not, Dennis is falling back on the tired old defenses of the current system that are preventing this community from actually addressing the problem.
    Folks, if NO RFA system is in place, or an unpalatable system is used in the interim (e.g. let the bureaucrats handle all RFA permissions), then the community will feel a sense of urgency to rebuild the RFA permissions system in a better way. Townlake (talk) 15:44, 29 October 2014 (UTC)
    That is a bit rude, and you are reading things into my statements that aren't there. I've spent years trying to get changes in the RFA (easy to find the diffs if you check the RFA talk page). I've actually been through a particularly nasty and drama filled RFA (134/31/2) that had blocks, bad math, and bad faith, so its safe to say I actually know what it feels like, so the problems aren't just theoretical perceptions for me, they are actual experience. All I've said is "what do you have?" I've offered my ideas over the last few years, and even down below. You haven't offered an alternative, I have. So the phrase "put up or shut up" comes to mind, what do you have that is BETTER than what we have? Seriously, unless you have a replacement in mind or some basic idea, talking about removing the current system is just silly. Dennis - 18:46, 29 October 2014 (UTC)
    Two years ago I was indefinitely topic banned by Arbcom from "making edits concerning the RFA process anywhere on the English Wikipedia." That tells me all I need to know about the viability of this proposal. Eric Corbett 19:08, 29 October 2014 (UTC)
    Dennis, what you call "silly" seems to be getting some serious traction here. I can offer you a hug if that will spare your feelings; otherwise you should stand aside. Your. Way. Failed. Townlake (talk) 19:58, 29 October 2014 (UTC)
His way may have failed, but I haven't seen anything from this discussion that points to any other method of appointing administrators gaining steam. Tone it down a little bit, we don't need tempers getting heated before the vote starts. Hell, we don't need it at all.--Church Talk 20:04, 29 October 2014 (UTC)
Thanks for the reminder Church. Dennis is a longtime contributor to this project and I respect him. I think he's a grownup and can understand that we're just speaking frankly here. He clearly has a particular point of view on this, mine is a polar opposite, and we both are taking this seriously. Townlake (talk) 20:14, 29 October 2014 (UTC)
@ Dennis. We're not offering a specific solution as we don't have one we know would be broadly acceptable. What we are offering is what we consider to be a close to infallible method to agree on something better. (Possibly the first new method we decide on would not be better in practice, but then we just need to use this same method again to replace it.) We're saying have faith in the community's ability for positive change. I've gave it my best shot at explaining this in the 'No safe option' section below.
@ Eric. I'd not normally take the liberty, but as you're here, my opinion is that it's bizarre to the point of perversity that an editor who's done as much for the project as you - in article writing, helping others to write, and (mostly) being friendly - hasn't been given adminship. Maybe you'd unblock a few friends, but you'd not be the sort to use tools to block an opponent or delete their article. On the other hand, I also think anyone using the C word should trigger an automatic desysop and 4 week block. FeydHuxtable (talk) 20:26, 29 October 2014 (UTC)
Perhaps you're an American? For myself, I don't see this C word as being any worse than many others, but if you feel like agitating for a change in the rules about what words can and can't be used on WP then feel free to do so. I'm much more enraged by being accused of being married to another editor I've never met simply because we both belong to the same WikiProject, as that has real-life implications. But this is of course an unnecessary digression. Eric Corbett 20:48, 29 October 2014 (UTC)
Im English 'till I die! Myself and the Colonel (also very British) tried to push for a change back in the great civ case of 2012. Probably a lost cause. I agree accusations that might afffect real life relationships are worse. FeydHuxtable (talk) 21:08, 29 October 2014 (UTC)
But you don't get blocked for them, you get blocked for using the C word. Anyway, I'm probably already stretching my ArbCom topic ban to the limit so I'll say no more. Eric Corbett 21:28, 29 October 2014 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────Speaking in general and not just this RFA concept, my experience has been that nothing ever gets done because there is always a group that wants EVERYTHING changed, and when someone supports an incremental change towards their goal, they flip out. "All or nothing" is their mantra, and they get exactly that: nothing. I'm an incrementalist, willing to accept small steps in the right direction to test out ideas, where the risk is lower and the rewards are delayed but more likely. You might think you are getting traction, but wait til the voting starts. Even if the community voted RFA out, WMF wouldn't allow that. I would rather try to find common ground and a partial solution that will do some good, than talk in circles and a month later, not a damn thing is different. This IS a perennial proposal because people try to do too much at once and are usually ill prepared to answer the tough questions. RFA has problems, yet I've still managed to push 6 candidates through as nom or conom and about to nom at least one more this year. But I do a lot of homework and vet them myself. [12] Not all the problems are the RFA system, which is why I say come minor tweaks might be a good place to start. If that doesn't work, try something bigger. Dennis - 21:49, 29 October 2014 (UTC)

I like gradual changes too, but again this has been tried before. Dozens of minor changes are on offer at this page alone , some as minor as ending the use of 'weak' and 'strong' support. AFAIK only one of these ideas got consensus (albeit informal) on RfA talk itself. This was for clerking. MBizance himself tried to put this into practice, redacting overly harsh votes. Despite the previous apparent consensus, he soon got push back, including from a fellow crat, and the system went back to character assassination as normal. The existing RfA is like something out of a horror film. It can't be changed. Kill it! FeydHuxtable (talk) 22:32, 29 October 2014 (UTC)

How about tweaking the current system?[edit]

I doubt abolition with no replacement is going to pass, nor should it. It seems to me that tweaks to the current system have a better probability of success. For example: (1) Reducing the super-majority needed for approval from 70% to 60%; (2) Changing the basic questions asked from 3 bland ones to a dozen better ones and segregating unique questions to a lower visibility area of the page; (3) Making Adminiship a 2 step process with a 12 month probationary period followed by a reconfirmation vote rather than instant granting of a lifetime term; (4) Creation of a process making recall of bad Admins easier. Make no mistake, WMF is going to meddle with this process and even in the unlikely scenario in which RFA is abolished with no replacement, coming up with a new system which not only meets community muster but WMF's legal concerns is unlikely. Carrite (talk) 11:13, 29 October 2014 (UTC)

  • Rearranging the deck chairs on the Titanic.—S Marshall T/C 12:08, 29 October 2014 (UTC)
    • "Destroy RFA and then something better will be devised" is like scuttling all the lifeboats on the Titanic so that the crew and passengers will be motivated to devise a way to keep the ship from sinking. I agree with Carrite on a 12 month probie adminship with a review/confirmation. Edison (talk) 15:09, 29 October 2014 (UTC)
I agree with Carrite. We should ask the WMF now what their requirements are, rather than work something out and then have a battle with them. I like the 12-month reconfirmation idea for new admins; or, in default of an easier desysop process, three-year reconfirmation RFAs for all could become feasible as the number of admins falls. There would be several per week, but with a lighter-touch process that would be manageable.
My suggestion for improvement would be to disallow threaded exchanges, where most of the venom turns up. At least one person is already banned from threaded exchanges at RFA, while still allowed to vote, for this reason. Each opposer (or supporter) gives their reason; the candidate may reply if s/he chooses; that's it.
It would be possible to show only the totals, hide the comments and communicate them to the candidate privately. That could help to avoid pile-ons, but I don't like the loss of openness. While I don't say hostile comment during RFA is a good thing, anyone unwilling to face it is unlikely to be an effective admin, which can bring much worse abuse. JohnCD (talk) 12:46, 29 October 2014 (UTC)
Sorry if Im reading this wrong, but it's almost like some think our relationship with WMF is adversarial. I can see there is some reason for this, but IMO at least, WMF absolutely want to have a friendly and collaborative relationship with the community. In specific cases where their objectives are opposed by a significant portion of the editors, there is always a risk of friction. But as long as our objectives are aligned, as Im sure they would be in terms of having a functional RfA, there's no reason to think they'll make things difficult for us. However, as several much more experienced editors seem to think differently, I've asked Philippe, and if he responds just on his talk page, I'll cross post here. FeydHuxtable (talk) 14:37, 29 October 2014 (UTC)
Perhaps I phrased that badly, but RFC result versus what WMF will allow has been a sensitive issue lately. What I meant was, we know that WMF Legal have concerns about the selection/vetting process for people able to see deleted content which may include BLP violations; therefore we should understand their concerns and take them into account when devising a new system, rather than agree on something and then find it is unacceptable and have to go back to the drawing board. It will be hard enough to reach agreement once. JohnCD (talk) 16:11, 29 October 2014 (UTC)
Understood. Hopefully Phillip will clarify for us soon. FeydHuxtable (talk) 20:26, 29 October 2014 (UTC)
  • I've always thought you limit the support/oppose/neutral vote to around 50 words (or a different number, and diffs count at 0 words), no threads, and move the threaded discussion to the bottom below Neutral. This lets each !voter give a reason for their vote, allows passersby to view the rationales, you still have the discussion about being fit on the front page, but it prevents the threads from drowning out the big picture. Crats should consider the entire front page, including threads at the bottom. This is a tiny tweak, but I think it is a safe tweak to start with and might reduce a little drama, as the reward for the drama is less, the impact is less. We need to do small things first. The basic layout isn't the problem, but allowing threads up top gives drama mongers a perfect stage to beat their drum. Currently, we don't even USE the "discussion" area very often (which is currently above the voting), except for procedural notes, it all gets jammed into the polling, which is the problem. Dennis - 13:57, 29 October 2014 (UTC)
  • "tweaks to the current system have a better probability of success" - As Feyd pointed out at the beginning, people have been proposing reform and tweaks for years and nothing significant has come of it. If we're considering that approach to be the most likely to succeed, we might as well just give up. Mr.Z-man 15:02, 29 October 2014 (UTC)
    If we can't agree on tweaks, what makes you think we can agree on a completely new system? Dennis - 15:04, 29 October 2014 (UTC)

Debating how to fix the current system is in the "perennial proposals" section for a reason. Suggesting modifications to the failed system already in place is a waste of time. Townlake (talk) 15:40, 29 October 2014 (UTC)

  • A 12 month "probation" would, at least for me, result in more "support" !votes than currently is the case. I'm hesitant in the current RFA for example, but would not have been in case of a probation. Making de-sysopping easier would also be a good idea, although the process would have to be designed carefully (admins tend to make enemies, no matter how careful and friendly they are...). As for the current RFA process being toxic, I disagree. This may have been the case some years ago, but in the 12 months or so that I have been following them, I find most comments constructive (there's always the odd exception, but those are generally ignored by everybody). --Randykitty (talk) 12:30, 30 October 2014 (UTC)

Alternate RfA[edit]

What about having a new process coinciding with the existing one, and allowing candidates to choose? That would allow us to close the old one if it works, or close the alternate one if it fails. Oiyarbepsy (talk) 18:19, 29 October 2014 (UTC)

To me it seems that consensus is that the old system doesn't work, which is why we're here.--Church Talk 18:31, 29 October 2014 (UTC)
On paper an excellent idea Oiyarbepsy. Jimbo Wales himself championed a possible parallel alternate RfA back in 2011. Unfortunately, is seems to have failed for the same reason all other reform attempts have. As long as the old system remains in place, there's just not sufficient impetus for consensus to cohere on any one possible alternative. FeydHuxtable (talk) 18:38, 29 October 2014 (UTC)
It looks like the !votes below that give rationale for maintaining the current one point out that they would have gone for another system if it would first exist and then removing the existing one should be debated - which is a good argument in itself. Creating a parallel process first with option to choose any would pave way for taking that out of the equation (or maybe not and the wiki can have two permanent ways). --lTopGunl (talk) 17:38, 30 October 2014 (UTC)

No Safe option[edit]

There's three broad options to the RfA problem.

Do nothing
This is essentially a choice to embark on a dangerous social experiment. There will be further concentration of power and responsibility on admins who chose to remain. The unwavering decline in active admins over the past 7 years leave no doubt this is where 'Existing RfA road' leads. To a place that seems unfair both to admins and the community. At best, conscientious and dedicated admins will put an increasingly amount time and effort into Wikipedia, neglecting their own best interests, but perhaps keeping things ticking over for another 5 years. At worse, the perceived gap between regular editors and admins will widen to a chasm. Increasingly powerful admins will be more prone to abuse and harder to desysop. Admins will have less time to make considerate decisions, and the resulting distress caused by a more hostile editing environment could take years to heal.

Attempt to agree on a replacement RfA process while leaving the existing process in place
On paper this is the obvious choice. The only problem is its been tried hundreds of times before, to no effect. Thousands of editor hours have been expended on this cause, including from some of our very brightest editors. To see evidence of this, click WP:RFA2011.

Each new attempt to decide on a new process seems not only to waste time, cause frustration, and increase reform fatigue, thus making successful reform even less likely. Einstein had a word to describe the practice of repeatedly trying the same approach and exspecting to get a different result. That word was insanity.

End the existing disused RfA process, then agree on a replacment

Cortés scuttling his own fleet so there is no going back to how things were before. He then proceeded to conquer the smallpox-crippled Aztec empire with only a few hundred men.

Several editors understandably feel ending RfA without first agreeing on its replacement is reckless. To clarify, Townlake, myself, SMarshal, Mr Z and others are not lunatics. We're trying to be realistic about the fact that historical failure to reform RfA means we're dealing with something close to mission impossible. Burning ones bridges or ships is not something one does lightly, but it does have a track record of being used to pull of close to impossible feats. The tactic's been used by the ancient Chinese and Romans even before Christ, and perhaps most famously by Cortés.

In our case, we have all the advantages this method conferred upon the Spaniard, but almost none of the risks. This is how easy it was to create an RfA process from a clean slate

It's not going to be quite as simple as it was for Camembert back in 2003. So we're proposing a more structured method. After we agree to mark the current RfA as historical, we can have a week long creative period where we build up new and existing ideas for replacement, such as a modified version of RFPERM, or Arbcom light style elections with tranches for specialists. Then a further week where we eliminate the less well supported options, until we settle on our final choice. With a well structured RfC to ensure we get a result, and with no option to return to the harmful status quo, how can this fail? FeydHuxtable (talk) 20:26, 29 October 2014 (UTC)

Proposal: administrators must be civil servants, not politicians[edit]

Moved to Wikipedia talk:Administrative standards commission Oiyarbepsy (talk) 23:13, 30 October 2014 (UTC)

The problem with RfA, as it is presently structured, is that it is based on what are essentially democratic principles. Being a Wikipedia administrator is a technocratic job. It is a job of maintenance. It is not a position of leadership, nor is it a legislative position. Democratic principles stymie and obfuscate the purpose of adminiship, and turn it into a populist post. Civil servants are properly appointed, not elected. That's the way it works in most governments, and that's how it should work here. We need to remove the democratic element, and stop this mob rule nonsense. Therefore, I'd propose the following. This is just a basic idea, sans details. A search committee is created with the sole purpose of appointing administrators. The committee is elected by the community, similarly to the present Arb Com elections. The committee would accept applications for adminship, and evaluate them based on merit. A simple majority of committee members in favour of a candidate would lead to that candidate being granted adminship. The committee would not just accept applications, but would also seek out potential candidates. This strikes me as the best way forward. Democracy is not the answer to every question. RGloucester 04:21, 30 October 2014 (UTC)
Now that I like - the first major change proposal here that I could support, though success should require more than a simple majority. Suggestions to flesh it out: number on the committee at least six, maybe ten. Once it's established, two-year terms with half retiring (but re-electable) each year, to maintain continuity. Committee's deliberations are private, but where they decline a candidate the reasons are stated publicly. JohnCD (talk) 09:19, 30 October 2014 (UTC)
I've suggested this before, in the labyrinthine by-ways of Wikipedia RFA discussions. This culture directly elects its enforcers and you don't have to be Sherlock Holmes to see why that's a problem. What we should do is elect a supervisory body ("commissioners"?) who will run our admin corps: they'll select, promote, coach, support, discipline, encourage, demote where necessary. Arbcom lose their "emergency desysop" function in this proposal, which I think is a good thing: they're already overempowered and overloaded.—S Marshall T/C 09:52, 30 October 2014 (UTC)
A system like that would have my preference, too. It saves time for the community (no need for dozens of editors going through candidate's histories) and be easier on the candidates themselves (I certainly would have gone for admin earlier under such a system). --Randykitty (talk) 12:34, 30 October 2014 (UTC)
I've proposed a variation of that idea more than once, but it hasn't received any traction. While it doesn't address all issues, I think it does address some of the important issues. My most recent post was written as a response to someone else,, I've edited slightly to write it as an essay: User:Sphilbrick/RfA reform. It short, we should start with an organized selection committee.--S Philbrick(Talk) 13:13, 30 October 2014 (UTC)
Yeah, I knew I had already seen this idea. And the problem is also that the Foundation requires vetting by the community to see deleted stuff, as it contains copyvio and other bad things. The other problem is that being on that committee to select admins, that is a LOT OF POWER, so you've made that a political position. One corrupt person there, or someone that is forcing their ideology in secret (no Christians allowed / No Republicans /No whatever) and you have a worse situation. That method is vulnerable to corruption, which would be far reaching before it was noticed. Dennis - 13:26, 30 October 2014 (UTC)
The committee members would be held to account by elections, just as arbitrators are. As suggested above, they'd be required to release a report on why a candidate was granted adminship. To be frank, I feel the fear of corruption is unwarranted. The present populist system is much more prone to "corruption by mob", than this system will be prone to "corruption by individual". Also note that there are enough members on the committee to override any one corrupt individual. RGloucester 13:32, 30 October 2014 (UTC)
This is an interesting idea and in theory I think would be better. The biggest practical problem I can foresee is in selecting the committee, in particular the risk of a shortage of good candidates. There's also the risk of giving the appearance of adminship being a "private club" if the majority (or all) of the committee members are admins. Mr.Z-man 15:58, 30 October 2014 (UTC)
I would suggest that the committee should have an equal number of seats for administrators and non-administrators, so that both sides of the coin are included. RGloucester 16:04, 30 October 2014 (UTC)
Admittedly, this is not a bad idea, and something to think about if all other alternatives fail to work. However, I'm concerned about the lack of outside participation and the extra level of bureaucracy that this would add to our already bureaucratic system. I have an idea or two concerning a new election process, but I'm not going to post them until the RfC is finished. --Biblioworm 16:27, 30 October 2014 (UTC)
Our system is one of mob rule, and it isn't working. Sysop candidates should not ever be subjected to a public humiliation, a popularity contest, or indeed any kind of mass vote. They need to be selected on merit. We need administrators with skills. We do not need political leaders who can figure out how to wheel-and-deal people into "voting" for them. There would be outside participation, that is, the committee would be elected by the community. We need a way to check the mob, and this is it. RGloucester 16:41, 30 October 2014 (UTC)
What would the requirements be to get elected into this committee? Would there be terms for committee members? How could a committee member be stripped of his membership if he started to behave unacceptably? --Biblioworm 16:53, 30 October 2014 (UTC)
  • Personally, I'd want to offer Eric Corbett one of the seats on the first commission.  :) Yes, I think there'd have to be terms for commissioners: they'd be re-elected every year or so. Unacceptable behaviour by a commissioner strikes me as an unlikely circumstance, but part of their charter might be that a commissioner could be de-appointed by simple majority vote among the other commissioners (which action would trigger a by-election for a new commissioner). Or something. The details can be sorted.—S Marshall T/C 17:14, 30 October 2014 (UTC)
I'd propose that the body we create be termed the Administrative Standards Commission. This body would consist of eight commissioners, each elected by the community for a term of one year. Election procedure would mimic the Arbitration Committee's election procedure. I would propose that four commissioners be non-administrators, whilst the other four would be administrators. As stated above, a commissioner could be removed from office by a simple majority vote amongst the other commissioners, triggering a new election. The duty of the commissioners would be as follows: to search for potential candidates for adminship, to accept applications for adminship, evaluate those applications, to appoint administrators, and to serve as a forum for the review of administrative actions. I'm not opposed to the idea of maintaining the existing RfA process as a parallel option in the interim period. RGloucester 18:41, 30 October 2014 (UTC)
This is definitely an interesting system that I would be willing to try out. My only concern would be what to do in case of ties? Say the four administrators vote for a candidate and the four non-admins don't? Is it just marked no consensus? My suggestion would be to forget the whole admin, non-admin thing and just let the entire community elect who they feel is right and have an ODD number of people (Say, 7) there to prevent that from happening. --Church Talk 18:45, 30 October 2014 (UTC)
I think it is good to ensure representation for non-administrators. We must remember that "adminship is no big deal". It has become inflated in importance in recent years, but that's not how it should be. Having non-administrator representatives will entrench the idea that adminship is no big deal, and that administrators are not "ranked" higher than anyone else. They are technocrats employed by the community to take on tasks important to the maintenance of the encyclopaedia. I wouldn't be opposed to an odd number, say the seven you proposed. In that case, I'd recommend three non-administrators and three administrators, with one slot open to anyone. RGloucester 18:52, 30 October 2014 (UTC)
I like this idea, but there should be a limit on how long anyone can serve, so that we do not get an entrenched oligarchy. I suggest a three year term, with zero or one repeat (community choice when it is set up). There would be three classes with initial elections for one, two and three year terms. If we wanted an odd number there could be 9 positions, with three new ones elected per year. There could be 5 designated nonadmin seats and 4 designated admin seats. To avoid a buddy system, nonadmins leaving the body could be excluded from running for admin for one year. Edison (talk) 19:53, 30 October 2014 (UTC)
I would not mind if all members would be non-admins, in the spirit of "no big deal". I would not even object a system where admins would be excluded, given that this committee would also deal with desysopping. The elections would ensure that non-qualified people (e.g. somebody who just joined with 300 edits and such) would not get a seat. --Randykitty (talk) 19:57, 30 October 2014 (UTC)
I don't think excluding admins entirely would be a good idea. The main job of the board is choosing people to be admins, desysopping will hopefully be a much smaller task (if not, then they're probably doing their first job poorly). It makes sense to have some people who actually know what being an admin entails. Not having any admins would be like having a medical board with no doctors on it. Mr.Z-man 20:18, 30 October 2014 (UTC)
  • Why 4/4 or 3/3/powercard? Administrators make up about 4% to 6% of the population of active editors on wiki, so why give them so much power in this process? I'd much rather see a 1 crat, 2 admin, and 4 non-crat/non-admin editors who would not be eligible for the admin tools during their term. I'd see this as a much closer representation of the population of editors (although still skewed in favor of crats and admins). — {{U|Technical 13}} (etc) 20:07, 30 October 2014 (UTC)
  • It would be extremely hard for commissioners to do their admin-supervising job unless they could view deleted contributions, so I think that for reasons of practicality they'd have to receive the admin tools on being elected.—S Marshall T/C 20:37, 30 October 2014 (UTC)
Perhaps it would be possible to grant them the ability to see deleted contributions without giving them other administrator powers? Given that these candidates will have been vetted by the community in the elections, I see no reason for the Foundation to object. RGloucester 20:42, 30 October 2014 (UTC)
  • This is getting out of hand. The key to proposals like this is that they cannot be overly complicated. I stick by my suggestion that we should have one-year terms. I'm strongly opposed to complicated distributions of power based on population representation. As said above, administrators are the ones that deal with administrative matters on a daily basis, and hence are important to a balanced Administrative Standards Commission. I think that a 3/3/1 allocation is the best we can hope for. Three administrators, three non-administrators, one open seat. I see no necessity for bureaucrats to be allocated a seat. RGloucester 20:29, 30 October 2014 (UTC)
With that said though, I don't think we should prohibit a crat from holding the seat if the community decides that. Crats are admins after all.--Church Talk 21:29, 30 October 2014 (UTC)
Of course. They merely would not be allocated a special seat. RGloucester 22:06, 30 October 2014 (UTC)

Moved to Wikipedia talk:Administrative standards commission Oiyarbepsy (talk) 23:13, 30 October 2014 (UTC)

List of incremental improvements to RFA over the last five years[edit]

There's been tons of time and typing spilled on the RFA issue in various wikifora over the last 5+ years, attempting to achieve incremental improvements to the process. Can someone provide a list of the actual improvements to RFA that have come from all this effort in the last five years? Townlake (talk) 15:08, 30 October 2014 (UTC)

Are we limiting the list to reforms that lasted, rather than something that was tried a couple of times and given up on? If so, then I believe that the complete list of lasting reforms is in this box:
But perhaps someone else knows more than I do, because I don't usually follow RFA reform discussions. WhatamIdoing (talk) 21:22, 30 October 2014 (UTC)

List of RFA Alternatives Proposed[edit]

Regardless of the vote calls for I see no harm in getting all of our ideas in one place for convenience and this is my attempt to do that, please feel free to add your idea if I forgot to add it.

  1. unbundling the admin tools and having them be open in a process like Requests for Permission.
  2. Arb-Com Style Elections for Administrators
  3. The creation of a committee that would actively "search for potential candidates for adminship, accept applications for adminship, evaluate those applications, to appoint administrators, and to serve as a forum for the review of administrative actions." - see WP:Administrative Standards Commission
  4. Tweaks to RFA to limit commenting, appoint clerks, and other suggestions that would keep the basic RFA process we've come to know.
  5. User:WereSpielChequers/RFA reform#Upbundling, especially of the block button.
  6. See User:Application Drafter/Sysop applications draft. (Sorry for inserting this in someone else's comment, but I don't know how else to do this.) Application Drafter (talk) 03:09, 31 October 2014 (UTC)
Feel free to update this list as you see fit. Regardless of if we close RFA or not I think we should not give up until we can hammer something out. This multi-year long debate dies here if we make it die here. I'm not for RFA, I just think it should stay until we can actively set up an alternative.--Church Talk 19:30, 30 October 2014 (UTC)
I added the upbundling one (#5), since the block button is the one that most makes one want to look at demeanour issues, and these are where the criticisms can get personal. --Stfg (talk) 21:01, 30 October 2014 (UTC)
See item number 6, above. Application Drafter (talk) 03:09, 31 October 2014 (UTC)

Proposal: Admins should serve terms[edit]

As most people probably know, if you are elected as an admin in the current system, you hold the position for life unless you voluntarily resign or ArbCom takes it away. This fact may play a part in the restrictiveness of RfA, because as of now, there is no easy way to remove adminship, so the candidates that you elect must be really good.
However, this problem could be solved by having admins serve "terms". How long your "term" is depends upon the amount of support you get. For example, if you get 50%-75% support, you're only elected for a one year term. If you get 75%-100% support, you get elected for a two year term. At the end of this "term", the admin would go through a reconfirmation, where it would be confirmed that they haven't done anything to warrant a desysopping. A predefined list of things deserving a desysopping would exist as a guideline, so that we could ensure that an admin couldn't be desysopped merely for making a couple of mistakes, which would not be out of the question if it was up to the mob. If no outstanding issues arise during the reconfirmation, a 'crat would close it as successful, and the admin would serve for another term. As long as the admin remains trustworthy and does not violate the desysopping criteria, there would be no limit to the amount of terms that an admin could serve.
I feel that, if implemented, this would loosen the requirements in electing new admins, because an admin could always be desysopped if he acted unacceptably during his term. I'm looking forward to everyone's input. Thanks, --Biblioworm 23:41, 30 October 2014 (UTC)

Strongly oppose – As I said above, adminship is not a political position, nor a leadership position, nor a legislative position. Admins should continue to serve on merit, in line with their duty as technical servants of the Wikipedia community. Forcing them to run for "election" will politicise the post even further, resulting in administrators who are good at wheeling-and-dealing, not dealing with the maintenance of the encyclopaedia. RGloucester 23:55, 30 October 2014 (UTC)
I'm not trying to turn this into a political position (besides, being a member of a committee is also a political position). I'm just saying that the notion of "admin for life" is probably a main reason why the admin position is thought to be a big deal. Once you have it, you cannot lose it unless ArbCom revokes it, which can be difficult to do. In my opinion, we'll never fully get rid of the "power", "authority", and "mystery" surrounding admins until we have a more convenient way to desysop. In fact, this proposal is not completely incompatible with the proposed ASC, as the committee could review admins at the end of their term. --Biblioworm 00:11, 31 October 2014 (UTC)
This is a good and thoughtful proposal. I especially like the protection you've built in against mobs. I don't fully agree with RGloucester on admins being purely servants. In practice their role does contain an element of executive function and leadership , even if some of the more maintenance orientated admins chose not to get involved in that side of things. IMO opinion you wouldn't get rid of the "power" element even with an easier desysop (which I probably wouldn't support due to the risk of anti admin witch hunts) There's two reasons I like RGloucester's ASC idea even more. It wouldn't feel right to retrospectively apply terms to existing admins, and so this would risk making all new admins second class. And compared to the selection board, this proposal would still allow scope for the same sort character assassination that happens with existing RfA. (Im skeptical that even bolting on clerking would not prevent this.) FeydHuxtable (talk) 00:26, 31 October 2014 (UTC)
As I mentioned above, this proposal can easily be adapted to fit the ASC. I suppose, though, that the advantage of the ASC is that desysoppings can be done on a rolling basis rather than at set intervals. Even if my proposal isn't accepted in its current state, I do strongly believe that we should have some sort of convenient desysopping procedure. I really don't care if the ASC or the community handles it, so long as it's something. (However, I am beginning to increasingly support the concept of the ASC, but it does still need some work.) Whatever desysopping procedure we adopt, it has to have some sort of "mob protection". --Biblioworm 00:41, 31 October 2014 (UTC)
I do strongly agree that administrators should be able to carry out their duties without being hanged on a whim, which is one of the reasons I like the idea of the WP:ASC (the proposal now has its own page). RGloucester 01:01, 31 October 2014 (UTC)
I must say, this could work. It would mean a lot of "re-adminships", but what do we have to lose? --AmaryllisGardener talk 01:31, 31 October 2014 (UTC)
We have plenty to lose. Such a proposal further entrenches the wrong idea that adminship is a "big deal". We need to be curtailing this notion, not furthering it. RGloucester 01:33, 31 October 2014 (UTC)
Off the top of my head, and from the last 30 times this has been proposed: you stand to lose a lot of admins. If we already have trouble finding enough candidates willing to run the gauntlet that is RFA, forcing everyone to run it again and again will only exacerbate attrition. Not to mention a significant additional bureaucratic burden that takes everyone away from what we are supposed to be here for: building an encyclopedia. You also risk massively reducing the number of admins willing to take on controversial tasks because of the very same predilection for "character assassination" as FeydHuxtable so aptly terms it above. Why would anyone take on a tough job if the only they they can expect as a result is reams of abuse? Resolute 13:51, 31 October 2014 (UTC)
Ultimately, adminship is a bigger deal than it was in 2003 because Wikipedia is a bigger deal than it was in 2003; there's probably no going back on this. Standards are a bit higher, because the seriousness of our fuckups is higher. In the interim "I'm concerned there aren't enough administrators, so let's start removing admin status from the existing admins" makes no sense. WilyD 13:38, 31 October 2014 (UTC)


If you support the proposal but advise any changes to the suggested timeline above , please mention in your vote.

The proposal to vote on is:
The community supports marking the existing RfA / RfB process as historical, thus providing a clean slate on which to design a suitable replacement.

Please vote Abolish (Support) to abolish our current RfA system or Maintain (Oppose) to maintain it (for now).

Abolish current RfA system[edit]

  1. Strong Support. (I'm the first one here. Face-smile.svg) The more I'm thinking about this, the more I'm becoming convinced that we're not going to get anywhere unless we just blow it up and start over again. For years, the community has wasted time and effort trying to reform RfA, but none of them have yielded results. Unless the current system is shut down, there will be no motivation to come up with a new one. (By the way, I do think this RfC should be extended to last about 30 days, since this is such a major proposal.) Thanks, --Biblioworm 00:09, 30 October 2014 (UTC)
    While I'm not opposed to the idea of blowing it up and starting it over, I think we should do it in the other order - first construct the new process, then demolish the old one and start using the new one. If this proposal passes, then how will a user try to become an adin the day after we close down RFA? עוד מישהו Od Mishehu 19:40, 30 October 2014 (UTC)
  2. Strong Support per Biblioworm. FeydHuxtable (talk) 00:21, 30 October 2014 (UTC)
  3. Me too. In order to address some of the opposers' concerns, I suggest that if this process succeeds and RfA is marked historical, then the RfA process should be suspended with effect from, say, 1 January 2015, so we've got a known end date but we also maintain some process for promotion (even if it's dysfunctional) for a month or so until the end of December.—S Marshall T/C 00:51, 30 October 2014 (UTC)
  4. The definition of insanity is doing the same thing over and over and expecting a different result. Years (7 according to Feyd) of incremental reform efforts have led nowhere. It's time to try something different. In the past, RFA was functional enough that this plan would be too extreme. But at this point, the promotion rate is so low, not having a process for a couple months will barely make a difference. Mr.Z-man 03:11, 30 October 2014 (UTC)
  5. This is the only way to fix RFA, but I expect this effort to not achieve "consensus". It's a shining example of the failure of the consensus model to govern a community that has clearly outgrown it. With no adults in charge, clearly-broken processes can't be changed. Good luck making those "incremental changes," folks. Townlake (talk) 03:37, 30 October 2014 (UTC)
  6. Support. Essentially agree with Biblioworm and Mr.Z-man, above. Cheers, — Cirt (talk) 04:30, 30 October 2014 (UTC)
  7. Support. Let's dispense with the notion that it's radical or irresponsible to deconstruct a system (and what is permissible within it) that is gradually failing to do its job, particularly with the understanding that we are dedicated to work together to build something better. Editors arguing that there are other factors besides the system are probably right, but there is sufficient evidence that the system is a major factor and is something malleable that can be improved. I encourage editors who do not consider the system to be a significant problem to read over WereSpielChequers observations, comments in this recent invitation for candidates on AN, some of the feedback at User:Juliancolton/Why I hate RfA, and User:Dayewalker#My RfA, and good faith advice on yours. I, JethroBT drop me a line 08:05, 30 October 2014 (UTC)
  8. Unbundle the tools, unbundle the tools, unbundle the tools. Come up with weak and strong versions of the tools, so that some users can demonstrate their facility with the weak version before getting the strong version. For example get a permission to block only anons, and only for a short time, with progressively more authority needed to block registered editors, and to impose longer/indefinite blocks. bd2412 T 19:39, 30 October 2014 (UTC)
    You realize some people would go completely nuts over that proposal, calling you an elitist, IP hater, via WP:IPs are people too, as that makes IP sound less human than registered editors? Dennis - 20:14, 30 October 2014 (UTC)
    • I hadn't thought about it, but what other division can we use to give editors a trial power to block a subset of all editors? bd2412 T 20:18, 30 October 2014 (UTC)
      • Duration. ie: 1 week or less. They still have to go through RFA, however, per WMF. A talk page (mine is fine) is better for extended discussion) Dennis - 20:32, 30 October 2014 (UTC)
  9. Support For those who are opposing because it would disrupt the adminship process: What has RfA done for you in the past two months? Nothing? Then I don't see why suspending the process would be disruptive. KonveyorBelt 20:12, 30 October 2014 (UTC)
  10. Support, the current system comes from another time and another place. It has served us well, but it's time to let it go, because it's clearly not serving us well anymore. It's clear after years that 'reforms' aren't going to stick, so I think the first step to a better way to fill the admin corps is to abolish the current system, and force us to design a better one. Lankiveil (speak to me) 22:49, 30 October 2014 (UTC).
  11. Abolish which is a support !vote for those who didn't read the directions above :) - this process is clearly broken, otherwise why would RfA reform be one of our most well-known perennial proposals? Nuke it, it's the only way. I'll not be opposed to maintaining the existing RfA until the RfC closes, to placate those worried that being without a system with such a pathetically low turnover rate would be disastrous (it clearly wouldn't), but when the RfC closes, the existing RfA must close with it. Ivanvector (talk) 23:07, 30 October 2014 (UTC)
  12. Support. It doesn't work anymore; almost nobody is getting through. Everyking (talk) 01:08, 31 October 2014 (UTC)
  13. Support and see my proposed template at User:Application Drafter/Sysop applications draft. Application Drafter (talk) 03:10, 31 October 2014 (UTC)

Maintain current RfA system[edit]

  1. Oppose I'm afraid that I can't get behind this idea. I'm not comfortable removing RFA with at least a general idea of what the replacement would be. With that said, I'm not opposed to moving to support and I plan to think this over in the coming days but for right now I just have too many questions and concerns and too little answers. We can go gun-ho all we want about this, but I can't help but think incremental changes would be better then destroying RFA completely. The big argument is that it's been done and it didn't work numerous times. I don't have an answer for that right now, but I'm extremely uneasy removing the one way we have to promote administrators for any amount of time.--Church Talk 00:27, 30 October 2014 (UTC)
    I believe one idea is an ArbCom-style election, but there hasn't been extensive discussion about that. If this RfC does fail, I suppose we can open yet another discussion to collect some ideas for a new election system. --Biblioworm 00:35, 30 October 2014 (UTC)
    Looking at the data, not enough people are using the RfA process to make it worth keeping. Why not just blow it up and build something new and useful? — {{U|Technical 13}} (etc) 00:58, 30 October 2014 (UTC)
    I'd rather have it and not need it, then need it and not have it.--Church Talk 01:02, 30 October 2014 (UTC)
    • What you are saying is you'd rather have something that won't be used and is apparently harmful to the wiki instead of build something new that will be useful in increasing our core of editors and producing new and improved content for our readers. I entirely understand. Why does Wikipedia need administrators anyways? Let's just do away with all of them! Nevermind, my sarcasm would simply be wasted in this forum...  ;) — {{U|Technical 13}} (etc) 01:10, 30 October 2014 (UTC)
    • (edit conflict) I never said that I was against change or removing RFA. I simply said that I'm not willing to take a leap of faith with the only option we have right now. RFA has apparently been detrimental to the community for a long time, I don't see how it could hurt to have it awhile longer to at least have a good list of alternatives before we decide to retire it.--Church Talk 01:27, 30 October 2014 (UTC)
  2. Maintain I oppose abolishing as reckless. Where is the study that says the RfA system is the problem? Better may be: 1) Conduct a study that explains the low numbers. 2) If the study shows that the system itself is the reason for the low numbers, design a new system. 3) Post here proposing switch. Anna Frodesiak (talk) 01:23, 30 October 2014 (UTC)
  3. Maintain What Anna said. Well meaning, but this isn't going to make things better, it will just divide the community even more. We should look at tweaking what we have instead. Dennis - 01:32, 30 October 2014 (UTC)
  4. Oppose any proposal in which RfA is disbanded without an immediate replacement by something else. This is being done backward; first get consensus for a new process, then either modify or disband the old one. StringTheory11 (t • c) 02:30, 30 October 2014 (UTC)
  5. Oppose a specific transition plan should be ready to take over, perhaps even with an overlap (during "beta" of the new process) prior to discontinuance of the existing process. — xaosflux Talk 03:20, 30 October 2014 (UTC)
  6. Maintain Not a single person has suggested a replacement system, and some proposed fixes have been suggested here that I don't think have been tried. If someone had some good replacement, I'd reconsider, but I don't see that happening. Oiyarbepsy (talk) 03:43, 30 October 2014 (UTC)
  7. Maintain per Anna and Dennis. INeverCry 04:01, 30 October 2014 (UTC)
  8. Maintain, what Anna said. I'm not convinced RfA is the problem (my personal opinion is that it lies closer to the lack of its opposite process); whatever the problem, i believe it would be foolish, at best, to dump a process with no replacement in place. Yeah, Cortés burned his ships, as is mentioned above; he also was unbelievably brutal, benefited from disease, and inaugurated several hundred years of exploitation. Not sure i'm comfortable following his example.... Cheers, LindsayHello 05:15, 30 October 2014 (UTC)
  9. Maintain, at least until something better is worked out. The work still needs to be done. As I have remarked elsewhere, any process can be made ineffective by complaining, belittling and pointing out problems until no one wants to be a part of it, and then pointing to the resulting lack of participation as further evidence against it.—Anne Delong (talk) 06:05, 30 October 2014 (UTC)
  10. Maintain, but experiment - I have no problem with the proposal to appoint a board for a limited term as an experiment (maybe limit their chosen admins to needing an RfA after a year), I just think it is highly premature to eliminate RfA. If the board can act with good judgment and find competent and thoughtful admins who would not have pursued RfA, then I think it would just become the de facto adminship process. But eliminating RfA without any experience with a new system is madness. VanIsaacWScont 06:11, 30 October 2014 (UTC)
  11. Oppose I don't think the problem is with RfA, but with attitudes towards adminship generally. If people don't want the job, they're not going to apply, regardless of what the application process is. --ais523 06:13, 30 October 2014 (UTC)
  12. Oppose. RfA is not too great a hassle or an insurmountable obstacle. Rather, the performance of admin work is a stick with no carrot. Most editors who would be good candidates for the job are not interested in having it, and that's not a problem with RfA. Dekimasuよ! 07:00, 30 October 2014 (UTC)
  13. Oppose as ill-thought out and quite possibly misguided. We need to find more editors who want to stand and who have a chance; the current process does promote people who are qualified. BethNaught (talk) 07:44, 30 October 2014 (UTC)
  14. Oppose RfA related RfCs/proposals won't pass when it's just one or two editors dreaming up a wacky "solution" and then opening it to a vote. It should have been obvious from the short thread at WT:RfA that Townlake's suggestion was not widely supported. For actual change you need to take part in existing discussions, feel the way the wind is blowing, reach out to people and look for something likely to be accepted by the community. benmoore 08:17, 30 October 2014 (UTC)
  15. Oppose. Maintain current system, but experiment. Full marks to Feyd and Townlake for a BOLD proposal, but I don't accept either of the propositions behind it: (a) RFA is so uniquely bad that anything cobbled together under pressure against a short deadline must be better, and (b) the unique badness of RFA is the reason why so few are applying. As regards (a), I don't see much evidence that RFA is passing people who shouldn't be admins or failing people who should; as regards (b) this year's numbers are about one third of those for 2011 - has RFA got so much more terrifying? We should look elsewhere for the reasons why the numbers of people who want to do this fairly thankless task are falling. JohnCD (talk) 08:49, 30 October 2014 (UTC)
  16. Oppose/Maintain. The whole thing seems to hinge on the idea that once RFA is abolished, it would only take a week or so to put together an acceptable alternative. That is hopelessly naive. Neatsfoot (talk) 08:50, 30 October 2014 (UTC)
  17. Maintain Marking it historical is a sure way to ensure failure. But I do like the idea of adding additional mechanisms. I have proposed the idea of a selection board in the past as mentioned above by Vanisaac. Graeme Bartlett (talk) 10:13, 30 October 2014 (UTC)
  18. Maintain I'd love to see improvements in the RFA process. Those who say it's the people that's broken, not the process, overlook that processes are there to be operated by people. So I agree that RFA needs improvement to remove, or at least reduce, the nastiness and arbitrariness. But this is rushed; the idea that we can come up with consensus so quickly just because we've marked the current one historical is wildly optimistic; and the prescription that "going back to a modified form of the existing RfA process is not an option" prejudices consensus and is a showstopper for me. Instead, we should be trying out ideas like some of those suggested in User:WereSpielChequers/RFA reform, piecemeal and with the option to reverse them. --Stfg (talk) 10:31, 30 October 2014 (UTC)
  19. Maintain but move straight on to agree a reform package. Credit to the proposers for kickstarting this debate. Don't agree "it can't be reformed without scrapping it": when previous credible attempts were launched, the recruitment rate had not been so low for so long: Noyster (talk), 10:56, 30 October 2014 (UTC)
  20. Oppose, though I find myself extremely sympathetic to the other side as well. I think the proposers might well be right that the best way forward from our current format might be "blow it up and start again from the ground up," but I find the notion that if we do blow it up, the people will magically come together, quickly and neatly, into consensus to be naive. Historical efforts to change RFA have failed largely because while everyone agrees it's broken and needs to change, everyone's fix is different; if we want any hope of fixing RFA, we're going to have to first find a way to route around the tendency to agree in a cacophony of disagreement. I think we may have reached a point now where people are going to be willing to compromise on RFA/proposal format in exchange for a discussion that ends actually-truly-actionably, and I think floating that sort of proposal should be our first step, not just blowing up RFA and hoping the rest fixes itself. A fluffernutter is a sandwich! (talk) 13:37, 30 October 2014 (UTC)
    Thanks fluff. In fact our thinking wasn't quite as naive as it might seem. We did anticipate some of the difficulty you foresee (the Abilene paradox ) but we felt if we could first kill the beast , it would open the way for a well structured RfC (perhaps a recursive version of the pending changes RfC) to narrow down the available alternatives. Beeblebrox was mentioned above as the first choice to lead that had the first stage of this reform attempt found consensus, and had he declined, I had your good self in mind as the second choice. In hindsight it might had been better to have planned this out better, I was perhaps too concious of the too much prep/ not enough action issue that has sunk so many previous attempts. FeydHuxtable (talk) 15:14, 30 October 2014 (UTC)
    As a former Abilenian, I will grant you +1 point for linking to that relevant article. Dennis - 15:25, 30 October 2014 (UTC)
  21. Maintain for now, while I propose another section right below this which defines and establishes consensus on one or more experimental proposals. Such a proposal can run as an alternate route to RFA in parallel and we'll have A/B testing results soon enough while at the same time there will be iterations on the experimental system to near the refinement of RFA. While the experimental system remains (and ofcourse after some basic refinement), it can be optional for candidates to choose either. --lTopGunl (talk) 13:48, 30 October 2014 (UTC)
  22. Maintain - There's nothing wrong with RfA as it is. Good candidates are approved without much fuss (apparently we have right now a good example ongoing at Wikipedia:Requests for adminship/Jackmcbarn), bad candidates ared snowed under, and controversial candidates will have to answer a lot of questions. Those who complain are mostly the candidates who are either ambitious or egocentric and were voted down for evident failure to comply with the minimum requirements. Please give me some examples when a real good candidate was voted down by vicious antis for no good reason. Kraxler (talk) 13:57, 30 October 2014 (UTC)
    Three good candidates have passed in the last four months, counting Jackmcbarn. I don't mean to pick on you, but your rationale doesn't address the underlying problem. I completely agree with you that the current system rejects bad candidates, and that's desirable. But it also repels good candidates who aren't interested in subjecting themselves to the scrutiny of hundreds of self selected evaluators who all get to use their own criteria. Look at how many candidates sign up for an RFA nowadays; something is quite obviously wrong with RFA as it is. Townlake (talk) 15:22, 30 October 2014 (UTC)
    We also have to think about what is truly "bad". The problem is that many !voters sometimes have unreasonable expectations of candidates, and when they (understandably) don't meet them, we call them "bad" candidates. If we loosened the expectations a bit, I think we would find that some candidates who would normally be called "bad" would actually make pretty good admins. --Biblioworm 15:33, 30 October 2014 (UTC)
    Very good point Biblioworm. A few seem to have such a strong belief in the infallibility of the current system, they think the very fact someone failed is proof they were a bad candidate. There are several failed candidates who would have been top tier admins IMO, but pointless to point out who they are. The problem is there's no comparable alternate way to assess someones quality that would be widely accepted. And no point pitting one's personal opinion against aggregate community judgement as expressed by the RfA monster! FeydHuxtable (talk) 15:44, 30 October 2014 (UTC)
    I also want to add here that a single nomination that appears to successful (so far) is not sufficient evidence to claim that this downward trend is changing. I, JethroBT drop me a line 01:22, 31 October 2014 (UTC)
    Ok. So, no examples are coming forth, just theoretical diffuse criticism, because someone you supported was voted down. I've not always voted the same as the eventual result, but I've never been on the verge of abandoning Wikipedia because of it. Strange/unconvincing/nonsensical oppose rationales can amount to 30% of the votes without prejudice. I doubt that more than 30% "trolls" (many rationales are judged unconvincing and nonsensical by some, but heartily endorsed by others, but for argument's sake let's say "trolls") would appear at any RfA. Overall, explanations for the declining number of successful candidatures might be: A)) Editors who create mainspace-content don't want to lose time with janitorial tasks. B)) A general decline of the number of editors leads to a general decline of numbers of admins/RfAs. C)) Many, including otherwise "good", long-time editors have been involved in unsavoury controversies and scandals in the past. If they run, they are voted down despite their expertise, because the community wants to avoid more trouble. If they don't run, the number of RfAs declines, but at least the editors show common sense. Etc. et al. Kraxler (talk) 13:29, 31 October 2014 (UTC)
  23. Oppose - we should either reform RFA, or draft a new one and replace the current one with that. We shouldn't shut down RFA until we have a new process to replace it. עוד מישהו Od Mishehu 16:05, 30 October 2014 (UTC)
  24. Maintain - By all means experiment by limiting comments as suggested above but I am not convinced there is a better way of doing it. I get the impression that almost anyone could get to be an admin in the early years. We are now getting the best.Charles (talk) 18:48, 30 October 2014 (UTC)
  25. Maintain - Blowing it up solves nothing other than more arguments and nothing getting done, There's no doubt about it RFA one way or another needs to change but personally I have no idea how!.... –Davey2010(talk) 19:44, 30 October 2014 (UTC)
  26. Expecting a polarized, dysfunctional group of people to behave less dysfunctionally when put under additional pressure seems unwise. See Budget sequestration in 2013. --Floquenbeam (talk) 23:07, 30 October 2014 (UTC)
  27. Maintain RfA works for most tools. We should remove the two sets of privileges which people have real trust issues with (deletion and restriction oriented tools) and then move forward from there. GraniteSand (talk) 23:18, 30 October 2014 (UTC)
  28. Simmer down, folks. – Juliancolton | Talk 00:44, 31 October 2014 (UTC)
  29. Read WP:RFA2011 - apart from the fact that NOTNOW applications happen, RFA is about where the community wants. Although a lot of people agree that it's "broken", their perceptions of the brokenness go in various directions, and it's the sensible compromise. If I think the thermostat is five degrees too hot, and my wife thinks it's five degrees too cold, we both agree that it's at the wrong temperature, and yet, that doesn't mean there's a better temperature for us to set it at. Parallel process proposals don't fail because the existing process exists, they fail because other potential processes all have less community support than the process we have. If you want to increase the number of successful RfAs, there's only one course of action. Go do new page patrol, and assist and mentor new editors, rather than chasing them away and deleting their work. In the interim ... well "We want more new admins to be created; therefor, we want to eliminate the only method of creating new admins" is a sow's ear. WilyD 13:31, 31 October 2014 (UTC)
  30. Oppose. Counterproductive and reckless to hold a vote on abolishing RfA when you haven't come up with a community-approved replacement beforehand. Resolute 13:52, 31 October 2014 (UTC)

Something not related to closing RfA[edit]

The better place to raise this issue would be Wikipedia:WikiProject Football. --Jayron32 01:14, 30 October 2014 (UTC)

And I just moved it there - Wikipedia talk:WikiProject Football#Team divisions on player pages. Oiyarbepsy (talk) 06:20, 30 October 2014 (UTC)

Watchlist with watch/ignore talk page threads[edit]

As an IEG proposal, I have proposed making a user script which permits you to watch or ignore threads on talk pages. With this script, for talk pages your watchlist will only show the threads you have chosen to watch. Alternately it will show all threads except those which you have indicated you desire to ignore. In addition, the script will permit you to display entries from your watchlist on other Wikipedia projects and languages. If would like to see this functionality happen, please go to the IEG page and indicate your support (endorse). — Makyen (talk) 23:52, 30 October 2014 (UTC)

Commons admins/OTRS access to deleted files? Opt-out?[edit]

Hi. Since this seems to be mostly ignored on VPT, and someone on the RfC said it was not a good place to put it, I'll put this link here too: m:Requests for comment/Global file deletion review. πr2 (tc) 00:51, 31 October 2014 (UTC)

Unbundling the tools[edit]

Having read BD2412's comment above about unbundling, it got me thinking: which of the tools should be unbundled? Deletion and blocking, I think, are the two most sensitive tools in the toolkit, as blocking can easily drive off good contributors and deletion, as brought up by somebody (I think it was Dennis Brown) on the RfA talk page, must come with viewing deleted content, which is incredibly sensitive.

Other than those two, though, I fail to see a good reason why the tools should be kept bundled. Stuff like protection (WP:RPP, where there is a perennial backlog), changing userrights of others (WP:PERM), and overriding the title blacklist could easily be placed into the hands of a trusted user, I think, through a less rigorous process than RfA. Thoughts on potentially unbundling these tools, or others? StringTheory11 (t • c) 00:52, 31 October 2014 (UTC)

I think that unbundling page protection would be a good idea. --Tryptofish (talk) 01:00, 31 October 2014 (UTC)
(edit conflict × 2) You complain about backlogs. Unbundling the tools would just create more backlogs. - NickGibson3900 Talk 01:03, 31 October 2014 (UTC)
@NickGibson3900:One thing though, one could work their way up to admin. Maybe that way users would be more confident to run for RfA. You act as if users that would apply for this unbundled right would just be satisfied with what they're doing and wouldn't run for RfA just to help out with the big stuff. Well, admins aren't required to work everywhere. --AmaryllisGardener talk 01:13, 31 October 2014 (UTC)
(edit conflict) If this came up just a week ago I would have responded with a sarcastic reply, but, now I'm thinking, this might work. I doubt it would pass an RfC, but we could try. :) Don't forget about viewing deleted content, that's looked at as the most sensitive admin tool. One place you can see this is here. We could have a right that can deal with issues number 1 to 5, then "administrators" could deal with all of them. --AmaryllisGardener talk 01:08, 31 October 2014 (UTC)
If implemented, this would allow users to gain trust with the "lesser" toolset before applying for the more advanced one. Using the "lesser" bundle responsibly would probably be looked upon favorably by the community when the user decides to apply for the more advanced tools. --Biblioworm 01:15, 31 October 2014 (UTC)
Took the words right out of my mouth. --AmaryllisGardener talk 01:20, 31 October 2014 (UTC)
Issues with the ability to see deleted content could be ameliorated to a great degree if there were levels of deletion, with sensitive deleted content being distinguished from run-of-the mill maintenance-type deleted content. bd2412 T 01:51, 31 October 2014 (UTC)
We already have two levels, Deleted and Oversighted. The Devs, WMF and the community would all have to agree on a 3rd. I wouldn't bet my lunch money on that, particularly since it really complicates stuff for admin. Dennis - 02:03, 31 October 2014 (UTC)
Keep in mind, the WMF says you MUST pass RFA or very similar to get any of the tools, so that wouldn't change, although the drama might be less because the "risk" is lower when they get fewer tools. That said, I've always thought that everything but the block button would be good for many users who are purely content creator types, the ones that have no interest in fighting vandals. They become "content moderators" or "mods". Then they could protect, delete, undelete, revedel, so they could close any XfD. These are areas we could use the extra help and they likely would excel in. It isn't a stepping stone to admin, even if some choose to use it that way.
Their authority would be limited to content only. For example, when it comes to general sanctions, they wouldn't be able to block or issue any sanction (ie: treated like a regular editor). However, WP:INVOLVED would have to apply to them, they can't protect an article they have worked on, etc. WP:ADMINACCT would also apply, as would behavioral expectations in general. While this isn't a giant breaking of tools, it really is a big breaking up of duties. And lets be honest, some people are great when dealing with policy and notability, but not so much at mediating or handing brawls. Their special tools and authority would be purely on content, where they would be considered equal to admin in authority in those areas. When it came to behavior and editors, their authority would be on par with non-admin. I know for a fact that many editors would like this as they are content centered and don't want the hassle of playing "wiki-cop", so you would get more interest. Unfortunately, this might change the view of admin to be more as wiki-cops, although I have no hard evidence to back this. Dennis - 01:18, 31 October 2014 (UTC)
The protection "backlog" is mainly because people almost forget it exists. In practice, protection is the least used of the 3 main tools. For every page we protect, we delete ~20. User rights changes are even less common. Having 1000 people with the ability to protect pages just means that the average "page protector" is going to use the tool twice a month. Or, in cases where it would make more sense to block the offending user(s), they'll just protect the page instead - when all you have is a hammer, everything looks like a nail. Mr.Z-man 01:36, 31 October 2014 (UTC)
A very valid point that made me think Mr.Z-man. However it does not need be like that. As an example, if all you have is roll back, then everything does not look like it needs to be reverted. People will call an admin instead of starting an edit war. I have faith that people will use the protect right correctly. - Sincerely, Taketa (talk) 08:44, 31 October 2014 (UTC)
Regardless, it doesn't change my main point, which is that there isn't much demand for page protection in the first place. Mr.Z-man 11:32, 31 October 2014 (UTC)
Issuing some sort of "protector" type rights would likely need to bundle: protect, stablesettings, editprotected, editsemiprotected, templateeditor --So the question at hand is: is this worth being a non-admin if you can change things like : Main Page, and/or fully protected templates used by the interface? — xaosflux Talk 02:38, 31 October 2014 (UTC)
It would make more sense to pass admins based on a curve than it would to unbundle the tools in my opinion. That way we could pass the amount of admins needed to stop attrition. Chillum 02:57, 31 October 2014 (UTC)
@Xaosflux: - Yes this is important to discuss. In my opinion people can be fully trusted AND be deemed not qualified to judge deletion of articles. Some of the main oppose reasons I see at WP:RFA is that people do not have enough experience in creating content themselves and voters do not want them to be deleting content, and that people do not have enough experience at WP:AFD and the voter cannot judge their ability to judge article deletions. Both of these concerns do not influence the protect right in the examples you supplied. People can be fully trusted and at the same time not be deemed qualified to do certain things or have certain rights. Sincerely, Taketa (talk) 09:02, 31 October 2014 (UTC)

I actually think WP:RFPP is the most contentious Wikipedia process. Allegations of admin abuse tend to be "someone is using admin powers to win an edit war". Deletion can't really do that, most of the time. Blocking can, but blocking someone you're in an edit war with is really obvious and people tend not to be accused of it unless it actually happened. Protection, and editing through protection, are a lot more of a gray area (especially because unlike routine CSDs and routine vandalism blocks, protection often implies there's an actual edit war going on, frequently where both sides are in good faith or at least not obviously in bad faith. --ais523 08:51, 31 October 2014 (UTC)

Page protection is a big deal tool, and anyone who can be trusted with it can also be trusted with blocking and deletion. If the problem is that RfA is too harsh, pushing people through TWO RFAs is not a solution. Title blacklist is unimportant, and can be handed out freely. Changing userrights is less clear. WilyD 09:58, 31 October 2014 (UTC)
See, I wasn't focusing on "trust", as I think that if you can't be trusted for one, you can't be trusted for any. When I talked about breaking off "block", it was because the "block" button is one reason why some people don't want to be an admin. They don't want to block, or have the tools, they want editing tools, not to be responsible for banhammering someone. My thinking was that is how you get MORE people to run in the first place. There isn't a lack of people who are qualified, there is a lack of people willing to accept the tools. Dennis - 13:26, 31 October 2014 (UTC)
Is there a single person who's declined to stand for adminship because they'd have access to the block button? Having access doesn't mean they'd have to use it. But otherwise, the decline in new admins is almost entirely a decline in qualified candidates; not that none exist, but there are far less than there were in 2006, because there are far less new editors than there were in 2006. You get more people to stand by having a bigger pool to pick from. WilyD 14:19, 31 October 2014 (UTC)