Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia
  (Redirected from Wikipedia:VPR)
Jump to: navigation, search
  Policy   Technical   Proposals   Idea lab   Miscellaneous  

New ideas and proposals are discussed here. Before submitting:

« Older discussions, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134
Centralized discussion
Proposals: policy other Discussions Ideas

For a listing of ongoing discussions, see the dashboard.

Note: entries for inactive discussions, closed or not, should be moved to the archive.

Activate Visual Editor on talk pages on English Wikipedia[edit]

I propose that Visual Editor is enabled on talk pages on English Wikipedia alongside Source Editor. This would remove the need of new editors to have to learn how to use Source Editor to interact with the rest of the community. It would also allow people from outside the Wikimedia movement more easily communicate with us e.g writing a question about donating images on a Wikiproject talk page. It seems very odd that there is a higher technical barrier to entry for talking to each other than adding information to articles.

Currently VE is being used in discussions on Wikimedia projects successfully including this one about copyright strategy started by WMF.

Would it be possible have this activated on one or a few Wikiprojects as a trial to identify any issues?


--John Cummings (talk) 13:09, 2 September 2016 (UTC)

I'd say it should be enabled in all namespaces. It's now good enough that even as a dedicated source code editor, even I find uses for it -- mainly, table editing and pasting rich text. But when I try to use it, say, in the Wikipedia: namespace, I have to figure out why I can't. It's a needless annoyance. I think we all agree that VE was initially pushed prematurely, but it's a lot better now...and having available sometimes, but unavailable others, is far from ideal -- for both newbies and experienced editors. -Pete (talk) 23:46, 3 September 2016 (UTC)
I'll just comment to say that the WMF is very against it. The logic is seriously warped. The answer is "No, because Flow". Or, to fill in the missing details on that, "No, because we want to exterminate Talk pages completely, we want to force everyone to use Flow, and we view enabling VE on Talk as some sort of alternative or threat to the Flow agenda". Link: MW:Flow#If you are not working on Flow, will the visual editor be enabled on talk pages? Alsee (talk) 11:24, 4 September 2016 (UTC)
Thanks for the link, Alsee. I wish I could keep up with the status of Flow, it seems to be ever-shifting. That FAQ item was added in August 2016, so I suppose it is authoritative. Even though discussion technology has been under active discussion since at least 2010 or so, for some reason this is all on hold until June 2017. Discouraging. Thank you for the link. -Pete (talk) 19:16, 4 September 2016 (UTC)
@Jdforrester: This really does not stand a chance of happening. The VE team are dead against it see for example the closed WONT-FIX task T53154 "VisualEditor: Provide a tool to insert a talk signature in namespaces that need it".--Salix alba (talk): 19:19, 4 September 2016 (UTC)
@Salix alba: that task was completed and you can add a signature in VE, you can find insert signature under the insert menu in VE. --John Cummings (talk) 20:46, 4 September 2016 (UTC)
That does seem weird. I detest VE, but I understand why people like it, and the tool should not be forbidden to them on talk pages for no apparent reason, as long as the sigs issue noted above really is fixed.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  11:22, 5 September 2016 (UTC) Reconsidered.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  11:47, 5 September 2016 (UTC)

I just went to that Visual Editor user guide on Mediawiki[1], and tried to edit it in VE. After a long wait, it opened, more or less. Many images are not shown but given as text ([[File:VisualEditor and so on). (mind you, that page looks rather shitty in reading mode already, the section with "Once you have entered or selected the link, you complete the linking" isn't completely visible on my already widescreen small font machine...). If even that page isn't editable correctly in VE, I still see no reason to roll it out any further on enwiki (considering also the ongoing creation of many "nowiki" errors in the main namespace by VE edits). Fram (talk) 11:35, 5 September 2016 (UTC)

Oh, if it's still doing the incorrect nowiki thing, then, no. It is not ready for prime-time yet. I thought it only barfed that stuff up when used inside Flow.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  11:47, 5 September 2016 (UTC)
That page contains <translate> tags which aren't supported in VE. ed g2stalk 03:50, 6 September 2016 (UTC)
  • While I'm tempted to say better V/E than Flow; The solution is to teach newbies the classic editor rather than V/E. Ideally with auto signature as a default on talkpage edits so unless you untick a box on your edit screen any edit you make on a talkpage has a space and four tildas appended. BTW could anyone create a script that does that? ϢereSpielChequers 12:29, 5 September 2016 (UTC)
    Some talk page edits should not be signed; adding banners at top of page, for example. --Redrose64 (talk) 12:49, 5 September 2016 (UTC)
    Yes, hence my point about having a tick box you can untick for such edits. ϢereSpielChequers 12:54, 5 September 2016 (UTC)
  • Support in concept. Just need a few tweaks. Doc James (talk · contribs · email) 18:14, 6 September 2016 (UTC)
@Doc James:, what tweaks do you think are needed? --John Cummings (talk) 20:24, 6 September 2016 (UTC)
It should be turn on able as a beta feature immediately so that long term editors and other can try it out. The signature issue was mentioned above. Doc James (talk · contribs · email) 20:28, 6 September 2016 (UTC)
Ok, thanks Doc James, what's the next step to implement VE on talk pages as a beta feature? John Cummings (talk) 20:58, 6 September 2016 (UTC)
How about we have a RfC and than present the result of that RfC to the WMF? That could gain some traction. Doc James (talk · contribs · email) 21:00, 6 September 2016 (UTC)

Thanks Doc James — Preceding unsigned comment added by John Cummings (talkcontribs) 11:30, 7 September 2016 (UTC)

So, my above experience was apparently invalid because they made VE available on a site where most pages contain translate tags, which mess up VE... Speaks volumes about both VE and the WMF, but nothing new there. So instead I tried to edit my user page there, which doesn't have such tags[2]. I go to the end of my text, press enter (cursor to new line), press enter again (cursor to one line lower down? No, cursor goes back up one line, to the end of my text!).

So I enabled VE here (very temporarily), and tried to have a conversation with myself on my user page (which still looks different in VE than it does in reality, fail again). At least I don't get the problems described above, but when I type


I get Hi<blockquote>Hello</blockquote><blockquote>:Heya</blockquote> as the result. Which is useless.

I checked the linked page at Meta, [3], and very, very few edits there are made using VE, none in response to others, probably because that doesn't work in VE. If you can't even (easily, intuitively) reply to someone using VE, then why would you enable VE on talk pages? For the very rare cases where you really think VE offers a benefit (say, creating a table), you can always create the table in VE in your sandbox and then copy the wikicode to a talk page. Setting up a VE which is clearly unsuited for standard talk page editing just so a few exceptional cases can be made easier seems counterproductive. Fram (talk) 12:16, 7 September 2016 (UTC)

I think this fits with why JDF is so against VE for talk page. Talk pages were never in the design brief for VE so features like doing multi-level indentation haven't been worked out fully. Adding them takes time away from doing what they are supposed to be doing. --Salix alba (talk): 17:33, 7 September 2016 (UTC)
Well, also remember that the usage of : is a total abuse of the visual effect of a technical feature that should never have been in the first place, but is an accident of history that we can no longer correct. That means that for VE to distinguish between the visual effect for Talk page discussions and the technically correct usage pattern is really hard, since the difference is basically arbitrary. —TheDJ (talkcontribs) 09:25, 9 September 2016 (UTC)
You mean that Parsoid has to do that. VisualEditor 'thinks' in HTML, not wikitext. This means that it sees <dd> (instead of :), and it can't create that kind of list (yet. I have asked for this feature to be prioritized, partly because I use that in my own editing, but my request has been declined so far. I do not expect that feature to be seriously considered again until early 2017).
I appreciate the sentiments coming from John Cummings and others. However, I'm not hopeful that the proposal would be accepted. Firstly, it is impossible to enable it for specific pages only, so it would have to be for a full namespace. The most plausible "test" namespace would be Wikipedia: namespace, which is mostly AFDs and non-discussion pages. However, so long as WP:ANI exists in the Wikipedia: namespace, I do not believe that it will be enabled even there on this wiki. Secondly, the product manager has declined every single similar request from other wikis. So while you're free to make the proposal, I don't think it would be worth your time at this point. You might consider this subject again after the latest version of the wikitext editor has been deployed (i.e., no longer a Beta Feature [if you're interested in trying it as a Beta Feature, then check your prefs in about a month]). Whatamidoing (WMF) (talk) 22:30, 10 September 2016 (UTC)

Thanks for the information Whatamidoing (WMF), can I ask a couple of questions to understand the situation better? I have never done a proposal before like this:

  1. Who would do the accepting or now accepting of this proposal? I'm confused about if it would be a community decision or one made by a specific person at WMF or something else.
  2. Would it be technically possible to turn on VE on talk pages as a beta feature either on or any other Wikimedia projects e.g Meta?
  3. I'm only suggesting this because the current system is not ideal and I understood that Flow was not being developed any more, is this the case? I don't want to propose something if there is another solution coming that will be widely implemented.

Thanks again

John Cummings (talk) 10:42, 13 September 2016 (UTC)

@John Cummings:, The primary problem is that VE does not (and will not be made to) match the mis-use of :::'s (which create a definition list) that we've historically mis-used for multiple indents (as discussed above), and as such it will never be suitable for editing multi-indent discussions. For #3, major development of Flow is currently paused, whilst the Collaboration team works on wrapping up Notifications work, and progresses on mw:Edit Review Improvements, but they do hope to look at this area (structured discussion) again after the ongoing work is done. HTH. Quiddity (WMF) (talk) 20:35, 14 September 2016 (UTC)
  1. John Cummings, proposals for config changes have to be "physically" implemented by WMF staff, and of course they're not going to implement something that they disagree with. In this case, it'd have to be accepted by the product manager for mw:Extension:VisualEditor.
  2. It's technically possible to turn the visual editor on at any MediaWiki site (including all Wikimedia sites) in any normal namespace (e.g., not "Special:").
  3. I agree that the current system isn't ideal. Flow is currently in active use at a few wikis, including mw:, where it's been the default for all (new) talk pages for a long time (old pages stick with their old format unless individually changed). However, I wouldn't expect Flow to be made available here at the English Wikipedia for a long time (=years). Whatamidoing (WMF) (talk) 17:37, 19 September 2016 (UTC)

restrict editcontentmodel permission[edit]

A new WMF change is planning to grant access to (editcontentmodel) as used by Special:ChangeContentModel to all (auto)confirmed users. Some of the technical information is located in phab:T85847. Outside of Special:MassMessage there is little use case for this ability currently on the English Wikipedia and I propose that for enwiki we restrict this access to sysops (already assigned) and Mass Message Senders (who could make use of it to use Special:CreateMassMessageList). This utility can be used break articles from being able to be read or reverted by anonymous users, and is not currently easily reverted. Please comment below. — xaosflux Talk 02:01, 8 September 2016 (UTC)

  • Support This could have unintentional consequences if used by those not familiar with how different content models should be used. It can also be used for disruption. It can be added to other user groups at a later point if the need arises. — JJMC89(T·C) 02:47, 8 September 2016 (UTC)
  • Let's just wait and see what the practical consequences are, before we restrict it. Restricting something later on should be easy enough. —TheDJ (talkcontribs) 08:21, 8 September 2016 (UTC)
    This is already available to sysops, the practical consequence is easy: most users will be able to take a working article and break it, See this page for an example: test2wiki:Law2. Apparently this is being done to support something about Flow, which we have strongly rejected on enwiki. — xaosflux Talk 11:33, 8 September 2016 (UTC)
    Well, that's not true at all. "most users" isn't true, because most users actually aren't autoconfirmed. In any case, any user can "break" an article by changing it's content. In this case, they can break it in a different way. It's not being done to support Flow, Flow already bypassed this. Legoktm (talk) 21:50, 8 September 2016 (UTC)
    @Xaosflux: While 'take a working article and break it' might be true, that goes for most things we do. The only question which to me is relevant, is wether dealing with that breakage is 'expensive' enough in labor to warrant protecting it more than page moves, and to have other people running around doing the work that an auto confirmed user might have been able to do on his own. And since we haven't tried this, we can't say anything about it yet. So, I would opt to gather that experience, before deciding it needs the protection that people seem to think is required. While I support some of your original concerns, I think that with the fixes made by Lego and Bawolff, will sufficiently address the problems to at least experiment with a wider access to this option. —TheDJ (talkcontribs) 11:00, 9 September 2016 (UTC)
  • Strong support to limit to sysops and mass message senders (for now). The possibility of "Content model change vandalism" per the apparent result at test2wiki:Law2 (and warring?!) could be disasterous, especially if folks are unaware that this would be a new area that needs patrolling. Side note: there are times when (user) script writers require a content model change when a page is not created with a js/css extension, but could be trusted with the permission. — Andy W. (talk ·ctb) 16:01, 8 September 2016 (UTC)
    Update/clarify: If undo/rollback reverts contentmodel changes, some of my personal concerns are resolved. I still think a contentmodel change on an article will throw many experienced editors off, and there'll be plenty of folks who wouldn't realize an undo (or an edit of a previous revision?) would solve the issue. I'd be willing to support a rollout of (editcontentmodel) to a user group that has some semblance of maintenance or patrolling, like reviewer or rollbacker. I sincerely hope that contentmodel changes don't become a new form of disruption. Also, I hope a non-admin cannot change the content model of User:Andy M. Wang/common.css and move it to their userspace. — Andy W. (talk ·ctb) 01:56, 9 September 2016 (UTC) added 02:10, 9 September 2016 (UTC)
    Thanks for updating. No, non-admins will not be able to do that. To be able to change the content model of a page, you first need to be able to edit it. In this case, non-admins are not able to edit your CSS or JS, so they would not be able to change the content model. Legoktm (talk) 03:28, 9 September 2016 (UTC)
  • Question. For those of us just coming into this discussion, could someone provide a link to where the idea of "contentmodel" is explained? Maybe point WP:Contentmodel at it? As Andy W. notes, it's something that is apparently new and might need to be understood (or at least known-about/knowable-about) by lots of editors. DMacks (talk) 16:11, 8 September 2016 (UTC)
    @DMacks: Most of the content model help is at to avoid fragmentation of information, I think. (See Help:Content model) — Andy W. (talk ·ctb) 16:14, 8 September 2016 (UTC)
    @DMacks and Andy M. Wang: Not new, but rarely encountered; even admins aren't fully knowledgeable (as in, how many of us have ever needed to do this?). There was a thread at VPT a few months ago (see Wikipedia:Village pump (technical)/Archive 147#MW Error message when undoing "content model" change) where somebody had managed to accidentally change the content model of a page, and had difficulty changing it back. This was the first time that I'd heard of the feature. --Redrose64 (talk) 23:02, 8 September 2016 (UTC)
    @Redrose64: Thanks. I had thought that the undo or rollback button did nothing to change the content model, and that had to be a separate mechanical action. To clarify, I don't think anyone's ever needed to monitor Special:Log/contentmodel before; I've maybe glanced at the log twice, maybe thrice tops. Suppose some editor changes Michael Phelps from wikitext to JSON. I thought there would be no working undo or rollback button since a text revert makes the page incompatible with JSON format (hence a need to monitor that log). If undo/rollback reverts text and contentmodel changes, that alleviates some of my concerns. — Andy W. (talk ·ctb) 01:58, 9 September 2016 (UTC)
  • Strong support We shouldn't be giving out freely a tool which makes hard-to-revert vandalism easy and which has very little use. MMS holders should get it per Xaosflux. If it would be useful for some script developers, we can think of making a separate user group, but now we need to quickly get it out of the hands of our more enterprising vandals. I hope this can SNOW so the change doesn't get deployed here at all. BethNaught (talk) 17:05, 8 September 2016 (UTC)
    It would be helpful if you could elaborate on how this vandalism would be "hard-to-revert"? Legoktm (talk) 21:50, 8 September 2016 (UTC)
    According to your comments phab:T145044#2618347 and phab:T75490#1416463, edits changing the content model cannot be undone fully (i.e. changing the content model back) without visiting a special page and doing so manually. This is hard because a) the undoing is labour-intensive and slow b) the patroller has to know about it in the first place c) the process is not apparently compatible with common anti-vandal tools like Huggle and Twinkle. If as you state, the ability to do a complete revert in the standard way will not be soon forthcoming, the ability to change content models should not be widely given out. Autoconfirmed socks are not hard to obtain for a keen vandal, such as the Nikita troll who recently forced the implementation of ECP on many music articles. BethNaught (talk) 22:09, 8 September 2016 (UTC)
    Hmm, I think those comments might be a bit misleading out of context. In any case, thank you for explaining, I appreciate it. Those are discussing *undo* specifically. Actions like rollback will properly revert content model changes, meaning that tools like Huggle and Twinkle will work just fine. Does that resolve your concerns? Or do you see undo working as a requirement for granting to autoconfirmed users? Legoktm (talk) 22:25, 8 September 2016 (UTC)
    Long-term I consider the issue with undo a serious bug. Undoing a revision should undo all the associated changes. However, with regard to the upcoming deployment, if I were convinced that anti-vandalism tools would work I would be more sympathetic to TheDJ's wait-and-see approach. However I'm not convinced Twinkle will work. As far as I understand it, Twinkle works by taking the content of the old revision and posting it into a new edit, not by invoking MediaWiki rollback -- in fact, that's then point, to have rollback without rollback rights. So the automatic content model revert included in MediaWiki rollback wouldn't be invoked. Arguably Twinkle needs updating here, but it is a problem that needs resolving. BethNaught (talk) 22:55, 8 September 2016 (UTC)
    You're right :) Well, kind of. It uses the API's undo functionality apparently, not normal rollback. Bawolff and I are working on fixing that and will have it fixed by Monday when we planned to roll this out. Legoktm (talk) 23:20, 8 September 2016 (UTC)
    @BethNaught: There is a parallel, it's existed for years - and it's well-known too. Consider a (confirmed) user - let's call them Example - who goes to a page, makes a text change, moves the page to another title, and makes another text change. Let's assume that none of these actions was constructive, and the best thing to do is to put the article back to how it was before Example touched it. If you look at the page history, there will be three entries for that user, and all three have an "undo" link, yet the middle one, if clicked, will throw this message (in red). I believe that if Twinkle is used on that sequence of three actions, it will satisfactorily undo the two text changes, but not the page move. Moreover, true WP:ROLLBACK (not the Twinkle rollback) will also not revert the page move. --Redrose64 (talk) 08:34, 9 September 2016 (UTC)

Wow, I'm rather disappointed in how Xaosflux started and framed this discussion. This isn't a "WMF" change. I'm pushing this forward in my free/limited volunteer time. I've already asked how this could be used to break articles in a way that isn't undoable. And after responding to concerns at phab:T85847, no one has provided me with any specifics, which I'd really like to hear. Legoktm (talk) 21:50, 8 September 2016 (UTC)

Legoktm First let me apologies for my misundersanding on the source of this change. I've striken the WMF portion in the lead. While this is not "undoable" it does allow a registered user to break from the point of view of readers in a way that an unregistered user can not fix. It allows users to break an article for readers that is difficult to reverse (at least currently). You can not "undo" or "revert", you can not even load the last working version and hit save. Revert links to not appear on pages after content model changes? where is the revert? Try to force it get:
Grabbing data of the earlier revision: [V9HoewpAID4AADqduzMAAAED] Exception Caught: Bad content model: expected javascript but got wikitext.
. For the English Wikipedia at least, I can't think of any good reasons that the article namespace should have js, JSON, MML formats presented to readers at all - please, please let me know what I am missing here and why this is needed? — xaosflux Talk 22:42, 8 September 2016 (UTC)
Thanks. I don't buy the argument of unregistered changes not being able to fix this. How is it different from an autoconfirmed user vandalizing a semi-protected page and blanking it? The reason it's throwing an exception is because we haven't deployed the fix for the bug your reported yesterday. Legoktm (talk) 23:03, 8 September 2016 (UTC)
That error above is not from "undo" it was from trying to do a twinkle rollback. Can any admin help demonstrate by changing User:Xaosflux/Test2 to js? — xaosflux Talk 23:37, 8 September 2016 (UTC)
Twinkle rollback uses "undo" via the API. Anyways, I converted the page. Legoktm (talk) 03:25, 9 September 2016 (UTC)
  • Meh. Not seeing a need to restrict this. No evidence of actual abuse, and should be just as easy to revert as any other vandalism. -- Ajraddatz (talk) 22:44, 8 September 2016 (UTC)
    Ajraddatz Can you describe the steps needed to revert the model vandalism test here: test2wiki:Law2? — xaosflux Talk 22:47, 8 September 2016 (UTC)
    It's broken right now, but the appropriate thing to do with a bug is to file a bug report about it rather than trying to restrict the ability to non-admins. Hence why I added "should" to my comment. -- Ajraddatz (talk) 22:52, 8 September 2016 (UTC)
    Thanks Ajraddatz - so do you think this "should not" go out until it is easy to revert? — xaosflux Talk 23:38, 8 September 2016 (UTC)
    Obviously if it was detected before release, but the bug wasn't intended to be there; bugs happen, the best we can do is fix them. And in this case, it has seemed to take as much time to just fix it as it would have to remove it altogether until the issue was resolved. And keep in mind, there still doesn't seem to be an actual issue here; you still have not provided any examples of actual abuse happening with it. -- Ajraddatz (talk) 16:22, 9 September 2016 (UTC)
    Well, had you used multiple accounts like happens with actual vandalism, he would have simply pressed "rollback". Legoktm (talk) 23:03, 8 September 2016 (UTC)
    Hi folks. Just to let you know, I'm working on making the undo button work for content model changes. Bawolff (talk) 23:10, 8 September 2016 (UTC)

Update: Thanks to all your feedback and some work by user:bawolff, undo will now also undo content model changes. This also means tools like Twinkle rollback will work as well (Huggle uses normall rollback IIRC, so it would have already worked). You can test these changes on the Beta Cluster in a few minutes (you only need to create an account there to change content models), they won't work here yet. Legoktm (talk) 03:35, 9 September 2016 (UTC)

  • Not sure if needed - but if changing a content model by way of the rollback function - it bypasses the change in the content model change log. — xaosflux Talk 03:36, 9 September 2016 (UTC)
    I noticed that as well, and fixed it :) Legoktm (talk) 04:54, 9 September 2016 (UTC)
    @Legoktm and Xaosflux: I did some tests as "Andy M. Wang" and "Andymw2" at the Beta cluster. It looks like I can change another editor's subpage to CSS and prevent myself from editing it / undoing it. It also appears that for a page I can currently edit, I cannot select an old revision of a page whose content model differs from the current and try to edit that. I'm afraid that behavior might break Twinkle's revert-to-revision when the select revision's contentmodel is different. To revert to a revision, it looks like a manual change is needed. The reason this is problematic regardless is when a user changes a page like 2016 Summer Olympics to CSS, and makes a second edit. Users without rollback who are not aware of Special:ChangeContentModel (that's surely almost all) might try to select a revision prior to the contentmodel change, but cannot edit it due to the restriction. I'm waiting to be autoconfirmed so I can test what happens when I move a CSS to another user's subpage — Andy W. (talk ·ctb) 06:18, 9 September 2016 (UTC)
    To summarize the scenario: suppose User A made the last good revision to Foo. User B changes the content model to CSS. User C edits the page. Then I believe an autoconfirmed User D should be able to select User A's revision and edit that, or use Twinkle's revert to revision by User A. — Andy W. (talk ·ctb) 06:34, 9 September 2016 (UTC)
  • Support. It appears that the only use case here is massmessage, and we don't allow autoconfirmed users to utilize the page to send massmessage spamblasts. That is already a restricted-rights function for admins[4] (and presumably any massmessage-usergroup). Having an admin create the page is rare and trivial. Alsee (talk) 09:12, 9 September 2016 (UTC)
    Note, to aid any users that want to build up a mass message list, we have built empty shells for them to use (see Wikipedia_talk:Mass_message_senders#Mass-mail_subscription_list_shells). — xaosflux Talk 11:36, 9 September 2016 (UTC)
    Alsee, massmessage is certainly not the only use case. Changing the content model of a page is useful to anyone who works with JSON or JS pages on a regular basis, which covers all user script developers and anyone who works with the meta:Meta:FormWizard gadget, which is used on a bunch of WikiProject pages. (See, for example, WP:WikiProject Women in Red.) Enterprisey (talk!) 16:33, 10 September 2016 (UTC)

I'm not clear on what the security implications are of changing, for example, a mainspace article to a Javascript content type. Would this enable anyone to create a mainspace page with arbitrary Javascript that would run in readers' browsers? isaacl (talk) 00:22, 10 September 2016 (UTC)

@Isaacl: The page you browse could be a css or js, but is not in the list of things to be run in readers' browsers, so there's no major concern. (There's an order to which CSS (and JS) gets loaded by the browser. I think some of that is detailed here. As far as I know, at the enwiki local level, there are some site-wise css/js, but most of what the user customizes would be at Special:MyPage/common.css, (and Special:MyPage/common.js), and depending on skin, a vector.css/js or monobook.css/js etc. I don't think it's possible to create a .css or .js and maliciously move it to another user's specific css/js title to get run, so that's not a concern either.)
But that also being said, there really shouldn't be any legitimate reason anyone changes a mainspace page to a CSS or JS other than a miscreation at a bad title. — Andy W. (talk ·ctb) 01:42, 10 September 2016 (UTC)
  • Support per all above me. This is useful for massmessage-senders and other trusted users for a very specific type of work. Others won't need it and there's romm for potential disruption. So I agree this should be restricted to MM senders and sysops. MarcoAurelio (talk) 10:46, 10 September 2016 (UTC)
    MarcoAurelio, which "other trusted users" were you talking about? Changing the content model of a page is useful to anyone who works with JSON or JS pages on a regular basis, which covers all user script developers and anyone who works with the meta:Meta:FormWizard gadget, which is used on a bunch of WikiProject pages. (See, for example, WP:WikiProject Women in Red.) Enterprisey (talk!) 16:36, 10 September 2016 (UTC)
    Can you help explain what is the workflow where one would change the content type of a page? I would appreciate learning more about this topic. isaacl (talk)
    I'll give an example where I had to pester an admin. xaosflux and I were working on the Navigation Popups gadget, and he had the bright idea of making a template-style sandbox where we could test a beta version of the gadget, so he made it and immediately changed the content model to JavaScript. I missed this second change, so when I made a sandbox myself myself, I was initially confused and had to pester xaosflux until he changed the content model of it. If I had the permission, I could have done it myself. At the moment, whenever I want a new gadget sandbox, I have to go get an admin to do it. Heck, come to think of it, I don't think we'd see much community opposition if we were going to add it to something like template editor. Enterprisey (talk!) 04:17, 11 September 2016 (UTC)
  • Oppose. I see no benefit of restricting it. I've had to pester admins when I do need the content model of a page to be changed (which is when I've been working with gadget sandboxes). Enterprisey (talk!) 16:27, 10 September 2016 (UTC)
  • Repeating what I said at phabricator:T85847#2626070: We should empower users to be bold. :-) I favor as liberal permissions as possible in nearly all cases as I think that's the wiki way. In the case of editing a content model, it should not be any more disruptive than moving/renaming a page. --MZMcBride (talk) 20:47, 10 September 2016 (UTC)

Hi BethNaught and xaosflux. Thanks for participating in this discussion. Other than the undo issue, which I think everyone agrees should be fixed (thanks Lego and Bawolff for doing that!), are there problems you foresee with more users having this user right? --MZMcBride (talk) 20:52, 10 September 2016 (UTC)

I was thinking I should have started this discussion along the lines of "Which user level should we add this permission to" - and with undo working I think I'd be good with adding this to extenedconfirmed. — xaosflux Talk 21:58, 10 September 2016 (UTC)
Extendedconfirmed seems like an OK level to put it at, but TBH I'd prefer to get rid of that not extend use of it myself. To avoid policy creep I'd say keep it as-is at autoconfirmed. -- Ajraddatz (talk) 22:33, 10 September 2016 (UTC)
As much as I'm personally unenthusiastic about it, extendedconfirmed seems to be what the community thinks is an acceptably high bar for a lot of things, and for that reason, if we can't get consensus for autoconfirmed, extendedconfirmed seems to be a good place to put this right. Enterprisey (talk!) 04:13, 11 September 2016 (UTC)
xaosflux, also, as I've realized from the above discussion, I think it would be worth it to restart this RfC with your proposed question. We've only had nine firm !votes so far, and everyone in the discussion (as far as I can see) already keeps an eye on this page. Enterprisey (talk!) 04:19, 11 September 2016 (UTC)
@MZMcBride and Xaosflux: Yes, sorry to interrupt, but may I please get an answer about how User D fixes this scenario:
  • User A writes the last good revision to page "Foo".
  • User B maliciously changes the content model of "Foo" from wikitext to CSS.
  • User C edits the page in good faith.
  • User D would like to revert to User A's revision without knowledge of Special:ChangeContentModel. (as not required by the undo/rollback cases tested so far)
I think the answer is neither undo nor rollback nor Twinkle's revert-to-revision nor "manual edit previous revision" (which I believe is not possible today), i.e. not possible. Thanks, — Andy W. (talk ·ctb) 06:13, 11 September 2016 (UTC)
I suspect they get lost test2wiki:Law3 has a 3 edit combo if you want to look. — xaosflux Talk 14:11, 11 September 2016 (UTC)
If the only mitigation is Special:ChangeContentModel, I believe this is a usability bug then, mostly because users are very much unaware of that special page, and don't know how to reverse a content model change when undo and rollback are not available. — Andy W. (talk ·ctb) 19:17, 11 September 2016 (UTC)
Sorry, I forgot to respond here. I filed phab:T145316 for this and have a patch pending. Thank you for testing :) Legoktm (talk) 20:46, 11 September 2016 (UTC)
Hi Legoktm, sorry, the scenario I'm describing above is for a generic mainspace page "Foo" in which it becomes impossible to undo/revert for anyone, including sysops. Let me know if I need to clarify — Andy W. (talk ·ctb) 20:53, 11 September 2016 (UTC)
Yeah, I read too fast and then just edit conflicted with you. I thought it was about your comment earlier that you can lock yourself out of editing a user's subpage if you convert it to CSS or JS. Back to this scenario. Why would User C edit the page if they observe that the layout was messed up by the last commit? Wouldn't they try to undo B's edit first before making their good faith edit?
For discoverability...I suppose we could add a change tag that indicates the edit changed the content model of the page, which would then link to documentation about changing content models? Legoktm (talk) 20:58, 11 September 2016 (UTC)
Legoktm Sorry for not having a phab acct at this time I'm assuming User C could be relatively new, doesn't know about undo, and edits a high-traffic mainspace page (perhaps 2016 Summer Olympics) in good faith (or even in bad) after User B. If such an edit happens, rollback would no longer reverse a contentmodel change. Is support for a revert-to-revision (edit previous revision) out of scope? If it is, I think content model changes are still more disruptive than moves. Perhaps a tag could work...? My impression is that we're supporting undo/rollback to ensure most folks can reverse bad content model changes, and a mitigation for this seemed to fit the bill. — Andy W. (talk ·ctb) 21:09, 11 September 2016 (UTC)
Created phab:T145344 — Andy W. (talk ·ctb) 22:32, 11 September 2016 (UTC)
I'm not OK with adding this to extendedconfirmed. That's massive scope creep. Now that improved revert capabilities have been added, and the situation is (per Redrose) not too dissimilar to page moving, I would be OK with a trial run added to autoconfirmed (and confirmed, don't forget about that), but with a speedy restriction along the lines of the original proposal here in case of any abuse. BethNaught (talk) 16:30, 11 September 2016 (UTC)

Update #2: This won't be going out today (Monday), it'll be Thursday at the earliest, I will post here once plans finalize and also email wikitech-ambassadors. Legoktm (talk) 10:21, 12 September 2016 (UTC)

  • Oppose It doesn't allow any damage that regular editing can't already cause, and it can be fixed as easily as regular vandalism. Jackmcbarn (talk) 02:50, 17 September 2016 (UTC)
  • I think this discussion has helped spawn a lot of the issues that are being addressed in phab:T85847, if they all get resolved (basically making these type of changes easy to undo by most anyone) and empowering other tools (like the Abuse Filter) my overall opposition to expansion will be much diminished. As far as protecting articles, are there any current use cases where an existing article should ever have its content model changed? An edit filter to prevent that for the mainspace could be deployed. — xaosflux Talk 12:45, 17 September 2016 (UTC)
    The filter can be extended possibly to mainspace and Module, perhaps? It looks like there's one for Module with a similar purpose. — Andy W. (talk ·ctb) 00:43, 21 September 2016 (UTC)

Update icons for some templates[edit]

WP:SNOW Consensus against these new icons.
Almost all responses noted reduced readability as a primary concern, and this is especially an accessibility issue for those with poor vision.
Editors who did not raise readability concerns nonetheless found the current icons satisfactory, and saw no rationale to replace them. Alsee (talk) 19:35, 20 September 2016 (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.

This year is Wikipedia's 15th anniversary, and it is time for update icons of some templates, because some icons are outdated, which created in 2007. These new icons are created in 2013. Here are my proposals (for example):

Old New
Commons-emblem-question book orange.svg
Unbalanced scales.svg Commons-emblem-scales.svg

and more. I think these icons will replaced in all languages Wikipedia. So I would like to discuss this, thanks.--Shwangtianyuan Talk Here 05:57, 14 September 2016 (UTC)

Support - The two examples you put up are clear improvements, and the CommonsEmblems_icons set in general is a good unified style for these sorts of icons. T.Shafee(Evo&Evo)talk 06:15, 14 September 2016 (UTC)
Comment - whilst retaining the coloured circular border, are you a) able to make the whole icon take up more space within its canvas and b) make the meaning-bearing central sections black and more easily distinguished? T.Shafee(Evo&Evo)talk 23:44, 14 September 2016 (UTC)
Oppose for now. You are killing off a lot of contrast and 'readability' of those icons. Just take a step back and squint a bit. Now consider how many people have some level of a vision problem. —TheDJ (talkcontribs) 06:25, 14 September 2016 (UTC)
Well its a good idea to change your icons and stuff from time time.[why?] On the other hand those particular examples shrink the meaning-bearing elements too much IMO. Herostratus (talk) 13:28, 14 September 2016 (UTC)
Question Do we have a Manual of Style for svg icons? I would like to read it and contribute to the talk page. ClemRutter (talk) 14:46, 14 September 2016 (UTC)
Oppose The new icons are two orange circles with an indeterminate squiggle inside. The old icons looked like a pair of scales and a book. Why change clear symbols to meaningless circles? Martin of Sheffield (talk) 15:29, 14 September 2016 (UTC)
Maybe, but not with that style - agree with TheDJ here - bad readability - not just "step back" but think scaled down like on a mobile browser as well. — xaosflux Talk 21:05, 14 September 2016 (UTC)
Oppose per The DJ. There is a serous degradation of readability in the proposed new icons. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:27, 15 September 2016 (UTC)
  • oppose per The DJ. No good reason to change them and the suggestions are significantly worse.--JohnBlackburnewordsdeeds 16:45, 15 September 2016 (UTC)
  • Oppose - I think that the current icons are good. If I saw this on {{disputed}} or some combination of this and this on {{refimprove}}, I would vomit. KATMAKROFAN (talk) 00:31, 17 September 2016 (UTC)
  • Oppose because to be extremely blunt ... they're shit!, All's I see is an orange-outlined circle with something inside ... can just about make out what they are, Whereas the "outdated" ones are as clear as day to see, As the saying goes "Don't fix what isn't broken". –Davey2010Talk 01:33, 17 September 2016 (UTC)
  • Oppose. The icons in use now are fine. Colonel Wilhelm Klink (Complaints|Mistakes) 02:00, 17 September 2016 (UTC)
  • Oppose - the frame is a distraction and makes it hard to distinguish between icons for people with problems like poor vision. Blythwood (talk) 21:09, 18 September 2016 (UTC)
  • Oppose. Older icons are much easier to see and understand. NinjaRobotPirate (talk) 22:17, 18 September 2016 (UTC)
  • Oppose per NinjaRobotPirate and TheDJ. NgYShung huh? 15:35, 20 September 2016 (UTC)
  • Oppose I don't see how the new icons are an improvement over the old ones. To frank, this appears to me to be Yet Another Change for Sake of Change -- a chronic flaw of Microsoft products. -- llywrch (talk) 15:40, 20 September 2016 (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.

Wikipedia has to come out against Trump[edit]

Pulling the plug on this. I see no supports and a long list of oppose votes with very strong comments. Even the OP seems to realize this is going nowhere. Not questioning good faith, but if there has been a more obvious case of WP:Dead on arrival in the last month or so, I can't recall. Not a fan of the whole trout thing but I will admit this tempted me. (Yes I am WP:INVOLVED- sue me or revert me if you really think this deserves further debate.) (non-admin closure) -Ad Orientem (talk) 20:44, 21 September 2016 (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.

--- Fine, fine, fine, I get the point you're not for this. P.S. my guess is that the original article that ticked Trump is actually this one. Kudos to Scientific American for respecting the people. Wnt (talk) 17:15, 21 September 2016 (UTC)

I am appalled to read that Donald Trump has now sunk to suggesting banning information about how to make bombs:

"But how do you allow magazines to be sold -- these are magazines that tell you, from step one, go to the store and buy such-and-such, right? ... Those people should be arrested because they are inciting violence, OK. They are making violence possible. They should be arrested immediately. They have websites that tell how to make bombs, how to make all sorts of things that are totally destructive, and you know where they are coming from, and yet we don't want to touch them because of freedom of speech."

This comes on the heels of his earlier hopes to "open up the libel laws" [5] even beyond the already appalling status quo that has allowed the destruction of an entire suite of publications at Gawker over one truthful publication.

Now I am not saying that Wikipedia should endorse Clinton or something like that, no. But it is time for it to stand up and say that by golly, how are we supposed to write an article like 2016 New York and New Jersey bombings without saying that the terrorist(s) got pressure cookers and lengths of pipe and filled them with tannerite and black powder? He seems to be envisioning a world where people - or at least, certain races of people - aren't allowed to know shit, I mean, where even saying the phrase "pressure cooker bomb" would be cause for somebody to get sent to jail because he might "incite" violence by "making it possible" for someone to do something.

It is contrary to the scholarly duties of Wikipedia, and it is just plain offensive to common sense. If we lose every liberty and become a herd of scared individuals afraid even to collaborate on an encyclopedia, what difference does it make if the government wins or the terrorists win? There will be no law but violence, no justice but death. Wnt (talk) 17:14, 19 September 2016 (UTC)

I didn't realize Wikipedia hosted bomb making articles. The fact is if Wikipedia comes out against one candidate you implicitly endorse the other and I don't think that's a good position to put Wikipedia in. Sure, oppose any policy or law that undermines Wikipedia's goals, but play the ball not the man. Betty Logan (talk) 17:20, 19 September 2016 (UTC)
WP:SOAPBOX and per Betty, no, I don't think we have to much less that we should. I can understand our single soapboxing moment (SOPA), but that had distinct implications for how the Internet and thusly Wikipedia works. --Izno (talk) 17:21, 19 September 2016 (UTC)
Did you mean WMF? I thought WMF was already allowed to take political positions. Wikipedia, per se, is nothing but a bunch of editors, and opinion of Trump is not a matter for community consensus. We may not be apolitical, but we should behave as if we are. Can you clarify? ―Mandruss  17:26, 19 September 2016 (UTC)
You are aware that 95% of the world isn't the United States, right? We already have the servers in Amsterdam; in the unlikely event that a situation ever arose in which the WMF felt it could no longer operate in the US, relocating would just be a case of re-registering the office elsewhere. Assuming you mean Wikipedia itself taking a political standpoint, that you happen to dislike a particular candidate in an election is certainly not grounds for jettisoning the first and most fundamental of the WMF's founding principles, nor would Wikipedia last more than a few weeks if we did. ‑ Iridescent 17:43, 19 September 2016 (UTC)

I see it would be hard to justify a site-wide black-out or even banner based on a few comments by someone who changes his spoken views every few months anyway. But what about an open letter or some kind of group protest? Wnt (talk) 18:13, 19 September 2016 (UTC)

My reply still applies. Like we don't have enough to bitterly battle about, we should battle over this? Take the recent Trump photo war. Multiply by about 100. ―Mandruss  18:17, 19 September 2016 (UTC)
As someone who supported both the blackout of the Italian and the English Wikipedia, I don't think we're anywhere near a comparable situation at this moment. So far we're looking at a knee-jerk reaction of a presidential candidate, not ready-made bill that is about to be passed by Congress. Even if Trump wins the election, I doubt he will ever be in a position to put his ideas into law (remember who's the legislative power in the US). When this day comes, we'll have a look at it again. --bender235 (talk) 19:35, 19 September 2016 (UTC)--bender235 (talk) 19:35, 19 September 2016 (UTC)
I'm astounded to see anything but 100% rejection of this proposal. Wikipedia is an encyclopedia, not a political activist organization. The editing population couldn't be more politically diverse, but we are to determine the political leanings of a plural majority and present that as "the Wikipedia position" on Donald Trump? I don't fucking think so. And that goes for any political issue. ―Mandruss  20:09, 19 September 2016 (UTC)
This isn't a place fo politics so no to this proposal. Please see WP:NOT Gary "Roach" Sanderson (talk) 20:18, 19 September 2016 (UTC)

Also in depth the policy has something, and it is doing it see What Wikipedia is not#Democracy Gary "Roach" Sanderson (talk) 20:22, 19 September 2016 (UTC)

  • As far as WMF doing anything, that's a nonstarter. 501(c)(3) organizations can, to a limited degree, discuss political issues (like the SOPA bit), but they are strictly and absolutely forbidden from endorsing (or "disendorsing") specific candidates. They'd lose their tax exemption. As far as editors doing it? Well, let's do as we always do. That is, keep the article accurate and neutral, and let the facts speak for themselves. With Trump...let's just say I think those facts shout pretty loudly indeed. We don't need to editorialize. Seraphimblade Talk to me 20:26, 19 September 2016 (UTC)
Works for me, and I stand corrected as to WMF. ―Mandruss  20:49, 19 September 2016 (UTC)
  • Oppose. I am appalled to read a request such as the one above anywhere on Wikipedia. Can someone quickly close this nonsense. Thanks, GenQuest "Talk to Me" 00:52, 21 September 2016 (UTC)
  • Wikipedia must have no opinion on Trump. WP:NOTADVOCACY covers this. --SmokeyJoe (talk) 01:22, 21 September 2016 (UTC)
You ask..."how are we supposed to write an article like 2016 New York and New Jersey bombings without saying...?" We can say that the bombs were home made without giving the recipe. Actually, that's probably äll a general encyĉlopedia needs. Britmax (talk) 11:16, 21 September 2016 (UTC)
@Britmax: This very case illustrates how damaging that approach would be. A homeless guy wanted a backpack, grabbed the abandoned backpack, and recognized the pressure cooker bomb for what it was. [6] If ordinary people weren't allowed to know what a pressure cooker bomb is, and just had some genericized notion of "homemade bomb" resembling something out of a Bugs Bunny cartoon, he might well have simply left the bomb behind without telling anyone, or at least, set it off taking out himself and nearby people while curiously fiddling at it trying to figure out what it was.
Wikipedia must never be reenvisioned as a "general encyclopedia", in the sense of, containing only such information as is needed to entertain some dilettantes without serving the needs of the serious researcher or even the honestly interested reader. Wnt (talk) 15:09, 21 September 2016 (UTC)
  • Strong Oppose - Urge SNOW Close This proposal is shocking and contrary to both the letter and spirit of the WP:PILLARS. It is also incompatible with the longstanding tradition of avoiding any form of political editorializing. Anything even remotely along the lines of political endorsements or editorializing would inflict incalculable and possibly irreparable damage on the reputation of the project. For the record, I can't stand any of the candidates for President and I loathe Donald Trump. But if (purely for the sake of discussion) this proposal were adopted, I would immediately retire from Wikipedia and have nothing further to do with it. -Ad Orientem (talk) 15:31, 21 September 2016 (UTC)
Agreed. GenQuest "Talk to Me" 15:35, 21 September 2016 (UTC)
  • Oppose This is far from helpful, a discussion close should take place. - Knowledgekid87 (talk) 17:01, 21 September 2016 (UTC)
  • SNOW close this ludicrous suggestion. Much as I loathe the appalling, disgusting, deplorable creature that is Donald Trump, suggestions like this are just as chilling as his campaign banning certain media organizations. Do we want Wikipedia to be like the Trump campaign? -- Scjessey (talk) 17:07, 21 September 2016 (UTC)
  • Strong oppose per Pillar No.1 and Wikipedia is not a soapbox. What next - Wikipedia should take sides on Israel/Palestine, Russia/Ukraine, next year's German elections... ? JohnCD (talk) 17:44, 21 September 2016 (UTC)
  • Massive oppose No we should not AT ALL. This goes against everything in WP:5P1 and WP:5P2. We are supposed to be an encyclopedia and neutral. I'd feel this way regarding Trump, Clinton, or any other candidate for office. If we did this toward any candidate, I, like Ad Orientem, would immediately retire and wash my hands of the site. This is a very bad idea. RickinBaltimore (talk) 18:42, 21 September 2016 (UTC)
  • Absolute oppose Almost THE definitive example of WP:POINT. Timrollpickering (talk) 20:29, 21 September 2016 (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.

Wells Fargo Checking account scandal[edit]

I know this isn't technically the place to propose new articles, but I was very surprised to find that WP hadn't worked up an article on the Wells Fargo checking account scandal. I am having trouble finding the article or has this not made it to article creation yet? NickCT (talk) 17:03, 20 September 2016 (UTC)

WP:SOFIXIT. There is no mandatory "article creation" process. There's a process called "You want the article, just go make one". It's how approximately 100% of all Wikipedia articles got made in the first place. --Jayron32 17:40, 20 September 2016 (UTC)
@Jayron32: - Well I just might do that....! Honestly I was just here for a gut check. Does seem odd that this hasn't produced an article, no? Seems like a pretty major scandal. The notability seems obvious. NickCT (talk) 18:32, 20 September 2016 (UTC)
Nothing is obvious to people who haven't thought of it yet. Everything is obvious if you have. Obviousness is only a measure of the mental state of the singular person, not of the world outside of your mind. In other words, I have no idea why you have found it obvious, or why others have not. That's neither here nor there, it makes no difference at all why the article does not exist. If you have reliable sources, create the article. If you don't have reliable sources, don't. That's all there is to it. --Jayron32 19:08, 20 September 2016 (UTC)
@Jayron32: - re "Obviousness is only a measure of the mental state of the singular person, not of the world outside of your mind." - Well I think you just won the Zen Words of Wisdom prize. Thanks for the input. NickCT (talk) 13:04, 21 September 2016 (UTC)
I understand you wanted to make a compliment (or was it irony?). If this were true Zen, we would have no Captain Obvious. I would rather say that "obvious" is a subjective judgement which may or may not be commonly accepted, like in that joke about a mathematician presenting ("This formula is obvious." ... Fifteen minutes of hard thought later... "Yes, this is obvious indeed.")
As for the question itself, I am tempted to utter something Zenful about due diligence: "Confucius say: One and the same thing has many names, but only one is the True Name. A master of True Names never forks".
@NickCT:Wells Fargo#Consumer Financial Protection Bureau fines - The True Name thereof is not obvious yet. Staszek Lem (talk) 19:32, 21 September 2016 (UTC)
@Staszek Lem: - I'm not sure it was meant to be a complement or ironic. Just an observation about the philisophical nature of the comment.
I saw that subsection. Strikes me that the scandal is of a size that merits more than a subsection. Agree that name is non-obvious. NickCT (talk) 13:38, 22 September 2016 (UTC)
"name is non-obvious" - that's the point. Some scandals have buzznames, which can be searchable terms. Otherwise IMO no reason to crease a separate page before it grows out of a subsection naturally, per Wikipedia:Summary style. Obviously it does not strike you (or me or others) hard enough to WP:SOFIXIT, e.g., by a simple cut-and-paste... Staszek Lem (talk) 16:21, 22 September 2016 (UTC)

Note about "Historical Lenses"[edit]

Not completely sure where to put this but there should be a template that explains that History is a living thing, in that the various ways it is interpreted can change over time...I don't know if "historical lens" is a thing or not, but the idea is that people see history through their own view points, and this should be explained somewhere and all articles related to history should have a link to this explanation. I don't mean it as a disclaimer, but more as a means of being open about POV in its various forms, and that the reader may be unaware of. Hires an editor (talk) 23:42, 20 September 2016 (UTC)

This is not going to happen, since virtually every article on Wikipedia is "related to history" in some way. Why we don't do this is already covered by our FAQ—Wikipedia does not aim and never has aimed to be objectively true, but to give due weight to all significant views of any given topic. If new sources are published which refute or challenge a claim made in a Wikipedia article, we rewrite the article to include them as appropriate. ‑ Iridescent 09:49, 21 September 2016 (UTC)

Make certain warning templates visible on mobile[edit]

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

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

  • Wow! This makes a whole lot of sense given the above. Support. Quickly! GenQuest "Talk to Me" 13:10, 21 September 2016 (UTC)
  • Support. JohnCD (talk) 17:46, 21 September 2016 (UTC)
  • Support. Common sense. Also, active editors ought to install the Mobile Sidebar Preview gadget. --Dervorguilla (talk) 19:29, 21 September 2016 (UTC)
  • Support {{hoax}} and deletion temmplates as stated, as this is informaation the average reader would certainly wqant to know before reading the article; neutral about {{medref}}, sincfe we don't give medical advice. עוד מישהו Od Mishehu 03:02, 22 September 2016 (UTC)
WP:MEDRS's take is that "Wikipedia's articles are not medical advice, but are a widely used source of health information". Mobile readers are shown inline {{medrs}} flags on individual footnotes, but if a whole section or article has been flagged because a lot of its footnotes are questionable, the mobile reader is told nothing of this. (If it's a section that's been flagged, which seems common for {{medref}}, they don't even get the two-word "page issues" warning.) --McGeddon (talk) 08:33, 22 September 2016 (UTC)
  • Support as an equity issue. Important information should be accessible to all readers. Regards, James (talk/contribs) 05:34, 22 September 2016 (UTC)
  • Support these proposed tags, including {{medref}} - even though we don't give medical advice a lot of people do take our medical articles as guidance anyway so that is a problem. Maybe {{BLP sources}} should be included as well? Jo-Jo Eumerus (talk, contributions) 15:32, 22 September 2016 (UTC)
  • Support More to the point, why is it "a problem" with people seeking medical guidance from WP? It's likely to be of better quality than what "Mrs Jones from number 37 said her daughter remembered"; which short of a visit to a GP is how many people find out. Martin of Sheffield (talk) 15:56, 22 September 2016 (UTC)
    There is no mechanism to prevent people from inserting incorrect and potentially dangerous information into Wikipedia. And if someone follows such incorrect information, they could get hurt. Jo-Jo Eumerus (talk, contributions) 16:14, 22 September 2016 (UTC)
  • In general I support this, but I would ask we discuss thoroughly HOW we show this information, because just putting those boxes designed for desktop in 'as is' is gonna be problematic. —TheDJ (talkcontribs) 09:20, 23 September 2016 (UTC)
iPhone 5S screen showing an ambox on an article
  • I've added a screenshot of how this would look when not doing too much. The problem for me here is that it is either all text, or no text, since the templates don't have 'short' versions or titles or anything... If someone has an idea how to fix that, that would be very interesting. —TheDJ (talkcontribs) 09:48, 23 September 2016 (UTC)
    {{ambox}} actually does have short-version functionality at Template:Ambox#issue_and_fix, although the AfD and prod templates don't use it (putting everything in "text="), and speedy deletions use mbox instead of ambox. It looks as if "issue=" is about right in terms of length ("approximately 10-20 words") and scope (we need to tell mobile readers there's an issue, but we can skip telling them how to fix it). If the deletion boxes can be wrangled, changing ambox from "template always invisible on mobile" to "template visible on mobile if hoax/medref/AfD/etc, fix always invisible on mobile" might be enough. --McGeddon (talk) 10:22, 23 September 2016 (UTC)
    Another solution would be to add a "mobile=" field to a/mbox, and change the templates so that if the mobile field is set to anything, it displays a small box on mobile, and otherwise remains invisible. This would be neater for not having to hardcode "if medref or hoax or..." in a/mbox - the "mobile=" field could either be a yes/no flag (the box displaying the text from "issue=" if yes), or could be free text if we'd rather write new, concise versions for mobile display. --McGeddon (talk) 10:40, 23 September 2016 (UTC)
  • Support; vital information that shouldn't be hidden from readers. Jc86035 (talk) Use {{re|Jc86035}}
    to reply to me
    11:55, 23 September 2016 (UTC)
  • Strong support As James Allison alluded to, the absence of warning templates treats mobile users as second class citizens. We should not be treating 45% of our users as unworthy of warnings. In addition to the templates mentioned above, I would add all content warning templates, but if that's unpopular I'd suggest at the very least {{copypaste}}, {{POV}}, {{original research}}, {{POV-lead}}, {{contradict}}, {{contradict-other}}, {{contradict-other-multiple}}, {{misleading}}, all neutrality cleanup templates, all BLP sourcing problem templates, and {{disputed list}}. I'd also like the "discuss" link of {{dubious}} to show up. Hairy Dude (talk) 10:58, 24 September 2016 (UTC)

The future of New Page Patrol and Articles for Creation[edit]

Following 5 years of unstructured discussion, a dedicated venue has been created for combined discussion about NPP & AfC where a work group is also being composed to develop the necessary changes. It is not an RfC, it is a call for genuinely interested users who have significant experience in these areas to join a truly proactive work group. There is some reading to be done before signing up. See: Wikipedia:The future of NPP and AfC. --Kudpung กุดผึ้ง (talk) 11:22, 24 September 2016 (UTC)