Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Godsy (talk | contribs) at 05:57, 25 February 2017 (→Rename "File mover" usergroup to "File handler" and grant ability to patrol files (only): comment). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

New ideas and proposals are discussed here. Before submitting:


Renaming Category:WikiProject Infoboxes

I just want to alert people that there is currently a proposal at CFD for renaming Category:WikiProject Infoboxes to Category:Wikipedia infoboxes [1]. Personally, I have opposed this, as this is obviously a maintenance category. I don't understand the rationale behind the proposal. ---Steve Quinn (talk)

Proposal to submit blockers on replacing our wikitext editor

Tracked in Phabricator
Task T154843
Tracked in Phabricator
Task T154844

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 (TALKCONT) 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. ‑‑YodinT 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 [thɔ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) 09:32, 18 January 2017 (UTC). To be sure these are still problems, I switched on the new Wikitext mode again, and edited Leuchtenberg Gallery. Not only does it take too long (15 seconds!) before I can start editing, the preview doesn't give ma good idea of how the page will look eventually (e.g. by eliminating the left sidebar, increasing the width of the page). On a second try, I first did "review changes" and from that window "preview", with the result "Error loading data from server: Failed to connect." This happened three times in a row. I could still edit the page and review my changes, so connection wasn't really lost... On preview, I don't get to see redlinks. This is one of the essential elements of preview for me, as it allows the correction of bad links before saving. Opening Exposition des primitifs flamands à Bruges first returns the standard editor for some reason, a second try gives me the new wikitext editor, but only after 50 seconds, which is way too long. I added an image, asked for a preview, and again got "Error loading data from server: Failed to connect.". In standard editing mode (I at this point switched back, quite relieved that that option still existed) opening the page took a few seconds, previewing went without any problem and showed the page as it would look after saving, including redlinks and the like. 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. Psychotic 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]

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]
  • 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... ‑‑YodinT 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]
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. Sumathi Murthy) I can,'t edit at all. This page has now opened in the new editor though (I thought it only worked in mainspace and user space?). Further testing confirms that I now can edit pages in the Wikipedia space with the new editor, but not in main namespace. I think I can safely conclude that this thing is far from ready to become a non-beta feature, never mind the default wikitext editor. 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]
    Izno, 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]

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]
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:
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]
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]

RfC: LTA Knowledgebase

Background

Our Long-Term Abuse (LTA) pages are an extremely valuable repository for Wikipedians doing anti-vandalism work - they inform editors on how particular vandals edit, even when those edits may seem innocent when taken out of context, let them know what to look out for in certain areas of the encyclopedia, and contain suggestions on how to treat certain users; no editor can know about the behaviour of every regular vandal. The records are also used for tracking purposes, informing edit filters for example.

But these pages aren't without their drawbacks. Vandals are often drawn to this system, either by aiming to become an LTA as some kind of badge of honour, trying to live up to their name once listed as an LTA, or by new vandals attempting to emulate the well documented vandalism methods. We should be doing a better job of denying recognition to these vandals, but this is hard to do whilst also keeping a comprehensive open record of their actions on Wikipedia. The other issue with having these records in a public space is not being able to properly document the vandals' edit patterns or our counter measures to avoid BEANS issues, leaving out information that could be valuable to anti-vandal editors.

Proposal

We are therefore proposing a new tool for Wikipedians, called the LTA Knowledgebase, which would be an off-wiki database of LTA records, available for viewing and editing to only (probably approved) experienced editors. Samtar has been working on this for a little while now, and you can see a proof-of-concept version here. With this database vandal fighters will be able to both log information on more recurring vandals as well as covering their editing habits and what we're doing in response in more detail (documenting how relevant targeted edit filters work for example). This will be especially beneficial for those LTAs who we don't even document in order to fully deny recognition. LTAs won't know whether they have an entry, nor what that entry contains.

This tool will not be for extra personal information on these users; it will only encourage more behavioural details, and rules will need to be in place for tool admins to remove any personal information that is added. Requirements for access can be debated in another RfC, but the approach would likely be that users would require manual approval from a tool admin with the needed experience level somewhere between that of NPP and OTRS, requiring sufficient time and experience working on anti-vandalism work to be trusted. Future RfCs could also decide on criteria for the addition of an LTA to the tool and whether all users are able to add an entry or whether new entries might require approval by a tool admin, for example.

Subsequent discussions can be held to clarify the details and specifics so these needn't be debated here beyond suggestions and initial discussion. Sam Walton (talk) and Samtar talk · contribs 16:21, 5 February 2017 (UTC)[reply]

The first question that needs to be answered is: Should the English Wikipedia have an off-wiki LTA database that can only be viewed and edited by trusted editors?

Support (LTA Knowledgebase)

  • Support - excellent idea and needed. Search should be on anything so searching on "Armenia" should find the LTA record for Ararat arev. -- GreenC 17:41, 5 February 2017 (UTC)[reply]
  • Support - and probably all admins should be approved automatically on request. עוד מישהו Od Mishehu 04:38, 6 February 2017 (UTC)[reply]
  • Support provided there is or will be an option to filter by active wiki and/or topic areas they're mostly active in (some LTAs are also belligerents in topic areas known to be warzones; for example Runtshit's second most favourite pastime is stirring the Israel/Palestine pot). —Jeremy v^_^v Bori! 05:06, 6 February 2017 (UTC)[reply]
  • Support. This is an excellent idea, and of course it would make sense to automatically approve all sysops. Tony Tan · talk 06:19, 7 February 2017 (UTC)[reply]
  • Support and make it automatic for Admins. -- Iazyges Consermonor Opus meum 06:22, 7 February 2017 (UTC)[reply]
  • Support, of course, because the proposal would solve the very serious BEANS problem associated with LTA pages. A similar solution would be good for sockpuppet investigations, for the same reason. Binksternet (talk) 06:43, 7 February 2017 (UTC)[reply]
  • Support Good BEANS solution (although I'll be sad to lose the innocent enjoyment of browsing that den of depravity) -- Elmidae (talk · contribs) 17:11, 7 February 2017 (UTC)[reply]
  • Strong support This is much-needed! — Gestrid (talk) 19:34, 8 February 2017 (UTC)[reply]
  • Support per above. MER-C 05:28, 11 February 2017 (UTC)[reply]
  • Support This is needed. ThePlatypusofDoom (talk) 13:08, 14 February 2017 (UTC)[reply]
  • Support with the suggestion that the requirements for access should be low - anyone with any of the various admin-granted user rights (rollback, reviewer, autopatrol etc) should be approved. This will prevent it from becoming seen as a secret cabal. Hut 8.5 18:36, 14 February 2017 (UTC)[reply]
  • Support I have read through the proposal, and it seems like a fantastic idea. Qaei ☎ 21:12, 14 February 2017 (UTC)[reply]
  • Support as others this is needed. There are a growing number of LTA cases where the main motivation seems to be generating larger and larger LTA report entries - if these occur off-wiki and in a less conspicuous location, I'm certain some LTA disruption will cease. I'd also add, the growing use of Wikidata as a repository for certain key data sources will require something to be done to co-ordinate action against LTA cases running across multiple sites, and speaking as an English Wikipedia and Commons administrator, it's very difficult to co-ordinate action as it is when all we're dealing with at Commons is (mainly) copyright issues, once WD seriously starts to become another place to fight over sources, data and page titles (you know, the sort of shit we've been dealing with over Eastern Europe, the Balkans, Israel/Palestine for every day I've been editing) it'll be imperative we can provide our WD colleagues as much data as possible so they can deal with issues. Nick (talk) 21:17, 14 February 2017 (UTC)[reply]
  • Conditional support With the proviso that the LTA pages stay useful enough so that inexperienced editors can refer to them to see the nature of the disruption and how to spot possible socks. --NeilN talk to me 21:21, 14 February 2017 (UTC)[reply]
  • (edit conflict) Support As far as some of the responses regarding attention seeking not being such a big issue, even if that were true (which I wholeheartedly disagree that it isn't) patterns are also a big part of tracking and identifying LTAs and discussion of those patterns is equally as important but discussing (as in identifying) them on-Wiki kinda gives it away (and also WP:BEANS may apply) and they may begin a newer pattern that isn't as easily identified. Though I support this for many more reasons as well...Chrissymad ❯❯❯ ¯\_(ツ)_/¯ 21:25, 14 February 2017 (UTC)[reply]
  • Support – We can probably hammer out the finer details in a second discussion, but a change in this general direction would be welcomed. I've always seen the LTA pages as almost diametrically contrary to WP:DENY (and publicly stating what kinds of edits to look for lets the abusive editors know exactly what kinds of edits to avoid, unless they want to be seen). One word of caution that I would advise is that the requirements for gaining access these pages should be low. I don't even think you need to have any additional user rights or a demonstrated need; anyone who is demonstrably WP:HERE should be able to see these pages on request. (Perhaps the ability the create and edit the pages could be restricted to a higher access level?) The more they are hidden, the less comfortable good-faith editors who don't have access to the pages feel. We want to find the right balance between preventing disruption and maintaining transparency in project administration. Mz7 (talk) 22:06, 14 February 2017 (UTC)[reply]
  • Support - I only have a little bit of experience with LTA cases, but I think that in each case, I came to the conclusion that it wouldn't be productive to "tip our hand" by adding to the details about a user's behavior when it may not be obvious to that user that others are onto a particular strategy/habit/pattern. Of course, this may be presuming that the SPI information that goes along with the LTA cases could also be hidden, and that may not actually be intended here. — Rhododendrites talk \\ 00:48, 15 February 2017 (UTC)[reply]
  • Support I think this solution is appropriate to the problem. Chris Troutman (talk) 12:21, 16 February 2017 (UTC)[reply]
  • Support - details about enforcement should rightfully be hidden from the public at large. That said, access control shouldn't be strict - given that it's meant to be an anti-vandalism reference, giving all rollbackers access sound about right. — Train2104 (t • c) 20:21, 17 February 2017 (UTC)[reply]
  • Support. It's a great idea! That page is like the "How to become an experienced vandals" for them. But I think only users with a certain number of construtive edit can access. By the way it's an important source for newbies too so everyone in the community knows what to do to block distruptive vandals.Justmeonhere (talk) 20:56, 19 February 2017 (UTC)[reply]
  • Support the concept. Oppose some small but serious details with the implementation plan, pending a pause before the next phase for conversation to address those details. I want the benefits and agree with the idea but I would not want the current implementation direction advanced without conversation, and I really do believe there are non-controversial, low risk paths forward. The WMF recently published advice to set up a sort of LTA Knowledgebase, so there is institutional support for the concept. That support and other hints of the idea are in the November 2016 meta:Training modules/Online harassment/First draft and meta:Training modules/Keeping events safe/First draft. With many others I proposed meta:Grants:IdeaLab/Centralised harassment reporting and referral service some time ago, which is a similar concept. Blue Rasberry (talk) 20:00, 22 February 2017 (UTC)[reply]

Oppose (LTA Knowledgebase)

  • Oppose. There's not much I can do to prevent an off-wiki database, though I think it's probably not a good idea, I'm generally opposed to removing the information from Wikipedia. It's useful for editors to be able to look up cases to be able to recognise LTAs. It's also useful for admins to just link to the cases instead of having to provide detailed explanations each time, when blocking and so on. Here for example, an IP user could tell me all I needed to know by linking to an LTA page. Reports at AIV for example will often just say "see WP:LTA/xxx", which is something I don't think should be restricted to a trusted subset of users. More eyes on reports means more good information and less incorrect information as far as I'm concerned. Like I say, there's nothing preventing anyone setting up a private LTA database anywhere they like, but the on-wiki version is useful, so for this reason I'm landing in the oppose section. -- zzuuzz (talk) 20:00, 8 February 2017 (UTC)[reply]

*Provisional oppose. Until a concrete plan is hammered out for how the existing LTA pages will be used and updated. --NeilN talk to me 14:27, 10 February 2017 (UTC)[reply]

  • @DatGuy: The stated goal of this project is to collect information on users, so it is more than likely that personal information with be shared there, whether intended by the designers or not. Regardless of the alleged ills that caused the reported users, this is a problem that should be taken seriously. There should be an oversight-like system to remove personal information. ArbCom should have jurisdiction, to reduce the probability for this type of incidents and settle any such incident. We need a real assessment that this complies with the privacy policy, not just some vague feeling it does. Cenarium (talk) 23:05, 14 February 2017 (UTC)[reply]
  • Oppose as self-defeating. The entire point of LTA is to inform editors of how to deal with serious vandalism. Moving this to a secret database which few have access to (and few would request access to, I believe) makes LTA pointless. I could only support this if the requirement for viewing was extended confirmed. Laurdecl talk 09:51, 14 February 2017 (UTC)[reply]
  • @Laurdecl: I don't know what you mean 'requires something like WP:PERM.' If we continue with a labs tool and not a wiki, you will click on "request account." Following a short amount of time, if you are not a vandal and some you will be accepted. For example, you would be accepted. Dat GuyTalkContribs 15:04, 15 February 2017 (UTC)[reply]
  • @DatGuy: "would require manual approval from a tool admin with the needed experience level somewhere between that of NPP and OTRS" sounds to me like WP:PERM. Anyway the issue is not whether I would get accepted, but whether this would restrict casual editors from learning about LTAs. LTA is supposed to educate editors about persistent vandals they may stumble across. Most editors would not even bother requesting permission and by the time they are approved would have lost interest. Again, if access was automatically given with extconf, I wouldn't oppose. Laurdecl talk 06:19, 16 February 2017 (UTC)[reply]
  • Oppose. On-wiki lists (pertaining to matters exclusively to that wiki) need to remain exclusively on-wiki. The alternate way to improve LTA would to make the on-wiki page more accessible and searchable. Steel1943 (talk) 14:12, 14 February 2017 (UTC)[reply]
@Steel1943: I don't think you get the point. We want the page to be less accessible, so vandals can't look at the LTA page, completely change their behavior, and not get caught. Also, an LTA page that's easily accessible kind of goes against WP:DENY, as it gives the vandals attention. ThePlatypusofDoom (talk) 22:19, 14 February 2017 (UTC)[reply]
@ThePlatypusofDoom: Oh, but I do ... since having such a database also restricts good-faith editors without whatever user right or program will be necessary to access this database from figuring out what in the world those with access are talking about, or for that matter, even know how to identify a LTA case themselves. So, the argument here is between figuring out if WP:BEANS or the risk of removing the transparency of the Wikipedia project is preferred. And with that being said, I think the latter is worse since hiding information such as this per WP:BEANS goes against some of the public domain licenses and goals of Wikipedia, especially considering that most of these LTA cases are already posted and thus have, in turn, already been agreed upon to be available to essentially any reader per the applicable license(s). In a nutshell, I worry that creating a separate, "inaccessible to some" database could have legal ramifications that I think the foundation would really rather not have to deal with. Steel1943 (talk) 22:30, 14 February 2017 (UTC)[reply]
...Come to think of it, I guess I could just attempt to confirm my concern with one of the proposers of this: @Samwalton9: I know you may have some insight on this: Per my comment above, would you think there would be and legal issues with such a database, and if not, why? Steel1943 (talk) 22:33, 14 February 2017 (UTC)[reply]
I'm very much not a lawyer, but I can't see why something that's been posted on Wikipedia is somehow required to stay on Wikipedia. Pages and edits are deleted and oversighted on a regular basis after all and any content copied over would be attributed in some way. The only legal concerns I could see would be around users assuming it more reasonable to post private/personal information there, but this is obviously a serious concern that would be given importance. Sam Walton (talk) 22:42, 14 February 2017 (UTC)[reply]
@Samwalton9: Yeah, I was more or less asking you in the event that you knew something as part of your "other life". For a few years now, I had the assumed understanding that unless there was some sort of legal issue with keeping something on Wikipedia, the information on a page, deleted or not, could be provided to almost anyone who requests. (But of course, whether or not it stays on Wikipedia is up to the community.) Just trying to ensure that any decision established as a result of this discussion will not cause legal issues that could bite the foundation later. Steel1943 (talk) 22:49, 14 February 2017 (UTC)[reply]
You'd need to ask someone from Legal for an official word on that, but either way, I think it would be reasonable to keep the text that's currently on LTA pages there (it's out in the open now at any rate) and simply not add any more to them from now on. Sam Walton (talk) 22:54, 14 February 2017 (UTC)[reply]
@Samwalton9: Understood and thanks! Not sure how or who to ask "from legal" though since I'm embarrassingly not sure how to do that. Steel1943 (talk) 22:57, 14 February 2017 (UTC)[reply]
@Steel1943: In the past, I've been able to contact Legal by simply leaving a message at User talk:Mdennis (WMF), and Maggie Dennis will liaise with the legal team for you. I think, however, you can also contact legal@wikimedia.org directly per wmf:Contact us, though I've never tried it that way. Mz7 (talk) 23:07, 14 February 2017 (UTC)[reply]
  • Oppose. As an administrator on a sister project I have found the publicly viewable LTA documentation here very valuable, because a number of these abusers take their activity cross-wiki when their efforts are frustrated by anti-vandalism measures here. If this research and documentation is kept behind closed doors then my job will be more difficult. (I am not persuaded that this proposal does not deprecate public LTA tracking: publicly viewable pages would fall into disuse and cease to be a valuable resource.) ~ Ningauble (talk) 17:56, 15 February 2017 (UTC)[reply]
    @Ningauble: There would certainly be plans to make sure this could be used and accessed across other language Wikipedias, but you raise a fair concern that this should be a priority before deployment. Sam Walton (talk) 18:27, 15 February 2017 (UTC)[reply]
    Sam, I was referring to a sister project rather than another language Wikipedia, but the case of my personal anecdote can be generalized in various ways. The most important generalization, common to both, is explicit in my post above: "publicly viewable" wikis. ~ Ningauble (talk) 18:57, 15 February 2017 (UTC)[reply]
  • Oppose on general principle of not maintaining such an archive as an off-wiki resource, and as well as limiting access to any specific group. I get the BEANSy-ness of the argument, but moving this off-wiki leaves us using an off-wiki repository for enforcement when any LTA comes back up. Access limitations to such a resource would plainly limit the ability of some editors to review such material and contribute to consensus. It should be made more usable, and some kind of archiving is a good idea, but it should stay inside the project, and available to all editors. Jim Miller See me | Touch me 19:48, 15 February 2017 (UTC)[reply]
  • Strongest oppose Creating an off-wiki restricted database with the express purpose of identifying particular users? No thanks. Wugapodes [thɔk] [ˈkan.ˌʧɻɪbz] 20:06, 19 February 2017 (UTC)[reply]
  • Oppose I could see such a system for off wiki info. On wiki allowed stuff should be on wiki. Also the site should be a wiki not whatever this is. Doc James (talk · contribs · email) 17:51, 20 February 2017 (UTC)[reply]
  • Oppose per Steel1943. Such stuff needs to remain on wiki. If you want to make an improved interface for accessing and searching LTA pages (which remain on wiki) that's fine. Kind of like Wikipedia:AutoWikiBrowser/CheckPage: primarily used by external software but still accessible on-wiki. feminist 09:45, 21 February 2017 (UTC)[reply]
  • Oppose I've been hesitating here , trying to make up my mind, and I think at the end of the day I oppose this. I tangled with one of the more notorious LTA cases early in my wiki-career, and free and easy access to the page about them helped me quickly understand what I was dealing with and how to respond appropriately. Moving it off-wiki, no matter how you do it, lowers the profile iof this important resource, possibly preventing newer users from even being aware of it. Duplicating it offline while keeping it here seems pointless. So I think we should keep it here. Beeblebrox (talk)
  • Oppose I think there are serious transparency issues that need to be addressed before I could support a proposal like this moving forward, and I'm not sure they can be. The fundamental problem is that if this is useful, it means we are using access restricted/secret information, as justification for on-wiki action that will likely involve blocking people. It is already problematic when Arbcom and other functionaries do it, but in that case, they are a very small group, of highly vetted and trusted users, and the secret information they use cannot be posted publicly. It also has various checks built in to provide review and limit abuse. It would be better if we didn't need it, but it is in the end a necessary evil. This does not appear to be such. If someone is being blocked for LTA, they should have the right to see the evidence presented against them. Moreover, if the block ends up being reviewed at WP:AN the community must be allowed to see the evidence, so they can judge the block. I would still have concerns, but at the least, I think there needs to be a way to make the entire LTA case fully public for review. Monty845 06:03, 24 February 2017 (UTC)[reply]

Discussion (LTA Knowledgebase)

What's going to happen to the existing LTA pages if this is implemented? --NeilN talk to me 16:30, 5 February 2017 (UTC)[reply]

I guess that's open to discussion, the options would be to retain them since the information has been public for long enough already, archive them and provide links to the new tool which may contain extra information, or remove/delete them. I think the preferable option would be to retain/archive so that existing links still work, but include a link to the tool and tell users to add content there rather than on-wiki. Sam Walton (talk) 16:46, 5 February 2017 (UTC)[reply]
I would probably oppose anything which prevented me from helping new/occasional editors (i.e., "non-approved" editors) understand what's going on by pointing to a LTA page explaining the nature of the abuse/disruption, what to look out for, etc. --NeilN talk to me 16:58, 5 February 2017 (UTC)[reply]
@NeilN: Perhaps we could repurpose the on-wiki pages to provide very general descriptions, moving all the specifics and IP/account records to the tool. Sam Walton (talk) 21:11, 5 February 2017 (UTC)[reply]

This is an interesting proposal and I know a case where it would help me have useful discussions about a particular LTA. Sam Walton, I don't think this is your part of the WMF, but something like this has been suggested in the new Community Health Initiative grant proposal, page 11. Had you heard of this? If so, do you have any thoughts about how it might tie in? BethNaught (talk) 17:05, 5 February 2017 (UTC)[reply]

@BethNaught: Interesting - I hadn't had a chance to read that document yet and wasn't aware that such a tool was already being talked about. It seems that the resource proposed there would be broader, documenting cases of harassment and editing restrictions too. We'll speak to Community Tech to see if it's worth continuing with this tool if they're planning to work on that. Sam Walton (talk) 21:13, 5 February 2017 (UTC)[reply]
Indeed, we were planning on making a similar, more broadly scoped tool that I think will account for all types of abuse. The LTA Knowledgebase as currently constructed could be adapted for this purpose, along with adding multi-project support and i18n. The harassment project as a whole is still in its very early stages, so for now I would carry on and assume there won't be any conflicts with what WMF will be working on. It is nice to see the community getting a head start and this RfC attracting support. Assuming you all are OK with joining forces (we certainly are), Community Tech will soon be in touch with Samtar, Sam Walton, and any other Sams involved :) — MusikAnimal talk 16:34, 7 February 2017 (UTC)[reply]

How about hosting a multilingual LTA on Meta? KATMAKROFAN (talk) 17:42, 5 February 2017 (UTC)[reply]

Down the road, it is planned that there will be multilingual support, especially for dewiki. Dat GuyTalkContribs 17:47, 5 February 2017 (UTC)[reply]

Please spell out the proposal ("viewing and editing to only (probably approved) experienced editors" is ambiguous). Currently it is possible to link to an LTA page in a comment or edit summary to explain an action. It is desirable to minimize such linking per WP:DENY but it is sometimes needed. Would the new system allow such links? What happens when people (an IP, a new account, an autoconfirmed account, an approved LTA operator) click them? I'm asking because if the information is available to all, why is the new system better than LTA pages? But if it's only available to approved operators, a link loses its explanatory power, although a link to generic information with a tag like an WP:OTRS ticket for more details would be good. Johnuniq (talk) 00:45, 6 February 2017 (UTC)[reply]

I would think that some standard similar to ECP would be used, albeit with a bit more restrictions on time and edit number (I'm thinking 1yr/10K edits on any one project). Anyone with sysop permissions on any wiki should automatically be trusted. I do have to ask, though; is there (or will there be) an option to filter LTAs by the wiki(s) they're active on? —Jeremy v^_^v Bori! 04:59, 6 February 2017 (UTC)[reply]
@Jéské Couriano: It is possible to link using toollabs:lta/publicdemo/view.php?lid=8 or via an external link. Currently its only enwiki, but when it will be expanded to other wikis there definitely will be an option to filter LTAs. There are no set requirements, but sysops will be always approved. There might be consensus on requirements in this RfC. Dat GuyTalkContribs 06:48, 6 February 2017 (UTC)[reply]
Above link doesn't work, try https://tools.wmflabs.org/lta/publicdemo/view.php?lid=8 -- Samtar talk · contribs 12:00, 6 February 2017 (UTC)[reply]

Why not implement this as a private wiki? We already have the private "arbcom-en.wikipedia.org" wiki as a precedent. I don't see why a custom tool on Labs is necessary; wikis come with a lot of built-in features like revision history. And availability is another consideration – what will be done during one of Labs' brief but regular outages? LTA response is not something which can wait until the outage is over, unlike, say, edit counting or category intersections. — This, that and the other (talk) 09:19, 9 February 2017 (UTC)[reply]

I second this comment. LTA databases should have lots of links back to the wikis targeted. Don't reinvent the wheel -- a private wiki is a very good solution for this problem. MER-C 05:33, 11 February 2017 (UTC)[reply]
@Samtar: We discussed this on IRC, but could this be restricted to people with Rollback? It's not hard to get and most vandal fighters have it already, and the requirements wouldn't be that strict, but it wouldn't be very easy for an LTA to get. ThePlatypusofDoom (talk) 17:30, 14 February 2017 (UTC)[reply]

To resolve some of the transparency issues involved, would it be feasible to use WP:OAuth and allow users to log in with their regular Wikipedia account, rather than create a separate Knowledgebase account? We could, perhaps, then allow all extended confirmed (or even lower) users to view LTA pages just to maintain transparency, and then grant editing access to the Knowledgebase using the manual approval process mentioned in the proposal. Mz7 (talk) 23:01, 14 February 2017 (UTC)[reply]

@Mz7: Samtar can clarify, but I believe the plan would be to use OAuth. Sam Walton (talk) 18:28, 15 February 2017 (UTC)[reply]
You login using OAuth. It still needs to go through a confirmation process if it is your first time though (even for viewing currently). Dat GuyTalkContribs 19:24, 15 February 2017 (UTC)[reply]
Ah excellent. Thank you both for the clarification. Mz7 (talk) 21:00, 15 February 2017 (UTC)[reply]
Request for listing

Could someone list this on WP:CENT? Seems suitably important. Tamwin (talk) 04:59, 14 February 2017 (UTC)[reply]

 Done Tamwin (talk) 06:46, 14 February 2017 (UTC)[reply]

Clarification ref current LTA pages

Hi all - a couple of people have raised concerns about what who happen to the current WP:LTA pages should a tool like this been accepted by the community - personally I wouldn't do anything with them, but others have suggested generalising them with WP:BEANS and WP:DENY in mind. What definitely won't be happening is them being deleted as this would seriously affect the ability of newer editors being able to assist with anti-vandalism. This tool has been designed to compliment and enhance our current methods of LTA-handling, and not to entirely replace it -- Samtar talk · contribs 15:34, 10 February 2017 (UTC)[reply]

Not sure if you've seen this @NeilN and Zzuuzz:. Dat GuyTalkContribs 10:29, 11 February 2017 (UTC)[reply]
Yes, but I'd like a more concrete plan. Not deleting is one thing, but how about updating and adding new cases? --NeilN talk to me 14:13, 11 February 2017 (UTC)[reply]
I think I have similar concerns to NeilN. Where would LTA reports go? Where do we point IP users who want to be informed of an LTA, and how can they point me to a page in order to get a block or page protection? How will this differ from the current system? If the current LTA system is unaffected, then we'll just carry on at LTA like normal (in the useful manner I've described above) and my oppose can be shifted from oppose to meh (for various (possibly unfashionable and idiosyncratic) reasons I don't think semi-private forums, like WP:WEA, are usually a net positive). But if the effectiveness of LTA is reduced by these changes then I have concerns. -- zzuuzz (talk) 20:53, 11 February 2017 (UTC)[reply]
Don't see how you can "generalise" without effectively deleting them. All the best: Rich Farmbrough, 23:47, 13 February 2017 (UTC).[reply]
@Rich Farmbrough, Zzuuzz, and NeilN: The current LTA system will stay the same. The tool could be seen as a "bonus." Dat GuyTalkContribs 17:38, 14 February 2017 (UTC)[reply]
The second paragraph of the introductory background for this proposal, beginning at "But these pages aren't without their drawbacks...", seems quite clear about deprecating the existing LTA pages. If a private database is adopted and used by a critical mass of (approved) anti-vandal editors, I find it hard to imagine that the existing LTA pages would not fall into disuse, at least, and might ultimately disappear. ~ Ningauble (talk) 17:32, 15 February 2017 (UTC)[reply]

Unpatrol moved pages

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

I present a proposal: that any time an article is moved it should lose its patrolled status, so that it is flagged for new page patrol (again, if necessary), other than page moves by editors with the page mover or autopatrolled rights, or perhaps all extendedconfirmed users.

A prolific sockpuppeting spammer has recently been discovered abusing the new pages patrol process to create promotional articles without detection. Without going into too much detail, the spammer "hijacks" a disambiguation page which has already been patrolled, replaces its content with the promotional article, moves that article to a new title carrying the patrol flag with it, then covers their tracks by replacing the {{R from move}} redirect with a redirect to one of the entries on the former dab page. This way their new page does not show up in page curation and the broken dab links aren't blatantly obvious, so this vandalism is only discovered if another user happens to be watching the page, or comes across the hijacked dab by chance. As I understand it, edit filters are ineffective because this vandalism involves a sequence of several edits, none of which are particularly easy to detect for wrongdoing in and of themselves.

For background, please see:

This activity is particularly insidious because it's more than just spamming the project: this vandal is also destroying good content in the process, in a way that's proven difficult to detect, but fairly easy to repair. It's also a pretty easy to replicate backdoor through new pages patrol, our only filter against unwanted new content. This proposal is a weak solution, but it is the only solution I can think of which would not prevent a large class of users from editing (such as restricting page moves, or some such). If someone has a better way to detect this, I'd certainly be glad to hear it. I look forward to your thoughts. Ivanvector (Talk/Edits) 14:36, 7 February 2017 (UTC)[reply]

A good technical question; I don't really know. I have always assumed that page patrol is a boolean state, and that any non-redirect article which does not have the patrolled bit set will appear in the Page Curation feed, and that therefore includes pages which have had the bit un-set for some reason. Perhaps an editor with more technical familiarity can comment. Ivanvector (Talk/Edits) 18:23, 7 February 2017 (UTC)[reply]
In core, patrol flag is assigned to an edit (we only have NP patrol but some wikis have full RC patrol, which would be unmanageable here, what we would need is something in between). In PageTriage, patrol flag is assigned to a page. Cenarium (talk) 13:51, 8 February 2017 (UTC)[reply]
Note - please see Filter 837 for any hits - this should catch removal of the disambiguation template. עוד מישהו Od Mishehu 09:53, 8 February 2017 (UTC)[reply]
Note: I've notified WT:NPR and WT:NPPAFC of this proposal. – Joe (talk) 15:26, 11 February 2017 (UTC)[reply]
  • Oppose pending more information. I'm concerned about rushing into something that will potentially hugely increase the load at the already hugely-backlogged WP:NPP. How many pages are moved per day? How many more reviewers would we need to handle the extra load? What's the scale of this problem? Are there other solutions we could explore (e.g. marking pages that have {{disambig}} removed as unpatrolled)? – Joe (talk) 15:32, 11 February 2017 (UTC)[reply]
  • Oppose Support per further discussions below This is not really a good solution for the problem. Simply removing the patrol bit places the page in a queue with about 16,000 other pages. If this type of vandalism is a major problem then there needs to be a seperate queue which will allow for quicker inspection as well as to give the reviewer an idea that they are looking at an old moved page that may have been hijacked rather than a new creation. Finally, removing the patrolled flag, I think, reinstates the NOINDEX magic word. It may get removed by virtue of the page being over 90 days old but I do not know.

    Get the foundation to give development time the the Curration Tool, add a filter by recently moved and we're good to go. If not this will not solve the problem. I would support this if it were something other than just 'unpatroll moved pages'. Jbh Talk 15:33, 11 February 2017 (UTC) Last edited: 15:27, 15 February 2017 (UTC) [reply]

    • This won't noindex the page, which isn't possible after a page is older than 30 days anyway, see the updated documentation. I've suggested using a separate queue below. Cenarium (talk) 16:36, 11 February 2017 (UTC)[reply]
      • Thanks. That is good to know although I thought new pages were NOINDEXed for 90 days, at least that is what everyone was mentioning back when it was turned back on a few months ago. Jbh Talk 17:01, 11 February 2017 (UTC)[reply]
        • I could have sworn it was 90 days too. That's quite concerning, considering the NPP backlog is at least three months. – Joe (talk) 19:16, 11 February 2017 (UTC)[reply]
          • There was confusion as to the value of $wgRCMaxAge, it is 90 days in default MediaWiki but 30 days on WMF. This is for how long recent changes are kept in the database. The vast majority of the stuff that shouldn't be seen by search engines is removed after the 30 days though, and going beyond that point would risk antagonizing creators of good content whose articles get stuck in the backlog. Cenarium (talk) 20:51, 11 February 2017 (UTC)[reply]
            • Having done a lot of patrolling at the back of the queue (currently new articles from August), I'm not so sure that's the case. And perhaps letting NOINDEX stick around indefinitely would antagonise creators of good content enough to get them to help out at WP:NPP... but we're probably getting off topic. – Joe (talk) 08:10, 12 February 2017 (UTC)[reply]
  • Oppose Support per below numbers and conversation We have recently just got the backlog down to a somewhat stable 14,900 pages needing review from a spike to around 16,000. This would increase the already substantial workload on those of us who spend our time at NPP. The newly promotional page would also get thrown in the feed at the time of the creation of the original page if this works like converted redirects. If the page was older, that would probably be a good thing because there is a fair amount of activity at the end of the backlog with people trying to clean up, but if the promotional accounts picked a disambiguation page that had been reviewed mid-December, it would likely go unnoticed for months, all while growing the backlog. I could support something along the lines of Joe's suggestion of marking converted disambiguation pages as unpatrolled, but just marking new moves as unpatrolled will not be helpful. TonyBallioni (talk) 16:17, 11 February 2017 (UTC)[reply]
  • Comment This doesn't have to be added to the NP feed, in fact we could have a separate Special:NewMoves page. There are several other reasons for doing this, as noted in phab:T14363. This would then be more integrated in the RC workflow than the NP workflow. Cenarium (talk) 16:36, 11 February 2017 (UTC)[reply]
  • I could support having a separate "New moves" workflow that would be like RC patrolling. I would still oppose marking them as unpatrolled, however, because since the RfC last Fall, only admins and new page reviewers can mark a page as reviewed. Having a separate feed wouldn't add to the backlog at NPP, but requiring the user right to mark them as patrolled would necessarily split the labour for a task that I think most editors could handle. TonyBallioni (talk) 16:48, 11 February 2017 (UTC)[reply]
  • I would support either a seperate queue or a filterable tag. Whether the page should be un-patrolled depends on how prevalent this problems is vs the number of pages moves made. Jbh Talk 17:01, 11 February 2017 (UTC)[reply]
  • It's a convoluted way to bypass new pages patrol, and there are other ways to bypass NPP using moves. So it has to be restricted to admins / NP reviewers otherwise these sockpuppets could patrol each other. As for how many are going to be a problem among all page moves, I expect only a few, but the difference with new page patrolling is that it's easy to spot if a move is legit while it can be time consuming to patrol a new article neither obviously bad or good. Cenarium (talk) 21:29, 11 February 2017 (UTC)[reply]
  • (edit conflict) Just by a very crude looking at the move log, on 10 February we had over 1000 pages moved. Given, a signficant portion of those are talk pages, and some in other name spaces, but you are talking about hundreds of pages a day being marked as unpatrolled. Creating this as a something needing to be patrolled with a user right is just begging to create an additional backlog. I'd like to see better numbers on this if someone could produce a report of the average number of mainspace moves per day/per week, but just from my crude looking at the move log, I really do not think that adding move patrolling as a responsibility of NPP/those with the NPR user right will have much impact on people bypassing the new pages feed, because most of it would be buried in a backlog of mostly good-faith moves with a limited number of people who are able to review it. TonyBallioni (talk) 22:17, 11 February 2017 (UTC)[reply]
  • @Pppery: No, the move log doesn't allow to filter by namespace of the moved page, it includes multiple moves of a same page, and it can't hide bots or patrolled moves. @TonyBallioni: There are 15234 moves in mainspace in recent changes (last 30 days). However, 10343 of them are by extended confirmed users. So if they were automatically patrolled, this would give us about 163 unpatrolled mainspace moves per day on average. Cenarium (talk) 00:16, 12 February 2017 (UTC)[reply]
  • Support/Oppose - I support having some sort of patrolling mechanism for page moves, but I don't think dumping all moved pages into the new pages feed is going to help things. That backlog is already huge and growing. Maybe they could be added into it with a special filter option (i.e. "Show page moves") or maybe it could be a totally separate backlog as suggested by Cenarium, but I don't think just unpatrolling them is the best idea. Kaldari (talk) 03:15, 12 February 2017 (UTC)[reply]
  • support This fills a significant gap in our procedures that has been exploited by many promotional editors for years, not just the case that instigate this proposal. Despite the backlog, I think it would need to go into the regular feed, because things will be even worse if we start adding new processes--we want to do the opposite, combine and simplify as much as possible. We'll have no less difficulty keeping track of them in separate processes. I assume it will be programmed so that moves by autopatrolled editors will be marked as patrolled, just as their new articles are. DGG ( talk ) 23:03, 12 February 2017 (UTC)[reply]
  • @DGG: would you be open to the idea suggested above that move from extended confirmed users be autopatrolled? I think 163 pages a day would be easy to manage in the existing feed so long as there would be an option to sort for only moves. TonyBallioni (talk) 23:16, 12 February 2017 (UTC)[reply]
Extend-confirmed is quite new. I can't say I've looked systematically, but I've encountered extended-confirmed editors who shouldn't be having autopatrolled on the work they submit. It would lead to spammers trying to game extended-confirmed just the way they gamed autoconfirmed. It's harder, but the spammers are trying harder these days. From the numbers given above, the actual workload would be about a 10% increase. What I think we need is more awareness that people can ask an admin for the autopatrolled right, and I for one am quite liberal in granting it--sometimes even before people ask, from observing their new pages. As for filtering, we need much more sophisticated filtering of new pages in general, including for this. DGG ( talk ) 23:45, 12 February 2017 (UTC)[reply]
I forgot to include sysops/bots in the previous query, out of the total of 15554 there are 10407 moves by extended confirmed users, 2358 by sysops, 1596 by bots, 1019 by extended movers and 5875 by autopatrolled users. So move-autopatrolling extended movers/autopatrolled users makes about 157 moves to patrol each day, while move-autopatrolling all extended confirmed users make only about 40 moves to patrol each day. Cenarium (talk) 18:46, 13 February 2017 (UTC)[reply]
The 40 number seems small enough to me to dump into the NPF as is. 157 I would prefer a separate feed or at least better filtering at Page Curation. TonyBallioni (talk) 18:54, 13 February 2017 (UTC)[reply]
  • Support I don't really get the opposition based on 'but it would add to the backlog!'. Well, yes it would. That's the point. A move causes a page to need to be patrolled. However, I'm certainly not objected to a "MovePatrol" log, or a filtering option or whatever. Headbomb {talk / contribs / physics / books} 12:00, 13 February 2017 (UTC)[reply]
  • Support Personally think only pagemovers and Autopatrolled should be excluded, as they have clearly been given a right showing their page moves dont need checking. -- Iazyges Consermonor Opus meum 13:05, 13 February 2017 (UTC)[reply]
  • Support - it's a good suggestion and it might just catch the more sophisicated forms of spam, but I'm seriously worried about why, with 350 New Page reviewers created since November, the backlog has shown practically no real signs of dropping. Forgive me my lack of AGF, but were they perhaps mostly hat collectors? Some indeed had not touched the Wikipedia for several years. The only thing at this stage that will make a dent in the new pages feed is WP:ACTRIAL. Kudpung กุดผึ้ง (talk) 10:44, 14 February 2017 (UTC)[reply]
Kudpung, Your assertion that there are loads of hat-collectors seems founded on the notion that all the users granted NPR were new new page reviewers. Scanning Wikipedia:Requests for permissions/Approved from the first NPR request on 29 Oct shows,
  • October : 10 requests
  • November : 105 requests
  • December : 29 requests
  • January : 25 requests
  • February : 10 requests,
a total of 179 approved requests. From this we've lost
  • 2 blocked spammers,
  • 1 self-requested block, and
  • 2 successful RfAs,
leaving 174 new NPR "hat-holders" in addition to the 171 grandfathered-in. I'd interpret the numbers as showing that there were 115 patrollers who noticed they'd lost the ability to patrol in Oct & Nov and applied to regain what they already had. This would mean we had 286 existing patrollers, to whichanother 64 have been added.
It's also likely to mean that the patrol group has lost a number of patrollers who didn't bother to reclaim the privilege, maybe because they no longer see it as a significant part of their wiki-activities, or for fear of being called hat-collectors.
You're expecting an awful lot from an probable increase of 30-40 patrollers, maybe 10% of the group's size.
The best that could be hoped for from the new privilege is a higher level of competence in the reviewing and more reliable outcomes. Just my 2¢. Cabayi (talk) 13:35, 14 February 2017 (UTC)[reply]
Cabayi, your assertion of my assertion, is once again, just plain wrong. If you want inside knowledge, then run for RfA, get the bit, then work the page at PERM. I am not going to do you the pleasure of going through your list to demonstrate once more that a large number of requests came from editors who had been almost totally inactive for years. Your time would be better spent counting how many patrolls each newly created New Page Reviewer has done - or do some reviewing yourself. Kudpung กุดผึ้ง (talk) 00:26, 15 February 2017 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

mandatory tagging of all refdesk pages and some refdesk questions

General refdesk disclaimer tag

Should the following tag, or something like it, be added to all reference desk pages and edit notices? User:Beeblebrox/sandbox 3 (Please keep in mind that this is just a rough draft, and not even in template namespace, this is just to give the general idea of what such a template might be, formatting and specific language can always be adjusted later.)

Discussion of General refdesk disclaimer tag

What about a smaller edit notice instead, similar to the one on this page? Instead of a big red box, what about a simple information box with the blue "i" icon providing links to Wikipedia's disclaimers, and other information pages regarding the reference desks? Narutolovehinata5 tccsdnew 10:29, 10 February 2017 (UTC)[reply]

This is exactly whay the question has the phrase "or something like it" and there is a note under the template reminding versions that it is a rough draft. The formatting is not the point, whether we should do something like this at all is. Beeblebrox (talk) 19:24, 10 February 2017 (UTC)[reply]
  • Oppose. This is 100% the OPPOSITE of what the disclaimer should say. Providing reliable sources should be the main function of the ref desk. I'd support a disclaimer that literally said the exact opposite of this one before I supported this. Hell no. --Jayron32 16:34, 10 February 2017 (UTC)[reply]
Yeah, but this isn't dictating the rules, it is reflecting how the refdesk actually functions. Of course they should always provide sources, but in practice it isn't done a lot of the time. Beeblebrox (talk) 19:23, 10 February 2017 (UTC)[reply]
No, the ref desk DOES function that way. There's a few people who don't get it, but by and large, it works just fine. --Jayron32 01:25, 12 February 2017 (UTC)[reply]
  • Oppose first point as per Jayron. References sometimes have to be held to a lower standard in order to provide an answer to the question, but we don't want to encourage the notion that references are not needed. ←Baseball Bugs What's up, Doc? carrots→ 17:02, 10 February 2017 (UTC)[reply]
  • The key question is who is the target for this disclaimer? If it is readers, then I think there is one key point to make: responses are the viewpoints of individual editors and do not reflect expert or consensus views. Everything else readers can infer from context. (For example, you don't have to tell readers that reliable sources are or aren't being cited; they can see for themselves.) If the intent is to dissuade other editors from wasting time trying to change the existing environment at the Reference Desk, then I suggest having a FAQ list on the talk page. isaacl (talk) 20:54, 10 February 2017 (UTC)[reply]
It's the first one, the intent is not to discourage anyone but to inform them that they are in an area that does not work like the rest of Wikiepdia. Beeblebrox (talk) 20:47, 15 February 2017 (UTC)[reply]
In that case, then I believe a single sentence with the message I stated is enough. The critical difference is whereas Wikipedia articles are copy edited to, in theory, converge towards a consensus view, individual responses at the reference desk are not. isaacl (talk) 16:52, 17 February 2017 (UTC)[reply]
  • Oppose: The way it appears, the notice gives editors far too much leeway in regards to crucial Wikipedia policies, especially when it comes to reliable sources. Such a policy should never be disregarded on Wikipedia. Ever. Blurp92 (talk) 05:58, 17 February 2017 (UTC)[reply]
That's just the way the refdesk works, and the regulars there are extremely resistant to any changes, that's rather the whole point here. Beeblebrox (talk) 06:41, 17 February 2017 (UTC)[reply]
  • Oppose Overkill, to say the least. All we need is a single line:
"Answers may not agree with each other. They are provided by various editors with various resources and opinions, and are not official opinions of Wikipedia."
This would handle everything without going into the "discussion forum" siding. Collect (talk) 14:48, 21 February 2017 (UTC)[reply]

Medical/legal questions tag

Should the following tag, or something like it be added to all questions that could be construed as requesting medical or legal advice? Note that this does not disallow the question, it merely aims to clarify the relative weight that any answers should be given. User:Beeblebrox/sandbox 4 (Please keep in mind that this is just a rough draft, and not even in template namespace, this is just to give the general idea of what such a template might be, formatting and specific language can always be adjusted later.)

Discussion of Mediacl/legal questions tag

  • support as proposer. This will have no effect whatsoever on any users ability ask such a question, or to go ahead and provide answers to such questions, the only purpose is to curtail infighting among refdesk regulars on these subjects and clarify the relative weight that should be given to any such questions. Beeblebrox (talk) 00:23, 10 February 2017 (UTC)[reply]
  • Oppose. If you love guidelines and policies so much, might I suggest going over WP:POINT? Seldom have I seen a "point" made with as big an exclamation as this! And in general, the fact that most Refdesk regulars believe that medical and legal questions are allowable is because asking the question or covering the topic is not advice. It is not a medical diagnosis or treatment to say a black widow bite is poisonous, or even to post sources claiming it's not that poisonous. Nor to say that cigarettes are bad, or even to post about alleged health benefits to be had from nicotine. And the open-ended nature of discussion on the Refdesk matches the open-ended nature of discussion on countless other pages on Wikipedia - the Village Pumps, Jimbo's page, the WikiProjects and so on. In other words, your policy objections have been heard and WP:CONSENSUS is against them. Wnt (talk) 01:30, 10 February 2017 (UTC)[reply]
You seem to be reading a lot into this that just isn't there. I am not making a policy objection, I am saying let's go ahead and accept the fact that the refdesk does not follow certain policies, allow that continue as it has for years, but just be sure to let people know the difference. You seem to take any attempt to say anything at all about the refdesk as personal affront and respond rather dramatically, I would again suggest (as I did way back during the 2013 discussion of actual reforms of the refdesk) that if you tone it down others might be more receptive to what you have to say. And I went out of my way to make it clear that these templates are rough drafts and the formatting is not the point of the discussion. They are both based off of {{No medical advice}} as a starting point, I would have no objection to something less obnoxious. Beeblebrox (talk) 02:18, 10 February 2017 (UTC)[reply]
@Beeblebrox: I accept the fact that you think the Refdesk doesn't follow certain policies/guidelines that it actually does, and in some cases you think others that don't apply to it ought to. But are you going to put a disclaimer on every Talk: page that it doesn't follow article guidelines, a disclaimer on every ITN item that it doesn't follow FAC guidelines? Policies that don't apply ... simply don't apply. Wnt (talk) 14:16, 10 February 2017 (UTC)[reply]
Please note that the actual question is if we should use this tag or something like it and there is a note beneath it stating that it is a rough draft. The purpose of this discussion is to decide if we should use a tag, the formatting is 100% open to be changed to whatever is more agreeable, I based both of these off of {{No medical advice}} just as a starting point. Beeblebrox (talk) 19:28, 10 February 2017 (UTC)[reply]
I did note that. A small notice would be "tolerable" and "crap up the page". You can count that as somewhere in the range of "neutral" to "passive oppose"... on the condition that the monster is trimmed 80% or more in square inches. Alsee (talk) 03:14, 11 February 2017 (UTC)[reply]
  • Oppose as a question tag, support as an edit notice. Maybe something smaller and much less obtrusive, albeit still noticeable, for individual questions. Ks0stm (T•C•G•E) 19:39, 10 February 2017 (UTC)[reply]
  • Oppose per current size and content. I am concerned that both the banner and the explanation of the banner contradict themselves. The banner directly states that no medical / legal advice should be given, then goes on to stay that the advice given should be taken with a grain of salt (as the proposer states"This will have no effect whatsoever on any users ability ask such a question, or to go ahead and provide answers to such questions") In additionI do not think a large warning template designed "only to curtail infighting amongst regulars" is an effective approach. I suggest developing a policy or guideline statement with consensus.--Tom (LT) (talk) 03:34, 11 February 2017 (UTC)[reply]
  • Oppose the current form and content (If I'm allowed as an IP User), though some milder advisory would be in order.
Overall, I would prefer that we avoid just adding even more advisory notices to the heads of the RefDesk pages – it would only make it even more likely that they'll be ignored by OPs. ObPersonal: I experienced a similar effect at an Atomic Weapons Establishment some years ago, where piling on ever more overlapping safety regulations led to an increase in accidents and near misses. The more effective approach was to prune them back to the economical and clear minimum required: in our case that minimum should, I agree, contain the fact that the answers are provided by quasi-librarians, not topic experts, and are not endorsed by Wikipedia as an entity.
I think also there is an as-yet-unexamined problem with the "no medical or legal advice" policy. People are naturally curious about physiological topics, and sometimes that curiosity is prompted by an observation of a likely harmless phenomenon on or in their own body, which they have no actual concern about, and for which the advice "consult your physician" would be egregious – allowable but expensive in some countries (such as the USA), cheap/free but arousing of official ire in others (such as the UK).
However, I see many queries which are actually seeking physiological/medical (or legal) information being hatted or removed on the grounds of our not giving medical, etc., advice. Sometimes this might have been avoided if the query had been, quite legitimately, worded in a less self-referential way (younger people tend to personalise queries even when not about themselves – "You know that thing where you get a . . . ."), sometimes even seemingly legitimate queries for non-personally relevant information are hatted or removed by what seem to me to be over-zealous editors, and the standards seem not to be consistently applied even by the same individuals.
I do however agree that some sloppy and detrimental practices have been allowed to proliferate on the RefDesks, some but not all attributable to a few particular Editors, (and of some of which I myself am guilty); I would support more rigorous application of whatever (laws rules) guidelines the community can come to agreement on. {The poster formerly known as 87.81.230.195} 90.203.118.169 (talk) 22:20, 11 February 2017 (UTC)[reply]
  • Support - the tag is a bit big but I support it in principle. DrStrauss talk 08:22, 13 February 2017 (UTC)[reply]
  • Support - If Beeblebrox thinks a tag or something is necessary, then it most likely is. However, in its present suggested form it's too wordy. It's been proven time and time again that Internet users DO NOT READ THE INSTRUCTIONS. Classic examples are the edit notices here (yes, go on click it for once), where up to three people a week blatantly disregard it, and on the RfA transclusion page; with the best will in the world such instructions rarely work but we we have to do something. Anyone who has ever run an online store will also know how frustrating it is when 30 people a day call to ask a price when the prices are staring them in the face - and unlike Wikipedia, online store software is designed by marketing professionals. Beeblebrox is following our Wikipedia tradition of verbosity in respect of that tradition, where a short, sharp headline (something he knows about) would suffice, such as: STOP:(Stop hand icon) Wikikipedia is an encyclopedia. We do not give legal or medical advice. If you ask, your question will probably be ignored. Kudpung กุดผึ้ง (talk) 23:19, 14 February 2017 (UTC)[reply]
  • Oppose – way too big. A hatnote just below the heading with a link to WP's medical disclaimer page would suffice. The Transhumanist 10:25, 21 February 2017 (UTC)[reply]
  • Oppose Overkill. Also note that mobile devices will end up showing some such messages as taking up a full screen :). Collect (talk) 14:50, 21 February 2017 (UTC)[reply]
  • Oppose more disclaimers are a perennial proposal, a slippery slope, and may create the risks they try to avoid. I would support creation of standard optional "We do not give advice" templates, for the purposes of rapid answering (or non-answering to be more precise) such questions. All the best: Rich Farmbrough, 11:56, 23 February 2017 (UTC).[reply]

Backlog of unpatrolled files

Request an autopatrolled group specific to files

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]

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]

Rename "File mover" usergroup to "File handler" and grant ability to patrol files (only)

Also to deal with the backlog of unpatrolled files. Patrolling files and patrolling new articles requires completely different abilities, editors with the file mover usergroup are knowledgeable about files and should be allowed to patrol files even if they aren't new page patrollers, and vice versa new page patrollers weren't vetted to patrol files. Hence I suggest to Nikkimariarename the file mover usergroup to file handler and grant them the ability to patrol files, while new pages patrollers would no longer be able to patrol files. Cenarium (talk) 21:18, 11 February 2017 (UTC)[reply]

I think this is getting too complicated - if someone just wants to patrol files, let them? The existing group can be used for that - if they are making bad patrols, it can be removed. — xaosflux Talk 13:05, 13 February 2017 (UTC)[reply]
I suppose this may make sense, but would users be given a newsletter and asked if they wish to get the new rights immediately, much like the grandfathering of the NPP rights? Because if not a massive backlog could ensue. -- Iazyges Consermonor Opus meum 13:10, 13 February 2017 (UTC)[reply]
Why not having two separate rights? Renaming a file is enough. Changing to "handler" would make things more complicated. Also, "file handler" is a little too new and needs to be practiced more. George Ho (talk) 21:07, 13 February 2017 (UTC)[reply]
We don't bundle page mover and new page patrol, so there's precedent for making them separate. But part of me says we're unbundling a bit too much. The suggested "file patrol" and the above "file autopatrolled" should be one right. Unlike article patrol where one can be good at identifying good articles/cleanup tagging but not that good at writing content from scratch, someone familiar with the file licensing polices should be easily able to apply them to their own uploads. — Train2104 (t • c) 06:08, 16 February 2017 (UTC)[reply]
Echoing Xaosflux: Users who wish to patrol pages and demonstrate and understanding of what constitutes an appropriate page should be granted the new page reviewer user right. The right can be removed If they demonstrate a pattern of patrolling inappropriate pages. — Godsy (TALKCONT) 05:56, 25 February 2017 (UTC)[reply]

Let's ask Microsoft to give their encyclopedias to the public domain

@Ocaasi, Nikkimaria, and Samwalton9:

According to the Funk & Wagnalls article:

After failing to purchase rights to use of the text of the Encyclopaedia Britannica and World Book Encyclopedia for its Encarta digital encyclopedia, Microsoft reluctantly used under license the text of Funk & Wagnalls encyclopedia for the first editions of their encyclopedia. This licensed text was gradually replaced over the following years with content Microsoft created itself.[1]

As long as all the Funk & Wagnalls material was replaced, that might not be a problem.

But MS owns more than just Encarta. According to the Encarta article:

In the late 1990s, Microsoft added content from Collier's Encyclopedia and New Merit Scholar's Encyclopedia from Macmillan into Encarta after purchasing them.

(The Funk & Wagnalls copyright issue would not pertain to those.)

So, let's ask them to release Encarta, Collier's, and New Merit Scholar's.

Or, if they were to donate them all to the Wikimedia foundation, maybe they could take a deduction from their taxes.

So, what's the next step? The Transhumanist 08:25, 12 February 2017 (UTC)[reply]

Don't ask them? Do we really want editors copying material from encyclopedias, even if attributed? Usually the material is unsourced and is often out of date or presents only one pov. Doug Weller talk 17:06, 15 February 2017 (UTC)[reply]
Well but OP is not asking editors to copy material from these entities. I mean you could object to any source on the basis of "well, editors are just going to copy from newspapers and magazines and books, so let's not use those as sources". You can certainly pick individual facts etc. from an encyclopedia article to meld into your Wikipedia article along with material based on other sources.
And yeah the material is unsourced (and is it even? Britannica gives sources IIRC, are you sure these other entities don't?) but I mean a lot of things are unsourced. If I look at Playbill or whatever they don't give a source. If they say a play opened on September 13 1955 I'm not like "Well, how do they know that? What's their source? I can't use this". They have a reputation for being correct about stuff like that and fixing it if it's wrong.
I mean, maybe Encarta was not rigorously fact-checked and they just wrote down stuff they they overheard on the subway or whatever, and maybe ditto Funk & Wagnalls and Collier's and New Merit Scholar's. If that's the case, fine. Is it? Or did these entities have good fact-checking operations? Herostratus (talk) 21:20, 17 February 2017 (UTC)[reply]
Next step: Look at some sample Collier's content and see if there's anything there that we don't have. All the best: Rich Farmbrough, 12:00, 23 February 2017 (UTC).[reply]

References

  1. ^ Randall E. Stross, The Microsoft Way: The Real Story of How the Company Outsmarts its Competition (Reading: Addison-Wesley, 1996), pp. 81f, 91f

Page creation restrictions

Hi, I've been doing a bit of new page patrolling recently and for four days following the last newsletter the backlog was cut by 1,000 however it is now steadily growing again and within a week will have surpassed its previous size. As a large proportion of new articles either have dubious notability or require substantial cleanup, I suggest that page creation be temporarily restricted to extended confirmed users until the backlog is down to a manageable size. This would allow important, high quality articles to be created whilst the new page reviewers work on slashing the backlog without having more added. During this time, users not meeting the necessary qualifications can apply for their article to be created at AfC. Thoughts? Kind regards, DrStrauss talk 08:27, 13 February 2017 (UTC)[reply]

To clarify, only extended confirmed editors would be able to create articles in the mainspace, whilst anonymous to confirmed would need to create in the draftspace? -- Samtar talk · contribs 08:38, 13 February 2017 (UTC)[reply]
@Samtar: as I understand it, IPs can't create articles anyway but if I am mistaken then yes, you are correct. If not then restriction on IPs remains the same. DrStrauss talk 08:57, 13 February 2017 (UTC)[reply]
Well then I entirely support this - how long would you suggest this restriction be applied? -- Samtar talk · contribs 09:03, 13 February 2017 (UTC)[reply]

The WMF have said they won't allow anything like this, even on a temporary basis. – Finnusertop (talk ⋅ contribs) 09:09, 13 February 2017 (UTC) [reply]

Awh damn -- Samtar talk · contribs 09:13, 13 February 2017 (UTC)[reply]
@Samtar and Finnusertop: that's a shame but if the backlog grows beyond say 25,000 the WMF probably have to change its tune. DrStrauss talk 09:25, 13 February 2017 (UTC)[reply]
No, DrStrauss, they don't have to. And I doubt they will. From their point of view, Wikipedia's success is about web traffic, and explosive increase in the number of articles serves that purpose far better than article quality does. – Finnusertop (talk ⋅ contribs) 09:33, 13 February 2017 (UTC)[reply]
Hmph. Better crack on with reviewing then! DrStrauss talk 10:50, 13 February 2017 (UTC)[reply]
I've looked at that thread a few times over the years and it seems filled with the developer overreach that was not untypical at that time. Perhaps it's time to push the issue forward again, as attitudes may have changed, with certain people having left the organization. --NeilN talk to me 18:11, 14 February 2017 (UTC)[reply]
@NeilN: If the community still wishes to impose an autoconfirmed requirement for creating articles, this can be done with the Mediawiki:Titleblacklist and with no need for WMF involvement. This would look and function for the affected users very similarly to page protection. BethNaught (talk) 18:58, 14 February 2017 (UTC)[reply]
Thanks BethNaught. Do you know of any discussions surrounding this? --NeilN talk to me 19:01, 14 February 2017 (UTC)[reply]
There has been a small amount of discussion at Wikipedia talk:The future of NPP and AfC/To do#ACTRIAL and Wikipedia talk:The future of NPP and AfC#Some ACTRIAL code, though nothing large and public that I am aware of. Unfortunately people seem to know about the edit filters more than the blacklist, so discussion has focussed on what is a worse solution, because the edit filter only stops your page creation on the point of saving, but (for desktop users only—there is a bug in mobile) the blacklist stops you from starting to edit at all. BethNaught (talk) 19:12, 14 February 2017 (UTC)[reply]
@BethNaught, Samtar, and NeilN: considering the strong consensus and time passed since the last proposal, do you think we could try to push for WP:ACTRIAL to be implemented? Regards, DrStrauss talk 19:20, 14 February 2017 (UTC)[reply]
I think ACTRIAL supporters exaggerate the strength of the consensus, if you read the original closes. In any case, now five years have passed, I think a new RfC should be required. I hadn't joined Wikipedia when the original debate occurred and I don't necessary support it; I simply want to make sure that if the community consensus still exists then it is implemented in the best way. BethNaught (talk) 19:27, 14 February 2017 (UTC)[reply]
@BethNaught: should I start the RfC? DrStrauss talk 19:30, 14 February 2017 (UTC)[reply]
That's your prerogative, but I would advise you not to do so, soon at any rate. If you botch the RfC (insufficiently convincing opening arguments, malformed questions etc.) you would set back your cause possibly by a long amount of time. You would do better to start an initial discussion with other interested parties such as at the NPP work group, in order to determine the best course of action and polish an RfC before posting it. That said, there has been discussion of this before (linked above) at that group and it fizzled out, and I don't know if there are off-wiki discussions happening about it. BethNaught (talk) 19:34, 14 February 2017 (UTC)[reply]
I agree with Beth in that a new RFC should be held to evaluate the community's feelings on the matter, five years on. The RFC should be clearly worded, with assistance from editors experienced in the matter. --NeilN talk to me 19:36, 14 February 2017 (UTC)[reply]
@NeilN: shall I create a subpage in my userspace and notify the new page patrol noticeboard about it so they can help as a draft? DrStrauss talk 19:38, 14 February 2017 (UTC)[reply]
Did you see the last thread at Wikipedia_talk:The_future_of_NPP_and_AfC/To_do#ACTRIAL? If it was me, I would point editors to this topic (the one we're commenting in) and see what the response is like. --NeilN talk to me 19:50, 14 February 2017 (UTC)[reply]
Be sure to ask Kudpung but yes, I recommend creating a subspace draft to draft a good write-up before formally creating the RfC. After five years and significant strain, a new RfC is appropriate. Chris Troutman (talk) 19:53, 14 February 2017 (UTC)[reply]
If the Foundation is opposed to such a throttle, then even if it can be implemented without their help, they might intervene. It might be better to discuss ways to address the backlog rather than throttling its growth.--S Philbrick(Talk) 21:33, 14 February 2017 (UTC)[reply]
Has the Foundation been approached lately about this? As I alluded to earlier, we might get a different response as certain people have left. --NeilN talk to me 21:59, 14 February 2017 (UTC)[reply]
@Sphilbrick: the growth needs to be throttled to effectively approach it. New pages are coming in at a larger rate than we can review them so "throttling" it is a necessary step to effectively addressing it. Thanks. DrStrauss talk 23:10, 14 February 2017 (UTC)[reply]

(edit conflict) A new RfC may be a good idea but it will need to be well crafted and managed to keep it from running off the rails and either devolving into a chaos of competing proposals or simply crashing because it is not properly formed. As to discussions with the Foundation my thought is to establish what the community wants to do first. Before we have a consensus to work from "in principle" discussions are less than useless - likely becoming stuck on things which may not be issues and missing issues that may be red lines later. Also, if there are no software changes requested to implement ACTRIAL-2 there is really no handle for the Foundation to use to thwart community consensus without reaching further into the governing of en.wp than they may find comfortable or politic. Jbh Talk 23:15, 14 February 2017 (UTC) [reply]

As Sphilbrick notes, the Foundation might intervene if they don't want any kind of throttle. Better to feel them out first rather holding another RFC that will be ignored or thwarted. If they have no comment or say we are free to use existing software features the way we see fit that will signal to editors that their time won't be wasted again. --NeilN talk to me 23:24, 14 February 2017 (UTC)[reply]
The argument against that is that an answer to a hypothetical RfC vs. an answer to another massive 500+ person RfC after the fact could be vastly different, and depending on the reasoning for the close could also impact it to. TonyBallioni (talk) 23:28, 14 February 2017 (UTC)[reply]
Yes. Entering into discussions based on hypotheticals is almost never a good idea if you want to make a change. It makes it very easy for any obstructionist to throw up equally hypothetical problems, conditions and red lines which kill the proposal before it is actually made. When reduced to their basics a preliminary discussion can only have three outcomes;
  1. I can't say anything until you give me a concrete proposal so hold a RfC and get back to me.
  2. Sure. The community is self governing.
  3. No we won't allow it.
If the answer were #3 my, rather firm, guess is that we would still want to run the RfC much like we did with Flow and Gather (both instances of where Foundation and community disagreed and the community "won") but we would be starting from a position where someone has already staked their ego/authority/self-worth/whatever on No. That would make further discussions much more difficult and high stakes. Better to know if there is consensus for the change or not before lines get drawn. Jbh Talk 23:59, 14 February 2017 (UTC)[reply]
I'm contributing as someone who admittedly has not been part of the solution, but this fits into a theme that I hope to write up separately – a number of areas where the existing mechanisms are not adequate. However, while I obviously do not speak for the Foundation, and know that they try to stay hands-ff from internal editorial decisions, the very possibility that the community might conclude that Wikipedia is no longer the encyclopedia that anyone can edit strikes me as a big deal, not a minor editorial decision. I'm sympathetic to growing backlogs (Can I share my frustration at growing OTRS and copyright infringement backlogs?) but I think throttling is the last step not the first step, and I don't see much evidence that robust attempts to either recruit new reviewers, educate editors or improve triage processes have all been exhausted.--S Philbrick(Talk) 00:11, 15 February 2017 (UTC)[reply]
  • @TonyBallioni, NeilN, Sphilbrick, Jbhunley, and Chris troutman:, et al: I'm glad to see that people still believe that ACTRIAL is needed. I belive it's now needed more than ever. Our mistake at the time was asking the WMF to tweak the software to implement WP:ACTRIAL. None of us having knowledge of computer programming languages realised that it could easily have been done by local administrator access using edit filters and/or js. That RfC was one of the largest in Wikipedia history - if not the largest, and it closed with an overwhelming consensus. We have since delved into history and found instances where the WMF has greatly throttled the creation of new pages without even asking the local communities, so their 'argument' against ACTRIAL was pure balloney. What more do you folks want? (Perhaps you should all also read the Bugzilla fiasco, and prior to that, the entire two ACTRIAL debates before deciding anything here}. The venue for any future discussion has been created at WP:The future of NPP and AfC which I implore people to read thoroughly, including the new mini poll on ACTRIAL, and join if they want to be active on this front. Let's get a proper mini consensus on what to do before we go ahead, burn our bridges and train wreck again our possibilities like we did by asking the WMF devs to technically implement ACTRIAL. Kudpung กุดผึ้ง (talk) 00:13, 15 February 2017 (UTC)[reply]
    Agree on that initial approach - measuring community consensus for what is wanted is much more important then the how - we've come up with creative fixes before and can again. WP:CXT is a somewhat recent example of the community shutting down a tiny subset of unwanted new article creation - it didn't need WMF to change their software. — xaosflux Talk 00:20, 15 February 2017 (UTC)[reply]
I'd like to see more clarification of the problem statement. A large backlog is not a statement of a problem, it is an observation of a symptom of a problem. Is NPP mindnumbing? If so can it be improved or do we need better ways to thinks those who do it? Is the backlog large because gifted editors are flocking to Wikipedia to write sparkling prose, or are is it large because we provide little guidance and editors are supplying crap? Do we even have a triage process? --S Philbrick(Talk) 00:34, 15 February 2017 (UTC)[reply]
Sphilbrick The best way to understand the problem is to spend an hour a day for a week doing new page patrol from the special:newpagesfeed selecting pages by new users as your chosen filter. That would immediately answer all your questions as clearly as is humanly possible. Is it large because we provide little guidance and editors are supplying crap? Yes, and due to the factthat the WMF refuses to prioritise the work they began in 2012 to address it. No one currently has a closer lobby to the Foundation on these issues than I have and I've recently had an hour long Skype conference withe the VP of the WMF (and other staff) who has now yet again shunted the solutions into a holding bay. Kudpung กุดผึ้ง (talk) 00:52, 15 February 2017 (UTC)[reply]
There's something fundamentally wrong if I am expected to spend seven hours before asking a question. Sorry, the OTRS backlog is far too large.--S Philbrick(Talk) 01:30, 15 February 2017 (UTC)[reply]
  • Extendedconfirmed seems like a big jump to me. I'm not against trying that for a limited period of time, but let's try just autoconfirmed first. I think we'll be surprised just how much crap that cuts out. I can easily write an abuse filter to warn then disallow on page creations by non-confirmed editors, with a warning message that directs them to copy/paste the text of their article into a draft and submit it through WP:AFC. It might be a trickier proposition to convince anyone to flip it on without another round of consensus-getting; the action would certainly face a lot of scrutiny. ~ Rob13Talk 00:22, 15 February 2017 (UTC)[reply]
No one, AFAICS, is seriously asking for Extendedconfirmed. Confirmed was what ACTRIAL demanded and it would put an end to 80% of the junk that arrives every day and which patrollers can't cope with for lack of a) numbers, and b) competency, c) interest. Kudpung กุดผึ้ง (talk) 00:52, 15 February 2017 (UTC)[reply]
  • I will never get why we don't require autoconfirmed before crating an article. It's such a low threshold. I tried to get this done several years ago but it didn't fly. (can't remember now where that discussion was but if I find it I'll add a link here) Beeblebrox (talk) 01:00, 15 February 2017 (UTC)[reply]
Found it Wikipedia talk:User access levels/RFC on autoconfirmed status required to create an article. That was quite a while ago, maybe time to revisit. Beeblebrox (talk) 01:05, 15 February 2017 (UTC)[reply]
I would approach it differently, although I'll start by saying our approach is all wrong. Our approach is hardly different than one designed to create failure. If a friend remarked that they wanted to take up the piano, and they were going to start with Liszt, would you encourage them to go for it? If someone said they wanted to take up running and they were going to start with a marathon, what advice would you give them? If they had never run for office and they decided to run for President...OK, bad example:) But seriously, we often say go for it. Instead of providing good advice like urging them to start with copy edits. I don't think auto-confirmed is enough, but rather than create a rule, I'd prefer to create incentives.
What if we prioritized our reviews, other than chronological order? What if editors with a few thousand edits could reviewed earlier than editors with a single edit? And we publicized this, explaining that someone with a single edit, trying to write a new article is setting themselves up for failure. Maybe they can do it, some can, but the review will take place after we get to people who are going about it the right way.
I haven't worked on NPP formally in some time but I look at hundreds of articles every week, people write emails to Wikimedia, which get handled in our OTRS system and many are brand-new editors wondering why their new article submission isn't going anywhere. It is sad to see how many people, who haven't tried a single edit in their life, think they can master our house style and Wikimarkup with no experience. We need to find a better approach, and throttling is not the answer.--S Philbrick(Talk) 02:15, 15 February 2017 (UTC)[reply]
The issue here is with spam (or self-promoters if we are dealing with BLPs), which is a significant portion of what we deal with everyday over at NPP. Spammers really don't care about building up an encyclopedia, no matter what you tell them. The Media-Wiki software releases unpatrolled pages to Google after 30 days, so by deprioritizing the accounts that spam and other problematic articles are likely to come from, you actually further incentivize the creation of the articles with new accounts. TonyBallioni (talk) 02:24, 15 February 2017 (UTC)[reply]
  • Oppose -- adjust the intensity of your review to fit the workload. I don't claim to be an expert on all this, so correct me if I'm wrong on either of these points:
1) New pages patrollers have been made artificially scarce by treating it as a user right to be requested specially, which is held currently by 346 people, plus admins.
2) New pages patrolling has been made exceptionally daunting by requiring the patrollers to go through a veritable Cape Canaveral checklist. What's more, the rare permission to do patrolling can be revoked if they don't go through all of it carefully.
Now what I see here looks a lot like we have in every industry in the real "capitalist" world, where there is always some racket of people who allow themselves and nobody else to do any given kind of work. You want, say, an interior design done, you're supposed to go to a licensed interior designer, and if you want to do it, you are supposed to pay the right people to take the right courses and get the right experience to be allowed take the right test to be allowed to work.
In the real world, the goal is for a better caste of people to keep the money away from their inferiors; on Wikipedia, new pages patrolling is a kind of stepping stone to stuff like adminning, so it's a career move of sorts. But the impact is still an artificial scarcity. Naturally, the way proposed to fix that is not to recruit far and wide for new NPPs and make the process simpler, but instead, to choke down on the opportunities to make a new article in the first place.
Now I may be exaggerating the crassness of motive here out of aggravation; maybe some people really think they are "just being careful" having this system. But it's ridiculous. These new articles are hopefully going to expand ten-fold, hundred-fold, with new regular edits after this is all over. All those other edits bringing in other stuff are going to be scrutinized only by the regular old Wikipedia way of having ordinary people look at them and see if they notice anything out of place. When I look at Special:NewPages I don't see a lot of oh-my-gods there, but basically a torrent of solid honest content not in urgent need of quibbles. Even if I restrict it to visualeditor edits, the solid wall of speedy deletes I see includes a lot of articles that are pretty well written and referenced, and it's by no means obvious to me that all those companies (there are a lot of them in this subset) need to be deleted. Even if some company slips through a glowing paragraph about their business until the next time a Wikipedian runs across it, it's not the end of the world - a little amateur POV pushing might even help vaccinate a reader against the pros. People shouldn't trust Wikipedia too much; doing so makes it untrustworthy. So I feel there's no real need for extraordinary competence and good-article like review for the first few drafts of a new article. We just need someone who has been around the block a few times, or a couple of people, to take a quick sniff and see if it stinks, same as any other Wikipedia edit. And if the process becomes that informal, it should be far less trouble to review a flood of new articles. Wnt (talk) 02:44, 15 February 2017 (UTC)[reply]
I found some statistics that have been compiled here, but I was wondering if there are any statistics that are more recent? Also, if this does get implemented, it might be a good idea to do a trial first, and then have the statistics from there get discussed to see if it should be implemented permanently (subject to community consensus, of course). RileyBugzYell at me | Edits 17:48, 19 February 2017 (UTC)[reply]
It might also be a good idea to see if there was a spike in deleted pages by new editors after the IP page creation ban thing. If there was, then that would most likely mean that there would be a spike in autoconfirmed editors creating spam pages. And since those editors would be autoconfirmed, they would also be able to edit semi-protected pages. Basically, this proposal could be the beginning of an influx of single-purpose accounts getting autoconfirmed status, allowing them to edit semi-protected pages. All in all, that is not a good thing. Anyways, somebody should look into this. RileyBugzYell at me | Edits 18:22, 19 February 2017 (UTC)[reply]

Proposal

Hey all, what do you think to this draft proposal? DrStrauss talk 11:20, 15 February 2017 (UTC)[reply]

For one it only addresses the issue from the perspective of NPP. While that is a big portion of it there is also a huge, and from the viewpoint of most editors, more important issue of editor training and retention. For instance one of the most common reasons to oppose ACTRIAL is the idea that if someone can not create an article immediately they will be discouraged and not hang around. The counter argument is that having one's first article quickly deleted is more likely to be what sends people away. The point of ACTRIAL is to get new editors to work through AFC where they can get feedback and instruction so their articles do not get speedy-tagged right off the bat. A properly set up RfC will have metrics to see which of these is more accurate.

From a harm reduction point of view it requires spammers to invest a bit more effort and should cause a reduction in 'one-edit-wonder' promotional/paid articles which make up a massive amount of the backlog. Again a well formed RfC will establish metrics to see if this is in fact true. If you read through the prior discussions on this topic you will see several things like these. Reviewing new pages is a vastly important maintinance task but it is not the only thing affected by ACTRIAL and presenting ACTRIAL solely from a NPP perspective without addressing other points of view - as well as the "Anyone can edit" values/ideology of most of our editors will fail and fail badly. Beyond that there is a particular skill in organizing the management of a large RfC and without a proper management plan even the best phrased major RfC will fail to demonstrate consensus because the discussion fragments into dozens of "Support but...", "Oppose but..."', and the niche alternate proposals that people then throw in. The bigger the proposed change the more preparation needs to go into a RfC - this is a very big change so... lots more preparation. Jbh Talk 15:01, 15 February 2017 (UTC)[reply]

I think the message is clear that this is not the time for a unilateral independent RfC for ACTRIAL. As I've said elsewhere,teamwork is the essence of making a good RfC and that's why The Blade of the Northern Lights, Scottywong, and I achieved such a massive participation and a clear consensus. What everyone is ignoring is that the limitation to confirmed users was ony half the proposed solution. The other half was what we had designed to help those users who were still in such a rush they would not / could not wait 4 days for their spam articles and garage bands to go live. A lot of work went into that proposal including meetings and conferences. Nothing of the sort has been done here. Who, for example is going to notify everyone of the 500 former participants of the new RfC? That's a task that needs sharing for starters. Let's also not forget that ACTRIAL is a TRIAL. It was not a new policy set in stone and it was written into the proposal that it would be reverted if the stats proved after six months that it was having a detrimental effect on the encyclopedia. The WMF already set its own precedent in 2006 for throttling the creation of new pages, thus proving that the project is organic and need to keep pace with its growth and evolution. They conveniently forgot that when they chucked out ACTRIAL. xaosflux hit the nail on the head when he agreed that we should first decide what to do before we rush headlomg into things. That said, I say don't bother with an RfC at at all, try the implementation, and see what happens. Kudpung กุดผึ้ง (talk) 16:36, 15 February 2017 (UTC)[reply]
@Kudpung: - fair enough, I suppose time is needed. If we bypass RfC, who will implement it via the blacklist. And what would that process entail? Thanks. DrStrauss talk 16:23, 16 February 2017 (UTC)[reply]
Again, DrStrauss, the answers to all those questions are at WP:The future of NPP and AfC - you have some reading to do. Kudpung กุดผึ้ง (talk) 18:43, 16 February 2017 (UTC)[reply]

Proposal to solve problem of process subpages

I was drafting this in my userspace pending advice on the feasibility of this proposal, but I figured going ahead and proposing it would be a better way to invte constructive criticism.

I have noticed something of a problem in the last few weeks. A number of process pages (WP:RM[7] and WP:GAR[8] among them) depend on transcluded subpages. The main process pages have hundreds of watchers, but the subpages have almost no one watching them. As a result, unilateral changes can go months or years without being noticed, or at least without being questioned. Given that the instructions included in these process subpages tend to be taken as authoritative, care should be taken that they are in line our core policies.

I am sure these unilateral changes were made in good faith, but since such changes should not generally be made without either prior community consensus or some way of determining that a significant portion of the community tacitly approved of the changes, I would like to propose either one of the following:

  1. Permanent full protection for all process subpages;
  2. Merging process subpages into their respective main process pages.

The former would prevent the pages from being edited by non-admins without prior discussion/consensus, while the latter would at least mean that the 1,580 editors watching RM and the 251 editors watching GAR would be notified when changes are made.

Hijiri 88 (聖やや) 22:32, 20 February 2017 (UTC)[reply]

So, am I being shunned? Is my proposal so utterly outrageous that no one will even comment? Hijiri 88 (聖やや) 03:06, 22 February 2017 (UTC)[reply]
The utterly outrageous ones get quick negative replies - see, for example, #Create draft namespace redirects which is present on the page here right now. The ones with no replies are typicly the ones which few users care about one way or the other - see Wikipedia:Avoid Parkinson's Bicycle Shed Effect. עוד מישהו Od Mishehu 13:53, 23 February 2017 (UTC)[reply]

Elections for New Page Patrol/New Page Review coordinators

Voting for coordinators has now begun HERE and will continue through/to 23:59 UTC Monday 06 March. New Page Review and its Page Curation is a core MediaWiki extension. The process of expertly vetting all new articles is a critical issue needing a couple of 'go to' people. The coordinators will do their best for for the advancement of the improvement of NPP and generally keep tracks on the development of those things. Coordinators have no additional or special user benefits, but they will try to keep discussions in the right places and advance negotiations with the WMF.
Please be sure to vote. Any registered, confirmed editor can vote. Nominations are now closed.Kudpung กุดผึ้ง (talk) 02:02, 22 February 2017 (UTC)[reply]

Make certain warning templates visible on mobile (requesting formal close)

If an article is up for AfD and flagged as a possible hoax with insufficient medical sourcing, any reader visiting that article on a computer is greeted by three large red and orange boxes at the top of the page, one with a cautionary stop sign. The reader is clearly told that what they're about to read may be a complete fabrication, contains inadequately referenced medical advice, and that an active, serious discussion has been raised about removing the article from Wikipedia. If a reader instead visits the same hoax medical article on their phone (and 45% of Wikimedia traffic is now from mobile devices), they just get two tiny grey words "Page issues" under the article title - the same ignorable alert they'd get if the article had an inconsistent footnote style or a missing taxobox - and the article is presented like any other.

I propose making {{hoax}}, {{medref}}, {{afd}} and all speedy templates visible on mobile, in whatever cut-down version is appropriate for mobile displays (perhaps just omitting the advice-to-editors "Please review the contents of the article and..." text in the templates' "fix=" fields). --McGeddon (talk) 10:03, 21 September 2016 (UTC)[reply]

iPhone 5S screen showing an ambox on an article
  • I've added a screenshot of how this would look when not doing too much. The problem for me here is that it is either all text, or no text, since the templates don't have 'short' versions or titles or anything... If someone has an idea how to fix that, that would be very interesting. —TheDJ (talk • contribs) 09:48, 23 September 2016 (UTC)[reply]
    {{ambox}} actually does have short-version functionality at Template:Ambox#issue_and_fix, although the AfD and prod templates don't use it (putting everything in "text="), and speedy deletions use mbox instead of ambox. It looks as if "issue=" is about right in terms of length ("approximately 10-20 words") and scope (we need to tell mobile readers there's an issue, but we can skip telling them how to fix it). If the deletion boxes can be wrangled, changing ambox from "template always invisible on mobile" to "template visible on mobile if hoax/medref/AfD/etc, fix always invisible on mobile" might be enough. --McGeddon (talk) 10:22, 23 September 2016 (UTC)[reply]
    Another solution would be to add a "mobile=" field to a/mbox, and change the templates so that if the mobile field is set to anything, it displays a small box on mobile, and otherwise remains invisible. This would be neater for not having to hardcode "if medref or hoax or..." in a/mbox - the "mobile=" field could either be a yes/no flag (the box displaying the text from "issue=" if yes), or could be free text if we'd rather write new, concise versions for mobile display. --McGeddon (talk) 10:40, 23 September 2016 (UTC)[reply]
  • Support; vital information that shouldn't be hidden from readers. Jc86035 (talk) Use {{re|Jc86035}}
    to reply to me     11:55, 23 September 2016 (UTC)[reply]
  • Strong support As James Allison alluded to, the absence of warning templates treats mobile users as second class citizens. We should not be treating 45% of our users as unworthy of warnings. In addition to the templates mentioned above, I would add all content warning templates, but if that's unpopular I'd suggest at the very least {{copypaste}}, {{POV}}, {{original research}}, {{POV-lead}}, {{contradict}}, {{contradict-other}}, {{contradict-other-multiple}}, {{misleading}}, all neutrality cleanup templates, all BLP sourcing problem templates, and {{disputed list}}. I'd also like the "discuss" link of {{dubious}} to show up. Hairy Dude (talk) 10:58, 24 September 2016 (UTC)[reply]
  • Support. I would especially love to see Hairy Dude's suggestion put into place. White Arabian Filly Neigh 21:24, 25 September 2016 (UTC)[reply]
  • support per nominators rationale--Ozzie10aaaa (talk) 17:58, 27 September 2016 (UTC)[reply]
  • Oppose obscuring the whole screen by making AFD templates visible (especially to logged-out people/readers) because "I don't think this meets our criteria for notability" (the most common reason for AFD) is not a "warning" about the content of the page in any sense.
    Support making {{hoax}} visible. Weak support for making all speedy templates visible, because some are relevant and it's probably too much hassle to decide which ones matter and then code them all separately.
    Oppose including {{medref}}. (I know; my anti-woo friends at WPMED aren't going to be pleased about this vote. But:) That tag is not a badge of shame or a "warning" to the reader. We have WP:No disclaimers in articles, not even for articles that have outdated (>5 years old) sources or that use less than ideal sources. (Typically, an article earns this tag when the sources are peer-reviewed academic papers about original studies or webpages from reputable(!) patient groups like the American Cancer Society, rather than review articles and med school textbooks. It's not a "dangerous content here!" tag. It's really a call to action for editors, and the goal is usually just to replace okay sources with ideal ones – often with no change to the actual text of the article. If you're not familiar with this, then look at Plague (disease), where it's been spammed into a history section (an area that WP:MEDRS doesn't apply to) and Blood cell, whose main fault is merely having too few citations total. WhatamIdoing (talk) 18:10, 27 September 2016 (UTC)[reply]
  • Support special short and expandable versions of these templates for mobile. We should not hide our problems, but actively tell people about them. —Kusma (t·c) 18:33, 27 September 2016 (UTC)[reply]
  • Oppose all but {{hoax}} which I support. It is hard to clean up an article on mobile so not really needed. Doc James (talk · contribs · email) 05:38, 28 September 2016 (UTC)[reply]
  • Support, under the conditions that the warning is important and directed towards non-editors. We're plastered by warnings all the time and having too many only causes us to ignore them — so they should only be used very rarely, such as they examples made above. Technically it should not be too difficult to make them display on mobile, however an issue arises when we have the template {{multipleissues}} — which can not simply be adapted to display certain things on mobile, while not others. Any ideas? Carl Fredrik 💌 📧 15:03, 28 September 2016 (UTC)[reply]
  • Support making {{hoax}}, {{afd}} and all speedy templates visible on mobile, per User:James Allison. Even if we don't add a "mobile=" field to a/mbox. I do support adding that, and making {{medref}} visible too, once that's done.--Elvey(t•c) 19:12, 29 September 2016 (UTC)[reply]
  • Support Displaying AfD, PROD, CSD, and Hoax tags. Neutral on medref. Hoax needs to be implemented ASAP. Tazerdadog (talk) 06:58, 30 September 2016 (UTC)[reply]

This discussion got a lot of support back in September before it got archived, but I've struggled to get any traction for how we could actually implement it since, at either WikiProject Templates or Village pump (technical). Another editor has advised that I move it back out of the archives and request a "formal close", so here it is. Can somebody do the honours? --McGeddon (talk) 17:16, 24 February 2017 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=767321691"