Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia
  (Redirected from Wikipedia:PROPS)
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, 118, 119, 120, 121, 122, 123, 124, 125
Centralized discussion
Proposals: policy other Discussions Ideas
  • A proposal to gradually offer both wikitext and VisualEditor to new accounts
  • Discuss proposals for celebration of the upcoming 5 millionth article on English Wikipedia
  • An RfC for a banner alert campaign on the threat to Freedom of Panorama in Europe
  • An RfC for a four-day delay period for deleting abandoned AfC submissions under G13
  • An RfC to permit trusted non-admins to close TFD discussions with uncontroversial delete outcomes
  • A proposal to forbid IPs from participating in the RfA process.
  • A proposal to elevate WP:BRD to guideline status
  • An RfC on "edit in Wikidata" links, for templates using Wikidata

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


New button: View source[edit]

I propose that for each article, in every section, alongside the "Edit" button, we have another button, "View source". This would allow editors to see the code which generates the section text without opening the section for editing. Editors can then get a quick look at how specific formatting is accomplished without extensive hunting through the tutorials for explicit instructions, but without the slight danger of accidentally modifying the section.

For example, matrices have fairly complicated code. Suppose that someone wanted to insert matrices into a section of an article which does not already have matrices in it. The editor could simultaneously view the source code in another article which has matrices neatly formatted, while creating the matrices in the first article. — Anita5192 (talk) 17:48, 13 June 2015 (UTC)

I don't really see how this would be different from clicking edit on the page; that shows you the source markup. I've not heard accidentally saving changes being an issue, but if you do you can just undo the edit. Something similar that could be useful is a source page that has clickable links which take you to the relevant markup help pages or contains links to the templates being used in the article, this would help new users find exactly how things are being done in another article without having to hunt around. Sam Walton (talk) 17:56, 13 June 2015 (UTC)
@Anita5192—an excellent idea! Viewing source code and manipulating working markup is the best way to learn. Using a live edit view is an invitation to learn Murphy's Law; Wikipedia is the encyclopedia anyone can edit—but no one wants to do so accidentally. I began here copying source to my sandbox, and I worry still about unintentionally making a live edit. And @SW—undoing is only a fix if you realize you made an accidental edit (think multiple pages open, it's late, and your coffee's worn off).— Neonorange (talk) 22:15, 13 June 2015 (UTC)
@ Neonorange: My thoughts, exactly! Face-smile.svgAnita5192 (talk) 18:11, 14 June 2015 (UTC)
I also think it's a great idea. ~ ONUnicorn(Talk|Contribs)problem solving 16:16, 16 June 2015 (UTC)
I agree it would be good as a gadget option.Godsy(TALKCONT) 06:00, 1 July 2015 (UTC)
Nothing wrong with it as a gadget option.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  23:18, 17 June 2015 (UTC)
There's a gadget in zhwiki which can be adopted here.--GZWDer (talk) 14:39, 25 June 2015 (UTC)

Revisiting trivia, and pop-culture / cultural references / cultural impact material[edit]

FYI: Pointers to relevant discussions elsewhere.
  1. Proposal to develop a content guideline on encyclopedic relevance: There is no question that the Wikipedia community has a general consensus on the handling (mostly rejection) of trivia, on the fact that not all popular culture material is trivial, and that material on cultural influence/impact is a necessary part of encyclopedic coverage. We have no content guideline covering this, but a number of essays that include some very well-accepted advice and rationales. It should not be too difficult to develop a draft guideline for WP:Proposal from the best-regarded of these points, tied to WP:Core content policies. The last time this was attempted was many years ago, when inclusion of trivia was advocated by many editors. Much has changed since then. I advocate a descriptive as much as prescriptive/restrictive approach: Codify existing best practices, rather than introduce new rules.
    Please comment at WT:Handling trivia#Proposal to develop a content guideline on encyclopedic relevance.
  2. Proposal to restart WikiProject Popular Culture with a new focus: It still has years-old material about "saving" trivia, and has of course become inactive. It should be repurposed improve actually encyclopedic cultural references material, and perhaps to speed the removal of unsourced, unencyclopedic trivia.
    Please comment at WT:WikiProject Popular Culture#It's time we realign this project's priorities and reboot it.
  3. Proposal to deprecate the "In popular culture" heading: Other headings can more accurately describe the (proper) content of such sections, and be much less likely to attract the addition of trivial cruft. "Cultural references" seems to be the most popular alternative, but only address one of at least 3 rather different classes of / approaches to such sections.
    Please comment at WT:Manual of Style/Trivia sections#Deprecating the "In popular culture" heading.

Relatedly:

I think that together, such efforts may lead to better handling of encyclopedically relevant cultural-references and cultural-influence material, and a faster general reduction in unencyclopedic pop-culture trivia.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  11:58, 14 June 2015 (UTC)

  • Trivia is not the same thing as "In popular culture". The academic study of the humanities, as well as much general reader interest, involves in considerable part the study of the influences of one topic or work or author upon others: this is the basis of which intellectual history is made. Similarly, even what we call trivial uses are significant as part of social history--what people put in the background of their works can be very meaningful. (I have for example seen academic discussions of the significance of the product brands chosen to characterize individuals in F Scott Fitzgerald's novels.) What needs reforming is our rules that restrict this coverage. At present we have an uneasy equilibrium, and accept a good deal of this material from major topics, but even this is continually challenged. I'd like to have more, but I am concerned about the possible effects of upsetting the balance. I think the rational position for those on either side of this issue is to let the compromise stand.Only a zealot really wants to gamble on all-or-nothing. DGG ( talk ) 00:05, 17 June 2015 (UTC)
    • I agree on all of that up to "the rational position for those on either side of this issue is to let the compromise stand". There's no all-or-nothing gamble. It's a pre-proposal to see if there's enough interest to write a proper relevance (not trivia or pop-culture only) guideline that absolutely takes all of that into account. If it didn't and would "risk all", then fail it. I would like us to be able to go through a collective-brain rearranging process like we did with notability (formerly a lot of stuff like "importance", "fame", "notoriety", etc.) and come up with something useful and not detrimental. As someone else said on the other VP, "relevance" is a broader matter. If we can separate relevance from the format (short factoids, allegedly "trivia", but often relevant and just needing integration) and from the focus (media mentions/appearances/homages/parodies/etc, allegedly "trivia", but also often relevant), we'll be getting somewhere. Especially if we also can provide guidance on how to ID material that is well-developed and seems encyclopedic but actually is irrelevant.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  23:07, 17 June 2015 (UTC)
      • Hello, I've long claimed that Wikipedia had policies on article relevancy, but not on content relevancy. That is, there's a rule on whether a topic deserves a standalone article or not, but we don't have specific rules on whether a fact deserves to be mentioned on a given article or not. This goes much further than pop culture trivia. --NaBUru38 (talk) 19:41, 24 June 2015 (UTC)
        • Perhaps you would like to read WP:DUE, which is our policy on whether a fact deserves to be mentioned in a given article or not. WhatamIdoing (talk) 19:44, 24 June 2015 (UTC)
          • Dear WhatamIdoing, that section of the NPOV policy deals only with majority vs minority points of view, except for the phrase "Undue weight can be given in several ways, including but not limited to depth of detail, quantity of text, prominence of placement, and juxtaposition of statements." That's far from a specific rule. I mean, it doesn't really explain whether Babe Ruth, Rosa Parks or Donald Knuth should be mentioned in the article United States. We need a proper policy con article content. --NaBUru38 (talk) 17:43, 25 June 2015 (UTC)
            • Yes, that is our policy: don't give undue weight to any material, of any kind, in any way, on any article. If you want something more detailed, then you should consider drafting a guideline. WhatamIdoing (talk) 22:28, 25 June 2015 (UTC)

Gradually enabling VisualEditor for new accounts[edit]

TL;DR: The recent test results show that there's no negative impact from offering VisualEditor to newly registered accounts, alongside the wikitext editor. Here's a plan for how we might offer it more widely in a gradual manner.

Hi everyone,

Research results[edit]

Yesterday, Aaron shared the results and his analysis of the recent VisualEditor A/B test. We designed the test to determine how giving users of new accounts the choice between the visual and wikitext editors would affect their activities on the English Wikipedia, and the effects that would have on the English Wikipedia's means of curating new revisions. In particular, we wanted to find out whether it would enable more damage (e.g. vandalism and sub-par good-faith edits) to take place, and whether it would add any further burdens to the work of the community of change patrollers.

The A/B test indicates that giving users the option to use VisualEditor does not result in extra vandalism, nor does it lead to lots of poor-quality edits. More specifically, we found that:

  • New editors who use VisualEditor create no additional burden on existing community members. They are no more likely to be reverted or blocked than editors who are offered only the wikitext editor. In fact, there's a slight reduction in the burden on admins when VisualEditor is enabled; and
  • New editors who have VisualEditor available to them make as many good edits as those with just the wikitext editor, and stay around for just as long.

You can read more detail of the data collected and the means of analysis on Aaron's research page on meta.

Improvements[edit]

I think these results are related to improvements made to VisualEditor over the past few years. Since 2013, we've learnt a great deal about making VisualEditor a good experience for our new and existing editors alike, not least through working with the various wiki communities where VisualEditor is already enabled for all users.

We have processed thousands of bugs, tasks and feature requests surfaced by community. Since June 2013, we have made over 100 production releases, each with improvements for usability, stability and/or performance. We ran several surveys, including a targeted exercise to improve VisualEditor's function and design and make sure improvements reflected community concerns. We held monthly "office hours" for editors to share their concerns, and later switched to holding open weekly triage meetings to make that sure we prioritise fixes and improvements around the most important aspects for you.

Lately, we've been focussed on making simple edits as easy as possible for users who don't yet know wikitext, so that they can focus on making valuable contributions to Wikipedia. Some of the features and improvements that support this include:

  • the auto-filled citation generator, which automatically creates a templated citation from online sources based on a URL or some academic reference IDs like DOIs;
    VisualEditor - demonstration of auto-cite creation, flat.png
    View as animated GIF

  • a better link editor, which suggests links from the wiki with redirect and disambiguation pages flagged, and an image and the Wikidata descriptions for each article to make it clear where you're linking;
    VisualEditor-link tool-search results.png
  • we introduced a context panel, which shows some details about things you click on as you edit. For example, clicking a link will show you where the link goes; clicking a reference will show you the citation as it will show up in the references list; and clicking on a template will tell you which template is being used, with an 'edit' button to fix things that you want to change;
VisualEditor-context menu-link tool.png
VisualEditor - Editing references 1.png
  • you can now add columns or rows to tables (and do more complicated things, like merge cells) at the click of a button, which even very experienced users have said is a good deal easier to understand than staring at the wikitext. We've also expanded browser support to cover well over 90% of all our readers and editors, and worked with major browser makers to help iron out bugs in their browsers which VisualEditor has to work around; and
    VisualEditor table editing add and remove columns.png
  • load and save performance, which I know was a particular concern for many of you, has hugely improved.

I'd like to thank all the editors who have helped us improve VisualEditor over the past two years. The millions of times people have used VisualEditor has given us vital data points to analyse and improve. The time people have taken to find, report, and highlight bugs as they arose on-wiki has been superb. The community participation on-wiki, on Phabricator and elsewhere, and the help we've had from some volunteer developers and community gadget authors, has been great, and has really driven forward integration with existing tools and workflows.

Proposal[edit]

Given these results and the recent improvements, I think it is now time to undertake a slow, steady process in which we will gradually make VisualEditor available to more editors on the English Wikipedia, alongside wikitext editing. My current focus is strictly on new accounts, who I think have the most to gain from having VisualEditor available. To be clear, this would not involve changing the interface for existing editors. As always, existing editors here can opt-in to having VisualEditor available at any time via Special:Preferences.

So, what specifically would a graduated release for new accounts look like?

I always keep the impact on our current editors, patrollers, and curators at top of mind as I consider changes. Because no amount of testing and triage will ever catch every possible issue, I do not want to make changes quickly, and we have several processes in place to respond rapidly if anything does arise. To minimize any impact if problems do occur, we would gradually enable VisualEditor for new accounts, starting at 5%, which is about a dozen new active editors a day. This portion of new accounts would be able to choose which edit tab they wanted to use each time they edited: VisualEditor or the wikitext editor. The remaining 95% would get the existing experience, of just having the wikitext editor.

If that initial roll-out goes well, we would slowly and incrementally raise the threshold, making VisualEditor available to more new accounts. Throughout the process, we'd be carefully monitoring the on-going impact on both the new users and the wider community of experienced editors. Our regular public triage meetings will continue to take place, and I would be happy to continue the conversations there too, or on Phabricator. The pace of the roll-out would be determined by how well each step worked for all concerned, and the process would probably take a month or two before the choice reached all new users.

Again, this process would only affect newly created user accounts. Only once we're confident that the community's existing edit triage processes are faring well with the change for new accounts do I think we should look at enabling VisualEditor for logged-out users, as there are a huge number of edits made every day by IPs, and I don't want to swamp the community if anything does arise during subsequent testing.

As always, I would appreciate your thoughts on this proposal.

Yours,

Jdforrester (WMF) (talk) 21:15, 17 June 2015 (UTC)

Discussion - Gradually enabling VisualEditor for new accounts[edit]

Should new, logged-in editors have the option of using both wikitext and VisualEditor, or only wikitext?
Support – Editors should have both wikitext and VisualEditor. Oppose – Editors should see only the wikitext editor.
VisualEditor read edit source edit view history.png

Support proposal: Give (only) new editors two buttons, and let them make their own choices for each edit.

YesY Wikitext (for everyone)

YesY VisualEditor (second button)

Wikitext read edit view history buttons.png

Oppose proposal: New editors should not have a choice. They should only see the wikitext editor.

YesY Wikitext (for everyone)

N VisualEditor (hidden)


  • Absolutely yes. I have wanted this for a long time, specifically for new users. As a volunteer I participate in a lot of local Wikipedia trainings. We get some really smart people in the room—people who by all means should be Wikipedians. While we have been teaching our participants about wikitext formatting, it's an annoying obstacle. I want people who volunteer the time to write Wikipedia articles to be able to spend their time doing that—writing articles, and not finagling over whether it's two apostrophes or three apostrophes and so on. This makes the job of a Wikipedia trainer that much easier, and it makes editing Wikipedia a much more engaging the experience. I was at the National Institutes of Health, and someone needed help with a citation. I told him about our little secret VisualEditor, and boom! He had access to a full-on citation editor. This is the kind of experience that should be accessible by more people. I see a lot of promise in VisualEditor, especially since it is a lot better than it used to be, and I support this gradual launch approach. Harej (talk) 21:32, 17 June 2015 (UTC)
  • Oppose If your study shows that new editors using VisualEditor "make as many good edits as those with just the wikitext editor, and stay around for just as long", what's the reason for the switch? What problem are you trying to fix? I'd want to see evidence that VisualEditor has a significant positive impact on editor retention and constructive contributions before it's rolled out. There are still significant issues with VisualEditor, and we shouldn't have to start cleaning up <nowiki/> tags everywhere for no good reason. --Ahecht (TALK
    PAGE
    ) 21:39, 17 June 2015 (UTC)
    It would be nearly impossible to study VE's impact on "editor retention" without VE being rolled out to a large number of existing users for a long period of time. If VE's rollout is contingent on that evidence being available beforehand, then it will never be rolled out. And as for the "problem" VE seeks to resolve, it seems self-evident to me: most potential contributors in the world don't know how to edit wikicode, and VE removes that barrier of entry, allowing for more content creation and a better encyclopedia. That seems particularly important now, given that Wikipedia's editor base has been continuously shrinking over the past several years. –Prototime (talk · contribs) 06:02, 18 June 2015 (UTC)
    But it was studied recently. The May 2015 study looked at a population of 20,000 editors, half of whom had VisualEditor enabled as default. Of these two groups, nearly identical numbers (3386 vs 3363) made an edit, nearly identical numbers (2502 vs 2551) edited more than one article, nearly identical numbers made productive unreverted edits (1778 vs 1772), and an identical number were still editing 3-7 days after registration (287). If anything, this shows that Wikicode doesn't scare off new editors any more than VE does. --Ahecht (TALK
    PAGE
    ) 19:47, 18 June 2015 (UTC)
  • Support enabling I haven't used VE much recently, so I'll have more comprehensive thoughts on it in the future (I'm going to re-enable it now!), but from everything I've seen this is something the Wikipedia community, especially new editors, would really benefit from. Sam Walton (talk) 21:41, 17 June 2015 (UTC)
  • This sounds like a reasonable strategy for deployment. I hope future major changes are rolled out in this way as well. Seraphimblade Talk to me 21:46, 17 June 2015 (UTC)
  • Strong support - I've been using VE lately for almost everything that I can and it's wonderful. I've been teaching newbies how to use it and they love everything about it, and are able to make productive edits much faster and able to do more complicated tasks much more efficiently. It is so much better than it used to be - really, it's now what it should have been when launched - and I think new editors can greatly benefit from a gradual launch. Keilana|Parlez ici 21:48, 17 June 2015 (UTC)
  • Support: While I find the regular edit mode easier to use, it does not appear to me that it would not really hurt users who would opt not to use it in any way to have it enabled by default, but it would help with people who would use it but don't opt in for whatever reason. Jo-Jo Eumerus (talk) 21:50, 17 June 2015 (UTC)
  • Tentatively support per the pro arguments above (I can't see any I disagree with, and I really want to see if it increases new recruits), but tentative per the second concern of Ahrect: the bugs. Do we have any info on when these will be fixed? Ahrect's first concern I don't share: We'll only know if it has measurable positive effects if we try it on a larger scale for a while at least. We can always turn it off again later (though should only do so for new new editors, not recent ones already using VE. PS: I personally loathe the VE, but I can understand why some people love it. Either you are a WYSIWYG person or you're a coder [or sometimes both, in different environments/contexts].  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  22:57, 17 June 2015 (UTC)
  • Support. VE has greatly improved, and I think it's been ready for use on enwiki for some time now. Opposers would do well to remember that VE is vastly easier than the wikitext editor for new users to learn. — Mr. Stradivarius ♪ talk ♪ 00:37, 18 June 2015 (UTC)
  • Strong oppose – New editors need to learn how to edit the encylopaedia properly. They needn't be misled with training wheels, such as these. The only way for a new editor to understand the workings of Wikipedia, the technical details, the intricacies of editing, is through familiarity with Wiki markup. That familiarity comes from experience. I'd say that the Visual Editor should only be allowed for editors who have acquired a prerequisite experience in markup, so as to ensure that all editors have a good foundational understanding of the way Wikipedia articles are constructed. RGloucester 00:50, 18 June 2015 (UTC)
    Strange though it may sound to some, but VE is the proper way to edit, instead of trying to put all the 6433 lines of Parser.php into your head ;) Max Semenik (talk) 01:08, 18 June 2015 (UTC)
    Honestly this is reading to me as "I had to do things this way so now everyone else has to". People should not be expected to learn what is, with parser functions, a turing-complete programming language to be able to edit and it's ludicrous to say that new users should be expected to immediately "understand the workings of Wikipedia, the technical details, the intricacies of editing". Forcing someone to learn, in complete idiosyncratic detail, how systems work and then allow them to use something simpler and more intuitive to inexperienced people is precisely the opposite of how any process should work. To extend your analogy, if VE is training wheels, your proposal is giving a five year old a monster truck (because they can't drive if they don't know how a combustion engine works!) and then hoping they aren't terrified. Ironholds (talk) 14:35, 18 June 2015 (UTC)
    This. Veteran editors seem to forget that wiki markup was supposed to be an easy to use, simple mechanism for non-technical people to create well-formed content. That it has devolved through feature creep into a monstrous entity, requiring several megabytes of help pages and style rules to use correctly, is something to be ashamed of, rather than proud; even if every one of those features has proven essential to build an encyclopedia. VE may not be perfect yet, and I consider it phylosophically inferior to markup, but it recovers the spirit of "anyone can edit through dead-simple tools" that we should have never lost. Diego (talk) 15:30, 18 June 2015 (UTC)
    "Anyone can edit" isn't now, nor should it ever have been, the most important criteria of an actual reference work. As we've grown, "if every one of those features has proven essential to build an encyclopedia" has grown in importance. That shouldn't surprise or disturb anyone.—Kww(talk) 17:41, 18 June 2015 (UTC)
    So, you don't think that having a diverse and large user base is critical for achieving a neutral and comprehensive reference work, overcoming the systemic WP:BIAS? Well, I do. Diego (talk) 23:08, 18 June 2015 (UTC)
    Would you also require everyone who has a blog to understand and use PHP before using a text editor to make posts? What useful purpose could that serve? There is zero benefit in requiring contributors to jump through unnecessary learning curves to provide content to readers. Readers only care about the end product; it makes no difference to them whether contributors created the end product through intricate mastery of a programming language or simply using a text editor. Let's not make things more difficult for contributors for the sake of tradition and being "proper". –Prototime (talk · contribs) 17:48, 18 June 2015 (UTC)
  • Support definitely. I think it is definitely possible to understand the "workings of Wikipedia" from VisualEditor. For the deeper technical details, sure, you need to delve into the wikitext of templates etc.; but most editors are simply not interested in doing that - their goal is to improve article content. VisualEditor has come a long way in the last two years; I use it regularly for the majority of article editing, and although there are a number of known issues, they will not affect the majority of our new users who perform more straightforward edits. Source editing is always available from the "edit source" tab alongside VisualEditor's "edit" tab in all cases, for those who prefer to use it. — This, that and the other (talk) 02:50, 18 June 2015 (UTC)
  • Oppose Support; editing tables in VE is much easier than in wikitext. As long as the Wikitext editor remains an option, at this point I believe that VE is a net positive to enable at the start. I do think that VE should show what the equivalent markup would be in wikitext, however, as editors should still learn wikitext due to its greater versatility. StringTheory11 (t • c) 04:42, 18 June 2015 (UTC) Changing to oppose based on the fact that the WMF wants to label the VE button solely as "edit". Something in beta should NEVER be presented as the "proper" way to edit, and frankly, VE is not the "proper" way to edit; rather, the wikitext editor should be the one labeled "edit" and the VE should be labeled "edit (VE)" or something. Really, WMF, it's not that hard to admit that you're not always right. Also the fact that the WMF will not enable Citoid for the text editor makes it seem to me that they will eventually want everybody to use VE, which is pure elitism. StringTheory11 (t • c) 01:28, 26 June 2015 (UTC)
    • As we discussed on your talk page, the citoid service is not intended only for VisualEditor. It will be possible to use citoid in the wikitext editor when it supports a greater variety of sources.
      From the comments below, it sounds like most editors would rather discuss the labels on the buttons in a later discussion. Whatamidoing (WMF) (talk) 00:14, 27 June 2015 (UTC)
    • Nothing is this proposal addresses what the edit buttons would be labeled, so I'm confused by your decision to reverse your support on that basis. This proposal is simply to roll out the use of VE. Some editors were discussing below what the buttons should be called, and as Whatamidoing pointed out, that discussion has indicated that it is a separate issue worth discussing if this current proposal gains consensus. –Prototime (talk · contribs) 21:28, 28 June 2015 (UTC)
  • Oppose Basic foundational bugs to the way VE handles template/table interaction still prevent using it from editing awards lists (see https://en.wikipedia.org/w/index.php?title=Alice_in_Chains&veaction=edit&vesection=17), pop music articles (try to edit the tables in https://en.wikipedia.org/w/index.php?title=Bette_Davis_Eyes&veaction=edit&vesection=7), and pretty much any of our myriad of articles that use templates to enforce consistent formatting across groups of similar articles. These bugs have been known for years and never addressed. Its whole approach to template editing makes it difficult for editors to see how our standard articles are constructed, and that leads to an inevitable and inexorable erosion in our ability to maintain consistent styling across projects.
    Further, we still have issues with stray "nowiki" tags being scattered across articles. Until those are addressed, the notion that VE doesn't cause extra work for experienced editors is simply a sign that the metrics used to analyze effort were wrong. Jdforrester, can you explain how a study that was intended to measure whether VE caused extra work failed to note that even with the current limited use, it corrupts articles at this kind of volume? Why would we want to encourage such a thing?—Kww(talk) 05:33, 18 June 2015 (UTC)
    • The nowiki edit filter is not specific to VisualEditor (phab:T53421). In the last 24 hours, it appears that there were about 16 edits using VisualEditor there.
      The A/B test was looking at overall edit quality, perhaps what you could call "all-cause mortality" for edits. Errors that are typical of each editing environment are treated equally by the test. A reversion due to someone mis-typing the number of [[brackets] or '''apostrophes'' in the wikitext editor (which happens many dozens, if not hundreds, of times a day) is equal to someone reverting because Parsoid added an unwanted nowiki tag as far as the test is concerned.
      Also, I'm unable to reproduce your bug report about editing the tables. I copied them to my sandbox, and, as you can see, I can edit them in VisualEditor. I was able to change both content and structure for these template-based tables. Can you be more specific about the problem you were encountering, and tell me what web browser you're using? (You can post the details at Wikipedia:VisualEditor/Feedback if you prefer.) Whatamidoing (WMF) (talk) 18:42, 18 June 2015 (UTC)
      • These are old bugs, Whatamidoing (WMF). Look at the display of the "result" column in https://en.wikipedia.org/w/index.php?title=Alice_in_Chains&veaction=edit&vesection=17 and note the corrupt display of raw HMTL formatting. Try to change {{nom}} to {{won}}. If you can figure it out, then see if you can tell me in good faith that it was easier or more obvious than changing "nom" to "won". As for https://en.wikipedia.org/w/index.php?title=Bette_Davis_Eyes&veaction=edit&vesection=7, I see that you did, indeed, add a Dutch100 entry. How on earth does an editor add the row to the table to add that? For music articles, that's probably the stereotypical newbie first edit, and I can't figure out how to do it for the life of me.—Kww(talk) 21:58, 18 June 2015 (UTC)
        • In the previous diff, I was removing the Dutch100 item. Here I change the nominated and won templates, and inserted a new Dutch100.
          The complex transclusion editor is, well, complex. The first change is pretty easy: insert a new template, slide it down to the correct position, and delete the old. The second took me a couple of minutes (it took two tries to because I didn't realize that it was validating the contents and therefore wouldn't accept "Kww" as a chart name ;-) I don't think the complex transclusion editor is mentioned in the basic user guide, but I can leave instructions on your talk page, if you really want to do it (there are two methods, depending on whether you know the wikitext for the template). However, what I'd rather see is both the wikitext there being simplified, and VisualEditor’s support for complex tables being extended, so that doing this is all quite easy for everyone, no matter what editing environment they want to use. Whatamidoing (WMF) (talk) 22:41, 18 June 2015 (UTC)
          • Whatamidoing (WMF), I notice that you haven't mentioned the corrupted display of the "results" column. I still don't see the point of an editor that makes relatively simple things difficult in the quest to make trivially simple things even more trivially simple.—Kww(talk) 21:58, 22 June 2015 (UTC)
  • Support - The process laid out here is a reasonable, slow roll out of a product that is much more polished than its somewhat-bungled initial release a few years ago. I have no doubt that VE is not perfect, but perfection shouldn't be the standard, especially not for a slow rollout as proposed. Rather, the standard should be whether the benefits of rolling out VE outweigh the costs. Yes, there are still bugs to work out, but given the functionality of the product at this point, including the many tools listed in this proposal that were not available during its initial release, it seems more than ready to start being used across Wikipedia. –Prototime (talk · contribs) 06:02, 18 June 2015 (UTC)by
  • Support especially with the proposed deployment plan. —TheDJ (talkcontribs) 08:52, 18 June 2015 (UTC)
  • Comment this seems like a reasonable proposal (not going to oppose), although the estimated schedule of 1-2 months (in total?) is a bit short and should be longer. Such a slow partial rollout may be helpful to get additional feedback from other user groups. However, Visual Editor is not a finished product - the main focus should be on fixing the long list of remaining issues and improving the interface, not on getting it over with as soon as possible. And a note for clarity: if a significant number of additional errors occurs during this rollout period, further rollout should be stopped or delayed. GermanJoe (talk) 11:12, 18 June 2015 (UTC)
    • @GermanJoe: I agree; the main point of a progressive deployment is — precisely as you say — to check for fixing any issues which arise, whilst getting additional feedback. If a significant number of additional issues were to be found during the rollout, I would absolutely delay continuing until they had been adequately addressed. Jdforrester (WMF) (talk) 00:37, 27 June 2015 (UTC)
  • Oppose: Isn't VE still in the beta? I don't feel like it's such a good idea to put a beta product to a new user. In the long term, yes, of course, VE should be the future. But I think it's more prudent to enable the software once it's complete (wikitext after all is complete and works perfectly). -- Taku (talk) 12:20, 18 June 2015 (UTC)
    @TakuyaMurata: VE is in "beta features" because it's not rolled out yet; that's where things tend to live until they're fully deployed. I wouldn't say Wikitext works perfectly; it is the baseline everything else is compared against, and when the baseline is "doing everything Wikitext can do"..well, yes, Wikitext can do that, but perfection it ain't. Ironholds (talk) 14:37, 18 June 2015 (UTC)
  • Strong support. Ironholds (talk) 14:37, 18 June 2015 (UTC)
Hi, Ironholds. Please remember WP:NOTVOTE, especially because you might have special insight from your WMF role. I did see your comment above that makes it clear you think VE is easier but this seems counter to the May 2015 study that concludes there is "No significant difference" in "Newcomer productivity and survival" and there are "lower completion rates and more time to save". Also I have to wonder what, if any, conflicts of interests you may have as a WMF researcher on reader data. Have you worked on VE? Studied its user data? etc. Jason Quinn (talk) 20:10, 19 June 2015 (UTC)
You could always structure those queries as actual questions rather than leading ones; you're likely to get a better response. Try it.
My position above has, as you said, made clear what my opinion of VE is, and the study does not conclude there is "no significant difference" in "newcomer productivity and survival"; what it concludes is that in the first week or couple of weeks, VE is as-good as wikitext. Survival is based around much more than the first couple of weeks, of course - it also involves interactions further down the line when someone does not yet identify as "A Wikipedian" but is still contributing, and those further contributions are likely to be where wikitext really bites because it's where you run into issues around, for example, new article creations or precise formatting, a lot of the time. I've never worked on VE in a research capacity and my only work studying its user data was grabbing lists of users for the community liaisons to poke around beta testing; I'm pretty confused as to what logical chain you followed to decide that someone who studies how readers interact with our search systems would gain some benefit from people editing, or not editing, external to their benefit as a Wikipedian from having more Wikipedians around. Could you explain that?
What being a researcher has taught me, however, is that there are several potential confounds here which would make the VisualEditor potentially appear worse than it is: in other words, we can probably treat "not worse" as a baseline. For example, users previously editing as IPs, or under other accounts, who sign up and are confronted with the VE, have some adjustment time; the short length of the study and the fact that it is only a study of a percentage of logged-in users makes it difficult to test for previous activity or measure adaption time for that class of user. Hopefully this adds additional clarity. Ironholds (talk) 21:34, 19 June 2015 (UTC)
I had only one query (about any potential COI). The rest of my message was a reminder that just saying "support" is not an argument which I was hoping would function as a nudge for you to add one since your two prior replies cannot really be said to contain a cohesive argument. As for the study, it does conclude there's "no significant difference" in "newcomer productivity and survival". I copied and pasted directly from the Results section of the study. (Look at the TL;DR summaries.) Regarding the rest of your comment, I think it supports my idea that VE needs longer and more expansion trials but not necessarily enabling. Also when you say "I've never worked on VE in a research capacity", does that exclude as a developer? Jason Quinn (talk) 22:10, 19 June 2015 (UTC)
Outside of our analytics stack I've never worked as a developer for the Wikimedia Foundation full stop. Ironholds (talk) 22:31, 19 June 2015 (UTC)
Have you ever cashed a paycheck from them? Are you still receiving paychecks from them? If yes, do you not see this as a massive financial conflict of interest to be flacking for one of the major policy initiatives of your employer without appropriate disclaimers? Why are you not recusing here? Carrite (talk) 19:04, 2 July 2015 (UTC)
  • Support - The case seems to be fairly strong for this proposal, and some of the new features may even have me giving it a try again. Obviously, if VE is shown to have significant issues or if it creates more work work for experienced editors, then this gradual roll out can be halted while the issues are addressed.- MrX 14:54, 18 June 2015 (UTC)
  • Strong support as someone who does outreach in GLAM and Education, appreciates the significant table editing improvements in VE and who has heard direct feedback on the positive impact of the VE on other language communities for training new users and for making people less scared of editing: I fully endorse the need for this, Sadads (talk) 15:26, 18 June 2015 (UTC)
  • Neutral, leaning towards support with caveats. I'm torn on this one. On the one hand I'm all for providing newcomers with tools adapted to them ASAP. On the other hand, there is the matter (explained above by other editors) of hard-to-spot and randomly-appearing bugs that could erode the quality of articles througout the whole project. Given the precedents of WMF pushing problematic code without a back-off strategy, I'd rather have the deployment strategy made of several steps controlled by the community -who should greenlight every new batch of users exposed to the tool- rather than a WMF-controlled roadmap, even if it's flexible. Diego (talk) 15:46, 18 June 2015 (UTC)
  • Neutral leaning oppose. On one hand, VE is quite handy when editing templates or inserting references. On the other, it is buggy. I can recall two times; once it left "nowiki" tags and once it revertde to a past version of the article. You don't want to drive away newbies who get confused about what happened during their edit. --Fauzan✆ talk✉ mail 17:49, 18 June 2015 (UTC)
    • Hi Fauzan, thanks for this note. Do you happen to have a diff from the edit that ended up with the wrong version? It would be really helpful to me. Whatamidoing (WMF) (talk) 19:00, 18 June 2015 (UTC)
  • Support. Several months ago, for the first time, Wiki Education Foundation asked a handful of classes to get started with VE instead of wikitext. It went well enough — and enough of the problems that came up have been fixed since then — that I think VE is ready to become the default for new editors. Hopefully, as VE continues to improve, we'll see it overtake wikitext in terms of new editor retention and productivity. --ragesoss (talk) 19:49, 18 June 2015 (UTC)
  • Oppose It's just not quite ready yet. I like the idea of the VE and I really want to support, but the known are currently a problem. It wouldn't be so bad if a bot could easily clean them up, but it's not feasible to build one to effectively remove them. I also gave a test of the VE, the interface really lagged, and somehow I managed to completely mess up the article. I'm not sure what I did to do that, but suddenly half the article was missing.—cyberpowerChat:Online 23:38, 18 June 2015 (UTC)
    • Cyberpower678 opened a Special:Random page in Internet Explorer. His browser froze up for a moment, and a little later, he realized that half the article was missing. He and several other people have tried to reproduce it, but it seems to be working fine for them now. Having half the article disappear could be any number of things, like an accidental keypress or invalid wikitext, but Internet Explorer freezing up for a moment is definitely either a bug in VisualEditor or the ever-present gremlins in Internet Explorer. If anyone else has IE10 or IE11 installed, please try opening a few pages in IE to see if we can track this down. This link should work. Please leave a note at WP:VEF if you encounter any problems (same or different). Thanks, Whatamidoing (WMF) (talk) 05:03, 1 July 2015 (UTC)
  • Neutral I can understand how visual editor is easier for someone just starting out at Wikipedia. Making simple copy edits using it is much easier. The problem comes when you try to do anything more complex. It's not at all clear how to create wikilinks, cite sources, insert pictures, or edit tables. If one is editing the source code it may be confusing at first, but you can copy what was done on other articles to get the same result in the article you're working on. So it has pros and cons. Make the UI more clear so it's easier to figure out how to do things other than change "adn" to "and" and I'll support.~ ONUnicorn(Talk|Contribs)problem solving 23:46, 18 June 2015 (UTC)
  • Question Has there been any analysis of the effect of VE on newbies' participation in talk page discussions? The biggest thing I'd be concerned about with wider deployment is that talk pages still use wikitext. It's a standard expectation, and common advice to newbies, to engage on talk pages when there are problems or concerns about an edit. Introducing VE to newbies in effect asks them to learn two systems at once, and they won't develop any experience with the wikitext used on talk pages from editing articles and seeing the relationship between existing markup and the visual result. (On the other hand, maybe the edits they produce with VE are less likely to be misformatted or missing references, and therefore are less likely to be reverted or require discussion?)
In any event, I support a broader rollout; I just suspect the behavioral dynamics of newbie interactions might be different in ways that aren't captured by "productivity" metrics. Opabinia regalis (talk) 23:51, 18 June 2015 (UTC)
  • Support a gradual rollout to new users, with a plan to roll it back in the pocket if needed. I would like to note that I'm expressing support as a long-time Wikimedia volunteer, as a WMF community liaison I have not worked with VisualEditor in well over a year. Keegan (talk) 06:25, 19 June 2015 (UTC)
  • I support a gradual rollout too. I am using VE more and more these days and it's definitely better than it was. There are still some instances where only wikitext will do, but these don't generally relate to things that new editors will want to do. — Martin (MSGJ · talk) 08:24, 19 June 2015 (UTC)
  • Oppose and Object. This proposal is too biased and too soon. The proposal begins by mentioning "no negative impact" from VisualEditor while ignoring that the same study also found that there's no positive impact either. Ahecht thankfully mentioned this in an early comment. This is important because a few of the support comments are worded such that it suggests their authors did not read the study's results and therefore their support comments were biased by the proposal itself. I hope the closer of this proposal takes this into account and weighs those comments accordingly. This discussion was initiated the day after the results of the A/B testing were announced. That gave inadequate time for public review, discussion, and digestion of the results and methods of the study. I also believe the subsequent wording and structure of this proposal is too non-objective to initialize a fair discussion. Maybe the VE is ready to enter more advanced trail phases to gather more data on its use. This proposal, however, guarantees the eventual deployment of VE by default for all new users because there's no way of "unrolling it" if VE is less efficient on average than text editing. The proposal only implies the rate of increase would slow temporarily if "problems" were detected. (What counts as problems also needs detailing.) By "enabling" VE via this proposal, it's akin to planting an seed that there's no intention of uprooting if it turns out to be a weed. A neutral proposal would have to give conditions under which the threshold would be incrementally decreased, something the proposal never addresses. Jason Quinn (talk) 19:41, 19 June 2015 (UTC)
  • Strong Support Eventually we are going to need to move towards VisualEditor enabled by default, and I'm in favor of adding it now. With the ability to generate citations from doi and pubmed-id I'd probably switch to it for most non-template work myself. There are some quirks, but there are quirks in mark-up as well, and as long as development continues I support it. -- CFCF 🍌 (email) 21:10, 19 June 2015 (UTC)
  • Oppose current proposal: Needs a little more work - I think that Visual Editor is an excellent idea, but would suggest that we need to have some prep work done first: 1. All users it rolls out to should have a video or the like explaining both Wikitext and VE (and not just "VE makes this easier" - it should explain the Wikitext alternative as well, with particular focus on templates.) We're probably going to be in a state where we need both for a while still, so let's make sure VE users can find the Wikitext help they need when it becomes needed. Adam Cuerden (talk) 23:14, 19 June 2015 (UTC)
  • Support I have been trying VE for some edits and I have found it reliable for tasks newbies tend to perform (copy-edits, straightforward content writing, linking...). Wikimarkup is a really intuitive markup language, but most people don't use markup languages at all. Enabling VE for new editors by default will allow them to get started without as many frustrations. They will still need to learn wikimarkup eventually, but they won't need it from the get-go. BTW, even with VE enabled, you still have an edit source tab, and a link on every section so the text editor is not innaccessible. My only two suggestions would be to allow new users to choose VE or not in the account creation process (with good information, including that this choice is reversible), and to tag accounts that opt in so that editors trying to help them know what is going on. Happy Squirrel (talk) 01:25, 20 June 2015 (UTC)
    • Hi Happy Squirrel, thanks for the suggestions. The old team in charge of WP:GettingStarted was pretty firm that every extra option in the sign-up process led to a measurable decrease in the number of people who created accounts. Consequently, their thinking seems to be more about providing information after the sign-up process is complete (e.g., a note pointing at the Beta Features link or a GuidedTour once you open it) rather than in the middle of it. Most of the new editors in the study seemed to be able to figure it out for themselves, though. One of the main differences between the two groups was that a lot of the editors with access to both opened both, poked around for a while, and then picked the editing environment they wanted to use for their edits.
      You shouldn't have much trouble telling which editors are using VisualEditor, since every single edit made in it is tagged. These tags should be visible in your watchlist, page histories, and RecentChanges. Whatamidoing (WMF) (talk) 06:33, 20 June 2015 (UTC)
  • Weak oppose - While it seems to have made a lot of strides, there are still some issues. The auto-filled citation generator is somewhat problematic. If you give it a URL for a site it doesn't "recognize", it returns an incomplete citation with nothing but the title, URL, and access date. But then rather than prompting you to fill in the rest, you have to insert it and then click a whole bunch of things to be able to manually fill in the extra data. Its handling of DOIs is also spotty. In particular, it doesn't work with journals published by one of the largest scientific publishers. This appears to be because, as far as I can tell, it extracts the data from the publisher's website and needs special code for every single publisher, even though CrossRef has an API for extracting metadata from DOIs (that, not to brag, reftoolbar handles with around 50 lines of code that works for virtually every journal). And for the journals it does work for, it frequently produces incorrect output. Of 4 journal articles from 4 publishers I tested, it didn't work 100% correctly on any. 1 was an Elsevier journal that didn't work at all, 2 produced dates in a format not accepted by the template, and 1 filled the ISSN field with "null." Mr.Z-man 02:44, 20 June 2015 (UTC)
  • Maybe New editors should be given the choice. VE may be better for some while other may like the old text editor. Having this choice may improve editor retention. We all do not need to do things in the same way. There are still improvements I would like to see such as if the DOI or PMID is given a url is not typically needed. I do like that if one gives it a PMID it automatically also finds and fills in the DOI. One concerns is that this will make it harder for new editors in that they will being using one system for the article and another for the talk pages. Doc James (talk · contribs · email) 06:54, 20 June 2015 (UTC)
  • Support much easier for new users, although not ideal for experienced editors. --Tom (LT) (talk) 08:55, 20 June 2015 (UTC)
  • Oppose Rolling out to new users until two eminently fixable issues are addressed. (1) It doesn't display the BLP EditIntro, which is an important policy notification that new users should be made aware of. The edit intro for disambiguation pages is also helpful. (2) The options, advanced settings and languages tabs should be removed altogether since they are useless to new users, and to everyone actually since they provide functionalities either unused in mainspace or incorrectly handled (e.g. redirecting keeps the old page content), and on the other hand the possibility to edit categories should be more visible. Although the second point can be 'fixed' by playing around with css and js, the first point requires software changes: phab:T56029. Cenarium (talk) 14:11, 20 June 2015 (UTC)
  • Support This is a slow rollout only affecting new users. There is research done that shows that this won't cause major problems to existing editors, and there really has been a lot of progress made to Visual Editor it looks like. Its definitely worth noting that the new users this affects would not be forced to use VE, as they will just be shown two buttons, one for VE and one for Wikitext. This proposal would give new users a choice. I would support this proposal. I see no good reason at the moment to oppose. Zell Faze (talk) 20:42, 20 June 2015 (UTC)
  • Oppose To support something on the basis of a study that has shown no real benefits because it has shown only minor disadvantages seems paradoxical. Until it actually improves the experience for new and old editors, there is no reason to enable it. A VE certainly has potential advantages , and I look forward to see a version that actually realizes it. DGG ( talk ) 23:51, 20 June 2015 (UTC)
    • Hi DGG, the research study found that there is one small but real benefit (slightly fewer of their edits needed to be reverted), and that everything else is equal. It found no disadvantages. The types of errors or complications differ between the two editing systems, but the net effect is slightly positive for editors who have both editors available. Whatamidoing (WMF) (talk) 00:32, 21 June 2015 (UTC)
      • You mean the result that the study described as: Rigor tells us we can't believe this result. Either there is a real, but very small effect or non at all. --Ahecht (TALK
        PAGE
        ) 04:48, 22 June 2015 (UTC)
        • I mean the result that the study described as "editors in the experimental condition produced slightly fewer revisions that would need to be reverted (W = 5869081, p-value = 0.007)." The sentence you've quoted from his work log referred to an erroneous calculation (read the next sentence, which begins with the word "Oops"). Whatamidoing (WMF) (talk) 17:26, 22 June 2015 (UTC)
Actually, the final conclusion (after the error was accounted for) still contains: even if this is, in fact, a real effect... (Though that analysis was indeed later superseded.) Sunrise (talk) 04:59, 1 July 2015 (UTC)
  • DGG, there's one way in which VE improves the editing experience, but I don't think it's going to be easy to measure. I've switched almost entirely to editing articles in VE, and I am much more productive as a result. I would like to see the option made more visible to new users because some of them may have the same experience I did. I'm basing my support not so much on the experimental evidence above as on my own experience with VE. Mike Christie (talk - contribs - library) 12:16, 21 June 2015 (UTC)
  • Strong oppose - find a way so that next to the regular 'edit' button there is a 'visual edit' button, where EVERY editor has simply the plain choice to choose whichever editor they want to use. An absolute strong oppose to enforcing user to use one of the editors, an absolute strong oppose to abandoning the old editor (I am hoping that you will never even start considering to abandon the old style editor anyway, so there is no reason why these cannot run next to each other and giving the person who wants to make an edit a choice). --Dirk Beetstra T C 06:33, 21 June 2015 (UTC)
    Dirk, unless I'm missing something your comments aren't addressing what's been proposed. The wikitext editor will be visible to all users, in the enabled group or not. There's no suggestion of eliminating the wikitext editor, and I can't imagine anyone suggesting something so foolish. The proposal is what you suggest it should be -- give editors both buttons so that they have a choice. Can you clarify what you're opposing? Mike Christie (talk - contribs - library) 12:11, 21 June 2015 (UTC)
    Mike, I oppose having it standard enabled for any user, I want every user to, on every single edit they wish to make, to have a direct choice, not 'edit goes to VE' (and if I need source-editing I have to click somewhere else), or 'edit goes to source-editing' (as it is now), I want just two buttons - one for VE and one for source - so I can chose on every single edit which one to use, and that choice has to be clear: one button with 'edit with VE', one button with 'edit source'. No settings needed to be changed, no standards needed to be changed. Hence I oppose. --Dirk Beetstra T C 13:27, 21 June 2015 (UTC)
    Basically, what I want to see is what currently is the case when you enable VE: two tabs, one saying 'edit source' and one saying 'edit' - but I want the latter to specify that it says 'edit (VE)' (or something similar making clear that that 'edit' is using the VE-engine). Then there is no need for settings to be enabled, and it is clear what you get (like VE: what you click is what you get). --Dirk Beetstra T C 13:33, 21 June 2015 (UTC)
    I think I follow. Just to check: are you saying that if the label on the "Edit" tab were changed to "Edit VE" or "Visual edit" or something similar, you would support this proposal? Mike Christie (talk - contribs - library) 15:31, 21 June 2015 (UTC)
    It would make it better, but I still don't think that new editors should be subject to this - it should be the experienced editors who take out all glitches first, a new editor, when the vE is behaving weird, is unlikely to figure out how to do the 'emergency repair'. The whole thing is again smelling of 'we think it is good to have it, we spend money and time to develop it, we want people to use this, we'll push it through somehow'. --Dirk Beetstra T C 03:32, 22 June 2015 (UTC)
    Comment after the above clarification - first, I still insist that the standard edit button should make clear it goes to a visual editor (which is still in beta and under development). Secondly, I still oppose enabling this for NEW editors first. It is still under development, it is still in beta, what I see around are still issues, and all we got presented are, at best, m:Research:VisualEditor's effect on newly registered editors/May 2015 study does not see a statistically relevant improvement on anything (e.g. "editors in the experimental condition produced slightly fewer revisions that would need to be reverted (W = 5869081, p-value = 0.007)" - the "slightly fewer" is statistically not supported, and if it is true, it may actually be that vandals have more problems with VE, which may be a bad sign in itself). Anyway, putting the burden on new editors is a bad idea, especially when it can not be shown whether VE is actually giving less problems with edits and the follow up of edits. --Dirk Beetstra T C 06:26, 1 July 2015 (UTC)
  • Support. No doubt more bugs will be found each time the threshold is raised; I hope the process for raising the threshold will include further review here, and some discussion of any serious bugs that cause damage to articles. Mike Christie (talk - contribs - library) 12:11, 21 June 2015 (UTC)
  • Support. I don't plan to use VisualEditor—wikitext manipulation is much more powerful—but pushing it to newbies is a good idea. It's one less barrier to entry at a time when we could use more participation and when the average newbie probably hasn't had much experience with markup languages. I do share the concern that we should try to avoid "scaring people off" from wikitext—for example, I think we ought to pair VE with a syntax-highlighting wikitext editor—but this is the next step in removing a barrier to entry for those unwilling to learn wikitext markup. {{Nihiltres|talk|edits}} 14:47, 21 June 2015 (UTC)
  • Support The benefit to acclimating new users (less reversion) is good, and in some opposes, I hear the echo of that paper encyclopedia meeting circa 1999 (new tech? new systems? no, no, no - and then they were history), in other opposes, I hear, 'this thing should run before it walks (or perfect is the enemy)' -- well, this is what walking is - so that running may come some day. Alanscottwalker (talk) 15:09, 21 June 2015 (UTC)
  • Support We need to be forward looking. I agree VE is not perfect. Will it ever be for everybody in every possible situation? Sure no. Is it good enough to attract and retain a new generation of editors? Yes. Then VE is worth a shot. --Afernand74 (talk) 20:55, 21 June 2015 (UTC)
  • Support We don't need habitual reactionaries; we need to attract more qualified editors.--Anders Feder (talk) 21:40, 22 June 2015 (UTC)
  • Oppose but kudos for improving V/E to the point where it is no worse on average for newbies as the classic editor, that must have taken a huge amount of work. I still believe that a good WYSIWYG editor would be way better than the classic editor. But it would be premature to deploy it now. Remember one of the won't fix bugs was that it was written to take advantage of the latest chips and in consequence runs glacially slowly on old kit. So the people we'd gain from V/E are the ones who don't like the wall of text and profusion of curly brackets and the like, they will still be ready for us when and if V/E is ever clearly better than the classic editor. But if there is no net advantage to V/E then we can assume that the people we gain will be matched in number by the people we lose because V/E runs ridiculously slowly on their PCs. As a global inclusive organisation we shouldn't discriminate in such a way. ϢereSpielChequers 21:48, 22 June 2015 (UTC)
    • Hi WSC, I’m not sure which old bug you’re talking about. The team have dealt with over 4,000 requests by now. Do you have a link to it?
      They spent the last few months dramatically improving performance. In fact, in parts of Central Asia or Africa, it is usually faster to open a page in VisualEditor than in the wikitext editor. (In North America and other rich countries, the wikitext editor usually edges out VisualEditor; it depends upon the Internet setup in each place.) The main idea is to give people a choice and let them decide what works better for them. Why don’t you try it out? Just click http://en.wikipedia.org/wiki/Special:Random?veaction=edit a few times, and see what you think. Whatamidoing (WMF) (talk) 23:49, 22 June 2015 (UTC)
      • One of the problems of running the bugs on bugzilla and or whatever system they used for V/E is that they don't get included in your watchlist and those of us who raise bugs don't get told if they are fixed or not. I reported a lot of bugs in early 2013, most were archived without comment because even before it was first rolled out there were too many bugs coming in for the devs to keep up with. But one of the bits of feedback I did get was that my experience of extreme slowness with V/E wasn't the IO issue I'd assumed but was down to my then using an old machine, and that this was a "won't fix". I have since replaced that machine, so hopefully the bug would no longer affect me, but no-one has told me that the "won't fixes" have been fixed, I've no doubt that many of the things they were trying to fix have been fixed and that the software is not as bad as it was two years ago, but the evidence of retention rates is that if the hypothesis that we need a WYSIWYG editor to recruit most non programmers, then V/E still has a long way to go. As for your invitation, thanks, but after my previous experience with V/E testing I'm very reluctant to spend my time testing new WMF software again. ϢereSpielChequers 09:46, 23 June 2015 (UTC)
        • I tend to agree with you about the "off wiki" problem for bug reports. I've looked through the archives and found several discussions you participated in (beginning here), but I was not able to find anyone saying that performance improvements were a wontfix issue. In fact, improving performance has been a major goal, with a dedicated sub-project. I've had several editors tell me that they use VisualEditor successfully with older computers, including one who says that VisualEditor is faster than the wikitext editor on his nine-year-old computer. I've heard no significant complaints about speed for months.
          However, the actual speed is a bit of a red herring: the point of this proposal is only to give new editors easy access to the choice, not to make them use VisualEditor. They can decide for themselves which works best for them or their computers. I believe that the choice between wikitext and VisualEditor should be in the hands of the individual editor, so that each editor can freely choose whichever one is better for that editor's own situation. Whatamidoing (WMF) (talk) 05:39, 24 June 2015 (UTC)
          • VE is about 2-4 times faster now compare to 1,5 years ago in my experience. But it will never be as fast as wikitext editing. Then again. MS Word, Google docs, and Pages aren't by a long shot as fast as notepad either and all have their fanboys. —TheDJ (talkcontribs) 18:24, 24 June 2015 (UTC)
  • Support Making new users think about what they are doing and looking more modern is better than the current system. VE could be better, but I support adding thing that help new users. New users are always good. --Frmorrison (talk) 15:21, 23 June 2015 (UTC)
  • Strong upport. Giving new users the choice of which editor to use (VE is best for some things, Wikitext is best for others), and rolling that choice out gradually is a Good Thing for Wikipedia. As long as bug reports continued to be monitored (and I have no doubt at all they will be) then I cannot see any disadvantages to this. Thryduulf (talk) 09:57, 24 June 2015 (UTC)
  • Support. It is thoroughly ridiculous that we make new users manually enable an editing system that is demonstrably easier to understand and requires far less of a learning-curve for new users to operate effectively, and yet we are perfectly happy showing them a highly complex code system by default. At this stage of VE's ongoing development, the only reason that we would not want to allow people to have the option of either system by default is because we want to retain the higher barrier to entry for newbies. Wittylama 10:31, 24 June 2015 (UTC)
  • Support. I have it enabled and it has worked well for me the times I've used it. I often edit from diffs and the like so, often end up using wikitext directly mostly out of habit. I've also used visual editor or other wikis and believe it would be useful as a default for new editors. My biggest problems is occasionally running into places where it isn't able to edit, or on really long pages minor performance issues, though in most of those cases that really is a sign that the page should be split. PaleAqua (talk) 20:07, 24 June 2015 (UTC)
  • Oppose, for a while. (My Wikitext browser crashed, so this may be a shortened version.) IMO, the reversal rate is not a good measure of the error rate. In my experience, most wikitext editor errors can be seen, even just when reading; while VE errors, except for "snowmen", often require careful investigation of the wikitext to discover. Furthermore, I could be wrong, but I don't think all the "show-stopper" bugs have been fixed. — Arthur Rubin (talk) 23:14, 24 June 2015 (UTC)
  • Oppose, I did try to use it, but it is useless for me. If VE had been the default choice when I started editing Wikipedia, well, then I would never have become a Wikipedia editor. Huldra (talk) 23:29, 24 June 2015 (UTC)
    • @Huldra: Understood. My plan is very much to offer both options to new users so that they have the choice for each edit they make, based on whichever one works for them – I agree that, for some people, wikitext will always be more comfortable, and I want to make sure we keep catering for them. Jdforrester (WMF) (talk) 00:39, 27 June 2015 (UTC)
  • I can actually support enabling this now that it has finally been cleaned up to the point that it doesn't crap all over articles. I just re-enabled it to test it, and it seems reasonably responsive and the user interface is actually reasonably intuitive. However, I vehemently oppose any and all attempts to hide the source code editor, showing only the visual editor. Also, please add a button to add the references list.... Reaper Eternal (talk) 23:58, 24 June 2015 (UTC)
    • Hi Reaper Eternal, it's actually pretty easy: Go to the "Insert" menu, expand it (to show "More"), and click the "References list" item to insert it wherever your cursor is. Whatamidoing (WMF) (talk) 00:27, 27 June 2015 (UTC)
  • Strong support VisualEditor has improved significantly in stability and in features (like the citation editor). Statistically, the study results show that there's no harm in enabling VisualEditor as the new editor default, and we have long heard from newbies that editing wikitext is confusing and slows down contributing. Steven Walling • talk 08:00, 25 June 2015 (UTC)
    • Hi, Steven. In the interest of full disclosure, would you summarize your involvement (or lack thereof) with the creation/development/etc of the VE while you were a Foundation employee? Jason Quinn (talk) 12:14, 25 June 2015 (UTC)
      • I was not on the VE team nor involved in its design or development. I ran a completely separate team (see old docs). Steven Walling • talk 18:43, 25 June 2015 (UTC)
Have you receive paychecks from WMF? Are you still receiving paychecks from WMF? Do you not feel it is a financial conflict of interest to be opining here about one of the major policy initiatives of your employer? Carrite (talk) 19:14, 2 July 2015 (UTC)
Steven left the employ of the WMF in September 2014, over nine months ago. Could you please reconsider the wording of your comment, Carrite, as it implies that Steven is currently employed by the WMF. Risker (talk) 19:26, 2 July 2015 (UTC)
  • Support wholeheartedly. Per many of the above, but also because it's 2015. We need to move away from a system developed to get around 2001 browsers. Protonk (talk) 20:31, 25 June 2015 (UTC)
  • Support Wikitext is a barrier to many new editors (I certainly found it one). In light of the improvements that have been made and the phased nature of the proposed rollout, I am not persuaded that the fears of the opposers will be realised. Neljack (talk) 06:54, 28 June 2015 (UTC)
  • Strong support. VE has gotten a lot better, and those new features are pretty nice. APerson (talk!) 13:30, 28 June 2015 (UTC)
  • Support. Wikitext is a learning curve that turns away potential contributors. VE is a great (if imperfect) alternative. -- Ypnypn (talk) 17:45, 28 June 2015 (UTC)
  • Support for two reasons: firstly, because of the supportive comments above from people working on meetups and GLAM etc. (statistics are brilliant but the ones in this study were too vague and had various different plausible explanations, while comments by newbies may reflect the advantages of VE better); secondly, because of the improved referencing system. In fact, I might be tempted to start using VE myself for the first time in a year and a bit — one key reason I stopped using it for most edits was the annoying process of trying to add citations. I'm disappointed to see that the anomaly I remember with <nowiki> tags is still unfixed, but given all the crap attempts at using source code jargon I've seen, I think VE is better for newbies. Bilorv(talk)(c)(e) 23:11, 28 June 2015 (UTC)
  • Support giving VE a second chance. The interface has improved. Altamel (talk) 02:52, 29 June 2015 (UTC)
  • Support - Ideally, it would support talk page editing or roll out at the same time as WP:FLOW, but I think that given the improvements and the measured approach being proposed, it's worth enabling as a visible option. — Rhododendrites talk \\ 18:12, 29 June 2015 (UTC)
  • Strong oppose I spend most of my time on frwiki where VE has been enabled by default to everyone for almost 2 years. I see there the number of damages still caused by VE on a daily basis, and the lack of solutions found by the VE team for many problems reported since the beginning. For example, a lot of nowiki tags are added by VE (see filter on frwiki with more hits than filter on enwiki while there are a lot less daily edits on frwiki). Other example: the constant damages on ISBN, like this example, which has been reported countless times. And if you look at the history of VE feedback page, you can see a lot of my reports. --NicoV (Talk on frwiki) 21:01, 30 June 2015 (UTC)
  • Oppose - Newbies should be allowed to have an option between the 2 having WikiText as the default, There was alot of issues with VE when it was launched here so I'm reluctant on making something a default if that something still has issues. –Davey2010Talk 21:31, 30 June 2015 (UTC)
  • Support - I've obviously misread it somewhere as I've pretty much supported above anyway Face-grin.svg, Although I don't use VE nor do I entirely trust it Newbies should be given a choice and if they can't get on with one then they have the other to fall back on, Thanks Whatamidoing (WMF) for pinging. –Davey2010Talk 14:45, 1 July 2015 (UTC)
  • Oppose per StringTheory11, DGG, Jason Quinn, and Beetstra. Benefits should be shown before it is implemented in this way. It should be clearly labeled "Visual Editor", and appear after (to the right) of the normal Wikimarkup editing ("Edit source") button.Godsy(TALKCONT) 23:20, 30 June 2015 (UTC)
  • Conditional since it’s complicated. Several points:
  • First, the question is not framed neutrally. This is an issue which can and does invalidate RfCs, so if Jdforrester (WMF) finds himself in the position of writing another important RfC in the future, I strongly recommend prior consultation with Wikipedians who are experienced with this. Other issues besides the lack of neutrality include the lack of a concise question and (as shown by e.g. the edits made to it on 27 June) a lack of clarity.
  • The text of the RfC question is a poor representation of the data and describes it as considerably more certain than it actually is. I had a very productive and civil conversation (at Meta, following the questions I asked in one of the sections below) with Halfak (WMF), who performed the study in question. While we disagree on some points, we do seem to agree that the conclusions should be regarded as tentative.
  • On what to take away from the data, I conclude that the observed effect on revert rates is unlikely to be real. There’s probably not a major difference between the two interfaces, but the RfC question presents this conclusion as considerably more certain than is warranted given this data.
    • [Minor interjection: For the sake of editors who don't want to wade through a stats discussion, Sunrise does not believe that the finding "editors in the experimental condition produced slightly fewer revisions that would need to be reverted (W = 5869081, p-value = 0.007)" (direct quotation from the study report) is appropriately described above, where it says those editors were "no more likely to be reverted" (direct quotation from the proposal) than editors without it. Whatamidoing (WMF) (talk) 02:41, 1 July 2015 (UTC)]
[Actually, that's not correct, and there's also quite a bit more at issue than just the revert rate finding. I'll reply on my talk, and will just note here that I have no objection to the specific excerpt that you quoted.] Sunrise (talk) 03:56, 1 July 2015 (UTC)
  • My final answer depends on what precisely is being asked, which still isn’t clear. I interpret (as have some others) that the RfC question is “shall we implement this proposal?” But the proposal simply describes a rollout procedure. The question is whether this RfC, if consensus is found, will be interpreted as agreement to (ultimately) enable VE by default over the entire English Wikipedia. This seems to be the most logical interpretation, although it’s made unclear by the poorly written question. One major difference is in the phrase "if that initial rollout goes well": who will hold the ultimate authority to decide that?
  • So it might be that the main idea behind this proposal is to perform more expansive testing so that more data can be collected and analyzed, and then to bring the question back to the community for another RfC like this one (with no consensus defaulting to the status quo, as usual). I think that a number of the supporting editors above are supporting only with this expectation, and in this context I would support as well. But if the rollout procedure cannot subsequently be stopped except by a finding of consensus against it (or, of course, by the WMF deciding not to proceed), then in that context I oppose - because we do not have enough data, and what we have was not accurately presented.
--Sunrise (talk) 00:16, 1 July 2015 (UTC)
  • Support – There is little in the way of good reason to oppose including both editors as options. Apparently there are some bugs or things that VisualEditor cannot do; could not these be addressed with a simple notification to those users who have opted to make use of it? New editors may have more trouble with wikitext and may be more suited to get "caught" on editing Wikipedia using VisualEditor before learning the finer details of wikitext editing. Dustin (talk) 00:56, 1 July 2015 (UTC)
  • Oppose Until Visual Editor works right and improves the editing experience for all users I won't support it. I've been on other wikis that use VE and it's annoying to not be able to see the mistakes it causes until after you're finished. Psychotic Spartan 123 04:17, 1 July 2015 (UTC)
  • Support After running many edit-a-thons, I have found that new users tend to prefer the visual editor, particularly users that are less tech-savvy. If we want to appear welcoming to users like (for example) older members of historical societies, I think the visual editor (as one option, at a minimum) is the way to go. Calliopejen1 (talk) 05:02, 1 July 2015 (UTC)
  • Very weak support
1) The study done doesn't show that new editors do more or better work with the Visual Editor.
2) Most newcomers to Wikipedia will be more use to editing web sites with editing "programs" like the old Wikitext editor.
3) So let the older Wikitext editor stay the default, with a toggle button to let users switch to the new Visual Editor, and back to the older Wikitext editor.
4) It would be OK to me, if this behaviour was enabled for all editors with an additional button to choose one or the other permanently (that would set an option in each User's Preferences, so it can be changed.)
Lentower (talk) 02:13, 2 July 2015 (UTC)
  • Oppose I don't like the VisualEditor; tends to make certain kinds of vandalism hard to revert; and I don't like the idea of limiting anyone's ability to root out vandalism. Melody Concertotalk 02:21, 2 July 2015 (UTC)
    Interesting. Do you mean that VE makes it easier to do certain kinds of vandalism that are then hard to revert, or that using VE it is hard to revert certain kinds of vandalism? Can you give an example? Mike Christie (talk - contribs - library) 02:52, 2 July 2015 (UTC)
  • Oppose - We need to hear some testimony from some of the Wikis that have been using Visual Editor. Failing that, a limited roll out for a 60 day trial might be okay. We've been fooled before by WMF's Engineering Dept., however, and verification that the software has been fixed from actual users seems essential before a general roll out. Carrite (talk) 19:12, 2 July 2015 (UTC)\
  • Support - VE seems to have progressed and improved enough to offer it as an option to all users. The increased usage will only help to improve it further.--Wolbo (talk) 21:28, 2 July 2015 (UTC)

Note: Added clarification for new participants[edit]

We’ve had several conversations about what the proposal is, including some really odd comments that seem to come out of nowhere (e.g., "making [VisualEditor] the default" or "abandoning" wikitext: there’s not a single word in the actual proposal that says anything like that, because that’s absolutely not the proposal). Naturally, the comments that are most odd to me are the comments that amount to “Oppose, because I insist that instead of <something not in the proposal> you do exactly what this proposal says and give new accounts access to both editors!"

Since so many people are trying to WP:VOTE for or against a single binary question, despite this being a discussion about a proposal, I've tried to clarify "a question" at the top of the discussion section so that everyone will at least be voting on the same question.[1] Some of the !votes posted before then may appear a little confused to later readers.

I hope that this increases clarity, rather than creating another layer of confusion. This is partly inspired, in one way or another, by some comments above, but also from general comments that people made about being confused and the apparently strong desire to vote on something. If you have ideas about how to improve the question, then please let me know (here or on my talk page). Whatamidoing (WMF) (talk) 04:54, 1 July 2015 (UTC)

I would say it depends on what the goal of the RfC was. If the intention was to get agreement from the community before continuing with the VE rollout, then some sort of clear question was needed. If it was just supposed to get a general idea of what the community thinks, then that should also have been made clear - I think most editors will assume there is a specific question being asked unless it's explicitly said that there isn't one, just because that's almost always the case. (And we've already had ~80k bytes of discussion from editors presumably making assumptions along these lines. Hopefully some conclusions will still be possible...) Sunrise (talk) 05:16, 1 July 2015 (UTC)

Non-voting discussion[edit]

Should we be doing this when talk pages aren't covered by VisualEditor? I'm a bit worried about pushing two different editing styles on new users. Adam Cuerden (talk) 21:15, 20 June 2015 (UTC)

Here are two points I think you should consider: First, most new editors don't use talk pages at all (only about 4% of all accounts that registered during the recent research used a talk page). Second, this part of the study analyzed edits by namespace, and there was no statistically significant difference in the use of talk pages. If learning wikitext at the same time as learning the much more familiar, word-processing-style environment was too difficult, then we should have seen a difference there. Whatamidoing (WMF) (talk) 00:39, 21 June 2015 (UTC)

Some questions on the study:

  • How many editors in the experimental group disabled VE? There appears to be data on editors in the control group that enabled it, but not vice versa. (And if there's a difference, is there any asymmetry, like editors in the control having a link encouraging them to try VE but not vice versa?)
  • What are the absolute numbers for numbers of reverted edits (the metric for which VE performed better)? I can't see any information here, only the information for number of editors blocked. Also, why was this comparison only analyzed with Wilcoxon given that most of the others used both Wilcoxon and chi-squared?
  • The Wilcoxon signed-rank test is a test for paired data - how and when was the pairing done, and shouldn't the control and experimental groups have the same number of editors if the data were paired? (I haven't used this test much, so apologies if I'm missing anything basic.)
  • What correction was used for multiple hypothesis testing?
  • Where can we find the raw data, e.g. in CSV format?

Thanks, Sunrise (talk) 02:01, 21 June 2015 (UTC)

I don't think that anyone knows how many editors changed their preferences. What's known is how many people in each group actually used VisualEditor.
You may find the other information in the work logs. In the infobox at the top of this page, you will find a link to the dataset. I'm sure that EpochFail will be happy to discuss his research with you next week. Whatamidoing (WMF) (talk) 05:17, 21 June 2015 (UTC)
Thanks! I hadn't been aware of the links to the work logs or dataset. One thing that concerns me is that according to the work logs for revert rate here, Halfak seems quite doubtful that an effect exists, but on the summary page and in the above discussion, it seems to be presented as a solid result. (The conclusion that the effect probably isn't real is a sentiment I felt as well after reading the summary, and was partly the motivation for my questions.) There also seems to have been a translation from "no difference found," which is what this type of analysis tells us, to "definitely no difference" which is a very different statement that a p-value analysis can't tell us about.
I do think the majority of my previous comment is still relevant, but I'm happy to wait until the wilderness vacation is complete. :-) Sunrise (talk) 06:58, 21 June 2015 (UTC)
Hey folks! I just got back. It seems like these questions are best posed on the study's talk page since this conversation will be fragmented otherwise. See m:Research talk:VisualEditor's effect on newly registered editors#Sunrise's questions. --Halfak (WMF) (talk) 14:26, 24 June 2015 (UTC)
For the record, we do log preference changes in EventLogging, so someone with the appropriate access could look it up if they wanted to. Legoktm (talk) 06:08, 23 June 2015 (UTC)

What rationale has been provided for excluding talk pages from the scope of VE (referring to the objection which leads off this section)? Very curious about that. --User:Ceyockey (talk to me) 01:42, 26 June 2015 (UTC)

Because it is not suitable for discussing subtle differences in potential content of articles, among other reasons. — Arthur Rubin (talk) 15:23, 26 June 2015 (UTC)
That doesn't ring true to me ... at the base level, VE is an in-place visual text editor, so the addition and revision of text occurs inline rather than in a separate frame. There is the issue, though, that talk pages can be farrr larger than the articles they are attached to (particularly in the Wikipedia: space), so I could see there being performance issues if the tuning and performance improvements have been targeted to some proportion of the mean+2SD size for articles. --User:Ceyockey (talk to me) 14:08, 27 June 2015 (UTC)
WP:FLOWPrototime (talk · contribs) 01:54, 27 June 2015 (UTC)
Thanks for the reminder -- I'd forgotten about this other initiative. --User:Ceyockey (talk to me) 14:11, 27 June 2015 (UTC)
Fortunately, talk pages are much simpler to edit - in fact, since starting a new thread (section) requires knowing no wikitext, whether an editor prefers VE or the classic wikitext UI is essentially irrelevant. (Protocols, like signing with four tildes, well, that's another matter.) As for editing an existing talk page section, since the protocol is generally to post a comment at the bottom of the section, reading wikitext isn't critcal (and, again, the protocol of indentation is dissimilar to wikitext editing of articles, where colons and multiple asterisks for indentation are rare; fortunately, talk page indentation isn't critical, and is easily fixed). In short, while we want to minimize how much an editor needs to know technical stuff in order to edit articles and to communicate, the overlap (technically) between talk and mainspace is relatively minor - hence Flow rather than VE as a solution for talk page issues. -- John Broughton (♫♫) 17:49, 28 June 2015 (UTC)

What about a choice[edit]

Can someone from WMF please explain why this editor has to be, excuse my wording, shoved down the throat of people. It is my hope that the old-style editor is not going to be abandoned completely anyway (it should always be available to edit out quirks that the VE did not manage to handle for whatever reason), so why not run them next to each other - always? Just have for every person both the 'edit' and the 'visual editor' choice and they can ALWAYS use whatever they want. Why the insistence (including spending development money on studies showing that the new editor is just as good or even better than the old one) to have everyone use the new editor - give the choice, and when your site-stats show that 99%+ of the editors is using the new editor by choice, then you can consider to make it a default choice (but still keeping the old option available). --Dirk Beetstra T C 06:40, 21 June 2015 (UTC)

Current state: one button, and no choices.
Proposal: Give them two buttons, and let them make their own choices for each edit.
Yes the old editor must never be disabled. I hope there are no suggestions that it will be.
I agree people should be given a choice. Maybe both should be shown by default with a "visual edit" button and an "edit" button. People should than be able to keep both, turn of one, or turn off the other. I would support this rolling out. Doc James (talk · contribs · email) 07:57, 21 June 2015 (UTC)
There is NO need to have 'edit' standard go to VE, just give everybody a second edit button next to the first one, and make sure that one clearly goes to VE ('edit (VE') and one to source ('edit source'). As editing the wikisource may be confusing to editors, that will also be the case for using the VE (and the ratio we can guess or determine later). Not having 'edit' standard go to VE, but make sure that on button goes to a visual editor, and the other to wikisource editing. Not a standard set choice, but a choice every time. --Dirk Beetstra T C 08:05, 21 June 2015 (UTC)
Yes that is what I mean. The edit button goes to the normal editing mode. The "edit visual" goes to VE. The normal editor is on the left the VE button on the right. People can remove either if they wish. Doc James (talk · contribs · email) 08:13, 21 June 2015 (UTC)
I don't understand this objection, because it's requesting what's been proposed. The proposal is to give new editors a choice between editing environments. If you want two buttons for new editors, so that they can easily make their own choices every time, then you should be supporting this proposal. If you want only one button, so that new editors cannot choose VisualEditor, then you should be opposing this proposal. Whatamidoing (WMF) (talk) 17:01, 21 June 2015 (UTC)
Yes I sort of support the proposal. I would prefer the old edit button called "edit" and the new edit button called "visual edit"
I would also like to keep the ability to turn of one or the other button to clean up the user interface. Doc James (talk · contribs · email) 04:03, 22 June 2015 (UTC)
They'll have the same button for enabling and disabling VisualEditor via Beta Features that you have now. Whatamidoing (WMF) (talk) 06:05, 24 June 2015 (UTC)
It seems to me that this discussion is about the normative position - whether the word "edit" should apply to the old style or the new style, and by extension, what should the "other" form of editing be called. For example: "edit / edit (beta)" and "edit (source) / edit" actually mean the same thing. BUT, this is a side issue to the question of allowing new users to have BOTH options turned on by default. Wittylama 10:23, 24 June 2015 (UTC)
Yes agree it is a side issue and a super easy one to address. I guess we could have a separate RfC to discuss it. Doc James (talk · contribs · email) 10:57, 24 June 2015 (UTC)
I agree that this is a side issue, one that should be discussed in a separate RFC (and probably after this current RFC is concluded, since the button labels will be a moot point if the community rejects the roll out). –Prototime (talk · contribs) 21:51, 24 June 2015 (UTC)
Without presuming to speak for the product teams, this old essay may be helpful in understanding the costs that choices/preferences impose on developers, QA, and users (especially new ones). Another variation on the same theme was written by the team at 37 Signals as part of their influential book "Getting Real".—Luis (talk) 21:33, 24 June 2015 (UTC)
I must say that I disagree. Different people work in different ways. And there is nothing wrong with that. Doc James (talk · contribs · email) 22:25, 28 June 2015 (UTC)
There is a rather simple rationale for moving people to VE and away from wikicode editing, though I'm not sure if this is among the rationales in use at present: by moving to a non-code editor, this frees the backend to adopt any coding variant or standard which is needed on a particular architecture or technology. At present, there would be no way of overhauling wikicode en masse due to the crippling effect this would have on most prolific editors; by divorcing the editing activity from the interpreted code, you allow technology driven changes to the back end while keeping the front end unchanged. Now, does this mean I'm a booster for VE - no, it does not. However, I can see this as one of the major attractions for the push toward VE. --User:Ceyockey (talk to me) 01:46, 26 June 2015 (UTC)
I see that as one of the major reasons to avoid using VE, unless the Foundation is willing to commit to manually editing the millions of existing articles to ensure that no damage occurs in the changing of the back end (Parsoid). Some (not all) of the early bugs in VE were due to the fact that its internal representation didn't support the existing source, and some of the ongoing problems (in both source and VE editing) is that Parsoid doesn't support the existing source. — Arthur Rubin (talk) 15:38, 26 June 2015 (UTC)
This suggests to me that the UI for VE is not properly separated from the code implementation by an abstraction layer, which I'd see as being pretty problematic. One of the points of putting a UI on top of a code revision process is to provide for some independence in evolution of the two through abstraction. So, VE is at present making the situation worse by being too tightly wound up with the code layer? This would seem to be a significant design flaw ... agreed? --User:Ceyockey (talk to me) 14:03, 27 June 2015 (UTC)
@Ceyockey: You’re right, well-architected code maintains appropriate separation between the front-end/interface, the logic, and the back-end/storage system. Indeed, VisualEditor doesn't interact with wikitext at all; it works with a pure HTML5 DOM back-end, mw:Parsoid, on which it builds a model for transactions and (eventually) real-time collaboration. That's why not only do other wikis use VisualEditor, but it is also used on websites like PLOS without using the MediaWiki at all (see e.g. this talk, about 35 minutes in).
As Arthur notes, Parsoid converts wikitext to HTML for editing in VisualEditor and other tools, and then back again when the page is saved. This recent update might interest you. The most recent of the daily tests, run across more than 150,000 randomly selected Wikipedia articles, show that problems with this conversion are actually very rare – rare enough that all of them, including false positives, errors caused by invalid wikitext, and problems that have been resolved in the last couple of months, can be listed on a single, short page.
HTH. Jdforrester (WMF) (talk) 17:53, 29 June 2015 (UTC)

Alternate proposal - choice of VE or source-editing at any given time an editor decides to edit[edit]

Every editor gets next to the original 'edit' tab a new tab with the title 'edit (visual editor)', and the old edit tab is renamed 'edit (source)' (appropriate naming making unambiguously clear to which editor an editor goes to be determined). The 'edit (visual editor)'-tab leads to the VE-editor, the 'edit (source)'-tab leads to the current edit interface. In the preferences, we get an option choosing either both, or one of the two are visible, and we have a follow-up RfC whether the two tabs are standard visible to every editor who did not make a choice either way.

  • Support as proposer. --Dirk Beetstra T C 09:55, 21 June 2015 (UTC)
  • Comment When VE is enabled, this is exactly what you see, except that the VE edit tab is just marked edit. The option to have both tabs or one is in preferences under beta. This RfC is precisely asking whether both tabs should be visible by default to new editors. Happy Squirrel (talk) 16:36, 21 June 2015 (UTC)
  • This is, indeed, exactly the proposal at hand, except for the question of what names ought to be on the buttons. If anyone has ideas about how to make this clearer (maybe we should move the screenshots to the top, and label them "If you want two buttons, then support" and "If you want one button for wikitext only, then oppose"? I just don't know how we ended up with this level of confusion today. Whatamidoing (WMF) (talk) 17:04, 21 June 2015 (UTC)
  • Support Some of use want the button more clearly named. I like the proposed naming here. Doc James (talk · contribs · email) 04:06, 22 June 2015 (UTC)
  • Seems like a community issue to me. MediaWiki namespace and you can call it "Editor for newbs" and "Editor for nerds". I'd preach about consistency, but I've given up on that with en.wp, Commons and de.wp. —TheDJ (talkcontribs) 18:35, 24 June 2015 (UTC)
  • Oppose As the order in which they'll appear isn't specified. The Wikimarkup editing system shouldn't be able to be shut off/not displayed.Godsy(TALKCONT) 23:27, 30 June 2015 (UTC)

Alternate proposal - ask new users[edit]

When a newbie registers, they will get a notice asking them if they want to use VE or not:

This way, if they don't want it, then they will be able to say no. This also links them to a guide and a page to test it out, preventing test edits by newbies wanting to test out VE. Esquivalience t 15:27, 28 June 2015 (UTC)

Without comment on the proposal, it's unlikely that experts and the Foundation could agree on the wording of the notice. VE is not WYSIWYG, nor "simple", and still (at least sometimes, if not often) generates serious errors, which are difficult to fix except by reverting. It's still beta, and should be labeled as such, both in the notice and on the buttons. — Arthur Rubin (talk) 17:25, 28 June 2015 (UTC)
This seems unnecessary, given that the original proposal isn't to force new editors to use VE, and they will never have to use it if they don't want to. –Prototime (talk · contribs) 21:23, 28 June 2015 (UTC)

Proposal for slight expansion of existing suppression criterion[edit]

There are regular occurrences where new editors to Wikipedia perform their first edit without realizing that their IP address will be shown in place of a username, and oversighters are periodically asked to suppress the IP information. There is a perception that the purpose of the current Oversight policy is only to protect registered users from accidental logged-out edits, and some oversighters will regularly decline such requests. This seems significantly problematic in that it is extremely easy to miss the "You are not logged in" flag at the top of the edit window (it is on a pale yellow background with black writing, and no differently coloured warning symbols). We know it's easy to miss because even experienced editors sometimes miss it. Attempts in the past to make this "notice" more obvious have been opposed by editors who deliberately choose to edit using their IP addresses, as well as others.

Therefore, I propose a slight expansion of the existing suppression criterion: request from new editor who can articulate that s/he did not realize that the IP address would be published in place of a username. We want to keep these new editors, not drive them away using rules that we do not apply to registered users; in fact, we want them to become registered users and keep editing. The fact that they have actually managed to find the way to request suppression indicates that they've quickly developed some useful Wikipedian skills. This is not a brand new oversight criterion, but an extension of an existing one to include not-yet-registered users/first time editors.

I've posted this here so that there can be discussion from the broader community, not just the small number of people who watch the Wikipedia:Oversight page. Risker (talk) 00:57, 19 June 2015 (UTC)

Discussion - Slight expansion of suppression criterion[edit]

  • Support - No reason to withhold this from those who would be most likely to need it. ~ ONUnicorn(Talk|Contribs)problem solving 01:14, 19 June 2015 (UTC)
  • Support - I think that it should only be used in obvious cases. Supdiop talk 01:39, 19 June 2015 (UTC)
  • Support. Seems eminently reasonable considering the number of requests we get from alarmed people who didn't realize editing = sharing their IP with everyone forever. Humans are a species known for not RTFMing (well, them and giraffes. Giraffes are the worst at it), and when it comes to internet safety it's better for us to err on the side of protecting them despite this. A fluffernutter is a sandwich! (talk) 01:44, 19 June 2015 (UTC)
  • Support per nom. -sche (talk) 02:18, 19 June 2015 (UTC)
  • Dupport - this criterion is clearly part of crietrion 1 (Non-public personal information about a real individual); if it's drequently declined because oversighters don't think it counts, we should change the policy to make it clear it does count. עוד מישהו Od Mishehu 03:54, 19 June 2015 (UTC)
  • I'll just comment on the basis that there are a significant number of logged out IPs which use IPs without disclosing the connection between themselves and a registered account. Maybe that ought be taken into account. The intent is generally good, however. NativeForeigner Talk 05:10, 19 June 2015 (UTC)
  • Oppose, and strong oppose unless add'tl procedures are implemented to verify requestors. As it is, I'm already concerned about the potential abuses of user/editor-hiding under criteria one; it enables possible cover-ups of attempts to evade scrutiny. To be honest, I think it is hard to claim that IP addresses of unregistered users meets the criteria even when read in the broadest context. LFaraone 05:17, 19 June 2015 (UTC)
    You sound like you've seen this happen in specific case(s), but I'm having trouble picturing what the misuse you're thinking of would be. Can you explain a little more how you see this being gameable in a way specific to people without (or claiming not to have) accounts, that wouldn't be already happening in cases where the user already has an account (we currently handle those cases as a matter of course, clearly covered under current OS policy). If it's all too beans-y to lay out in public, this kind of gaming is probably something Oversight-l should be aware of anyway, so maybe explain it there? A fluffernutter is a sandwich! (talk) 05:32, 19 June 2015 (UTC)
    I'd like to second Fluffernutter's request for some examples, either here or on the Oversight-L mailing list if it is eyes-only; I've been doing oversight since 2009, and the only time I've encountered someone "gaming the system" to get their IP suppressed was a longtime editor with a registered account; I've never seen a new/first-time editor do it. Risker (talk) 14:54, 19 June 2015 (UTC)
  • Support I think the community is collectively pretty silly when it comes to how big a deal we make about IP Address privacy. There are some edge cases where there are legit reasons why someone really needs to keep it a secret, but for 99% of us it really doesn't matter. But since that doesn't seem to be changing, if we are going to make a big deal about it, being consistent is a good thing, and there is no reason to deny IP editors who request this after creating an account when we already do it for editors who accidentally edit while logged out. I would however clarify that this is something the new account holder should need to affirmatively request, and not something we should take it on ourselves to request on the behalf of others, as sometimes occurs to hide IPs accidentally logged out editors. Monty845 05:26, 19 June 2015 (UTC)
  • Support, but only under limited circumstances. If an IP editor gets an account shortly after making one or a small number of IP edits, I would support suppressing their IP address. Or if an IP editor from a repressive country makes a "politically incorrect" edit and then realizes their IP address could be traced back to them, I would support a suppression (but also strongly urge the person to get an account). But if someone does a lot of IP editing and is unwilling to get an account, I'm not very sympathetic. — Richwales (no relation to Jimbo) 05:32, 19 June 2015 (UTC)
  • Support As someone with access to privileged / personal information in the form of IP addresses with regards to the account creation team, I can understand all too well how both new users and seasoned users can feel concerned for their IP being listed for a number of reasons - dynamic IP associated with vandalism, simple privacy concerns, etc. - and just because they're new, I feel that that is an unfair reason to deny that method of recourse to an IP user. Assume good faith and help them out, provided they can articulate it in a way that makes sense from a reasonable perspective. RegistryKey(RegEdit) 05:35, 19 June 2015 (UTC)
  • Support per the proposer's own rationale. Thryduulf (talk) 10:01, 19 June 2015 (UTC)
  • Comment I am interested to know what process would be in place to verify that a user requesting to suppress an IP address are in fact the same person. I think this is a great idea since accidental logged out contributions happen all the time but an even better (but albeit infinitely more complex) solution would be to merge an edit of an IP to a editor's account -- therefore correctly attributing the contribution. Mkdwtalk 11:16, 19 June 2015 (UTC)
While I don't disagree with you, Mkdw, this is pretty far outside of the scope of oversighters. I'm not sure if the ability to merge contributions is operative yet, or whether or not it is possible to merge *individual* edits by an IP to an account (bearing in mind that most IP addresses are dynamic and often have been used by multiple editors over the course of years), but the merge-edits ability is not part of the Oversighter toolkit, nor is it likely to be added. Risker (talk) 12:37, 19 June 2015 (UTC)
@Risker: I agree it's outside the scope of oversight, but we're essentially asking oversight to fix a problem about attribution of contributions. It's one fix, but I feel like the real fix would be to resolve the merging of contributions, and then let oversight do what they do best in terms of confidentiality and protection. Mkdwtalk 19:06, 20 June 2015 (UTC)
  • Comment - would it not be more prudent to make the "you are not logged in" notice more noticeable? I would also argue that this should only be actioned if the IP can actually be traced to a username, rather than opening ourselves into suppressing any IP for any reason. — foxj 15:14, 19 June 2015 (UTC)
I tried to make the "not logged in" notice more visible in May 2014 and was soundly defeated in my efforts; in fact, I received almost no support, at least in part because some WMF staff were doing some kind of "experiment" and kept declining any proposals. Even if it is more "noticeable", we still have plenty of evidence that even experienced editors who should be much more aware of the meaning of editnotices fairly regularly miss them; logged-out editing by experienced users is probably the #2 reason for suppression (after personal info of minors) and has been since the day suppression was made available.

The requirement that someone have an account is kind of defeating the purpose of this proposal; I would suggest that our standardized response to these cases (the OTRS 'canned text') strongly urge the creation of an account with appropriate links. Step One should be addressing what the user believes is an unexpected breach of their privacy. This isn't trying to protect people who are gaming the system, it is aimed at the top unexpected personal information exposures that new, unregistered users are exposed to. Oversighters already have the tools required to say "no" to a request that appears to be gaming the system. Risker (talk) 15:32, 19 June 2015 (UTC)

  • Support I have from time to time seen the need for this in running training sessions, where people have already edited as an ip and now want to get a user name. I'm sure there are other good cases. DGG ( talk ) 23:38, 22 June 2015 (UTC)
  • Support as proposed. OSers can still use their judgement when someone is requesting for the wrong reasons or to evade scrutiny, etc., this just gives them a little more flexibility. Dennis Brown - 10:57, 24 June 2015 (UTC)
  • Support - This simple measure will better respect the privacy of inexperienced editors and perhaps help us retain some of them. –Prototime (talk · contribs) 04:49, 25 June 2015 (UTC)
  • Support, This seems like a reasonable clarification of an already-existing policy. I don't see any issues with codifying this specific criteria in policy. Nakon 04:51, 25 June 2015 (UTC)
  • Support. I don't see a likely problem with this. If, somewhere, there is a record associating the IP with the account, I don't see a possible problem. I don't have access to the tools, but Oversight (and possibly Checkuser) access should be able to detect gaming attempts. As an Admin, I've revdeled some IPs from accidentally logged out accounts (usually, on talk pages, when they edit their signature) but it should be clear this is only on request. — Arthur Rubin (talk) 05:34, 25 June 2015 (UTC)

Add RFA to TW dropdown list[edit]

There should be another option under TW named RFA on a user talk page. When you click on it, you can then type in a description for the user and Twinkle should automatically create an RFA subpage and put {{subst:RfA-nom|YOUR USERNAME}} on the user talk page. GeoffreyT2000 (talk) 18:17, 21 June 2015 (UTC)

You might want to suggest that on Wikipedia talk:Twinkle, the discussion forum for Twinkle. RfA nominations are sort of rare though, but I can see the benefit in light of the complaints about the RfA nomination process being difficult in terms of transclusions (which was discussed on Wikipedia talk:Requests for adminship just a few days ago). Jo-Jo Eumerus (talk) 19:17, 21 June 2015 (UTC)
I don't see how this would solve the transclusion issue, since creating an RfA page and transcluding it when finished are different processes/stages. Sam Walton (talk) 20:17, 21 June 2015 (UTC)
Yeah, my thoughts exactly. Why would we add such a rare utility? Not to mention it could potentially cause mayhem. Best, FoCuSandLeArN (talk) 20:31, 21 June 2015 (UTC)
  • Not used enough to justify the mess it would cause. The RFA template does need cleaning up, but this can be done on a separate page, where it isn't likely to cause more cleanup for admin. Dennis Brown - 10:59, 24 June 2015 (UTC)
  • Agree with Dennis Brown: doesn't really serve much point given the shockingly low number of RfAs. —Tom Morris (talk) 13:59, 24 June 2015 (UTC)
  • We do need someone to overhaul the RfA submission process to make it simpler, it has become a barrier for some users and we might see an uptick if it weren't so daunting a process. –xenotalk 14:11, 24 June 2015 (UTC)
This, however, is not the solution; adding RFA to Twinkle will simply result in a glut of inappropriate nominations. Since such nominations often result in the retirement of the nominee when they are inevitably closed as failures, this is, however, a great way to help drive moderately proficient editors away from the project. Yunshui  14:14, 24 June 2015 (UTC)
Exactly. We need a separate page in the RFA space that the candidate can fill out, and allow noms to fill out, then press a single link and i will autotransclude once completed, but there is no reason for TW to be involved. As a matter of fact, most noms require 2 or 3 people to fill out something, so TW would be terrible for this. Dennis Brown - 20:03, 24 June 2015 (UTC)
  • RFA has many problems, but the complication of transcluding one is not an issue. There must be hundreds of editors out there who could pass if we ran RFA to the standards of 2004/5. There have been several extra barriers/criteria put on since then, including some I agree with, but I'm pretty sure that the transclusion process hasn't got more difficult in yonks. ϢereSpielChequers 11:12, 25 June 2015 (UTC)
    • Perhaps, but with so many nerds among us, it does seem silly that we can't streamline the RFA process a bit with some code. It used to be that if you fudged up the transcluding (I did on mine in 2012 and quickly fixed it) that some people would automatically vote against you. That isn't so much the case nowadays, but surely we can do better. Without Twinkle, and without making it VE-like. Dennis Brown - 13:21, 25 June 2015 (UTC)

Group disambiguation[edit]

I've just spent a while trying to disambiguate an article (2015 NCAA Division I Outdoor Track and Field Championships), which uses the common names for United States Universities. Its a repetitive process in related articles. In that sphere, state names and city names are common shortened names for the universities that bear the common name of the larger agency. So whenever one is working on an NCAA article, or an article on American Universities in general, those common shortenings would be used. Can't we build a set of those disambiguations that can be placed in a hidden header to an article that refers all links in the article to the set of defined names for that group? American postal codes have defined lists of 2 letter codes, which would currently all turn into disambiguation pages. For a long set of names (probably copied from list documents in sources) with the specified two letter code built in, it would certainly save editors a lot of labor to have an automatic feature that, if invoked, checks against the specified 2 letter codes and resolves the proper state name and wikilink out of it. Trackinfo (talk) 00:51, 24 June 2015 (UTC)

I use WP:POPUPS along with the User:Anomie/linkclassifier script. The script highlights links to disambiguation pages so they can be easily identified, and popups lets you disambiguate the links with a couple of button clicks. It's not exactly what you're suggesting but it will probably make things faster for you. Ivanvector (talk) 01:06, 24 June 2015 (UTC)
Hi, Trackinfo! How about this?
Those links could be replaced by bots. --NaBUru38 (talk) 20:05, 24 June 2015 (UTC)
Would redirects help here? Or are you saying that the abbreviation is to the city and in other contexts that abbreviation means other things? For example when you are discussing English football Liverpool, Leeds or Chelsea would clearly be references to those teams, but in other contexts you would expect the link to be to the place. ϢereSpielChequers 11:20, 25 June 2015 (UTC)

My Village name is missing in wikipedia[edit]

My village name is Pilligundlu (V) , Dodderi (post),Rolla (mandal) ,Madakasira (Taluk), Anantapur -515321 .it was missing in Wikipedia please add my village name Pilligundlu (V) . appreciate if you add as soon as possible .— Preceding unsigned comment added by 110.159.8.238 (talkcontribs)

Feel free to use the Article wizard to create an article on your village, or ask for someone else to do so. You will need to provide reliable sources for the information about your village. ~ ONUnicorn(Talk|Contribs)problem solving 16:20, 26 June 2015 (UTC)

Personal Death-list ?[edit]

I wonder if someone with technical knowledge could create a system where users could make/create their own personal death list. For example a list of celebs that are familiar to you. As I watch the Death 2015-list, it struck me that most of the persons on the list are unfamiliar to me. Possible as many as 95 %. Perhaps we could have a specific watchlist for persons on wikipedia that pops up on your page when someone on your list have died--Ezzex (talk) 17:02, 26 June 2015 (UTC)

Biographies of living persons[edit]

A bot should automatically remove citation needed templates from pages about living persons. See Wikipedia:Biographies of living persons#Remove contentious material that is unsourced or poorly sourced for more information. GeoffreyT2000 (talk) 14:41, 27 June 2015 (UTC)

There is actually an active RFC about what should and should not be covered by that on the talk page. Myself and others argue that merely being uncited does not mandate removal and so the citation needed tag would be fine to enforce WP:BURDEN and improve citation in cases where the claim in need of citation is not negative or otherwise harmful to the subject. Also, removing the tags by bot, without addressing what was tagged seems backwards even if you reject my position. Monty845 14:59, 27 June 2015 (UTC)

CHANGE YOUR FACEBOOK PAGE and add a simpl share bouton on evry page of wikipedia[edit]

I think that on the Wikipedia facebook page there should be a simpal coments field just like there is on evry other normal facebook page. I also think that there should be a simpal share bution at the bottom of evry Wikipedia page so that I or any one for that matter can simply share what the are looking at on Wikipedia with any siocal web site account that they want. I regard the fact that you don't have one as you are behind the times in a way so pleas strongly think about theees 2 things. thanks musch — Preceding unsigned comment added by ‎ 2601:1c1:8202:adad:9434:db4e:e185:a82c (talkcontribs) 01:10, June 28, 2015

Bad idea, even if you believe Wikipedia should be like Facebook. The page you "like" will change. — Arthur Rubin (talk) 02:08, 28 June 2015 (UTC)
  • Ah, no. WP is not a social media network. GregJackP Boomer! 02:13, 28 June 2015 (UTC)
And you really should look into fixing your understanding of written English. - Denimadept (talk) 02:26, 28 June 2015 (UTC)
@Denimadept: That was a wholly unnecessary dig intended to incite. Try to restrain yourself. --User:Ceyockey (talk to me) 02:57, 28 June 2015 (UTC)
@Ceyockey: I've got my priorities. - Denimadept (talk) 07:56, 28 June 2015 (UTC)
If memory serves (it's been a while since I've 'Faced'), you can create topic pages in Facebook that are essentially representations of Wikipedia pages ... (had to take a look): so a page like Neuroscience or I'll Follow You Down are essentially Wikipedia-described topic pages. So, people are already effectively 'liking' Wikipedia articles by using them to anchor Facebook topic pages. It would be useful to know how many such pages exist. --User:Ceyockey (talk to me) 02:57, 28 June 2015 (UTC)
About changing the Wikipedia facebook page -- there is a "suggest edits" link available on the page; it is under the "..." button beside the "share" button in the lower right corner of the top picture panel. --User:Ceyockey (talk to me) 03:01, 28 June 2015 (UTC)

It had not occurred to me that Wikipedia even had a Facebook page, but it seems it does: https://www.facebook.com/wikipedia. It looks legit, but I'm not sure just how I would definitively check that. Does anyone know whether it's officially sanctioned by the WMF? Who decides what goes on it? --Trovatore (talk) 02:38, 28 June 2015 (UTC)

The official social media links are available at https://wikimediafoundation.org/wiki/Social_media Whatamidoing (WMF) (talk) 03:21, 28 June 2015 (UTC)
See Wikipedia:Perennial proposals#Share pages on Facebook, Twitter etc. Eman235/talk 03:51, 28 June 2015 (UTC)

WikiWidgets[edit]

Some time ago I thought that many readers would benefit if we could embed simple interactive programs (widgets) into articles to help illustrate and explain the concepts within them. So I thought of a crude way to implement it and made a proposal here. However, maybe due to technical and conceptual immaturity, it didn't garner much support. So I took it to my home project, the Spanish Wikipedia. There it sparked some interest, and slowly we refined it and eventually implemented it. Today we have two wikiwidgets already deployed, you can check them out here and here.

Today I'd like to share with you the way we implemented it, and ask for your support to get it working here in the English Wikipedia. Basically, to get the wikiwidgets working we need three things.

First we need to create the Template:WikiWidget. That's easy, I just did it. Second, we need to add the following lines to MediaWiki:Common.js:

/**
 * Inserts WikiWidgets in the articles with the Template:WikiWidget
 * WikiWidgets serve to illustrate and explain interactively the concepts treated within articles
 */
$( '.WikiWidget' ).each( function () {
	var wikiwidget = $( this ).attr( 'data-wikiwidget' );
	importScript( 'MediaWiki:WikiWidget-' + wikiwidget + '.js' );
	importStylesheet( 'MediaWiki:WikiWidget-' + wikiwidget + '.css' );
});

This code checks for the presence of the WikiWidget template in every page. When found, it loads the code of the wikiwidget named in the first parameter of the template. If the wikiwidget is called X, the loaded code will be MediaWiki:WikiWidget-X.js and MediaWiki:WikiWidget-X.css. So the third step is to add the code of one or both existing wikiwidgets to their proper pages in the MediaWiki namespace, that is:

You can find the code in the homonymous pages in the Spanish Wikipedia, or at the GitHub project here.

Besides the implementation, a bit of documentation will be needed for the template, at Wikipedia:WikiWidget and maybe even a WikiProject, but I can take care of that. What I cannot do by myself is the stuff in the MediaWiki namespace, but even if I could, I think that the project is novel enough to require some support of the community before asking an admin to implement it. So I hope you like it and support it, and even help me develop it, cheers! --LFS (talk) 15:50, 26 May 2015 (UTC)

While this would be interesting in theory, I have to oppose this on the principle that we shouldn't require JavaScript for page content. JavaScript can and should enhance site functionality, but shouldn't be strictly required whenever possible. {{Nihiltres|talk|edits}} 16:37, 26 May 2015 (UTC)
I also think this is a bad idea, for a number of reasons. Embedded JS raises serious performance, accessibility and security concerns. Performance in that running JS uses CPU cycles. Accessibility as many people disable JS; many more have browsers unable which don't support HTML5/JS which this needs. And security as having complex and arbitrary JS run on pages opens them up to all sorts of exploits. We can already do animations with animated GIF or movies, so there’s little need for it.--JohnBlackburnewordsdeeds 16:52, 26 May 2015 (UTC)
Hi, thanks for your constructive criticism. The wikiwidgets don't make JavaScript necessary in any way. I forgot to mention this (sorry) but the second parameter of the WikiWidget template is the file to be shown when the wikiwidget isn't loaded. In fact, the file is always shown, it's just that it's replaced by the wikiwidget when the JavaScript code loads. If the code doesn't load for whatever reason, then the file will just stay there. This means that the JavaScript code isn't required at all, pages will render fine without it. Having JavaScript just enhances the user experience.
As to security, the development process of wikiwidgets is very similar to that of gadgets, yet we don't reject gadgets for security concerns. We just need code review, like with gadgets or any other piece of code, and this will be accomplished through the GitHub project.
Regarding performance, I can edit the existing wikiwidgets so that they don't start automatically, and we can establish this as a rule for further wikiwidgets. This would make them much less of a bother for those with weak CPUs.
I think that a wikiwidget isn't nearly the same as an image or a movie: it incorporates a key element to the learning process: interactivity. The existing wikiwidgets already show some of the potential (did you play with them for a while?), but there is a lot more to be discovered. Imagine other wikiwidgets for explaining the movements of the planets or other physical phenomena, and all those that we cannot imagine yet. The field is vast. But even if we never get beyond a few wikiwidgets, then a few is better than none, don't you think? We already have two available, all we need are a few lines of code to get them working. Cheers! --LFS (talk) 01:55, 27 May 2015 (UTC)
Your two demo links were impressive. They are very valuable additions to the articles. Unfortunately I don't think we can allow editors to inject arbitrary code into pages. It's a security issue. Alsee (talk) 02:56, 27 May 2015 (UTC)
Hi Alsee, I'm glad that you find them valuable! As mentioned above, the security risk is no greater than with gadgets. Do you think gadgets are a security issue? --LFS (talk) 03:35, 27 May 2015 (UTC)
I do, and I suspect that anyone who knows anything about what could be done by an admin who is careless (or whose account was hacked by someone malicious) will agree with me. We ought to require code review for popular gadgets—including every single change, not just when it's first enabled. Code review isn't fun, but it does prevent problems. WhatamIdoing (talk) 08:50, 27 May 2015 (UTC)
WhatamIdoing: so some gadgets are not reviewed? That sucks, I agree that every gadget should be reviewed! The one gadget I contribute to (ProveIt) does have code review. In any case, unlike gadgets, WikiWidgets will be developed in a centralised way through the GitHub project. In GitHub, only approved users can contribute code, and if a non-approved user wants to contribute, s/he has to do a "pull request" and the code will necessarily go through review. GitHub is a tried and tested platform for code collaboration. If the project gets implemented, people will not rush in to create wikiwidgets, more likely there will be one submission per year, so I will definitely review it properly. And if somehow the project starts getting too many submissions for me to review (extremely unlikely) then surely other developers will help me, especially given the fact that this project aims to be inter-wiki, so the same code will be used in all Wikipedias. --LFS (talk) 13:10, 27 May 2015 (UTC)
Gadgets have been mentioned but they have two key differences. First they are opt-in. They may start off as some editors personal tool, which they advertise and gets adopted. Eventually they may be added to preferences, but that's not a requirement, and many still exist as snippets of JS and CSS you add to your own common.js and .css or similar. This means they cannot affect editors who haven't enabled them and aren't aware of them. Second because of they way they work they are typically visible to editors using them across all pages. This means that problems with gadgets are almost always spotted and reported very quickly.
On the other hand problems in articles can go unnoticed and unreported for a very long time, weeks, months even years. At the moment these only damage the encyclopaedia, by lowering its average quality. But if JS widgets were allowed in page the potential for direct harm to readers is much much greater, which also increases the incentive to do harm, and to hide the nature of the damaging JS. Mandating a thorough code review would catch many if not most of these but that would be an immense amount of work, which we don't do for any other sort of content. JohnBlackburnewordsdeeds 16:24, 27 May 2015 (UTC)
JohnBlackburne, I take it that your previous concerns about performance and accessibility were answered. It seems that the security issue is the main concern for everyone involved in this discussion, so hopefully if we dismiss it the project may get some support. WikiWidgets will be developed through GitHub, the largest platform for code collaboration in the world. GitHub has a system by which only approved users may submit code directly, and non-approved users have to submit a "pull request" which forces approved users to review the code before merging it. This is the way most software is developed today. The existing wikiwidgets are composed of a single JavaScript file of less than 1000 lines of code, and future wikiwidgets are unlikely to grow much bigger, which means that they are really easy to review, compared to gigantic softwares like MediaWiki. You mention that the workload may be too great, but don't worry, most likely there won't be a single submission in the rest of the year, and if there is I will be glad to review it, rather than burdened. (Plus you won't be doing the work, I will!) As with any piece of software, the risk of malicious code slipping by will never be absolute zero, but I hope you will not let that dim chance put a stop to a project that could be a step forward for Wikipedia and has much more potential to do good than harm. --LFS (talk) 18:58, 27 May 2015 (UTC)
No, the performance and accessibility issues are still issues: pages on WP currently load fine with no JS at all (though it's needed for many optional and editing features). But security is the main concern. We certainly don't want to require editors to sign up to and become familiar with GitHub to contribute. It has its uses but largely replicates what we have here already. E.g. instead of a commit history we have a page history. Instead of being able to fork here you can use a sandbox or sandboxes. And as far as we are concerned WP's mechanisms are stronger: we have e.g. user rights so not everyone can edit code. Anyone can sign up to GitHub. Users contributions here are tied to their accounts, useful for awarding rights and reviewing them. That would not be possible with GitHub contributions. And so on.JohnBlackburnewordsdeeds 19:34, 27 May 2015 (UTC)
Ok JohnBlackburne, let me know what concerns you about performance and accessibility, maybe there is a solution. Regarding the use of GitHub, please remember that software designed for code collaboration is much more efficient at code collaboration than software designed for building an encyclopedia. The MediaWiki software is developed using Git, though not GitHub. We use another code review software called Gerrit, plus Phabricator for tracking bugs. Many MediaWiki gadgets are developed using GitHub, as well as some extensions and dependencies of the software. Nevertheless, if this project gets some support, I can almost certainly move the development of wikiwidgets to Gerrit and Phabricator, where it would be more in line with the way the majority of the software for Wikipedia is developed. --LFS (talk) 02:16, 28 May 2015 (UTC)
Again the performance and accessibility issues are that it uses JavaScript. I am typing this on a relatively old (2006) laptop. Hardly ancient and it still works fine. Except many web sites are unusable due to JavaScript; they slow to a crawl, and/or start using 20% of CPU. Open two or three tabs and it can bring my whole machine to a halt. So I sometimes have to turn off JavaScript to browse them. Not WP though which works fine without JavaScript (though I loose some gadgets such as popups). Right now any WP page wastes no CPU cycles on JS whether reading or editing. If it did I would have to consider disabling JavaScript to view such pages, or not visiting them at all. Other people may not have that choice, or may not be aware of it, so may just find WP suddenly slow and stop visiting. Still others will disable JavaScript for other reasons: to disable adverts, or paywalls, or for general security reasons. And many will have older browsers which do not support the particular HTML/JS capabilities this depends on.
The point about Github is these are content, not parts of the WP software. And content is hosted on WP, or on Commons. This even includes source code, such as Lua, and a limited amount of JS such as MediaWiki:Common.js. Hosting it on GitHub would just exclude many editors from contributing, whether that's contributing code, checking and verifying code, or making suggestions for improvements. Given that GitHub largely duplicates what we have here it would seem perverse to host it there when it can be done very easily on WP with far better integration into WP systems and accessibility for WP editors.--JohnBlackburnewordsdeeds 19:50, 28 May 2015 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── I'm adding a few quick comments here, to make sure that we're all using the same language:

  • "Gadget" means "thing listed at Special:Gadgets". These are the scripts that you'll find in Special:Preferences#mw-prefsection-gadgets. If you create the same kind of thing, but it isn't listed there, then it is called a "user script".
  • Gadgets can be, and sometimes are, enabled by default. At the moment, I count nine gadgets enabled by default in the list at MediaWiki:Gadgets-definition at the English Wikipedia (this is the page you [if you're an admin] change to add, remove, or re-configure all gadgets). The list of on-by-default gadgets include mostly Javascript (e.g., charinsert, RefToolbar, Reference Tooltips) and a couple of things with both Javascript and CSS (e.g., Teahouse, Featured Article links).
  • Code review is a sort of (very) fully protected style of WP:Pending changes for code. The general idea is that I post my code revision, but nobody uses that code unless and until someone else (someone trusted) looks it over and agrees that my code is sensible and unlikely to break stuff.
  • There is no way to require code review for any user script, any gadget, or any other page hosted on wiki. (Even if it could be applied to Javascript files or pages in the MediaWiki: namespace, Pending Changes never stops an admin from making live changes to a page.)
    • Exactly like user scripts, almost none of the gadgets at the English Wikipedia are fully (formally) code reviewed. This is because most of them are hosted directly on wiki, where your change to the page is live immediately, no matter what.
    • There is no way to prevent any admin from making immediate changes to what's in the list of gadgets or whether they're turned on by default. Other tech-savvy admins also watch the page, but your (any admin's) change to the gadgets page is live immediately, and if your typo breaks things, then it's broken for thousands of readers and editors immediately. There is currently no way to force code review for this page. Admins can optionally choose to post their suggested code in a sandbox or on the talk page, but there's nothing except their own fear of breaking things to require sensible measures like that.
    • Ditto for pages like MediaWiki:Common.js, which hosts what you might think of as "gadgets" that you're not allowed to opt out of. m:WikiMiniAtlas is a particularly relevant example, since it's code-reviewed using the same system that LFS is proposing, it's enabled for everyone (with no ability to opt out, even), and it directly affects article content.
  • The lack of code review for on wiki scripts has led to a variety of problems, usually minor, over the years. Here at the English Wikipedia, it's usually resolved within a few hours. At some of the smaller wikis, problems have persisted for years, and many of them are quite easily identified through basic code review. For example, in 2013, someone found and fixed a problem at a small Wikipedia that was due to someone pasting the same code twice into the common.js (or was it common.css?) file. This is the sort of problem that code review usually catches.

If you're interested in this problem, then I'll add that a system for code review for gadgets and other designated scripts could be implemented, but it would require more than a little bit of dev time. I don't know if it's likely to happen unless the larger communities request it. WhatamIdoing (talk) 15:19, 29 May 2015 (UTC)

Thanks for your contribution WhatamIdoing. I just checked and it seems like Gerrit has no repositories for gadgets! It looks like they are all developed via GitHub or some other code developing platform, or even through no platform at all (no code review). Indeed it would seem that organising and even centralising gadget development would be a good thing, but this is another issue (and a big one for sure). I may start a proposal at Wikimedia when I find the time. Anyway, back to the wikiwidgets, I told JohnBlackburne that I can probably move their development to Gerrit, but it would probably be easier to do that if we first implement wikiwidgets in the English Wikipedia, as doing so would add weight to the request to open repositories for them at Gerrit. Do you think that it would be better to move the development of wikiwidgets to Gerrit, or does it seem equally ok to you if it's done via GitHub?
JohnBlackburne, regarding performance and accessibility, I updated the code of the wikiwidgets so that they don't start by default. Could you check if the pages with the wikiwidgets in the Spanish Wikipedia load ok for you now? Here and here are the links. Cheers! --LFS (talk) 15:14, 5 June 2015 (UTC)
I have no preference between Gerrit and GitHub. I am satisfied with any platform that encourages code review. WhatamIdoing (talk) 20:35, 5 June 2015 (UTC)
I would actively oppose a policy that required using a proprietary service to contribute to Wikipedia. LFaraone 05:05, 14 June 2015 (UTC)
  • Tenatively support: This would be very useful for all sorts of things. An immediate one that comes to mind is illustrating things in cue sports articles, with a virtual billiards, pool, or snooker table. My security hairs raised immediately too, along with those of others, but your answers so far seem adequate. I'm seeing some "damned if you do, damned if you don't" flawed reasoning in some of the security-related naysaying. We can't simultaneously expect that the ability to inject Javascript into pages must be strictly limited, then complain that it can't be strictly limited because that would impede editors from using this tool. It's perfectly fine to require people to use GitHub if that's what's it takes to do this securely. We do stuff like this all the time, like now all the interwiki stuff is done offsite at Wikidata, and I can't be bothered to figure out how to use it. There are 100,000 other things for me to do on WP, so no overall productivity to the project is lost; some people just become Wikidata-competent and some don't. The move of complex templates to Lua modules is the same; some editors choose to learn enough Lua to deal with it, others work on something else. I also don't buy the "we can't require Javascript" argument; it'd be a simple content guidelines matter to add a line somewhere saying not to build articles in such a way that they can't be understood without JS. This really isn't any different from adding videos and other supplementary material, and frankly WP is already greatly usability-impeded without Javascript, as are almost all modern, complex websites. JS support is just part of how the Web basically works, and has been since the late 1990s.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  03:33, 28 May 2015 (UTC)
Thanks for the tentative support SMcCandlish, let me know if you see any blocking problems. --LFS (talk) 15:14, 5 June 2015 (UTC)
I don't see any, really.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  20:29, 5 June 2015 (UTC)
  • These examples show that the javascript is used differently to the rest of the javascript on wikipedia. Rather than a tool for editing (or reading) support, the javascript is the content. I think this is important and that this this javascript needs to be treated more like images to video than the rest of javascript (think: moving to commons, systematic approaches to finding display alternatives, etc.). Stuartyeates (talk) 03:47, 28 May 2015 (UTC)
Stuartyeates, moving the wikiwidgets to Commons would definitely make sense, as the code should be exactly the same throughout the various Wikipedias, except for the internationalised messages. However, I'm pretty sure that the software isn't quite ready for that, and until there are enough wikiwidgets in enough Wikipedias, there is little incentive for the Foundation to invest resources on it. If we want the wikiwidgets to be hosted in Commons, I think that the best start would be to implement them in enough Wikipedias, starting by the English Wikipedia, and if the project grows enough, we can then do a stronger proposal to the Foundation. --LFS (talk) 15:14, 5 June 2015 (UTC)
I tend to concur, though it wouldn't hurt to ask over at Commons and see what the reaction is. These strike me as different and severable issues though. Where it's hosted has little to do with whether en.wiki should use this.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  20:29, 5 June 2015 (UTC)
This sounds interesting, but I don't personally have resources to help out further. However I do want to make three suggestions here with regards to performance:
  1. Don't auto-start. As LFS pointed out, these widgets should only start computing things, creating DOM elements, bind event handlers, make HTTP requests, etc. until after the user has first performed some kind of interaction with the widget.
  2. Don't auto-load. In fact, I'd like us to take it a step further and also don't call importScript/importStylesheet until after user interaction. Loading the code and stylesheets is still significant overhead in HTTP requests and consumer bandwidth usage. This means that, in order to eliminate these initial loads, we have to standardise the "start" button (or equivalent) as part of the WikiWidget provider gadget. E.g. a play button or some other simple interface. We don't have to be limited to just a single way to start a widget, but we should provide a finite number of them. This also makes it easier to maintain a consistent user interface since these "entry doors" will be controlled by the same gadget (the WikiWidgets provider).
  3. Specify resources. Don't assume there will be a one JS and one CSS file. Instead, let the template declare which ones are expected to exist. Making a needless HTTP request that will only yield a 404 Not Found is a waste of resources.
Thanks for this great idea! --Krinkle (talk) 14:45, 9 June 2015 (UTC)

---

I'm glad you like the idea Krinkle. I liked your suggestions too, so I implemented a couple of them in the Spanish Wikipedia. The "don't auto-start" suggestion was already implemented when you wrote. The widgets loaded automatically but didn't auto-start. Regarding your second suggestion of not auto-loading the widgets, the two available widgets so far are for relatively obscure topics, so they don't load too often and shouldn't be a burden to the servers, but in the future they may become more common, so the suggestion is reasonable. Furthermore, having a unified interface for the wikiwidgets sounds like a good idea too, so I created a logo for the project based on your suggestion of a play button and the standard colors of the Wikimedia logos. The project needed a logo too, so now it has one, yey!!

WikiWidget Logo.svg

I also adjusted the JavaScript for MediaWiki:Common.js so that the logo is loaded instead of the wikiwidgets, and the wikiwidgets are loaded only when the logo is clicked. The new code for MediaWiki:Common.js is:

var WikiWidgetLogo = $( '<img>' ).attr({
	'class': 'WikiWidgetLogo',
	'src': 'https://upload.wikimedia.org/wikipedia/commons/thumb/5/57/WikiWidget_Logo.svg/200px-WikiWidget_Logo.svg.png',
});

WikiWidgetLogo.click( function ( event ) {
	var wikiwidget = $( event.target ).parent().data( 'wikiwidget' );
	importScript( 'MediaWiki:WikiWidget-' + wikiwidget + '.js' );
	importStylesheet( 'MediaWiki:WikiWidget-' + wikiwidget + '.css' );
});

$( '.WikiWidget' ).html( WikiWidgetLogo );

I also had to add a line to MediaWiki:Common.css to make the logo shine a little when hovering over it:

.WikiWidgetLogo:hover {
	cursor: pointer;
	opacity: 0.9;
}

So now, only the logo is loaded by default, and when clicked, the wikiwidget is loaded, which doesn't auto-start. Besides minimising requests to the server, this should make the wikiwidgets much more bearable for slow computers. The new implementation has already been deployed in the Spanish Wikipedia, you can check it out here and here. As to your last suggestion regarding explicit mention of the resources in the template, I think it is a good idea and should be implemented, and I tried several solutions in my mind and my local wiki. However, I haven't hit on the right one yet, there are several annoying little problems, so I left it rest for now. I hope it isn't a blocking issue for you, though I'll try to solve it in the following days.

I asked and got repositories created for the two existing wikiwidgets at Gerrit, here and here. This removes the requirement of having to create an account in a for-profit third-party service like GitHub in order to contribute to the project, which indeed wasn't ideal. Can I count with your support now, LFaraone and JohnBlackburne? Is there any other blocking issue?

WhatamIdoing, SMcCandlish, Stuartyeates, any comments on the new implementation? --LFS (talk) 03:34, 29 June 2015 (UTC)

Luis Felipe Schenone, I'd just like to add a comment: wow. The existing wikiwidgets on eswp look amazing. I can't wait until these get implemented here. Nice work! APerson (talk!) 04:19, 29 June 2015 (UTC)
I don’t see there being a difference between Gerrit and GitHub. I have an account at the latter, it cost me nothing, it has never popped up with a payment request. I still don't understand why these need to be hosted on an external site rather than e.g. WP itself. We have templates and modules on WP, two sorts of programs. The benefits are significant: a familiar interface for editing, diffs, history, no need to create a separate account, close integration with user accounts. Sites like GitHub offer richer environments for large projects with many branches or contributors but that’s overkill for these. Besides they have to exist on WP somewhere; once they do then any editor with enough rights (autoregisted I asssume to match your rights) will be able to work on them, fixing bugs, optimising code, adding features, documenting or better formatting what is there.
Other than that it does not address my other concerns, of performance, accessibility and security. Even if these are totally benign, so they don’t autorun, fallback to an image with incompatible browsers/JS disabled, and do nothing harmful having user editable JS on an encyclopaedia that anyone can edit has all sorts of security implications. We have a few JS files on WP already but they can only be edited by admins, and tend to only be touched by a handful of experienced admins, as any wrong edit can break things badly.--JohnBlackburnewordsdeeds 05:17, 29 June 2015 (UTC)
Two points:
  1. When Krinkle says Loading the code and stylesheets is still significant overhead in HTTP requests and consumer bandwidth usage, you respond ... they don't load too often and shouldn't be a burden to the servers .... Consumers are the clients, not the servers. Do not underestimate the number of people who use dial-up access or have limited-data plans.
  2. As someone who writes JS for a non-WikiMedia MediaWiki wiki, I'll echo some security concerns. Who writes the JS? How does it get promoted into the MediaWiki space? There's a reason only Admin+ can edit global JS and only individuals can edit JS in their own user space.
I'm not saying it can't or shouldn't happen. I'm only saying that there's more to it than plug it in and turn the crank. JS in articles should get the same level of scrutiny (and maintenance) that Gadgets get. --Unready (talk) 09:35, 29 June 2015 (UTC)

History-from-this-point link[edit]

I would like to propose Wikipedia:Village_pump_(proposals)/Archive_113#Link_from_an_old_revision_to_its_point_in_page_history again now. And I would like to add a proposal about adding a similar "Contributions-from-this-point" link next to the (talk | contribs) links in diffs and pages histories. User:Nyttend participated in the previous proposal. Iceblock (talk) 14:17, 29 June 2015 (UTC)

I still support the original proposal, while I have no opinion on the new one. If it's successful, we can add the link to MediaWiki:Revision-info. Nyttend (talk) 14:40, 29 June 2015 (UTC)
I would support this as well. Sounds like a great idea. --Ahecht (TALK
PAGE
) 15:16, 29 June 2015 (UTC)
Support this. I could have used it today. Diego (talk) 15:18, 29 June 2015 (UTC)

Although, if you had the first proposal ("find this revision in revision history") the second one is redundant, as the revision history page already has a "cur" link that finds the differences between that revision and the current page. Diego (talk) 15:44, 29 June 2015 (UTC)

I think that it's a different idea. For example, if you're at [2], the contributions-from-this-point link would be [3], showing other contributions made by the same user immediately before or immediately after the one you were looking at. Nyttend (talk) 16:36, 29 June 2015 (UTC)
Yes, Nyttend, this is what I am thinking of. Iceblock (talk) 16:41, 29 June 2015 (UTC)

VisualEditor in Microsoft Edge[edit]

In one month, Windows 10 with its new browser Microsoft Edge will be officially released. Therefore, its time to have support for VisualEditor in Microsoft Edge. GeoffreyT2000 (talk) 23:48, 29 June 2015 (UTC)

Hi GeoffreyT2000, VisualEditor is expected to work in Edge. Have you encountered any problems with it? If so, please post the details to WP:VisualEditor/Feedback. Whatamidoing (WMF) (talk) 17:28, 30 June 2015 (UTC)

Userpage drafts shown in search engines[edit]

Hello,

I recently realised that if you try to Google for any topic, you also get userpage drafts in the search results. For example, see this wikipedia entry and the corresponding search query. In most userspace drafts, it is not obvious that the article is a draft under progress, causing readers to possibly get confused.

To deal with it, I can possibly see two ways out -

  1. All userspace draftspages have NOINDEX added to them. If I remember correctly, all drafts currently in the Draftspace use something similar and this should solve the issue for us. If there is no such easy option to locate drafts in the Userspace, we could consider if putting NOINDEX on the entire userspace itself is feasible
  2. Consider having a policy to move Userspace drafts, atleast for retired users to Drafts namespace.

What do others think?

Soni (talk) 09:36, 1 July 2015 (UTC)

The whole of userspace desperately needs to be NOINDEXed because it is very lightly patrolled. There's too much spam and other self-promotional crap around and not enough people deleting it -- not to mention copyright problems, attack, BLP and child protection issues. MER-C 13:01, 1 July 2015 (UTC)
I'd support a NOINDEX of the userspace. But perhaps there's a way to make them default to NOINDEX and allow that state to be overridden on individual pages? Praemonitus (talk) 21:24, 1 July 2015 (UTC)
I'd support a blanket NOINDEX of the userspace as well. I can't think of a good reason not to. --Ahecht (TALK
PAGE
) 23:11, 1 July 2015 (UTC)
NOINDEX all of userspace. I already do that with all of my own for quasi-privacy reasons, anyway. (BTW you can NOINDEX JavaScript with // __NOINDEX__ and both JS and CSS with /* __NOINDEX__ */) --Unready (talk) 00:06, 2 July 2015 (UTC)
Support NOINDEX also. These pages are not really of interest to the average internet user and might confuse them. Happy Squirrel (talk) 01:37, 2 July 2015 (UTC)
Support a blanket NOINDEX of all userspace. Geogene (talk) 18:24, 2 July 2015 (UTC)
Yes, I agree. I have long NOINDEXed my user page and sandbox. We tell people WP is not a web host and then provide a web host. Thincat (talk) 18:35, 2 July 2015 (UTC)
Support. I can think of no legitimate reason why userspace content needs to show up on search engines - and many good reasons why it shouldn't. AndyTheGrump (talk) 18:49, 2 July 2015 (UTC)
Hrrm, I'm going to noindex my page right now! Very good idea. Eman235/talk 19:38, 2 July 2015 (UTC)