Wikipedia:Village pump (proposals)

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

New ideas and proposals are discussed here. Before submitting:

« Older discussions, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143

Auto skip inactive editors from newsletters[edit]

Editors come and go, but if someone has not been around for a year or three their talkpage can get very cluttered with newsletters. Eventually as per an earlier proposal this prompts others to suggest that said inactive editor should start talkpage archiving, so why not autosuspend editors from subscriptions if they haven't edited in 4 months? It should be easy to change the newsletter bots to only post to talkpages of editors who have been active in the last 4 months. ϢereSpielChequers 19:15, 27 October 2017 (UTC)

Update. 4 months is arbitrary, I'm not actually bothered between 4 months and 12 months. Perhaps if others express a view on this then if the proposal has consensus the closer can set the time period. ϢereSpielChequers 10:48, 29 October 2017 (UTC)

Survey (Auto skip inactive editors from newsletters)[edit]

  • Support As proposer. ϢereSpielChequers 19:15, 27 October 2017 (UTC)
  • Support at one year. Users inactive for that long don't need active newsletter posts. Four months might be safe, but a year is safer. —swpbT go beyond 19:33, 27 October 2017 (UTC)
  • Support at whatever time threshold (4 months, year, ...). And this should be the default behavior for bots such as User:SuggestBot and Feedback Request Service. Of course, there should be an opt-out so people can ask continue to receive these posts despite their own inactivity. EEng 21:56, 27 October 2017 (UTC)
    The problem with in opt-in option is that some of us (and they don't know it) will either die suddenly, or become permanently incapable of editing Wikipedia suddenly. We don't want these users' talk pages to become cluttered with newsletters. While some of these users have friends who would be trusted to confirm that they will never be back, most probably don't. עוד מישהו Od Mishehu 12:46, 29 October 2017 (UTC)
    I said opt out i.e. the mechanism for suspending delivery after X months of a user's inactivity is active by default, but a user can opt out of that stop-after-4-months'-activity behavior if he wants i.e. set it so that even if he's inactive for X months, delivery continues indefinitely. No matter what, as soon as the editor makes any single edit, he's no longer inactive and delivery resumes. EEng 13:13, 29 October 2017 (UTC)
    A user opts out of delivery stoppiong, and then if this user dies suddenly (perhaps several years later), delivery still continues indefinitely. If it's reasonably possible, I would certainly say that if a user goes on a declared WikiBreak, delivery could start at the last round before the declared return date; however, we do need to put an absolute, non-overridable, date beyond which delivery stops. עוד מישהו Od Mishehu 07:55, 30 October 2017 (UTC)
  • Support Long, cluttered talk pages make it hard to see substantive content, and it is sometimes necessary to investigate why some things were done a certain way. Also, while monitoring pages with broken templates I have often found user talk pages where templates no longer work due to superfluous bot messages. Johnuniq (talk) 22:01, 27 October 2017 (UTC)
  • Support. Newsletters piling up on inactive talk pages is a nuisance. Alsee (talk) 23:41, 27 October 2017 (UTC)
  • Support, but give the user a notification to tell them their newsletters won't be sent if they don't perform an edit or logged action within the next N days (and/or a notification after the suspension of newsletters). Jc86035 (talk) 10:57, 28 October 2017 (UTC)
And so it begins. Let's not start adding more posts. They're just newsletters. Most such posts have a link that says, "To stop receiving this newsletter..."; change that to "To stop or resume receiving..." and leave it at that. EEng 14:23, 28 October 2017 (UTC)
  • Support as per previous comments, especially the desirability of avoiding long cluttered talk pages. Peter coxhead (talk) 19:47, 28 October 2017 (UTC)
  • Support, provided that the suspention stops immediately once editing resumes - that is, for the user to start getting them again, all (s)he needs to do is a single edit with no need to resubscribe; additionally, a bot should probably warn the user at the last delivery of a subscription (in a separate section) about such suspention. I think the longer of 4 deliveries and 4 months is lone enough. עוד מישהו Od Mishehu 11:22, 29 October 2017 (UTC)
  • Support with a time threshold and an optout. jcc (tea and biscuits) 11:33, 29 October 2017 (UTC)
  • Support I suppose, but I would much prefer 12 months. Jenks24 (talk) 12:09, 29 October 2017 (UTC)
  • Oppose - though, clearly, a good faith effort, this remedy has collateral consequences that suggest its achievable gains, both can and should be managed in some other, more efficient way. In general, I support centralized solutions over local solutions where the means are; invariably: more costly and far more inefficient. My recurring notifications arrive via an alternate account which this proposal, to my chagrin, would cease; for the editing inactivity of that account. Not withstanding these, I can not support the local mechanics of this proposal, nor the stifling effects their inadequacy too often spawn.--John Cline (talk) 06:41, 30 October 2017 (UTC)
Forsooth, my liege, thou canst opt-out, thus to continue the succor of thy monthly Signpost! EEng 07:16, 30 October 2017 (UTC)
One potential solution would be a bot which can parse templates from Category:Alternative Wikipedia account templates, and keep delivering to a publicly-declared alternate account if the main account is still active. עוד מישהו Od Mishehu 07:57, 30 October 2017 (UTC)
  • Support 12 months. At a minimum 6, but 4 months sounds too short to me (call it unbelievable, but some people have jobs that require them to travel to far-away places without internet, and a 4-month lapse seems way too short to establish an account will probably not be used any more). Whether the proposal does not solve certain edge cases (e.g. opting out before having a stroke) is not all that relevant (see nirvana fallacy). TigraanClick here to contact me 08:44, 30 October 2017 (UTC)
  • Support 1 year. Longer may be necessary, but I think 1 year is a good start. JTP (talkcontribs) 01:57, 31 October 2017 (UTC)
  • Oppose In the case of some newsletters, it can spur people into activity. --Rschen7754 04:01, 31 October 2017 (UTC)
    But this is about cases where it hasn't (most people seem to favor a full year or more before this triggers).  — SMcCandlish ¢ >ʌⱷ҅ʌ<  15:53, 6 November 2017 (UTC)
  • Support Swarm 20:32, 2 November 2017 (UTC)
  • Support. Don't care much about the time span; anything over about 6 months seems fine. No prejudice against some other solution (per John Cline).  — SMcCandlish ¢ >ʌⱷ҅ʌ<  15:53, 6 November 2017 (UTC)
  • Support a year. Excessively cluttered talk pages serve nobody any purpose. A year's worth of twice a month newsletters is 24 sections! – Train2104 (t • c) 19:00, 6 November 2017 (UTC)
  • Support a year. If they're not logging on, it's just piling up. White Arabian Filly Neigh 16:29, 8 November 2017 (UTC)
  • Comment. I think it is important that this be a minimum prescribed behavior - that it explicitly allows bots to drop subscribers who have been inactive for a shorter timeframe than what looks to be the 12 month consensus. If memory serves, the feedback request service stops after one month on inactivity, and this policy definitely should not supersede that timeframe, nor any other talk page subscription that expires in less than a year. VanIsaacWScont 17:35, 10 November 2017 (UTC)
  • Support a year - Long overdue!, If those inactive still want to read for instance the Signpost then they can bookmark that page .... –Davey2010Talk 00:07, 11 November 2017 (UTC)
  • Support I didn't edit Wikipedia for two years, and my talk page was completely cluttered. I think that this is a great idea for inactive accounts. EMachine03 (talk) 14:25, 15 November 2017 (UTC)
  • Support this obvious proposal (i can't believe no one has suggested this already). The timespan is less important, though a year's inactivity should be the outside length. Happy days, LindsayHello 10:31, 19 November 2017 (UTC)
  • Support anything from 4 months and 12+ months. 6 months seems very reasonable and useful if you have to pick a number. Dennis Brown - 17:25, 20 November 2017 (UTC)

Threaded discussion (Auto skip inactive editors from newsletters)[edit]

  • This looks very much like a solution in search of a problem. If someone hasn't edited for 4 months then why would anyone feel the need to read the user talk page anyway? And if nobody is reading the page then what does it matter how long it is? It's quite possible that a user doesn't edit but is still interested in reading newsletters, and, if not, it does no harm to carry on sending them. (talk) 20:19, 27 October 2017 (UTC)
Many of us will have multiple inactive Wikipedians on our watchlists. The absent Wikipedian can be assumed absent, but not others. As for the problem, eventually these newsletters turn such talkpages into ones that are slow to load, hence the earlier, more intrusive proposal to autoarchive them. ϢereSpielChequers 21:30, 27 October 2017 (UTC)
I've got a number of "missing Wikipedians" on my watchlist hoping to be able to welcome them back, and these notices every few days just gum up my watchlist. I find the argument that maybe someone is silently reading newsletters for a year, without making a single edit, unpersuasive to say the least. Anyway, we can have an opt-out by which people can explicitly ask to continue receiving. EEng 21:56, 27 October 2017 (UTC)
Does anyone force you to have these pages on your watchlist? Surely you can just remove them. This is supposed to be an encyclopedia, not a social networking site, so welcoming people back should be very low on anyone's list of priorities. (talk) 18:40, 28 October 2017 (UTC)
I disagree; there's a serious shortage of editors, and welcoming editors back is very worthwhile. Peter coxhead (talk) 19:49, 28 October 2017 (UTC)
I realise that I'm in a minority here, so I'll make this my last comment, but I don't believe that there is any evidence that any of this touchy-feely stuff actually leads to a better encyclopedia, which is supposed to be what Wikipedia is about. (talk) 21:24, 28 October 2017 (UTC)
  • Most of the larger newsletters are sent using MassMessage from opt-in lists. I think 4 months is too short, perhaps a year - and mailing lists may want overrides on this. — xaosflux Talk 17:03, 28 October 2017 (UTC)
    It's not difficult to remove other people from MassMessage mailing lists; here's one that I did recently. --Redrose64 🌹 (talk) 20:40, 28 October 2017 (UTC)
    When people die mailing list removal makes sense, but if people are on a long wikibreak then skipping inactives is much better - after they come back the latest issue will turn up after a while. ϢereSpielChequers 10:45, 29 October 2017 (UTC)
    And if someone is severely sick for a long time, there's a chance they may be back eventually; returning them to the active delivery list shouldn't require any action on their part. עוד מישהו Od Mishehu 12:49, 29 October 2017 (UTC)
  • @WereSpielChequers: can you explain how easy to change the newsletter bots to only post to talkpages of editors who have been active in the last 4 months? Also note - not all newsletters are sent "by bots", regarding MassMessage above - are you proposing that the extension somehow be able to detect "activity"? Will cross-project activity account? What is your measure of this (e.g. will a logged action suffice?) — xaosflux Talk 00:40, 30 October 2017 (UTC)
    For example, lets look at a very popular newsletter, Wikipedia:Wikipedia Signpost - this is not sent "by bots", it is sent by editors. — xaosflux Talk 00:45, 30 October 2017 (UTC)
    Hi Xaosflux. I'm happy for cross project activity to count, and yes one logged action would be sufficient to show you are still around - afterall we do have cross project notifications now so if you are only active on commons you would know if you were still receiving a newsletter on EN. As to the mechanics of this there are several ways it could be done. It could be on the fly with a new massmessage bot that people could use putting in their subscription list and the latest newsletter, or a standalone bot that moved people from subscription lists to an inactive subpage and back again when they reappear. At present I'm just seeking consensus for it to happen, precise mechanics would be up to the bot writer. ϢereSpielChequers 07:10, 30 October 2017 (UTC)

Can inactive editor be determined by having logged in, rather than edited? Because if you are never logging in you probably won't be looking at the notices anyway. ClubOranjeT 19:39, 30 October 2017 (UTC)

  • I'd be somewhat in support of a software change to the MassMessage extension to "skip inactive" users, possibly as an option that the sender could use. This would require developer time. — xaosflux Talk 04:26, 31 October 2017 (UTC)

Should talk page newsletter notices be abolished completely?[edit]

  • Has there ever been a community discussion about whether "newsletter" notification should ever be used? I find it lazy and obviously its become resource intensive on inactive editor pages. Why can't we expect editors to just put newsletters in their watchlist and keep informed via that existing mechanism rather than use a bot-driven, spammy mechanism like talk page posts? Every time a "newsletter" is updated, it becomes my watchlist that is spammed as many people I've interacted with on their talk page gets these notifications. -- Netoholic @ 07:33, 30 October 2017 (UTC)
    Indeed; I have never subscribed to The Signpost, but sometimes read it - on the user talk pages that I am watching for other purposes. My own User talk page stays pretty clear of newsletters - all the ones that I'm interested in are subscribed to by other people. --Redrose64 🌹 (talk) 09:48, 30 October 2017 (UTC)
    Is that what happens to my New York Times some mornings? EEng 19:36, 30 October 2017 (UTC)
    Especially with the notification system (which is newer than these newsletters were originally created), these subscriptions are probably unneeded. With the signpost we have a transcludable template, a system which can be used for all newsletters; a bot could easily PURGE all pages transcluding a particular newsletter's template, and the notification system will inform any interested user about the new edition without spamming any page visible to anyone else. However, if we make such a change, we need to actively inform all users on any distribution list about this change. עוד מישהו Od Mishehu 13:50, 30 October 2017 (UTC)
  • Hmmmm... There's a good point here. Maybe people who want to subscribe should just add a template to their page which transcludes the current version of the newsletter, plus whenever there's a new "edition" they would get a ping. (The template would add the user to a category, and everyone in that category gets the ping.) That's a very clean approach. EEng 19:39, 30 October 2017 (UTC)
  • Brilliant. That would solve all problems. And it could include a link to an archive in one location that lists every issue so the hypothetical contributor who has been offline for ten months can spend a couple of days reading the past issues to see what they've missed. Johnuniq (talk) 22:10, 30 October 2017 (UTC)
Johnuniq, you know the Ways of the Pump better than I. Can you find the best way to make sure other participants in this RfC know about this? Perhaps WereSpielChequers will suspend this RfC in favor of a new one on this template idea -- we can always revive this discussion if the template idea fails. When you think about it, the template idea is way easier to implement, and with fewer design decisions to make (e.g. what counts as activity?). EEng 23:07, 30 October 2017 (UTC)
I see no need to abolish these entirely, but they might become redundant to Extension:Newsletter if installed. Sam Walton (talk) 23:15, 30 October 2017 (UTC)
Um, OK, well it seems unnecessarily complicate, but anyway why isn't it being used already? EEng 23:17, 30 October 2017 (UTC)
That extension looks insanely bureaucratic for the purposes of most Wikipedia newsletters, and I'd vehemently oppose any suggestion to roll it out across Wikipedia except possibly for a couple of high-traffic high-visibility newsletters like Signpost. As I read it there will be a separate set of admin-granted userrights for every single newsletter, and anyone wanting to contribute to a newsletter will need to persuade an admin to grant them the "publisher" userright for that specific newsletter—no sane person is going to want to jump through those hoops. ‑ Iridescent 23:29, 30 October 2017 (UTC)
mw:Extension:Newsletter#User Rights says that by default only admins can do things, but the extension would be customized for whatever was wanted at enwiki. For example, certain groups (say admins) could create or delete a newsletter, but other groups (say extendedconfirmed = 30 days/500 edits or autoconfirmed = 4 days/10 edits) could manage any newsletter. Johnuniq (talk) 03:19, 31 October 2017 (UTC)
  • As a purely practical issue, assuming I'm understanding this proposal correctly as "if you want to subscribe to a newsletter, transclude it to your talkpage or a dedicated newsletter page in your userspace and you'll get a notification when it's updated", I can see a potential issue with Wikipedia's numerous phantom newsletters. Because of the tendency for people to get bored, a lot of newsletters get updated very infrequently—to take an extreme example, had this setup been in place previously all of these people would have had the December 2013 edition of the WikiProject London Transport newsletter sitting on their talk page for the last four years as nobody's bothered to put out a fresh issue since then. ‑ Iridescent 23:30, 30 October 2017 (UTC)
Well, then, after a while someone noticing that the LT newsletter is stale can just go move the "current" (way old) issue to the newsletter archives, making the current issue empty i.e. there's no current issue. EEng 00:28, 31 October 2017 (UTC)
Changing a transcluded template does not trigger echo notification. And why would you want to keep an old newletter on your page indefinitely - not knowing when it is going to be updated again? — xaosflux Talk 01:40, 31 October 2017 (UTC)
Re how the notification works, please read my proposal carefully, in the post starting "Hmmmmm." Re "indefintely", as also already explained, defunct newsletters can be blanked. EEng 02:37, 31 October 2017 (UTC)
@EEng: have you got a working demo of this? I just tried a quick and dirty and neither changing the transcluded page, or changing the category it include only'd had any echo notification to another account transcluding such page. (including after a force purge) — xaosflux Talk 04:01, 31 October 2017 (UTC)
I'm not making myself clear. A bot would walk the category and ping every user in it. I don't know if it's possible for a custom message to accompany a ping e.g. A new issue of the X newsletter is now available on your Talk page. Honestly, though, now that I think about it, why not then just ping people to the page where the newsletter itself is, and just skip the transclusion part? EEng 04:08, 31 October 2017 (UTC)
Ping them where (some random page?, the actual newletter template?) This also requires every single project with a newletter to get a bot to manage their newletters and MassMessage - is that what you are proposing? — xaosflux Talk 04:25, 31 October 2017 (UTC)
A bot delivers the newsletters now. In no way does this require "every single project with a newletter to get a bot to manage their newletters and MassMessage" – what are you talking about? A project that wants to use this very simple technique can do so, and everyone else can keep doing what they're doing if that's what they want. EEng 04:37, 31 October 2017 (UTC)
Hi @EEng: we must have a big disconnect in this scope - which "newsletters" are you referring to? I'm seeing this on VPR and thinking this is a proposal to change enwiki newletter processes in general - if any single project wants to change how their newletter wants to be managed, it doesn't need to be here, they can just do it. For reference, several newsletters on my own talk page were not "delivered by bots", whereas other things that are not "newletters" (such as SuggestBot suggestions) are actually delivered by bots and maybe unneeded clutter for departed editors. — xaosflux Talk 05:02, 31 October 2017 (UTC)
  • Maybe abolish in favour of an unsubstituted template? I'm just now wondering, I might prefer to receive newsletters, like the signpost, by email. Investigating, I might like the Wikipedia:Wikipedia Signpost/Subscribe Watchlist notification method. --SmokeyJoe (talk) 04:05, 31 October 2017 (UTC)
Um, an unsubst'ed template is exactly what I'm proposing. EEng 04:08, 31 October 2017 (UTC)
Where? --SmokeyJoe (talk) 04:57, 31 October 2017 (UTC)
A dozen posts up, starting with "Hmmmmm..." EEng 05:21, 31 October 2017 (UTC)
Unsubst'd templates/transclusions have the disadvantage of never notifying people that the template was changed. A new message on your talk page lights up your notifications; a change to a page that you're transcluding doesn't even put your talk page in your watchlist.
Iridescent, there's currently a live test of Extension:Newsletter at mw:Newsletter:Tech Showcase, and it really doesn't seem to be bureaucratic. User:Qgil-WMF could give you more information about the practical details, but as far as I can tell, he just tells it to send a page to everyone. It probably doesn't take him even 30 seconds to send the "newsletter".
@MZMcBride: People are talking about changes to MassMessage, so you might want to look this discussion over. Whatamidoing (WMF) (talk) 17:02, 8 November 2017 (UTC)
Whatamidoing (WMF) It's not the sending that's bureaucratic—unless I'm misreading the documentation completely, each newsletter will need to have its own bureaucratic structure with specific userrights for who can edit it and who can send it out. Thus, if I were to try to revive (for instance) the aforementioned moribund London Transport newsletter, I'd need to find out who was currently its admin (who may not even be active any more, given that the newsletter hasn't been published since 2013), persuade them to grant me the editor right for that newsletter, persuade them to grant the editor right for anyone else I wanted to approach to contribute to it, and then persuade them to send it out or grant me the right to send it out. The sort of people who have time and inclination to jump through that many hoops aren't the sort of people who are likely to have anything very interesting to say. ‑ Iridescent 18:41, 8 November 2017 (UTC)
Having glanced at the documentation, I think that any admin (i.e., anyone on the list at Special:ListAdmins) can grant you the right to send out any newsletter. ("Editing" a newsletter is just a matter of editing a normal page.) Whatamidoing (WMF) (talk) 04:47, 9 November 2017 (UTC)
Iridescent, Whatamidoing (WMF), Johnuniq Hi, mw:Extension:Newsletter was designed with minimalism in mind. The permission to create newsletters is currently set to admins in because it is a new extension and we wanted to see it being used by real publishers without risking types of abuse that we hadn't think of. It can be configured to any user group. I personally think that newsletter account creation can be permissive, because the potential damage is directly proportional to the number of subscribers, and a publisher will only get subscribers if the newsletter is interesting, not some kind of spam. Once the newsletter has been created and a publisher has been assigned to it, the publishers of that newsletter can add/remove other publishers themselves. I don't think you can have it simpler than that. For what is worth, the Newsletter extension is not being deployed to other Wikimedia wikis as long as interwiki support is not resolved (phab:T110645). Qgil-WMF (talk) 10:54, 9 November 2017 (UTC)

Hi. Thanks for the ping. It's no real secret that EdwardsBot was a spam bot. And its replacement MassMessage created infrastructure and additional legitimacy to the concept of spamming user talk pages. The architecture never made much sense, obviously. I always found it akin to, as EEng suggests, delivering the paper to household driveways and businesses when you could instead have a Web site. But people really liked getting the talk page messages, just as some people still like getting the newspaper delivered to their home or office.

I think that's kind of a key point: hundreds of people subscribed to The Signpost and liked getting a new talk page message each week, so we supported that. User talk page messages also came with "free" e-mail notifications for users who have talk page messages send an e-mail. And, yes, of course, you could just e-mail people directly instead, but people liked getting the talk page messages for The Signpost, for wiki meetup invitations, for newsletters, etc.

The wiki talk page delivery system is also used with non-user talk pages. Some users watchlist centralized pages that receive notifications, such as technical news posted to Wikipedia:Village pump (technical).

I'm not clear to me what specifically is being proposed for the MassMessage extension or the Newsletter extension, but the better venue is probably Phabricator. :-) --MZMcBride (talk) 05:28, 9 November 2017 (UTC) (cc: Legoktm, wctaiwan)

Newspaper deliverers to remove old newspapers still on the driveway[edit]

  • This may be mildly complicated, but I think the bots used to deliver newletters should scan for the previous newsletter and remove it it is still there. The archive of all newsletters should be stored at the source, not on recipients' talk pages or even their talk page archives. --SmokeyJoe (talk) 03:58, 31 October 2017 (UTC)
    Again, please note most of these are not "delivered by bots" they are delivered by the MassMessage process, the sender never interrogates the recipient pages. — xaosflux Talk 04:01, 31 October 2017 (UTC)
    Maybe they should be delivered by bots, who could then clean up previous issues of the newsletter. Ivanvector (Talk/Edits) 12:24, 31 October 2017 (UTC)

Show the metadata gadget to all readers[edit]

The metadata gadget gives a reader a summary assessment of the quality of the article in question. In the case of featured and good articles, it is more prominent than the star or icon on the side. In the case of lower quality articles, it gives the reader an expectation of the quality of the content that they are going to see (they can then read the article and then judge it on its own merits).

Should the Wikipedia:Metadata gadget be shown to all readers, logged in or logged out, regardless of whether it is enabled as a gadget for registered users? My name isnotdave (talk/contribs) 12:22, 10 November 2017 (UTC)

Survey (Show the metadata gadget to all readers)[edit]

  • oppose — Readers unfamiliar with wikipedia may find this confusing. And you say you don't want it to be enabled by default, but how else would readers that aren't logged in activate/deactivate it? Natureium (talk) 20:37, 10 November 2017 (UTC)
  • Strong Oppose both from the resource concerns discussed below, but also because this system is not designed for readers. FA's and GA's already get an article identifier. If we want a full quality rating system, we need to pick one and install it (e.g. a flavor of mw:Extension:FlaggedRevs or the like. — xaosflux Talk 21:36, 10 November 2017 (UTC)
  • Oppose – There isn't a compelling encyclopedic reason to impose our internal quality rating system on our readers. All of the classes other than FA and GA (and the rare A-Class) are self-assigned, oftentimes even by the creator of the article themselves. As a result, there is a good deal of variation in the actual quality of specific ratings – some B-Classes could very well be GAs whereas others are probably closer to C-Class or even Start-Class. Given the amount of subjectivity, these quality ratings are probably less important/meaningful to readers as they might be to editors. Mz7 (talk) 23:31, 10 November 2017 (UTC)
  • Oppose - I see no value in this proposal. Beyond My Ken (talk) 18:05, 11 November 2017 (UTC)
  • Oppose the rating system, especially beyond GA/FA (which are already displayed), has too many problems to be promoted to logged-out users. power~enwiki (π, ν) 18:51, 11 November 2017 (UTC)
  • Oppose not a default suited tool, showing it for all readers is effectively that. The article rating system is just an internal tracker mostly for WikiProject work tables, all that matters for the readers is GA/FA and stub, all of which are shown already. Any editor who needs this ought to have enabled it already. Dysklyver 12:26, 12 November 2017 (UTC)
  • Support Providing it would not put an unreasonable drain on the servers (and I accept it may well do!), I see absolutely no reason for hiding any quality/completeness assessment from any of our readers or editors, whether logged in or not. We invite both user-types to make improvements where they can, so should facilitate them seeing how the community has currently assessed each article and encourage their improvement where we can. It's a really useful guide to editors on page quality, whilst non non-editors (school students especially) should be aware of the quailty of what we're giving them to use in their homework. Someone said there's no compelling reason - I think the reverse. It should be available by default, and removable if wished by logged-in users. As the Hovercard page eloquently explains: Unfortunately, there is no good way to tell users about a new feature without showing it to them first. OK, it's not a new feature, but why on earth should we hide our own assessment of the quality of each page? If the assessment is wrong, having it more clearly displayed can only encourage others to make a re-evaluation or an improvemnt to the article. Stamp it on every page, I'd say. Regards from the UK, Nick Moyes (talk) 17:25, 12 November 2017 (UTC)
  • Oppose. I use it, and find it useful, but that's because I understand how the system works; a tiny minority of IP-only editors will benefit from this, but 99.9% of anglophone Internet users won't understand what it means, and we'll confuse a good proportion of them. `Nyttend (talk)
  • Oppose, will confuse majority of readers. Stifle (talk) 10:30, 14 November 2017 (UTC)
  • I have no idea what this is and neither will 99% of readers TonyBallioni (talk) 23:23, 14 November 2017 (UTC)
  • Oppose. Other than FA, GA and stub, all of which are already flagged to readers, Wikipedia's article assessment scale is almost completely arbitrary and will mean absolutely nothing to readers. (Would you understand a grading scale where the grades are S-C-B-G-A-F if it weren't explained to you?) If anything, we should probably be deprecating it altogether, as its original purpose (to determine which articles were of an adequate enough quality to be included in proposed print and CD-ROM versions of Wikipedia) is long since obsolete. ‑ Iridescent 23:32, 14 November 2017 (UTC)
  • Oppose. The assessments are totally subjective. For those articles that don't go through WP:FAN, WP:GAN, or WP:Peer review, anyone can assess an article as whatever grade they want, which isn't very helpful for our readers. -- œ 04:58, 15 November 2017 (UTC)
  • Oppose Showing this for everyone will just confuse the large majority of Wikipedia readers that don't understand Wikipedia quality standards. EMachine03 (talk) 14:29, 15 November 2017 (UTC)
  • Oppose. Ugh. feminist 15:02, 18 November 2017 (UTC)
  • Support Most articles are utter junk and the reader should know that. Chris Troutman (talk) 21:01, 18 November 2017 (UTC)
  • Oppose As per Mz7. This would be a lot of overhead for what is very little objective information. Dennis Brown - 17:24, 20 November 2017 (UTC)
  • Oppose - This would only confuse our readers and that isn't something we want to do.... –Davey2010Talk 21:01, 20 November 2017 (UTC)

Threaded discussion (Show the metadata gadget to all readers)[edit]

  • Regardless of wether or not the information should be shown.. In its current form, we will not make this a default gadget, because it would be prohibitively resource intensive on all readers and on the servers. If you want to show this information for all readers, you need to do it with a PHP extension. —TheDJ (talkcontribs) 13:07, 10 November 2017 (UTC)
    And could this happen? My name isnotdave (talk/contribs) 13:16, 10 November 2017 (UTC)
    Sure if someone puts the work into it. Many things are possible in Software engineering, the better question is how expensive and time-consuming will it be :) —TheDJ (talkcontribs) 15:06, 10 November 2017 (UTC)
    Good. I did not expect that this proposal would mean that the gadget would remain a gadget. It didn't seem like the standard way of doing things. My name isnotdave (talk/contribs) 15:45, 10 November 2017 (UTC)
  • Question: does this affect only desktop or mobile as well? Renata (talk) 16:31, 10 November 2017 (UTC)
    @Renata3: Good point. I was not thinking about mobile. Calvin Coolidge, a featured article, does not have its star on the mobile layout. My name isnotdave (talk/contribs) 18:42, 10 November 2017 (UTC)
    FWIW, @My name is not dave:, I think implementing FA and GA icons on mobile is a better reader experience idea than this intrusive and unnecessary implementation. Triptothecottage (talk) 07:01, 19 November 2017 (UTC)

Simple diff[edit]

Normal diff
Simple diff

Your thoughts on this are welcome here or at m:2017 Community Wishlist Survey/Reading. In the normal diff it is often difficult to see changes to the text of an article because of all the formatting, template and other code. (Flip between these two images a few times.) At the Wikimedia Wishlist, I’ve proposed WMF develops a simple diff so patrollers, editors and authors can see at a glance how the meaning of an article has been changed. This, obviously, isn’t meant to or going to replace the normal diff. It’s just an additional tool. —Anthonyhcole (talk · contribs · email) 07:49, 13 November 2017 (UTC)

Um, how is "Simple diff" easier than "Normal diff"? It fails to show the replacement of text with templates, the modification of citations, and more. Also, how does it handle transcluded templates? Apparently it displays the result of the template (look at the 40/104 item in the second line of each item); does this mean that the diff will change later if someone edits the template? And will it display changes to infoboxes, bottom-of-article navboxes, etc? Nyttend (talk) 00:40, 14 November 2017 (UTC)
An ongoing WMF project they call “visual diff” is reaching maturity now and, with little tweaking, I think it will fulfil my wish here. You can access the visual diff feature while using the visual editor by clicking “view your changes” and “visual (beta)”. If I can link to a visual diff from a page’s history, and that seems eminently doable, that will meet my needs. It looks like the visual diff will include template changes - not sure about transclusions, images, Wikidata infoboxes, Nyttend. —Anthonyhcole (talk · contribs · email) 04:46, 14 November 2017 (UTC)

Using Wikimedia maps instead of geohack ?[edit]

Looking for some feedback here. Please do leave your comments. —TheDJ (talkcontribs) 07:54, 15 November 2017 (UTC)

TfD for Authority Control[edit]

I started a deletion discussion for Template:Authority control at Wikipedia:Templates for discussion/Log/2017 November 15#Template:Authority control. As this is a template that is in use on more than 500,000 pages, and at the same time the TfD is currently only visible to people watching the actual template or TfD, I thought dropping a note here would be good. Feel free to spread the word at other neutral boards as well (or WP:CENT if you think it is warranted). Fram (talk) 16:13, 15 November 2017 (UTC)

RfC: Add a link to Wikinews on the Main Page[edit]

Proposal: A link to Wikinews should be on the main page, perhaps in the "In the news" section.

Rationale: A recent RfC on WP:NOTNEWS stated that the policy should be loosened because "Wikinews is dead". Regardless of the outcome of that RfC, I believe that Wikinews' problem is the lack of outside readership, and therefore editors. A more prominent location on Wikipedia's homepage would likely do wonders for the traffic to Wikinews, which is likely the only viable solution for its lack of readership and contributors.

As I put it in the Idea Lab, which I posted when I was more awake and by extension a lot more convincing:

The rationale is "Wikinews is dead". You know, sure. It's not the most popular WMF project - not by a long shot. However, the problem is mainly that:

  1. No one seems to know it exists (except the more active Wikipedians)
  2. Not many non-editors go there
  3. No one seems to know it exists (again, I know, but no one does)

I know Wikinews is technically on the main page by the other WMF pet projects, but a link in In the news will be more beneficial to WN.

Below is a copy of the discussion on the Idea Lab. Thanks. ProgrammingGeek talktome 15:19, 16 November 2017 (UTC)

Discussion copy
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.

Okay, I know what you're thinking. Hear me out.

This RfC proposes to reduce the enforcement of WP:NOTNEWS to increase news coverage on Wikipedia.

The rationale is "Wikinews is dead". You know, sure. It's not the most popular WMF project - not by a long shot. However, the problem is mainly that:

  1. No one seems to know it exists (except the more active Wikipedians)
  2. Not many non-editors go there
  3. No one seems to know it exists (again, I know, but no one does)

Whether or not it's a good or bad idea to put news in Wikipedia is not a discussion for here. However, why does wikipedia not try to increase awareness of sister WMF projects? enwiki is in a good place to do this, it's one of the most popular websites in the world, and is renowned for its impartiality and stunning dedication to consensus. WN is much the same, but without participation. If we could increase participation and awareness (the two go hand in hand, just look at the growth of the number of editors on enwiki), then it could be a quality news source that people rely on.

Isn't it already on the front page? Yes, technically. By the links for Wikibooks and the other pet projects of the WMF. However, if we could link to it more prominently (eventually link to WN articles in the In the News section, perhaps), it would grow a lot more.

Haven't we given it up for dead? They're still publishing articles over there, although admittedly few. We could do a lot better!

I'd just like thoughts at this point. Thanks. ProgrammingGeek talktome 15:56, 8 November 2017 (UTC)

This does not address the fundamental problem of; consumer demand of recentism and Wikipedia quality vs. Wikipedia's rigid stylistic form and immediate publishing vs. copy cat news website that usually publishes after people stopped showing interest in the topic, if at all. We have created this situation to reflect our reality, but we need to recognize that it is not a situation that a consumer will ever consider logical. As such we cannot fix the problem unless we start bending either Wikinews or Wikipedia to closer match the desire of real consumers of the information. —TheDJ (talkcontribs) 16:20, 8 November 2017 (UTC)
There's several concurrent discussions related to NOT#NEWS in general, but one of the issues that comes up is the "consumer" aspect - that we do know people are coming to Wikipedia for current news articles. The problem is that an encyclopedia should be the last place you come to breaking news, as we're supposed to be summarizing news with a long-term view. There are stories that we can write on with that perspective, but it is a very careful approach, but vastly different from how one would write a standard newspaper article (eg what would be more appropriate at Wikinews). Unfortunately, there's a fair number of editors that like to write recent news, and no end of consumers for that. That said, we have in the past taken steps to cut off content that may have been consumer-driven: for example, early on was the removal of endless lists of fiction-related elements that were only sourced to primary works (eg Pokemon lists). They may have been popular pages, but as they were written then, not encyclopedic content. We have to have a consensus decision to cut off current event articles and move them elsewhere, and these concurrent discussions suggest that's not going to happen easily. --MASEM (t) 19:02, 8 November 2017 (UTC)
Masem, exactly. We have a ready-made location for this sort of content. I don't want it to seem like we're outsourcing the problem, but if people know about Wikinews, we won't be inundated with these articles. ProgrammingGeek talktome 19:11, 8 November 2017 (UTC)

To raise awareness of other Wikimedia foundation projects, could we not put information about them on Wikipedia: Main Page? The main page is one of the most viewed articles on Wikipedia, if not the most viewed, and putting information about Wikipedia's sister projects on the main page would seem a good way to raise awareness of them. Vorbee (talk) 18:23, 8 November 2017 (UTC)

The Main Page of Wikipedia has a section in its top right-hand corner called "In the news..." ... it should not prove too difficult to put in a note that there is such a website as Wikinews there.Vorbee (talk) 20:14, 8 November 2017 (UTC)

  • I support linking to Wikinews articles in the "In the news" section of the main page because Wikipedia is not for news, but Wikinews is, and if we're going to mention news on our main page, we should link to our sister project, not just Wikipedia articles. Conservapedia has a similar section on its main page, commonly known as "mainpageright," it has included links to external sites for a long time, and it is one of the most popular features of the wiki. PCHS-NJROTC (Messages)Have a blessed day. 22:10, 8 November 2017 (UTC)
  • This does seem like a useful idea, regardless of other developments (unless there is a vested interest in actually having WikiNews wither on the vine). --Elmidae (talk · contribs) 09:25, 15 November 2017 (UTC)

Perhaps we could have a note at the bottom of the Main Page's "In the news" box saying "For more information on news stories, see Wikinews". Vorbee (talk) 16:31, 15 November 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.



  • Support We should make an effort to keep Wikinews afloat. Dysklyver 21:52, 16 November 2017 (UTC)


  1. Oppose WikiNews is dead. They have nothing serious to offer our readers and would decrease our credibility. I'd support a global RfC just to get rid of it as a project. While I am very much team NOTNEWS needs to be enforced, our ITN section offers our readers infinitely more than WikiNews ever would. Sending people who want to learn about relevant current events to a project that doesn't have that would be a joke. TonyBallioni (talk) 21:55, 16 November 2017 (UTC)
  2. Wikinews is completely defunct and the only reason it still exists is that nobody has the energy to start the Meta RFC to pull the plug. (FWIW, in the entire month of September a mighty 19 people made five or more edits there, and that was the highest rate of activity for over a year.) Even Jimmy, who was the main cheerleader for creating it, has lost all interest and has instead set up a direct rival. The conversation to be having is how it can be put out of its misery most painlessly, not what we can do to prop it up a little while longer. ‑ Iridescent 22:12, 16 November 2017 (UTC)
  3. I wanted to support this as an experiment, but then I remembered that we used to have the Wikinews link until 2013. Things were not much better then. Note that I would support a "link to Wikinews" proposal if there was at the same time an effort to re-start Wikinews (which currently has many problems, mostly linked to the fact that it isn't a very wiki Wiki). —Kusma (t·c) 18:02, 19 November 2017 (UTC)
    For the curious, if you look at the Wikinews page views (third chart down), removing the link had almost no measurable impact on average page views. (The later apparent crash in 2015 is an artefact of the WMF deciding not to count crawler bots as "page views", and doesn't reflect any actual change in the number of readers.) ‑ Iridescent 18:08, 19 November 2017 (UTC)
  4. I suspect wikinews is effectively dead as per evidence posted above. And linking will not benefit it Cas Liber (talk · contribs) 23:30, 19 November 2017 (UTC)
  5. I don't support propping it up. If it survives, it should be on its own merits. If it regains merit, then we would consider linking it. Linking it now is a disservice to the reader. Dennis Brown - 17:22, 20 November 2017 (UTC)
  6. Their recent changes indicate WikiNews is long dead, Seems kinda stupid to redirect our readers to a site they have 0 interest in and is long dead, Linking could bring in some editors but I highly doubt it, If anyone wants to run an Meta RFC on pulling the plug I'd support that tho!. –Davey2010Talk 20:55, 20 November 2017 (UTC)
  7. Don't prominently link to it from the main page, and NOINDEX it because it's no kind of service to the reader in its present state. --Anthonyhcole (talk · contribs · email) 10:05, 21 November 2017 (UTC)


Threaded Discussion[edit]

  • "Wikinews is inactive"? If someone wanted to delete all the sister project link, transwiki request, etc. templates (except for the Wiktionary, Commons, and Meta ones) for that reason, then they'd be laughed out of TFD. KMF (talk) 23:22, 18 November 2017 (UTC)
    Not surprisingly, this has absolutely nothing to do with those templates. It has to do with putting a more prominent link to Wikinews on the main page. --Majora (talk) 23:54, 18 November 2017 (UTC)

As I tried to show at the Ideas Lab, I would be in favour of such an idea. Vorbee (talk) 16:48, 19 November 2017 (UTC)

Appeal by Δ (BetaCommand)[edit]

The community is invited to comment on the appeal lodged by Δ at Arbitration Requests for Clarification and Amendment.

For the arbitration committee - GoldenRing (talk) 11:13, 18 November 2017 (UTC)

Allow prominent linking to expert- or peer-reviewed articles[edit]

We have a few Wikipedia articles that have passed peer- or expert-review. I think it would be a service to the reader to put a prominent self-explanatory button at the top of such articles, linking readers to the reviewed version. Also, I’d like to see a similar button (prominent, self-explanatory) linking the reader to a simple diff that clearly shows the reader how the article/topic has evolved since the review.

Review quality is everything here. Most of us would link the reader to a version that had been reviewed by the leading academic journal in the field. We’d probably all decline a review managed by big pharma. I’m inclined to hold the bar very, very high: only link to versions where the review was managed by an entity with a reputation for independent and rigorous review in the relevant field.

Thoughts? —Anthonyhcole (talk · contribs · email) 12:12, 19 November 2017 (UTC)

I could accept putting it in the "article milestones" section at the top of the article talkpage (in the same way that we link the versions that have passed/failed Wikipedia's internal review processes—see Talk:May Revolution for what's probably the canonical example of an article that's been through multiple review processes). I'd be opposed to making the link to the reviewed version prominent on the article itself. "Consensus can change" applies to reality just as much as it applies to Wikipedia, and if there were new developments subsequent to the reviewed version, we'd effectively be intentionally directing readers to an outdated article. To take an extreme example, if we treated the version of Barack Obama that passed FAC as the flagged revision, we'd be telling our readers that this was the version of his biography they should trust. (Besides, who decides what constitutes an "expert" for these purposes? For topics like civil engineering there's not much controversy and there are recognized and undisputed experts, but when you get into something like economics or politics you'd be lucky to find two experts who agree on anything, and when you start heading into fringier or more controversial stuff the experts are pretty much the last people who should be judging due weight. Would you want the leading experts in homeopathy deciding what the appropriate tone of [[Homeopathy]] should be? Are the Vatican or Richard Dawkins really the best-qualified people to assess Religion?) ‑ Iridescent 18:20, 19 November 2017 (UTC)
Regarding your Barack Obama example, I don’t think that’s the kind of topic that would fit this model. But to your point that reliable sources go stale: of course. I hope that an expert-reviewed article would be reviewed periodically, to keep the expert-reviewed version up to date. Meanwhile, I’m proposing two prominent links at the top of the article: one to the reviewed version and one to a simple diff, so the reader can see the difference between the reviewed and current versions. It would be clear to the reader that the linked, reviewed version was superceded by the current version
Entities with decades (or centuries, in some instances) of experience and an established reputation for quality review should decide what constitutes an expert for these purposes. I suggested above that we only endorse reviews performed by independent bodies with an existing good reputation for this kind of work. I have in mind, particularly, the editorial boards of highly esteemed journals that cover the topic. We would no more accept a review of Homeopathy managed by Multidisciplinary Respiratory Medicine (see [1]) than we would use an article peer-reviewed by them as a source. I, personally, wouldn’t accept anything less prestigious than JAMA, NEJM, Lancet, BMJ or the like for general medical topics, Movement Disorders or similar for movement disorders, Pain, Journal of Pain or similar for that, etc. I, personally, don’t think we should settle for anything but the editorial boards of the most highly-regarded journals in each relevant topic. Yes, there will be many topics - entire fields actually - where the scholarship is too flakey or nonexistant for this to work. So, we don’t do this on those topics.
The point of this exercise is to make one version of the Wikipedia article a WP:RS, something that can be cited in journal articles, school projects and even other Wikipedia articles. The point is for the reviewed version of a Wikipedia article to be the most trustworthy encyclopedia-style treatment of a topic, period.
Take a look at Parkinsons disease. BMJ selected a panel of reviewers to pick it apart. The panel included the person most responsible for the current worldwide standard diagnostic criteria for PD and another who is not only the most-published author of peer-reviewed articles on PD but also one of the main drafters of the proposed new diagnostic criteria. I wouldn’t, personally, want us to endorse anything less than that calibre of review, but when we do have such a version, I think we owe it to the reader to point them to it and show them how the current version differs.
Look at Dengue fever. This version passed peer review by a now-defunct open access Canadian journal. This is a simple diff showing how the article/topic has evolved since the review. For the record, I wouldn’t endorse linking our readers to that reviewed version. The journal doing the review isn’t nearly reliable enough. —Anthonyhcole (talk · contribs · email) 23:03, 19 November 2017 (UTC)
I think you've answered your own question then. (I.e. no). Wikipedia's reviewing power is spread out too thin as it is. Best practice is to reinforce the GA or FA process. Cas Liber (talk · contribs) 23:36, 19 November 2017 (UTC)
I’m talking about a process after an article has reached FA. Next time you bring a medical article to FA, I’ll arrange for the most highly-regarded relevant journal to review it for you, if you like/dare. 😏 —Anthonyhcole (talk · contribs · email) 23:50, 19 November 2017 (UTC)
There is nothing to stop anyone reviewing a Wikipedia article if they choose to do so, so go right ahead, It would be interesting to see how well it would be received. Particularly since FA is very much a group effort where any interested party can contribute. · · · Peter (Southwood) (talk): 06:07, 20 November 2017 (UTC)
Yes to all of that, Peter. —Anthonyhcole (talk · contribs · email) 18:09, 20 November 2017 (UTC)
It also occurs to me that outside of a few fields like medicine, there's nowhere near as much of a culture of peer review, and it's not going to necessarily be obvious what constitutes "expert review". I can cite that Russell Potter (who literally wrote the book on the Franklin Expedition) described my Halkett boat article as "far more detailed and better illustrated than anything I have seen in printed sources"—which in this admittedly niche field is literally the best endorsement possible—but there's no way I'd consider it a formal review. I'd worry that (as you allude to yourself above) by effectively creating a quality rating that can only ever be applied to articles on certain topics, in terms of public perception we're effectively saying "everything else is unreliable". (Readers can't be expected to understand Wikipedia's arcane internal rules; if they regularly see "quality assured" markers on medical articles but never see them on articles about music, the conclusion they'll quite reasonably draw is "Wikipedia's musical articles are consistently poorer quality than its medical articles".) ‑ Iridescent 19:06, 20 November 2017 (UTC)
Wikipedia is an unreliable source. FA and GA stars don’t confer an assurance of accuracy. Parkinsons disease was a featured article when it went to the BMJ and it was riddled with inaccuracies - some quite serious. Yes, if we point out to the reader that a version of a Wikipedia article is reliable, it may remind them that the rest of Wikipedia is not. I don’t, myself, see that as a sound reason to block this proposal.
It may be possible to devise a trustworthy expert-review process for topics like obscure history and some aspects of music, too. It won’t look exactly like this model (just appropriating the existing journal review process) but it may be doable. I’d like to start with this fairly simple medicine option and then see how other academic domains respond. I hope you’ll reconsider your opposition. —Anthonyhcole (talk · contribs · email) 01:59, 21 November 2017 (UTC)
Thank you for this conversation. I appreciate you hearing me and your very thoughtful responses. Can I ask you to allow this for articles reviewed under the terms I've outlined above - where the review is managed by a publisher with a good reputation to defend and conducted by the topic's leading researchers and thinkers, whose reputations, too, will be on the line? I realise a lot of thought needs to go into how/if this can work for topics outside medicine. But this model will work for medicine. This model will offer the reader an option they don't presently enjoy: a Wikipedia article they can trust. --Anthonyhcole (talk · contribs · email) 10:45, 21 November 2017 (UTC)
The WikiJournal of Science, in the process of being set up, and the already up-and-running WikiJournal of Medicine provide something like that - a peer-reviewed, journal-published version of a good article that is then available as a pdf permalink. No preferential linking is planned at this point though, as far as I know. --Elmidae (talk · contribs) 09:04, 20 November 2017 (UTC)
I'm aware of the Wiki Journal of Medicine. I wish them success but would not support linking to their endorsed versions from mainspace until we get a better measure of the quality of their reviewing. --Anthonyhcole (talk · contribs · email) 11:31, 20 November 2017 (UTC)
  • Putting some type of indicator that an article has been peer-reviewed or expert-reviewed provides a good idea, providing that the article really has been peer- or expert-reviewed. One thing we would need to be careful about is protecting such indicators from vandalism. Vorbee (talk) 16:40, 20 November 2017 (UTC)