Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia
Jump to: navigation, search
  Policy   Technical   Proposals   Idea lab   Miscellaneous  
Shortcuts:

New ideas and proposals are discussed here. Before submitting:
« Older discussions, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138
Centralized discussion
Proposals: policy other Discussions Ideas
For a listing of ongoing discussions, see the dashboard.

Renaming Category:WikiProject Infoboxes[edit]

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) 18:04, 15 January 2017‎ (UTC)

Proposal to submit blockers on replacing our wikitext editor[edit]

There is a strong consensus among the participants of the discussion to support both the proposals.Winged Blades Godric 12:30, 21 March 2017 (UTC)

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

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)

Responses[edit]

  • 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)
  • 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)
  • 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)
    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)
    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)
  • 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)
  • 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)
    Dear Izno, would you submit an edit when you can't preview it? --NaBUru38 (talk) 00:13, 24 January 2017 (UTC)
    @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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
    • 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)
    • 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)
  • 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)
  • 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)
  • 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)
    • 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)
      • 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)
      • @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)
  • 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)
  • Support both. Slower loading times are an issue for developing countries and mobile users who don't like the mobile interface (I know I'm not the only one). But having a preview that doesn't render the page exactly like it appears when saved (even if it is just a missing sidebar) is daft. As Alsee said, if it ain't broke, don't break it. There's no reason to eliminate the plain text editor; far from simplifying things, the proposal to ultimately eliminate it is a switch to a more resource hungry process for no real benefit. oknazevad (talk) 23:00, 18 January 2017 (UTC)
  • 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)
  • 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)
  • 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)
  • Support both per Euryalus. Ealdgyth - Talk 15:36, 19 January 2017 (UTC)
  • 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)
  • 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)
  • Support both. And under no circumstances should the existing source editor be removed. Peter coxhead (talk) 09:53, 31 January 2017 (UTC)
  • 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)
  • Support both and do not remove the existing editor. ThePlatypusofDoom (talk) 18:20, 31 January 2017 (UTC)
  • Support both I support anything that obstructs WMF. Chris Troutman (talk) 20:19, 31 January 2017 (UTC)
  • Support both per above. The current wikitext editor is not broken. -FASTILY 22:16, 31 January 2017 (UTC)
  • 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)
  • 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)
  • 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)
  • Support load time as a blocker. I can live with the bad previews, but the slow load times will actually limit my editing activity. I frequently edit from countries where internet access is quite slow and having to wait more than a minute to edit a page isn't workable for me. I'm sure other people with slow internet access feel similarly. Kaldari (talk) 01:57, 12 February 2017 (UTC)
  • Strong oppose, we should keep ONE editing mode and ONE reading mode. On other Wikipedias have I noticed that it's possible to wright directly in to the text. This
  1. causes confusion
  2. the "direkt wrighting" will attract pure vandals
  3. there is no obvious benefit, with a new way of editing Wikipedia

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

Note: Boeing720 explained[4] that they were attempting to oppose VisualEditor on EnWiki. Visual Editor is already here. This proposal is about a change to the wikicode editor. Boeing720, you may want to strike or revise your !vote here. Alsee (talk) 09:52, 21 February 2017 (UTC)
Alsee is 100% correct, like anyone who reads my explanation will understand. I made a huge mistake by turning the proposal. I Strongly support both. Sorry for the confusion I may have caused. Boeing720 (talk) 10:11, 21 February 2017 (UTC)
  • Strongest possible support on the load time. Long load times make editing a chore, so quick fixes of simple errors are likely to be left alone. Editing in general will be discouraged. Support on the rendering. VisEd still can't render links properly? After all this time, that is totally sad. SpinningSpark 19:42, 18 February 2017 (UTC)
  • Support on load times. I have just come back from the Phillipines. It was nearly impossible to edit even with the faster load times of the wikitext editor. If the only option becomes an even longer load times less of the world is going to be able to contribute. Also there is no "color coding". The color coding of WikEd is essential. The cite tool still adds unneeded urls when the pmid is give (this too needs fixing) Doc James (talk · contribs · email) 16:12, 20 February 2017 (UTC)
  • The New Visual Editor =should replace the old Visual Editor, not the old wikicode editor. --NaBUru38 (talk) 13:04, 19 March 2017 (UTC)

Discussion[edit]

  • 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)
    There's at least one currently open task for that. --Izno (talk) 13:50, 17 January 2017 (UTC)
    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)
    • Noo! @Alsee:, where did you see that conversation? That would be a terrible idea, having the worst of two worlds. Diego (talk) 16:24, 30 January 2017 (UTC)
  • 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)
    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)
  • 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)
    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)
    @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)
  • 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)
    @Andrew Davidson: This is tracked at phab:T154217. --Izno (talk) 15:14, 18 January 2017 (UTC)
  • 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)
  • 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)
  • Then consider this a Beta test of the TCG. A bit like we get from the WMF all kinds of software that is in mid-draft but which gets rolled out anyway... Fram (talk) 10:03, 19 January 2017 (UTC)
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)
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)
  • 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)
    • "probably in mid-2017, we'll begin to provide it by default in place of the current wikitext editor"[5] If the WMF plans to roll out a new default editor in mid-2017, then early 2017 seems like the perfect time to discuss whether this really is fit to be the default editor, and which things surely need correcting before this can happen. The result of making this the default editor would be that new editors would encounter three editing environments instead of two (luckily we don't have Flow), as it has been shown here that there are circumstances where you always get the old wikitext editor, even if the new one would be the default. Sending out the message to the WMF that this is not acceptable is best done in time and not at the last minute (or even worse but rather typical, the WMF implements this, then a consensus emerges that we don't want it, the WMF refuses to roll it back because that would be too complicated or "confusing for new editors" or some similar excuse, and only after a long and bitter dispute does the WMF relent). This is a Beta, no one is arguing to end the availability as beta feature, but the stated plans by the WMF to roll out this out as the default in a few months time are simply premature. To dismiss this as "unconstructive" and "nurturing your inner grumpy old men" and adding the rather disingenious "this feature is not being released yet" (no, but it would be very stupid to wait with this discussion until it is released, wouldn't it?) is typical "shut up" behaviour of WMF supporters and not helpful, constructive, or open-minded at all. You could instead take the comments made in this very discussion as "testing and design feedback" and be happy that people care and voice their opinions. Fram (talk) 08:29, 20 January 2017 (UTC)
    • 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)
  • 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)

Third blocker: undo no longer works?[edit]

  • 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)
    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)
    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)
    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)
    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)
    That sounds more like your cache is wonky. You should consider clearing it. --Izno (talk) 15:08, 18 January 2017 (UTC)
    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)
    @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)

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

There is no plan to remove the old wikitext editor[edit]

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)

@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)
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)
@Whatamidoing (WMF): If we switch both editors to use Parsoid, issue #2 will be moot (as you explained above), but it isn't clear to me that that is actually going to happen. Can you provide any clarification on that issue? i.e. is the Editing Team planning on switching the old Wikitext editor to use Parsoid? Personally, I haven't heard of any such plans. On issue #1, my understanding is that there is little possibility of further improving the load time of the new WikiText editor due to its architecture (since it has to load most of the VisualEditor code in order to function). Is that also your understanding? Has the Editing Team considered re-architecting it to address the load time concerns or is that not a realistic option? Kaldari (talk) 02:23, 12 February 2017 (UTC)
Hi, Kaldari: Replacing the old parser with a modern one (i.e., some modern one/not necessarily Parsoid) has been expected for some time (software is not eternal, bitrot is real, etc.), but I believe that the decision to replace it with Parsoid (i.e., a modern replacement that happens to be Parsoid) was officially taken last quarter. (That decision belongs to ArchCom and Parsing, not to the VisualEditor team.) There is some information on the plans at on mediawiki.org; IMO the more interesting and informative page is the one about the two-systems problem itself.
The VisualEditor team is not currently working on performance issues. It's being considered for the coming year, but I don't know what they'll decide yet. There are some resource constraints that make it a difficult choice (e.g., inability to instantly clone certain members of Ops.  ;-) Whatamidoing (WMF) (talk) 18:40, 20 February 2017 (UTC)
Even if maintaining our "old" editor, have I experienced troubles at other Wikis, which uses more than one. All developments are not necessary good ones Boeing720 (talk) 00:52, 24 February 2017 (UTC)
A dozen different editing environments are officially supported on WMF wikis, and there are others that aren't officially supported (such as WP:WikEd). Whatamidoing (WMF) (talk) 21:44, 2 March 2017 (UTC)
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.

Future of magic links[edit]

There is consensus to replace the magic links with corresponding templates, and to do this replacement via bot. The consensus for the bot extends only to the conversion of magic links, not any other ISBN/ISSN/etc tasks like linking things that currently aren't linked at all. ~ Rob13Talk 18:14, 19 March 2017 (UTC)

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.
Moved from WP:VPT

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

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

21:49, 5 February 2017 (UTC)

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

Background[edit]

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)

What meeting? All the best: Rich Farmbrough, 23:55, 13 February 2017 (UTC).
phab:E287. Anomie⚔ 13:53, 14 February 2017 (UTC)

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

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)

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

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

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

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

Discussion on how / if to replace magic links[edit]

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

Backlog of unpatrolled files[edit]

Request an autopatrolled group specific to files[edit]

MAKE IT SO:

Consensus is that a file-autopatrol userright ought to be created that makes one's uploads automatically patrolled. There was also a suggestion that regular autopatrol should not patrol files but I am not certain there is consensus for that yet - a few users supported this proposal and others did not comment. Criteria for the file autopatrol to consider are understanding in file patrolling, copyright and fair use. Potential future projects that don't have consensus support yet (also per the following section) are to grant the file-autopatrol status by default to file movers. Jo-Jo Eumerus (talk, contributions) 10:11, 19 March 2017 (UTC)

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.

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)

  • Support. Seems like a good idea. I don't think (article-)autopatrolled users should necessarily have their files autopatrolled either, since WP:PERM/A doesn't do anything to check that the editor is au fait with licensing policies etc. – Joe (talk) 15:52, 11 February 2017 (UTC)
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)
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)
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)
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)
  • Support and remove file auto patrolled from the normal auto patrolled per Joe Roe. -- Iazyges Consermonor Opus meum 13:08, 13 February 2017 (UTC)
  • Support - Nifty idea and potentially good in practice. Criteria to obtain this permission may be needed, nevertheless. I don't know what the standards should be, but the criteria would be related to copyright and fair use. I don't know how many people would meet the criteria; the number would be the same as that of template editors or as high as the number of PC reviewers. George Ho (talk) 06:24, 14 February 2017 (UTC)
@Cenarium: May I add this discussion to "Centralized discussion" list? George Ho (talk) 19:49, 14 February 2017 (UTC)
  • Support - writing good articles and properly tagging uploaded images are two totally different skillsets and should not be bundled. — Train2104 (t • c) 06:08, 16 February 2017 (UTC)
  • Support fully. ~ Rob13Talk 04:23, 20 February 2017 (UTC)
  • Support: Helps reduce backlog of unpatrolled files. KGirlTrucker81 huh? what I've been doing 16:47, 24 February 2017 (UTC)
  • Support - Image copyright is a little trickier than print copyright (even allowing for some of the excesses and dubious interpretations of some extremist patrollers), but it should be simple enough to separate the sheep from the goats with respect to file uploading so that the goats can be more carefully minded. Carrite (talk) 21:13, 24 February 2017 (UTC)
  • Support Would make patrol status more meaningful. --AntiCompositeNumber (Leave a message) 23:09, 26 February 2017 (UTC)
  • Support – No reason not to. J947 18:28, 27 February 2017 (UTC)
  • Support, with the understanding that users will only get this right if they show an understanding in image patroll. עוד מישהו Od Mishehu 12:29, 5 March 2017 (UTC)
  • Support splitting the current autopatrol right into autopatrol-upload and autopatrol-page (and having them separate permissions on enwiki). For other wikis which have just one autopatrolled group and want it to have the ability to do both, the two rights can just be added to it. If this comes up for a consensus check later I also support giving the autopatrol-upload right to file movers on the understanding that they are already experienced in this area. Callanecc (talk • contribs • logs) 06:02, 8 March 2017 (UTC)
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.
@Jo-Jo Eumerus: Did you create a ticket for this? — Train2104 (t • c) 18:49, 22 March 2017 (UTC)
No. Jo-Jo Eumerus (talk, contributions) 19:08, 22 March 2017 (UTC)
Tracked in Phabricator
Task T161215
@Jo-Jo Eumerus: Done. First time I've done this, so hope I didn't screw up somewhere. — Train2104 (t • c) 13:37, 23 March 2017 (UTC)

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

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

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

RfC: Linking to details regarding the offline Medical Wikipedia app[edit]

The offline app allows you to download all of Wikipedia's medical articles in an app to access them when you have no Internet.
Wikipedia's health care articles can be viewed offline with the Medical Wikipedia app.

Should we allow a {{sister project}} style sidebar, i.e. Template:Offline in the form of {{offline|med}}, to be placed within the external links section of medical articles for the purpose of promoting Wikipedia:WikiProject Medicine/App? — Godsy (TALKCONT) 17:36, 29 March 2017 (UTC)

Support[edit]

  • Support Prior discussion here. Part of our efforts include "giving free access to the sum of all human knowledge" to all people. This should not be restricted to just when people have a functional Internet connection (something those in the developed world take for granted). Part of our work is to improve access to knowledge in the language of people's choice and in formats that they can use. For many of those in the developing world Internet access is only avaliable for a couple of hours a day or only when they visit larger urban centers. Offline content address these limitation. We know our online content struggles to reach those in the developing world. Our offline medical apps however have been downloaded by more than 150,000 people of which about 80% are from the developing world. Doc James (talk · contribs · email) 17:50, 29 March 2017 (UTC)
  • Support I wasn't a great fan of a huge banner for this, but I can't see any problems with this template, and Doc James makes a compelling case for the apps usefulness. Sam Walton (talk) 17:57, 29 March 2017 (UTC)
  • support per reason [7]--Ozzie10aaaa (talk) 17:58, 29 March 2017 (UTC)
  • Support: The Offline Medical Wikipedia app is an application that allows Wikipedia's medical content to be downloaded in a choice of languages in compressed ZIM format (as well as a free, open-source offline browser, Kiwix, that will natively display the compressed data, if required). Its principal purpose is to allow mobile phone users in parts of the world where internet access is restricted, intermittent, or unreliable to have constant access to our medical content. As an additional means of distribution of our content, I'd personally prefer it to be a sidebar link (like "Download as PDF" is), but I'll certainly support a link somewhere in the footers of medical articles to the WikiProject Medicine page where it is documented. --RexxS (talk) 18:24, 29 March 2017 (UTC)
  • Support. There are more than a million billion of people in developing countries that only have access to the Internet for a limited time. This banner is useful for million billion of readers who can use it when they are not online. The banner is the sum of all human knowledge at your fingertips for people who don't have unlimited Internet access or who want to use it while offline. Is there a better solution? QuackGuru (talk) 19:03, 29 March 2017 (UTC)
User:QuackGuru I think you mean more than a BILLION :-) Doc James (talk · contribs · email) 19:06, 29 March 2017 (UTC)
Yep. QuackGuru (talk) 19:17, 29 March 2017 (UTC)
  • Support - I had thought this debate had already been resolved satisfactorily in the deletion discussion. Yes, the sidebar is non-intrusive and helping users access our articles is an important part of our mission. Sizeofint (talk) 19:35, 29 March 2017 (UTC)
  • Support The debate had already been resolved to almost everyone's satisfaction, and this RFC appears to be unnecessarily pointy. • • • Peter (Southwood) (talk): 19:57, 29 March 2017 (UTC)
  • Support I also support this. I think anyone working in a developing countries context knows how important it is to have Wikipedia content available offline. I wonder if the people opposing this have ever lived in an area with poor internect access and poor public health, few doctors available, no access to healthcare etc.? For people like that having the offline version of medical content (in several languages) is wonderful. Due to the fact that not many people are aware of this app yet, I strongly support having the template (or any other form of awareness raising for this app) in an appropriate place of many related Wikipedia articles. Having it at the bottom right seemed like a perfect solution to me! EMsmile (talk) 20:01, 29 March 2017 (UTC)
  • support is a related WMF project, and will be limited to medical articles. Jytdog (talk) 00:18, 30 March 2017 (UTC)
  • Support - would also support the "inline" type being discussed below. Note, this support is contingent on the format that has already been debated multiple times - primarily that it links to an editor-controlled page. — xaosflux Talk 00:22, 30 March 2017 (UTC)
  • Support - the proposal is similar to other boxes that we have, so should be understandable to people who consult Wikipedia for a variety of topics. I would particularly note that the template should also display on mobile devices (I was disappointed to find that {{Library resources box}} does not). --122.108.141.214 (talk) 00:55, 30 March 2017 (UTC)
This template should also be included in {{Sister project links}} if this goes ahead. --122.108.141.214 (talk) 01:05, 30 March 2017 (UTC)
  • Support. This really is a very worthwhile initiative for the purpose of helping more people become readers of Wikipedia – which after all should be what we all want. In previous versions, there have been problems with potential advertising or with overly-large banners, but those problems have now been solved. And putting it in EL is the right way to do it. I think this RfC helps tie up loose ends from previous discussions, by spelling out where and how the box will be used. I also would support the inline idea described below. --Tryptofish (talk) 01:10, 30 March 2017 (UTC)
  • Support. Seems like a worthwhile cause that could be very helpful in regions of the world with poor internet infrastructure. ---- Patar knight - chat/contributions 02:29, 30 March 2017 (UTC)
  • Support Wikipedia's health care articles are generally high quality and it is helpful to inform readers about the app which displays that content. Johnuniq (talk) 10:45, 30 March 2017 (UTC)
  • Support, it's a good way to give the app visibility. Icebob99 (talk) 15:39, 30 March 2017 (UTC)
  • Support per Doc James. — Gestrid (talk) 04:53, 31 March 2017 (UTC)
  • Support for the same reasons as at the XfD I commented at. jcc (tea and biscuits) 12:31, 2 April 2017 (UTC)
  • Support — There really are no reasons to oppose beyond simply being obstructionist and wanting to hinder any improvement to the encyclopedia. It always ends up being the same people starting these pointless RfCs or who take it upon themselves to be the sole arbiters of guidelines and interpreters of policy. Carl Fredrik talk 00:37, 4 April 2017 (UTC)
  • Support - Addresses offline content issues for those in the developing world with limited internet access. SW3 5DL (talk) 04:44, 7 April 2017 (UTC)

Oppose[edit]

  • Oppose. Use formatting similiar to {{dmoz}} instead. KATMAKROFAN (talk) 20:28, 29 March 2017 (UTC)
    • Possibly an unfortunate analogy as DMOZ has just closed down. Nevertheless it's an interesting suggestion, so could you give an example of how this might look on an article like Pneumonia, please? --RexxS (talk) 21:05, 29 March 2017 (UTC)
Classification
External resources


KATMAKROFAN (talk) 21:35, 29 March 2017 (UTC)
Thank you. So essentially, you'd prefer the content of the template as plain text among the external links, rather than in a box floated to the right of the page with the sister projects? That seems a possible alternative. --RexxS (talk) 22:05, 29 March 2017 (UTC)
We also have Template:Commons-inline. The two are not exclusive of each other. Doc James (talk · contribs · email) 22:09, 29 March 2017 (UTC)
(edit conflict)Seems a strange way to do it. The links placed there are almost always links external to the Wikimedia projects, whereas we tend to put links to Wikimedia related places (Commons for example) in a side box like the one being proposed here. Sam Walton (talk) 22:09, 29 March 2017 (UTC)

  • I'm going to oppose.

    I'm sympathetic to the view that "offline reading" should be enabled.

    I do not, however, believe this is the way to do it. A systematic way, which relies not on en.WP's hack of a template, nor one which advertise a particular reader or viewer, is a) much better and b) provides the functionality for all pages, without c) the mess of a template addition to every article (within a certain scope) for d) every reader, mobile or not. To that end, there is a phabricator task for this funcitonality at phab:T113396. My final opinion: Just be patient. It's on the (WMF) radar. Courtesy ping to AGomez (WMF) who looks to have been editing the page at meta:New Readers/Offline. --Izno (talk) 12:58, 30 March 2017 (UTC)

  • Yup more options for reading Wikipedia offline are coming :-) The page this template links to will discuss that option as soon as it is avaliable. The template is not specific to raising awareness about a single app but about raising awareness about offline options generally (options of course need to be free and under an open license). Doc James (talk · contribs · email) 13:16, 30 March 2017 (UTC)
  • Oppose: it is not the job of each individual wiki article to make "meta" announcements of "other things that are available" related to Wikipedia. Articles are already at the borderline of being a mess in this sense, and if every special interest group within Wikipedia proceeded to add such "meta" announcements within individual articles, the result would clearly be untenable. I'm not sure why this particular announcement deserves an exception. Aureliano Babilonia (talk) 01:55, 3 April 2017 (UTC)
    • Because we see it as part of our mission to provide content to those in the developing world in a format that they can use. And also this appears to have consensus. Doc James (talk · contribs · email) 23:05, 9 April 2017 (UTC)

Neutral[edit]

Discussion[edit]

Relevant discussions preceding this RfC: Wikipedia:Miscellany for deletion/Wikipedia:WikiProject Medicine/App/Sidebar, Wikipedia talk:WikiProject Medicine/App#Sidebar, and Wikipedia talk:WikiProject Medicine/Archive 94#Sidebar. — Godsy (TALKCONT) 17:36, 29 March 2017 (UTC)

it seems s support vote is best for everyone, not clear what(or why) your position is such given prior general opinion[8]--Ozzie10aaaa (talk) 18:10, 29 March 2017 (UTC)
Discussion about titling the RfC
The initial heading was "non neutral". Have adjusted it so that it is.[9]. And here is the link to policy requiring the statement of the RfC to be neutral[Wikipedia:Requests_for_comment#Statement_should_be_neutral_and_brief] Doc James (talk · contribs · email) 18:19, 29 March 2017 (UTC)
@Doc James: Advertising, i.e. "the act or practice of calling public attention to one's product or service", is not inherently non-neutral. However, raising awareness is inherently non-neutral. — Godsy (TALKCONT) 18:32, 29 March 2017 (UTC)
Godsy you appear to dislike the app. Can you explain why? I was under the impression that we address your concerns. Doc James (talk · contribs · email) 18:34, 29 March 2017 (UTC)
@Doc James: Would you find "Publicizing the offline Medical Wikipedia app" or "Promoting the offline Medical Wikipedia app" agreeable for the RfC title? — Godsy (TALKCONT) 18:40, 29 March 2017 (UTC)
We could use "Linking to details regarding the Offline Medical Wikipedia app" Doc James (talk · contribs · email) 18:43, 29 March 2017 (UTC)
Yes check.svg Done. I'll fix the existing links. — Godsy (TALKCONT) 18:46, 29 March 2017 (UTC)
Godsy, although you're a relative newcomer, you must know very well by now that this encyclopedia is strongly opposed to any advertising. It is inconceivable that you do not understand that calling other editors' contributions "advertising" is rude and and offensive to them. To then edit-war your calumny back into this RfC is beyond acceptable behaviour, and I shall be considering seeking administrative assistance to ensure that you do not repeat that behaviour in future. --RexxS (talk) 18:56, 29 March 2017 (UTC)
@RexxS: Changing it to raising awareness was no better. I reverted twice, then came here to discuss; Doc James changed it thrice. If you do choose to seek administrative assistance, it will likely be fruitless, as I've done nothing inappropriate. — Godsy (TALKCONT) 19:07, 29 March 2017 (UTC)
@RexxS: I misspoke, I reverted twice. I was concerned about the link at {{cent}}. Best Regards, — Godsy (TALKCONT) 19:13, 29 March 2017 (UTC)
Changing it to raising awareness was no better - That's simply untrue. "Raising awareness" on Wikipedia carries none of the pejorative implication of "advertising" and it's not the "euphemism" that you claimed in your edit summary, ... if you euphemize inappropriately again, I expect you to check my contributions and fix all the existing links. You don't seem to understand edit-warring either. You called the template "Advertising the Medical Wikipedia app"; Doc James changed it to "Raising Awareness of the Offline Medical Wikipedia app". That's the point where you take it to talk, not after forcing your preferred version back into this page twice more. I understand your concern about having to update links at Cent, but that's a small price to pay for not offending other good-faith editors. Quite honestly, I'd much prefer not to have to waste my time at ANI, but I remain concerned that you're not willing to own up to mistakes like 22 reverts with no reason other than the edits you reverted didn't seek consensus beforehand and calling an RfC with a non-neutral title. --RexxS (talk) 19:33, 29 March 2017 (UTC)
Euphemize wasn't the best description, though it is not necessarily inaccurate; it and the rest of my edit summary was a reaction to behavior that I've come to expect from some wp:med participants. I created it at Title X (creation), Doc James changed it to Title Y (Bold), I revered it back to X (Revert) - that is the point where discussion should have taken place. Doc James shouldn't have changed it a second time (Discuss), especially as the title they changed it to was not any better neutrality-wise. The over 20 reverts you mention: Doc James added {{offline|med}} to a group of articles (Bold), I reverted the additions notifying them that the change was contentious and suggesting a venue for discussion (Revert), Doc James ignored that and restored them all (Discuss). History is important for context: Wikipedia:WikiProject Medicine/App/Banner was added to the top of a few articles, some about a year ago, and at least one with the edit summary "one week trial". I'm not sure if there was any local consensus at that point, but editors removed the banners, and they were restored by members of the WikiProject. Wikipedia:Miscellany for deletion/Wikipedia:WikiProject Medicine/App/Banner began. It was closed as "Keep, but not to be inserted into articles without obtaining consensus to do so." Editors removed the banners from the articles for a second time per that consensus, but again, members of the WikiProject restored them. Wikipedia:Village pump (proposals)/Archive 138#Use of Wikipedia:WikiProject Medicine/App/Banner on articles is opened, and finally 3 months later, the banners were removed after being present at the top of articles all that time (since the MfD) against community consensus. That's all I have to say on the matter here, as not to further detract from the RfC. — Godsy (TALKCONT) 04:26, 30 March 2017 (UTC)

I think it would be worth showing the actual template in question, to allow those unfamiliar with the previous debates to get an idea of what we are discussing. --RexxS (talk) 18:29, 29 March 2017 (UTC)

Thanks User:RexxS have moved to the top of the RfC. Doc James (talk · contribs · email) 18:38, 29 March 2017 (UTC)

If it is advertising, then it is advertising for something benign. The real offender is the link to the "Wikipedia Shop" selling T-shirts which appears on every page. Matthew Ferguson (talk) 18:51, 29 March 2017 (UTC)

The app is developed by volunteers at WPMED and Wikimedia CH. It is free and without advertising. The development cost (paying for programmers) is covered by movement funds. We are not "selling" anything so the user of the term "advertising" IMO is inaccurate. Doc James (talk · contribs · email) 19:15, 29 March 2017 (UTC)
agree--Ozzie10aaaa (talk) 19:40, 29 March 2017 (UTC)
Promotion/advertising/raising awareness/etc. It's semantics. I feel the reason this is an issue with some is that it represents placing a link on encyclopedia pages to a program which is not directly related to any given encyclopedia topic. Matthew Ferguson (talk) 20:40, 29 March 2017 (UTC)
It's more placing a link to the data - i.e. the compressed Wikipedia content. Surely the program (offline browser) is incidental. Wouldn't the reason you suggest be as logical as having an issue with the [Download as PDF] link, which is on every article page, because Adobe Acrobat "is not directly related to any given encyclopedia topic"? --RexxS (talk) 20:48, 29 March 2017 (UTC)
Invalid analogy really. 1. PDFs can be read with many programs, 2. downloading the article as PDF does not require you to download any program in particular, 3. the link gives you a PDF of the article you were on, I assume the link to the medical app will not directly link you to the article you were originally on. Matthew Ferguson (talk) 21:10, 29 March 2017 (UTC)
Not really. 1. ZIMs can be read by many programs; 2. downloading the data does not require you to download any program in particular – especially as ZIM is an open and standardized file format, unlike PDF; 3. the link gives you all of Wikipedia's medical content, including the article you are on, which allows you to go to all of the other medical articles that the article has wikilinks to (unlike a PDF). --RexxS (talk) 22:16, 29 March 2017 (UTC)
Yup exactly. The main WP app should be reading ZIMs soon aswell.Doc James (talk · contribs · email) 22:48, 29 March 2017 (UTC)
Clicking the "download as PDF" gives me a PDF of the article I was on. Clicking this link takes me to a description page about an app which I would have to download, which I would then have to navigate to find the article again. This is what is meant by not directly related to any given encyclopedia topic. Matthew Ferguson (talk) 19:54, 30 March 2017 (UTC)

Blockers to having short description on mobile[edit]

Overall I think having short descriptions on mobile is useful. This is now turned off per the above. What things do people feel are needed before they would be comfortable seeing it turn back on again? For me it is:

1) The ability to JUST have changes to the definitions on WD occur in my watchlists. And for this to be turned on by default (with the option for editors to turn it off).

2) The ability to have a local short definition override the one from WD. This should not be associated with infoboxes for all the obvious reasons but could be template based.

Doc James (talk · contribs · email) 17:31, 30 March 2017 (UTC)

  • as far as I'm concerned there were no blockers before, so neither are there now. Just wanted that noted, for all the thousands of ppl who did not ask for this to be disabled. I do think it's a bad idea to build a shielding layer that overrides Wikidata (again, flagged revisions-like solutions seem more suitable for this problem and could also deal with Wikidata property usage in info boxes perhaps). Inline presentation and editing might be nice enhancements (just append below the title, and only for autoconfirmed users initially). —TheDJ (talk • contribs) 20:23, 30 March 2017 (UTC)
And I am sorry that you cannot see what a breach it was of the basic relationships among the projects under the WMF umbrella, for the Reading team to unilaterally decide to tack content from a different project onto en-WP content and at that, content that is not governed by the basic policies of en-WP, and that is not generated and changed by the processes that have made en-WP whatever it is among the various WMF projects. I don't want to exaggerate but there was a constitutional crisis ~kind~ of thing underlying this. Jytdog (talk) 20:54, 30 March 2017 (UTC)
  • Fellow editors, this section is for discussing what you see as blockers to restoring the short definitions in mobile. User:TheDJ sees no blockers. Jytdog I would be interested in hearing what you think would be required before you would be okay with seeing the short defs return. Doc James (talk · contribs · email) 21:22, 30 March 2017 (UTC)
    I should point out that these definitions are still visible in VE, in the link dialog; they have not been disabled there. I would think the argument to disable the short definitions would apply in VE too. Mike Christie (talk - contribs - library) 21:24, 30 March 2017 (UTC)
User:Mike Christie Were do you see the short defs in VE? Doc James (talk · contribs · email) 21:27, 30 March 2017 (UTC)
Edit an article in VE, type in Newport and select that, and press Ctrl-K to bring up the link dialog. You'll see a list of possible link targets, each followed by the short definition. Mike Christie (talk - contribs - library) 21:29, 30 March 2017 (UTC)
Ah that is cool. I am fine to see that stay. That is not forwards facing to the reading public. Doc James (talk · contribs · email) 21:31, 30 March 2017 (UTC)
  • as i understand it
    • there are people who want this field drawn from Wikidata, and to be good and useful (e.g. this comment from User:PrimeHunter) and having a local override is .. not elegant, breaks things etc.
    • these same people generally want to have the en-WP community monitoring these fields and editing and improving them. They see that as a win for everybody, as this label can be used in lots of places.
    • from that perspective, making the label visible in desktop en-WP and easily editable and not over-ridable is the way to go.
    • in my view, while i get that, i think these people fail to recognize that volunteer time is the lifeblood of this project and every WMF project, and that their line of reasoning is basically blackmail similar to the orangemoody scheme - it sounds like this: "I am going to stick some words from Wikidata onto this en-WP page. Fix it in Wikidata if it goes awry and if you don't, well too bad for en-WP". (I know that is not the intention, but as someone to whom Wikidata is peripheral and has no interest in it, that is what it sounds like to me.) It is siphoning off volunteer time and attention to en-WP to benefit Wikidata and whatever else people want to feed from that. My commitment is to en-WP. That is what I volunteer for.
    • What is more foundational are the basic "constitutional" issues here. Every project has its own consensus, own policies and guidelines, etc. Wikidata is a young project with few policies and will have its own trajectory in developing them. It isn't appropriate, and I have no desire to even try, to enforce en-WP policies in a project where en-WP policies have no consensus (the bedrock of all WMF projects) and do not apply - it is disrespectful to the Wikidata community and a clash of mission and values that makes sense for no one.
    • If there are aesthetic issues with presentation of en-WP articles in mobile, the right answer is for the Reading team to explain that and ask the en-WP community to add a new element to the Manual of Style - namely the "brief description" and that is something we can build with time. Or the like. Jytdog (talk) 22:40, 30 March 2017 (UTC)
So are you recommending that these details simply be hosted locally on EN WP all the time? Doc James (talk · contribs · email) 23:05, 30 March 2017 (UTC)
If this is is done it should be done on-wiki. It just needs a simple template, something like {{lang}} which adds CSS that helps browsers decide how to display foreign language text. Then the CSS for desktop hides it, the CSS for mobile shows it. If editors want they can override this in their own CSS to either hide it in mobile or more usefully show it in desktop, to make it easier to spot and fix problems, easier to maintain a consistent style and approach which is badly lacking in these at the moment.
I thought the whole point of Wikidata was data. Data that could be usefully hosted off en-WP, so other language wikipedias could use it, and discussions about using Wikidata on en-WP have all been about such data. These comments are neither data nor useful for other languages. I can see why Wikidata might have its own descriptions but from just a short time browsing them they are unsuitable for use in articles, and absent the sort of editorial controls we have here they probably never will be suitable.--JohnBlackburnewordsdeeds 23:14, 30 March 2017 (UTC)
Doc James, kind of yes, but your question is kind of... begging the question. There is nothing existent to "host" in my view. The label field in Wikidata is something that the WMF Reading team decided would be useful in many ways. One of those ways, was providing a mini-WP:LEAD for en-WP articles on mobile. (as I wrote above, in my view their decision to insert the Wikidata label into en-WP content on mobile breached fundamental norms about inter-project relations and governance. And as JohnBlackburne noted above, with these labels we are in a very different ballpark from data items like half-life of drugs.) It it not clear to me if the en-WP community will even want to have a mini-LEAD (it may well do, but this needs to be discussed), and if it does, the en-WP community is going to have to figure out how to create them, format them, etc. For sure, the Reading Team should explain why it would be good to have a mini-LEAD for en-WP articles, and what kind of formatting would be most useful for the Reading Team. When you get to all of that -- yes, the mini-LEAD would be native en-WP content hosted on en-WP, like all en-WP content is. Jytdog (talk) 05:36, 31 March 2017 (UTC)
". . . yes, the mini-LEAD would be native en-WP content hosted on en-WP, like all en-WP content is." I think that is the crux of this issue, and should be one of the main points of any RfC. Having en-WP edited outside of en-WP, without our even knowing about it or being able to see it here, is mind-boggling to say the least. First Light (talk) 06:08, 31 March 2017 (UTC)
  • I'll definitely support option 1, but I'm quite conflicted about 2. IMO the point of these descriptions is that they already exist on Wikidata and are very common. I would rather not have them than attempt to move them to enwiki, it would just add another thing that we're "supposed" to add to articles (i.e. infoboxes). I'd like to make two suggestions that should be implemented before the descriptions are returned:
  1. Add an edit link next to the description so readers and editors know how to change it.
  2. Enable this on desktop, since the majority of our editors (not readers) use desktop.
Also, I started a thread on Wikidata about the BLP policy. Laurdecl talk 01:55, 31 March 2017 (UTC)
Some folks from the Wikidata community have responded and it is interesting to see how the WIkidata community views "BLP-like" issues. Laurdecl also found the policy proposal there (has existed since 2013) Wikidata:Living people. Jytdog (talk) 15:54, 31 March 2017 (UTC)
  • I think the original idea involves the fact that a mobile can quickly get the description from Wikidata without the overhead of downloading a big enwiki article. That allows (I think) the ability for a mobile user to find articles based on text in descriptions, and to choose whether to visit an article based on the description. Future developments are sure to want to automatically display more stuff from Wikidata in enwiki articles. A proper solution requires an option (default on) for an editor watching an article to also see only related Wikidata changes in the watchlist that affect text that could be displayed for a mobile user. For example, if someone changes the French description, people at frwiki would be alerted, while an English description change would appear in enwiki watchlists. Further, there must be a way that is clear and quick to temporarily suppress text from Wikidata being displayed while someone prepared to examine and fix the Wikidata is found. The "suppress" would prevent the offending text being shown on any platform (for example, it might be an egregious BLP problem or blatant vandalism). An alternative might be a system that is clear and quick to click a button at enwiki to temporarily wind back the last set of Wikidata changes. Johnuniq (talk) 02:14, 31 March 2017 (UTC)
  • 1) Have discussion whether we even want such short descriptions, and what they should be used for (top of mobile, top of desktop, search results, related articles, ...?)
  • 2) If 1) gives a "yes", design a method (probably a simple template) to incorporate this on enwiki. Collaborate with the WMF so that we produce something which they can use here and can use on other languages if they want it (not the other languages copying our descriptions, but the same template being used across different languages, to ease the technical implementation).
  • 3) If wanted, do a one-time bot run to import the current Wikidata descriptions into that new template. The suggestion "2" by Doc James at the top is a worse version of this; why tell the WMF to write software that does "if template:description exists on enwiki, use template:description; else use wikidata:description" when you can much more easily say "if template:description exists on enwiki, use template:description" and don't bother with the second part? Like multiple people have argued, this is not the kind of data Wikidata was designed for, this is language-dependent data (or "text" as most people would call it) which can and should better be hosted at the language-specific page where it will be used anyway. Of course Wikidata is free to have descriptions if they believe this to be useful for them (we are not going to impose what Wikidata can have or not), but they shouldn't be used anywhere on enwiki.
  • Summary of my position: if it is decided we want this, we need to design a simple template for it on enwiki, and the WMF should use that and only that to populate the things until recently taken from the Wikidata descriptions. Fram (talk) 07:04, 31 March 2017 (UTC)
    • There is the consideration of "without the overhead of downloading a big enwiki article" I mentioned just above. Getting mobile correct is very important, and while obviously the situation where people can add damaging headlines to articles for mobile users while escaping enwiki scrutiny is untenable, importing all the data to here won't work. Johnuniq (talk) 08:00, 31 March 2017 (UTC)
      • I read your comment, but I don't think it is correct. If you read the article, with the description on top, you need to download the article anyway. And if you get the descriptions in search boxes, it is the software that fetches the description from either Wikidata or from the enwiki article, and only returns that description to the search results (or the related articles, or...). In what situation would you need to fetch the whole article but not display it and would thus fetching the Wikidata page instead (assuming that that is significantly smaller) make an important difference in overhead? The heav work would be done server-side, for the end-user this should make no difference (on the contrary, when you actually see the article, no link to Wikidata needs to be made for mobile views in my solution, while it needs to be done in the current situation). Fram (talk) 08:13, 31 March 2017 (UTC)
        • I see what you mean. I have only played with the mobile view and thought I saw a case where a mobile might get the wikidata directly. As usual, there does not appear to be a page outlining what it is all about, but I can see that a very fancy index (full text) would be needed for a server to efficiently find descriptions stored in enwiki articles for a search. Johnuniq (talk) 09:10, 31 March 2017 (UTC)
          • AFAIK, the search doesn't work on the descriptions, you search for article titles, but the search results include a short description to help you pick the right result. So no full text index is needed for this. And on the other hand, we presumably already have a full text index, since you can "search within pages" already! Fram (talk) 09:26, 31 March 2017 (UTC)
        • If you read the whole article then it has to be downloaded but that's not the case when the description is with search results. For providing fast search results it's very useful when there's a simply database lookup. ChristianKl (talk) 12:20, 31 March 2017 (UTC)
  • The idea behind it is worthwhile (for mobile viewers). It should in no way be dependant on Wikidata. Wikidata has no policies that would ensure the quality (and legality!) of the description in line with the various projects. Short of the active userbase of EN-WP going over to wikidata and forcibly installing all our policies, thats unlikely to happen (and would probably piss off the other languages too. There are almost no technical or policy-based reasons this cant be done here or at any of the other language versions of wikipedia through a template to be used by the mobile viewer. Its a fact Wikidata does not have a fraction of the ability to spot and fix vandalism OR NON POLICY-COMPLIANT CONTENT so anything like this needs to be somewhere where an active userbase is already curating the articles. Only in death does duty end (talk) 08:42, 31 March 2017 (UTC)
  • Pinging User:OVasileva (WMF), I mentioned above that wikidata shows up on desktop view in the search bar at www.wikipedia.org. That should be turned off too if consensus is not to allow wikidata to appear on enwiki. NPalgan2 (talk) 16:06, 31 March 2017 (UTC)
    • Howdy NPalgan2, I'm not sure I understand. Wikipedia.org is not English Wikipedia (more on Meta). Regardless, as others have mentioned in this discussion it appears that the Wikidata descriptions showing up in other parts of the interface (like the visual editor link inspector) are permissible. (I was wrong, see below) CKoerner (WMF) (talk) 14:56, 3 April 2017 (UTC)
      • Not really, no. The RfC was not perfectly worded, so we can't automatically assume that it applies to all instances of the Wikidata descriptions appearing on enwiki. However, there is no reason to believe that what is controversial in one instance would be suddenly unproblematic in another (say, in search results or as the descriptions on "related articles). It is much more likely that most people who wanted to get rid of the descriptions (temporarily, definitively, or as a Wikidata-driven item) wanted this to happen in all instances of these texts on enwiki (not on other sites, that's their prerogative). It would be best if for the time being, this was disabled on enwiki completely (i.e. the descriptions as given on Wikidata are not displayed anywhere on enwiki, whether in popups, text, search, ...). Fram (talk) 15:45, 3 April 2017 (UTC)
      • I mean, just look at recent examples; for 56 minutes today, Adam Sandler (BLP, viewed by 10,000 people every day) had the nice description " Doctor druing the death of the jews hail hitler". As long as this can't be controlled (corrected, protected, ...) at enwiki, this shouldn't appear anywhere on enwiki. Fram (talk) 16:07, 3 April 2017 (UTC)
        I agree with Fram. I would be very sorry to see the VE link inspector usage disappear, as that's very useful, but I don't see how to justify exempting certain usages if the problem is not with the usage but the content. However, I think this RfC only applies to what it says it applies to. CKoerner, can you give a list of the different places this data is used on en-wiki? Perhaps some can be justified but it would help to know what the full list is. Mike Christie (talk - contribs - library) 16:57, 3 April 2017 (UTC)
        • Ah, sorry I misunderstood. I was trying to catch up after time away and assist Olga as she is out today. My apologies for not connecting the nuance in the discussion. As for the question on where else the Wikidata descriptions are used on English Wikipedia? The mobile web article descriptions (since removed), search results on the mobile web, and the visual editor link inspector (both mobile and desktop). The descriptions are also used in the wikipedia.org portal (pulling the appropriate language label depending on browser settings or changing the language in the search box). They are used in the mobile app for searching and in the articles as short descriptions. CKoerner (WMF) (talk) 19:26, 3 April 2017 (UTC)
          • User:CKoerner (WMF) thanks for that info. As I have noted, in my view the decision by WMF reading and search teams to take that text field from WD (which is not "data"), relying on the WD community (which is young, is not governed by any policies that I have been able to find, and has really undeveloped/poor community governance processes) and putting all this weight on it, in both search and reading, was unwise and something you all should back out of. That field is very unreliable, and hanging these important functions on it runs counter to the mission of WMF which is to provide the public with accepted knowledge. I understand the temptation to reach for it, but in my view this is a mission-level fundamental screwup. Jytdog (talk) 18:00, 5 April 2017 (UTC)
            • Blarg, I just saw this comment here after I left a response on your talk page. What timing. CKoerner (WMF) (talk) 20:36, 5 April 2017 (UTC)
  • Using Wikidata at all has been messy and controversial. Remotely hosting language-specific content doesn't make sense at all. The WMF has suggested moving the lead above the infobox, which may help. Perhaps the beginning of the lead can be grabbed as a "short description" to use in other places. If we do want to have dedicated short-descriptions for each article, then we should have a template for it. That template would be hidden on desktop, and that content could be grabbed for short descriptions on search results and elsewhere. (If the template is missing, just grab the beginning of the lead.) If we make description-templates, we could import the existing Wikidata descriptions. However rather than a pure bot job I would really prefer if it were semi-automated, with someone skimming to ensure that the short-description was roughly compatible with our existing lead. That concern is not just about importing vandalism - in some cases the wikidata item may not precisely match the article's concept. The description may have been written without even looking at the article here. Alsee (talk) 00:36, 1 April 2017 (UTC)

Enable Visual Editor on the Wikipedia namespace[edit]

I do a lot of edit training mostly to or through the GLAM sector. My earlier edit training using the wikitext editor produced very few ongoing contributors. However, I now teach Visual Editor (VE) and this has been very popular (including the those previously taught the wikitext editor) and I am seeing the VE training producing more ongoing contributors (e.g. [10]) which is a good result for the VE. The stumbling block I am now enountering is these users increasingly want/need to contribute to pages in the Wikipedia name space, where the VE is not enabled. Here are some examples:

  • VE users cannot use the VE to report bugs or give feedback on the Visual Editor because it is located at Wikipedia:VisualEditor/Feedback, so who knows what bugs/feedback are not being reported because of this
  • VE users cannot use the VE to get help from the Wikipedia:Teahouse
  • the GLAM work is documented in the Wikipedia name space. So I have VE-trained libraries wanting to edit these pages about Wikipedia projects involving their library but can't. My only workaround is to redirect the page from the Wikipedia name space as a subpage of a User account (where the VE is enabled). See this example [11].

We need to reduce the barriers to VE users from being unable to contribute more fully. I note that Talk is not currently enabled for the VE due to the earlier plan to replace Talk with Flow (which appear to have been dropped). At this time, the VE is currently unable to produce indentation as the colon does in wikitext, so I am not proposing enabling the VE on Talk pages at this time. However, opening up the Wikipedia name space would facilitate greater engagement for our new VE cohort of contributors. Kerry (talk) 02:14, 30 March 2017 (UTC)

@Kerry Raymond: Wikipedia pages have lots of odd markup that I'm not seeing as a good fit, for example look at this page - now head over to testwiki:Test1MarchA or test2wiki:Test2017MarchA and try it out with the visual editor. — xaosflux Talk 02:22, 30 March 2017 (UTC)
I think there are some problems with the sites you used for the copy (red links everywhere). But I copied this page into a the sandbox in my user space (i.e. still on the enWP site) and I didn't see any big issue with editing it in the VE. Kerry (talk) 03:23, 30 March 2017 (UTC)
The primary issue I found was that you can't properly indent comments in threaded discussions. Trying to add a comment here, for example, tried to add a paragraph one indent level back, and it wasn't obvious to me how to get it indented out again to the right place. VE also seems to add a lot of whitespace all over the place when editing, making the page very hard to read. Sam Walton (talk) 10:00, 30 March 2017 (UTC)
Indeed. VisualEditor is not supposed to be used in discussions at all. Jo-Jo Eumerus (talk, contributions) 14:43, 30 March 2017 (UTC)
If folks object to it being enabled everywhere, perhaps some method to enable it on a page-by-page basis where demand for such a thing exists? Lankiveil (speak to me) 04:18, 30 March 2017 (UTC).
  • Support page by page enabling of VE on non main space pages. Doc James (talk · contribs · email) 11:18, 30 March 2017 (UTC)
    • If I remember correctly, it's not technically possible to enable VE on a page by page basis. —TheDJ (talk • contribs) 14:33, 30 March 2017 (UTC)
      TheDj: Would it be possible to enable VE globally for a namespace, suppress the edit tab at the top of the page (so VE would work but you'd have to construct the URL), and then unsuppress on a page-by-page basis? Mike Christie (talk - contribs - library) 14:41, 30 March 2017 (UTC)
      • If it is possible to enable "FLOW" on a page by page bases I am sure they can make VE enabled on a page by page bases. Doc James (talk · contribs · email) 17:22, 30 March 2017 (UTC)
        • its software, with infinite resources almost everything is possible. But if it were easy to do, I'm pretty sure the VE team had done it by now, since it seems to align with their own desires —TheDJ (talk • contribs) 20:33, 30 March 2017 (UTC)
  • support per Doc James--Ozzie10aaaa (talk) 17:29, 30 March 2017 (UTC)
  • Oppose because it would cause VE to be enabled on some discussion pages where it doesn't and was never intended to work properly. Page-by-page enabling doesn't exist yet; also the proposer's suggested use cases involve discussion pages i.e. /Feedback and Teahouse. BethNaught (talk) 17:51, 30 March 2017 (UTC)
  • Oppose under the current rationale, because it is about talk pages (that happen to be on Wikipedia namespace rather than Wikipedia talk namespace) and VE can't deal with talk. No prejudice against relisting with a different use case. —David Eppstein (talk) 18:05, 30 March 2017 (UTC)
  • Oppose no, please. It would mean enabling VE on ANI, for one. --Rschen7754 00:18, 31 March 2017 (UTC)
  • Oppose proposal as is - as far as training goes: train users that wikitext is a thing that they will need to learn if they want to do more then edit articles. — xaosflux Talk 02:30, 31 March 2017 (UTC)
  • Oppose. Let's teach people to Wikitext instead. bd2412 T 02:34, 3 April 2017 (UTC)

RfC about marking the Featured portals process as "historical"[edit]

Portal:Featured portals and related pages have just been boldly tagged as {{historical}}, as there has been a lot of time without any activity in them. This was announced at Portal talk:Featured portals, but being such a big step, it should be discussed at a more visible location, like here. First of all: which would be the best venue to discuss this and find out which is the consensus? A thread here, a RFC, some other location?

Second: do everyone in here agree with this? Should we support the historical tag?

Third: if those pages become historical, should we remove them from the general Portal:Featured content? And what about the portals with featured stars? Do they get to keep them, or should a bot remove them? Cambalachero (talk) 18:48, 30 March 2017 (UTC)

  • Support marking it as historical since the process was (a) pointless (the proportion of Wikipedia's readers who navigate via portals is miniscule—even Portal:War, the most active of the lot, only gets about 300 views per day) and (b) completely moribund, although if you want to do it by the book just pick a page (here is fine) and put a {{RFC}} tag on it. Following the precedent of the killing off of Wikipedia:Featured sounds, just remove it from those places where it's currently listed. ‑ Iridescent 19:05, 30 March 2017 (UTC)
    • I have added an RfC tag here (and changed the section header accordingly) as we're here now. BencherliteTalk 19:34, 30 March 2017 (UTC)
  • (edit conflict with Iridescent, which whom I agree) In fact I also announced it at Wikipedia talk:Portal#Portals are moribund, an active conversation about the whole system of portals. My bold move today followed on from:
(a) years of declining interest in the concept of featured portals - visit Wikipedia:Featured portal candidates/Featured log and you'll see the decline in activity; and
(b) an attempt to start a discussion at Wikipedia talk:Featured portal candidates#Did anyone notice we lost a Featured Portal director? last December, which went unanswered, save from a comment from the sole remaining FPo director OhanaUnited at User talk:Bencherlite/Archive 31#Re: Featured portal process. He said "Let's wait for others to chime in and see if interest level remains or sparks more interest into the process."
Since December, nobody has chimed in and there has been absolutely no interest shown by anyone in the process - no activity on existing nominations to add or remove featured status, let alone new nominations (and when one removal nomination is nearly 2 years old, that tells its own story), and no activity at WP:Portal peer review either (which has been dead for years).
I used to be very interested and active in the featured portal process. I created Portal:Law of England and Wales and got that to featured status, and I used to comment regularly on nominations (even closing them from time to time, and carrying out various clerical tasks to keep the process running and properly documented). However, I lost interest as has everyone else... not even points for featured portals in the WikiCup has been enough to spark interest.
As for the questions raised by Cambalachero: (1) here is as good a place as any; (2) we don't need "everyone" to agree, of course, merely consensus that the FPo process has had its day; and there's no point in anyone saying that the featured portal process should remain unless they can put forward some ways in which the process can be made meaningful; (3) If FPo is "historicalized", yes we should remove it from Portal:Featured content in the same way that the featured sounds process was removed after that stopped in 2011, and we can remove the bronze stars; the categories, templates etc can be tweaked or deleted as appropriate unless the FPo process starts up again. If someone is looking for bold type, support marking historical. BencherliteTalk 19:31, 30 March 2017 (UTC)
  • Endorse marking as historical. There's nothing wrong with portals, except that almost nobody uses them or even knows they exist. Frankly, I didn't know neil right now that we ever had a featured portal process. Beeblebrox (talk) 20:00, 30 March 2017 (UTC)
  • I'm indifferent on this because it lost its critical mass after overall editorship declined. OhanaUnitedTalk page 20:10, 30 March 2017 (UTC)
    • I don't think the criticality parameter most relevant is of mass of editors, but the growth rate of new articles, which correlated to the growth rate of new editors, which ceased to be exponential in 2006-2007. --SmokeyJoe (talk) 20:34, 30 March 2017 (UTC)
  • Would this include removing the stars from the featured portals? Doc James (talk · contribs · email) 20:13, 30 March 2017 (UTC)
  • What's the point of keeping a bronze star on a portal when there's no process left to remove it? It just devalues the bronze star everywhere else. The promotion will remain documented in the article history on the portal talk page; for featured sounds, there was no article history on a talk page, so the template had to stay but suitably reworded. BencherliteTalk 20:41, 30 March 2017 (UTC)
  • Either archive things as is, or do a review process and then archive. I don't see any risk of devaluing bronze stars. There will be reasons for few people to review the old Portals, and it is an important part oft he historical record which were featured. I wouldn't object to altering the star to a star with a date range for the period of time it was considered featured. I do object to altering an archive if it is to hide the fact that it was featured. --SmokeyJoe (talk) 22:39, 30 March 2017 (UTC)
  • I support User:Train2104's suggestion below, altering the star's image to indicate that they are historical. --SmokeyJoe (talk) 22:42, 30 March 2017 (UTC)
  • Support. --SmokeyJoe (talk) 20:39, 30 March 2017 (UTC)
  • Support Am of the opinion that the stars should be deprecated. Doc James (talk · contribs · email) 20:44, 30 March 2017 (UTC)
  • Support. It is historical, with the declining interest, so by all means mark it so, and lose the stars, too. Bishonen | talk 20:53, 30 March 2017 (UTC).
  • Support. Those portals that got stars should keep an indication, but they should be very visually distinct from the true stars (i.e. an outline, grayed out, etc.) – Train2104 (t • c) 20:55, 30 March 2017 (UTC)
  • Support greyed out stars, or outlined ones, per Train. Iazyges Consermonor Opus meum 21:04, 30 March 2017 (UTC)
  • Query—what of the featured portals that are still updated every month with new content? Imzadi 1979 → 21:13, 30 March 2017 (UTC)
    • Is there a list of portals, featured or not, that are updated every month with new content? Do they have any impact? --SmokeyJoe (talk) 22:43, 30 March 2017 (UTC)
  • Comment - I'm not so sure that we should get rid of the Featured Portal process. I continue to maintain two featured portals, Portal:Maryland Roads and Portal:U.S. Roads. Also, if we were to get rid of the process, I'm not so sure I like the idea of removing the stars from the portals that editors worked to get. That is pretty much undoing achievements of those editors simply due to the increased inactivity of Wikipedia, though some editors may be doing their part to keep Wikipedia and the featured portals updated. If we were to go through with shutting down Featured Portal, I would still keep the stars on those portals that were featured at the time of the shutdown. Dough4872 00:43, 31 March 2017 (UTC)
  • Not opposed I've added articles to portals myself, a few times, mostly Portal:Guatemala; and as I did so I noticed the remarkably low activity. The page is currently getting an average of 20 views per day, and this is a country-wide portal. Most of these probably come from the fact that it is linked at the bottom of most sizeable Guatemalan articles, of which there are quite a few. The more obscure and specific a portal gets, the fewer things there are linking to it, and its utility declines. Personally, I do not ever recall using a portal for navigation. I can see why folks may be attached to ones they have helped create; but surely we could at least mark the unused ones as historical? Vanamonde (talk) 04:30, 31 March 2017 (UTC)
  • Merge featured portals with featured lists. De.wiki (second-largest Wikipedia if you don't count the bot-inflated ones) has the "informative" classification, which is used for both portals and lists. KATMAKROFAN (talk) 04:43, 31 March 2017 (UTC)
  • Support: I forgot to clarify it when I started this thread (it was Bencherlite who tagged the pages, I merely reported it because it deserved some discussion), but I do support tagging the projects as historical. I also support the idea of removing the stars in the process: as he pointed, many featured portals have low quality (a consequence of the lack of oversight, improving and watching). But perhaps we can replace that with a "hall of honor" page, that lists the portals that once achieved featured status. Or a navbox at the bottom, listing all those former featured portals, while also making it clear that their featured process is deprecated. Cambalachero (talk) 17:59, 31 March 2017 (UTC)
  • It's a tough call. On one hand, if it was doing a lot of good, one would think that there would be more nominations. On the other hand, it's not doing any harm to the project either. One could argue that it forces people to work on more "critical" enterprises, but I'm not sure I subscribe to that viewpoint. I do think that keeping the stars, but putting a disclaimer on them is a good compromise. --Rschen7754 01:07, 1 April 2017 (UTC)
  • Support: as someone who's created many many many portals it's with a heavy heart I say I support. I also believe that the feature status should be removed. Was a big supporter of these when they first came out... that's why I created many but I see that they're not used and nor are they maintained properly....with vandalism unnoticed a lot.--Moxy (talk) 17:49, 3 April 2017 (UTC)
  • Support proposal. In fact, all portals should be tagged as historical. Other than amusing some of the editors these portals serve no encyclopedic purpose. 106.209.153.61 (talk) 06:14, 5 April 2017 (UTC)
  • Support marking featured portals as historical and portals in general. Maintenance costs are exceeding benefits to readers, and there are now many alternatives to portals to easily navigate between related articles (categories, navboxes, lists, what links here, etc). ~ Rob13Talk 22:40, 5 April 2017 (UTC)
  • Support, seems reasonable as there isn't much activity around this anymore. Regarding the stars, either remove them or leave them. I don't like the idea of using grey or outlined stars. Kaldari (talk) 02:02, 6 April 2017 (UTC)
  • Comment – A bit indifferent about marking the Featured portals pages as historical, but the featured portal stars should not be removed from all portals that have achieved this status as a broad-sweeping default that lacks any oversight other than simply indiscriminately mass-removing the star graphic. The latter would serve to unnecessarily denigrate significant work some users have performed on portals and in the featured portal review process. It would be quite unfair to those users to automatically dismiss and disqualify their work in this manner. Rather, featured portals could be de-listed on a case-by-case basis, via the discussion process, which could occur on talk pages or elsewhere. North America1000 07:10, 8 April 2017 (UTC)

Make Wikipedia Great Again[edit]

[4-1] (Note: Hovering over the wikilinks is part of the joke.)

Make Wikipedia Great Again! HotdogPi 02:20, 1 April 2017 (UTC)

This sounds to me the type of thing which relates to things discussed on Wikipedia: Perennial proposals. Carltonio (talk) 20:50, 1 April 2017 (UTC)

Sorry - I have just spotted the acronym! Oh, well, as I type these it is after noon on my side of the pond! Carltonio (talk) 20:52, 1 April 2017 (UTC)

I think we should build a firewall around Wikipedia and make the IPs pay for it! Chuntuk (talk) 11:58, 4 April 2017 (UTC)

Remove the Citation needed template and make people use Citation needed span[edit]

In my opinion the {{Citation needed}} is unnecessary and hard to understand when it is used (In a paragraph containing a sentence that doesn't require a citation because it is obvious and a sentence that requires one, a person wouldn't know which part needs a citation). {{citation needed span}} is more understandable. For the 700,000 pages using {{Citation needed}} we can change them so that the whole paragraph is added to the span automatically by a bot. Uni3993 (talk) 04:57, 2 April 2017 (UTC)

  • Oppose both are useful, and I have no problem with allowing people to use either as they see fit. --Jayron32 02:58, 3 April 2017 (UTC)
Comment How about a wiki markup tool which allows the editor to select the span and then apply the citation needed template by clicking the tool button, much in the way one would do for a subscript or reference? The tool could then automatically produce a dated markup. I would guess the majority of editors are not even aware that {{citation needed span}} option exists. If no span is selected it would default to the preceding paragraph. • • • Peter (Southwood) (talk): 06:26, 3 April 2017 (UTC)
Such a tool has been discussed for a number of years both among Wikipedians and developers. During this years MediaWiki Developer Summit it became much more tangible concept. This is on the radar of developers and is being taken into account in the long term vision of the software development. —TheDJ (talk • contribs) 08:00, 3 April 2017 (UTC)
Is it a difficult thing to do? • • • Peter (Southwood) (talk): 08:47, 3 April 2017 (UTC)
If you haven't disabled the CharInsert gadget, you can get most of what you asked for easily enough, at least in the standard wikitext editor (not sure about VE or the 2017 VE-based wikitext editor). Stick this in your common.js:
if ( !window.charinsertCustom ) {
    window.charinsertCustom = {};
}
if ( !window.charinsertCustom['Wiki markup'] ) {
    window.charinsertCustom['Wiki markup'] = '';
}
window.charinsertCustom['Wiki markup'] += ' \x7b\x7bsafesubst:citation.needed.span|text=+\x7d\x7d';
if ( window.updateEditTools ) {
    window.updateEditTools();
}
Then look in the edit tools near the bottom of the edit form, in the "Wiki markup" section. If you highlight text it'll wrap it, but if you don't it'll just insert an empty template at the cursor instead of defaulting to the whole previous paragraph. When you save, Module:Unsubst will make it substitute into a dated instance of the tag. Anomie⚔ 23:33, 3 April 2017 (UTC)
Support Good idea 69.158.148.87 (talk) 18:02, 3 April 2017 (UTC)
{{citation needed}} also has |reason= but few use it. -- GreenC 14:28, 3 April 2017 (UTC)
Possibly mainly not used by people who don't know that it exists. I only recently found out by accident, though I have been using the basic template for years. It is the sort of template that one discovers by seeing it in use, then doing the same thing oneself, and that almost always means that one is exposed to the reasonless version, and then produces more of the same. It may be obvious after the fact that there should be a reason, but many things that should be are not. • • • Peter (Southwood) (talk): 21:05, 3 April 2017 (UTC)

It's not broken IMO. The great majority of the citation-needed tags I see are placed where it is clear what is meant. Nor is the "reason" field usually needed, since its clear what the reason is: there's no ref, and one is desired. Citation-needed-span is also good sometimes and should be popularized, I agree. The select-and-click markup idea sounds good too. However, the current Citation-needed-span makes the source text a little more complicated to read, if you're working in the basic editor, so that's a small negative. Herostratus (talk) 19:36, 3 April 2017 (UTC)

I'm not familiar with span, so I guess I shouldn't cast a "formal" "vote", but otherwise I agree with Hero's comments above. Besides, if one isn't sure what's being questioned, one can always ask the tagger or start a Talk page discussion. DonIago (talk) 20:27, 3 April 2017 (UTC)
  • Oppose as I agree 100% with @Jayron32: above. GenQuest "Talk to Me" 20:04, 3 April 2017 (UTC)
    I have found by experience that asking the tagger seldom gets a useful answer. If you don't get to ask them immediately they will probably have forgotten their reasoning at the time. Even tags I have made myself are often not clear when I come back later. • • • Peter (Southwood) (talk): 21:05, 3 April 2017 (UTC)
  • Oppose If it's not broken, don't fix it.ThatGirlTayler (talk) 22:54, 5 April 2017 (UTC)
  • Oppose bot modification. In many cases applying a false span for the tag is clearly worse than not indicating a span at all. Alsee (talk) 16:15, 6 April 2017 (UTC)
  • Wikipedia is famous for "citation needed". Even non editors know it well, and have an idea when it could be used. Making it span only would put it beyond most editors skills. So please keep {{cn}} and {{citation needed}} Graeme Bartlett (talk) 01:56, 10 April 2017 (UTC)

Abolish sidebar navigation templates[edit]

We now have hundreds of sidebar navigation templates that are identical (or nearly identical) to corresponding footer navigation templates. For example {{Conservatism US}} and {{Conservatism US footer}}. It is common practice to include both in any articles related to the subject. See, for example, Paleoconservatism. I don't see any point in including the same content twice in the same article. However, it is virtually impossible to keep people from adding these templates to the articles, even when one of the two templates is already present. The only practical solution, IMO, is to abolish the practice of having sidebar navigation templates. I'm not sure what purpose these templates were designed to address that isn't already handled by footer navigation templates. For anyone opposing this proposal, please explain why we need both. Kaldari (talk) 02:01, 6 April 2017 (UTC)

  • They're helpful in several ways. They're more likely to be seen than the templates at the bottom of articles. They often include images, so they contribute to the article not being a wall of text. And they help to shorten the long lines of text we have because we have no fixed width. If they're being added a lot, it means people like them. SarahSV (talk) 05:57, 6 April 2017 (UTC)
  • I'm very conflicted about these sidebar navigations. There indeed is a lot of duplication here, but there has always been a space for both of these. I think the problem is that if a series box becomes a 'let's link to everything' navbox with multiple levels of 'by default' collapsing (which ppl really need to start learning means 'only-collapsed-on-desktop'), then it's no longer working as it was intended. —TheDJ (talk • contribs) 10:43, 7 April 2017 (UTC)
  • The sidebar navigation should only have a few simple links without options to expand more links. Save that for the footer. Graeme Bartlett (talk) 01:53, 10 April 2017 (UTC)
  • I oppose any abolishment of these things. Or any rule that prohibits their use. Definitely WP:CREEP if you ask me and some of these work fine. I use the {{forensic science}} sidebar on almost every single article I care about. There is no bottom navbar for that topic. And I also agree with SarahSV. They break up the walls of text that are in the top of articles that don't have infoboxes. --Majora (talk) 02:00, 10 April 2017 (UTC)
  • Whether we need both or not, I see no harm in having them and therefore oppose a blanket abolishment of them. I would suggest that attempting to craft a more nuanced policy on nav templates may be more helpful than just trying to delete an entire category of them. Beeblebrox (talk) 02:58, 10 April 2017 (UTC)
  • We should stick with navbars and scale back on sidebars IMO. Doc James (talk · contribs · email) 09:25, 10 April 2017 (UTC)
  • Would there be any benefit in combining the templates for navboxes and navbars so that there is only one for any given subject, but it can be selected to display as either. This would allow user choice of output format, or could be linked to skin, etc. • • • Peter (Southwood) (talk): 09:35, 10 April 2017 (UTC)
    • Some more clarity around which should be used when would be useful. Doc James (talk · contribs · email) 10:32, 10 April 2017 (UTC)

Linking from Wikipedia to other wikis[edit]

Transferred from WP:AN. Nyttend (talk) 05:06, 24 March 2017 (UTC)

  • There are external wikis that specialize about one subject or another. Examples are:
  • Admittedly, these wikis may vary in quality; for example the Manchester United wiki shows evidence of not enough routine checking to remove vandalism; access to these wikis may have to be decided separately for each wiki. Anthony Appleyard (talk) 23:36, 23 March 2017 (UTC)
    @Anthony Appleyard: You can link to these wikis, but only to the "good" ones per WP:ELNO#12. --Izno (talk) 00:00, 24 March 2017 (UTC)
    Why would we link to any unreliable fan sites (which these wikis all are). The only wikis we may occasionally link to are tightly controlled, supervised ones, not truly open wikis. Links to wikia (and similar ones) should be removed from every article but the wikia one (and other very rare exceptions where the wikia is e.g. the source of a notable controversy). Fram (talk) 09:26, 24 March 2017 (UTC)
    Your stance is not reflected in ELNO, so do not portray your stance as fact. We do routinely link to open wikis (some of which are at Wikia and others which are not) to provide additional information to the reader. (Or perhaps the word "open" to you means something other than "(most) anyone can edit"?) --Izno (talk) 14:05, 24 March 2017 (UTC)
  • To me, the Casualty Wiki and the Star Trek Wiki at least, seem to be of good quality. It depends on how well each wikia is supervised by its administrators. It looks that each wikia will have to be judged separately to see if it can be listed as reliable. Anthony Appleyard (talk) 09:33, 24 March 2017 (UTC)
  • WP:ELNO#12 says: "Except for a link to an official page of the article's subject, one should generally avoid providing external links to ... [o]pen wikis, except those with a substantial history of stability and a substantial number of editors. Mirrors or forks of Wikipedia should not be linked.". That is, more or less, "one can provide external links to open wikis which have a substantial history of stability and a substantial number of editors, (but not to mirrors or forks of Wikipedia). Anthony Appleyard (talk) 09:36, 24 March 2017 (UTC)
  • Add: http://blakes7.wikia.com/wiki/Main_Page (Blake's 7)
  • Add: https://www.festipedia.org.uk/wiki/Home_Page (Ffestiniog Railway)
  • Anthony Appleyard (talk) 09:36, 24 March 2017 (UTC)
    • (edit conflict) I'm with Anthony and particularly Izno on this. I do think that such links need to be carefully marked though, perhaps a template such as {{wikisource}} but with suitable guarded wording. You'll see that other respectable websites like BBC news: Kent have a section of external links, indeed so do we on some articles. We maintain WP:NOTCENSORED internally, so why should we prohibit external links, provided there is a suitable warning about (1) no connection to WP, and (2) content unverifiable by WP. Martin of Sheffield (talk) 09:42, 24 March 2017 (UTC)
      • I am not opposing linking to external links, which is standard practice. An external link is only acceptable if it would also be acceptable as a reference or a primary source, but simply isn't used as such. The Blake's 7 wikia has had 5 articles edited the past month, 4 by IPs. I see no reason to add a link to such wikis. Fram (talk) 11:15, 24 March 2017 (UTC)
        I agree in the case of "Blake's" if those are the stats for activity. However, there are clearly wikis (Wowpedia, MemoryAlpha, MarvelDatabase, and Wookieepedia are perhaps the largest off-the-cuff) on the other end of the activity/stability spectrum which are clearly suitable for inclusion as external links here. --Izno (talk) 14:05, 24 March 2017 (UTC)
  • Those are:-
  • The amount of edits per day that a wiki gets, is not necessarily always related to how good the wiki is. If not much more new happens in that wiki's field of knowledge, i.e. if that field of knowledge becomes static, then the amount of edits per day (as distinct from people merely reading that wiki's pages) likely will tail off as the wiki's contents approach the best wording to describe that field of knowledge, perhaps with intermittent bursts of new editing when anything new happens in that field of knowledge. Anthony Appleyard (talk) 09:49, 6 April 2017 (UTC)
  • Oppose; wikis are notoriously not objective, factual, or reliable. GenQuest "Talk to Me" 15:49, 6 April 2017 (UTC)
  • Support in external links on a case by case basis. THey would not have to fall into the same quality as references. The criteria should be that they are useful to the reader. Bias or speculation should not rule them out, but may need a warning next to the link. Graeme Bartlett (talk) 01:51, 10 April 2017 (UTC)

MediaWiki:Sharedupload-desc-here[edit]

Moved from Wikipedia:Village pump (technical): – Train2104 (t • c) 05:53, 8 April 2017 (UTC)

In late 2011 it was suggested (by user jonkerz) unlinking the Commons logo (File:Commons-logo.svg) in MediaWiki:Sharedupload-desc-here or making the link point to the actual file on Commons like it is in pt:MediaWiki:Sharedupload-desc-here. In many other major/important Wikipedias that logo is either unlinked or link points to the corespondent Commons file page. Hereby I've opened this thread to decide together what to do. XXN, 20:59, 4 April 2017 (UTC)

Working with files in several Wikipedias, jumping from on wiki to another and trying to access file pages from articles, sometimes I've encountered a problem here clicking quickly on that logo to access the specific file page of the viewed file on Commons, but in result I just opened one more time the page File:Commons-logo.svg:( That's why personally I prefer to see that link pointing to the corespondent Commons file page of the viewed file, or at least to see it unlinked. XXN, 20:59, 4 April 2017 (UTC)
I didn't even notice this...but now that I do, it seems really silly. Support delinking it. – Train2104 (t • c) 19:41, 5 April 2017 (UTC)

Add quality criteria to WikiProject templates[edit]

WikiProject templates such as {{WikiProject Biography}} on article talk pages help project members by adding the articles to project categories and lists. However, many editors do not understand the quality criteria. They may just rate all short, boring articles as "Stub", all long, interesting ones as "C" and all others as "Start". The WikiProject templates include links to the quality scale, but most editors do not click on links like that, or give up when they see how long the instructions are.

This is to propose adding a [show] link to the project templates, as in the mock-up below, to open a standard definition of the chosen quality class:

Redwood National Park, fog in the forest.jpg
 This page is supported by WikiProject Ecoregions, a collaborative effort to help develop and improve Wikipedia's coverage of ecoregions. The aim is to write neutral and well-referenced articles on these topics. See WikiProject Ecoregions and Wikipedia:FAQ/Contributing.
Start
Low This article has been rated as Low-importance on the project's importance scale.

The [show] link would apply to projects that have accepted the standard assessment scheme, and would be implemented in {{WPBannerMeta}}. A lot of editors would still ignore the criteria, but more of them would check to see what their assessment really means. Assessment quality would improve. Aymatth2 (talk) 13:04, 8 April 2017 (UTC)

Comments[edit]

  • Neutral leaning support. I don't really have a problem with this. The only problem I can see going forward is that certain WikiProjects actually have slightly different criteria for each rating. The military history one seems to be the one most people go back to for an example of a well functioning project. Personally, I would rather see a uniformity towards the assessments but this is a step in the right direction. --Majora (talk) 17:10, 8 April 2017 (UTC)
    • {{WPBannerMeta}} takes a parameter "QUALITY_SCALE" that defaults to "standard", which is what most projects use. The proposal would only apply to projects that use the standard scale. I would prefer to keep it simple at this stage, maybe support non-standard scales later. Aymatth2 (talk) 17:38, 8 April 2017 (UTC)
  • Oppose I don't see the point of this. If people don't click on "Quality scale", that's because they're not interested in it, or remember what Stub/Start/C/etc mean from the last time they clicked on the link. There is little point in adding more clutter to banners. Headbomb {t · c · p · b} 17:47, 8 April 2017 (UTC)
    • It does not add much clutter. A [show] link is more likely to get used because most editors know it will not take them off to another page, and perhaps because people like to check out hidden things. Of course, a lot of editors will just keep using their personal criteria anyway. Aymatth2 (talk) 18:11, 8 April 2017 (UTC)
  • Support provided that this is included as an option. Include a parameter "quality_info" or something which toggles in these descriptions if set to yes in the WikiProject template itself (i.e. not in each article, just in {{WikiProject National Football League}} etc). This lets projects with their own scales decide not to use these. ~ Rob13Talk 18:00, 8 April 2017 (UTC)
    • We could add a "show_quality_info" parameter to {{WPBannerMeta}}, default "yes". Individual project templates like {{WikiProject Biography}} could choose "show_quality_info=no". But see above, this proposal would anyway only apply to projects that have chosen the standard scale. Aymatth2 (talk) 18:11, 8 April 2017 (UTC)
      • @Aymatth2: Yes, but many use the standard scale while applying different meanings to what the standard scale means. That's what I'm intending to address. Not to mention that individual projects may just not like the explanations being there. I would prefer default no, not default yes, to prevent unexpected changes. All active projects could be alerted of how to make the change (if they wish) via a talk page message. ~ Rob13Talk 18:22, 8 April 2017 (UTC)
        • Some projects have their own definitions and override the {{WPBannerMeta}} default. But if a project template uses the default, the quality scale link will point to the standard definitions. This proposal only applies to project templates that link to the standard definitions. It gives quick access to the relevant definition. Aymatth2 (talk) 19:06, 8 April 2017 (UTC)
  • Unneeded given that quality scale is linked already. And I would oppose any bloat in the code sent out to the remove devices. Some of us have long and thin connections to the Wikipedia servers, so we can do without the extra delay. Graeme Bartlett (talk) 01:08, 10 April 2017 (UTC)
    • There is significant overhead in the data sent with a Wikipedia page. A talk page with nothing but one project banner, like Talk:Amapá mangroves, will be about 30,000 characters long for a fixed device. The definition would push that up to about 30,500 characters – an insignificant amount. The same talk page sent to a mobile device will be about 21,000 characters long, or 21,500 characters with the definition. Still, we could skip adding the definition for mobile devices. The feature is mostly aimed at editors, and most editors will be using a desktop. The fact that many assessments are incorrect shows that the link to the quality scale is not working. The hope is that a [show] link would work better. Aymatth2 (talk) 11:23, 10 April 2017 (UTC)

Inserting relevant YouTube videos into wikipedia articles[edit]

Hello!

The idea is to unify and synthesize world's knowledge and information (on wikipedia)

Wikipedia is already organized by topics and videos may be easier to consume than long blocks of text

e.g. https://www.youtube.com/user/khanacademy https://www.youtube.com/user/crashcourse https://www.youtube.com/user/Harvard https://www.youtube.com/user/StanfordUniversity https://www.youtube.com/user/oxford https://www.youtube.com/user/MIT https://www.youtube.com/user/UCBerkeley https://www.youtube.com/user/caltech

Is it allowed? What are some of your ideas about this? — Preceding unsigned comment added by Dndm49 (talk • contribs) 15:28, April 9, 2017 (UTC)

@Dndm49: It is not allowed for various reasons. One of the major one being copyright. Wikipedia is licensed under the CC BY-SA 3.0 and GFDL licenses. These are "free" copyright licenses. Those YouTube videos are under the Standard YouTube License which is "All Rights Reserved". They are copyrighted under a license we cannot use. Most everything you find on the Internet will be copyrighted under an All Rights Reserved type copyright and is not suitable for inclusion here. That is why all media that is embedded into articles has to be directly uploaded to a Wikimedia server somewhere (either here or on Commons). That way there is controls. Media can be checked and ensured to be licensed under a copyright license we can use. --Majora (talk) 16:49, 9 April 2017 (UTC)
Videos can be inserted, but using a format that normally results in low quality or large size. We should keep an eye on when patents expire so that unfree formats become free. It is a lot of work to make a video. There are also some useful animated gifs around. Graeme Bartlett (talk) 01:47, 10 April 2017 (UTC)
There are conversion tools if the only thing stopping you is file format. True, the free video file formats are subpar compared to other ones but if the copyright is there, a bad quality video is still better than nothing at all. --Majora (talk) 01:49, 10 April 2017 (UTC)

Relisted merger discussion on "Infobox single" and "Infobox song"[edit]

The RfC discussion on merging {{Infobox single}} and {{infobox song}} is relisted. I invite you to improve consensus. --George Ho (talk) 22:18, 9 April 2017 (UTC)

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