Wikipedia:Village pump (proposals): Difference between revisions

Browse history interactively

← Previous edit Next edit →

Content deleted Content added

VisualWikitext

Inline

Revision as of 20:20, 30 November 2017

Table of contents
First discussion
End of page
New post

Shortcuts

New ideas and proposals are discussed here. Before submitting:

Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
Consider developing your proposal at Village pump (idea lab).
Proposed software changes should be filed at Phabricator (configuration changes should have gained a consensus).
Proposed policy changes belong at Village pump (policy).
Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
Proposed new wikis belong at meta:Proposals for new projects.
Proposed new articles belong at Wikipedia:Requested articles.

« Archives, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

Auto skip inactive editors from newsletters

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. Ϣere SpielChequers 19:15, 27 October 2017 (UTC)[reply]

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. Ϣere SpielChequers 10:48, 29 October 2017 (UTC)[reply]

Survey (Auto skip inactive editors from newsletters)

Support As proposer. Ϣere SpielChequers 19:15, 27 October 2017 (UTC)[reply]
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. —swpb^{T go beyond} 19:33, 27 October 2017 (UTC)[reply]
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. E Eng 21:56, 27 October 2017 (UTC)[reply]
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)[reply]
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. E Eng 13:13, 29 October 2017 (UTC)[reply]
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)[reply]
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)[reply]
Support. Newsletters piling up on inactive talk pages is a nuisance. Alsee (talk) 23:41, 27 October 2017 (UTC)[reply]
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)[reply]

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. E Eng 14:23, 28 October 2017 (UTC)[reply]

Support as per previous comments, especially the desirability of avoiding long cluttered talk pages. Peter coxhead (talk) 19:47, 28 October 2017 (UTC)[reply]
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)[reply]
Support with a time threshold and an optout. jcc (tea and biscuits) 11:33, 29 October 2017 (UTC)[reply]
Support I suppose, but I would much prefer 12 months. Jenks24 (talk) 12:09, 29 October 2017 (UTC)[reply]
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)[reply]

Forsooth, my liege, thou canst opt-out, thus to continue the succor of thy monthly Signpost! E Eng 07:16, 30 October 2017 (UTC)[reply]

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)[reply]

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). Tigraan^{Click here to contact me} 08:44, 30 October 2017 (UTC)[reply]
Support 1 year. Longer may be necessary, but I think 1 year is a good start. JTP ^{(talk • contribs)} 01:57, 31 October 2017 (UTC)[reply]
Oppose In the case of some newsletters, it can spur people into activity. --Rs chen 7754 04:01, 31 October 2017 (UTC)[reply]
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)[reply]
Support Swarm ♠ 20:32, 2 November 2017 (UTC)[reply]
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)[reply]
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)[reply]
Support a year. If they're not logging on, it's just piling up. White Arabian Filly ^Neigh 16:29, 8 November 2017 (UTC)[reply]
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. Van Isaac_WS^cont 17:35, 10 November 2017 (UTC)[reply]
Support a year - Long overdue!, If those inactive still want to read for instance the Signpost then they can bookmark that page .... –Davey2010^Talk 00:07, 11 November 2017 (UTC)[reply]
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)[reply]
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, Lindsay^Hello 10:31, 19 November 2017 (UTC)[reply]
Support anything from 4 months and 12+ months. 6 months seems very reasonable and useful if you have to pick a number. Dennis Brown - 2¢ 17:25, 20 November 2017 (UTC)[reply]

Threaded discussion (Auto skip inactive editors from newsletters)

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. 86.17.222.157 (talk) 20:19, 27 October 2017 (UTC)[reply]

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. Ϣere SpielChequers 21:30, 27 October 2017 (UTC)[reply]

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. E Eng 21:56, 27 October 2017 (UTC)[reply]

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. 86.17.222.157 (talk) 18:40, 28 October 2017 (UTC)[reply]

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)[reply]

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. 86.17.222.157 (talk) 21:24, 28 October 2017 (UTC)[reply]

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)[reply]
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)[reply]
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. Ϣere SpielChequers 10:45, 29 October 2017 (UTC)[reply]
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)[reply]

@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)[reply]
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)[reply]
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. Ϣere SpielChequers 07:10, 30 October 2017 (UTC)[reply]

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. ClubOranje^T 19:39, 30 October 2017 (UTC)[reply]

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)[reply]

Should talk page newsletter notices be abolished completely?

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)[reply]
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)[reply]
Is that what happens to my New York Times some mornings? E Eng 19:36, 30 October 2017 (UTC)[reply]

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)[reply]
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. E Eng 19:39, 30 October 2017 (UTC)[reply]

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)[reply]

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?). E Eng 23:07, 30 October 2017 (UTC)[reply]

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)[reply]

Um, OK, well it seems unnecessarily complicate, but anyway why isn't it being used already? E Eng 23:17, 30 October 2017 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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. E Eng 00:28, 31 October 2017 (UTC)[reply]

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)[reply]

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. E Eng 02:37, 31 October 2017 (UTC)[reply]

@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)[reply]

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? E Eng 04:08, 31 October 2017 (UTC)[reply]

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)[reply]

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. E Eng 04:37, 31 October 2017 (UTC)[reply]

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)[reply]

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)[reply]

Um, an unsubst'ed template is exactly what I'm proposing. E Eng 04:08, 31 October 2017 (UTC)[reply]

Where? --SmokeyJoe (talk) 04:57, 31 October 2017 (UTC)[reply]

A dozen posts up, starting with "Hmmmmm..." E Eng 05:21, 31 October 2017 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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 MediaWiki.org 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)[reply]

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)[reply]

Newspaper deliverers to remove old newspapers still on the driveway

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)[reply]
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)[reply]
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)[reply]
Some users might want to keep all newsletters for archive purposes, though, and might not want old editions to be removed. -Indy beetle (talk) 13:42, 27 November 2017 (UTC)[reply]
In that case, would a link to the stored source would suffice? Iggynelix (talk) 21:31, 28 November 2017 (UTC)[reply]

Show the metadata gadget to all readers

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

There is a near unanimous consensus to oppose the proposal. The arbitrarily lettered grading scale of the project and the acute subjectiveness of the entire process outweighs it's benefits (if any) massively. Winged Blades^Godric 16:43, 28 November 2017 (UTC)[reply]

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 is}not^dave (talk/contribs) 12:22, 10 November 2017 (UTC)[reply]

Survey (Show the metadata gadget to all readers)

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)[reply]
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)[reply]
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)[reply]
Oppose - I see no value in this proposal. Beyond My Ken (talk) 18:05, 11 November 2017 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
I have no idea what this is and neither will 99% of readers TonyBallioni (talk) 23:23, 14 November 2017 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
Oppose. Ugh. f e minist 15:02, 18 November 2017 (UTC)[reply]
Support Most articles are utter junk and the reader should know that. Chris Troutman (talk) 21:01, 18 November 2017 (UTC)[reply]
Oppose As per Mz7. This would be a lot of overhead for what is very little objective information. Dennis Brown - 2¢ 17:24, 20 November 2017 (UTC)[reply]
Oppose - This would only confuse our readers and that isn't something we want to do.... –Davey2010^Talk 21:01, 20 November 2017 (UTC)[reply]
Oppose - Newby opinion: for all other information sources, consumers decide for themselves how reliable, complete, neutral etc. the information (and provider) needs to be and actually is. To varying degrees they have confidence in the editorial policy and processes of information sources. I think we have to trust the intelligence of information consumers to discern good quality from poor quality as they do elsewhere. If articles fall below 'acceptable editorial standards' we should withdraw them from publication until such time as they do. Mikemorrell49 (talk) 15:30, 22 November 2017 (UTC)[reply]
Oppose - Aesthetically ugly, clutter, and article assessment ratings are frequently inaccurate. Neutrality^talk 21:40, 22 November 2017 (UTC)[reply]

Threaded discussion (Show the metadata gadget to all readers)

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 (talk • contribs) 13:07, 10 November 2017 (UTC)[reply]
And could this happen? ^{My name is}not^dave (talk/contribs) 13:16, 10 November 2017 (UTC)[reply]
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 (talk • contribs) 15:06, 10 November 2017 (UTC)[reply]
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 is}not^dave (talk/contribs) 15:45, 10 November 2017 (UTC)[reply]
Question: does this affect only desktop or mobile as well? Renata (talk) 16:31, 10 November 2017 (UTC)[reply]
@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 is}not^dave (talk/contribs) 18:42, 10 November 2017 (UTC)[reply]
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)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

RfC: Add a link to Wikinews on the Main Page

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

There is a snow consensus to oppose this proposal.And, there seems to be a near-unanimous consensus that Wikinews is effectively dead and sending our readers to such a project will be a dis-service. Winged Blades^Godric 16:49, 28 November 2017 (UTC)[reply]

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:

No one seems to know it exists (except the more active Wikipedians)

Not many non-editors go there

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)[reply]

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:

No one seems to know it exists (except the more active Wikipedians)
Not many non-editors go there
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)[reply]

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 (talk • contribs) 16:20, 8 November 2017 (UTC)[reply]

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 en.wiki 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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]

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)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Poll (Add a link to Wikinews on the Main Page)

Support (Add a link to Wikinews on the Main Page)

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

Oppose (Add a link to Wikinews on the Main Page)

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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 - 2¢ 17:22, 20 November 2017 (UTC)[reply]
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!. –Davey2010^Talk 20:55, 20 November 2017 (UTC)[reply]
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)[reply]
Oppose. Wikinews is dead and should be put out of its misery altogether. Neutrality^talk 04:41, 23 November 2017 (UTC)[reply]
Directing our readers to Wikinews would be doing them a disservice. It is a dead project walking and cannot make any credible claim of being able to keep whatever readers there may be informed. The Wicked Twisted Road (talk) 18:20, 23 November 2017 (UTC)[reply]
Jesus tapdancing christ no. FACE WITH TEARS OF JOY ^[u+1F602] 04:01, 28 November 2017 (UTC)[reply]

Neutral (Add a link to Wikinews on the Main Page)

Threaded Discussion (Add a link to Wikinews on the Main Page)

"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)[reply]
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)[reply]

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)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal to enhance the "Search Wikipedia" box

Hi, Everybody. I want to make a proposal at Phabricator to slightly enhance the Search Wikipedia box that is at the top of every Wikipedia page. Before doing so, I need a consensus here, at the Village Pump. Please alert other interested parties to this proposal, but without canvassing or tooling the outcome

I use the search box constantly, but most times it would improve my workflow to have the search box open in a new tab, window, or popup (I do not care about that detail - any one will do). Most times I want to leave my active window intact, so having a new tab, etc. would allow that. This would also ensure that there is no loss of data during an edit session.

If my explanation is not clear or complete, please comment below. An alternative would be to have a radio button or such to give the option to opt-in/opt-out of having it open in a new tab or window.

I have searched the list of persistent proposals, and the FAQs, and I do not see a previous proposal for this. If there is one, please direct me to it. Having fun! Cheers! {{u|Checkingfax}} {Talk} 23:13, 21 November 2017 (UTC)[reply]

(note: !votes are not a traditonal vote. They are a discussion and poll to reach consensus. To that end, please give a rationale, policy, guideline, or citation to back up your !vote. An !vote without backup will be ignored)

Option #1: Open Search Wikipedia request in a new tab, window, or popup box

(please !vote Support, Oppose, or Neutral, along with your rationale)

Discussion for option #1

Option #2: Open Search Wikipedia request in a new tab, window, or popup box, but with a radio button or such

(please !vote Support, Oppose, or Neutral, along with your rationale)

Support – as nominator. {{u|Checkingfax}} {Talk} 23:13, 21 November 2017 (UTC)[reply]
Support. I don't think it's a good idea to have it automatically open a new tab, as sometimes I just want to leave a page. I could see the use case for such a button, however. ProgrammingGeek^talktome 23:21, 21 November 2017 (UTC)[reply]

Discussion for option #2

Option #3: Put option in User preferences to enable open in new tab/window

(please !vote Support, Oppose, or Neutral, along with your rationale)

Discussion for option #3

Option #4: Oppose all options

(please !vote Oppose, along with your rationale)

Oppose - AFAIK, all popular browsers provide an easy way to open a new tab. For me, it requires two mouse clicks and no keyboard input to open a new tab and show my watchlist, which, like all WP pages, contains a search box. The proposed enhancement would save me one or two clicks, assuming I actually want a separate tab. The downside is that it increases complexity, which is a detriment for less-tech-savvy users. Tab/window management should be at user's discretion and under their control. Any kind of new element such as a button increases visual clutter on the page, another form of complexity. Emphasis should not be on minor time-savers for power users, who are already quite productive. On balance and all things considered, cost exceeds benefit. ―Mandruss ☎ 05:56, 22 November 2017 (UTC) ADD: Also oppose new option #3 per my comments in the General discussion section below. ―Mandruss ☎ 12:07, 25 November 2017 (UTC)[reply]
Oppose - What @Mandruss said. It's very easy to change a regular link into one which opens a new tab, just by holding the CTRL key when you click (at least when using a Chrome browser on Windows, YMMV). We don't need to add more stuff to the UI. Chuntuk (talk) 07:48, 22 November 2017 (UTC)[reply]
Oppose - This would just add to the already heavy UI, and it would just confuse new users and be of no help to regular users, who have likely already figured out how to open a new tab from a link. RileyBugz^会話_投稿記録 12:10, 28 November 2017 (UTC)[reply]
Oppose – per Izno and Deskana (WMF) in the discussion section below. Violates Technique G200 of the W3C Web Content Accessibility Guide 2.0. Mz7 (talk) 17:36, 29 November 2017 (UTC)[reply]

Discussion for option #4

General discussion

This is bad web accessibility. --Izno (talk) 23:31, 21 November 2017 (UTC)[reply]
Indeed; also some browsers, like Opera 36, do not switch to the new tab, so you may think that the link hasn't been followed. --Redrose64 🌹 (talk) 23:51, 21 November 2017 (UTC)[reply]
How do those browsers react to a popup box instead of a browser window or tab? Having fun! Cheers! {{u|Checkingfax}} {Talk} 01:07, 22 November 2017 (UTC)[reply]

Hi, Izno. Your link actually provides many cogent reasons why a new tab, window, or popup would be ideal. Thank you for that link. One of the times I want a new tab, etc. is when I am in an edit session. Another is when I want to copy/paste off the new window. Plus, a few more scenarios. Awesome! Having fun! Cheers! {{u|Checkingfax}} {Talk} 01:37, 22 November 2017 (UTC)[reply]
@Checkingfax: Two points. First, the term is "!vote" (pronounced "not-vote") not "iVote"; more at WP:!VOTE. Second, having three identically-named yet different "Discussion" headings is not good, so please can we have unique headings? --Redrose64 🌹 (talk) 23:47, 21 November 2017 (UTC)[reply]
Hi, Redrose64. You are a wise sage. Will do. My bad. If I botch it, feel free to edit it. Having fun! Cheers! {{u|Checkingfax}} {Talk} 00:56, 22 November 2017 (UTC)[reply]
As noted above, I oppose the two options you've given us. I'll suggest a third which I'm neutral on: allow users to specify in their Preferences whether search results should open in a new tab/window or not. I don't personally think this would be worth the trouble of doing, but if someone has the time and ability to do it I don't mind. Chuntuk (talk) 07:48, 22 November 2017 (UTC)[reply]
I like having a preference as well; maybe we could even write a gadget or something to make it less of a mediawiki dev issue. Enterprisey (talk!) 11:25, 22 November 2017 (UTC)[reply]
Hi, Enterprisey. I have added an option above to make it a preference rather than a radio button for opt-in/opt-out. Can you please support or oppose that? Also, feel free to reword the proposal to align it with your thoughts. Thank you. Having fun! Cheers! {{u|Checkingfax}} {Talk} 10:38, 25 November 2017 (UTC)[reply]

I'd like to see a significant degree of interest in that. We shouldn't be adding options on the desire of a few editors for a minor new "nice-to-have" feature. We probably have too much of that in Preferences already. It would be really interesting to see counts of active editors who have changed each option from its initial value. That would be something worth doing. ―Mandruss ☎ 12:12, 22 November 2017 (UTC)[reply]
Something similar was done several years ago when there was a concerted effort to remove some preferences. Maybe it would be a good idea to take a second look. --Izno (talk) 15:47, 22 November 2017 (UTC)[reply]
This proposal would cause the search box to violate Technique G200 of the W3C Web Content Accessibility Guide 2.0. Making Wikipedia less accessible is not a good idea. --Dan Garry, Wikimedia Foundation (talk) 13:02, 22 November 2017 (UTC)[reply]

Hi, Dan Garry. I believe you are misinterpreting G200. If using a search box would cause one to lose session, then G200 states that a new tab or window would be appropriate. Izno already mentioned this angle, and I thought I already pointed out the logic error.

2. "The user is logged into a secured area of a site, and following a link to a page outside of the secured area would terminate the user's logon. In this case opening external links in an external window allows the user to access such references while keeping their login active in the original window."

Requesting a search, while in an editing session, does result in a loss of session data. This is bad UX. LOL. Having fun! Cheers! {{u|Checkingfax}} {Talk} 23:33, 22 November 2017 (UTC)[reply]

No, it is you who is misinterpreting G200, which deliberately recommends avoidance of opening links in new tabs/windows unless necessary. Performing a search on Wikipedia is decidedly not following a link to "a page outside of the secured area", nor does it terminate one's login session. While there are indeed times when opening a search in a new tab or window would be preferred, in the vast majority of times, it actually isn't necessary. Think about searching from the Main Page. Why would I need to keep the Main Page open as a tab if I'm searching for something else? I suspect this change would cause more annoyance to readers than benefit, and Izno and Dan Garry are both spot on when they point out that this would reduce web accessibility. Mz7 (talk) 17:34, 29 November 2017 (UTC)[reply]

I just love Safari sometimes. Command-enter or command-click and done :) —TheDJ (talk • contribs) 17:02, 22 November 2017 (UTC)[reply]

Hi, TheDJ. You have found a way to do that from within Search Wikipedia box? Having fun! Cheers! {{u|Checkingfax}} {Talk} 23:35, 22 November 2017 (UTC)[reply]

~~Isn't this standard on most browsers?~~ Type something in the search box and hold Ctrl if you're on Windows or Command if you're on Mac, then click enter. Update: Works on Safari for sure. Google Chrome it looks like you might need to hold Shift. Mz7 (talk) 17:40, 29 November 2017 (UTC), 17:41, 29 November 2017 (UTC)[reply]

Limit the size of biographical infoboxes and use succession boxes for multiple offices

At present many Wikipedia biographical articles have an infobox in the top right corner and a set of succession boxes near the foot of the article. In some cases, often for politicians, so many different offices are listed in the infobox that it becomes more of an info-column, stretching way down into the article. See Winston Churchill and Tony Blair for examples of this. This is not a neat way of summarizing information which is what the infobox is presumably supposed to do. The same information about offices held is then duplicated in the succession boxes at the foot of the article - in a more easily read format though. I suggest that the infobox for biographies should ordinarily be limited to the one appointment for which the subject is best known. In unusual cases where a person is known roughly equally for two different roles then these might both be listed in the infobox. In extreme cases we might run to three appointments but no more. Greenshed (talk) 00:02, 23 November 2017 (UTC)[reply]

I addressed this exact problem in a past Signpost article here and got an infobox that extended for a couple of miles into the planet's core. Best Regards, Barbara (WVS) ✐ ✉ 01:44, 23 November 2017 (UTC)[reply]

Thanks - I shall take a good look at your Signpost article. However, what I really want is to establish a WP guideline (or similar) that I can refer to when pruning infoboxes (of which I also am generally a fan). Greenshed (talk) 01:52, 23 November 2017 (UTC)[reply]

I'd have to say I'm opposed to making this policy or a guideline. If inflated infoboxes are a problem, I'd rather that be addressed with consensus on a case by case basis, considering sometimes its important to show that a person held multiple important infoboxes upfront (like Robert F. Kennedy, who served as US Attorney General and a US Senator, or Moise Tshombe, who served as President of the secessionist State of Katanga before becoming Prime Minister of the Congo [even if his infobox doesn't immediately reflect that, I think it probably should]). Heck, even the Churchill article you mentioned actually has most of the offices he served in collpased by default, which is actually a rather nifty way of handling things. Also it should be noted that infoboxes are not required to be present on office-holders' articles. -Indy beetle (talk) 21:13, 24 November 2017 (UTC)[reply]

Thanks for your comments. First off two subsidiary points. 1. I am not against listing two important offices - e.g. for Robert F. Kennedy, US Attorney General and being a US senator. 2. A guideline would still allow for the development of consensus in unusual cases. Anyway my main point is that while I grant that collapsed multiple offices in infoboxes are better than not, this still duplicates what is in the succession box. I suggest that I would be better to have a link in the infobox titled something like "more offices" which links to the succession boxes rather than expand out a huge column. It is much easier to follow at a glance what someone did year by year in the succession boxes than scroll and scroll down through a long and thin column. This sort of information is analogous to an annex to the main article and is better placed near the end. In any case, would you agree that, by default, the infobox should not extend below the lead and the contents table? Greenshed (talk) 20:19, 25 November 2017 (UTC)[reply]

I can appreciate the spirit of such a default but I could not accept the implementation of the letter of it (even "Guidelines" hold a lot of weight around here and you can bet somebody will do just that). An FA-class article I've written, Marcel Lihau, would already violate such a principle. It also makes the infobox contingent off of the size of the lede of an article and the size of the ToC, which is unfair as these parameters are bound to vary article to article (I also note that this may change depending on the size of the screen a page is viewed on). I mentioned the Lihau article because its an abnormally small FA bio with a slim lede that could be affected by such a change. I'm still putting my weight behind the collapsed method. I'd also like to point out to those below me that predecessor and successor parameters are often useful navigation tools for our users, who might not wish to scroll all the way to the bottom of an article to see whether or not succession boxes are present. In my experience, infoboxes are much more prevalent than succession boxes. -Indy beetle (talk) 05:50, 27 November 2017 (UTC)[reply]

You've clearly done some good work on the Marcel Lihau article and I do not wish to decry that. Personally, I would move "Secretary of State for Justice of the Republic of the Congo" and "Commissioner-General of Justice of the Republic of the Congo" sections in the infobox into a comprehensive set of succession boxes at the foot of the article, delete the fact that his successor as First President of the Supreme Court of Justice was Bayona Bameya from the infobox and move the fact of his resting place (Gombe, Kinshasa) from the infobox into the main body of the article. I would do all this to ensure that the lead and especially the infobox only convey the key facts. (see Choess's comments below to the effect that immediate predecessor and successor aren't [usually] very germane). The consequence of this would be to probably get the infobox down to a size whereby it did not extend below contents table on most standard screen resolutions. More generally, it's not the Marcel Lihau type of articles that I have in mind and going a bit below the contents table would perhaps be ok (although maybe not ideal). For years we have had quite a few GA+ biographies with infoboxes stretching down towards the core of the earth (to borrow an expression). Having this debate over and over again on every article's talk page would really be too much for me to take this problem on. Greenshed (talk) 01:05, 28 November 2017 (UTC)[reply]

To prove the point, I tried thinning out the infobox on Auxillia Mnangagwa. This was reverted (in good faith) pretty quickly (https://en.wikipedia.org/w/index.php?title=Auxillia_Mnangagwa&oldid=prev&diff=812716383). If editors think that there is a problem with over-sized infoboxes then something like a guideline will be needed.Greenshed (talk) 01:13, 30 November 2017 (UTC)[reply]

Tentatively support, at least in principle. This is a well-known failure mode for infoboxes; editors abdicate their responsibility to select the most important facts and simply fill in every parameter. It should be possible to endorse exceptions by local consensus, but if you're trying to jam in more than one or two "infobox officeholder" templates, you're probably doing it wrong. Also, there's a difference between saying someone held a particular office and giving the full information available in succession boxes (office, dates, predecessor, and successor); in the case of RFK, for instance, while it's noteworthy that he held the office of US Attorney General, his immediate predecessor and successor aren't very germane to summarizing his career. That said, has their been resistance to trimming these overlong infoboxes? I'd rather not write a formal rule about it unless it's necessary. Choess (talk) 14:06, 26 November 2017 (UTC)[reply]

Infoboxes are intended to provide a bullet point summary, and should be succinct. Succession boxes provide a means to follow through successive holders of the same office. Here I am thinking of some UK politicians who have had a much longer list of appointments. Peterkingiron (talk) 16:17, 26 November 2017 (UTC)[reply]

2 Solutions for Tor ban

Some users can only trust a de-centerised proxy like Tor when for example want to disclose a economic law to public don't aware of it in a country. I propose that Wikipedia ask for bitcoin from open proxy editors so allow them to edit or shows their edits of articles on different tab. — Preceding unsigned comment added by M-G (talk • contribs) 03:26, 23 November 2017 (UTC)[reply]

Wikipedia doesn't ask for money so that people can edit. Tor is blocked because it is easily abused by vandals. As I understand it, a user could still create an account and then apply for IP block exemption. — Insertcleverphrasehere ^{(or here)} 07:00, 23 November 2017 (UTC)[reply]

@Insertcleverphrasehere: Tor users cannot create accounts, and the error message – the standard "Your IP address is in a range which has been blocked on all wikis" (not specific to account creation) – doesn't make it clear that they can ask someone to create an account for them. Jc86035 (talk) 12:33, 25 November 2017 (UTC)[reply]

Ok... but presuming that they could briefly have access to a non-Tor IP, they could quickly create an account, and request IP block exemption. — Insertcleverphrasehere ^{(or here)} 19:40, 25 November 2017 (UTC)[reply]

@Insertcleverphrasehere: If they're using Tor and need IP block exemption they might not have access through a non-Tor IP anyway. The bitcoin thing is not particularly helpful because not everyone uses it, but it would be helpful to change the block message. I've asked on Wikipedia:Village pump (technical)#Account creation for Tor users. Jc86035 (talk) 05:13, 26 November 2017 (UTC)[reply]

$200 worth of books to win

Just to announce that for the last five days of Wikipedia:WikiProject Women in Red/The World Contest we're offering a bonus prize of $200 worth of books of the person's choice for whoever creates the most new (satisfactory) women biographies by the end of the month, minimum 1kb of readable prose and no sourcing issues. If you need a bunch of books to help you with editing I propose that people join in! ;-)♦ Dr. Blofeld 22:09, 25 November 2017 (UTC)[reply]

Renaming "Hyperloop Makers UPV" to "Hyperloop UPV"

Could you plase rename it like "Hyperloop UPV", please? I'm new here and I don't know if this matter should be even here.

Thanks--Manesmo1 (talk) 19:11, 27 November 2017 (UTC)[reply]

Manesmo1

Done - Next time consider asking at The Teahouse, our dedicated forum for new editors to seek help and feedback. GMG ^talk 19:15, 27 November 2017 (UTC)[reply]

Convert all old full creation protected articles to ECP creation protection

Withdrawn. ~ Rob₁₃^Talk 15:15, 28 November 2017 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Historically, we’ve used full protection as the usual form of creation protection because it was the lowest form of protection that tended to work in that scenario. Since the introduction of extended confirmed protection, creation protecting at this level has become more popular (endorsed for this usage near unanimously at WP:ECPP2). Editors with 30 days and 500 edits on the project can generally be trusted not to recreate an article with serious issues. It’s good to lower protection where possible, so I propose we switch all articles which were fully creation protected before ECP existed to ECP creation protection. This does not prevent admins from using full creation protection if appropriate going forward, just lowers protection where ECP was previously not an option. Thoughts? ~ Rob₁₃^Talk 19:48, 27 November 2017 (UTC)[reply]

@BU Rob13: Do you have a list of articles saved anywhere? Or are you talking about all of the articles found here? Nihlus 20:11, 27 November 2017 (UTC)[reply]

The articles included would by everything on the list you link to minus everything protected after ECP was introduced. I don’t have a list saved anywhere, but one could easily be generated (pinging Oshwah). If preferred, the list could be up for a certain period of review where any admin can remove an entry to keep it fully protected. ~ Rob₁₃^Talk 20:14, 27 November 2017 (UTC)[reply]

BU Rob13 - Here you go. ~Oshwah~^{(talk) (contribs)} 20:45, 27 November 2017 (UTC)[reply]

How often do editors have to contact an admin to unprotect a salted page? Looking at that list, it seems most of those articles would never need to be created. Natureium (talk) 20:25, 27 November 2017 (UTC)[reply]

Strong Oppose I have mixed views on this because I hate when people come to DRV asking for permission to move something into mainspace, because I think it is used as a way to "G4-proof" an article. This would get rid of that excuse. At the same time, salted articles like Steak and Blowjob Day, sometimes get picked up by good faith editors, and there should be a firm consensus to unsalt before we allow them back in mainspace. Full protection is the only way to ensure that. I also don't see the advantage of a manual review of each of the these articles, which per Steak and Blowjob Day would be needed. Most of these articles shouldn't be created and doing a manual review of them for the principle of lowering protection on an article no one actually wants seems like a waste of volunteer resources. TonyBallioni (talk) 20:30, 27 November 2017 (UTC)[reply]
- Updating this to Strong Oppose after Oshwah told me off-wiki the number of full-protected salted pages linked above is 4742. Lowering all of those without review is a horrible idea and manually doing it would be a bigger time suck than I had guessed. TonyBallioni (talk) 20:54, 27 November 2017 (UTC)[reply]
  I don't think there was any statement in the proposal that specifically says "will do it automatically" or "without review". Nor do I think that you should oppose the other option for the length of time it would take. We should rarely be indefinitely create-protecting anything, and as the AN discussion is evidencing, several admins have mis-fired on the trigger for blocks--I expect a similar reaction to the protected ones as well. (No comment on the original comment.) --Izno (talk) 22:55, 27 November 2017 (UTC)[reply]
Oppose because this is a solution in search of a problem. WP:RFPP rarely has a backlog of more than a day or two, and users who wish to remove protection just have to ask. --Jayron 32 15:03, 28 November 2017 (UTC)[reply]
Oppose - Protection can be easily lifted when necessary as all a user needs to do is bring it to the attention of the protecting administrator (or eventually bring it to RFPP). This seems like a lot of work for a very limited benefit. Nihlus 15:09, 28 November 2017 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I would have opposed the proposal, basically per what TonyBallioni said. But I'm glad to see there was a discussion, I've been wondering if we have ever discussed criteria by which we determine if an article should be full-create-protected versus ECP-create-protected. I always set create protection to sysop because I don't know when I'm supposed to use ECP. Ivanvector (^Talk/_Edits) 15:21, 28 November 2017 (UTC)[reply]
EC protection was created mainly to allow for the enforcement of ArbCom and community decisions on specific high-controversy topic areas which are likely to attract armies of meatpuppets with little interest in abiding by Wikipedia policies and community principles. It was never meant as a general type of protection to be assigned willy-nilly just because we don't want to "deal with" problems proactively. While the community has since expanded EC protection as a part of the general suite of tools we use to combat disruptions, it should still not be a tool of first resort when less drastic methods can be tried. It's one of those "according to demonstrated need" tools that we shouldn't apply just because we're too lazy to monitor problems. --Jayron 32 15:33, 28 November 2017 (UTC)[reply]
It seems to me that extended-confirmed creation protection is itself a less drastic method than the full creation protection that administrators typically applied prior to the introduction of extended-confirmed. Because of this, I've also shared Ivanvector's uncertainty at times whether to apply full creation protection or extended-confirmed creation protection. If we follow the principle of "less drastic first" to conclusion, it seems that we should be applying extended-confirmed protection as a first resort for salting articles, and then, if EC is ineffective, full protection. (Currently, as Ivanvector notes, most admins jump straight to full protection.) Mz7 (talk) 04:40, 29 November 2017 (UTC)[reply]

Avatars On Wikipedia

SNOW CLOSE

Clearly not happening. ♠PMC♠ (talk) 06:39, 29 November 2017 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

It would be nice if each user has the option to have his or her own avatar. I know Wikipedia isn't a social networking site, but Wikia does enable avatars. Who knows, it may also attract potential new users and increase the growth rate of Wikipedia.31.215.115.49 (talk) 16:42, 28 November 2017 (UTC)[reply]

Oppose Wikipedia is neither a social networking site nor Wikia. Also, avatars (unless of the simplest form, like the letter-in-a-coloured-disc as used by GMail) are images, and this would be against WP:SIGIMAGE. In any case, this has been discussed and rejected before. --Redrose64 🌹 (talk) 18:06, 28 November 2017 (UTC)[reply]
Oppose. What Wikia does is completely irrelevant; they're a site for the organisation of fan clubs, and we're an academic collaboration. Without wanting to sound too elitist, we want new editors who come because they want to contribute something useful, not the sort of people to whom "does it allow avatars" is a consideration. With 61,006,325 pages currently, "increasing the growth rate of Wikipedia" is the least of our worries. ‑ Iridescent 18:10, 28 November 2017 (UTC)[reply]
Oppose: It is completely counter-intuitive to our purpse and would make us look less professional and trustworthy to outsiders. --Deathawk (talk) 05:56, 29 November 2017 (UTC)[reply]
Oppose, but for a different reason. I feel that customizing your own signature is already a pretty good compromise for self-expression. Having jumping animated GIFs bouncing around as avatars, well, you can imagine how quickly that would devolve. Let alone the technical challenges of it. Where would the avatar appear? If it were Facebook style (at the beginning of a comment), I'm not even sure how that would be implemented in our current system. Drewmutt (^ᴥ^) talk 06:24, 29 November 2017 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

RFC on production section wording in the Film Manual of Style

I opened up an RFC on proposed changes to the Film:MOS regarding proposed guidelines for production sections. You can vote on it here, Thanks --Deathawk (talk) 06:05, 29 November 2017 (UTC)[reply]

Add always-present template at the top of every draft.

Please consider joining the feedback request service.

An editor has requested comments from other editors for this discussion. This page has been added to the following lists:

Wikipedia proposals
WikiProjects and collaborations

When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

I propose that we automatically display the following template at the top of every page in the draft space Template:Draft top Or something very similar, containing basic help, links to find sources, and a reminder to not copy-paste the page when it's ready for inclusion. This would guide newbies, and significantly cut down on WP:REPAIR requests, where roughly half of the requests are from the draft space. Headbomb {t · c · p · b} 17:31, 30 November 2017 (UTC)[reply]

Discussion (Draft Header Template)

There is a preexisting {{Draft article}} template that could be merged with the one you created for this purpose. Mz7 (talk) 19:26, 30 November 2017 (UTC)[reply]

Proposal for a better article assessment process

The wikipedia ratings for articles go (from highest to lowest): FA, Good, A, B, C. Start, and Stub. Seven ratings in all. I've created more than 120 articles which have been rated B, C, or Start -- and all of those 120 articles are of similar quality, covering in my opinion the subject as thoroughly as it need be covered in an encyclopedia and being comprehensible to the average reader. In other words the assessment of the articles I have written has been arbitrary depending more upon the reviewer than the quality of the work. Yeah, I know you can claim that the rating system is objective....but it isn't. Different people come to different conclusions about what they see and read.

Rather than expend the time of reviewers trying to decide whether an article is A, B, C, or Start, rather than undergoing the water-torture of trying to determine what is "Good" and what is "FA", the whole system should be imploded. I suggest there be only one rating for an article: "Good", a rating achieved only after a careful and continuing review of the article by experienced Wikipedians. All articles not judged as "Good" would be unrated. For inaccurate or misleading articles, the article could be tagged as they are at present as dubious or lacking references or whatever.

I would guess that 95 percent of wikipedia readers never go to the talk page to see how an article is rated, and thus the rating system is not very important. Why, therefore, complicate it with a plethora of ratings which nobody cares about -- except the article creator who is more likely to be insulted than complimented by the rating his beloved article receives (I speak from experience).

Moreover, I would propose that a "Good" article have a note to that effect at the top of the article -- and that the "Good" rating not be relegated to the talk page that nobody looks at. That would give credit and prominence to editors for their work and a "Good" rating would give confidence to the readers that what they are reading is accurate, neutral in tone, and complete.

Another reason for simplifying the rating system is that articles change in quality over time -- going from poor to good and from good to poor as different edits are added. Yet, articles are rarely reassessed -- or only after years. Thus, even if you are the rare reader who looks at the talk page to see how an article is rated, the rating is likely out of date.

Let's expend our efforts to try to increase the number of "Good" articles on wikipedia -- and keep them "Good", rather than worry about whether an article is an A or B or C or Start or Good or FA.

"Out of clutter find simplicity": Einstein. Smallchief (talk) 19:21, 30 November 2017 (UTC)[reply]

Wikipedia:WikiProject Council/Assessment FAQ. Article assessments aren't for readers, they're for helping Wikiprojects prioritize which articles are most in need of work. ("[T]hese ratings are meant primarily for the internal use of the project, and usually do not imply any official standing within Wikipedia as a whole.") "Good articles", however, do have their status shown at the top of the page, to the right of the title. --Yair rand (talk) 19:37, 30 November 2017 (UTC)[reply]

A minor point, but A-class is a higher rating that GA.

More significantly for your proposal, GA and FA ratings are already indicated on the main page of an article: you can see the little bronze star/green plus mark at the top right-hand corner of a Featured or Good article. (See Sappho or Emily Davison for examples of GA and FA respectively).

Start/B/C ratings are at best inconsistently applied, and I can see very little downside to scrapping them (in theory, they are useful for editors knowing which articles they are interested in are most in need of improvement; in practice they are inconsistently enough applied that they aren't actually that useful).

Any proposed system of ratings which scraps all of the current ratings and sets up a new standard for what is a "Good article", though, must propose a set of criteria for it to be judged by. Are we going to keep the current GA system? Because while not as fundamentally broken as the start/C/B rankings, that has its own problems. Caeciliusinhorto (talk) 19:50, 30 November 2017 (UTC)[reply]

Well, thanks for telling me. I've done 26,000 edits on Wikipedia and I never noticed that little star that tells you it's a Good or Fine article. I doubt that anybody else has either. Let's put a notice at the top of the article that everyone can see and read saying that Wikipedia considers this a "Good" article.

Maybe the first step in the simplification process would be to combine B, C, and Start reviews into a single category as they are arbitrary -- and it's not really very useful to distinguish among them. Smallchief (talk) 20:02, 30 November 2017 (UTC)[reply]

I've said this variously before, but I would totally be in favor of switching to something like Stub, Article, Good Article, Featured Article. GMG ^talk 20:07, 30 November 2017 (UTC)[reply]

That sounds good to me. Smallchief (talk) 20:09, 30 November 2017 (UTC)[reply]

Having said that, even if this could get consensus, I have no idea how much work it would take to piece together a bot that could change the current rating conventions on 5.5 million article talk pages and lord only knows how many associated template. Ping... uh... User:Primefac. GMG ^talk 20:18, 30 November 2017 (UTC)[reply]

Writing the bot is easy. Getting consensus for having that much spam in people's watchlists would be difficult. power~enwiki (π, ν) 20:20, 30 November 2017 (UTC)[reply]

@@ Line 421: / Line 421: @@
 ::::That sounds good to me. [[User:Smallchief|Smallchief ]] ([[User talk:Smallchief|talk]]) 20:09, 30 November 2017 (UTC)
 :::::''Having said that'', even if this could get consensus, I have no idea how much work it would take to piece together a bot that could change the current rating conventions on 5.5 million article talk pages and lord only knows how many associated template. Ping... uh... [[User:Primefac]]. [[User:GreenMeansGo|<span style="font-family:Impact"><span style="color:#07CB4B">G</span><span style="color:#449351">M</span><span style="color:#35683d">G</span></span>]][[User talk:GreenMeansGo|<sup style="color:#000;font-family:Impact">talk</sup>]]  20:18, 30 November 2017 (UTC)
+:::::: Writing the bot is easy.  Getting consensus for having that much spam in people's watchlists would be difficult. [[User:power~enwiki|power~enwiki]] ([[User talk:Power~enwiki|<span style="color:#FA0;font-family:courier">π</span>]], [[Special:Contributions/Power~enwiki|<span style="font-family:courier">ν</span>]]) 20:20, 30 November 2017 (UTC)