Wikipedia:Village pump (proposals)

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

New ideas and proposals are discussed here. Before submitting:

« Older discussions, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117

Contents

Centralized discussion
Proposals: policy other Discussions Ideas

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


Media Viewer RfC Question 1[edit]

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

This RFC has been running for significantly more than a month, not counting the withdrawn close, the participation has dwindled and it is past due for closure. Some have suggested that several admins should close the discussion in unison, but I have rejected this possibility since the RFC didn't seem to have interested that great a proportion of the community to warrant it, compared to the PC RFC for example, and it would have without a doubt further delayed the time of closure, to the point of making the RFC moot. In analyzing the discussion, I had to take into consideration the improvements to the media viewer that have been made since the start of the RFC, as acknowledged by the initiators, and determine how they affected the arguments. In light of this, simply counting votes is a very distorted and unreliable measure of consensus, and as is required of administrators closing such discussions, the strength of the arguments has been considered. I must stress on this point that the lack of a proper discussion and review of improvements, instead going straight to a poll, made this task very difficult and there is a case to be made that a plain "no consensus" closure due to the lack of clear outcome would be warranted, but when analyzed in details, a more subtle conclusion can be drawn. It is only because of this lack of thorough debate that I have to make such a lengthy assessment in order to get an actionable result out of all this. First off, it is crucial to make a distinction between logged in and logged out users, as most commentators agree, but such separation was not preserved in the format from the previous RFC. Yet, to reach a conclusion, it is necessary to draw this line, and I have analyzed the debate in light of this distinction.

With regard to logged out users, it is not in dispute that the overwhelming majority of them are foremost readers and we should take into account their needs, while at the same time encouraging them to contribute. The large majority of supports for turning off the feature were either regarding issues addressed by subsequent improvements, expressing disappointment at the version of media viewer first deployed, frustration at the subsequent events, anger at the WMF, or did not provide a rationale. As such, those did not contribute to the result, neither did arguments regarding exceptions to consensus, speculation on the WMF response, or personal feelings on either side. The arguments that the media viewer is closer to the needs of readers compared to a classic file page are well supported, since nearly all readers are interested in only viewing the image with its description or caption, as opposed to reusing it or perusing metadata. It is what readers of an encyclopedia expect and is in line with online usage. While it is true that a certain proportion of readers may not like this new presentation, most of the complaints were regarding issues that have now been addressed (such as access to full res image, description, or load time) and only a minority reject it totally. In any case, it is now easier to turn it off, for unregistered users included, while it's much harder to find out about it and turn it on when it is disabled by default.

The argument that the media viewer does not show licensing information sufficiently compared to file pages is unsupported, since on file pages this information is below the image and in their overwhelming majority, readers will not scroll down to it and look at it since they already have what they're looking for, so file pages aren't that much of an opportunity to educate them. Unlike file pages, in its current configuration, the media viewer directly and clearly shows the essential of the licensing information to readers, with a link to further details, and attributes the author. It also specifies how to properly reuse when downloading, which the file page doesn't. As such, on the count of attribution, copyright and licensing, the media viewer is more succinct but not inferior to file pages. The other kind of information, such as file usage or history, is more of a specialized utility and primarily of interest to editors, and image metadata is of interest essentially to image professionals. All in all, based on the commentators who have expressed an opinion on media viewer for logged out users, I find that there is no consensus for disabling it by default.

Some have suggested that absent consensus for a specific outcome, the previous RFC should be implemented. This is not be the case, since both the issue at hand and the community's take on it have enormously changed. Just checking relative support and opposition by numbers (however distorted they may be), we're moving from an opposition of about 1 to 13 for logged in users and 1 to 4 for logged out users in the previous RFC to 1 to 2 in this RFC. The media viewer has also been considerably revamped since then, so the issue being commented on is very different, and the community has a very different take on the situation, meaning the previous RFC result has become irrelevant (but I did consider the still relevant comments from there).

Now with regard to logged in users, the proportion of editors is much greater, so their needs must be given greater weight, however if media viewer is not wanted by a registered user, it is now easier to disable it completely. Unfortunately to complicate the matter in terms of outcome, the questions as they apply to logged in vs logged out users are not independent. Indeed, at registration, if a new user finds media viewer disabled when they always had it enabled while unregistered, it would confuse them, and it's not that obvious to turn it back on. This has been discussed in the previous RFC but not the present one, there's simply no way to avoid this issue if we want to reach a specific outcome, and I do not think that such a RFC should be closed vaguely, or we would get nothing out of it. Therefore, I am bound to conclude from the lack of consensus for disabling media viewer for logged out users and the lack of a consensus strong enough to override this issue, that there is no consensus for disabling media viewer for logged in users by default as well. As an aside, but on a related note, it was determined in the Media Viewer RfC Question 2 closure that there is no consensus for forcing the issue through, regardless of the outcome.

The community did clearly express that the initial roll out of media viewer was unsatisfying, that the product should have been more mature at the time, and that the initial response to community feedback had been inappropriate on several counts. The WMF should truly take this into consideration for future deployments. As noted, there is no consensus for either of the two main outcomes, but there is consensus for requesting several modifications to the media viewer, in order to address several points of enduring concern, expressed on both sides, which need to be resolved as soon as possible, though the implementation of each can be discussed further if needed :

  • Newly registered users should be given a clear choice, such as by showing the window displayed when clicking on the icon for disabling media viewer, appropriately modified, the first time they open an image, asking if they want to keep it enabled or prefer to be directed to the file pages.
  • Readers should be made aware of the possibility to edit the file description, such as through a link in the lower bar or side bar.
  • There is a lack of information on how to upload files, the importance of licensing and the purpose of commons, a help link should be added, maybe before the help links on media viewer itself.
  • In order to meet the specific needs of experienced users, the media viewer should be thoroughly customizable through gadgets and scripts, and proper documentation should be given on this subject.
  • The more details button shouldn't link to the commons description when a local description exists, since the templates for featured pictures and pictures of the day on the English Wikipedia are added locally.
  • The remaining technical issues for some file types or platforms and the cases of improperly displayed documentation should be addressed.
  • In general, any suggestion to improve the user experience taking into account both the needs of readers and editors should be considered.
  • Feedback based on the latest media viewer version should be collected, in a survey or otherwise, and the results published.

Should it become necessary, any future RFC on this matter should be preceded by a thorough review of improvements and feedback, and a proper discussion should be held before any poll is conducted, if any consensus on the major points is to be reached. Cenarium (talk) 00:59, 10 December 2014 (UTC)



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
    PAGE
    ) 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 69.140.0.55 (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. --98.207.91.246 (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. --98.207.91.246 (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 98.207.91.246. 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 en.wiki and de.wiki, 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)
  57. Support Media viewer changes the viewing experience in a way that gives the end user less information and pushes attribution to the author into the background. StaniStani  09:55, 1 November 2014 (UTC)
  58. Support per many compelling arguments above. Sasata (talk) 15:13, 1 November 2014 (UTC)
  59. Any image viewer we use must show copyright, description, and author information along with the image itself. These aren't some kind of boring metadata detail, they are critical information. Our job isn't just to show pretty pictures, it is primarily to educate. A description places the photo in context and furthers that goal. Ensuring to show copyright status helps to prevent someone mistakenly thinking anything on Wikipedia is free for all reuse. Showing full author attribution is just the right thing to do. Media Viewer still doesn't do those things, so I can't support it. Anyone who is aware of these limitations and knows how to work around them can always opt in. Seraphimblade Talk to me 16:01, 1 November 2014 (UTC)
  60. Support per Seraphimblade, WereSpielChequers, AFBorchert and others. Andreas JN466 22:17, 1 November 2014 (UTC)
  61. Support, with an easy way to turn on. Grognard Chess (talk) Ping when replying 15:00, 3 November 2014 (UTC)
  62. Support KonveyorBelt 18:20, 3 November 2014 (UTC)
  63. Support Not active under my account, but I'm making a point to find where the discussion is on this change and supporting the revert. It's extremely slow and cumbersome to use. Until that's improved I don't see how any other viewer is an improvement for the user base. --Nonforma (talk) 05:50, 4 November 2014 (UTC)
  64. Support - The media viewer is unnecessary, cumbersome to use, still very slow, hides the meta data, and should therefore not be activated by default. As long as these issues have not been fully resolved, it cannot be more than an opt-in feature. --Schlosser67 (talk) 11:27, 5 November 2014 (UTC)
  65. Support. From a user point of view I am absolutely not convinced that MediaViewer is necessary or that it enhances the reader experience. From the point of view of a concerned Wikipedian, I think there are other far more pressing software issues that developer time and funds should be dedicated to.--Kudpung กุดผึ้ง (talk) 22:17, 22 November 2014 (UTC)
  66. Per Seraphimblade and others.  Sandstein  14:29, 23 November 2014 (UTC)
  67. Support per Seraphimblade. I also find the argument that "they're going to address issues at some point later and therefore we should keep it for now" to be terribly out-of-sync with how things should work on Wikipedia. If it is changed, let that new version be implemented by default by consensus with a discussion, it shouldn't be on by default just because some editors think it might be fixed eventually in some vague way, and that this should supersede consensus. - Aoidh (talk) 04:50, 25 November 2014 (UTC)
  68. Support - it is a community choice to enable it standard - turn it off now, and then let the community decide when to turn it (back) on (if ever). --Dirk Beetstra T C 10:06, 25 November 2014 (UTC)
  69. Support Hlevy2 (talk) 16:58, 27 November 2014 (UTC)
  70. Support Luxure Σ 10:53, 28 November 2014 (UTC)
  71. Moving from neutral to support, per 98.207.91.246's links under Neutral that show many disgruntled readers and very shaky evidence that Media Viewer is beneficial. I also think it's pretty impressive that someone began editing Wikipedia for the express purpose of protesting Media Viewer. Separately, considering some of the feedback left by readers, this feels like yet another case of releasing buggy software to the public and explaining away the detriment to readers and/or new editors by saying it will be fixed. Finally, there was already an RFC on this and the overwhelming consensus was to disable it. What's the holdup? ekips39 05:28, 29 November 2014 (UTC)
  72. Support Having seen it creep into my account whilst I was inactive, I've never seen it be beneficial. It doesn't have any improvements over the previous system, and, seemingly, has many disadvantages. Yet another mis-step in a long line of them from the WMF, although at least this isn't the second coming of VisualDestroyer. Lukeno94 (tell Luke off here) 02:57, 30 November 2014 (UTC)
  73. Throwing in my own voice in support, but mainly just a big THANK YOU to whoever put the link at the top of the watchlist notifications so that I found a discussion that provided a link to how to turn the damn thing off. --Andreas Philopater (talk) 23:49, 1 December 2014 (UTC)
    OH GOD YES Why are we still discussing this? Seriously, kill it already. This has been discussed to death, so lets see some God-<bleeping> action on the matter already before the rest of us riot over the inaction. TomStar81 (Talk) 03:57, 1 December 2014 (UTC)
    Just had a second glance and I apparently already through in my support a while back. Therefore, I am striking this support and its comment. That was m'bad, sorry all :) TomStar81 (Talk) 08:33, 1 December 2014 (UTC)
  74. Support. As I've seen stated above, the description, author, and copyright information is vital to any image viewer that's used here. My thoughts on this have already been said by Nihiltres and Seraphimblade; it's not ready, and doesn't show some of the vital information that should be displayed when files first come up. -Fimatic (talk | contribs) 00:57, 2 December 2014 (UTC)
  75. Support The new media viewer sucks. It's a big step backwards from the old viewer. It's clumsy and clunky. It doesn't always work properly and doesn't easily provide the information you could see at a glance on the old viewer. ThemFromSpace 01:18, 2 December 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) Responding futher to some of the comments particularly Seraphimblade, the claim that the MV is any less revealing of attribution and copyright is factually unsupported - just in reviewing my own image contributions and others (I only refer to my own to ward of the emotive claim that contibutors are somehow damaged) attribution and copyright information is given in the first click in MV, without scrolling, whereas on the old page the first click window provides no attribution, nor copyright, without scrolling. Even so, it remains that, per policy, the "decisions" and "acts" of the WMF take "precedence" and are not replaced by WP:Vote (see also WP:CONLIMITED) nor by WP:ILIKEIT/WP:IDONTLIKEIT. Alanscottwalker (talk) 15:06, 23 November 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)
  32. Oppose - I personally don't see anything wrong with Media Viewer (I kind of prefer it, actually). Like others have said above me, this is still under development and will probably be improved as time goes on. Perhaps we give logged in users the ability to turn it off if they don't want it, and we could also add a "View in 'Normal Mode'" button for logged out users. --Biblioworm 17:18, 1 November 2014 (UTC)
  33. Oppose per Fluffernutter. Neljack (talk) 06:49, 23 November 2014 (UTC)
  34. Oppose --Guerillero | My Talk 05:42, 26 November 2014 (UTC)
  35. Keep Media Viewer per Oiyarbepsy. The default setting should be reader-oriented, not editor-oriented, because editors have the ability to change their settings, whereas casual readers do not. —Granger (talk · contribs) 15:14, 27 November 2014 (UTC)
  36. Oppose per Oiyarbepsy. APerson (talk!) 05:01, 8 December 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)
  1. Don't have a strong opinion about Media Viewer; it's apparently helpful to new editors, and it's bothersome to established ones such as myself, but also easy to turn off. (And before I found out I could turn it off, I simply used Open link in new tab.) Was initially leaning toward support, but mainly because people like me who frequent a variety of Wikimedia projects find they must check that little box on all of them for an optimal experience, which is kind of a pain, not only because it's a lot of clicking, but because you turn it off on, say, English Wikipedia and then proceed to forget it was ever there, then head over to Commons and--surprise!--it's back. So what I really want to see is a way for this preference to be made global. ekips39 15:57, 28 November 2014 (UTC)
    Kindly don't repeat the myth that it's "helpful to new editors." It's entirely a figment of the WMF's imagination. Not even a majority of "readers" or "casual editors" of the English Wikipedia said that the Media Viewer is useful for viewing images in the WMF's own survey, let alone preferable to the file page. No "readers" or "casual editors" have written in support of Media Viewer. To the contrary, they've been unanimous that Media Viewer should be turned off. --98.207.91.246 (talk) 17:35, 28 November 2014 (UTC)
    After reading mw:Multimedia/Media Viewer/Survey, it sounds as if approval ratings are actually pretty high, and even English readers ended up with an approval rating of over 65%. It does say that it's not to be cited as conclusive, but still, I've been unable to find evidence that readers unanimously don't prefer Media Viewer (though, to be fair, I also haven't managed to prove my original assertion right). I'd be interested to see where you got this information. ekips39 03:20, 29 November 2014 (UTC)
    The plot you cite is the weekly approval ratings, not the cumulative results. As the poll went on, the response rate dropped dramatically, so the later weeks are not representative of the overall approval rating. That plot is thus scandalously misleading and I find it hard to believe that's anything but intentional given the complete deafness the WMF has shown to their users in this matter. I found the raw data once upon a time, but I can't find it anymore. The last full data I can find shows a cumulative approval rating of 37% amongst "readers" who responded in English three weeks before the survey closed. I do recall that in the final numbers, that percentage improved, but still hadn't reached majority in any English subgroup ("reader," "editor," and "frequent editor"). As for unanimity, I refer specifically to the IPs who responded on this page, on MediaWiki.org, and the original RfC. I'd link to the "community consultation" (which amounted to a sham), but it was so heavily censored under the excuse that disabling the thing was out of scope, despite that being the most commonly asked "must have." Not a single one registered support for Media Viewer. Personally, I figured out how to edit Wikipedia solely to protest Media Viewer. For all their alleged focus on readers, the only way to opt out of Media Viewer for months was to create an account. --98.207.91.246 (talk) 03:58, 29 November 2014 (UTC)
    Thanks for the info; you've convinced me. Moving to support. ekips39 05:28, 29 November 2014 (UTC)
  1. I don't particularly like the MV (or the VisualEditor for that matter), but I don't see it as much of a problem. I hate the "touchification" (everything designed as if we have touchscreens even on desktops, like Win8) of the web, and software. Even though I don't access images through it if I need info (I click the middle button, it opens a new tab with the classic image page), but I got used to the pop-up picture and quick return to the page. It's still hard to work with beyond casual viewing (for example the other available resolutions aren't shown or offered even in fullscreen, and loading takes a while). The improvements WMF added, even though they aren't enough, are a start, and I'd like to see the other points done (even those listed as "could have") I don't support MV, neither do I oppose it. I've been waiting to vote till the end of October, but I'm still not convinced either side. ¬ Hexafluoride (talk) 18:43, 1 December 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. --98.207.91.246 (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?"--98.207.91.246 (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. --98.207.91.246 (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)


RfC Close challenged, close withdrawn, RfC reopened[edit]

I have posted on the closer's talk page questioning a closing which baselessly rejects a two-to-one outcome as "no consensus". Alsee (talk) 04:17, 7 November 2014 (UTC)

I've been wondering about the exact same thing myself. The vote shows that consensus remains the same: turn it off, just like the first RFC said, and just like the WMF's own feedback suggested. That's three times that the community has spoken and said the same thing: turn off mediaviewer.

I fail to see any reason for the rather subjective closing of this RfC with "No Consensus", it's a clear confirmation of the former RfC. The WMF has now the clear duty to switch the MV to opt-in, if it doesn't, it shows utter disrespect to the communities. --♫ Sänger - Talk - superputsch must go 05:17, 10 November 2014 (UTC)

I agree, ♫ Sänger, that "WMF has now the clear duty to switch the MV to opt-in, if it doesn't, it shows utter disrespect to the communities"...However, I've actually given up investing any effort or hope in seeing any actual community-driven MV decisions implemented by WMF. Given the toxic atmosphere they (WMF) created and the cynical nature of their "engagement" w/ the Community re. MV, I've done the only things I can do to register my disagreement with WMF's abuse of the Wikipedia editors who actually produce the knowledge content leveraged by Foundation to accumulate money and influence: 1) I stopped editing almost completely (even as IP) and 2) I've withheld any monetary support and encourage others to do the same.
For me, WMF has poisoned this Project Environment and now I simply won't encourage my own marginalization by user:Fabrice Florin (WMF). WMF should just drop the pretense that they believe they have any accountability to the Community, and then we'll see how enthusiastic editors are about contributing their unpaid time to supporting such a gilded elite. JDanek007Talk 22:00, 12 November 2014 (UTC)

NOTICE: The closer has simply ceased to respond to comments on his talk page. I find him to be unwilling to participate in informal discussions of this close. I am drafting a formal request for review. I am more concerned with filing a high quality review-request than a hasty review-request. I am going to take some time refining the language and arguments before submitting it. I invite comments on my talk page. Alsee (talk) 08:50, 14 November 2014 (UTC) WP:Administrators'_noticeboard/Archive266#Close_Review_Media_Viewer_RfC Review Request submitted. Alsee (talk) 16:29, 15 November 2014 (UTC)

Just a friendly BUMP, as it should not be archived yet until the review request is decided. ♫ Sänger - Talk - superputsch must go 12:08, 21 November 2014 (UTC)
I've commented out my close. Consensus seems clear enough that people want it reconsidered. However, I will note that this whole issue seems to be drama over nothing, as there appears to be little chance of anything happening; bugzilla:67826 makes that clear enough. --Mdann52talk to me! 17:00, 21 November 2014 (UTC)
You are probably right, the WMF has shown their disdain of the communities before, and the hostile, unwarranted closure of that bugzilla is only one example of this. But consensus for opt-in is clear, I think some programmer will know now how to do this graceful (as opposed to the things DaB. did for deWP) with commons.js or whatever. An admin with this skills should simply do it, it's the right thing, the WMF definitely is on the bad side of this conflict. If the WMF again acts with brutal force against the clear will of the communities, they show, that they are completely alienated from their proper bosses, that's the communities. --♫ Sänger - Talk - superputsch must go 17:16, 21 November 2014 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────@Sänger S.G: the fact is, that is the only way for us to suppress it (that or using hacky js as a gadget, which comes with it's own issues). As per below, there is not a consensus to push this too far, too fast however, so another option may emerge later on, although I wouldn't hold your breath too much. The WMF have shown what they think of this sort of change before, especially when it has impacts on performance. Yes performance is not in our remit, but when something we do causes a lot of issues, then it is our faults. --Mdann52talk to me! 17:28, 21 November 2014 (UTC)

The directions at WP:Village Pump (technical) state what is required for any and all feature requests, and it is not an RfC result, it is a report to Bugzilla for determination. Alanscottwalker (talk) 18:17, 23 November 2014 (UTC)

The above discussion is preserved as an archive of the debate. Please do not modify it. No further edits should be made to this discussion.

Close challenged #2[edit]

A previous close on this RfC was overturned. There is an open Close Review case on this second closing at wp:Administrators'_noticeboard#Close_Review_Request_after_overturn_and_reclose for examination or comment by any interested parties. Alsee (talk) 10:28, 23 December 2014 (UTC)

Media Viewer RfC Question 2[edit]

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
No consensus to implement the outcome as proposed below as a whole. Most opposition is against the deadline and method given in the first and last terms. Such an implementation would not be possible anyway, as policy provides no foundation for the community to "direct" administrators to perform certain actions, especially those requiring the use of admin privileges. Even if a 'willing' admin would be prepared to do so, others will be opposed. The last attempt resulted in a very lengthy ArbCom case. Having said that, There is no prejudice to implement any other of the terms, as they do not require any consensus per se. Anyone is free to adress and appeal to the foundation and request a configuration change using a bug report, or do so collectively depending on the outcome question one. -- [[User:Edokter]] {{talk}} 18:39, 4 December 2014 (UTC)

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. --98.207.91.246 (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)
  16. Support as enforcement of decision in question #1 above.. StaniStani  10:02, 1 November 2014 (UTC)
  17. Support While I have serious doubt as to whether they will respect the community's will, that shouldn't stop us from being reasonable. This is ample time to implement the change if the community sees fit, and any discussion about a compromise or other changes can happen after implementation. Dennis - 20:15, 1 November 2014 (UTC)
  18. Support, in order to essentially make the antagonism reach such a height that Wikipedia dies. Grognard Chess (talk) Ping when replying 15:06, 3 November 2014 (UTC)
  19. Support as sending a strong message to the WMF, even if they block it. KonveyorBelt 18:22, 3 November 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
    PAGE
    ) 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)
  14. Oppose I agree with the above objections to the final bullet point. Neljack (talk) 06:50, 23 November 2014 (UTC)
  15. Oppose - just follow the outcome of the first RfC. We don't wait 7 days after an XfD is closed to see if something changes or someone else wants to make a statement either. Also, the WMF has all the time to comment, rebut, and/or convince while the RfC is open, no need for waiting another 7 days. --Dirk Beetstra T C 10:14, 25 November 2014 (UTC)
  16. Do we want to go through the events of this summer again? --Guerillero | My Talk 05:47, 26 November 2014 (UTC)
  17. Oppose - just follow the outcome of the first RfC and the prior RfC. Hlevy2 (talk) 17:01, 27 November 2014 (UTC)
  18. Oppose - WMF will ignore this RfC, and rightly so based primarily on WP:CONEXCEPT as well as the poor timing of it. The ultimatum is entirely in conflict with the author's stated intent to develop a more collaborative relationship. --Wolbo (talk) 11:43, 28 November 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 69.140.0.55 (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)
  1. Neutral - I do not believe we should fix the details of further procedures before Question 1 is resolved. However, I would like to use the occasion to state that we should generally avoid using Javascript in Wikipedia and related projects, such as to make it easier to use with simpler web browsers. --Schlosser67 (talk) 11:36, 5 November 2014 (UTC)
  • Neutral. I don't see how those points are supposed to solve the problem. Strong-arming the WMF into what the community wants isn't the solution or the right way to do it. Besides, the WMF isn't bound by RfCs. However, WMF needs to listen to the community, and if a wide slice of us want changes they should consider them and start a dialog. — Hexafluoride (talk) 15:56, 30 November 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. --98.207.91.246 (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 wikipedia.org, 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. --98.207.91.246 (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. --98.207.91.246 (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)
Just a timestamp to prevent archiving. HiDrNick! 16:20, 21 November 2014 (UTC)
Note to Closer and everyone. Many of the Opposes on Q2 are clearly Opposed to an "implement" result on Q1, rather than opposed to adding a 7-day hold on the implement from Q1. If it helps firm up a consensus-close, the final bullet point from Q2 could be implicitly or explicitly dropped. The close could say something to the effect of "Consensus to reaffirm and, after a 7 day hold, to implement RfC:Media_Viewer/June_2014". Alsee (talk) 19:29, 26 November 2014 (UTC)
Timestamp to archive just after question 1 : 1:00, 10 December 2014 (UTC)
The above discussion is preserved as an archive of the debate. Please do not modify it. No further edits should be made to this discussion.
A previous close on this RfC was overturned. There is an open Close Review case on this second closing at wp:Administrators'_noticeboard#Close_Review_Request_after_overturn_and_reclose for examination or comment by any interested parties. Alsee (talk) 10:28, 23 December 2014 (UTC)

Restrict title blacklist override and no rate limit to account creation for account creators[edit]

The account creator usergroup was given title blacklist override (tboverride) in order to create accounts matching the title blacklist, but the userright allows to override the title blacklist everywhere, so also for moves, pages creations and editing of title blacklist protected pages (used for editnotices, TFAs, etc). A userright allowing override only for account creations (tboverride-account) was created a few years ago, but we didn't switch back then because there was some purpose in allowing selected non-admins to edit those. Now, we have the template editor usergroup, specifically designed for this purpose, so there is no longer any need for it. And account creator is granted increasingly easily to any user who claims to need it for an event or meetup, without regard to experience; this wouldn't be a problem in itself, but this creates a pointless security risk. So we should grant them tboverride-account instead of tboverride. The same goes for the userright bypassing rate limits (noratelimit), which allows to create more than six accounts per 24 hours but also makes page moves unlimited, etc. We could request switching to a userright allowing bypass only for account creations. Cenarium (talk) 13:48, 27 November 2014 (UTC)
PS : Restricting no rate limit will also allow us to give more rate limited rights to all autoconfirmed users without taking big risks, such as a rate limited move subpages userright. Cenarium (talk) 14:19, 27 November 2014 (UTC)

Personally, I don't see the point. If people abuse the right, then it should be removed. I think granting them the full lot is a net positive, as it allows them to carry out this work. Unless we are going to make another group to allow people to bypass the blacklist to create pages etc., why reduce the pool of people who can do this? --Mdann52talk to me! 14:04, 27 November 2014 (UTC)
I agree with the blacklist bit, but not the rate limit. Reason why? If the bit is abused, it's removed. Since we already have an account specific flag, I see no reason not to use it. However, creating a flag creates some unnecessary technical work, depending on the mood of the devs. What I see more viable is adding a technical featuring that places a time limit on the bit, and automatically removes it after the time limit expires. That would definitely work for account creator bits.—cyberpower OfflineHappy Thanksgiving 14:09, 27 November 2014 (UTC)
@Mdann We already have that other group now, template editor, which is why I'm suggesting it now. Account creators only use their rights for account creation.
@cyberpower This will also allow us to give more rate limited rights such as a rate limited move subpages feature without taking any additional risk. It's what prompted me to look into this, actually. Cenarium (talk) 14:19, 27 November 2014 (UTC)

I'm confused. I understand tboverride, but I don't understand what tboverride-account is. Could you explain better? Oiyarbepsy (talk) 20:20, 28 November 2014 (UTC)

It allows to override the title blacklist when creating an account (some abusive account names are blacklisted), and only when creating an account. Cenarium (talk) 20:48, 28 November 2014 (UTC)
  • I've added an RFC tag and listed the discussion in {{Centralized discussion}} to get wider input. I'll also send an email to the enwiki account creation team mailing list. Callanecc (talkcontribslogs) 23:12, 14 December 2014 (UTC)

Temporary granting[edit]

Since this is used by a lot of class supervisors and the like, it is technically feasible to grant it for a limited period? Oiyarbepsy (talk) 20:20, 28 November 2014 (UTC)

Unlikely to be technically feasible anytime soon, see T12493. Cenarium (talk) 20:48, 28 November 2014 (UTC)

Phase 1[edit]

I think we certainly can deal with this in a step-wise fashion, without having to have new permissions set built. We frequently run across short term account creator requests at WP:PERM (for workshops, etc) and usually issue them with strong warning to only use that permission for account creation and not to override the blacklist for other reasons, or else. — xaosflux Talk 15:52, 28 November 2014 (UTC)

Change proposed
CHANGE enwiki "Account creators" group permissions as follows:
REMOVE tboverride
ADD tboverride-account (c.f. mw:Extension:TitleBlacklist)
Support
  1. As phase proposer, — xaosflux Talk 15:50, 28 November 2014 (UTC)
  2. Per above. FYI, I had already filed the bug and was asked to start a discussion - T76050. Cenarium (talk) 20:11, 28 November 2014 (UTC)
  3. Yes. Yes yes yes. I've been wanting this for literally years. I was unaware this right now existed, or I'd have pushed for this a while ago. [stwalkerster|talk] 01:41, 29 November 2014 (UTC)
  4. Absolutely - This right is designated for creation of new accounts; we should only grant them the rights necessary to create these accounts. de>tboverride-account gives them as jkuch of the ability to do this task as tboverride does, but aloows them to do less other restrcted stuff, so ot's better for this group. עוד מישהו Od Mishehu 19:24, 29 November 2014 (UTC)
  5. Support Sounds like a great idea, wish we were aware of it in the previous discussions about the user group. Callanecc (talkcontribslogs) 06:26, 4 December 2014 (UTC)
  6. Support Seems very reasonable to me. tboverride-account is what account creators require, not tboverride. Tony Tan98 · talk 15:23, 7 December 2014 (UTC)
  7. Support. Very reasonable change. APerson (talk!) 05:09, 8 December 2014 (UTC)
  8. Support Sounds reasonable, and the right is already implemented, so why not? FunPika 20:27, 14 December 2014 (UTC)
  9. Support Seems to make sense. Always found it strange that Account Creator rights came with all the extra seemingly unrelated stuff. Sam Walton (talk) 23:22, 14 December 2014 (UTC)
  10. Support Mike VTalk 00:09, 15 December 2014 (UTC)
  11. Support -Sounds reasonable. I didn't knew however, that an account-creator was able to do that much stuffs. Out of interest, Has the possible abuses mentioned in the discussion above ever been practiced in real yet by any account-creator? Anupmehra -Let's talk! 09:32, 15 December 2014 (UTC)
  12. Support If we didn't already have the correct userright I'd probably oppose as unnecessary, but since it's all in place, we might as well change it. Gigs (talk) 17:13, 15 December 2014 (UTC)
  13. Support Chris Troutman (talk) 22:13, 15 December 2014 (UTC)
  14. Support this group is for creating accounts and not anything else. A reasonable change. BethNaught (talk) 22:27, 15 December 2014 (UTC)
  15. Support - Mlpearc (open channel) 17:58, 17 December 2014 (UTC)
Oppose
Comment
This is on phab, at phab:T76050.  Revi 06:17, 29 November 2014 (UTC)

Phase 2[edit]

About the rate limits (maximum of page moves or other actions allowed per minute or some other duration). noratelimit allows to bypass all those rate limits, as well as the limit of 6 account creations per 24 hours period.

Change proposed
CREATE noratelimit-account enabling to bypass the limit on account creations only
CHANGE enwiki "Account creators" group permissions as follows:
REMOVE noratelimit
ADD noratelimit-account (c.f. mw:Manual:$wgAccountCreationThrottle)
Support
  1. So that we can unbundle from sysop or create more rate-limited rights without taking unnecessary risks, such as a rate limited subpage moves. This right was initially given to all autoconfirmed users but had to be restricted to sysops because it didn't respect the rate limits so was massively abused for page move vandalism, I've proposed to modify it so that it does respect the rate limits, making it safe to give back to autoconfirmed users ... unless some of them can easily get assigned a noratelimit userright. Yes, we're restricting a bit here, but those users aren't supposed to use it outside account creations anyway, and it allows to open up elsewhere. Cenarium (talk) 20:11, 28 November 2014 (UTC)
    I don't really understand what you are saying here. Are you also proposing a change in the way noratelimit works? Gigs (talk) 17:17, 15 December 2014 (UTC)
    Yes, but it is separate from this proposal (autoconfirmed users would have the ability to move subpages but subpage moves would count in the rate limit - so no more than ten per minute in total). My point is that it will allow us to grant account creator usergroup to any and all users who need it, without having to worry about rate limits and especially future modifications in the way noratelimit works. Cenarium (talk) 10:47, 19 December 2014 (UTC)
  2. Definitely, the proposed user right would give this group the full account-creating ability that noratelimit gives them. עוד מישהו Od Mishehu 19:26, 29 November 2014 (UTC)
  3. Support this one two, all the group to do what it should be able to do. Then we can look into giving the right to other groups. Callanecc (talkcontribslogs) 06:29, 4 December 2014 (UTC)
  4. Support as well, because this does not remove any account-creation abilities and account creators do not need to override all rate limits. Tony Tan98 · talk 15:29, 7 December 2014 (UTC)
  5. Support Account creators don't need to be able to override rate limits on anything but account creation. FunPika 20:45, 14 December 2014 (UTC)
  6. Support Again seems sensible. Sam Walton (talk) 23:24, 14 December 2014 (UTC)
  7. Support Mike VTalk 00:10, 15 December 2014 (UTC)
  8. Support -Yes, otherwise we have to rename the group to overriders, if it is not limited to only accounts. jk Anupmehra -Let's talk! 09:32, 15 December 2014 (UTC)
  9. Support Chris Troutman (talk) 22:13, 15 December 2014 (UTC)
  10. Support BethNaught (talk) 22:27, 15 December 2014 (UTC)
  11. Support It's a bit of process creep, but if the devs are fine with it so am I. — xaosflux Talk 22:38, 15 December 2014 (UTC)
  12. Support - Mlpearc (open channel) 17:59, 17 December 2014 (UTC)
Oppose
Comment

FYI, this need new phab bug, other than the one in Phase 1. (When creating new one, please CC "Revi" so I can tag it or do the patch.)  Revi 06:22, 29 November 2014 (UTC)

There is currently a bug open (T50373) for merging $wgAccountCreationThrottle into $wgRateLimits. If this happens I believe it would be possible to modify the $wgRateLimits configuration to remove (or at least set to an impossible to hit level) the account creation limit for the account creators group. Therefore we shouldn't need a new right. FunPika 03:26, 15 December 2014 (UTC)

Proposal: enable "Syntax highlighter" gadget by default for all editors[edit]

Syntax highlighter in action

In my 10 years editing Wikipedia, no other tool has been as helpful in making editing more friendly than the Syntax highlighter gadget. I can think of no reason this shouldn't be enabled for everyone (with an option to turn it off for the few who will inevitably dislike it). I am also experienced in teaching newbies about Wikipedia - I have taught over a 100 student editors - and all them unanimously said they prefer editing with rather than without this gadget. Even if one dislikes it (and I can't really think why), I'd urge you to allow it to be the default add-on for the majority whose editing experience is going to be vastly improved as a result of turning this on. Ping creator, User:Remember the dot. --Piotr Konieczny aka Prokonsul Piotrus| reply here 02:39, 5 December 2014 (UTC)

The Known issues page for this tool says it does not work with Internet Explorer. I would oppose making it the default unless it some mechanism can detect the editor is using Internet Explorer and disable the Syntax highlighter for those editing sessions. Jc3s5h (talk) 02:49, 5 December 2014 (UTC)
While I see your point, the tool, as far as I can tell, causes no problems in IE - it just wouldn't change the default behavior of IE at all. I have tested IE a bit (a few student prefer it, and I observed them too) and nobody ever run into any issue. It would be great if the gadget could work with IE, but it not working with it doesn't affect anybody much. We should not deny this tool to Chrome/Firefox users because IE users would not benefit from it... --Piotr Konieczny aka Prokonsul Piotrus| reply here 02:59, 5 December 2014 (UTC)
I haven't tried it in IE; it would need to be tested before it becomes a default for IE users to determine that it at least does no harm. The developer(s) would have to commit to testing new releases in IE to insure they don't break anything. Jc3s5h (talk) 03:29, 5 December 2014 (UTC)
I've revised mw:User:Remember the dot/Syntax highlighter#Known issues to clarify that the highlighter will not even attempt to execute if Internet Explorer is detected. This was a condition of making it a gadget in the first place. —Remember the dot (talk) 06:08, 5 December 2014 (UTC)
  • Opposed for now as I'm more concerned with the technical implications and what conflicts it may have with other gadgets that are much more powerful and useful such as wikEd (even just wikEddiff). If we were going to make some tool a default, I would much prefer this much more powerful tool. I do have a couple minor concerns with that as well, I know it had issues coexisting with the code editor, but code editor seems to have disappeared. I'd like to see much more testing of either gadget before deciding it should be a default on gadget. This seems like a decent candidate for an Individual Engagement Grant to see what more new editors and readers who may edit anonymously on occasion might think. Please ping me with a link if a proposal is made there. — {{U|Technical 13}} (etc) 04:35, 5 December 2014 (UTC)
    wikEd won't highlight syntax as you type it, and on Linux it disables the Ctrl+Shift+X shortcut for "Redo". The syntax highlighter also has the advantage of being much smaller and faster to download compared to wikEd. I'm ambivalent about turning the syntax highlighter on by default, but I definitely do not want wikEd on by default. Oh, and if you find a bug in the syntax highlighter, please report it to me. —Remember the dot (talk) 06:08, 5 December 2014 (UTC)
    • Rtd, I think you're missing my point, which may be my fault if I poorly worded it. Let me "try" to clarify. While I appreciate your tool, and am happy to hear that new users working on small pages seem to benefit from it, I think the proposal here was poorly thought out and poorly excuted in a way that I believe will doom It to failure. What I propose is for Piotrus to officialy withdraw this proposal and you and them (and I'm willing to help in any way I can) thoroughly test this script in all environments (OS/browser/skin) available and make sure it works. While working on that, I'd love to see some research done by the WMF per a grant like I suggested above to see how beneficial it is to "non-regular" editors. Based on that data, and having a fully functional script, then take some time putting together a well thought-out and worded proposal for this again. Does that sound fair and reasonable? — {{U|Technical 13}} (etc) 21:01, 5 December 2014 (UTC)
      You're probably right that obtaining a research grant and concrete data is the only way that the community will accept this. I might be able to collaborate on such a grant, but I wouldn't want to spearhead it. As far as this proposal, I likewise doubt that it will succeed, but we might get some interesting comments if we leave it open. —Remember the dot (talk) 21:17, 5 December 2014 (UTC)
      • @Technical 13, Remember the dot: I am afraid I have little experience (or time for) learning how IEG work, but I do think that it would be worthwile to have WMF examine this. Is any of you familiar with who in WMF may be interested in looking at this discussion? My WMF contacts are related to the Education Program, rather than UI development. --Piotr Konieczny aka Prokonsul Piotrus| reply here 04:43, 8 December 2014 (UTC)
  • Opposed to turning anything like this on by default. I don't need or want this feature; if others do that's fine, but let them turn it on themselves. I don't want this or other similar add-ons suddenly appearing by surprise and disrupting my volunteer work here. Townlake (talk) 04:58, 5 December 2014 (UTC)
  • Opposed I used this for a while and it was problematically slow on very large pages which I deal with often. Chillum 18:52, 5 December 2014 (UTC)
    The syntax highlighter automatically disables itself if it takes more than 100ms to execute, and that value is customizable. Maybe you'd like to suggest a lower default timeout? —Remember the dot (talk) 20:13, 5 December 2014 (UTC)
  • In my experience it causes up to 3 seconds of page freeze before it finishes disabling itself with a 100ms timer. Again, this is for very large pages. Chillum 22:57, 6 December 2014 (UTC)
    Thanks for the feedback. I just modified the code to detect earlier that it's going to time out, so hopefully you won't see delays up to 3 seconds anymore. —Remember the dot (talk) 04:27, 8 December 2014 (UTC)
  • @Chillum: Are you sure you are not confusing syntax highlighter with wikiEd? I tested both, and sh loads quickly on all pages, including long ones like this, whereas wikiEd gives me long - about 3s indeed - delays. --Piotr Konieczny aka Prokonsul Piotrus| reply here 04:43, 8 December 2014 (UTC)
  • Yes I know what I was running. There are a lot of OS/browser combos on different hardware, it is going to vary in behavior. Javascript is far from predictable across browsers. Chillum 05:07, 8 December 2014 (UTC)
  • Opposed I have no idea what this is, and am not helped by the first sentence on the linked page about it: "I've created a script that makes syntax stand out colorfully in the edit box". What on earth does that mean? Unitl a feature can be explained better than that, I see no point in it. HiLo48 (talk) 19:01, 5 December 2014 (UTC)
    A picture tells a thousand words... —Remember the dot (talk) 20:09, 5 December 2014 (UTC)
No it doesn't. Are you serious? Put yourself in the position of someone who has no idea what it is, and seriously think if that picture explains anything. I still have no idea what it is and what use it would be to me. New systems are needed if there are problems with existing ones. This looks more like an incomprehensible, really crappy solution to a non-existent problem. HiLo48 (talk) 21:23, 5 December 2014 (UTC)
I've now added a link to Syntax highlighting at the beginning of the documentation so that anyone unfamiliar with the concept will be able to more easily familiarize themselves with it. —Remember the dot (talk) 23:02, 5 December 2014 (UTC)
It would be better to try to explain it right there in clear, simple language. "...makes syntax stand out colorfully in the edit box" seems simple, but it's not clear. HiLo48 (talk) 21:20, 6 December 2014 (UTC)
I sort of agree. A picture is worth something and undoubtedly HiLo is able to see from the image that what we're talking about here is the wiki markup of ref, infobox, wikilink etc. However, from Piotrus's opening statement I couldn't guess that--I thought he was talking about the syntax of English. Remember the dot, I am sure you can explain in a sentence or two what this tool does; doing so will help your case. For now, I'm totally with Chillum; even loading the Twinkle menu is already slowing me down to the point where I'm even more than normally irritated. Drmies (talk) 03:09, 7 December 2014 (UTC)
@Drmies: I am certainly conscious of loading speeds, which is why I wouldn't suggest to make wikiEd a default tool (it lags terribly for me). Syntax highligher, however, has (both for me and my students) been a lag-free add-on, it loads in much less than a second - I'd say instantly - on any edit page I've tried and observed (on a number of computers). Have you experienced any lagging caused by it? --Piotr Konieczny aka Prokonsul Piotrus| reply here 04:43, 8 December 2014 (UTC)
@HiLo48: Is the current description page better formatted? If it is still inadequate, what further improvements would you suggest - and can you point to a gadget or feature that you think has a "best practices" description page? --Piotr Konieczny aka Prokonsul Piotrus| reply here 04:43, 8 December 2014 (UTC)
  • Oppose If we're still discussing things like reasonable default timeout values, then it's not ready to be turned on by default (and I'm actually concerned about the timeout anyway: will some editors experience seemingly random behavior where the feature sometimes works and sometimes doesn't depending on invisible factors that impact loading time?). I also have a more personal aesthetic objection: I prefer more traditional syntax highlighting where the tokens themselves are given a different style rather than changing the background. Changing text background introduces much more visual weight and clutter. I'm guessing this approach is due to a technical restriction, given that it is the only style option available. Regards, Orange Suede Sofa (talk) 21:18, 5 December 2014 (UTC)
    It's not seemingly random; if you've ever had this happen to you, you will have noticed the message that appears to explain why syntax highlighting isn't available. And yes, the background-highlighting approach is because of technical restrictions. —Remember the dot (talk) 21:30, 5 December 2014 (UTC)
  • Oppose for now, generally on account of issues, possibly including performance, but I am open to reconsidering if a better case can be made. If seems very useful despite its warts then perhaps prominent suggestion can be made on how to enable it. ~ J. Johnson (JJ) (talk) 21:15, 6 December 2014 (UTC)
  • Comment - I would just like to say how much I enjoy using the syntax highlighter tool. I am a poor typist, and I find it invaluable in finding mismatched brackets, etc. If it can't be a default tool, perhaps there is a way to advertise it to new users, since it appears that there are some who don't know of its existence. If I were an IE user, this tool would be enough to make me switch.—Anne Delong (talk) 22:54, 6 December 2014 (UTC)
    If you love it, maybe you can help others by explaining it in better words than "I've created a script that makes syntax stand out colorfully in the edit box". I'm still unclear on what it does and why it's useful. HiLo48 (talk) 23:08, 6 December 2014 (UTC)
    @HiLo48: It makes editing pages easier, because it's easier to find specific bits of markup that would normally be lost in a sea of text (this is what it feels like to me, anyway, particularly when editing larger articles). Using this gadget, markup gets highlighted in groups so you can differentiate between templates, wikilinks, formatting, HTML, and actual prose. I, JethroBT drop me a line 23:28, 6 December 2014 (UTC)
    Thanks. That's a lot clearer. HiLo48 (talk) 03:08, 7 December 2014 (UTC)
    Don't believe him, HiLo--that's just what a bot would say. Skynet, anyone? Seriously, I'm still waiting, as are others, on a good sales pitch. Obvious syntax issues aren't problematic; it's the tricky ones that are bothersome, like the stupid syntax for tables. I remember it once took three editors and an hour or so to figure out that it was an errant hard return that fucked up an infobox. Does it spot that? Drmies (talk) 03:12, 7 December 2014 (UTC)
    Although the more obvious syntax errors may not be as hard to find as the example you give, they occur much more frequently, and each one eats up a little time. The syntax highlighter makes it obvious, even to people like me with rather poor eyesight, when there are mismatched apostrophes, or when a square bracket has snuck in where a curly one was intended. —Anne Delong (talk) 12:28, 7 December 2014 (UTC)
    Actually, that's a really good example (the brackets) of something that bothers me as well--old age. But I wouldn't want another piece of interface in between with, as I expect, a relatively low payoff. YMMV, of course. Drmies (talk) 15:20, 7 December 2014 (UTC)
    @HiLo48: For me, the major advantage for new editors is that it allows them to find editable prose text easily, without having to parse through code, which can be daunting for the newbies (particularly when it comes to references or tables). Advanced editors should also benefit from the ability to quickly distinguish code from prose due to the visible background changes. --Piotr Konieczny aka Prokonsul Piotrus| reply here 04:43, 8 December 2014 (UTC)
    Anne, I think you have a good idea here: we need a good way to "advertise" gadgets and tools to editors, so that people can find the tools that they would benefit from (without having to go through dozens of items in prefs). WhatamIdoing (talk) 21:59, 8 December 2014 (UTC)
  • Couldn't the syntax highlighter be turned on and off by a toggle in the edit toolbar ? It would be off by default and the toggle wouldn't even be displayed in browsers where it couldn't work. If possible, it should remember if it's been turned on or off from one edit to the next (otherwise, add an option in preferences to turn it on by default, but it wouldn't be as handy). This way it wouldn't bother anyone not interested in it but would be readily accessible for anyone who may be interested. Cenarium (talk) 04:06, 7 December 2014 (UTC)
  • I really like this tool and used it for a while but turned it off because I do a lot of work where I open numerous pages at the same time (using multi-links) and when doing so using the Syntax highlighter the loading takes a really long time, and with it failing pretty much across the board.--Fuhghettaboutit (talk) 15:30, 7 December 2014 (UTC)
  • Thanks for the feedback. I just modified the code to improve its load time, so hopefully it will fail less often now. Honestly though, I'm a bit surprised that so many people are now complaining of performance limitations because the script rarely times out on me, even on my phone. —Remember the dot (talk) 04:27, 8 December 2014 (UTC)
    I've also had very few timeout issues. I, JethroBT drop me a line 04:33, 8 December 2014 (UTC)
  • Oppose - I've never used the tool and sure as hell don't plan on using it any time soon. –Davey2010(talk) 04:50, 8 December 2014 (UTC)
  • Oppose it as a default. I sure wouldn't want a load of highlighting to interfere with the readability of an edit window, and I'm still unsure, after reading the posts above and looking at that picture, what the heck it's supposed to tell us. What 'syntax' is referred to - grammatical, programming or what? If it's to do with the grammar, no way. I'd be happy with a spellchecker that could lightly mark 'form' when it should be 'from' (and so on and so froth), but that's very unlikely to ever happen. I think we'd find that a lot of people would just ignore the highlighting because they wouldn't know what it was for. Or what to do about it. If it's to do with coding, even fewer will know what it means. It may be fine for those that want it, but don't try to force it like the WMF do so often. Peridon (talk) 18:12, 10 December 2014 (UTC)
Looks like it is coding. Is it for 'geek level' coding, or 'page editing level' coding? Peridon (talk) 18:20, 10 December 2014 (UTC)
Note I am not opposing the existence if this tool. I have no objection to other people using it. I do object very strongly to it being foisted on all and sundry, mopst of whom won't know what it is and won't know how to turn it off. Obviously, people have already discovered it and some like it. Good for them. But enough with the defaults... Peridon (talk) 19:56, 10 December 2014 (UTC)
  • Support: I've started to use the syntax highlighter for the first time since seeing this discussion: it's brilliant. I was editing an article where the original editor had put punctuation after refs instead of before: the highlighter coloured the refs so it was much easier to skip to the end of a group of two or three adjacent refs, spot the punctuation, move it to the right place. I'll be using it regularly now. It's timed out on me once so far, but produced an obvious, and comprehensible, notice to say so. I think it might well be helpful if it was a default: the colouring clearly indicates something, and by looking at it you can see what. Without the colour, a very new editor is much more likely to accidentally edit within a reference or otherwise get in a mess. I can't see that it would do any harm to anyone. Having started this message off as "Comment", I've talked myself into changing that to "Support". Failing that, as Anne says, we need a better mechanism for telling people about the useful gadgets, rather than expecting new editors to browse the "gadgets" tab in "preferences" and work out for themselves how useful something will be. PamD 18:33, 10 December 2014 (UTC)
I agree that there should be a Glossary of Gadgets or some other name, linked from the gadgets page (and the welcome templates too, perhaps, telling people that there are gadgets there if they want them) to tell people what the gadgets do. If there was one, it would have saved me having to be a bit scathing on VPT about things that changed with only the techies knowing and understanding. Peridon (talk) 20:03, 10 December 2014 (UTC)
@Peridon: I proposed something like that (with a wireframe mockup) at mw:Talk:Requests for comment/Redesign user preferences#Gadgets. +1 it if ya like it. Quiddity (talk) 01:51, 17 December 2014 (UTC)
I'll try to look tomorrow. Currently tired and hungry... Peridon (talk) 00:03, 18 December 2014 (UTC)
To be quite honest, I can't see much difference. Adding the number of users would put me off some things, as I'm one of those who tends to think that large numbers of people can be wrong (they buy FIATs, don't they?). I'll try again later. Peridon (talk) 19:39, 18 December 2014 (UTC)
  • Opposed ( was support ) Being able to see where the beginning and ending of bolding quotes ''' and other markup is very useful especially for new editors that might not yet be used to counting brackets etc. PaleAqua (talk) 18:43, 10 December 2014 (UTC)
    Switching to opposed. The performance impact on mobile editing is too large. Having had to do a bit of mobile editing this week the performance has really slowed me down. PaleAqua (talk) 23:39, 20 December 2014 (UTC)

RfC: Simple easing of RfA[edit]

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

Discussion (easing RFA)[edit]

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

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

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

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

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

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

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

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

Support (easing RFA)[edit]

  • Support as RfC author. Alsee (talk) 14:45, 9 December 2014 (UTC)
  • Support. This is probably the most straightforward way to increase the number of sysops. I have not noticed a particularly strong correlation between the level of support candidates receive and the quality of their subsequent performance. James500 (talk) 23:17, 9 December 2014 (UTC)
  • Contrary to what is suggested below, the appointment of five new admins in November might be a statistical blip. The overall number of admins appointed this year is still down more than 35% on last year, with less than 19 days to go. November was preceded by an unprecedented two month period during which no admins were appointed. Unless another six admins are appointed in the next 18 days (plus a number of hours), we will have a worse performance than 2012, our previous nadir. To say there has been a miraculous recovery may be premature. James500 (talk) 07:35, 13 December 2014 (UTC)
  • Weak support. Per James, I don't think that those numbers matter much. It would be interesting to see, however, a list of proposals that failed in the range of 65-70%. --Piotr Konieczny aka Prokonsul Piotrus| reply here 08:42, 11 December 2014 (UTC)
  • Worthless support. Although I support the proposal, it will obviously not pass. The fact that this community is often incompetent of reaching consensus on changing things that need changing surprises me more and more every day. --Biblioworm 00:23, 25 December 2014 (UTC)

Oppose (easing RFA)[edit]

  • Oppose – Ideally, we'd move completely away from this idea of numerical approval numbers. These should be like any other Wikipedia discussion, not determined by percentage, but by the strength of what people say. The idea of "reducing the threshold" implies we should have a numerical threshold at all, and I'm opposed to that. RGloucester 23:20, 9 December 2014 (UTC)
  • Oppose per RGloucester. — {{U|Technical 13}} (etc) 23:48, 9 December 2014 (UTC)
  • Oppose. I agree with Samwalton9 and RGloucester. This proposal appears to be based on a misunderstanding of the numbers' significance (which the suggested change would promote). —David Levy 23:58, 9 December 2014 (UTC)
  • Oppose A rule of thumb should not be made authoritative which while not perhaps the intent of this proposal, would unfortunately be it's impact. I've seen an RfA with 69% go to bureaucratic discussion not that long ago, there is some flexibility in the system. PaleAqua (talk) 00:10, 10 December 2014 (UTC)
  • Oppose per RGloucester. Steel1943 (talk) 03:53, 10 December 2014 (UTC)
  • Oppose - I think RfA is currently doing a grand job and that the bar is not too high. A lot of people claim that the worst admins were those who were appointed pre-2007, the watershed year. Therefore, if the criteria have got tougher since then, those who regularly complain so loudly, bitterly, and oft uncivilly about admins in general should be content. Even with the higher post-2007 criteria, some unsuitable editors scrape through the process and then have to be relieved of their tools again later; even those who have aspired to Arbcom membership or who are WMF employees. The thing that people fear most is the discipline at RfA which for many years was regarded by the community as a place where one could be as nasty as possible, Ignoring All Rules of common decency with impunity. Reaching its peak around 2010-2011, the polution has slowly but surely abated with November 2014 showing a bumper crop of new admins - almost a miraculous recovery. No, I don't think for a moment that we need to lower the bar. --Kudpung กุดผึ้ง (talk) 11:32, 11 December 2014 (UTC)
  • Oppose There is nothing wrong with the current process, as witnessed by the five successful RfAs in the last month.  Philg88 talk 08:59, 13 December 2014 (UTC)
    • That's five out of six, and the sixth editor stopped editing entirely after being subjected to RFA. I'm not happy about a process that has lost us yet another experienced editor (this one with 25,000+ edits). Are you happy about that outcome? (Oh, wait, now that I've read your own comment at that RFA, maybe you actually are happy that we've lost another long-time editor.) WhatamIdoing (talk) 02:48, 16 December 2014 (UTC)
      • Admins need to be open to criticism. If someone leaves the project because they failed RfA then the community made the right decision. I failed my first RfA, badly. I took it okay. A few months later I was accepted. Chillum 22:57, 24 December 2014 (UTC)
    • This is just what I expected. There was a lot of talk about RfA inactivity and that led to a flurry of activity. Well, that flurry is over now. There are problems with the current process, as witnessed by the fact that periods of activity are brief. Mellowed Fillmore (talk) 16:03, 16 December 2014 (UTC)
  • Oppose especially in the absence of an easier de-sysopping process. Bureaucrats can already make someone an admin even if the overall support percent is lower than the minimum. Ca2james (talk) 16:39, 16 December 2014 (UTC)
  • Oppose I think that the current numbers, with the key point of bureaucratic discretion in making the ultimate decision, is a good standard. I support keeping it that way.--Slon02 (talk) 22:37, 24 December 2014 (UTC)
  • Oppose The current bar is reasonable. I think that closers of RfAs should consider the quality and basis in policy in each argument just like closers at AfDs do, the numbers would be far different. This is done to some degree but I would like to see "votes" be based in policy and defended if needed before counted. Chillum 22:50, 24 December 2014 (UTC)
  • Oppose Admins cannot be easily removed, so they should not be easily appointed. Townlake (talk) 00:15, 25 December 2014 (UTC)

Something more helpful than [edit] near section headers on the Help Desk[edit]

Mandruss proposed on WT:HD that [edit] or [edit source] by section headings be replaced or supplemented by something more friendly (and sensible) like [Continue discussion] on WP:Help Desk. We may as well use the same kind of hovering text box as used in the Teahouse. This is considering the fact that many of the Help Desk visitors are newbies, and after posting a query, may not know how to continue the discussion. --Fauzan✆ talk✉ mail 16:25, 11 December 2014 (UTC)

I'm for that. ;) ‑‑Mandruss  01:12, 12 December 2014 (UTC)

Hear, hear! Tharthandorf Aquanashi (talk) 01:47, 12 December 2014 (UTC)

Since there is at least no consensus against doing so, WP:BOLD? --Fauzan✆ talk✉ mail 18:21, 17 December 2014 (UTC)

Conduct a new "new editors" test of VE[edit]

The precise way this test will be conducted is TBD. this means how will it be executed, and what will be the metrics of success/failure. i think similar test was run in the past, either here on enwiki or elsewhere. if memory serves, this is sometime referred to as "A/B test".

I opened a discussion in WP:VPT recently suggesting exactly this, and asking the community for comments. several people responded with "oppose", but as far as i could understand their arguments, they were mainly of the types "MWF sould never have done it - there are better ways to spend development resources", and "I do not like/hate VE, so i will oppose anything related to it".

I could only find a single viable argument: the use of VE by some editors cause many wrong "nowiki" to appear in the wikicode, which causes damage.

as luck would have it, the latest code version (came out after the discussion started) fixes the "nowiki" problem.

i think VE made enough improvement in the (almost) year and a half since WMF tried to force us to use a half-baked product. i think VE is ready now for a new round of testing. once we get some stats, we can decide if we want to ask for some specific changes and improvement, or are we ready to enable VE again. peace - קיפודנחש (aka kipod) (talk) 21:16, 13 December 2014 (UTC)

If this is done in a way that forces new editors to use it, then I will have to vote against this. If it is given as an option, then I might be for this. Tharthandorf Aquanashi (talk) 00:03, 15 December 2014 (UTC)
there is no "forcing" anyone to use it. even on wikis where it's no experiment, and is activated by default for everyone, it's always an option: every editor still has "edit source" (i.e., activate the current wikitext editor) on every editable page. peace - קיפודנחש (aka kipod) (talk) 01:17, 15 December 2014 (UTC)
It's quite possible such tests have been done throughout the development of VE, by the development team. That should be intuitive to any competent team, and I have no reason to believe that the VE team is not competent. In any case, if they haven't been doing that, they should be the ones to do it, and the suggestion should be made there, not here. ‑‑Mandruss  01:25, 15 December 2014 (UTC)
the tests (aka A/B test) were done on numerous wikis, ttbomk including enwiki, and the conclusion was to activate VE. after activating VE (and making it the default for anons), the enwiki community revolted, and after some unpleasant discussions with VE team, we turned it off (to the best of my knowledge, we and dewiki are the only projects that did that - i might be wrong here). i doubt WMF will conduct a new test on enwiki without the community's permission, so you can read this proposal as "allow WMF to conduct VE test on enwiki again". peace - קיפודנחש (aka kipod) (talk) 17:40, 15 December 2014 (UTC)

A few comments:

  • VisualEditor is available almost everywhere, either as an option or as by default.
    • VisualEditor is enabled by default for all users (logged-in and logged-out) at about half of the Wikipedias, at MediaWiki.org, and a few other smaller projects.
    • At Wiktionary (except sv and fr; Wiktionary is exceedingly template-heavy) and Wikisource (needs integration with ProofreadPage), it is not available at all.
    • At all others, you have to enable it in the Beta Features tab of Special:Preferences.
  • VisualEditor is not offered by default to about half of the Wikipedias because of language problems. Some (e.g., Welsh) need a more robust special character inserter. Some (e.g., Japanese) need special language support. Some (e.g., Chinese) need really complicated language support.
  • VisualEditor is additionally not offered by default (you can opt-in if you want) at four large Wikipedias:
    • Dutch, where it was never enabled by default, because of template-related problems;
    • German, where it was never enabled by default, because of a community request to wait for further features, like table editing;
    • English, where it was turned off in September 2013, because of community frustration with wikitext corruptions; and
    • Spanish, where it was turned off a few months later.
  • It might be possible to set up another round of A/B testing with new editors here. I'd have to ask, and Analytics is frankly overloaded, so I can't guarantee anything. This would probably involve making VisualEditor be enabled by default (i.e., they get immediate access to both editors) for 50% of new user accounts for maybe a week, and then following all accounts for a few weeks, and seeing if any differences appear (e.g., if new editors with access to VisualEditor are more or less likely to edit on a second day than editors without immediate access to it). (Note that the length of the trial would should be determined by the stats people, with the goal of producing a statistically significant result. That might not be exactly one week, but I think (based on comments they've made in the past) that 50% of newly registered accounts at en.wp for about a week is often sufficient.)
  • The user testing that's been done more recently is more intensive, for example, video-taping new editors as they try to accomplish specific tasks. This eliminates some problems (none of their edits appear on wiki) and introduces others (none of you can see what they did or hear what they said). It has some advantages (you can ask testers direct questions about why they did something) and some disadvantages (they're not necessarily "real" editors, who have chosen an article that interests them and want to improve it). On balance, though, it seems to be useful.

If there is interest in requesting more testing, then please let me know. Whatamidoing (WMF) (talk) 03:18, 16 December 2014 (UTC)

Question: If the probably was that it was previously causing wikitext errors, then what exactly is the testing for? We should know if it's still generating errors from the registered editors that use it. So if the wikitext problems are fix, we should just enable it for everyone without testing. Oiyarbepsy (talk) 15:42, 16 December 2014 (UTC)
That was a main cause of nowiki tags among experienced editors; brand-new editors never made that mistake. There are some other problems that cause nowiki errors as well, like a stray space added when you split one paragraph into two. You can check the current status, if you want: https://en.wikipedia.org/w/index.php?title=Special:AbuseLog&wpSearchFilter=550 This link shows nowiki tags added in both the wikitext editor and VisualEditor. The last time I did a spot-check, VisualEditor was still producing more than its fair share of nowikis, but maybe 70% of nowikis are coming from then wikitext editor. Whatamidoing (WMF) (talk) 20:59, 18 December 2014 (UTC)
See also:
No easy answers. For me, VE is getting more usable. Insert pictures, add a wikitable row, etc. If VE gets easier referencing tools, we're in business! (mw:Citoid, mw:VisualEditor/Design/Reference Dialog) And then we need to put this slooooow VE thing on steroids! --Atlasowa (talk) 15:05, 18 December 2014 (UTC)
Citoid is currently expected for January 2015. I'm not sure which project will see it first. It will be released for VisualEditor initially, but James F (the product manager) wants to add it to the wikitext editor, too. Access to fully formatted citations in two clicks would be valuable for everyone, not just for users of VisualEditor. Whatamidoing (WMF) (talk) 20:59, 18 December 2014 (UTC)
Very glad to hear that, Whatamidoing (WMF) :-) January 2015 sounds great and not forgetting wikitext refs sounds even greater! I just looked at the latest VE Reference Dialog Design and the prototype.
I have 2 suggestions to make:
1) The reference dialog "insert URL + autofill, preformatted -> done" is too dumbed down:
We want editors to check / correct the autofilled ref, but you currently need an extra-click "edit" to be able to do that ("the user can choose to edit it"). I don't expect the citoid autofill to work perfectly for every URL, nobody can expect that. The form for editing the ref should be shown by default, not hidden behind extra-clicks. As the VE ref dialog works currently, it invites lazy unchecked autofill-refs. Show the autofill-ref in a form! Have a look at makeref and templator by magnusmanske, these tools do this well (blue-framed fields are mandatory, white ones optional; please fill out as many as possible).
icon to insert reference: The 3rd one is obvious and preferred! Not the brick factory icon (first)!
2) The ref icon (insert reference). It is very unintuitive. This has been pointed out over and over and over again.
http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Icons_are_incomprehensible
http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2013_07#Reference_Issues:_Omnibus_Edition
http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2013_07#Mystery_meat_navigation
http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2013_07#References
http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2013_07#Attempting_to_add_a_reference
http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2013_07#User_experience
http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2013_07#Refs_and_templates
https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2013_8#Icons_are_incomprehensible
https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2013_12#Editing_a_footnote
https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Toolbar#Icon_for_Reference
https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2014_1#The_new_reference_dialogue
There is even a bugreport for the ref icon, which was "provisionally closed". And we're still stuck with the incomprehensible brick factory icon, which some WMF designers seem to prefer. I think the "ref [1]" is a lot better to understand. And yes, make [1] blue if this gets us better references, damn the design guidelines! But, who decides this?
How about this: Let's make a survey with 3 alternatives. Or not really a survey, rather a banner with user test, for potential new users, aka readers and editors. Show them the editbar full of icons (including the 3 ref icon options) and ask them to insert a reference, count which icon they click. Bonus: This test/survey would also work as a tutorial / invitation to edit (some time, not immediately) / participation tool / VE announcement. Win-win? --Atlasowa (talk) 12:47, 19 December 2014 (UTC)
On 1), I believe that the design is supposed to automatically show the entire citation (look at the third image) as it will display to the reader. In terms of getting people to check the ref, this is probably more effective than showing them a screenful of filled-in boxes, with no idea how the data in those boxes will be used. In my own testing (which has focused on PubMed and Google Books), the accuracy has been remarkably good, and sending me to an editing panel would not have been as useful as showing me the finished output.
On 2), the desktop site does not use those icons; the cite menu is identified with the word "Cite" (or the local language equivalent). There are some appearance changes on the way. You can see them at MediaWiki.org now. (Type something at the bottom of the sandbox to see the 'Save' button's new color.) None of the changes involve replacing the "Cite" label with the book/bookmark icon. Whatamidoing (WMF) (talk) 19:52, 19 December 2014 (UTC)
On 1) Citoid UI: Go use the citation dialog with real URL refs from random WP articles, not "focused on PubMed and Google Books". "showing the finished output" is not "getting people to check the ref", it is getting people to lazily insert whatever the software autofills. You're making a big mistake if you do no real-world testing, invite lazy unchecked autofill-refs and wait for another community-shitstorm. Citoid is a great thing, please do not fuck it up.
On 2) insert ref icon: Whatamidoing (WMF), your response is false, or at least very misleading. You pretend that the brick-factory ref icon is not used. Go to https://en.m.wikipedia.org/wiki/Flotation#/editor/0 you see the brick-factory ref icon! Or go to MediaWiki.org VE editing, click on "cite", what do you see: the brick-factory ref icon! Go to the latest VE prototype, what do you see: the brick-factory ref icon! You write "There are some appearance changes on the way" - will they remove the brick-factory ref icon, on desktop AND mobile, yes or no? Please do not dismiss the suggestion by pretending that the icon is not used, only to have the brick-factory ref icon all over the place in the coming months. Read the bugs closing comment "I'm going to provisionally deem this solved with the new icon." --Atlasowa (talk) 17:03, 21 December 2014 (UTC)
  1. My testing exclusively involves whatever sources I'm actually using in my everyday volunteer editing. I tend to use books and journal articles rather than random websites. Using the tool while actually writing encyclopedia articles presumably counts as "real-world testing" by most standards. Beyond that, I'm not the QA team, so it's not my job to do systematic testing. In theory, the product isn't ready for that type of testing yet (which is what I'm told every time the service goes offline while I'm writing).
  2. I do not understand why putting the entire, fully formatted citation in front of people is going to make them less likely to check the citation than putting a small fraction of the template's parameters and data in front of them. You are asking us to show all editors this. Notice that the screenshot displays just three parameters out of the eight in this example (it could be many, many more). The plan is to show editors the entire citation:
    • Fitzgerald, Carol (2001). The Rivers of America: A Descriptive Bibliography. Washington, D.C.: Oak Knoll Press. p. 199. ISBN 9781584560326. 
    If there were an error in this citation, then which of these two displays do you think would make it more likely that the editor will see it? The one that shows you all the information, including formatting, or the one that shows you less than half the information, and if you're motivated to check for more details, then you're welcome to scroll down?
  3. I never said that the book icon (with a ribbon bookmark) was not used at all. I said "On 2), the desktop site does not use those icons" to identify the Cite menu. The "Cite" menu is labeled with plain words on desktop (or "<MediaWiki:Visualeditor-toolbar-cite-label>" in your local language). You have supplied a link to the mobile web site. Mobile's design is necessarily constrained by the width of a smartphone, which could be less than 3 inches wide; as a result, when many options need to be provided, you really cannot spell out words. (Inside the desktop menu, there are multiple icons, but those icons are next to words that remove any possible confusion.) I know that you don't like the book icon, since you've said so repeatedly. User testing (with new editors) showed that the word "Cite" was much easier to understand than any type of icon. That's why the desktop design is using words. Whatamidoing (WMF) (talk) 01:07, 23 December 2014 (UTC)

Proposal to auto-transclude /doc subpages[edit]

There are two fundamental components of a Wikipedia article:

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

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

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

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

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

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

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

Moving forward[edit]

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

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

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

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

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

Support (documentation)[edit]

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

Oppose (documentation)[edit]

  1. Oppose adding this directly to core; Oppose adding it as an extension; Support a gradual process resulting in an on-by-default gadget. — {{U|Technical 13}} (etc) 20:04, 15 December 2014 (UTC)

Comment (documentation)[edit]

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

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

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

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

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

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

Proposed technical change: show pages expanded from redirects on Special:NewPages and Special:NewPagesFeed[edit]

Special:NewPages and Special:NewPagesFeed show all new pages, but they do not show pages that previously existed as a redirect but have been re-purposed into a content page. This is a significant loophole, allowing the creation of articles (many of which are necessarily content forks) that bypass the patrol pages entirely. I propose showing these pages on both aforementioned special pages, with a new filterable tag on NewPagesFeed, "Created from redirect". My questions:

  1. Does support exist for the proposed change?
  2. Is the proposed change technically feasible?

Any and all feedback is appreciated. (Edit: I've expanded the proposal to include Special:NewPages, in case anyone is still using it; I don't believe this significantly changes the proposal.) Swpbtalk 14:28, 16 December 2014 (UTC)

(Second edit: filter 342 can already catch these pages; it's just a matter of re-enabling the filter and getting the pages displayed on the patrol pages.) Swpbtalk 20:06, 18 December 2014 (UTC)

  • I suppose that could be another one for Wikipedia:Village pump (idea lab)#Bot tagging of edits if that idea gets off the ground. — {{U|Technical 13}} (etc) 15:24, 16 December 2014 (UTC)
    I don't know about the technical limitations, but it seems these pages could be tagged by the edit filter, or whatever mechanism is currently used to identify new pages. I'm not opposed to bot tagging, I just don't want to tie this horse to that cart. Swpbtalk 15:28, 16 December 2014 (UTC)
    The filter catching those edits was deactivated for being too expansive, the proposal for bot tagging of edits precisely aims to address those performance issues, since the bot would do the job instead of the edit filter. Cenarium (talk) 12:55, 19 December 2014 (UTC)
    Too expansive in what way? Was it catching false positives, or just causing too much server demand? I suppose it doesn't matter how the pages get tagged (filter or bot), as long as they can be added to the patrol lists. Swpbtalk 17:06, 20 December 2014 (UTC)
  • Support if technically feasible. It probably is, since it does catch pages moved from user land to article land. Oiyarbepsy (talk) 15:38, 16 December 2014 (UTC)
  • Support We can easily tag these edits with an edit filter, and you could use the older Special:NewPages to detect them by supplying the tag name there. Updating Special:NewPagesFeed to show these tagged edits will require WMF involvement, I believe. — MusikAnimal talk 21:32, 16 December 2014 (UTC)
    Not sure how the tag alone would help. Special:NewPages still won't show the pages unless they're newly created. Swpbtalk 01:00, 17 December 2014 (UTC)
    Ah of course, duh! I guess Special:RecentChanges is where you'd do your patrolling. Less than ideal. — MusikAnimal talk 17:22, 17 December 2014 (UTC)
    Not necessarily WMF involvement, but certainly developer intervention. Although most of the devs who understand NewPagesFeed are/were WMF people. — This, that and the other (talk) 04:56, 17 December 2014 (UTC)
    Indeed. I'm planning to enter a Phabricator ticket once it seems there's a consensus. Swpbtalk 14:00, 17 December 2014 (UTC)
  • Support. Good idea if technically feasible or if not. The tags would be easy to use; just go through the edits that the tag catches. We just need to be careful to mark only the edits that cause the redirect to stop working (for whatever reason), because we don't want it to start flagging redirects that have just gotten marked with {{R from modification}} or a comparable template. Nyttend (talk) 02:34, 17 December 2014 (UTC)
    Indeed. I imagine the filter would look for the removal/breaking of the "#REDIRECT" syntax, rather than the addition of anything else. Swpbtalk 14:06, 17 December 2014 (UTC)
  • Seems like a very sensible idea. It may be technically quite difficult to implement, though. Currently Special:NewPages is essentially a filtered version of Special:RecentChanges that only includes changes marked with the "N" flag. To check whether a page has gone from being a redirect to not being a redirect would require loading and inspecting the old revision of the page to see whether it was a redirect. This would have to be done for every entry in the recent changes table, which would be very taxing on the server. There could be ways around this but they would be quite complex to implement and would require very careful design on implementation on a huge wiki like this one. — This, that and the other (talk) 04:56, 17 December 2014 (UTC)
    Wouldn't it be fairly easy to implement a "created from redirect" edit filter/tag, and modify the special pages to include those pages, in addition to those with an "N" flag? Swpbtalk 14:04, 17 December 2014 (UTC)
    Implementing the filter may be easy, I don't really know. (Yes, it's true that I am an "edit filter manager", but that doesn't really mean I know anything about the edit filter...) This could technically work by adding a flag to the edit filter system, allowing us to create filters that "add the page to Special:NewPages". But that in itself may be difficult to get working. — This, that and the other (talk) 11:08, 19 December 2014 (UTC)
  • Oppose. I am concerned this might result in increased erroneous attempts to delete (especially on the inapplicable grounds of notability) plausible redirects and mergeable content, which is already a problem. (The redirects will already have been patrolled once and identified as plausible). I think a list of such changes should at least be kept wholly seperate from NewPages. I am not convinced there is much need for this. No statistics have been offered as to the proportion of these pages which are invalid content forks. James500 (talk) 04:32, 18 December 2014 (UTC)
    To James500: Neither plausible redirects or mergeable content would be harmed under this change. The proposal is not for redirects to appear on NewPages; it's only for ex-redirects to appear. These are, for all practical purposes, totally new pages that have never been patrolled. And it's reasonable to assume that the proportion of such pages that are inappropriate will be at least as high as that among regular new pages, and probably higher; but at any rate, that's what patrol is there to sort out. Plausible redirects are in fact less likely to be deleted under this proposal, as they will no longer pose a risk of later becoming an un-patrolled article. And mergeable content created on an ex-redirect will actually be seen and merged (or at least tagged for merging), instead of languishing in un-patrolled obscurity as now. I hope you will re-examine your assumptions about how the proposed change works, and re-assess your position. Swpbtalk 13:08, 18 December 2014 (UTC)
  • Ex-redirects are not practically equivalent to unpatrolled new articles. They are not new. They have already been patrolled once and found to be unsuitable for deletion. The difference between expanding a mainspace redirect and expanding an article seems small to me. It is not reasonable to assume that ex-redirects are as likely to be innappropriate as new articles. We redirect sub-topics, and a sub-topic of a notable topic is quite likely to be notable at our stage of development, which has incorporated only a small fraction of the information available from reliable sources. It isn't proposed to confine this to the expansion of redirects marked as redirects from an alternative name. In any event, we should proceed on real statistical evidence and not guesswork. I have seen far too many attempts to delete obvious redirects and mergeable content to assume that this proposed innovation will not result in mass nominations of them. I have even seen arguments at AfD along the lines of 'this should not be redirected/merged because it is non-notable' or 'we have an AfD on anything non-notable even if it is an obvious redirect'. If we do have an "expand redirect log", we will also need a "BLAR log" so that we can revert innappropriate blank and redirects. James500 (talk) 03:36, 19 December 2014 (UTC)
  • There are quite a few missing steps in the logic that leads from this proposal to "mass nominations" that lead me to believe you have no interest in actually understanding the proposal. Swpbtalk 18:56, 20 December 2014 (UTC)
  • I understand the proposal perfectly. I also understand that lists of pages or edits can be used in a manner for which they were not intended.
  • Do you? Because the "list of pages or edits" being created here specifically does not include redirects; it's actually impossible for it to be abused to delete redirects, as you say. As for any other kind of "abuse", there's no reason to expect it. NPP is patrolled by inclusionists too, and they consistently force deletion-taggers to justify themselves. I myself frequently chastise editors who apply CSD tags outside their bounds. Any deletion taggings brought about by this change would surely face the same level of scrutiny. If that level of scrutiny isn't enough for you, then your argument isn't with the present proposal, but with the entire patrol system, or possibly with the current standards for inclusion. Swpbtalk 13:35, 22 December 2014 (UTC)
  • Another issue is that, compared to new pages, these redirects are more likely to be on the watchlists of editors who regularly edit articles within the subject area of which the redirect is a sub-topic. There may therefore be no need for an ex-redirect article to be "patrolled" by editors who know nothing about the subject because it has already been examined by editors who are familiar with the subject. James500 (talk) 16:08, 21 December 2014 (UTC)
  • I reiterate that the pages we're talking about have not "already been examined" in any meaningful way, because of course the new content may bear no relation at all to the original target. Certainly, the quality of the original target article has nothing to say about the quality of the content on the newly un-redirected page. Swpbtalk 13:35, 22 December 2014 (UTC)
  • That has nothing to do with what I said. It is possible watchlist a redirect. If a user has an article on his watchlist, he is likely to watchlist all the redirects to that article as well. If one of those redirects is subsequently expanded it will show up on the watchlist, and the user will presumably see it and examine the ex-redirect article. So, if you are worried that redirects to an article might be innapropriately expanded, all you have to do is find them with Special:WhatLinksHere and add them to your watchlist. Problem solved.
  • Another concern that I have is that, in addition to the lack of statistics and examples presented here, I cannot remember a single instance of a redirect actually being innapropriately expanded. James500 (talk) 08:37, 23 December 2014 (UTC)
  • I'm glad we don't have to rely on your memory. Your baseless "mass nominations" fear aside, you've still never presented a credible drawback to the proposal. Swpbtalk 13:33, 23 December 2014 (UTC)
  • Uh. What? Special:NewPagesFeed shows redirects. By extension, it'll show pages that started as redirects. Ironholds (talk) 15:53, 18 December 2014 (UTC)
@Ironholds: I believe this is discussing old redirects being changed into articles (ie. de-redirected), as opposed to new redirects being created. --Mdann52talk to me! 17:37, 18 December 2014 (UTC)
  • Oppose These pages aren't new. This circumstance is more like a page move or regular content editing and so is best dealt with by the RecentChanges. Andrew D. (talk) 18:05, 20 December 2014 (UTC)
    • It's completely unlike a page move - in a page move, the content doesn't change at all. In this case, an entire new encyclopedia article can be created, and never once patrolled. Swpbtalk 19:03, 20 December 2014 (UTC)
  • Oppose including in new pages lists but support listing them in some sort of former redirect list. PaleAqua (talk) 18:34, 20 December 2014 (UTC)
    • You've stated your position, but you've provided no rationale for it. This is a discussion to uncover worthwhile considerations related to the proposal, not a vote on whether you like it. Swpbtalk 18:59, 20 December 2014 (UTC)
      • The conversion of redirects into new pages seems like a different type of issue to watch for, ( specifically content forks ) and it seems to me that it would better to be able to watch from them seperately. The actions for content fork vs an unsuitable new page also seem like they would be different. Allowing different groups to watch different sets of page actions seems like a better use of wiki-editor power. PaleAqua (talk) 23:36, 20 December 2014 (UTC)
        • That's a reasonable concern, they are somewhat different issues — but I would argue that they're not so different as to demand a separate watchlist. For one thing, new pages are already frequently content forks, and regular NPP'ers understand what to do in such a case (merge any new sourced content, then redirect; or if there's no mergeable content, redirect or speedy the page, depending on the plausibility of the title as a search term). I think we should avoid splitting watchlists too finely, to avoid having underwatched lists. Swpbtalk 13:42, 22 December 2014 (UTC)
  • Support if technically possible - these pages probably have nearly all the problems that new pages do. Even new pages may end up being redirected, and redirects which have been turned into articles are more likely to be restored to their redirect version than deleted. עוד מישהו Od Mishehu 07:33, 21 December 2014 (UTC)

History diff link in deletion discussions[edit]

During XFDs, it can be helpful to see what a page looked like when the discussion began, especially if it's been heavily edited since that time. I'd like to see all of the XFD headers include a link to the page as of when the XFD discussion was created; for example, this would be in {{afd2}} and {{cfr2}}. Is this possible? I'm talking about an autogenerated link dependent on some sort of timestamp, vaguely comparable to the timestamp that's given when we add {{prod}} or {{db-c1}} to a page. No point in discussing adding this if it won't work. Nyttend (talk) 02:32, 17 December 2014 (UTC)

This could easily could be added to a tool such as Twinkle. However, I don't think it would be possible for those who don't use scripts and gadgets, without making people manually fetch the oldid (revision ID) of the current revision of the page when they nominate it. Lua doesn't seem capable of fetching oldids. — This, that and the other (talk) 05:13, 17 December 2014 (UTC)
I think it should be possible within the wikitext. Would the following work?
  1. Make the deletion tags added to the article ({{Afd}} etc.) add a parameter such as |revision={{subst:REVISIONID}}
  2. Use Lua to retrieve the revision number from the article source (e.g. with a regex .*$|revision=($d+)$}$}.*)
SiBr4 (talk) 10:54, 17 December 2014 (UTC)
Sounds good, if technically practical to do automatically. עוד מישהו Od Mishehu 07:29, 21 December 2014 (UTC)

Posted at Wikipedia talk:Twinkle, I asked those editors to comment here. Oiyarbepsy (talk) 06:10, 22 December 2014 (UTC)

Sounds brilliant (if possible). This way if the article has been greatly improved since the AfD began, it avoids making the proposer look like in idiot, and if it's been "gutted" then it gives "Keep"-ers something to work with. — Preceding unsigned comment added by Eman235 (talkcontribs) 13:31, December 22, 2014‎

Copy and paste detection[edit]

We have had this bot running on articles associated with WP:MED and WP:PHARM for 6 months. When it flags a concern more than half the time it is correct. In the last few months we have had more than 200 true positive issues it has helped us fix. Wondering if other projects are interested in having this run on their articles? Does require human follow up. Doc James (talk · contribs · email) 06:17, 18 December 2014 (UTC)

Added as a suggestion for bot tagging of suspected copyvios. Cenarium (talk) 12:24, 19 December 2014 (UTC)

Bot tagging of edits[edit]

<-- User:!DoNotArchiveUntil! 05:43pm, 25 December 2014 (UTC) --> I propose that we allow bots to tag edits, and request the implementation of such a feature. The edit filter (and other extensions) can tag an edit before it is saved. In the end these edits are not very effective at catching certain type of edits, and performance is a constant concern since each check makes saving an edit a tiny bit longer. On the other hand, a bot would tag an edit after it has been saved, which may take a few seconds due to processing and API lag, but removes any performance cost. There is already a request at phabricator, T3189, however this is for all users, not just bots, and it has stalled; a suggestion was made at the community level, to request it get moving along. Importantly though, I am proposing tagging for bots, and only for bots, for three reasons: to gain a strong consensus, which would create less issues, that will have to be solved in another way or time, and no need for a devs, to create a user interface, since bots need only the API, meaning that it gets implemented faster (of course this doesn't prevent devs from working on a UI for manual tagging, but whether we would enable this separate feature is for another discussion). The following are possible uses :

  1. edits identified as very likely to be vandalism, but not with a high enough likelihood for rollback or where rollback is prevented due to 1RR - for ClueBot NG (talk · contribs)
  2. edits containing urls that are potentially suspicious, but with enough legitimate uses that rollback is inappropriate - for XLinkBot (talk · contribs)
  3. student edits (looks like that extension doesn't have much support so we can't expect it to tag on its own any time soon)
  4. redirects transformed into articles - tagged by 342 (hist · log) but disabled for performance reasons
  5. probable cut and paste moves - for CorenSearchBot (talk · contribs) and incorporating 164 (hist · log)
  6. suspected copyright violations - for EranBot (talk · contribs) and CorenSearchBot (talk · contribs)
  7. cross namespace moves, this way we'll be able to filter them easily by tag in the move log 185 (hist · log) (disabled for performance), including the more specialized de-userfying 630 (hist · log)
  8. various template removals : speedy 29 (hist · log), images 59 (hist · log), copyvio 224 (hist · log)
  9. new articles : very short 98 (hist · log), large unwikified 180 (hist · log), 'autobiographies' 148 (hist · log), interrogative pages 289 (hist · log) (disabled for performance), pages created without categories 650 (hist · log)
  10. some other tag only edit filters such as inappropriate redirects 151 (hist · log) (disabled for performance) or undoing antivandalism bot 323 (hist · log)

We would also need a mass untag functionality available for admins in case of mistaken tags. Each bot tagging task would have to be approved. Cenarium (talk) 10:34, 13 December 2014 (UTC)

Definite support - tags are designed for automatic detection of suspicious edits, which can then be reviewed by human users to determine how bad they actually are. The ability for external automated programs to do this would be very helpful. עוד מישהו Od Mishehu 09:43, 21 December 2014 (UTC)
Huh? WP:Tags is all about brief messages that the software automatically places; they can't be placed by bots. Are you asking for a new software feature, enabling bots to tag edits after they're made? Are you asking for bots to be allowed to compile a list of edits that would otherwise be tagged? Unless you're saying that a bot should compile such a list (e.g. Special:Diff/123456789 expanded a redirect; Special:Diff/23456790 blanking, etc.), I don't see how your idea would work. If you want bots to go around compiling lists, I think you have a good idea. Nyttend (talk) 19:43, 21 December 2014 (UTC)
  • According to mw:Manual:Tags, To add a tag to a revision, recent changes entry, or log entry, use ChangeTags::addTag(). implies that tags can be added to anything that is logged after the fact. — {{U|Technical 13}} (etc) 20:30, 21 December 2014 (UTC)
Support in principle While I support in principle—especially for tags that would have too much impact on the server to be placed by an edit filter, but could still easily placed by a bot—there seems to be a few questions that need considering. For example is there a time window in which tags may be placed? How does this interact with recent changes? Should there be a recently tagged page? Will the tags added by bots be distinct from those added in other ways? If not what happens if a bot bug results in a large number of pages tagged that need to be revert where some of the pages already had and should keep the tag ? PaleAqua (talk) 20:23, 21 December 2014 (UTC)
To answer one question, we should make it mandatory that bots identify themselves in the tag itself, such as tag 12345, possible vandalism identified by Cluebot. Oiyarbepsy (talk) 22:04, 21 December 2014 (UTC)
  • Support This is a great idea for a way to tag edits without relying on EFs that can blow up and lock up the wiki if there is a small typo. — {{U|Technical 13}} (etc) 20:30, 21 December 2014 (UTC)
I would suggest starting with Cluebot NG - its borderline cases could tag edits as possible vandalism identified by Cluebot. It doesn't sound like any particular action is required to implement this now if we want, so a trial with a trusted bot may be the way to go. Oiyarbepsy (talk) 22:04, 21 December 2014 (UTC)
  • Support starting with Cluebot NG (talk · contribs) and gradually extending to other bots. Better than Edit Filter. Tony Tan98 · talk 05:41, 22 December 2014 (UTC) (10:11, 23 December 2014 (UTC): However, k6ka has a valid point below about perceived newbie biting if we start with ClueBot NG.)
  • While I am in support of this proposal, I do question us starting with ClueBot NG. For instance, ClueBot NG does list edits it knows is or suspects as possible vandalism but does not revert to reduce false positive rate - see User:ClueBot_NG#ClueBot-NG_RC_Feeds. You can see these edits with a tool like STiki. The idea is that it might cause a bit of newbie biting if CBNG makes a false positive here and tags their edit with "possible vandalism", rather than listing it on its IRC channel where a STiki user can make the final decision in private, without the editor knowing that the bot had done what it did. --I am k6ka Talk to me! See what I have done 13:50, 22 December 2014 (UTC)
  • Support per above. MER-C 02:39, 23 December 2014 (UTC)
  • Support. If this is only used for purposes similar to the edit filter, maybe a configuration page similar to Special:EditFilter could list the approved uses and standardised tags. If suggestion 1 under "possible uses" is acceptable, this could also be made available as an alternative to rollback if any anti-vandalism tools use the API. Peter James (talk) 18:59, 24 December 2014 (UTC)

Community authority over admins[edit]

There have been a lot of de-sysop proposals around here lately. I am coming here with my suggestion on how to make sure admins are more accountable to the community without making drastic changes to policy.

I will start by pointing out what current policy already allows:

  1. The community can come to a consensus that a person be blocked, including an admin
  2. The community can come to a consensus that a person be given an interaction ban, including an admin
  3. The community can come to a consensus that a person be given a topic ban, including an admin
  4. The community can come to a consensus that a person be banned outright from Wikipedia, including an admin.

This is all true right now. There is however a culture that admins are not to be blocked or sanctioned, while this attitude is prevalent it does not enjoy consensus. I think the community needs to show some teeth and actually propose and come to consensus to do these things when it is needed.

So far this is not a policy change proposal but rather a plea that users who think admins are not accountable use the authority the community already has.

I do want to propose one addition to policy:

  • If the community comes to a consensus to ban and administrator from Wikipedia then that administer shall have their admin bit removed "under a cloud".

Existing policy allows the community to hold admins accountable. If an admin is harassing a user, IBAN that admin. If an admin is poorly closing AfDs regularly then topic ban that admin. If an admin is acting downright poorly then block that admin for whatever length of time you see fit. BAN that admin if the issue is serious enough and you can get consensus.

I am saying all of this as an admin, and I will challenge any admin who thinks that community sanctions are not applicable to them. The community is failing to use the authority they already have, lets try using it before trying to get more.

I propose the one policy addition only to satisfy those we think we need community desysoping. Really it is redundant as if an admin unblock themselves they will lose their bit for sure. I could care less if the addition is made but I do feel strongly that the community needs to be more assertive with what they already have. Chillum 04:00, 22 December 2014 (UTC)

The wording, as drafted, seems to me unclear as to whether it applies to bans in general or only full bans (as bans can be IBANs and topic bans and whatnot). I'm also not sure that it is wise to link so strictly the two things. That is not to say that admins should not be accountable to the community, but merely that there could be cases where the community should have the option of not desysopping a person when a ban is issued. Snowolf How can I help? 04:05, 22 December 2014 (UTC)
I agree with your point. I think it is redundant too, I added it to appease those who insist on community desysoping. It makes no different if you desysop someone who is banned anyways.
This is more of a plea that the culture change to be less afraid and use the authority they already have. Chillum 04:16, 22 December 2014 (UTC)
I obviously agree that the community already has ample authority and powers to police their admins and can do so as it deems fit. Sysops are not special users, and are subject to all policies just as normal users, and they can be restricted just as normal users, regardless of their hats, including obviously being advised not to use their hats in any or all ways. We, as administrators can operate merely with the consent and authority of the English Wikipedia community, and should we loose its confidence, we have to accept that and act accordingly. Snowolf How can I help? 04:19, 22 December 2014 (UTC)
(edit conflict × 2) I'm planning on winding down my participation in these matters for a little while, but I have a very important question. Why is it that people don't make a big deal out of the community's ability to impose something as draconian as a ban, while they're nervous about letting the community have an easy desysopping procedure? In my opinion, simple desysopping is a much less severe "punishment" (so to speak) than an all-out site ban. As I've said before, there are times when an admin is far from deserving a ban, but is just not fit to have the admin toolkit. A desysopping procedure independent of bans is needed. Otherwise, we'll have unwanted cascading effects. --Biblioworm 04:21, 22 December 2014 (UTC)
The community, as I understand it, can impose a targeted ban to prevent an administrator from using their powers. There's no need for any restriction on a user's editing, if the concern is merely with their administrative actions. There are many kinds of ban that are not an all-out site ban :) To answer your question as to why procedures for the community removal of administrative privileges struggle to be supported, I think that might have a lot to do with specifics more than the concept in general. I think more editors think that admins should be accountable to the community, but the best way to do so can be difficult to agree upon :) Different people have different concerns about different methods of proceeding with removals, I think. Snowolf How can I help? 05:32, 22 December 2014 (UTC)
Well, then, if the community can essentially ban admins from using any of their tools, why can't that same ease be applied to desysopping? Or, perhaps, we could institute a system where the community impose "targeted bans", as you put it, and the admin is automatically desysopped if the ban is ever violated. --Biblioworm 16:20, 22 December 2014 (UTC)
Any user will end up blocked if they violate their ban. If an admin unblocks themselves then they will lose the bit. If your goal is to make admins accountable and to have the community exert authority over them then existing powers are enough. If that is not enough and you need to remove the bit too then ask yourself why? Are you seeking accountability or penalty? Chillum 18:25, 22 December 2014 (UTC)
I have no objections for full-banned admins being desysoped - after all, if theyt can't even be trusted to edit, how can they possibly be trusted to do administritive actions? However, TBAN and IBAN shouldn't apply here - the admin can probably still be trusted to take administritive actions outside ther ban. עוד מישהו Od Mishehu 08:07, 23 December 2014 (UTC)

I don't understand Chillum's proposal. My opinion is that if the community is allowed to decide any kind of ban, it must be based on a violation of an previous rule (uncivility, abuse of powers, etc). That is, I disagree with the community banning a user just because of a vote. --NaBUru38 (talk) 15:25, 24 December 2014 (UTC)

Question: It's asserted that "The community can come to a consensus that a person be blocked, including an admin", etc. How? The RFC/U process, which allowed for a fairly deliberate discussion, has just been eliminated. wp:ANI's focus is not on reviewing a person's impacts in depth; the focus is on shutting down incidents quickly and there is delight in applying "boomerang" to anyone--especially non-admins--suggesting seriously any action about an admin. There's no concern for fairness, and no deliberate process. wp:3RR in practice is also dominated by quick judgment with no concern for fairly identifying fault. ARBCOM is not a venue for the community to decide something, it is set up for arbitrators to exercise their arbitrary power to arbitrarily settle something (and has its purposes). What venue for the "community" to discuss and come to a consensus about an administrator, is available? I don't see how the community has any such powers that are asserted. --doncram 22:09, 24 December 2014 (UTC)

? RFC/U by design could not take any action. Community banning occurs at AN and sometimes AN/I and has for a very long time. Alanscottwalker (talk) 22:42, 24 December 2014 (UTC)

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

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

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

Discussion[edit]

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

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

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

When you begin TWA, it warns you that it makes automated edits on your behalf, though indeed it does not specifically warn you that it will place badges on your user page. I don't think it's a problem, because the badges can be removed as with any other template. However, it may be worthwhile asking the TWA maintainers to modify it, say, such that you get a choice each time like: "Add badge to my user page" / "No thanks". BethNaught (talk) 17:07, 26 December 2014 (UTC)
Thanks for that. If the automated edits stay in the rookie's "User contributions" list, of course, they cannot be removed from there. That could be objectionable for some. Townlake (talk) 17:10, 26 December 2014 (UTC)
That's true, of course; they do stay in the contributions log. (See for example Special:Contributions/BethOne, where I did a test run. The whole process takes about 50 edits.) It does warn you that it makes edits before beginning, as I say. I don't think I would judge any TWA player adversely if their subsequent contributions were good (and I don't see why anyone should), but I can understand why you say what you do. BethNaught (talk) 17:15, 26 December 2014 (UTC)
Right, thanks for verifying. I wouldn't judge adversely either, but a real new user won't fully understand that warning and would wind up with a permanent "n00b Badge" in their contributions. In some corners of this project, wrongly or wrongly, that could cause the new user to be treated with kid gloves and pats on the head. Townlake (talk) 17:58, 26 December 2014 (UTC)
You have a good point, Townlake. That's actually one reason why I've never used it myself, since I don't want to be labeled as "the user who took that childish TWA when he was a newb". When I read Wolfowitz's MFD, I actually understood his point a little bit, namely the part about not wanting to attract immature children to this site. Despite the fact that there are some exceptionally mature ones, I've seen enough of them in my relatively short time here to know that it would not be in the best interests of the site to mass attract them and make them think this is some utopian MMORPG. --Biblioworm 18:08, 26 December 2014 (UTC)
Yes, Biblio, we're on the same page. To be clear, I like your proposal, and I don't want to overblow my concern here (honestly the "n00b Badge" would not be that big a deal), but I don't want there to be whiplash if the proposal is implemented and then new users are surprised. It only takes one or two malcontents to waste a lot of editors' volunteer time here. Townlake (talk) 18:13, 26 December 2014 (UTC)

Support[edit]

  • Support: I have tested TWA myself. While I have reservations about the extent of gamification, presenting it as one of a set of ways to learn about Wikipedia is appropriate because it allows people to choose the style of tutorial they like. I think it provides an adequate primer to the key skills for Wikipedia. BethNaught (talk) 16:26, 26 December 2014 (UTC)

Oppose[edit]