Wikipedia:Village pump (proposals)

The Wikimeda Foundation is working on a new software project called New Wikitext Editor (also known as NWE, or 2017 Wikitext Editor). The "new editor" is being built as a new wikitext mode within the Visual Editor extension. This allows the WMF to consolidate on a single editor with both Visual and wikitext modes. The plan is for this to become the default wikitext editor in a few months. The current wikitext editor would be temporarily retained as an opt-in in preferences, but eventually the current wikitext editor would be removed completely. Please view mw:2017_wikitext_editor for a more thorough explanation of the project, as well as the WMF's reasons for it. The new editor is available for opt-in testing under the Beta features section of Preferences.

The WMF is still working on a number of issues with the new software, however over the last few months several editors have raised a pair of issues which (in my opinion) they have not constructively addressed. Both of these issues appear to be a direct consequence of designing the "new wikitext editor" as a mode within Visual editor. The issues are:

1. Slow load time, primarily on larger articles. Different people may experience different load times, but I will report my experience. With the current wikitext editor I am able to start editing the article United States within 3 seconds after clicking edit. (The toolbar at top took a moment longer to finish loading, but that does not obstruct editing.) The new editor took 30 seconds to load before I could begin editing. With the current wikitext editor it took 5 seconds until I could edit our largest article (List of named minor planets (numerical)). With the new editor my load time was 127 seconds.
2. Faulty previews. The new editor does not provide genuine article-view previews. Instead it uses the Visual Editor rendering engine for previews. This results in a large assortment of things that render incorrectly in preview, or fail to render at all. The WMF has been working to address these issues for years as part of the Visual Editor work, and they plan to continue hunting down and fixing many of these rendering problems. However the WMF has indicated that some of these rendering problems are CANTFIX or WONTFIX. They hope to address the common cases, and their goal is to eventually get 99+% correct previews.

The WMF has been developing a Technical Collaboration Guideline. According to the guideline, the community is invited to submit "actionable blockers" on any software project. These are issues that block deployment unless/until the issues are adequately resolved. This RFC is seeking consensus to formally submit the one or both issues as actionable blockers. You may support one issue as a proposed blocker while opposing the other.

EDIT FOR CLARIFICATION: The WMF has been developing a Technical Collaboration Guideline. It is currently a draft. At least one WMF staff member has been actively seeking to test the guideline in action (Qgil-WMF) and another WMF staff member subsequently requested removal of any mention of the guideline (Keegan (WMF)). Editors are reminded that it is merely a draft. This RFC could be interpreted by the WMF as a test of their draft best practices for collaboration with us, or it could be interpreted as some generic consensus on the New Editor's prospects for successful deployment if specific issues are or are not addressed, or it could be interpreted in some other manner. In any case, our goal is to work with each other as partners in a positive and constructive manner, seeking to serve our shared mission to the best of our ability. Added: Alsee (talk) 20:27, 19 January 2017 (UTC)[reply]

Proposals:

1. Actionable Blocker: Load time. Load time is a priority concern for both new editors and experienced editors. Possible resolutions:
   • We could happily retain our current wikitext editor; or
   • if possible, drastically reduce New Editor load times, particularly on large pages.
2. Actionable Blocker: Article previews. Previews are a critical part of the learning process for new editors, as well as a critical tool for experienced editors. Inaccurate previews will confuse, disrupt, and frustrate. Possible resolutions:
   • We could happily retain our current wikitext editor; or
   • previews must use the article-view rendering engine (this is called the PHP parser), as well as any other relevant parts of the article-view software stack. This fixes the assorted rendering errors all at once, and it ensures that previews remain synchronized with article views when any changes are made to the software.

Alsee (talk) 00:04, 17 January 2017 (UTC)[reply]

Responses

• Support both. The load time on large articles is gross, and using an entirely different rendering engine for previews was a bizarre design decision. Unless both of these issues are adequately resolved, our current wikitext editor is clearly superior to the proposed replacement. If it ain't broke, DON'T BREAK IT! Alsee (talk) 23:52, 16 January 2017 (UTC)[reply]
• Support both Loading time is a problem with VisualEditor, I am guessing that it's a problem with Parsoid. And the preview engine should use the parser, not it's own software, otherwise it's just reinventing a wheel. A square one most likely. Jo-Jo Eumerus (talk, contributions) 00:08, 17 January 2017 (UTC)[reply]
• Strongly oppose removal. To clarify, strongly support both (03:58, 17 January 2017 (UTC)). On some very large pages the text editor takes a bit to load, let alone the JavaScript-heavy visual editor. The visual editor has its uses and I support keeping/improving it, but making it the sole option would definitely make it harder for me to edit. Daß Wölf 01:34, 17 January 2017 (UTC)[reply]

  It is a mischaracterization to say that the WMF is making the VE the sole option--it is that both the VE and the 2017 WTE use the same root software. --Izno (talk) 13:43, 17 January 2017 (UTC)[reply]

  Thanks for your reply, I wasn't aware that VE and 2017 WTE were different things. Still, new WTE also has bad loading times. For example, the minor planets list referenced by Yodin below takes about 20 seconds to render in reading mode, 5 seconds in normal edit source (less than reading mode!), 114 seconds in new edit source and at least 5 minutes and 12 timeouts in VE (I gave up). This page takes around 2.5 seconds in both reading mode and old edit source and 21 seconds in the new edit source. In both cases loading the new edit source caused prolonged browser freezing and delayed keyboard and mouse response as long as the minor planets page was opened in a background tab. I'm going with "don't fix what ain't broke" here. Daß Wölf 01:10, 18 January 2017 (UTC)[reply]

• Support both. I'd rephrase the first one as "loading times must be less than or equal to the current wikitext editor". Previewing using Parsoid is a mind-bogglingly stupid decision, especially when proper previewing is just an API call away. MER-C 02:59, 17 January 2017 (UTC)[reply]
• Support load time as a blocker. Do not support previews as a blocker. Previews are pretty gosh-darn close. --Izno (talk) 13:43, 17 January 2017 (UTC)[reply]

  Dear Izno, would you submit an edit when you can't preview it? --NaBUru38 (talk) 00:13, 24 January 2017 (UTC)[reply]

  @NaBUru38: You can preview your edits in WTE2017, though the workflow is a little wonky: Click "Save Changes", and in the box that pops up is an option "Show preview". There's a task open to pull the "preview" button onto the main editing screen at phab:T153306. The original poster of this discussion is making the distinction that previews are not 100% equivalent to the PHP parser (which is a fact, but lacking the context that something like 99%+ renders using Parsoid are correct), not that they don't exist. --Izno (talk) 00:27, 24 January 2017 (UTC)[reply]

• Support both as I will any other reasonable measures that may achieve allowing us to "happily retain our current wikitext editor". — Godsy ^(TALK_CONT) 13:46, 17 January 2017 (UTC)[reply]
• Weak support 2, wary about 1. Load times are going to vary from computer to computer and browser to browser, and I think it's hard if not impossible to explicitly say that a specific measured load time applies to everyone. I support the idea of 1, that load times should be at worst comparable to the current editor, but I'm not sure that in practice this is something that could be a certain result. As for 2, I'm fine with the current previewer (I assume there's a good reason for using it), provided it reaches parity with the old one and is consistent with the saved contents of the page. For the record I very much support the new text editor, and apart from the unintuitive copy/paste behaviour (being debated elsewhere I believe), will be happy to use it. Sam Walton (talk) 15:48, 17 January 2017 (UTC)[reply]
• Support both noting that 2 is particularly egregious. Also comment that I do not want the current wikitext editor to be dropped for a very long time. BethNaught (talk) 15:51, 17 January 2017 (UTC)[reply]
• Support both Having a resource heavy GUI as the only option would prevent a lot of contributions from editors who don't have the hardware or bandwidth to handle it, which defeats the object of wikimedia encouraging grassroots participation. Not everywhere is wikisilicon valley. In addition inaccurate rendering of previews can cause countless problems, direct and indirect.Cesdeva (talk) 22:41, 17 January 2017 (UTC)[reply]
• Oppose I've been using the new source editor since the beta was announced and haven't run into anything like the load times you describe. I'm also not sure the "preview" issue is nearly as serious as you present it; many of the cases in which the preview is substantively inaccurate are pathological in the first place (i.e. you shouldn't be doing whatever it is that's causing the renderer to barf). There are definitely some irritating usability issues, but neither of the items on your list seems worth throwing a wrench in the works over. Opabinia regalis (talk) 23:25, 17 January 2017 (UTC)[reply]
• Support both. I have a decent computer, but don't have broadband, and decided to try both of the examples given above. United States: in the current editor took 4 seconds before I could start typing, and 6 seconds before the full page loaded; in the new Visual Editor text mode, it took 35 seconds! Then List of named minor planets (numerical): in the current text mode it took me 8 seconds before I could start typing, and 14 seconds for the entire page to load; in the new editor, it took 90 seconds before timing out, then timed out again at 120 seconds, and took about 122 seconds in total to load. As pointed out above, these figures are just anecdotal, but now that the issue has been raised, please provide reliable stats on a range of modern and old devices, at various internet speeds and in various countries – we don't want to become "Wikipedia, the encyclopedia that anyone with a fast enough connection can edit"! I'm genuinely pleased for people who enjoy using the Visual Editor, and wouldn't want to take it away from them, but likewise please at least provide an option that will allow me and others in a similar position to keep editing. ‑‑Yodin^T 00:29, 18 January 2017 (UTC)[reply]
  • The best answer to the problem with List of named minor planets (numerical) is that 1.12MB is just too big for one article. I hope the people responsible for the 26 views per day via mobile aren't actually using their mobile data for that. Opabinia regalis (talk) 01:28, 18 January 2017 (UTC)[reply]
  • Speed varies considerably per account, browser, device, and location. For example, it took me just six seconds in Safari 10 and nine seconds in Firefox 50 to open United States in the wikitext mode of VisualEditor – much less than the time it took your computer. In Safari, VisualEditor's wikitext mode is slightly faster than reading the page; in Firefox, loading the page in read mode is one second faster than opening it to edit.
    The team has a standardized system for testing this. In general, the results are that short pages take faster than long pages; that VisualEditor is faster in Europe and Africa than in North America; that any method of editing wikitext is faster than anything that shows a lot of images (e.g., reading a page); that newer computers are faster than older computers; and that IPs and new editors have faster load times than experienced editors (who tend to have a lot of performance-harming scripts in their accounts). For a reasonable sample of pages (i.e., not just the longest ones), when editing as an IP (e.g., with no scripts or gadgets), with nothing else running (e.g., no other scripts running or tabs refreshing in the background), in a highly standardized setting, the time-to-open speeds are approximately the same for VisualEditor's built-in wikitext mode vs the 2010 wikitext editor.
    And then you impose all of the real-world, non-standardized conditions that affect each of us, and the answer becomes: Who knows? Your experience is your real experience, and whether your experience is fast or slow, it's not safe to assume that the next editor will have the same experience. Whatamidoing (WMF) (talk) 19:33, 19 January 2017 (UTC)[reply]
• Oppose (edit conflict) both procedurally and on the merits. Firstly, the technical guide is still a draft, it's not a guideline like the proposer states. I think it's far too premature to start implementing things from it. Secondly, the draft says that "Development teams participate in the discussion focusing on the proposed blockers (whether they are sensible, consistent with the project, actionable, realistic…)" so I am hesitant to make any decisions until the proposer shows they've discussed this with the devs or until the devs actually participate in this discussion. Thirdly, the purspose of "actionable blockers" is that they be actionable, they, in my mind, need to have clearly defined criteria for when they have successfully been actioned. Neither the proposal nor the draft technical guide adequately lay out how it is determined that an actionable blocker has been overcome. The draft says: "If the development team solves the blockers, the community will be asked for a new review. If no surprises are found, the deployment will proceed." What constitutes "surprises"? What is the threshhold for these proposed actionable blockers? Load times are highly variable, how will we determine an adequate level of load time? What if we just happen to have a discussion full of people contributing via Windows 95 who oppose the re-review? More likely, what if we just keep inflating our standards saying it's not fast enough or the preview isn't good enough in order to filibuster implementation? Wugapodes [t^hɔk] [ˈkan.ˌʧɻɪbz] 01:37, 18 January 2017 (UTC)[reply]
• Support both. Both have long been known as serious VE problems, to introduce these (and other VE problems) into normal editing would be a very bad idea.
  Fram (talk) 10:00, 18 January 2017 (UTC)[reply
  ]
• Oppose. I use primarily use the Visual Editor for content work and find the Parsoid preview adequate 99% of the time. In the few instances where it's troublesome (e.g. not seeing references), there's a very easy workaround: save the page. Excessive load times are a concern, but the proposed "blocker" is too vaguely worded to achieve anything. It seems to me that submitting a phabricator ticket asking for it to be profiled and reduced would suffice (if one doesn't already exist). – Joe (talk) 10:12, 18 January 2017 (UTC)[reply]
  • A. It seems a bit rude for someone not affected by this change (since you are a VE user) to oppose those who are affected by this change. B. "Saving" is no workaround for previewing, previewing is also meant for testing, but the mainspace is no place to test things. Of course, one can copy a page to a sandbox, comment out the categories, and then start testing, but this is no longer an "easy workaround" but a lot of haasle. C. Excessive load times of VE have been noted from the very start of VE, and numerous times since then[2], but have four (five, whatever) years later not been corrected. Yet another phabricator ticket won't solve this. (the "redlinks should be red" issue has been a ticket for more than a month now[3], no activity as far as I can see; other issues also are already phab tickets). Note that the new editor also seems to break some well-used gadgets and tools like Twinkle, apparently (I haven't tested this).
    Fram (talk) 11:00, 18 January 2017 (UTC)[reply
    ]
    • Fram, the new editor is an entirely new system. Gadgets and scripts will need to be rebuilt from scratch. That adds a one-time cost to switching, but I think it's fair to primarily focus on long-term pros and cons. (Although I'm not really seeing a long-term pro to the new editor.) Alsee (talk) 22:32, 18 January 2017 (UTC)[reply
      ]
    • @
      Fram: I said primarily; I also use the wikitext editor so I'm as "affected" as anyone else. After seeing this I opted into the NWE beta and haven't experienced any appreciable slowness, making me think that this, like the very few edge cases where Parsoid previews aren't sufficient, isn't a hugely critical issue. We can't keep obstructing the WMF's efforts at improving our antiquated interface because the new versions have a few bugs. All new software has bugs. – Joe (talk) 09:23, 19 January 2017 (UTC)[reply
      ]
• Support both, On point one, as a regular editor from developing countries the last thing I need is even slower download times. On point two, I'm mystified at the idea of a preview function that doesn't render the page as it would if you saved it. -- Euryalus (talk) 11:14, 18 January 2017 (UTC)[reply]
• Support both. Slower loading times are an issue for developing countries and mobile users who don't like the mobile interface (I know I'm not the only one). But having a preview that doesn't render the page exactly like it appears when saved (even if it is just a missing sidebar) is daft. As Alsee said, if it ain't broke, don't break it. There's no reason to eliminate the plain text editor; far from simplifying things, the proposal to ultimately eliminate it is a switch to a more resource hungry process for no real benefit. oknazevad (talk) 23:00, 18 January 2017 (UTC)[reply]
• Support both The optimism that allows programmers to ply their trade often leads them down strange paths, but none stranger than thinking these features should be imposed on everyone, with performance details on the todo list. Just save your edits for a true preview! That must be what was behind the fuss a couple of months back when someone dropped into
  WP:VPT to tell template/module writers they should not show extra error messages during preview. Johnuniq (talk) 23:04, 18 January 2017 (UTC)[reply
  ]
• Support both per every single support listed here. I tried the new editor and did not enjoy it. If they do go ahead and bring the new wikitext editor out of beta, they must keep the old editor. — Gestrid (talk) 05:46, 19 January 2017 (UTC)[reply]
• Support both These sound like serious issues that need to be addressed. Change always makes me a bit uncomfortable, especially when there are problems. Also Support keeping old editor, as I think many editors would consider leaving if it was taken away, and we already have editor retention problems. Tamwin (talk) 05:50, 19 January 2017 (UTC)[reply]
• Support both per Euryalus. Ealdgyth - Talk 15:36, 19 January 2017 (UTC)[reply]
• Support both Don't fix what isn't broken: current editor working perfectly on my end.
  Spartan 123 18:43, 19 January 2017 (UTC)[reply
  ]
• Support both. Just tried it, clearly noticeable speed difference and the "preview" is unacceptable. Echoing BethNaught in that I do not want to see the current source editor (which is actually functional) to be removed. In what ways is the new source editor superior, other than "easy switching" (which is negated by the long load times of VE to start with) and the toolbar (whether that is even superior to the current setup is debatable)? This is a sham referendum, not that I expect any better from the WMF. feminist 09:38, 31 January 2017 (UTC)[reply]
• Support both. And under no circumstances should the existing source editor be removed. Peter coxhead (talk) 09:53, 31 January 2017 (UTC)[reply]
• Support both. Offer it as an option, but don't try to impose it on everyone, especially not with increased load times and preview that doesn't preview. SarahSV ^(talk) 15:58, 31 January 2017 (UTC)[reply]
• Support both and do not remove the existing editor. ThePlatypusofDoom (talk) 18:20, 31 January 2017 (UTC)[reply]
• Support both I support anything that obstructs WMF. Chris Troutman (talk) 20:19, 31 January 2017 (UTC)[reply]
• Support both per above. The current wikitext editor is not broken. -FASTILY 22:16, 31 January 2017 (UTC)[reply]
• Support both for all the reasons given, plus.
  • Previews are necessary: Opabinia regalis said

    I'm also not sure the "preview" issue is nearly as serious as you present it; many of the cases in which the preview is substantively inaccurate are pathological in the first place (i.e. you shouldn't be doing whatever it is that's causing the renderer to barf).

    I don't know what you use previews for, O. regalis, but a large part of their value for me is spotting errors of execution as well as errors of intention. For example, last night on my mobile I added a rather complex "cite" ref, incorporating a template call as the last item. When I tapped Next for the preview, I got an "unclosed reference" error (or whatever the wording is). It turned out that in the steps of constructing the ref, which involves a good bit more moving around on a smartphone than on a computer, instead of inserting the double double curly closing braces at the end (}}}}) I'd lost track and only inserted one pair (}}), and as a result the "</ref>" and everything after it got swallowed up as part of the citation. This is not "doing something pathological that caused the renderer to barf" in the apparently snarky way you used it. This is called "checking your work", and we all should be doing it regularly.

  • Loading time. If you think it's slow on a computer, be glad you're not using a mobile. I get fairly frequent browser crashes, and I'm sure some of them are due to timeouts.

  --Thnidu (talk) 00:10, 2 February 2017 (UTC)[reply]

• Support both. If WMF really does adopt the concept of project-by-project blockers, I would welcome that improvement. Here, I think both issues are meaningful, and I see no reason to implement anything that has significant problems. Most of us are here to edit an encyclopedia, not to beta-test software that does not even address the issues that we care about. --Tryptofish (talk) 00:03, 3 February 2017 (UTC)[reply]
• Support both – It is supposed to be an upgrade, not a downgrade. And what is going to happen to WikEd? The Transhumanist 19:53, 6 February 2017 (UTC)[reply]
• Support load time as a blocker. I can live with the bad previews, but the slow load times will actually limit my editing activity. I frequently edit from countries where internet access is quite slow and having to wait more than a minute to edit a page isn't workable for me. I'm sure other people with slow internet access feel similarly. Kaldari (talk) 01:57, 12 February 2017 (UTC)[reply]

• Strong oppose, we should keep ONE editing mode and ONE reading mode. On other Wikipedias have I noticed that it's possible to wright directly in to the text. This

1. causes confusion
2. the "direkt wrighting" will attract pure vandals
3. there is no obvious benefit, with a new way of editing Wikipedia

Boeing720 (talk) 02:21, 14 February 2017 (UTC)[reply]

Note: Boeing720 explained[4] that they were attempting to oppose VisualEditor on EnWiki. Visual Editor is already here. This proposal is about a change to the wikicode editor. Boeing720, you may want to strike or revise your !vote here. Alsee (talk) 09:52, 21 February 2017 (UTC)[reply]

Alsee is 100% correct, like anyone who reads my explanation will understand. I made a huge mistake by turning the proposal. I Strongly support both. Sorry for the confusion I may have caused. Boeing720 (talk) 10:11, 21 February 2017 (UTC)[reply]

• Strongest possible support on the load time. Long load times make editing a chore, so quick fixes of simple errors are likely to be left alone. Editing in general will be discouraged. Support on the rendering. VisEd still can't render links properly? After all this time, that is totally sad. SpinningSpark 19:42, 18 February 2017 (UTC)[reply]
• Support on load times. I have just come back from the Phillipines. It was nearly impossible to edit even with the faster load times of the wikitext editor. If the only option becomes an even longer load times less of the world is going to be able to contribute. Also there is no "color coding". The color coding of WikEd is essential. The cite tool still adds unneeded urls when the pmid is give (this too needs fixing) Doc James (talk · contribs · email) 16:12, 20 February 2017 (UTC)[reply]
• The New Visual Editor =should replace the old Visual Editor, not the old wikicode editor. --NaBUru38 (talk) 13:04, 19 March 2017 (UTC)[reply]

Discussion

• Does anyone else think the current pasting behavior is weird, too? Whenever I copy a part of a page title and paste it, I want to get the text that I copied, not some empty bulleted lists and other wikitext cruft. Enterprisey (talk!) 03:03, 17 January 2017 (UTC)[reply]

  There's at least one currently open task for that. --Izno (talk) 13:50, 17 January 2017 (UTC)[reply]

  Enterprisey, the WMF is aware of the copy-paste issue. They'll address it. The ability to paste something like a fully formatted table could be really nice in some rare cases, but plaintext is what we want in nearly 100% of cases. Right now they are leaning towards the idea that a single line copy would be plaintext paste, and a multi-line copy would be markup-code paste. (I think that's probably the wrong fix, but I didn't comment on that.) Another idea is that ctrl-V would always paste plaintext, and ctrl-shift-V would always paste markup-code. (That's probably the better fix, but it would be hard to discover that ctrl-shift-V even exists.) The WMF will happily give us whatever we want. Alsee (talk) 14:52, 17 January 2017 (UTC)[reply]

  • Noo! @Alsee:, where did you see that conversation? That would be a terrible idea, having the worst of two worlds. Diego (talk) 16:24, 30 January 2017 (UTC)[reply]

• Once again, Alsee, you refer to a "large assortment" of rendering failures in the Parsoid previews, without providing a link or reference to help editors understand what you are talking about. With the exception of the fact that red links do not appear red (an obviously severe flaw that needs to be fixed), it seems to me that most of the issues that you are referring to are in fact obscure and rarely encountered. It would be helpful if you could link to or provide some examples of wikitext that does not preview as you expect. That way, editors can judge for themselves whether the problem is indeed as serious as you make it out to be. — This, that and the other (talk) 14:02, 17 January 2017 (UTC)[reply]

  This, that, I considered putting various examples in the RFC, but (1) I didn't want to bloat it up with a huge list, (2) the list that *I* happen to have compiled is an clearly an insignificant fraction of the issues that exist, and (3) I think the fundamental issue is broken previews, even if some of the cases are rare. I said in the RFC that the WMF is hoping to fix the common issues, and is aiming for 99+% accurate previews. If you think the exact list is important, then perhaps the WMF should compile a list. I'll happily contribute my pile of examples. Table of contents is missing. Redlinks, black links, external links, PDF links all show as plain blue links. Some links in the preview point to the wrong place... clicking them or opening-in-new-tab takes you to the wrong page. Markup on a link can completely break the link. Images can display in a completely wrong section (I haven't investigated why). Audio and video aren't included in the preview at all (they are replaced by a speaker-image). Oddly placed comments can break the preview. Some things that should be on one line are split onto multiple lines. Some elements - even entire paragraphs - can display in the wrong order. REFs can be missing from the reflist. I have multiple cases where it fails to render section-titles. Templating a template-name is is broken. Definition lists can render wrong. Some uses of elements like <code> <tt> and <s> can completely trash the preview. It can badly mangle table structure. Cases where stuff like <sub> doesn't get applied. Markup like #if can badly break if Parsiod doesn't like how it's arranged. And more. Some issues are related to Tidy, and the WMF is planning to remove Tidy, but so long as Tidy is part of the article view then Tidy must be part of the preview. And again, I'm sure the WMF can come up with far more examples than I have. And I'm sure that new examples will keep popping up. So let's consider the issue here as fix the endless render bugs that no one has listed yet, anywhere. In which case any particular list is irrelevant. Alsee (talk) 15:32, 17 January 2017 (UTC)[reply]

• I would also add that I forgot to switch off the VE before editing the above section... and for some reason was given the entire html of the page instead of the wikitext of just the section, <!DOCTYPE html><html prefix="dc: http://purl.org/dc/terms/ and all. I didn't dare click preview... ‑‑Yodin^T 00:34, 18 January 2017 (UTC)[reply]

  It's a problem I've been experiencing since the last software deploy. I believe that Parsoid is showing us the internals of the page (incorrectly). I would guess there's a phabricator task for this problem at this time but I haven't gone looking (nor have I reported one). It is well you did not save; I find that

  bypassing your cache fixes the problem. --Izno (talk) 01:10, 18 January 2017 (UTC)[reply

  ]

  @Yodin: And I didn't see another task in Phabricator, so I've added one; tracked at phab:T155632. --Izno (talk) 15:26, 18 January 2017 (UTC)[reply]

• I tried the beta for this just now. I noticed the formatting issue when pasting text. That wasn't too bad but there was a major hiccup when I was using it to post an entry in a big RfC. There was an edit conflict and I chose the option to handle this manually. The resulting edit took an 86K bite out of the discussion. That was quite alarming so I reverted my edit immediately. I have stopped using the beta now as it's taking me too far out of my comfort zone when I want to get things done. Andrew D. (talk) 14:05, 18 January 2017 (UTC)[reply]

  @Andrew Davidson: This is tracked at phab:T154217. --Izno (talk) 15:14, 18 January 2017 (UTC)[reply]

• The Technical Collaboration Guideline is a document of guidance in communications that is in mid-draft and has nothing to do with this. It does not call for actionable blockers as framed here. Remove its mention, please. Keegan (WMF) (talk) 07:41, 19 January 2017 (UTC)[reply]

• Specifically, the very first line says "This is a recommendation for software projects following the Technical Collaboration Guideline (TCG)". No project is following the TCG since the thing is still being written. More importantly, the guideline is not a guideline in the sense of the word that the English Wikipedia knows, a form of directive. It's help, that's all. To the point: you can't put something under rules it doesn't qualify for, and that aren't rules to begin with. Remove its mention in the proposal. Keegan (WMF) (talk) 07:49, 19 January 2017 (UTC)[reply]

• Then consider this a Beta test of the TCG. A bit like we get from the WMF all kinds of software that is in mid-draft but which gets rolled out anyway...
  Fram (talk) 10:03, 19 January 2017 (UTC)[reply
  ]

• No. Keegan (WMF) (talk) 18:26, 19 January 2017 (UTC)[reply]

Keegan (WMF), I have added a clarification on this issue. I hope you find it constructive and satisfactory. Alsee (talk) 20:29, 19 January 2017 (UTC)[reply]

I think the entire mention could have been taken out and the intent of the request is clear - I still think that's the better way to go, but meh. What I do not want is to see this as any sort of test or use of the TCG aside from "as an example." If that is your intent, that's fine. I'm working on building collaborative frameworks for the future years, and great harm can come from using them before everyone agrees and we're all ready. I hope you can appreciate that perspective. Keegan (WMF) (talk) 21:02, 19 January 2017 (UTC)[reply]

• This seems like a pretty pointless discussion, from a developer's perspective. Not sure what it is trying to accomplish. This feature is not being released yet, the feature is not bothering any of the people who are voting here, the previews will be aligned at some point in the next 1-2 years (mostly because maintaining 2 parsers is gonna be problematic), there is no plan to remove the current editor. If someone wants to be useful and constructive however, they could assist in some prototyping work, testing, design feedback etc etc. instead of nurturing your inner Statler and Waldorf. —TheDJ (talk • contribs) 01:49, 20 January 2017 (UTC)[reply]
  • "probably in mid-2017, we'll begin to provide it by default in place of the current wikitext editor"[5] If the WMF plans to roll out a new default editor in mid-2017, then early 2017 seems like the perfect time to discuss whether this really is fit to be the default editor, and which things surely need correcting before this can happen. The result of making this the default editor would be that new editors would encounter three editing environments instead of two (luckily we don't have Flow), as it has been shown here that there are circumstances where you always get the old wikitext editor, even if the new one would be the default. Sending out the message to the WMF that this is not acceptable is best done in time and not at the last minute (or even worse but rather typical, the WMF implements this, then a consensus emerges that we don't want it, the WMF refuses to roll it back because that would be too complicated or "confusing for new editors" or some similar excuse, and only after a long and bitter dispute does the WMF relent). This is a Beta, no one is arguing to end the availability as beta feature, but the stated plans by the WMF to roll out this out as the default in a few months time are simply premature. To dismiss this as "unconstructive" and "nurturing your inner grumpy old men" and adding the rather disingenious "this feature is not being released yet" (no, but it would be very stupid to wait with this discussion until it is released, wouldn't it?) is typical "shut up" behaviour of WMF supporters and not helpful, constructive, or open-minded at all. You could instead take the comments made in this very discussion as "testing and design feedback" and be happy that people care and voice their opinions.
    Fram (talk) 08:29, 20 January 2017 (UTC)[reply
    ]
  • This is design feedback. An editor with broken previews and atrocious load times is clearly inferior to what we have, and should not be deployed unless the issues are resolved. Your suggestion that no issues should be addressed until deploy phase is silly. A primary reason the WMF has been developing the Collaboration guideline is to avoid having these sorts of issues (and RFCs) pop up at the last minute, during deploy. The best time to address issues is as early as possible, preferably during concept and design phase. Unfortunately there was no project page or information available until after it was built. Alsee (talk) 13:11, 30 January 2017 (UTC)[reply]
• Comment - (sigh) I don't understand why there always seems to be so much effort going on in this project to create alternatives to things that already work fine. I hope this isn't where the money goes that is donated to Wikipedia, which I'm sure that the donators assume is used for maintaining servers and organizing the development of the encyclopedia. That said, load times of software under development are often high, because of bloat left in for testing purposes and emphasis on functionality over speed in early phases. We can only hope that sincere efforts at optimization take place before the deployment.—Anne Delong (talk) 12:40, 7 February 2017 (UTC)[reply]

Third blocker: undo no longer works?

• Apparently from every page, if I am at "View History" (instead of "read") and then press "edit", I get the old editor instead of the new one. Apparently a page must be completely loaded in read mode before the new wikitext editor can be used. This would also mean that something like UNDO would no longer work when the new wikitext editor would be the only available editor. This seems to me to be a major blocker as well. Can others reproduce this and confirm this technically?
  Fram (talk) 11:18, 18 January 2017 (UTC)[reply
  ]

  You're mischaracterizing the WMF's plans re the new editor, so far as I'm aware. It is not that there will be no other way to do it, but that the wikitext editor which will be available when e.g. Javascript fails to load will be a simple and plain text field (rather than include the editor bar and other such items). That said, I have reproduced that error multiple times, though no discrete steps for it (I think it's just clicking the 'undo' button, but I could be wrong). --Izno (talk) 13:04, 18 January 2017 (UTC)[reply]

  As long as the old wikitext editor remains, undo should keep on working, if they start it by default anytime the new editor fails (instead of e.g. only allowing it for people who have turned off the new editor explicitly). What their promises to keep the wikitext editor around are worth is anyone's guess of course. And obviously that "read - edit" gives a different result than "view history - edit" is perhaps not a technical blocker, but is it indicative of the total lack of adequate testing at the WMF, the thing that already sinked so many of their pet projects. The things that get discussed here are not exceptional occurrences or edge cases, these are basic functionality and actions.

  Fram (talk) 13:49, 18 January 2017 (UTC)[reply

  ]

  I agree that undo is a regression--and I think their intent to keep a basic text box form is pretty sound because we do need to provide some support for Javascript-less users. --Izno (talk) 15:08, 18 January 2017 (UTC)[reply]

  Having activated and desactivated the new wikitext editor beta a few times, I now have all kinds of problems. At the moment, the beta (new editor) is activated: on most articles, I only get the old editor, and on some pages (e.g.

  Fram (talk) 14:28, 18 January 2017 (UTC)[reply

  ]

  That sounds more like your cache is wonky. You should consider clearing it. --Izno (talk) 15:08, 18 January 2017 (UTC)[reply]

  Fram, I've also had issues where it seems random which editor starts up, and where turning the new editor on or off in preferences doesn't seem to take effect, among other problems. Bypassing local cache with shift-reload does not fix the issue. If it's a cache issue, it seems to be the server cache. I've also had cases preview fail to work at all, returning server errors. I suspect it's related to Parsoid, as I was trying to preview an article which the WMF had listed as generating a Parsoid roundtrip semantic error in their automated testing. Alsee (talk) 23:21, 18 January 2017 (UTC) On second thought, it might have been an article that generated Parsoid timeout in the automated testing. Alsee (talk) 23:45, 18 January 2017 (UTC)[reply

  ]

  @Alsee: Yes, there's a handful of tasks documenting issues related to the 'wrong editor' in Phabricator. With Fram however "activating and deactivating a few times", that's not going to go well, I should think, and I'm pretty sure I've seen advice regarding other "Beta"-tab projects to the effect of "try to avoid turning things off and on multiple times". --Izno (talk) 23:54, 18 January 2017 (UTC)[reply]

My biggest failure mode with VE is undo failing. If there is any cut & paste in my undo buffer, trying to undo that step often fails in an odd way, and I have to reconstruct my edits piecemeal. If that's what Fram is talking about, and it would apply to NWE editing, that seems like a major issue to me as well. Not as big a blocker as performance, but significant for complex edits. – SJ + 22:28, 19 March 2017 (UTC)[reply]

There is no plan to remove the old wikitext editor

I have seen comments now on multiple pages that say something like, "eventually the current wikitext editor would be removed completely" – with the implication that this is definitely planned and will happen soon.

If we use a typical definition of "plan" like a "list of steps with timing and resources, used to achieve an objective" (to quote the article), then there is no plan to remove any of the wikitext editors from any WMF site. It would be far more accurate to say that the Editing department (and anyone who's been around computing for more than a few years) has a reasonable expectation that none of the current software will be used a hundred years from now, or even a few decades from now. So, sure, it's technically true that "eventually the current wikitext editor would be removed completely": someday, it presumably will be. However, it's also technically true that "eventually" I'm going to die (as will all of us) – and AFAICT it's still an open question as to which of those events will happen first.

On the other hand, I believe that we are all going to outlive the old parsing system, which is what the second proposed blocker concerns. They are planning to remove the old (HTML4-based) parser and to use (HTML5-based) Parsoid for saving all pages, no matter which of the many editing tools you're using. This epic project will certainly not be finished during 2017, but when it is finally completed, the odd differences between the two parsers will simply disappear. (One example: should [<!-- Invisible -->[Text]] produce a normal wikilink or should it display all the characters on the page or should it display the brackets but not the invisible HTML comment?) 

If you are interested in this project, then I recommend that you join WP:WikiProject Check Wikipedia. The first major step in replacing the old parsing system is described at mw:Parsing/Replacing Tidy; basically, some typos in HTML codes (e.g., someone typing </br> rather than the correct <br>) will no longer be silently fixed. (NB: This initial set of disruptive changes would have to happen even if Parsoid didn't exist; the library is unmaintained and outdated.) Whatamidoing (WMF) (talk) 07:25, 19 January 2017 (UTC)[reply]

@Whatamidoing (WMF): When you say that Parsoid will be used to save all pages, do you mean that pages will be saved in Wikitext but rendered with Parsoid, or saved in Parsoid HTML and round-tripped to Wikitext for source editing? I hope the former, as the latter will inevitably cause dirty diffs, and if made retroactive will change historical Wikitext revisions. BethNaught (talk) 09:00, 19 January 2017 (UTC)[reply]

I mean that what we've called "the parser" for years (Parser.php and a string of other supporting pieces in that system) will be completely removed – gone, not used, completely unavailable, deleted from the servers, given a death certificate that lists bitrot as the primary cause of death, etc. If you use (for example) the oldest, Javascript-free wikitext editor to save a change today, the resulting wikitext revision is currently turned into HTML by the old parser so that a reader can read it. When (2018? 2020?) the switch to Parsoid-based rendering is completed, even if you use exactly the same editor, the resulting revision will be turned into HTML by Parsoid instead. This change should have no practical effect on most Wikipedians, although I suppose that people may someday wonder why "obvious typos" like </br> were overlooked in articles for years. The change will be retroactive in the specific sense that it will no longer be possible to use the old parsing system to render any pages, so if you go look at a revision from 2003, then you will see how Parsoid turns it into HTML5, rather than how the old parser turned it into HTML4. (This is not very different from what we have now, since "the old parser" has changed quite a lot during its existence, and there's currently no way for you to see the 2003 revision with the 2003 parser, either.)

Whether revisions should be saved in wikitext alone or simultaneously saved in both wikitext and HTML+RDFa was an open question the last time I heard anyone mention it, but not one that affects the editing experience. (The idea seemed to be that dual-format saving would increase disk use but might be faster to read.) A few years ago, the devs discussed someday saving pages in

HTML+RDFa alone and then turning them back into wikitext whenever someone wanted to edit, but interest in that option was limited. Maybe it's something they should consider again in future decades, but I don't expect it to happen in the foreseeable future. Whatamidoing (WMF) (talk) 17:13, 19 January 2017 (UTC)[reply

]

@Whatamidoing (WMF): If we switch both editors to use Parsoid, issue #2 will be moot (as you explained above), but it isn't clear to me that that is actually going to happen. Can you provide any clarification on that issue? i.e. is the Editing Team planning on switching the old Wikitext editor to use Parsoid? Personally, I haven't heard of any such plans. On issue #1, my understanding is that there is little possibility of further improving the load time of the new WikiText editor due to its architecture (since it has to load most of the VisualEditor code in order to function). Is that also your understanding? Has the Editing Team considered re-architecting it to address the load time concerns or is that not a realistic option? Kaldari (talk) 02:23, 12 February 2017 (UTC)[reply]

Hi, Kaldari: Replacing the old parser with a modern one (i.e., some modern one/not necessarily Parsoid) has been expected for some time (software is not eternal, bitrot is real, etc.), but I believe that the decision to replace it with Parsoid (i.e., a modern replacement that happens to be Parsoid) was officially taken last quarter. (That decision belongs to ArchCom and Parsing, not to the VisualEditor team.) There is some information on the plans at on mediawiki.org; IMO the more interesting and informative page is the one about the two-systems problem itself.

The VisualEditor team is not currently working on performance issues. It's being considered for the coming year, but I don't know what they'll decide yet. There are some resource constraints that make it a difficult choice (e.g., inability to instantly clone certain members of Ops.  ;-) Whatamidoing (WMF) (talk) 18:40, 20 February 2017 (UTC)[reply]

Even if maintaining our "old" editor, have I experienced troubles at other Wikis, which uses more than one. All developments are not necessary good ones Boeing720 (talk) 00:52, 24 February 2017 (UTC)[reply]

A dozen different

WP:WikEd). Whatamidoing (WMF) (talk) 21:44, 2 March 2017 (UTC)[reply

]

Moved from

WP:VPT

Magic links are being removed per the outcome of a Mediawiki RFC. What should we replace them with?

• Nothing
• Links ([[Special:BookSources/$1|$1]])
• Templates ({{ISBN|$1}})
• Parser functions ({{#ISBN:$1}}) [Requires Mediawiki changes]
• Interwiki links ([[ISBN:$1|$1]]) [Requires Mediawiki changes]

21:49, 5 February 2017 (UTC)

Um the widely unadvertised RFC. All the best: Rich Farmbrough, 23:54, 13 February 2017 (UTC).[reply]

Background

In the RfC meeting for the Future of magic links RfC, it was agreed upon to disable magic links for the MW 1.28 release by default and begin the deprecation for Wikimedia sites. MW 1.28 was released 2016-11-28. I proposed a bot to replace the magic link to templates. See: Wikipedia:Bots/Requests for approval/Yobot 27 -- Magioladitis (talk) 09:10, 3 February 2017 (UTC)[reply]

What meeting? All the best: Rich Farmbrough, 23:55, 13 February 2017 (UTC).[reply]

phab:E287. Anomie⚔ 13:53, 14 February 2017 (UTC)[reply]

@Xaosflux: to comment. -- Magioladitis (talk) 15:22, 3 February 2017 (UTC)[reply]

I'm not seeing where the English Wikipedia had this "RfC meeting for the Future of magic links RfC" please provide a link to the RfC closure here, if there was not a community discussion here then spin one up. — xaosflux ^Talk 15:35, 3 February 2017 (UTC)[reply]

@Xaosflux: This is a Mediawiki issue. It will affect all Wikipedias. See mw:Talk:Requests_for_comment/Future_of_magic_links. -- Magioladitis (talk) 15:44, 3 February 2017 (UTC)[reply]

And for the record, Wikipedia:Village pump (technical)/Archive 151#Tech News: 2016-46 said:

• Magic links might not work in the future. [6]

The linked post links the RfC. PrimeHunter (talk) 16:59, 3 February 2017 (UTC)[reply]

@PrimeHunter: mw:Requests_for_comment/Future_of_magic_links#Problem links to the discussion to turn this off on the software, it does not show support for which (or even IF) local communities replace it with something else. — xaosflux ^Talk 17:06, 3 February 2017 (UTC)[reply]

Sure, I just pointed out we had been informed about the discussion to turn it off. mw:Requests for comment/Future of magic links links to phab:T145604 where the RfC meeting is mentioned. What local communities do (if anything) is something to be discussed locally. I assume Special:BookSources will still be there if we want to add a link to it. Wikipedia:Bots/Requests for approval/Yobot 27 was denied so this section is currently the only open discussion I know. If another exists or is opened then please post a link here. PrimeHunter (talk) 17:35, 3 February 2017 (UTC)[reply]

@MZMcBride: to comment on this. -- Magioladitis (talk) 15:49, 3 February 2017 (UTC)[reply]

I understand that if the magic link gets disabled it will just revert these to plan text. I'm also in general support that having these be linkable text is a good thing, and that mass conversions would need to be handled by a bot. What I'm not see is community support for which mechanism should the new enwiki standard for presenting ISBN values. It could be a template, or a parser function to be, or a combination - a pseudonamespace, etc. It could be one of thees, supported by another one a is traditional for a module in a template. I don't have any strong preference for which one to use - just that it has widespread support. — xaosflux ^Talk 15:51, 3 February 2017 (UTC)[reply]

I'd agree with this. Replacement of the magic links in general with something else is probably not something we get to decide on, what the "something else" is on the other hand... Jo-Jo Eumerus (talk, contributions) 16:18, 3 February 2017 (UTC)[reply]

Discussion on how / if to replace magic links

My vote is using a template. It's consistent with how we treat other citations already and it allows page-level tracking of usage. We now have Template:ISBN and it's been working fine in live articles. Assuming that MediaWiki will no longer support magic links, does anyone object to using templates for their replacement? --MZMcBride (talk) 21:43, 4 February 2017 (UTC)[reply]

I don't. -- Magioladitis (talk) 23:27, 4 February 2017 (UTC)[reply]

Agree with replacing with templates. Keith D (talk) 23:52, 4 February 2017 (UTC)[reply]

Ditto, for each magic link. Jo-Jo Eumerus (talk, contributions) 16:16, 5 February 2017 (UTC)[reply]

• Support Seems like a sensible idea, as Jo-Jo says, it should be the same for each of those magic links. Regards SoWhy 16:27, 5 February 2017 (UTC)[reply]
• Support. We should also have a bot convert all future instances to {{}} format. I really wish this discussion had been better advertised, entering these things on mobile phone is going to be a big added nuisance. Daß Wölf 16:30, 5 February 2017 (UTC)[reply]

  Coming back to this, I support the use of a template now that the deed has been done. However, I would be absolutely in favor of going back to using magic links if that's possible. Daß Wölf 02:25, 17 February 2017 (UTC)[reply]

• Support conversion to {{ISBN}} and {{PMID}}, which provide error-checking that magic links do not currently provide. RFCs might need semi-automated conversion; I have read comments that some editors write something like "RFC 1048" but do not want that to actually link to https://tools.ietf.org/html/rfc1048. – Jonesey95 (talk) 22:37, 5 February 2017 (UTC)[reply]
  • Currently, if editors don't want magic linking of RFC links, I would expect they would use <nowiki> tags to suppress the links (e.g. RFC 1048). As long as the bots doing the replacements don't replace any text inside nowiki tags, I imagine this would work.Harryboyles 04:35, 11 February 2017 (UTC)[reply]
• Support magic links are annoying, produce an unexpected result, and inconsistent with how we actually want them to be. Replace them with a template.
  books} 22:43, 5 February 2017 (UTC)[reply
  ]
• Support template for both ISBN/PMID. -- Magioladitis (talk) 23:19, 5 February 2017 (UTC)[reply]
• Support {{ISBN}} and {{PMID}} --S Philbrick(Talk) 18:27, 6 February 2017 (UTC)[reply]
• Support the use of the template, but request widespread explanation of it. Some editors never use any formats for inline citations or bibliography lists now (e.g., Jane Austen article), and now they will need to learn a template. If a bot makes the change for existing reliance on the "magic link", perhaps it should be in existence for more than a one time use. --Prairieplant (talk) 20:46, 6 February 2017 (UTC)[reply]
• Support use of {{ISBN}}, and a bot to go through and add the template to all existing ISBNs outside citation templates. PamD 22:45, 6 February 2017 (UTC)[reply]
• Support template solution as most intuitive and consistent. If a bot can switch all the bulbs, all the better. -- Elmidae (talk · contribs) 17:06, 7 February 2017 (UTC)[reply]
• Support templates. It's simple and consistent with almost everything else. The others are range from gross to vile. Alsee (talk) 22:13, 8 February 2017 (UTC)[reply]
• Comment: Should this discussion be linked from Template:Centralized discussion? The outcome of this discussion will affect at least 370,000 pages. – Jonesey95 (talk) 01:10, 10 February 2017 (UTC)[reply]
• Oppose at least for ISBN and ISSN. Why do we want to make Wikipedia harder to edit, instead of easier? All the best: Rich Farmbrough, 23:43, 13 February 2017 (UTC).[reply]
  
  • @Rich: This discussion is about how to replace magic links, not whether to replace magic links. Moreover, removing magic links at the MediaWiki level removes a headache in updating the wikitext parser(s), and therefore in updating VisualEditor and similar tools that ostensibly make it easier to edit Wikipedia. {{Nihiltres |talk |edits}} 16:27, 2 March 2017 (UTC)[reply]
    • Maybe, but that begs the question of whether we should. This has been proposed on an obscure page on an obscure wiki, and supported by an atypical collection of editors, from a point of view of information purism, and being unable to code what looks like some trivial internationalisation extensions. Purism is inappropriate for Wikipedia. The attitude that "we cannot make this work for Arabic, so we refuse to allow it for English" - is also indefensible. The money that the Foundation has poured into supporting internationalisation should enable this fairly trivial function to work in LtoR, RtoL and boustrophedon. All the best: Rich Farmbrough, 19:51, 2 March 2017 (UTC).[reply]
      
• Support templates for all the disappearing magic links. It's most consistent with what editors will expect from other contexts, such as {{Imdb}}. Definitely a job for a bot. Cabayi (talk) 09:24, 23 February 2017 (UTC)[reply]
• Support templates for everything currently handled by magic links, and by extension the creation of a bot to automatically wrap new instances of those non-magical links in an appropriate template. {{Nihiltres |talk |edits}} 16:27, 2 March 2017 (UTC)[reply]

File patrolling was technically introduced almost a year ago (phab:T11501). The backlog of unpatrolled files, visible at Special:NewFiles, is very significant. Autopatrolled users have their files automatically patrolled, but there are many users who are trusted to upload files that do not meet the requirements for autopatrol (which is concerned with new articles, not files). Thus I suggest we request a new usergroup, "File autopatrolled", with a single userrright (to be created): autopatrol-upload that autopatrols upload of the user. This way, we'll cut down a lot on the new files to patrol. Cenarium (talk) 18:36, 10 February 2017 (UTC)[reply]

• Support. Seems like a good idea. I don't think (article-)autopatrolled users should necessarily have their files autopatrolled either, since
  WP:PERM/A doesn't do anything to check that the editor is au fait with licensing policies etc. – Joe (talk) 15:52, 11 February 2017 (UTC)[reply
  ]

Indeed these are very separate areas, in fact one would need separate userrights for patrolling uploads too, which should probably be bundled with the file mover usergroup. Cenarium (talk) 17:29, 11 February 2017 (UTC)[reply]

I can see the benefit of this in principle but there may be a difficulty in assessing a user's uploading experience. Files uploaded here may be transferred to Commons (sometimes wrongly leading to deletion there). Also, files uploaded here with a NFUR or with copyright outside the US are transferred to Commons when they fall out of copyright. Can an admin see the files I uploaded which were transferred to Commons on 14 January 2017? For example File:Boating in St Kilda, J Norman Heathcote, 1900.jpg. Thincat (talk) 18:17, 11 February 2017 (UTC)[reply]

Yes, admins can see it - both the 2 image versions and all the versions of the text from the page. עוד מישהו Od Mishehu 18:28, 11 February 2017 (UTC)[reply]

Oh, well, in that case I am in favour, supposing the standard of approval is appropriate. (BTW I think the article autopatrolled criterion is too high I see the level has sensibly been reduced.). Thincat (talk) 18:32, 11 February 2017 (UTC)[reply]

• Support and remove file auto patrolled from the normal auto patrolled per Joe Roe. -- Iazyges Consermonor Opus meum 13:08, 13 February 2017 (UTC)[reply]
• Support - Nifty idea and potentially good in practice. Criteria to obtain this permission may be needed, nevertheless. I don't know what the standards should be, but the criteria would be related to copyright and fair use. I don't know how many people would meet the criteria; the number would be the same as that of template editors or as high as the number of PC reviewers. George Ho (talk) 06:24, 14 February 2017 (UTC)[reply]

@Cenarium: May I add this discussion to "Centralized discussion" list? George Ho (talk) 19:49, 14 February 2017 (UTC)[reply]

• Support - writing good articles and properly tagging uploaded images are two totally different skillsets and should not be bundled. — Train2104 (t • c) 06:08, 16 February 2017 (UTC)[reply]
• Support fully. ~ Rob₁₃^Talk 04:23, 20 February 2017 (UTC)[reply]
• Support: Helps reduce backlog of unpatrolled files. KGirlTrucker81 ^{huh? what I've been doing} 16:47, 24 February 2017 (UTC)[reply]
• Support - Image copyright is a little trickier than print copyright (even allowing for some of the excesses and dubious interpretations of some extremist patrollers), but it should be simple enough to separate the sheep from the goats with respect to file uploading so that the goats can be more carefully minded. Carrite (talk) 21:13, 24 February 2017 (UTC)[reply]
• Support Would make patrol status more meaningful. --AntiCompositeNumber (Leave a message) 23:09, 26 February 2017 (UTC)[reply]
• Support – No reason not to. J947 18:28, 27 February 2017 (UTC)[reply]
• Support, with the understanding that users will only get this right if they show an understanding in image patroll. עוד מישהו Od Mishehu 12:29, 5 March 2017 (UTC)[reply]
• Support splitting the current autopatrol right into autopatrol-upload and autopatrol-page (and having them separate permissions on enwiki). For other wikis which have just one autopatrolled group and want it to have the ability to do both, the two rights can just be added to it. If this comes up for a consensus check later I also support giving the autopatrol-upload right to file movers on the understanding that they are already experienced in this area. Callanecc (talk • contribs • logs) 06:02, 8 March 2017 (UTC)[reply]

 Not done--The proposal failed to gain consensus.Many editors have expressed a lack of any meaningful benefit/purpose ariving out of the change.Winged Blades ^Godric 06:42, 24 March 2017 (UTC)[reply]

Should the terms "edit history" and "revision history" be deprecated in favor of "page history"? ―Mandruss ☎ 22:37, 28 February 2017 (UTC)[reply]

If a Yes consensus is reached, occurrences of "edit history" and "revision history" would be replaced by "page history". This would begin with what are arguably the most visible occurrences, the links "revision history statistics" and "revision history search" on the page history page itself, and the "Revision history" in its heading. At Help:Page history, the sentence "A page history is sometimes called revision history or edit history." would change to "(The alternative terms 'revision history' and 'edit history' are deprecated.)" Other occurrences would be replaced as editors run across them, citing this consensus. ―Mandruss ☎ 22:37, 28 February 2017 (UTC)[reply]

Survey: Deprecate "edit history" and "revision history"

• Yes - I see absolutely no benefit to having multiple names for the same thing. Meanwhile, there is a downside in that new editors have to learn that the various names refer to the same thing. This is a good example of widepsread unjustifiable complexity that, collectively, serves as a barrier to entry. ―Mandruss ☎ 22:37, 28 February 2017 (UTC)[reply]
• request clarification Are we talking about changing links in policies and so forth or are we talking about what editors choose to call it, because those are two very different conversations.
  talk) 22:48, 28 February 2017 (UTC)[reply
  ]

  Request clarification of your request for clarification. If you're asking whether it's about changing existing or future occurrences within editor comments in talk spaces, the answer is no. Communication is improved when we agree on the names of things, but we don't go around changing editor comments from "edit comment" to "edit summary", "intro" to "lead" or "lede", and so on. Rather, it's about non-talk occurrences in the WP and Help spaces, etc., and infrastructure software such as the page history display. We can't make the horses drink, but we can lead them to the water. ―Mandruss ☎ 22:52, 28 February 2017 (UTC)[reply]

• Yes makes sense. -- Iazyges Consermonor Opus meum 01:43, 1 March 2017 (UTC)[reply]
• No, because the different terms are used in different contexts. When we're talking largely about the page itself, editors tend to say "page history". When we're talking about specific diffs, editors tend to say "edit history". When we're talking about specific revisions (but not necessarily which individual edit led to them), editors tend to say "revision history". The terms "page", "edit", and "revision" are distinct and editors have to learn them anyway. Any editor who struggles to understand what "page history", "edit history", and "revision history" means after knowing those three terms must not know what a "history" is, and that's something we're
  not going to be able to fix. This is a solution in search of a problem, and it actually has a small chance of causing harm. Removing the alternative terms that have different contexts from all documentation will just make discussions held in those different contexts more difficult to understand. ~ Rob₁₃^Talk 08:27, 1 March 2017 (UTC)[reply
  ]

Yes. As the OP poinyted out, we won't erase the terms from Help:Page history, and this will keep all current discussions consistant with the way major features of the software are refered to - this will make things easier for newcomers. Note that no automation should be used to fix anything here - each change needs to be reviewed by a human being (an admin inthe case of MediaWiki: namespace pages). עוד מישהו Od Mishehu 09:18, 1 March 2017 (UTC)[reply]

@Od Mishehu: "Current discussion" will be unaffected, just documentation pages. We obviously cannot ban editors from using the alternative phrases which are more descriptive in specific contexts. ~ Rob₁₃^Talk 09:20, 1 March 2017 (UTC)[reply]

Yes, but as we move towards the new terminology, the depricated ones will gradually fade out of use in discussions. We son;t ban editors from talking about the "Abuse Filter", yet I haven't seen anyone calling itby that name. עוד מישהו Od Mishehu 09:21, 1 March 2017 (UTC)[reply]

• No Outside technical and emergency contexts, there is no need for perfect consistency in language, especially in English. If I ask you for a pop from your ice chest, and you go and grab a soda from your fridge, we both know what I was asking for and effective communication happened. I see no evidence that effective communication is hampered by these terms. There isn't any real problem in referring to page history versus edit history versus revision history. They all refer to the record of past edits that revised the way a page displayed, and they all communicate effectively. We shouldn't try too hard to impose order on a usage area that will likely defy order. Eggishorn (talk) (contrib) 16:48, 1 March 2017 (UTC)[reply]
• No per there being no real reason to change. Not confusing and it doesn't hurt anything. Eggishorn also has a great explanation for why it doesn't matter. Just because it doesn't appear to hurt anything to change it doesn't mean we should do it. There should be a positive reason for the change, which I don't see here. TonyBallioni (talk) 14:37, 2 March 2017 (UTC)[reply]
• no. I too can see no reason for this, no benefit it will bring to the encyclopaedia, just a bunch of unnecessary edits and potentially a number of disputes as editors unaware or disagreeing with this proposal revert the changes.--JohnBlackburne^words_deeds 15:39, 2 March 2017 (UTC)[reply]
• No English has multiple different terms that mean essentially the same thing. Since the terms aren't confusing or misleading there's no real benefit to standardising on one, and trying to enforce a single term would only antagonise people. Hut 8.5 18:46, 2 March 2017 (UTC)[reply]

  There is no proposal to "enforce" anything. Also see today's further discussion in the following section. ―Mandruss ☎ 04:12, 3 March 2017 (UTC)[reply]

• No Per
  talk) 05:06, 3 March 2017 (UTC)[reply
  ]

  There is no proposal for a new rule. CREEP does not apply since the proposal is to replace two words, revision history or edit history, with a different two words, page history, in contexts referring to the tool described at

  WP:BLUDGEON, this will be my last attempt to get participants to expend a bit of effort to understand the relatively simple question presented in this RfC, as well as the rationale for support. ―Mandruss ☎ 05:10, 3 March 2017 (UTC)[reply

  ]

• No a waste of time RFC. The terms edit history and revision history are much more explanatory, esp. when it comes to external usage - by non-wikipedians. "Page history" is too vague. 103.6.159.75 (talk) 16:11, 16 March 2017 (UTC)[reply]

Discussion: Deprecate "edit history" and "revision history"

I don't want to vote yet, but I mean it sounds reasonable. Is there any any "against" argument? Herostratus (talk) 23:18, 28 February 2017 (UTC)[reply]

@Herostratus: Well, page history could refer to the history of things like deletion logs and such. I would value a single term for edit history/revision history, possibly just use one or the other? RileyBugz^{Yell at me} | _Edits 23:50, 28 February 2017 (UTC)[reply]

If I see significant support for a "choose the term or leave status quo" RfC, I will withdraw this and restart, pinging any prior participants. ―Mandruss ☎ 23:56, 28 February 2017 (UTC)[reply]

• My only concern would be if the use of edit history to refer to a users past edits accidentally get changed upon implementation, but that's unlikely to be a problem. -- Iazyges Consermonor Opus meum 01:43, 1 March 2017 (UTC)[reply]

  Right, none of this would be automated and I think human intelligence and BRD would prevent such a problem. ―Mandruss ☎ 01:46, 1 March 2017 (UTC)[reply]

I have generated a list of likely pages to look over for the term "revision history" - see here. The similar search for "edit history" has too many false positives to use this way. עוד מישהו Od Mishehu 09:24, 1 March 2017 (UTC)[reply]

A lot of the opposition is that there is no confusion. I fully understand that there is no confusion to us, after we have learned that they refer to the same thing. In my opinion experienced editors should put ourselves in the position of the newbie; this is about entry after all. Does anyone dispute that it does take longer to learn three synonyms than a single term? It doesn't take a lot longer, but combined with the numerous other such situations the learning curve is significantly longer than necessary. Does anyone not find it intuitively obvious that many newbies, especially those not coming from technical backgrounds, must be overwhelmed by the complexity of this environment?
The only way to address this is one nit at a time. The principle is that simpler is better, and the proper question is: What harm would be done by this small simplification?
The effort required to implement is miniscule; except for the trivial software changes (you don't have to do elaborate regression testing of a change to a few words on a generated page), I would do most of it myself. ―Mandruss ☎ 03:41, 3 March 2017 (UTC)[reply]

Counter-argument: Od Mishehu's comment above about "too many" false positives for a simple search on "edit history". In truth, it is not likely simple on a technical level, and certainly not simple on a behavioral level. Editors will continue to call and name these pages whatever they wish and banging them over the head with yet another stylistic preference is policy creep. Eggishorn (talk) (contrib) 04:00, 3 March 2017 (UTC)[reply]

(edit conflict) The question also shouldn't be What harm would be done by this small simplification? but Why should we do this? I haven't heard a good case for why we should do it. TonyBallioni (talk) 04:03, 3 March 2017 (UTC)[reply]

Changing the words used by Wikipedia is hardly banging anybody over any heads. I'm not proposing a warning template here. Hyperbole is not helpful to the debate or one's own thinking.
I think it's abundantly clear that editors would not be forced to use the "official" term any more than they are forced to use any other "official" terms. I merely assert that it makes sense to have one "official" term for each "thing". Some editors call the lead/lede the "intro", but does that mean we should rename Wikipedia:Manual of Style/Lead section to Wikipedia:Manual of Style/Lead or intro section? I think not. Does it mean we should call it lead/lede in some places and "intro" in others? I think not. Communication would be enhanced if everybody called it lead/lede, but we don't actively correct the editors who call it "intro". We simply hope that, at some point in their development as an editor, it will occur to them that Wikipedia calls it lead/lede and they will start calling it that instead. No head-banging.
I've made the best case I know how, but if I fail to convince a majority, I certainly know how to lose. I do ask that participants refrain from misconstruing the proposal, as that undermines any decision-making process. I've seen little evidence that closers take the time necessary to discount such !votes. ―Mandruss ☎ 04:09, 3 March 2017 (UTC)[reply]

Yes, yes. Disagree with your case, but wasn't trying to suggest you don't know how to lose. Sorry if the tone came off that way. Text being an imperfect means of communication :) TonyBallioni (talk) 04:12, 3 March 2017 (UTC)[reply]