Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Cenarium (talk | contribs) at 20:51, 11 February 2017 (→Unpatrol moved pages: re). 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 whennsaved (even if it is just a missing sidebar) is daft. As Alsee said, if it ain't. Time, 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 resorlurcenhungty 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]

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"[4] 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]

RFC on WP:RESTRICT

Wikipedia:Editing restrictions currently lists every single restriction that either the Arbitration Committee or the broader community have ever placed on a specific user, as well as lists of voluntary restrictions and conditional unblocks. The list is extremely long and contains many restrictions on users who are inactive or have been indefinitely blocked for an extended period. The purpose of this discussion will be to determine if it is desirable to continue to have all of these restrictions listed, and if not, what changes should be made. This is not a discussion of the validity of the individual restrictions or an attempt to have them revoked en masse, it is only concerned with managing the list to make it less cumbersome, and therefore more useful. Beeblebrox (talk) 21:52, 25 January 2017 (UTC)[reply]

Possible solutions

  • Remove listings on inactive users. Simply take them off the list if they have not edited in three years. This does not void the restriction.
  • Create an archive Any listing on a user who has not been active for two or more years will be placed in the archive. The restriction remains in place, and may be returned to the main list if the user resumes activity.
  • Split Split the various lists onto their own subpages, and possibly split them further by age, create a searchable index of these pages.
  • Status Quo It's fine the way it is.
  • Get rid of voluntary listings The smallest of the lists, currently only three entries, not really enforceable, not really helpful.
  • Mass review Do the thing we're not doing here: Compile a list of all restrictions that may no longer be necessary and review them all with an eye towards revoking them.

Discussion (WP:RESTRICT)

  • Status quo - Ctrl-F is a thing. Beyond My Ken (talk) 22:39, 25 January 2017 (UTC)[reply]
  • I'm not sure that any of the suggested changes would outweigh the benefit of being able to, as BMK put it, Ctrl-F on one page to find a particular user. That said, perhaps a bot-curated archive could be a good solution; if the bot were to move people back and forth based on whether they have been active in the past X years (i.e. if someone goes away they get moved to the archive, then when they start editing again the bot notices and automatically moves them back to the main page). That way there's only a maximum of two pages to search on (and only if you're looking for someone who may or may not be active), but the main one becomes a bit more manageable. Sam Walton (talk) 23:21, 25 January 2017 (UTC)[reply]
Just so you guys know, whetever it s that cntrl-F does for you isn't going to work on most mobile devices. Beeblebrox (talk) 23:29, 25 January 2017 (UTC)[reply]
As far as I'm aware most mobile browsers have a "Find in page" option. Sam Walton (talk) 23:32, 25 January 2017 (UTC)[reply]
Mine probably does somewhere, I guess, but I'm not sure that's really something we should require peopel to know in order to navigate this page. I don't see a particular benefit to bulking up these lists with a permanent record of restrictions on people who have been banned for five years or more, or who just left after their restriction was imposed and never came back. Beeblebrox (talk) 01:09, 26 January 2017 (UTC)[reply]
  • Create an archive - move any inactive users to a spearate page; make sure that the introducsion to te page mentions this split, and should any of those users become actiove again, they can be moved back to te active page. עוד מישהו Od Mishehu 05:59, 26 January 2017 (UTC)[reply]
    • @Beyond My Ken:If you think that this solution makes finding specific user's restrictions too difficult due to the Ctrl-F option being made difficult, we could also have a separate page which transcludes both parts; you could then use Ctrl-F there with no problem. Even if the community opposes such a third page in the project-space, you could create one in your userspace. עוד מישהו Od Mishehu 05:10, 27 January 2017 (UTC)[reply]
      • Why in heck would I want to re-create what should be a community resource in my userspace? I see absolutely no reason to change the existing system - to me it seems like change for the sake of change, and has the distinct downside of potentially destroying information which could come in handy in any future cases involving the listed editors. (You have noticed that the same names tend to pop up again and again, right?) Without the information on the RESTRICT page, we are reliant on the fallible memories of editors. Beyond My Ken (talk) 05:24, 27 January 2017 (UTC)[reply]
No information is being destroyed, it will be preserved in the same format on the archive pages for as long as the restriction remains in place and will retain the same functionality as the main list. It is not change for the sake of it, which I dislike as much as the next person. Beeblebrox (talk) 05:24, 7 February 2017 (UTC)[reply]
  • Just to note that I created the "Voluntary Restrictions" section, and I was thanked by some of the participants for doing so, as it put in a permanent (I guess semi-permanent now that you all want to change it) public place what had been agreed to. Beyond My Ken (talk) 00:27, 27 January 2017 (UTC)[reply]
  • Archive with bot per Samwalton and Od Mishehu. Iazyges Consermonor Opus meum 04:14, 27 January 2017 (UTC)[reply]
  • Archive non-voluntary restrictions with a bot. Beyond My Ken makes a very good point about those voluntary restrictions being a needed resource that was requested. It is a valuable community resource that should be easily findable. Old blocks of long-inactive users aren't needed with the same ease and can be archived. While searching the whole page for a user name "as is" isn't that difficult, the difficulty comes when you vaguely remember a restriction and have to hunt it down and see if the user you thought it applied to is or isn't there. That type hunting is harder when the page contains not-current information. Eggishorn (talk) (contrib) 05:50, 27 January 2017 (UTC)[reply]
  • Archive inactive users, especially if a bot can determine how active a user has been and move them between lists as necessary. — Jkudlick ⚓ t ⚓ c ⚓ s 00:52, 28 January 2017 (UTC)[reply]
  • Comment - Noting that WP:RESTRICT is not an exhaustive list of restrictions. WP:DSLOG contains what may be a much longer list of restrictions imposed as discretionary sanctions. Should we include that page in any of the solutions? - Ryk72 'c.s.n.s.' 04:47, 28 January 2017 (UTC)[reply]
  • Archive Active users should still be listed, inactive users can be moved to archive in case they become active again. Justly applied restrictions do not expire, and it is helpful to have a centralized database of all such restrictions as none of us can keep track of every user who makes a pain of themselves. --Jayron32 05:43, 28 January 2017 (UTC)[reply]
  • Archive by bot, per Od Mishehu. Tamwin (talk) 03:11, 29 January 2017 (UTC)[reply]
  • Status Quo per BMK. The list isn't so long that the page doesn't load well. I am not otherwise against archiving except that I worry that visibility will be lost on restrictions that remain in effect. I don't want archiving to either hide an ongoing restriction or create the impression that the restriction is somehow lapsed from being out of date. Chris Troutman (talk) 17:29, 29 January 2017 (UTC)[reply]
That issue could literally be addresses in about two minutes by posting notices on both the archive and the main list stating that the archives are just older restrictions but have not been rescinded. Beeblebrox (talk) 21:16, 30 January 2017 (UTC)[reply]
  • Archive - Ctrl-F is a thing for most users, but some old mobile browsers lack that function. Moreover, the old notices serve little purpose other than historical record. This is like old discussions, which we archive in order to maintain user-friendly and tidy talk and discussion pages (e.g., SPI, ANI, user talk pages, etc.). Preserving old information is standard practice here. I see no reason not to employ it on this particular page. We would need to choose a specific time interval (e.g., one year inactivity). EvergreenFir (talk) 05:48, 2 February 2017 (UTC)[reply]
  • Currently it runs to 250kb which is a bit big, but there is huge duplication, multiple people under identical sanctions, sometimes grouped together sometimes not. It should be easy to trim it a bit by grouping more people who share the same sanctions. More seriously there are lots of hard to use time clauses, restricted for 6 months or 12 months. Replacing those with dates would be a big step forward "not allowed to do x before 13/02/2017"is much easier to understand, and easy to remove the bits that are out of date. ϢereSpielChequers 10:41, 5 February 2017 (UTC)[reply]
I believe arbcom deliberately stopped grouping sanctions some time ago in order to simplify appeals and WP:ARCA requests. Grouping them together again would actually complicate the archiving process. Beeblebrox (talk) 05:22, 7 February 2017 (UTC)[reply]

Wikidata items pointing into our draft space

I'm closing my own straw poll. I believe a unanimous eight firm comments is clear enough. Wikidata links to draft pages are not wanted. The discussion section remains open. Alsee (talk) 20:56, 29 January 2017 (UTC)[reply]

The following discussion 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.

I am horrified that I even have to open this discussion. Apparently there are people at wikidata who are either creating wikidata items pointing to our drafts, or who are attempting to do so. There is an open Phabricator task T122806 Wikidata items for articles in the Draft namespace: It is possible to add sitelinks to draft articles on Wikidata, but they are not functioning properly. If I understand the situation correctly(???), general public readers of foreign language wikis would be given these links, encouraged to read our draft as the "English language" version of the article.

I've only been over at wikidata a few times. I will go over to wikidata and open a discussion on this, but first I'd like to have a quick rough consensus in hand.

Straw poll proposed communique to our friends at Wikidata: 

The EnWiki community requests that Wikidata establish a policy against linking to our draft space. Drafts are intended as an internal workspace. Drafts may contain inappropriate or problematical content. External consumption of drafts is undesired, and is strongly discouraged.

Alsee (talk) 23:43, 27 January 2017 (UTC)[reply]

Followup: Yes, my understanding was correct. See wikidata item Q969904. It has links to a French wiki biography, an Italian wiki biography, and to our draft of the same biography. When I view the french biography fr:Gian_Francesco_Biandrate_di_San_Giorgio_Aldobrandini, the left sidebar on the article has links to the article "In other languages". It links to the Italian version, and it links to our draft space as "the English version" of the article. Alsee (talk) 00:00, 28 January 2017 (UTC)[reply]

Straw poll

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.

Discussion (Wikidata)

  • It's probable that the links to draft space are there because of moves from mainspace to draftspace, and the Wikidata notability policy specifies that Drafts are not welcome as dedicated items. I would guess they would be amenable (as a Wikidatan) to removing Draft-space pages. --Izno (talk) 01:31, 28 January 2017 (UTC)[reply]
    • Izno, The draft was not moved. It was created as an unsourced stub, then Wikidata-linked. And the Wikidata notability policy you linked appears unhelpful. If I'm reading it right, all does is affirm Q969904 is valid. It has valid sitelinks to the ItWiki and FrWiki articles. I'd like to ensure there's a policy against draft links. And after that, it may be worth investigating a technical barrier to entering such links. Alsee (talk) 10:52, 28 January 2017 (UTC)[reply]
  • Rather than have this poll, have you tried discussing this on Wikidata first? --Rschen7754 04:46, 28 January 2017 (UTC)[reply]
  • Comment : There is at least one advantage to this : if someone has already started a draft on a topic you want to write something, you'll be aware of this. TomT0m (talk) 11:43, 28 January 2017 (UTC)[reply]
    • Indeed there are several good reasons why you might want to add a sitelink to a draft article. One is that the draft will then show inter-language links to other wikis which could help when writing a new article. Another is to be able to use the data about the topic in infoboxes, etc. which would then work just as well when the article is moved into mainspace. Another is the point by TomT0m above. It is my opinion that inter-language links FROM a draft should be displayed, but links TO a draft should be disabled. This is precisely the opposite of what happens currently, which is why I opened Template:Bug. — Martin (MSGJ · talk) 08:56, 30 January 2017 (UTC)[reply]
    • This is kind of a weird thing for us to be trying to make "rules" about. WP:CONEXCEPT indicates that we really have no right to tell Wikidata that they may not track whatever pages they want, and we certainly have no right to tell the communities at the French and Italian Wikipedias (to use the example given) that they have no right to link to our drafts along with the other interlanguage links if that's what they want to do. We really cannot expect to control in-bound links to our pages, whether on WMF-based sites or on independent blogs. WhatamIdoing (talk) 17:02, 6 February 2017 (UTC)[reply]
      • WhatamIdoing, I'll assume that you skimmed the topic without carefully reading it. Exactly no one in this discussion tried to make any "rules". Exactly no one said anything that that goes against conexcept. In fact this discussion could be linked from conexcept as an excellent illustration of exactly what conexcept does mean.
        1. A local individual has concerns about what another project is doing.
        2. A non-rulemaking, non-binding, utterly unofficial Straw Poll asks for input to sanity check whether this is a shared concern, just or a rogue individual with weird ideas.
        3. The first community respects the independence of the second community, and sends a friendly request that they stop doing X for reasons Y.
        4. The second community controls its own rules. They may or may not agree with reasons Y. They will act on the information as they see fit.
        1. They may even submit a request for the WMF to make a software change.
        2. The WMF decides whether to spend money (employee salary) making that change. We're all working together as partners, and if there's a good reason for the change then the WMF is generally happy to do so.
      In case you didn't check the discussion at Wikidata[5], the discussion has been going in the direction that they don't want these links on wikidata. Their Notability policy already says that userspace and draft space are not valid sitelinks. The software already blocks any attempt to add an invalid sitelink to userspace. Several of them have said there should also be a technical block preventing invalid sitelinks to draftspace. I think it would require a Phab request to tweak the existing invalid-link check to match the existing policy definition of invalid links. Alsee (talk) 11:10, 7 February 2017 (UTC)[reply]

Diffusing year categories for births and deaths

I'm proposing that diffuse the categories in Category:Deaths by year and Category:Births by year (i.e. Category:2000 deaths, Category:2000 births) into more general locations such as continents, countries, or maybe even states. Currently, many of these categories are unwieldy, containing thousands of biographical entries. By diffusing these categories, we could have something like Category:2000 deaths in Europe and so forth, presenting readers with links that should be more closely related to the article they were reading. FallingGravity 04:17, 1 February 2017 (UTC)[reply]

That would make it a lot harder to use. Now it is very easy to know whether to add 2000 deaths, but if it is subcatted, then you would have to know if it was 2000 deaths in France, or 2000 deaths in Normandy or whatever level of subsetting it is. Graeme Bartlett (talk) 09:56, 5 February 2017 (UTC)[reply]
"2000 deaths in Normandy" (if we even wanted to get this specific) would be a subcategory of "2000 deaths in France", which would be a subcategory of "2000 deaths in Europe" and so forth. All you really need to know is the person's birth and death places. FallingGravity 18:07, 5 February 2017 (UTC)[reply]
My point is that the person doing the categorisation will not likely know that level of detail about the category structure. Perhaps hotcat could help by listing subcats in a dropdown when you pick a supercat. Graeme Bartlett (talk) 01:50, 7 February 2017 (UTC)[reply]
There are some other issues. Breakdowns by country, for instance, become more involved when considering the mutations of countries through the centuries. And would we be prefer to know that the death happened in a certain place; or that there was the death of a citizen of a certain country? Gender is more easy to use; not least wikidata has gender for 1.4M en.wiki biographies, but we only remove 16.83% of entries from a category by moving females to a new category. Meanwhile, is an alpha-ordered list of 5k biographies really that unwieldy? Is it more unwieldy than the same cat decanted into 200 sub-categories? --Tagishsimon (talk) 02:17, 7 February 2017 (UTC)[reply]
For edge cases, these categories could always be partially diffused per WP:DIFFUSE: some members are placed in subcategories, while others remain in the main category. Regarding your concerns about categorizing place vs. citizenry, my idea was to go with place, because the places of birth and death are usually readily available in the article's infobox, text, and Wikidata item. Are diffused categories worse than undiffused categories? I guess it depends on how the reader uses them. FallingGravity 05:02, 9 February 2017 (UTC)[reply]


Template suggestion: Refer to living person with indirect microbiographical data

(Transplanted from Wikipedia_talk:Editor_assistance/Requests at the suggestion of TransporterMan (TALK) )


Many articles that refer to people often include year of birth and death or for living persons, year of birth in parentheses. As a software and database engineer from the DRY school of thought, Updating all these references strikes me as very inefficient when someone passes away. Additionally, many notable people change the name they are known by (i.e. the artist formerly, then once again known as Prince), their primary "descriptive noun" (a notable "author" could become best known as a notable "vocalist", for instance), or even their gender, one or more times in their career. It seems to me that often repeated details like this should not be repeated throughout Wikipedia when the person is mentioned (and linked to). It seems to make more sense to have a template that fetches these details from the notable person's wikipedia article and includes them inline.

What this could look like

On the notable person's page: (this is just an idea)

'''{{define person name|Eleanor_Parke_Custis_Lewis|first=Eleanor|last= Lewis|middles=Parke|maiden=Custis|nick=Nelly|render=inline maiden,no nick}}''' ({{define person period lived|Eleanor_Parke_Custis_Lewis|born= March 31, 1779|died=July 15, 1852|render=dates}) known as '''{{reference person name|Eleanor_Parke_Custis_Lewis|render=nick}}''', was {{define person primary noun|Eleanor_Parke_Custis_Lewis|the granddaughter of [[Martha Washington]]|render}}

could render as:

Eleanor Parke Custis Lewis (March 31, 1779 – July 15, 1852), known as Nelly, was the granddaughter of Martha Washington

While another page may refer to Mrs. Lewis as:

'''Acme Bologna Corporation''' was founded by {{reference person name|Eleanor_Parke_Custis_Lewis|render=first last}}''' ({{define person period lived|Eleanor_Parke_Custis_Lewis|render=years}}), {{reference person primary noun|Eleanor_Parke_Custis_Lewis}} on January 2, 1834 when {{reference person name|Eleanor_Parke_Custis_Lewis|render=last,no link}} failed to find a satisfactory maker of [[Bologna_sausage|bologna]].

which could render as:

Acme Bologna Corporation was founded by Eleanor Lewis (1779-1852), the granddaughter of Martha Washington, on January 2, 1834 when Lewis failed to find a satisfactory maker of bologna.

(my apologies to the deceased, if she in anyway disliked bologna or corporations. Again... just an example)

  • I acknowledge that gender is so ingrained in how we speak, and is changed so infrequently (per capita) to make templates for gender pronouns cumbersome and practically useless. I was using it as an example.
  • I am also aware that special care must be taken when a person's name changes, as the name of the page needs to be updated too, along with probably adding a redirect from the old page, though I suspect this could be automated too.

This is just an idea I thought might be worth discussing. One (of many I'm sure) place I saw this may be helpful was List_of_people_who_have_won_Academy,_Emmy,_Grammy,_and_Tony_Awards.

Linux_dr 6:33, 10 Febuary 2017 (UTC)

Could this somehow work with/retrieve from Wikidata? The execution in the person's biography example seems cluttered, and at least some of this information (if not all/more) is currently stored in Wikidata anyway (example: Tchaikovsky). - Purplewowies (talk) 06:59, 10 February 2017 (UTC)[reply]

Category redirects from "organisation" to "organization" and vice versa

At Wikipedia:Bots/Requests_for_approval#BHGbot_3, I requested permission to run a bot to create a set of a few thousand category redirects from "Foo organisations" to "Foo organizations" and vice versa.

If anyone has any views on whether this is a good or a bad idea, please add your comments at Wikipedia:Bots/Requests_for_approval#BHGbot_3. --BrownHairedGirl (talk) • (contribs) 13:50, 2 February 2017 (UTC)[reply]

Abolishing the edit-ban of archived talk pages

WP:SNOW CLOSE
Opposition to this proposal is unanimous. Discussion of modifying archive template language can take place on the talk page of the relevant template. Beeblebrox (talk) 20:00, 6 February 2017 (UTC)[reply]

The following discussion 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.

Currently the {{Talk archive navigation}} and {{Talk archive}} templates say: 

    Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

I propose abolishing this edit-ban as it significantly hinders discussion and progress on Wikipedia.

(Close to) nobody is going to actually go to an archive and revive an old discussion to post a single comment (especially for some rather small but nonetheless useful comment) - please don't deceive yourself.

Actually that's more than to expect from most editors - let alone readers - already. If anything allow editing of the page and automatically move the revived discussion to the talk page via a bot / automated process (that would actually be a second, separate proposal here; the template-text should however be changed first and asap).

It's Wikipedia - these are not actual physical "archives" - these are dynamic websites and we should be making use of this advantage (which is that no matter how old a discussion is it can be easily returned to).

If you think that this would be useful to prevent vandals from editing old talk pages: they can do so even with the template set but while the bad guys still can do their mischief and won't be stopped by this those who intend to reply to an old discussion are significantly discouraged/obstructed even though there are many instances where it would be very useful to instead of even encourage the revival of old discussions and their ideas.

You could also suggest some text that it can be replaced with (roughly).

I'd suggest something along the lines of: 

   This is an archived talk page. You may still reply to users here. Please use the {{ping}} template to notify them.

--Fixuture (talk) 18:10, 4 February 2017 (UTC)[reply]

Unnecessary. If you want to revive a discussion, bring it back to the main talk page. ansh666 18:33, 4 February 2017 (UTC)[reply]
I agree. If someone wants to revive a discussion, just take it out of archive and put it back on the main page. 24.29.215.27 (talk) 20:15, 4 February 2017 (UTC)[reply]
Wholeheartedly agree with the ban. I know some editors ignore it but revived discussions should be brought to the current page, possibly in summary and possibly including referencing back. Martin of Sheffield (talk) 20:44, 4 February 2017 (UTC)[reply]
@Ansh666, 24.29.215.27, and Martin of Sheffield: I expected people to say this here which is way I stressed multiple times that I'd like you to think practical about this and that in reality nobody (very few people very seldomly) does that.
Nobody. is. doing. that.
This is not the solution. Just because from your point of view as experienced editors it's easy to do a copy-paste move from the archive page to the current talk page doesn't mean that newcomers should be expected to do so. There are many reasons why this is a problematic approach:
  • It discourages editors from taking part in discussions and providing valuable input by making it a lot harder (in time and effort) to reply to a talk page entry, in addition to the extra time & effort needed the main point here is being open to newcomers and people that aren't as Wikipedia-savvy as you might be (note that people often speak about how hard Wikipedia is for newcomers - this is one such instance)
  • Also note that an effect of this is an increase of the perceived threshold for creating a reply - this means people won't reply if they aren't very sure that their reply is very useful or if they really want to know something etc. - this means much potential valuable content & discussion gets missed out. For better understanding of this: if you only have some short but potentially useful input and can very quickly and easily reply to a post (and that wouldn't be given even if the ban is abolished) you're more likely to make it than if people require you to do some pretty obnoxious wiki-code-juggling and "revive" an old thread and so that everybody gets "annoyed" by this "strange users that thinks a small correction of a year-date in thread that's irrelevant anyways" would be useful enough for this. A counter-argument of this would be that any such post such might develop into a discussion for which other users would be interested in as well. To this I'd say that this comes second after ensuring that the reply gets made in the first place. Also for this the text of the template could still encourage moving an archived thread to the current talk page (e.g. if one thinks it might be interesting some other editors as well) - which is something the person replied to can do as well btw. But after all the most perfect solution would be a bot that simply moves any discussions revived (btw one could consider this to be defined by 2 new replies instead of just one) to the current talk page. But again: I think that would go second after ensuring that these replies are made asap.
  • There's not even a tutorial on how to "revive an old one" - many might not boldly assume that this means copy-pasting content to the talk page as you might but might be unsure about how this is expected to be done: e.g. if there's some requests-like process here or if one should cut & paste it instead of copying it. Actually I'm not even sure myself besides that the latter would conflict with the first part of the template's text but e.g. 24.29.215.27 & User:Mandruss already misinterpreted(?) it to mean cut&pasting it there.
From my point of view I do not care about theory (once the time for it is over) I'm concerned with the practical state of things. This doesn't work in practice. And I want Wikipedia to succeed. Furthermore I think users here might very much be biased by their own editing-boldness & -skills as well as a tendency towards policy-conservatism. Please address these points when replying (and especially so if you'd like to suggest an alternative) and take the latter concerns into consideration.
--Fixuture (talk) 02:39, 5 February 2017 (UTC)[reply]
I did not misinterpret anything. It's possible you misinterpreted my comments, as English does not appear to be your first language. The template does not currently speak to restoring an archived thread and, as I said in my comments, perhaps it should do so. If someone lacks the skills necessary to do a copy-and-paste successfully, they may ask someone else to do that. But archive pages are not for discussion, full stop. ―Mandruss ☎ 02:55, 5 February 2017 (UTC)[reply]
@Mandruss: Okay, well then the template-text only conflicts with itself. Of course they could ask someone else to do this for them but in practice will never (very seldomly) get done. If people here against such a change then there's the full stop of course - I'm just asking you to consider these points, which you haven't. --Fixuture (talk) 03:22, 5 February 2017 (UTC)[reply]
@Fixuture: You can also just start a new one, linking to the old one in the archive, which we also do all the time. But since you made such a point about being practical and all...I'll bite: give us some concrete examples where any of this is a problem. ansh666 04:59, 5 February 2017 (UTC)[reply]
Oppose - Note that restoring a thread is a 2-edit operation: 1. Copy-and-paste it to the main page. 2. Remove it from the archive page.
Otherwise we end up with two versions of the archived thread, only one of them complete. This is the only type of edit that should be done to an archive page.
Perhaps the instructions should mention this one exception to the rule. I tend to take such instructions literally, so I never did step 2 until I was educated by an admin about that. ―Mandruss ☎ 20:52, 4 February 2017 (UTC)[reply]
Oppose, the main reason: for user_talk archives - it won't trigger "new messages", and for all archives other interested editors won't see it as they are very unlikely to be watchlisting archive pages. — xaosflux Talk 21:16, 4 February 2017 (UTC)[reply]
Oppose I have seen both article and user talk pages edited to and refactor posts in various threads. MarnetteD|Talk 21:19, 4 February 2017 (UTC)[reply]
  • @Iazyges: What would text would you suggest? I do think that maybe encouraging reviving threads if they might of interest to other editors but not discouraging edits to the archived page could be a possible solution here as well (note that by this the person replied to could also take over the revival of the thread). --Fixuture (talk) 02:39, 5 February 2017 (UTC)[reply]
  • Oppose because there's no ban here. These are templates and templates and their documentation are like essays: Anyone can create one and put whatever into it whatever they like but it's not binding on anyone unless the work is done to convert it into a policy or guideline. As far as I know — and I stand to be corrected — there's no policy, guideline, or even information page which makes it a sanctionable event to edit a talk page archive. What it is, is fruitless: No one will be watching and, moreover, any addition to an archived talk page will often be regarded as not contributing to consensus on an issue simply because no one was watching. Moving it back to the active talk page cures all that, but there's nothing really preventing you from editing the archive. — TransporterMan (TALK) 22:29, 4 February 2017 (UTC)[reply]
    Oh good, so editors can ignore any instructions they read, and (counter-intuitively) are required to go spend their time hunting down applicable p&g, often contradictory p&g. Really, really bad way to run an encyclopedia, and I oppose it. There is also no policy, guideline, or even information page supporting "ignore all instructions as nothing more than somebody's opinion", as far as I know. Some longtime editors excel at devising unworkable and grossly inefficient systems without community consensus. ―Mandruss ☎ 22:38, 4 February 2017 (UTC)[reply]
    @TransporterMan: It becomes quasi-policy once it's a standard template mass-used for a specific purpose. Practically this issue can't be resolved by creating a new template and running an own archive-bot that sets it or alike. --Fixuture (talk) 02:39, 5 February 2017 (UTC
@Mandruss: There is indeed such a policy: CONLIMITED. - TransporterMan (TALK) 07:00, 5 February 2017 (UTC)[reply]
When the instructions contradict a community consensus, that argument makes sense. But they rarely do so for very long, so it's also somewhat pointless and tends to confuse more than enlighten. CONLIMITED cannot be used to say that instructions are the mere equivalent of essays. As I said, unworkable and grossly inefficient. ―Mandruss ☎ 09:43, 5 February 2017 (UTC)[reply]
  • @Robert McClenon: I do not think that changing the template text solves it but that improves the state of things. And why would it be a dumb idea? A user not getting notified of a reply as the archived pages aren't watchlisted might indeed be a problem here, however the text could state that the username has to be linked / the {{ping}} template be used for a notification. But as said this is just a suggestion for temporary improvement until adequate software changes are made. So a (more) optimal solution to this would probably look like section-level watchlisting being implemented and also applying to talk page archives or a bot automatically moving talk page entries / creating notifications or alike. --Fixuture (talk) 03:22, 5 February 2017 (UTC)[reply]
  • Oppose People have to be able to let things go and editing an archived talk page is almost always a bad idea that should not be encouraged. Suppose someone did edit an archive and ping everyone nicely. What are the others supposed to do? Should they continue the argument in the archive? If someone is concerned about a point made in an archive, the solution would be to create a new section on article talk with a link to the archived section and a brief comment with whatever clarification is needed. However, please do that only if it is really necessary—participants should resist the urge to have the last word or to continue an unproductive discussion. There is no need to ping me. Johnuniq (talk) 03:46, 5 February 2017 (UTC)[reply]
What are the others supposed to do? Should they continue the argument in the archive?
Yes, or move it to the current talk page if anybody of them thinks it might be of interest to other editors. Note that this isn't just or mainly about arguments, unproductive discussion and last words on talk pages but about providing additional information (e.g. relevant links). For instance, the case I'm experiencing most is actually old village pump entries and alike that outline ideas that one had as well. Sometimes I find these before I made a post about them and sometimes afterwards. With the plenitude of villagepump posts I guess that is happening frequently. What would be the best way to go about such for instance? If the post has already been made it's useful to link to it from the old post and if it hasn't been it would be good to add any information that's missing to the old post. Also I'm planning to go through my old talk page posts, for which I haven't had any time for yet, soon of which most are probably already archived despite not being resolved in any way (typically due to low user engagement). Having unresolved talk page entries go to archives where users are disencouraged from replying and close to nobody will read them anymore kinda pains me (I might restore or resolve mine but those of others are basically lost). This is only my personal experience and not the reason why I made this suggestion though.
the solution would be to create a new section on article talk with a link to the archived section and a brief comment with whatever clarification is needed
The issue with that is that nobody does it and that typically users (often rightfully so) don't think that their brief clarifications/additions are worth restoring the talk page entry.
participants should resist the urge to have the last word or to continue an unproductive discussion
Well, that's a point more or less: this might cause more unconstructive, endless discussions.
As of right now it looks like the quasi-consensus won't shift towards my proposal. So if that doesn't change by the arguments I provided (in the 2 top posts; please consider them!) we still need to decide on what text to replace the template-text with as it's instructions are self-conflicting / paradoxical as noted above. I suggest that it also at least shortly describes how such a revival can be made.
Also maybe people have ideas for alternative approaches to this? Lastly I'd also like to note again that this suggestion was only about a temporary fix until a more optimal software solution can be found by which e.g. talk page entries are restored automatically or are made by the click of a button within an entirely new discussion system (see WP:Flow).
--Fixuture (talk) 04:32, 5 February 2017 (UTC)[reply]
I'm not sure what happens on village pump pages, but on other discussion pages, I've seen plenty of examples of editors retrieving discussions from the archives or starting new threads on the same topic with a pointer to the old discussion. Or when a new thread is started, someone aware of the past history will post a link to the older conversation. So while it might be nice to the ability to restore a conversation to the current talk page with a single click, I don't see it as a very pressing issue. It's much simpler to have all current conversation on the current discussion page. isaacl (talk) 04:44, 5 February 2017 (UTC)[reply]
Fixutre has a good point about linking to advice from the template; it would only require the addition of a sentence "For advice on how to link to this discussion from the current page please see WP:<something>. Does anyone know if there is a suitable <something> written yet, or where it should go – possible a new appendix to Help: Wikipedia: The Missing Manual? Martin of Sheffield (talk) 12:48, 5 February 2017 (UTC)[reply]
@Martin of Sheffield: I'd suggest something like:
Do not add new replies here. Instead move the discussion to the current talk page by cutting it from this page and pasting it there. (help)
(help) should link to a more detailed tutorial on how to go about that which may also feature some other relevant information on the revival of archived talk page entries etc.
--Fixuture (talk) 18:00, 5 February 2017 (UTC)[reply]
If an editor lacks the required basic knowledge of the wiki editor and their computer's copy-and-paste functions, they certainly are in no position to use sound judgment as to when an archived discussion should be restored, and we needn't add instructions to help them do that. "Hey I didn't get a chance to participate in this discussion", by itself, is not a good reason to restore a discussion, and your draft instructions do nothing to convey that. Restore should be done sparingly; I've done it about 8 times in 3+1⁄2 years, and most of those were unclosed RfCs that needed to be restored so they could be closed. ―Mandruss ☎ 18:41, 5 February 2017 (UTC)[reply]
I don't think that's fair. Some people will look at the current language and believe that "Do not edit the contents of this page" means that they are not allowed – by policy – to "edit the contents of this page" by cutting the discussion out of the archive and moving it to the current talk page. WhatamIdoing (talk) 18:01, 6 February 2017 (UTC)[reply]
@WhatamIdoing: I have said twice that the instructions could be updated to mention restore as the only exception to the "don't edit this page". My objection is to a "detailed tutorial" on how to do that. My rationale is that archive restores should be rare and an editor who needs such a tutorial is probably the last person we want making those decisions. It's basic edit and copy-and-paste, both of which are used all the time in the course of editing of any kind. Competence is required. ―Mandruss ☎ 18:42, 6 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.
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)

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]

@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)

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]

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]

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]

New Page Reviewing - Election for coordinators

New Page Reviewing - Election for 2 coordinators. Nomination period is now open and will run for two weeks followed by a two-week voting period.

  • Nomination period: Sunday 5 February to 23:59 UTC Sunday 19 February
  • Voting period: Monday 20 February to 23:59 UTC Monday 06 March

See: NPR Coordinators for full details. Kudpung กุดผึ้ง (talk) 17:03, 5 February 2017 (UTC)[reply]

Separating viewing deleted pages into it's own right

Yes, I know it's a perennial proposal with all the polls failing. I thought maybe I could explore the topic from a different angle that I've seen discussed. Essentially, I would like to view the content of deleted pages and have it "broken apart" from admins. This is my first proposal, so perhaps this will be a learning experience for me instead of a historical dead end.

My motivation is simple: I only have rollback and I help out in IRC. An often question I'm asked it "Why was my page deleted?" I can give a general answer (whatever the comment contained) but can't help with any specifics. For instance, the inability to mention a non-credible source they used. I tend to help late at night, so if there's an admin around, I get it as a pastebin URL, and to see it formatted, I paste it in my sandbox and save it. Needless to say, this very inefficient and at times detrimental to some admin's sleep health.

To address a few past concerns:

  • I have no interest in restoring the page or any section of it.
  • Truthfully, I'm even okay with just having this for pages that failed AfC.
  • Entirely agree it shouldn't be a public link, and should require a "viewdeclinedpages" right, same process as rollback.

As was mentioned on this failed proposal, legal chimed in with valid concerns and mentioned the adverse effects for OTRS. I respect that, and again, I'm a bit of a novice regarding this, but isn't that what OS/revdel is for? I don't think anyone is asking this proposed right to have any visibility into those. There's been some talk of a check-box if it's BLP or Office during deletion, I see that as a bit too complicated for what I'm proposing. Overall, I don't see any harm in allowing vetted users to see the content of a deleted page, anything that "isn't for our eyes" seems it should be OS'd anyway. I believe the current "process" is simply another thing to bother the admins from the more pressing things they focus on. I'd love your feedback and thanks in advance for your patience in this rehashed debate. Drewmutt (^ᴥ^) talk 00:53, 7 February 2017 (UTC)[reply]

OS and revdel are not for this. For one thing, the capacity of admins and oversighters is limited. Having to vet each deleted revision for the possibility that it contains content that should be restricted access is a big effort. Jo-Jo Eumerus (talk, contributions) 09:54, 7 February 2017 (UTC)[reply]
This just lands on the perennial pile. It's perennial because it's so obviously handy to have, and so obviously harmless in almost all cases. But it's an all-or-nothing deal. Deleted pages are an unsorted unmaintained trashheap. It grants access to copyright violations, which we can't do lightly for legal reasons. It also grants access to the entire range of the worst we delete for any reason, including any sensitive information that slipped by without being oversighted. The community is too careful to buy the "all" side of that all-or-nothing deal. Alsee (talk) 23:30, 8 February 2017 (UTC)[reply]
  • I could see it being viable only if admins were able to mark a deleted page after review as "safe for viewing" (by users with a specific permission). It's possible to change the visibility of deleted revisions so some of the revisions being bad isn't an issue, they can be hidden then the deleted page marked safe for view. But there are two hurdles. The first one is mentioned by Jo-Jo Eumerus, it takes admin effort to ensure the deleted page is viewable, although maybe for newly deleted pages it won't be an issue since the admin would have already reviewed the page in the process of making the delete decision (and could then immediately mark it as viewable). The second one is technical: it would need development, either asking the WMF to develop it directly but I wouldn't count on that, or convincing a volunteer developer, but said developer would want to be certain first that it would be accepted by both the community and WMF. Cenarium (talk) 04:22, 9 February 2017 (UTC)[reply]
  • I believe the Foundation has said that it will not aloow us to grant the ability to view deleted revisions to anyone who has not passed RFA or an equivalent process. If we have to do that, it's a zero-sum game -vs- just becoming an admin. Beeblebrox (talk) 04:41, 9 February 2017 (UTC)[reply]

Thank you guys so much for your feedback. Like I said, I'm still a bit new so thanks for your sage insight. In discussing this more with some of the other admins, I've come to agree with the consensus. I still feel there's a need for vetted volunteers to view deleted content without the help of an admin, so what I'm gathering is that deletion is too "wide" of a tool. Articles can be deleted for a number of reasons, and I get that some are more sensitive than others. As an admin do you think it would, as Cenarium suggested, be feasible (from a "workload" perspective) to have a "safe for viewing" box? I ask out of ignorance because I don't know if the entirety of articles are scanned before deletions (ensuring there is no sensitive data). Drewmutt (^ᴥ^) talk 05:05, 10 February 2017 (UTC)[reply]

  • This is one that is absolutely, positively, never going to happen, for lots of fairly WP:BEANS-y legal reasons. You linked to a previous discussion on the topic, take note of Wikipedia's legal counsel's words in that discussion, in part: "Allowing non-administrator users to have access to deleted pages would vastly increase the frequency and volume of legal complaints. (It could have even worse consequences than that in the long term, up to and including corrective legislation by Congress, which would be a disaster.) It is difficult to overstate how much legal and practical difficulty this would cause the Foundation. To be frank, community adoption of such a disastrous policy would create an actual emergency that would likely require Board intervention." That pretty decisively states why neither this nor any variant of it is ever going to happen, ever. Andrew Lenahan - Starblind 08:02, 10 February 2017 (UTC)[reply]

Unpatrol moved pages

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 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:58, 11 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]
  • Oppose 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]

Unobserved subpages embedded in authoritative policy and guideline pages?

I just noticed that Wikipedia:Requested moves/Controversial essentially has the power of an authoritative guideline despite almost no one having it on their watchlist and so being made aware when a unilateral change is made. It's transcluded in WP:RM, which does have a lot of watchers, but are these editors made aware when the sub-page is edited? I was apparently the first person to notice in over four years that an explicit endorsement of Google was unilaterally transcluded in the page back in 2012. The claim had previously been made that it had been stable for years, but I have to imagine this was only because no one noticed it being added in the first place and everyone else just assumed it had been discussed somewhere.

I'm not really sure how these situations are dealt with, but has this come up before? Is it mentioned anywhere that such subpages should be edited with the same caution as the main pages that have a lot of watchers? If not, should it be?

Hijiri 88 (聖やや) 00:26, 8 February 2017 (UTC)[reply]

WP:Requested moves isn't actually a {{guideline}}. (It's a process page.) WhatamIdoing (talk) 21:21, 8 February 2017 (UTC)[reply]
I know that. That's why I said "essentially has the power of an authoritative guideline". It's not actually a PAG, but the instructions given there are still supposed to represent community consensus rather than the random thoughts of lone editors. please present Google Books or Google News Archive results before providing other web results. looks like an authoritative instruction, and the user who added it was out of line, but I'd be willing to guess no one ever noticed it except when copy-pasting the template in order to open a new RM, and the reason for that is that the main RM page has over 1,000 watchers, who are presumably interested in what the page actually says, but were likely not notified when the sub-page was edited. In fact the overwhelming majority of text included on that page is transcluded from elsewhere; do the people who have the main RM page watchlisted think they will get notifications when the subpages are modified? Or do they actually get such notifications? (I don't have the page on my watchlist so I actually don't know -- I "Ctrl+F"ed WP:WATCHLIST for "subpage" and [WP:SUBPAGE]] for "watchlist" and came up blank.) If they do get the notifications, I find it hard to believe that the change went uncommented on for over a year.
On the other hand, I can't imagine the page's 1,578 watchers watchlisted it because they want to receive notifications when someone edits the "Commenting in a requested move" or "Relisting" sections but not the rest of the page -- is there any other benefit to having a page watchlisted?
And even if anyone is free to edit process pages as they like because they are technically still subordinate to the PAG pages, doesn't the problem still apply to actual PAG pages that have transcluded subpages? I don't know a fast way to check the total number of such pages, and a quick search appears to indicate that this is not a major issue for any of the core policies, but still...
Hijiri 88 (聖やや) 05:22, 9 February 2017 (UTC)[reply]

WP:INCUBATOR

I invite you to comment on as well as to endorse my idea of article incubator. The idea is not new and details of the previous version can be found at WP:INCUBATOR. I would be glad if you enhance it with your experience. Feel free to improve upon the proposal that I have placed. Anasuya.D (talk) 10:05, 8 February 2017 (UTC)[reply]

  • Sorry, but this is a very bad idea. The original incubator was a disaster and very few articles were ever moved out of it into mainspace. You can see from the discussion just how strong the consesus was to shut it down. We don't need to bring back something that decisively failed. Andrew Lenahan - Starblind 02:07, 9 February 2017 (UTC)[reply]

Unbundle EducationProgram rights from sysop

Admins currently have a lengthy list of education program userrights, however those are very specialized and already possessed by course coordinators. See Special:ListGroupRights. If any sysop decides to work in this niche area, they should grant themselves course coordinator. This way, there can be an exhaustive and updated list of course coordinators, which users can rely on if they need assistance. This is a similar rationale as to the edit filter manager group. Cenarium (talk) 13:12, 8 February 2017 (UTC)[reply]

Note, admin is the only group that has ep-bulkdelorgs so that shouldn't be removed. As far as the rest, I don't think this is going to solve your issue - people don't search for users based on what permissions they have - they may search for them based on what groups they are in - in which case looking for the list of coordinators will show the very few that exist; this includes 3 admins - who if they want to be active in this realm should feel free to list this as an additional group. — xaosflux Talk 00:32, 9 February 2017 (UTC)[reply]
Since they already have ep-bulkdelcourses, I don't see an issue with granting ep-bulkdelorgs to course coodinators as well. This way they would have all necessary rights to handle education program issues. My main interest in this is to prune the ever-expanding list of admin rights, some unbundling is good, we only need some core rights bundled together (mostly block/delete/protect/rightschange). Searching for the list of course coordinators was what I meant. This way, all admins interested in working in this area will have to add themselves to this list so will be visible (as with edit filter managers). Cenarium (talk) 04:04, 9 February 2017 (UTC)[reply]

Ok, so in the updated proposal I also suggest to grant ep-bulkdelorgs, currently only owned by admins, to course coordinators as well; this allows them to delete institution pages, knowing that they can already delete course pages and both are logged and reversible. Cenarium (talk) 04:04, 9 February 2017 (UTC)[reply]

Urban area vs. Metro area

Wikipedia articles for large United States cities typically display, in their introduction, information regarding the city proper population, and/or the population of the Metropolitan Statistical Area/Combined Statistical Area.

My proposal is as follows: Move the MSA/CSA Statistics from the introduction to the Demographics subheadings. Put the United States Urban Area definitions in their place.

This would make more sense in the introduction because the Urban statistics for U.S. cities are what are typically associated with each city. (Example: Cincinnati lists its City Proper, Metro, and CSA populations in the first paragraph. When people look up "Cincinnati", the Urban population gives the figure for the area immediately surronding Cincinnati, with residents likely going to Cincinnati for services, rather than the 15 surronding counties that people would rather refer to as the greater Cincinnati Area.)

The U.S. Census Bureau refers to an urban area as:

  • "a densely settled core of census tracts and/or census blocks that meet minimum population density requirements, along with adjacent territory containing non-residential urban land uses as well as territory with low population density included to link outlying densely settled territory with the densely settled core."

...while the Office of Management and Budget describes a Metropolitan area as:

  • "one or more adjacent counties or county equivalents that have at least one urban core area of at least 50,000 population, plus adjacent territory that has a high degree of social and economic integration with the core as measured by commuting ties."

I would love to hear everyone's opinions on each. --636Buster (talk) 13:22, 9 February 2017 (UTC)[reply]

Hi 636Buster. Perhaps you'd like to explain the application of the above to Beijing or Cape Town? ;-) Seriously though, you need to think this through in an international context and map the US-specific application to the general guidance. Regards, Martin of Sheffield (talk) 13:31, 9 February 2017 (UTC)[reply]

You're right, this idea more supports a U.S. theme. In articles on cities in China, the city proper population is listed because it more accurately demonstrates the population of what people would be considered in that city rather than the urban population that describes a smaller area. An example would ve Chongqing, where the urban population refers to a more isolated portion of the city/region. However, U.S. articles display city proper followed by metropolitan rather than the city proper and urban, which would more properly represent the city's size as a cluster rather than a link. --636Buster (talk) 13:47, 9 February 2017 (UTC)[reply]
I still think you need to consider internationally. Have a look at Sheffield: city population 563,749, urban population 640,720 and metropolitan area 1,569,000. These figures taken from the infobox. The first paragraph of the lead also mentions the figures. I then compared this layout to Cincinnati and again there are the three figures in both the infobox and the lead. This same model is common around the world, just the names vary, and it makes sense to me to keep the same format for all similar areas – it makes comparisons easier for one thing. Martin of Sheffield (talk) 15:10, 9 February 2017 (UTC)[reply]

Improved Spam blacklist: options to warn only, apply to new users only

Having seen this recent request to use the edit filter to warn users to not add urls to some sources that were determined as unreliable by consensus, I was wondering if we couldn't make a request to implement a more general system to warn users inserting some URLs: a spam greylist (that would warn, but subsequently allow the addition on confirming, as an edit filter warn). It would also log the attempts (restricted to admins, as the current spam blacklist log). It would be maintained at MediaWiki:Spam-greylist similarly to MediaWiki:Spam-blacklist (EDIT: or by adding options, as the MediaWiki:Titleblacklist does). The advantages, overall and over using an abuse filter, are as follows:

  • it's likely to have many uses in the future, it would provide more flexibility overall: it wouldn't be all or nothing as with only a spam blacklist
  • it could be done more efficiently than with an edit filter, and wouldn't use up the condition limit
  • a huge list of urls compromises readability in the edit filter editor
  • making addition/removal requests isn't as straightforward in the edit filter.

Cenarium (talk) 18:15, 9 February 2017 (UTC)[reply]

That is one of the uses of User:XLinkBot. Another implementation has been suggested in a long, long overdue rewrite of the extension, to have it operate more like a lightweight, specialised EditFilter. No-one has ever done this, does not have WMF/developer interest ... </frust>. --Dirk Beetstra T C 18:35, 9 February 2017 (UTC)[reply]
I may be interested in developing this myself or reviewing patches. Either way, we need to know if the community would like this specific proposal implemented. The way I first suggested it, or by adding an option like <warnonly> next to items in the spamblacklist, which may be better. But indeed I agree the extension needs a rewrite, such as better warning messages (having the possibility to customize the message for a particular entry). And we could also have an <autoconfirmed> option to indicate an entry should be applied to IPs/new users only. Cenarium (talk) 18:54, 10 February 2017 (UTC)[reply]
See T6459 and T157826. --Dirk Beetstra T C 05:41, 11 February 2017 (UTC)[reply]
I would prefer MediaWiki:Spam-greylist over adding options to the spam blacklist. I would like to see a list for pure spam or links using techniques we consider to be black hat for external consumption. MER-C 05:49, 11 February 2017 (UTC)[reply]
The greylist idea is a more technical form of XLinkBot. As long as it logs it is fine, people tend to ignore.
What I basically have suggested before is to take the current EditFilter, rip out the interpretation part completely, and replace it with a mechanism that does nothing else that match a regex against the added external links. That should be rather easy to implement, and much lighter than the current EditFilter (though likely heavier than the current blacklist tests). Filters already have the log only/warn/throttle/deny possibilities and possibility of custom warnings. Moreover, discussion and explanation could be on the filter page, and when an editor triggers a blocking filter they could be directed immediately to the correct discussion.
If one wants to fancy it up, it can have selections for confirmed levels (url's can only be added by confirmed, extended confirmed, admin only or nobody), built in whitelisting (second box) or even per-page possibilities. --Dirk Beetstra T C 10:24, 11 February 2017 (UTC)[reply]

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

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]

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]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=764947458"