Wikipedia:Village pump (proposals)/Archive 156

I can do this using my bot. There is a feature on WPCleaner called "Update ISBN warning messages" on WPCleaner. I have been having a discussion about this feature around two weeks ago. The discussion can be found Wikipedia talk:WPCleaner#ISBN warnings. The feature adds and removes ISBN warning messages on the talk pages of the affected articles. It tells the ISBN that is affected and it also tell the reason why the ISBN is affected. This will help Wikipedians fix ISBNs much more easily on English Wikipedia. The template is at User:NicoV/ISBN Warning at the moment. This needs to be moved to Template:ISBN warning. The talk pages with an ISBN warning message will be added into Category:Articles with invalid ISBNs. The WPCleaner script can add the warning message for the affected articles and remove the warning message for the articles that have been fixed automatically. I have tested this on my sandbox and it works. This feature is already available on French Wikipedia and User:NicoV kindly said that he can configure WPCleaner so that this can also happen at the English Wikipedia. The output looks like this:
  Your help is requested to fix invalid ISBN numbers (explanation) that have been found in the article:

• • ISBN 0-123-456-78 : The ISBN has only nine digits instead of ten so it is invalid.

Shall we have this brilliant feature which will help the identification of incorrect ISBNs on English Wikipedia? Pkbwcgs (talk) 10:19, 31 December 2018 (UTC)

I thought we already get error messages from apparently faulty ISBNs (and note that this sometimes includes the ISBN as written on the book) - how will this proposal improve things?Nigel Ish (talk) 10:24, 31 December 2018 (UTC)

@Nigel Ish: It will only do this to some ISBNs. At the moment, the ISBN errors are in the form of a list. It will also report incorrect ISBN formatting as well and it doesn't say that directly. Pkbwcgs (talk) 10:29, 31 December 2018 (UTC)

This can also be updated automatically and this makes it easier to locate faulty ISBNs. I am not sure exactly if it will tell the reason why the ISBN is faulty but this can be added manually. It will certainly list the faulty ISBNs. Pkbwcgs (talk) 10:33, 31 December 2018 (UTC)

The main interest I believe is that it's not restricted to ISBN created with templates (which can already be detected as invalid by the template), but it also works for ISBN created with the magic syntax. For example, note 189 on List of shipwrecks in 1946 is using an invalid ISBN but it's not detected because it's done using the magic link. WPCleaner uses several sources for finding invalid ISBN: categories, Check Wiki project, dump analysis... Errors found are listed in Wikipedia:WikiProject Check Wikipedia/ISBN errors but the editor of an article is currently unaware of this. --NicoV ^{(Talk on frwiki)} 10:44, 31 December 2018 (UTC)

It also detects some cases of incorrect syntax which do not produce a magic link (nowiki tags around the ISBN, a colon between ISBN and the number...). --NicoV ^{(Talk on frwiki)} 10:46, 31 December 2018 (UTC)

• I like the idea of a bot that can fix faulty ISBNs. Can I just ask will it do the same for faulty ISSNs (International Standard Serial Numbers)?Vorbee (talk) 14:39, 2 January 2019 (UTC)

  @Vorbee: I think the RfC launched by Pkbwcgs is only for reporting faulty ISBNs with a bot on the article's talk page, not fixing them with a bot. I can probably add some automatic fixing in WPCleaner for ISBN at some point, but it will probably be limited to format problems (wrong dashes, colons, dots...), not problems with the ISBN number itself (wrong length, incorrect checksum...) as it is really difficult to automatically know what is the correct ISBN (or even if the faulty ISBN is real...). Regarding ISSNs, WPCleaner can do the same as with ISBNs, it's just a matter of creating a dedicated warning template and configuring WPCleaner (it's already doing it on frwiki): Pkbwcgs will probably launch another RfC for ISSNs if this one is accepted and it has been put in production. --NicoV ^{(Talk on frwiki)} 16:35, 2 January 2019 (UTC)

  @Vorbee: I am doing a lot of help for ISBNs. I got RegEx ready that is ready for my bot to fix faulty ISBNs using AWB (PkbwcgsBot task 5) and I got approval for updating the list of articles with faulty ISBNs and ISSNs everyday (PkbwcgsBot task 8). The faulty pages are listed at Wikipedia:WikiProject Check Wikipedia/ISBN errors. However, we don't have ISBN warnings on article talk pages which means that users are unaware of some ISBN errors so notices on talk pages that tell which ISBNs are incorrectly formatted or are invalid. If this RfC succeeds, I will wait for User:NicoV to configure this feature for English Wikipedia and then submit a BRFA for my bot to add and remove these ISBN warning messages everyday using WPCleaner. As User:NicoV said, I will submit another RfC for ISSNs if this one succeeds. However, the top priority is for ISBNs because Wikipedia:WikiProject Check Wikipedia/ISBN errors has a huge and long list of faulty ISBNs. Pkbwcgs (talk) 17:11, 2 January 2019 (UTC)

• If you're interested to see the end result, I've configured WPCleaner on my test account to show it: check User talk:NicoV/List of shipwrecks in 1946 for the message that's written. Each part of the message can be configured (either in Checkwiki's configuration or in WPCleaner's configuration). --NicoV ^{(Talk on frwiki)} 18:12, 2 January 2019 (UTC)

  @NicoV: It looks good but that feature is not working on my WPCleaner test version at the moment. It says "You need to define the 'isbn_warning_template' property in WPCleaner's configuration". Pkbwcgs (talk) 18:30, 2 January 2019 (UTC)

  @Pkbwcgs: Yes, it's because I did the configuration only in my test account (NicoVTest), so the configuration is not available to others. And I also modified WPCleaner to allow user's specific configuration for some parameters. If this RfC is accepted, we can put the configuration in the general configuration page. --NicoV ^{(Talk on frwiki)} 20:50, 2 January 2019 (UTC)

  @NicoV: Okay. I have one question. Will this feature automatically report what is wrong with the ISBN (e.g. incorrect checksum, ISBN too long etc.) and tell this information in the ISBN warning message? Pkbwcgs (talk) 20:54, 2 January 2019 (UTC)

  @Pkbwcgs: It will give the same level of details as the example User talk:NicoV/List of shipwrecks in 1946: for example, in the example, the message says that the checksum is incorrect. Messages can be customized i, Checkwiki's configuration, with some variable parts. --NicoV ^{(Talk on frwiki)} 21:25, 2 January 2019 (UTC)

  @NicoV: That is a brilliant feature and I am sure it will benefit English Wikipedia by users being aware of what is wrong with the ISBN so that it can be fixed. Thanks for creating that feature. I am sure it will help. Pkbwcgs (talk) 22:05, 2 January 2019 (UTC)

the first one of these that I check: 0 7209 3995 2 in Lepidosperma squamatum matches the number in the published work at http://museum.wa.gov.au/sites/default/files/1.%20Storr_5.pdf so what do you do about that? Is the number in print authoritative? Graeme Bartlett (talk) 22:45, 2 January 2019 (UTC)

That's a good question Graeme Bartlett, and unfortunately I don't have a definitive answer that works for each case. For your example, the ISBN doesn't match the rules for constructing an ISBN: the computed checksum is "X", but the ISBN shows "2".

As I mostly work on frwiki, I can explain what I do for books in French: the authority for ISBN published in French (ISBN starting with 2, 978-2 or 979-10) is the French National Library. I usually search there for the book and if the notice exists, it will say either

• #1) that's actually the ISBN but it is errorneous (in that case, I use a special parameter "isbn erroné" instead of "isbn" to clearly state that the book has been published with an errorneous ISBN)
• #2) there's an other ISBN (in that case, I user the ISBN on the notice)
• #3) that's actually the ISBN but nothing says that it is errorneous (in that case, I report the problem to the BNF and they usually fix it within a week, so I end up with case #1 or #2)

For books in English, I don't know if there's such an authority... I use Worldcat a lot for them, but I find it useful only when the ISBN in the article is not the same as the one in the notice. In your case, Worldcat has only 2 entries for this book OCLC 24474223 and OCLC 941859713 and none of them gives the ISBN. Same for the National Library of Australia... So I don't know for this one. Maybe remove the ISBN from the article and use the OCLC or NLA link ? Or consider that the ISBN in print is authoritative and have a special parameter for the cite template to acknowledge that ?

I think that before running a bot to put the message on all talk pages, it could be good to do a first pass manually with WPCleaner to fix the easiest ones (Wikipedia:CHECKWIKI/WPC 069 dump: invalid syntax, Wikipedia:CHECKWIKI/WPC 070 dump: the ones that have the 10 or 13 prefix). --NicoV ^{(Talk on frwiki)} 07:53, 3 January 2019 (UTC)

@NicoV: I am also going to configure this feature and test it in my userspace. Pkbwcgs (talk) 11:39, 3 January 2019 (UTC)

@Pkbwcgs: The version of WPCleaner that is available publicly doesn't allow user specific configurations for ISBN warnings (I modified locally my source code to do it with my test account). But I think you can try to configure it on the general configuration page User:NicoV/WikiCleanerConfiguration if you want : in normal use (not bot mode), WPCleaner will only update an existing warning, not create one (that's why I manually created User talk:NicoV/List of shipwrecks in 1946/to do), and only if the modification on the article page has fixed any ISBN related problem. After your test, comment out the configuration to be sure. --NicoV ^{(Talk on frwiki)} 11:50, 3 January 2019 (UTC)

@NicoV: I am trying it on Benfleet railway station (reference 2 has an ISBN error). My configuration is located at User:Pkbwcgs/WikiCleanerConfiguration and the article in my userspace is located at User:Pkbwcgs/Benfleet railway station. The to do page is located at User talk:Pkbwcgs/Benfleet railway station/to do and the talk page is at User talk:Pkbwcgs/Benfleet railway station. However, the test is not working. What am I doing wrong? Pkbwcgs (talk) 12:03, 3 January 2019 (UTC)

@Pkbwcgs: Check my previous message: #1 you have to do the configuration in the main configuration's page User:NicoV/WikiCleanerConfiguration because user's specific configuration is not accepted by WPCleaner for those parameters. And you also have to fix at least something related to ISBN in the page User:Pkbwcgs/Benfleet railway station to trigger update of the ISBN warning. Otherwise, everything is done in bot mode, but it's not possible to select on which page it will work. --NicoV ^{(Talk on frwiki)} 12:41, 3 January 2019 (UTC)

@NicoV: Am I allowed to configure this feature on User:NicoV/WikiCleanerConfiguration and when I am done with testing, shall I revert it? Pkbwcgs (talk) 16:05, 3 January 2019 (UTC)

@Pkbwcgs: Yes, I think you can change User:NicoV/WikiCleanerConfiguration, use User:NicoVTest/WikiCleanerConfiguration to see what is needed. When you're done testing, you can either revert your modifications or just put them in comment (a # at the beginning of a line is a comment). --NicoV ^{(Talk on frwiki)} 16:16, 3 January 2019 (UTC)

@NicoV: For some reason, the feature is not changing anything. It is only saying it is retrieving the contents. Pkbwcgs (talk) 16:35, 3 January 2019 (UTC)

@Pkbwcgs: You have to fix an ISBN problem in your test page with WPCleaner to trigger the update (I did this one for my test). --NicoV ^{(Talk on frwiki)} 16:47, 3 January 2019 (UTC)

@Pkbwcgs: I forgot that there was a menu to add the ISBN warning directly, that's why I was talking about fixing an ISBN in the page. But, I tried to add the warning through the menu and it didn't work: I probably have to modify something in my code to handle the configuration for enwiki (it's different than frwiki). I'll keep you posted. --NicoV ^{(Talk on frwiki)} 16:57, 3 January 2019 (UTC)

@NicoV: It updated the ISBN warning message here. However, I think English Wikipedia would benefit from this if this warning message can be directly added and removed from the talk page of the article by my bot rather than having another "To do" subpage to make this feature work. Pkbwcgs (talk) 18:32, 3 January 2019 (UTC)

@NicoV: Your feature works brilliantly. It was unexpected as I pressed the wrong button but I reverted the edits. However, things like this diff would absolutely benefit Wikipedia. Pkbwcgs (talk) 21:06, 3 January 2019 (UTC)

@Pkbwcgs: WPCleaner can put the warning directly on the talk page or on the subpage depending on the configuration. The parameter general_todo_templates is for adding a template directly on the talk page (that's what happened in this diff): I think it's not correctly configured for enwiki as {{todo}} doesn't accept the list of tasks as a parameter. The parameter general_todo_subpage is for the name of the subpage to use when the warning is put on the subpage. To decide whether or not to put the warning on the subpage or on the talk page: general_todo_subpage_force forces the use of the subpage regardless of the other tests ; if the subpage already exists then the warning is put on the subpage ; if there's already a template on the talk page that provides a link to the subpage (from general_todo_link_templates, which seems to be the correct list for {{todo}}) then the warning is put on the subpage. --NicoV ^{(Talk on frwiki)} 10:16, 4 January 2019 (UTC)

As can be seen in this diff (and in the example in the OP) the rendered template has broken list markup (one asterisk is displayed as such; and a final line has two, not one, bullet points). This needs to be fixed, before any bot run please. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:28, 4 January 2019 (UTC)

@Pigsonthewing: That is a good point. I am actually not sure how to fix that problem. The template is located at User:NicoV/ISBN Warning at the moment if you would like to fix it there. It is transcluded through Template:To do so the problem could also be in that template as well. I have tried to fix it but it didn't work. Pkbwcgs (talk) 12:37, 4 January 2019 (UTC)

@Pkbwcgs: See User:NicoV/ISBN Warning/Sandbox. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:07, 4 January 2019 (UTC)

@Pigsonthewing: That looks good. @NicoV: Can you please amend WPCleaner so that this feature makes the template render as:

{{todo|
* {{ User:NicoV/ISBN Warning | revisionid=875583851 | 978-3-931473-16-4 | Computing the checksum gives 7, not 4 }} -- 21:02, 3 January 2019 (UTC) <!-- This line is updated from time to time by a bot. -->}}

We don't need a "to do" subpage for every talk page; I think it is updating fine so please don't change that. However, we want the line space after {{to do|. Pkbwcgs (talk) 18:57, 4 January 2019 (UTC)

@Pkbwcgs: You can try the last version... --NicoV ^{(Talk on frwiki)} 23:07, 4 January 2019 (UTC)

@NicoV: What do you mean by the "last version"? Pkbwcgs (talk) 12:03, 5 January 2019 (UTC)

@Pkbwcgs: If you're running WPCleaner normally (throught getdown, or with the provided scripts), it should update itself automatically to the release I did yesterday. Version number is the same. --NicoV ^{(Talk on frwiki)} 12:21, 5 January 2019 (UTC)

@NicoV: Shall I move the working ISBN warning template from User:NicoV/ISBN Warning to Template:ISBN warning? Pkbwcgs (talk) 12:25, 5 January 2019 (UTC)

@Pkbwcgs: It will be better if you wish to run the bot. --NicoV ^{(Talk on frwiki)} 13:22, 5 January 2019 (UTC)

@NicoV: Okay. I would still prefer to gain some consensus before I file the BRFA for this to run. Pkbwcgs (talk) 13:31, 5 January 2019 (UTC)

@Pkbwcgs: No problem. My own advice would be to rename the template and its documentation subpage, add a note on the documentation saying that consensus is required before using it. At least, you're sure you won't have to modify manually warnings put with the incorrect template name... --NicoV ^{(Talk on frwiki)} 14:06, 7 January 2019 (UTC)

Let's say I edit a wikipedia page. A few month later, somebody modifies my version (not using "undo", just overwriting what I've done). By default, there will be no alert about this. The basic setting should be to alert you, that's it to have the checkbox "Watch this page" checked by default each time you edit a page.

• Comment "Watch this page" should give individual more selective options on what "what the user want to watch". Right now it does not have. Colton Meltzer (talk) 05:44, 28 December 2018 (UTC)

"Power" editors, editing thousand of pages, would of course get a lot of notifications. But firstly it's not sure that it's unpractical for every power editor and secondly this kind of editors knows how to find their way to disable this option globally (by Preferences>Watchlist>Add pages and files I edit to my watchlist). This option is a bit buried in the options so most users will probably never use this option it but that's probably not the case for "power" editors.

• It's Counterintuitive

That's what you'll find on most internet boards, blog comment sections and I guess that's the expecting behavior for any user on this kind of sites. You don't have to rummage through the settings to find the option to get notified.

• It's Harmful

It's harmful because it misses the opportunity to encourage "not regular editors" to become regular editors. I guess people editing page quite rarely will completely forget their modification. If they're not alerted for further modifications, most will probably never know that and never come back on the page. Linuxo (talk) 12:14, 18 December 2018 (UTC)

Thanks for the suggestion, but I don't think it is needed. Some pages I edit, I check the little blue star and others I don't. You soon get into the habit. When your edit count grows you will no longer remember what you add to individual pages and you will learn to trust others to be sensible. There may be corners of WP where I don't tread where this is different- if you are working there check the star. ClemRutter (talk) 12:31, 18 December 2018 (UTC)

For yourself, go to Special:Preferences#mw-prefsection-watchlist and check the checkbox labeled Add pages and files I edit to my watchlist. If you're wanting to have that checkbox be checked by default for new users, it would need an RFC to show community consensus and consideration of the issues discussed in T38316. Anomie⚔ 03:00, 19 December 2018 (UTC)

Just would like to thank you for making me aware of this option. Thanks! WelpThatWorked (talk) 05:23, 20 December 2018 (UTC)

I have my preferences set to place every page I edit on my watchlist. That does have consequences: I now have more than 5,300 items on my watchlist (although I prune it occasionally, so that there are are over 7,000 pages I have edited that are not currently on my watchlist). I spend a good part of every day working through my watchlist. I'm sure there are a lot of editors that do not want, or have time, to deal with that. I think it would be best to leave this as an option. - Donald Albury 13:31, 19 December 2018 (UTC)

Watching every page you edit can easily become overwhelming. Only advanced users will like that. Therefore, I think it's better to keep the functionality opt-in. --NaBUru38 (talk) 14:26, 26 December 2018 (UTC)

If one wants to watch a page then click on the blue star. To set default on all pages which one edits would be overwhelming when edits on new articles increase. CASSIOPEIA^(talk) 14:37, 26 December 2018 (UTC)

• Oppose. I participate in a wiki in which this is the default, and it is not workable. You end up with hundreds or thousands of pages watchlisted, and the watchlist becomes effectively useless. We already have an option to turn this on, for people who want it and who can deal with it (probably editors very narrowly focused on a sharply limited topic range, and that's not most editors. Too many of us (probably very nearly all of us) randomly edit pages to fix typos and improve text, so this proposal is not practical, especially on site with several million articles, plus a large number of process and procedure pages, and a community norm of using user talk pages to communicate, and of leaving notices of deletion proposals and other such matters on relevant project talk pages, etc., etc.  — SMcCandlish ☏ ¢ 😼  23:50, 6 January 2019 (UTC)
• Oppose- Per SMcCandlsih: not a viable option, at least for those of us who edit many more pages than they watch. Beyond My Ken (talk) 17:08, 7 January 2019 (UTC)
• Support alternative I think we need to rephrase the proposal. Instead of having "Watch this page" checked by default, we should have "Add pages and files I edit to my watchlist" checked by default for new users. Power users who edit more pages than they watch can easily uncheck the preference once, but many users may not know that that preference exists. --Ahecht (TALK
  PAGE) 15:19, 8 January 2019 (UTC)
• Oppose Per SMcCandlish, I added around 30000 missing articles to my watch list in 2015 and cleared out many that had been created in 2017. at the end of 2018 I cleared out all the entras and restored my original pages and went through the Xtools to find other pages (including talk pages etc) that I had created. But I agree if we include all pages edited, the watchlist would be too cluttered. For the very few (like User:J3Mrs) who make many contributions to not that large amount of pages it can be useful. It could also increase edit wars (if people are watching every article edited), although it might make vandalism quicker to revert, it may discourage people from checking their watched pages if there were too many irrelevant pages. The default of watching creations (and moves I think) is sensible and enough. The few that do want this can opt in. As I mentioned to Donald Albury I added Ashford Carbonell to my watchlist due to recent problems but I don't think watching every edited page is generally sensible. Crouch, Swale (talk) 17:31, 8 January 2019 (UTC)
• Support It's better to have extra pages on your watchlist you can remove later than forget and lose track of your edits, in my opinion. Of course there should be an option to uncheck "Watch this page", but by default it should be on. People, especially new people, forget to add their edits. PrussianOwl (talk) 23:11, 8 January 2019 (UTC)
• Oppose I oppose making it the default, even though I had it turned on for all my edits for many years. In fact, I just (today) changed my settings to only add pages I create to my watchlist. My watchlist had grown to over 5,300 pages, but I removed about 1,800 pages today, almost all of which were moribund. Most of the pages on my watchlist show up maybe once every few months or less often. Many of those pages have a low number of watchers, and if I dropped them, vandalism to them might not be noticed for a long time. If I stopped following project pages, my watchlist would be very easily managed. But, what works for me may not work for others. - Donald Albury 00:38, 9 January 2019 (UTC)
• Oppose There's no need to watch everypage I edit, I edit several pages (minor edits) that I have no interest in, don't even mention uses who use programs like Huggle and AWB. – BrandonXLF (t@lk) 01:48, 9 January 2019 (UTC)
• Oppose, I add short descriptions to lots of pages that I do not want added to my watchlist under any circumstances. My watch list is alreadt larger than optimum with only the pages I created and manually added because I actually want to monitor them. If every page I edit were to be added, I would have to severely cut down on editing. If I remember correctly this is already an opt-in for anyone who is mad enough or edits so few pages that it would not be an enormous inconvenience. This should not under any circumstances be forced on anyone by making it default. · · · Peter Southwood ^(talk): 17:31, 9 January 2019 (UTC)
• Alt Suggestion. If the default was that the first 100 articles that you edit were added to your watchlist and then the system asked you, I think we would have a system that worked better for both newbies and old hands. My own watchlist has snuck back up from 4,000 to 5,000 despite some brutal pruning when I removed 9,000 pages a while back. So I certainly don't want an ever expanding watchlist, but I would like an option to watch sections. ϢereSpielChequers 19:08, 9 January 2019 (UTC)

  I suppose that could work, but may be more complicated and confusing, checking if "current" appears on you're contributions (though I don't do that much) and viewing the recent changes linked with pages linking to you're user page are sufficient IMO. I found an article that had been listed at AFD after I de-proded it by quickly checking through my contributions, though I don't do this that often. Crouch, Swale (talk) 19:16, 9 January 2019 (UTC)

• Support, only old-timers are in this discussion, and we can easily adjust according to taste. However, it's about noobs. 22 hours ago I dined with two new editors while explaining the watchlist. Newbies should learn early about watching their watchlist, and later get to the details of adjusting it. Jim.henderson (talk) 22:28, 9 January 2019 (UTC)
• Oppose and I'm most certainly not an old timer. I already have 27,308 pages on my watchlist, mainly because of my anti-spam work; this would be probably doubled if every page I edited but didn't tag was watchlisted too, and, more, for completely pointless reasons—90% (at least) low-level spammers such as I deal with never post again, so the very watchlisting is pointless. Let alone those who are not spamming! ——SerialNumber54129 23:34, 9 January 2019 (UTC)

There is a bot proposal to add this template to ~6300 article talk pages where the article is longer than 150,000 bytes (per Special:LongPages), like in this edit.. If this is something you would like to have happen, community support for running bots is required. This is the place to voice if you want a bot to do this or not. -- GreenC 15:56, 4 January 2019 (UTC)

150,000 bytes seems too low of a cut-off. Since the point of the template appears to be for oversized articles, something like 250000 would make much more sense as a cut-off because most pages at around 150000 bytes don't really need to be reduced in size (though of course things vary, and certain bare lists that size may need to be cut down or split). Galobtter (pingó mió) 16:24, 4 January 2019 (UTC)

@Pigsonthewing: -- GreenC 17:09, 4 January 2019 (UTC)

I disagree with Galobtter's assessment (most 150000 bytes articles are too long; see WP:AS); but in any case such bike-shedding is irrelevant; this template is to inform editors of the relative size of sections of articles; it does not mandate nor even recommend a split. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:15, 4 January 2019 (UTC)

WP:AS mainly talks about readable prose size, and most 150000 byte articles have a readable prose size much less than what necessitates a split per that guideline (indeed, there are numerous FAs which are more than 150000 bytes long). Every template adding to a talk page adds to the clutter, so there has to be some benefit; since that benefit would mainly be when talking about a split, talking about the cutoff seems important here when automatically adding the template. Galobtter (pingó mió) 15:35, 5 January 2019 (UTC)

A 250,000 limit is about 1000 articles. How was 250,000 arrived at? Asking because it seems to make a big difference how many articles would have the template based on where the cut-off number is. Personally I don't think 6000 articles is very much at all in the scheme of 5700000 articles, with that few I doubt most people would ever see the template in their lifetime at Wikipedia. -- GreenC 16:03, 5 January 2019 (UTC)

Large size articles would very disproportionately be popular ones which already have a very large number of templates on their talk page. (pages like Talk:Cristiano Ronaldo and Talk:Barack Obama would be the ones tagged, not obscure articles) Galobtter (pingó mió) 17:01, 5 January 2019 (UTC)

Like I said, "such bike-shedding is irrelevant". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:57, 5 January 2019 (UTC)

Are we talking 150kb bytes of readable text, or of total page size? 150kb of readable prose is almost certainly too long except in exceptional circumstances when there's a valid argument that all the material has to be kept together, but 150kb save size isn't unusual for pages that include lots of complex template markup (Barack Obama, for instance, uses 340kb of code to produce 79kb of readable prose). I'd quite strongly oppose using a bot to tag everything just based on the size of the code, as that will end up flagging large numbers of completely non-problematic articles as being too long, and consequently annoy a lot of people for little or no obvious benefit. ‑ Iridescent 17:10, 5 January 2019 (UTC)

There seems to be some confusion. The template being discussed does not suggest an article is too long. Jack N. Stock (talk) 17:15, 5 January 2019 (UTC)

Agree with that. And if we aren't talking about articles that are too long, what are we talking about? The template decumentation is (as usual) unclear, as is the proposal above. Johnbod (talk) 17:17, 5 January 2019 (UTC)

We're talking total page size (going off Special:LongPages which uses that), thus my comments. Galobtter (pingó mió) 17:19, 5 January 2019 (UTC)

You mentioned Talk:Barack Obama - why are we tagging that exactly? Johnbod (talk) 17:22, 5 January 2019 (UTC)

Well, the bot would be adding the template to the talk page of any article with more 150kb of wikitext, which would include Barack Obama (which has 340kb of code as Iri mentioned) Galobtter (pingó mió) 17:25, 5 January 2019 (UTC)

Exactly! But why? The original tool request By Andy was very much talking about "very long pages". Johnbod (talk) 17:27, 5 January 2019 (UTC)

It's useful information for whatever purpose. Such as breaking sections up into sub-sections, breaking sections into separate articles, refactoring sections by deleting content. Large article are targeted for the template because they are most likely to have work of this nature it helps users identify which sections they might want to work on. -- GreenC 17:32, 5 January 2019 (UTC)

FWIW Barack Obama is 85,394 as plain-text according to the API [1]. -- GreenC 17:44, 5 January 2019 (UTC)

• In light of the above replies, strongly oppose; this is clearly not an attempt to address an actual problem, but a pretext to use a bot to mass-spam this template under the guise of fixing a non-existent problem. ‑ Iridescent 19:27, 5 January 2019 (UTC)
  • So much for WP:AGF... Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:27, 5 January 2019 (UTC)
• Don't see the point of this. Headbomb {t · c · p · b} 20:58, 5 January 2019 (UTC)
• Oppose - This is a solution looking for a problem. –Davey2010^Talk 22:21, 5 January 2019 (UTC)
• I think this could be useful, but only if it also included other important size information such as readable prose size in bytes and words. Something like the output of this script would be beneficial: User:Dr_pda/prosesize.js. - MrX 🖋 22:24, 5 January 2019 (UTC)
• @GreenC: As the example edit added the template to a talk page that was 65 bytes in size, it appears the opening comment is incorrect and misleading. This is not about the size of the talk page. Suggest a strikethrough and correction to prevent confusion like mine. ―Mandruss ☎ 22:37, 5 January 2019 (UTC)

  fixed -- GreenC 23:14, 5 January 2019 (UTC)

  Fixed without strikethrough (and underscore), but whatever. FTR, the correct form is "article talk pages that are where the article is longer than 150,000 bytes". ―Mandruss ☎ 23:23, 5 January 2019 (UTC)

• Don't see the useful purpose. Not saying there isn't one, but it has not been explained. Hard to avoid bike-shedding when asked to comment on something where the intended purpose is not specified. · · · Peter Southwood ^(talk): 05:48, 6 January 2019 (UTC)
  • Nudge theory. Too-long articles are a well known and perennial topic on the various VPs. It has proven to be stubbornly difficult to reduce the size of long articles, so they keep growing; it is easier to grow than to shrink, sort of like the things collecting in ones basement and garage. This template is an unobtrusive small nudge towards condensing material. -- GreenC 04:48, 7 January 2019 (UTC)
• Support This would be useful information about the article. —Eli355 (talk • contribs) 22:02, 8 January 2019 (UTC)
• Oppose please avoid piling on talk-header-template cruft. The only apparent purpose for this would be as some sort of aid if someone was working on reducing page size, and even *if* someone were working on that, that must based on examination of the actual text in each section rather than blind numerical section sizes. Alsee (talk) 09:43, 10 January 2019 (UTC)
• Oppose more talk page clutter. Renata (talk) 13:21, 10 January 2019 (UTC)

We are using a lot of graphs in Wikipedia, and that's a good things. Graph can really help understanding data.

Sadly, a lot of graph on Wikipedia are misleading because they do not follow basic good practices.

To name a few:

• Use of pie chart (almost never a good idea, bar chart should be preferred)
• Origin of the graph at some other value than zero
• No name to axis
• Use of percentage, but axes do not show the complete range from 0-100%

 

 

Most of the graph are done using https://en.wikipedia.org/wiki/Template:Graph:Chart. And I believe we can fix a lot of common issue by modifying this template. I opened the discussion on https://en.wikipedia.org/wiki/Template_talk:Graph:Chart#Convert_all_Pie_chart_to_Bar_chart but I think this go beyond the template page.

My propositions:

1. Use 0 as a default value for xAxisMin and yAxisMin.
2. If pie type is used for more that two values force the use of bar chart (rect)
3. if xAxisTitle and yAxisTitle are empty. Display a warning.
4. Be a bit smart about xAxisMax and yAxisMax. How do you detect their is percentage? We can't be sure, but we can use yAxisMax=100 by default when the sum of the value is equal to 100 for example.

Gagarine (talk) 17:47, 30 December 2018 (UTC)

Gagarine, While supporting the notion that many graphs in Wikipedia may fail to follow good practices, I suggest that mandating good practices is potentially problematic. At a minimum, we ought to start with some suggestions and over time, gradually determine whether some hard rules can be implemented. I suspect that might be impossible. While some of your rules sound plausible, it isn't hard to find exceptions. For example, mandating zero as a minimum value is not necessarily the right answer. I am quite aware of that the use of selective values can be misleading, but mandating zero isn't always the right answer. Temperature graphs are a good example in three ways. If the graph is in Fahrenheit, 0 degrees Fahrenheit is an arbitrary value. Similarly, if you adopt the scientific preference for centigrade or Celsius as some people like to say, zero is not the same as for Fahrenheit and is almost as arbitrary. If you then go on to note that those two values are arbitrary but a nonarbitrary value is absolute zero, I suggest that there are very few temperature graphs for which you would really want to use absolute zero as the zero point.

I'm going to push back on the notion that a pie chart is almost never a good idea. Perhaps there is some rationale I'm missing, but when talking about the makeup of some group where the entire group is viewed as 100%, I think pie charts can be appropriate.

It's hard to disagree that having no name on the access is a bad idea. I don't disagree that good practices are to include a name on the axis, but converting it to a rule could be a problem. Imagine that some artists is reproducing some famous graph which happened not to have a name on the axis. feel free to take pot shots at the originator of the graph, but we certainly shouldn't insist that a faithful reproduction of a (presumably public domain) graph should artificially include a name.

While not coming up with a great example off the top of my head, I'll be surprised if we can't come up with a percentage graph in which forcing the range to be 100% is always the best idea. (Not to mention the fact that percentages can exceed 100%, so forcing a rule would be problematic.

I apologize for only focusing on negatives, but we need to be careful when implementing rules that we don't artificially enforce a format that is not the best format. S Philbrick(Talk) 02:17, 1 January 2019 (UTC)

Sphilbrick I'm more about good default than imposing things. For example, I do not want to mandating zero as a minimum value, but if no value is provided then we should use zero.

The page about pie chart start with: "Pie charts are very widely used in the business world and the mass media. However, they have been criticized, and many experts recommend avoiding them, pointing out that research has shown it is difficult to compare different sections of a given pie chart, or to compare data across different pie charts. Pie charts can be replaced in most cases by other plots such as the bar chart, box plot or dot plots.". You can find the references on the pages.

I agree we need to be careful, but I think we can be smarter by using better default for the template and perhaps documentation about good practices. Gagarine (talk) 18:30, 1 January 2019 (UTC)

Gagarine, We are on the same page if your goal is to provide good advice as opposed to mandating rules. That seems to be the case in your recent post where you said "I'm more about good default than imposing things". however, your propositions include "If pie type is used for more that two values force the use of bar chart (rect)". that sounds more like a mandate than advice.

I'm a fan of Tufte. It's been quite some time since I read his notable work and I confess I hadn't recalled his distaste for pie charts, but I read him as being opposed to bad pie charts, and possibly carrying out a little too far by suggesting they are never appropriate. (I confess I haven't gone back to read the original but I'm picking up on some summaries.)

our article on the incoming Congress 115th United States Congress has some nice graphics showing the breakdown of the membership. The use of the individual dots is arguably better than a pie chart but I'll emphasize that it's arguable as opposed to unequivocal. Not everyone making a presentation has easy access to such graphics capabilities. As noted at this site, bad pie charts can be very poor tools, but use of a bar chart for values that naturally some to 100% is not necessarily preferable to a pie chart. I know you included an exception for two values, but United States political articles showing party breakdown are classic examples of data with the values add to 100%, typically have two dominant values but often have a third (or more), and the single most important piece of information is which party is largest and whether it's in excess of 50%. A pie chart with two or three or four values conveys that cleanly and immediately. A bar chart doesn't do the job as well. Imposing a rule that pie charts can only be used if there are exactly two values would lead to the absurdity that when there are no third-party candidates pie charts would be used but if there's a small handful of third-party politicians, then we would switch to a bar chart.

The link does show examples where pie charts can be misused, so again, we are on the same page if we want to avoid their misuse, but my concern is your proposition doesn't sound like advice but in imposition of a rule. S Philbrick(Talk) 16:39, 2 January 2019 (UTC)

I agree that the format of various charts and graphs can be, and often has been, massaged to support a particular point of view, and that these shenanigans have no place on WP. The most egregious example of this is placing the origin at an unexpected location to emphasize a difference in numbers. I suspect however that most examples of bad or misleading format choices on WP are the more innocent in nature, being the result of ignorance of what constitutes good design rather than intentionally bad design. My objection to the proposal is that the design of visual information is a large and complex subject and it's probably better to refer editors to an appropriate standard work on the subject. We don't try to include the Chicago Manual of Style or Strunk and White in WP policy and similarly we shouldn't try to summarize Tufte's 'The Visual Display of Quantitative Information' in WP policy either. I'm more concerned that the data from which charts and graphs are clearly and reliably sourced and that other editors are easily able to tweak and improve the design if necessary. --RDBury (talk) 07:07, 9 January 2019 (UTC)

From what I have seen in this argument, the general consensus appears to be that yes, we should avoid bad graph practice, but no, we should not force certain things being that there are too many exception/flaws. May I suggest writing an essay instead of an official rule change or template change? Or maybe add these guidelines to the template documentation without implementing anything specific in the code? Integral Python ^{click here to argue with me} 15:37, 11 January 2019 (UTC)

Former discussion: Wikipedia:Bot_requests#Remind_me_bot.

The idea is to create a bot/template pair that sends on request a reminder to go back to a particular page. The case use is typically to check back on a discussion on high-traffic pages where a watchlist is inefficient or (on the contrary) when the discussion has very little participation and you want to make sure to come back one week afterwards to assess consensus.

As the reminder would likely take the form of an in-wp post, such a bot needs consensus per WP:BRFA. I believe VPP to be the best (or least worse) forum for that discussion, but do tell if I missed something obvious.

A template (e.g. {{remind me}}) that takes one argument, either a fixed date or a duration of time, is left by a user on the page they wish to be reminded of. Template transclusions are watched by a Toolforge bot (running every hour or so?). When the time is up, the bot posts a notification to the requesting user's talk page.

Asking for a notification by this process is public (i.e. other editors know that you asked for an update, when you asked for it etc.).

Depending on the technical details, and if that template gets widespread use, it might become necessary to put limits on the use. I would suggest no more than X pending notifications per user (so that you can put hanging notifications for Christmas 2118 but it eats up one of your slots); I think X=10 is a reasonable starting value if it comes to that, but I do not think it is needed outright.

1. While the bot postings themselves are fairly innocuous (you get 'em only if you ask for 'em), there could still be some clutter in the reminder request templates: e.g. if 100 posters drop just a "remind me" template in a discussion where 5 people are actually participating. I believe (1) that is quite speculative and (2) if it ever becomes a problem, it might be solved by conduct guidelines (e.g. "avoid using this template outside an overwise meaningful post, as this can be considered disruptive").
2. As pointed in the previous discussion, that might duplicate a Community Wishlist item that was among the top 10 (and hence will be worked on by WMF staff). I believe the use case is slightly different (that one is targeted at talk pages, as opposed to articles), and even if it is indeed redundant, I do not see the harm. (As I will be the one handling the bot coding, time wasted duplicating a system can be ignored: I think it would be fun to code. The only question is whether having two systems might be harmful, not useless.)

I have a better design.

Make a bot that you place on your own talk page (or on a special page if that makes the bot easier to write) with the same fixed date / duration of time arguments.

If I put

 {{remindme|03:14, 19 January 2038 (UTC)|Check [[Talk:Cockcroft–Walton generator]] for replies}}

on the appropriate page It would wait until January of 2038 and then post the following to my talk page:

Remindme bot reminder notice

On 00:00 1 January, 1970 03:14 (UTC), you requested a 03:14, 19 January 2038 (UTC) reminder. The text of the reminder is:

Check Talk:Cockcroft–Walton generator for replies

-- [Bot signature]

That way you could be reminded of anything. I have a similar reminder set locally that I use to remind me to check the edit history of blocked IP vandals a week after the block expires. That way I can report them if they go right back to vandalizing.

To reduce abuse:

The reminder should happen even if some vandal deletes the request.

There should be a way to cancel a reminder.

Users or admins should be able to cancel reminders for that user.

Reminders should be limited to 255 characters.

Users should be limited to no more than 32 open reminder requests.

A FAQ should explain that this is for Wikipedia-related use only; no "don't forget to buy more Vegemite" reminder requests.

If possible, it should be impossible or at least difficult to set a reminder to be shown on someone else's talk page.

--Guy Macon (talk) 14:06, 18 December 2018 (UTC)

@Guy Macon: If this were done on a user "JSON" page (eg User:Example/remindme.json) it would be: simpler for bots to parse requests (I think), restricted to editing by the same user, or administrators (meaning that vandalism is not an issue, and if the reminder is only sent if the request is present at the time specified, allows cancelation), makes it easier to limit requests (only pay attention to the first 32 json objects). Thoughts? --DannyS712 (talk) 00:59, 27 December 2018 (UTC)

• Can't you just make a bot-less design? Just put a template on your userpage that displays blank until time XXX, and then displays the reminder you wish it to display. You could probably make a user script that automatically adds such a reminder from any page. —Kusma (t·c) 11:04, 12 January 2019 (UTC)

  @Kusma: I could start working on a user script, which (i think) wouldn't need community approval (like a bot) because its a script, and would just edit in userspace... --DannyS712 (talk) 17:33, 12 January 2019 (UTC)

Hi guys, I might be misreading things, but does this not sound like one of the things in the top then of the community wishlist Article Reminders? Nosebagbear (talk) 19:55, 18 December 2018 (UTC)

It does. IMO people interested should get involved with the creation of that feature than rush to implement a bot to do mostly the same thing. Anomie⚔ 03:02, 19 December 2018 (UTC)

Indeed. I concur with Anomie. I wouldn't spend too much time on a bot/user script right now. The long-term solution might end up being a MediaWiki extension, which would address the possible objection about bot postings (since there'd be no bot involved). I suspect the implementation would allow for reminders about any page. To be clear, this project isn't "owned" by WMF, per se, rather it's now their responsibility. There have been top 10 wishes implemented by volunteers in the past. So, if you are eager to code you most certainly can be a part of it :) We just need to find the right solution first, one that accommodates the necessary workflows and will work for all wikis. — MusikAnimal ^talk 23:34, 30 December 2018 (UTC)

In July of 2018, Wikimedia made a call for proposals at their grants idea lab. The request called for ideas to improve Wikipedia community health. My first thought was that although some high-tension areas of Wikipedia are well trafficked and watched, there may be other less visible areas where discussion health may be an issue.

To make a template which can be optionally placed at the top of a talk page, with radio buttons, check boxes or single-select options ranking a talk page's health.

• Information would then
  • Be used to identify areas requiring feedback
  • Create statistical data about areas requiring attention

Some discussion regarding this proposal has taken place at Wikimedia

• the discussion includes:
  • A basic description of the proposal
  • Some example screen shots
  • A call for required experts and collaborators on the project
  • Some ideas about how to proceed on en-wiki.

This proposal has been mentioned at Wikipedia_talk:Community_health_initiative_on_English_Wikipedia

Edaham (talk) 02:52, 4 January 2019 (UTC)

What are the ranking criteria? Personal opinion? If so, what useful purpose would this serve? Would there be any actionable consequences? · · · Peter Southwood ^(talk): 06:00, 6 January 2019 (UTC)

• I don't see the point in this, especially since what's a 'healthy' or 'unhealthy' talk page is not something that can be turned into an algorithm. Headbomb {t · c · p · b} 15:21, 6 January 2019 (UTC)
• I'd go as far as to say that if anyone tried to add this to talk pages, I'd bulk revert and block them for disruption. Someone unilaterally declaring that pages they like the look of are "healthy" and pages they don't like the look of are "unhealthy" is about as uncollegial as one could get. Per the others above, what do you consider "healthy" and "unhealthy", anyway? Is a talkpage full of arguments an unhealthy sign because it's causing people to argue, or a healthy sign because it shows the community is engaged? Is a talkpage that hasn't had a single comment in six years a sign of poor health, or a sign that the attached article is so fantastic nobody can suggest any way to improve it? How do you prevent the usual lunatic fringe from canvassing all their friends to go and mass-downvote Climate Change, Rope worms or Gamergate controversy as "unhealthy"? ‑ Iridescent 15:52, 6 January 2019 (UTC)

  (adding) Having now read the proposal in full, changing from "no" to "hell, no". The whole thing seems to be based on what, to put it bluntly, is an absolutely batshit crazy notion of how Wikipedia operates, founded on the fundamental misconception that "the more dispute resolution is taking place regarding a topic, the healthier that topic is". ‑ Iridescent 16:34, 6 January 2019 (UTC)

"Thank you" for linking to rope worms. I possibly did not need to know that. Oh the humanity! |p --Elmidae (talk · contribs) 16:54, 7 January 2019 (UTC)

• Looks like a solution in search of a problem. - Sitush (talk) 16:01, 6 January 2019 (UTC)
• Not sure what this is meant to do, but it sure strikes me as a solution in search of a problem. Until we see a good definition of what "health of a talk page" means, I'm not seeing the need for this. Ealdgyth - Talk 16:27, 6 January 2019 (UTC)
• No. Solution in search of a problem. Edaham's interpretation of page health is grossly wild and inaccurate. What Iri says.∯WBG^converse 16:50, 6 January 2019 (UTC)
  • er, calm down? I was trying to help via some discussions I’d read on another wiki project. The idea would be to identify problematic areas of the encyclopedia and allow the community to give feedback without having to register complaints across pages. I’ve never made a proposal of this nature before, so please, try to assume good faith. I haven’t actually offered an “interpretation” of page health and deliberately left it open. The page you referenced was an example of a page one could reach via the template (It did actually say that at the top of the page, but I've since blanked it to avoid confusion), so I’m not sure what part of my suggestion could be termed, “grossly” or “wildly” inaccurate. Winged Blades of Godric. The idea would be that the resultant average would not be displayed, but be logged and available to people who want to know where problematic areas are and give an idea of health over time. “Mass downvotes” therefore, would be desirable from a point of view of being alerted to a a problematic area. It’s a feedback system. Many thanks for the comments though. Hope I didn’t take too much time out of your day. Edaham (talk) 00:57, 7 January 2019 (UTC)
• Unlikely. This idea reminds me of two problematic ideas -- one being the "upvoting" and "downvoting" prevalent on American social media, and the other being the "social credit" system being pursued by the Chinese government. Both of these things have the same problem, namely unreliable raters -- either an ignorant partisan rabble in the American case, or a sinister party elite AI in the case of the Chinese. In Wikipedia's case, it is moderately conceivable that some effort could be made to try to enlist "neutral" editors to do rating; I've long favored a jury system for settling disputes. But doing that without making it explicit that you're soliciting jurors and you want a fair decision and making the selection process both random and transparent and then targeting it all toward settling an issue rather than rating a page ... well, there are a lot of details I'd want there before this becomes that. Wnt (talk) 01:06, 7 January 2019 (UTC)

just a quick second comment to further clarify, firstly: results of voting needn’t be displayed. This is an opportunity for a user to rate an experience without having to have a discussion. We have lots of areas where people have to grind it out to be heard. We don’t have a system where people can easily and anonymously submit a piece of generic feedback. The data collected would provide a heat map of areas in which people had submitted this info, telling us about both level of interaction and satisfaction on a general scale.

secondly: I’m fully wp:MIAB compliant, so feel free to tell me if this is a hit or a miss. Be blunt. I don’t like being called batshit crazy though. Don’t do that if possible, cheers. Edaham (talk) 01:19, 7 January 2019 (UTC)

Well, the main problem with a 'heat map' is that the way I understand it, you're going to be looking for talk pages where people are furious at each other. If you find a talk page like that, everyone knows there's a dispute. Some of them have been on lists of "Wikipedia's lamest edit wars" for a decade or more. Probably the editors there want some kind of mediation by genuinely disinterested parties, but Wikipedia makes getting that extremely difficult. Whenever a new editor joins in the fracas to try to impose fair order, they end up sucked into the contention.

Also, I am concerned that developing a tool to provide secret results to an elite of Wikipedians would further increase the inequality between editors and therefore contribute to the decline of the project as a whole. We have an unhealthy dynamic in society that computers -> ownership -> special privileges -> dictatorship and it can be argued that "the medium is the message" and that online distribution of content is simply doomed to fail altogether. I don't know if any counteracting force can be devised, but in the meanwhile I am very wary of drawing new distinctions and privileges.

Finally, there's the aspect that quick ratings will inevitably be superficial. If an article about haplotypes is riddled with errors you might have to sit down for half an hour and review multiple papers to get an inkling of it. If a woman in a painting is naked, a random reader might complain in seconds. So I wouldn't want to take any results coming out of such a system very seriously. Wnt (talk) 01:59, 7 January 2019 (UTC)

• Alt suggestion. We have lots of talkpages that few if any editors are looking at, I know this from the number of queries that I have scattered round the project. It would be good to have an AI or something that listed article talkpages with open queries by wikiproject or by time since query raised. Having lists available of such pages would be useful, need not be obtrusive, and if the query has been resolved by editing of the article without updating the talkpage it should be simple for anyone to add {{done}} to the section. ϢereSpielChequers 14:10, 7 January 2019 (UTC)

  This can be done simply by reviewing e.g. Special:Recentchangeslinked/Template:WikiProject Video games. --Izno (talk) 16:09, 7 January 2019 (UTC)

  That's a neat trick, I didn't know that, and I can see it does part of what I suggest. But only part, it risks being swamped by article assessment, tagging for other WikiProjects and other edits. I am sure it would work for the enthusiast who is here more than once a week, but I was thinking more of the person who pops by once a month, or the person exploring a long dormant Wikiproject. Being able to list talkpages with outstanding queries would be useful in such scenarios. Though I suppose you would need to be able to swerve some off your WikiProject and onto more relevant ones. ϢereSpielChequers 21:32, 7 January 2019 (UTC)

• No - We're here to improve and build upon our encyclopedia ... not flaff around dictating what talkpages are healthy and what ones aren't, Solution looking for a problem is what this is. –Davey2010^Talk 21:25, 7 January 2019 (UTC)

• This doesn't make any sense at all to me, as there is no definition of "health" and no guide to what the 1-5 scores actually mean, as the definition of "health" is apparently up to individuals to decide for themselves. It's trying to quantify something, but without an objective definition of what that something actually is, any score would be utterly meaningless. Also, the idea that rectifying "bad health" should be a job for admins suggests the proposer does not understand the role of admins. Boing! said Zebedee (talk) 14:45, 13 January 2019 (UTC)

• • As a proposal for a data gathering system this isn't a direct solution to a problem per se, but if it were framed that way you could consider it thusly:
    • In addition to community feedback being mostly discussion based and therefore difficult to assess and quantify, our current system of assessing feedback doesn't allow for feedback from people who don't want (or no longer want) to contribute to discussions. People can't just engage briefly and then tell us what they thought of that experience. This means we disproportionately hear from people who take the time to repeatedly voice their opinion. Essentially we have one thing. We do not have the other. I think we should have both.
    • Mass down voting, an absence of voting, an abundance of voting are all indicators of community behavior, which would be visible via this system. 100% Accurate voting by genuine editors is neither possible or desirable in such a system.
    • Assessment of the data collected would lead to insights on popularity, areas of conflict and ways of dealing with it, which we have not yet considered. Among these would be a time based approach to rating community health, which could give an indication of health over time - giving us insights on the effectiveness of other initiatives aimed at improving user experiences.
    • Therefore in a nutshell, the problem is that we don't have a means of collecting generic data regarding the health of community experiences, and I am proposing a means of collecting it

I don't want to sell this any more than I have, so I will end my proposal by saying that in the (seemingly likely) event that this proposal is rejected, that we should consider ways in which Wikipedians tell us about their experiences and consider whether or not our current methods unduly exclude those who have an opinion but do not have the inclination to openly share it on our discussion pages. Hopefully the consideration of this point will lead to improvements on the proposal, or yet better ideas. Sorry about all the bold text but I really wanted to make a couple of points stand out.

Edaham (talk) 02:11, 7 January 2019 (UTC)

If people are not willing openly to express their opinions then they have no particular right to a voice here. One of the key points of Wikipedia is collaboration, and secret voting is not the way to achieve that. Hence, just about the only things that are secret here are ArbCom voting and legally protected information (eg: checkuser).

Your proposal seems like an even more extreme version of the oft-derided "friendly space" in its attempt to mollycoddle people. Real life is tough, real life needs interaction (unless you're a hermit), and real life involves disagreements: you have to stand up to be counted. In any event, both the method and the underlying theory of this proposal are fatally flawed, as others have pointed out. - Sitush (talk) 13:34, 7 January 2019 (UTC)

arriving a bit late to the party aren’t we? Come to help clear away the styrofoam cups? Voting (for something) and collecting survey data aren’t the same thing. Not really connecting is it. Edaham (talk) 15:53, 7 January 2019 (UTC)

Do what? Did you see my comment above of several days ago? Not late to anything. I understand you may be pissed that your proposal is being shot down but there's no need for that. If you can't see the problems with your proposal now, you probably never will. However, I was responding to you clarification: letting people complain anonymously (and, believe me, that is what you are proposing) isn't helpful. If they have a problem and want it fixed then they need to engage: shit or get off the pot. - Sitush (talk) 16:09, 7 January 2019 (UTC)

Just wow. Nice take down! You won Wikipedia! Im not pissed at all. Incredulous is the word. Surveys aren’t unusual in large projects, where it’s easy to gather large amounts of data. Wikipedia doesn’t really have customers, so the concepts typical to customer satisfaction might be a bit alien. I get that. Do you have an alternative suggestion? Although I think the proposal and its ramifications have been misunderstood somewhat I can understand the concerns raised. I’ll have think about it and resubmit an idea when it’s brushed up a bit. Edaham (talk) 16:33, 7 January 2019 (UTC)

No alternative suggestion because, as I said at the outset, I think you're trying to find a solution to a problem that does not exist. Just because surveys can be done does not mean that they should be done. And if you hadn't got stroppy with me, I wouldn't have retorted in similar vein. - Sitush (talk) 16:46, 7 January 2019 (UTC)

I assumed that was friendly and cheeky banter. I didn’t feel like you were being stroppy. A very interesting word actually with a murky etymology. To say, in a “strop” further mangles it because it then shares a pronunciation with a word for a piece of sharpening leather, with an unrelated etymology to the original word, which is synonymous with irksome. Probably a discussion for elsewhere. The reason this particular survey ought to be done is because if such data were pouring in, reviewing its change over time could be used to gauge the effects of other initiatives. Working out whether or not something we put effort into had a desired effect is a job, which ought to be done because it will divert us from wasting effort in the future. If we reduce the purpose of the discussion to that salient point and build up from there we might come up with something better. I say we, because I’m an optimist at heart and believe that with a little more warming you’ll come around to the edaham camp eventually. Edaham (talk) 17:01, 7 January 2019 (UTC)

This is getting at a real problem (low-traffic talk pages), but since the beginning, we've been less about voting and more discussion and consensus. Good principle, bad execution. The best way to make inactive talk pages active is to post notices elsewhere about discussions that are active or things editors want to bring attention to. - PrussianOwl (talk) 23:08, 8 January 2019 (UTC)

probably due to the way I originally framed the idea, my fault, we are having a really really hard time getting past the idea of voting. This isn’t voting. People vote for an outcome, as in will we have custard or ice cream for desert. This isn’t voting. It’s not. It’s not voting. The intention of the idea is that we have other schemes to improve community health. We don’t actually gauge (except by looking and judging) if they are having a positive impact. (Or do we?) If people are able to contribute marketing data at a roughly constant rate, we can measure that rate to see if our initiatives had impact. We’d be looking to find correlation between the data we obtain, and the things we are doing to improve the place. There’s lots of ways of doing this and the thing I’ve suggested is rudimentary and roughly sketched to the point that it has scuppered the idea apparently.

I mean you could probably just find correlation between community health initiatives and the frequency of the use of the “retire” template and the use of obscenities on talk pages, so this certainly isn’t the only way of handling things. People already contribute lots of data which reveals their general satisfaction, via their lexical input and the parsing thereof.

Also, on a side note, I let a friend of mine look at my comments and replies, which I made in a lighthearted and humorous spirit, and they said that given the nature of the conversation I’m probably coming off as grumpy and flippant. Sorry if that’s the case. Believe me I’m very happy to have the opportunity to contribute ideas in this forum! Edaham (talk) 02:40, 9 January 2019 (UTC)

Divide "Village pump" tabs into "Policy/Policy history", "Technical/Technical history", "Proposals/Proposals history", "Idea lab/Idea lab history", "Miscellaneous/Miscellaneous history". This would save a "click" when reviewing the various subdivisions of the Village pump. There would be no need to repeat the terms as I am doing now for illustration purposes only. And in fact the terms could be stacked vertically to save space, with the name "history" below the name of the tab. Bus stop (talk) 15:20, 14 January 2019 (UTC)

This would save a click for what? What are you trying to access? --Izno (talk) 17:54, 14 January 2019 (UTC)

"What are you trying to access?" I would be trying to access the history of a given subdivision of the Village pump. Let us say I was interested in developments at the Policy subdivision, the Proposals subdivision, and the Miscellaneous subdivision. Rather than click on Policy and then history, I would simply click on "Policy-history", saving a click. Bus stop (talk) 18:15, 14 January 2019 (UTC)

This is silly. Personalize your own view or enable popups so you can hover over the names at the top and access the history without navigating to another page. Killiondude (talk) 19:05, 14 January 2019 (UTC)

Thank you, Killiondude. I enabled popups. That is cool. I was not aware of that. Bus stop (talk) 19:18, 14 January 2019 (UTC)

Followup. I turned it off. It is annoying. Bus stop (talk) 21:18, 14 January 2019 (UTC)

  Resolved

My proposal is, after rolling back a user's edit, automatically open their talkpage. I know there is WP:Twinkle but that is not automatically work/open talk page. There are no features in preferences. If there are any Java scripts or features, then it will be very help for rollbackers. Thanks, Siddiqsazzad001 <Talk/> 09:00, 14 January 2019 (UTC)

@Siddiqsazzad001:   Done Script made. After rolling back a user's edit, open their talk page. Doesn't work if you have a script installed to require confirmation before rolling back. See User:DannyS712/Rollback talk --DannyS712 (talk) 09:27, 14 January 2019 (UTC)

@DannyS712: Thanks dude! It's working. I am the first user who used this script. :) Siddiqsazzad001 <Talk/> 14:58, 14 January 2019 (UTC)

Should I give you an award? :P ―Abelmoschus Esculentus (talk • contribs) 15:03, 14 January 2019 (UTC)

@Abelmoschus Esculentus: Me? or Siddiqsazzad001? idk... --DannyS712 (talk) 16:54, 14 January 2019 (UTC)

Nah just joking with Siddiqsazzad :) ―Abelmoschus Esculentus (talk • contribs) 23:12, 14 January 2019 (UTC)

@Abelmoschus Esculentus: Absolutely. They deserve an award for having such a great user script idea... --DannyS712 (talk) 23:54, 14 January 2019 (UTC)

• I'd like to leave a comment here that I started a discussion to list "spinning out the core admin toolkit" at WP:PEREN. Please take a moment to review and/or help with the homework to add it to the page. --Izno (talk) 20:49, 22 January 2019 (UTC)

Often first-time editors have trouble knowing the guidelines behind the specific subject they are editing. For example an inexperienced user may not know the general guidelines behind WikiProject Schools (usually don't list administrators below senior level, and don't include the text/lyrics of the school/fight song), and so he or she may do a faux pas. I suggest finding a way to display a convenient link to the topic-specific guidelines for a particular article when any user edits the page. So if Johnny edits an article about anime, he sees a link to the guidelines. Or when Susie edits about her high school, she sees a link to its topic-specific guidelines. It may also help for each sett of guidelines to have an "in a nutshell" before the nitty gritty details. WhisperToMe (talk) 03:46, 8 January 2019 (UTC)

I think Wikipedia:Editnotice already does that. It can display links and short note as you're suggesting and is active atop editing pane on any page where it's activated. –Ammarpad (talk) 06:19, 8 January 2019 (UTC)

If there's a way to automatically append an editnotice for any page tagged with a certain WikiProject tag (so instead of having to manually add an edit-notice to every relevant page, it gets automatically added), that would be great. WhisperToMe (talk) 10:22, 8 January 2019 (UTC)

This is done for BLPs and disambiguation pages through MediaWiki:Common.js; you'd need a consensus that a particular category of articles should display a notice. Galobtter (pingó mió) 13:56, 9 January 2019 (UTC)

Thanks for the tip! I went ahead and notified the Schools WikiProject: Wikipedia talk:WikiProject Schools#Add pagenotice with project guidelines (guidelines on how to make a school or school system/school district article) for all pages in the WikiProject? WhisperToMe (talk) 12:54, 10 January 2019 (UTC)

Also notified Anime and manga, China, and Japan WhisperToMe (talk) 05:57, 11 January 2019 (UTC)

• @WhisperToMe: There are few issues here which you may not be aware of, this is not as easy as it looks. To my knowledge only BLPs and Disambiguation pages have such notice injection via Common.js, and they're the exception rather than the norm. First of all, for that to be implemented to set pages, they need to have a master category where all members are directly in irrespective of any other categorization: See how Category:Living people and Category:Disambiguation pages are. This currently does not exist for schools. Category:Schools holds subcategories not the articles themselves. You need to have consensus to change that first.
  Second, editnotice of pages in Category:Living people is showing a core policy while that of Category:Disambiguation pages is showing a disambiguation guideline with wide acceptance, both are not WikiProject notices, you need to make a strong case why a single WikiProject should've this and what if other WikiProjects come forward requesting same. This is assuming you surmounted the first problem about Category:Schools. –Ammarpad (talk) 07:03, 14 January 2019 (UTC)
  • Thanks for notifying me of the programming issues. I wonder which Wikipedians have the most experience with this sort of thing.
  • I feel WP:Schools needs this because the projects editors have agreed on various content guidelines (such as in Wikipedia_talk:WikiProject_Schools#Request_for_comments:_What_administrators_to_list_on_school_articles, which was done because people keep adding long lists of school administrators to articles) that are intended for all articles in the project scope and enforced by project members, but without a notice displaying on the editing screen, drive-by editors and first-time editors won't know about any of these: they only see the common notice displayed at the bottom. Then they might be surprised or upset when their changes are reverted. They may not even be individually notified on their talk pages; while there might be a revert that does state who made the change, they may not be aware of the commenting system (using four tildes), and they may not understand how to approach the other editor. They won't know about the project guidelines as they may not even know what a WikiProject is. Telling the user this information in personalized talk page messages is the only way in which they can be expected to learn about it. It's important to consider the position of a person highly inexperienced with Wikipedia.
  • Project members themselves may dislike making multiple reverts of low-quality content, with low-quality partly due to falling afoul of agreed guidelines. While notices will not stop determined vandals, cutting down on low-quality edits would lessen administrator workload and project user workload. Freeing up administration means there's more time to do content creation; I had proposed to the others checking school attendance boundaries and matching communities (cities/towns/neighborhoods) with schools, but another editor gently reminded me that most of them were focused on administration stuff and that I would likely be alone in this task.
  • WhisperToMe (talk) 07:13, 14 January 2019 (UTC)

• OK, the proposal can go ahead here on VPR or on that talkpage, since the issues to discuss are now clear.–Ammarpad (talk) 07:59, 15 January 2019 (UTC)

See Template talk:Infobox comedian#Convert to wrapper. Comments invited. Thanks Capankajsmilyo^{(Talk | Infobox assistance)} 02:51, 16 January 2019 (UTC)

Non-free files today will eventually enter public domain. When that day comes, they are supposed to be transferred to Commons. I propose that Wikipedia should set up a standard procedure for such files, and there should be a few tweaks to current procedures to help this process in the future. Here is a list according to my perceived priority:

1. User:Theo's Little Bot reduces size for non-free files, but currently there is nothing in place to track whether an image is shrinked, other than the file histories. I suggest:
   1. When Bot reduces a file, insert a short note in EXIF, saying something like image shrinked by bot. I think this is the best solution such that reduced images are earmarked. Should they be transferred to Commons, another bot, commonshelper, or a built-in MediaWiki functionality, could be developed to identify or block them based on EXIF. This measure should be adopted by all image-shrinking bots across all wikis.
   2. If 1.1 is not possible, alternatively, include all bot-reduced images in a tracking category.
2. Before transferring to Commons, the original high-res files should be restored and reverted to. This could be done by a bot with admin rights. Say design a Template:Restore for transfer. A trusted user (autopatrollers?) tagging a file with this will let a bot restore all revisions and revert to the first version, which should be the best for most files. (A non-trusted user's tagging would be ignored, or reverted by the bot.) A note should be put up nonetheless, to remind users of picking the best for transfer.
3. There could be something to track when and where a file was made. An anonymous photo taken and published in USA in 1930 would probably enter PD in 2026. This something can help the transfer process by then.--Roy17 (talk) 01:01, 10 January 2019 (UTC)

Keep in mind that most editors that upload non-free already start with reduced image, there is no "old" version at the original resolution to go back to. Additionally, remember that commons wants works that are PD everywhere, and that requires a bit more knowledge about the origin of a work than our current systems allows. I'm all for some bot to tag potential non-free into a human-reviewed list as "Possibly now PD" and have humans do that work after checking things, but definitely not a bot do all the work. --Masem (t) 01:11, 10 January 2019 (UTC)

Also on your point 1, the file history will show the bot reduction. We don't need to add anything to an EXIF (and not all files will have an EXIF). --Masem (t) 01:11, 10 January 2019 (UTC)

I am aware of that. Still we could do the little thing to foolproof any bot-reduced images ending up on Commons. If a reduced image were transferred and an enwp admin deleted the local page, almost no one from commons could verify whether the file had been reduced. I have seen many cases of users transferring files (early wiki uploads, textlogos etc.) by downloading a scaled down preview from local wikis and uploading on Commons manually, such that local admins have to do the proper transfer again before deletion. This will certainly happen with bot-reduced non-free files. I believe it is best to mark the reduced images themselves, whether in EXIF for jpg and tif, or as some other forms of embedded codes, or a watermark. The marking must be machine readable. This lets Commons reject files straight. A template message could also be added to current local file pages to warn of reduced images. The more precautions taken, the less likely we make mistakes.

Many images would stay on local wikis for a long time until they enter PD. External sources often become 404 not found in the wait. The best version is of course an external original, in case the wiki one had been edited. But if the wiki one were the one to be transferred, the largest is the best.

I did not suggest a fully automated restore and transfer. The bot only does the restore part. A file could well be fair use for 150 years before entering PD. (Say a 20yo photographer takes the only image of a deceased person and lives to 100, and the rule of life+70 applies.) The original year does not really imply the actual PD date, but such extreme cases are not common. Many files should enter PD the latest 120–150 years after creation. Wiki editors in 2020s and 2030s will soon have to handle files from 1920s and 1930s. It will become a regular maintenance task in future. Some sort of preemptive cataloguing should be beneficial.

I believe this is something that should be implemented across all wikis, but I post here because enwp is the most active and attended by most tech-savvy users.--Roy17 (talk) 04:02, 10 January 2019 (UTC)

To determine copyright status of a file, the following parameters are the most essential: authorship/copyright claimant, year created, year published, and countries of origin. Here is my invention on yuewp, tweaking {{information}} and creating two templates, that categorise some uploads into cat:files created in YYYY or before: yue:special:diff/1246619, yue:t:before and yue:t:between.--Roy17 (talk) 04:19, 10 January 2019 (UTC)

I don't think a bot should mess with the files themselves other than reducing their size but what harm would there be in having Category:Non-free files that were reduced by a bot or similar? Additionally/alternatively, I think it would be good if the bot that resized the image added a template that says "This file was automatically resized by a bot and previous versions deleted per F5. If you believe the resize was in error, you can request refund..." or something like this. Then you could track these files through the template's transclusions. Regards SoWhy 11:36, 10 January 2019 (UTC)

• Template:Do not move to Commons already includes a field for expiry, which then adds the file to Category:Media now suitable for Commons. Problem is, not that many people seem to use it. Having a bot that undeletes original higher resolution files for transfer seems fine, so long as the bot also immediately PRODS the file, meaning if the file is not transferred in seven days, and the PROD replaced with Template:Now Commons, then the old revision should be automatically re-deleted. It also should merely restore the previous version, not revert to it, so that in the meanwhile we are still using the low-resolution version under fair use in our articles. The reversion should need to be done by a human prior to transfer. Also, the only user group we have that is specifically related to competency with files is file mover. So that's the only group where it would make sense to have an undelete-by-proxy option. GMG^talk 12:00, 10 January 2019 (UTC)
• Very few of these non-free files are about to have copyright expiring soon. Also it is not Wikipedia's job to archive these files. Instead we should explore other archives that will have stored the files (legally), and be ready to copy those copies once it is copyright expired. Also the bot will not know why a previous file was not used. There may be errors, or other quality issues. So manual intervention would be needed. For non-free files often there is not eough information to determine copyright expiry either, as original photographer and country are often missing information. Graeme Bartlett (talk) 02:58, 11 January 2019 (UTC)

I certainly agree with #1 (easy tracking), but not with the rest. Keep in mind that deciding when an image becomes PD can be complicated some times. In stead, allow users who believe that a specific image is already in the PD, or will be there within a month (or perhaps a shorter period), make a request about that individual image. עוד מישהו Od Mishehu 13:11, 13 January 2019 (UTC)

Following the new development of FileImporter, we are now able to transfer all undeleted revisions to commons directly. The part of reverting to the original can be dropped, because this can be done on Commons after successful transfer.--Roy17 (talk) 17:21, 16 January 2019 (UTC)

Please see a proposal discussion at Wikipedia talk:Requests for permissions#Proposal:_Bot for outreachdashboard.wmflabs.org creations regarding adding a service account for the outreach dashboard account creation workflow. Thank you, — xaosflux ^Talk 15:20, 17 January 2019 (UTC)

Recaptcha 2.0 allows a one-click verification that will speed up editing and publishing. Look into it at [[2]]. Thank you. --Whatever Floats your Zel! (talk) 18:47, 17 January 2019 (UTC)

@One Blue Hat: See Wikipedia:Perennial proposals#Use reCAPTCHA for why this has been rejected in the past. --DannyS712 (talk) 18:55, 17 January 2019 (UTC)

@DannyS712: Gotcha, makes sense. --Whatever Floats your Zel! (talk) 19:10, 17 January 2019 (UTC)

Previous discussion at Wikipedia:Bot requests/Archive 78#Auto-archive IP warnings

I imagine it's fairly confusing for IP users to have to scroll through lots of old warnings from previous users of their IP before getting to their actual message. We have {{Old IP warnings top}} (or {{wan}} or {{ow}}, but that can be bikeshedded about later), but it's rarely used—thoughts a bot to automatically apply it to everything more than a yearish ago? Gaelan 💬✏️ 19:49, 11 January 2019 (UTC)

• Support I don't think IP warnings need to stay up more than a few months. In my experience, vandalism from IPs comes in bursts that rarely last more than two days (probably because of blocking).
• I think this is a good idea. No opinion of length of time I thought a year was too short but who knows. Technically it would work like an archive bot but instead of archiving to a sub-page, it would archive to within the top/bottom portion of {{Old IP warnings top}}. It would look at the most recent post within a section to find the date, and if that section leads off with a warning. There are ways for things to not go right like if a warning is not within a section and has followup posts etc, so this would not be a perfect solution more of a best-effort, if it can't understand the formatting it leaves alone. -- GreenC 20:09, 11 January 2019 (UTC)
• I don't think its a great idea to send a bot around to chase all these. However, I'm assuming most of these warning etc are coming from tools like Huggle/Twinkle/etc - if so, approving a general concept that "archiving old (time to be determined) IP talk warnings to history" is allowed - these tool systems could add that functionality to their warning routines. — xaosflux ^Talk 20:21, 11 January 2019 (UTC)
• Support - Having looked at this for a few examples I'm surprised to see a lot dating back to 2006 ..., I personally would say warnings should be archived after a year and a half from when they were left, 2-3 years seems too excessive and just a year seems too short, –Davey2010^Talk 20:24, 11 January 2019 (UTC)

I imagine most IPs people edit with are dynamic ones that don't last all that long, but I have no idea. Gaelan 💬✏️ 20:50, 11 January 2019 (UTC)

• There's some previous discussion here here here and here, and in fact several other places which people should probably look at before anything. There's been more than one bot (and editors like BD2412) already doing this at various times. As with anything there's going to be some complicating factors: if it's anything recent the IP should probably not be actively or recently blocked, range blocked, or globally blocked. The bot probably shouldn't archive or blank sockpuppetry tags, whois tags and shared IP templates, and probably shouldn't blank spam-related backlinks, some custom notices, and intelligible non-warnings, IMO. I don't think the question is whether it should be done, as it's something that's been done for a long time, but the bike-shed details which were avoided in the proposal. And of course who is going to write and run the bot. Personally I think as a general rule a year is probably too short. (should probably also ping Dirk and Petrb). -- zzuuzz ^(talk) 21:43, 11 January 2019 (UTC)
• Support. I have previously requested a bot for this and the conversation died out with no one taking it up. As with others in this discussion, I would propose very specific limitations, those being that all discussions older than five years be removed from the page so long as the IP has not been the subject of a block within the past two years. Personally, I have been blanking tags if the page is pre-2010s, because IP addresses can be reassigned in that length of time - and even if they are not, Wikipedia is not a permanent directory of IP addresses. bd2412 T 22:15, 11 January 2019 (UTC)
• Comment the more complicated the policy, the more time consuming becomes writing and running the bot, the less chance anyone will take up the project, the greater the chance it never happens. -- GreenC 22:39, 11 January 2019 (UTC)
  • Well then let's start with something easy, that everyone can agree on, like ten-year-old warnings. bd2412 T 04:38, 12 January 2019 (UTC)
    • That's how you do it. Start with something conservative and uncontroversial. Proof of concept for everyone to see. Once the bot is approved and running, taking it to the next step is considerably easier. Trying to build a complete castle from day 1 is probably an over-reach technically and with the community. -- GreenC 00:41, 27 January 2019 (UTC)
• Comment Thoughts on this as a starting point?
  • When an IP user makes an edit… (no point in making a ton of spam cleaning up inactive users' talk pages)
  • If the IP has had no activity in the past 3 years… (activity = contributions, receiving talk messages, being blocked, even if the block was issued >5 years ago)
  • If the talk page consists only of templates from a whitelist… (for starters, uw- templates, along with their ClueBot and Huggle variants, and the Shared IP Notice Twinkle uses)
  • Wrap the talk page in {{Old IP warnings top}}.

It's super conservative, but would cover most cases and we could expand it in the future. Gaelan 💬✏️ 05:03, 12 January 2019 (UTC)

• Support archiving any notice that's more than a year old. That doesn't include "school" notices and similar, or any block notices that are still in effect (e.g., hardblocked IP addresses). Would also recommend removing 100% of sock tags on IP addresses that are more than a year old, even sooner if it's a known dynamic or mobile phone IP. These warnings and tags are quite likely to scare away potential new users, and serve little to no useful purpose for the administration of the project. Risker (talk) 05:36, 12 January 2019 (UTC)
• Oppose as is I'm with User:Zzuuzz here. @Risker:, I think a year can be too short. I'm not sure we can get one size fits all. Doug Weller talk 13:08, 12 January 2019 (UTC)

  I'm sure it can be done with a little preparation, but yes I think just blanking pages after a year is probably a bit too much. If we're to start going after the low hanging fruit I'd probably go with something like Gaelan said above: No activity for 5 years, no talk page history for 5 years, and only automated warnings in the history. Five years is again super conservative, but it's about the longest block you'll see and it's probably a good starting point for a general rule. I know BD2412 has complained about the backlinks before, so I don't know if wrapping the warnings would be as helpful as just blanking them. If it could (or would) be fitted into existing tools for when an IP edits that would be useful, but I don't really see any problem with a bot doing it on a schedule. My main concern really is just blanking what could be useful notes or discussions which can help understand edits made years earlier. Some may dismiss this stuff as some sort of waste of space, but historically I think it can be really useful. -- zzuuzz ^(talk) 14:53, 12 January 2019 (UTC)

  Yes, backlinks have been one of my main concerns because sometimes an editor needs to get an accurate sense of what is linking to a title from all namespaces, and a bunch of IP talk page links just muddy that view. We should not keep these in any form longer than is necessary to pass on the message to the IP about them. bd2412 T 17:30, 19 January 2019 (UTC)

• Comment As I have stated before, I have no problem with archiving or even blanking of old warnings/remarks. I have a problem with outright deletion of old-IP talkpages, which is something that should NEVER be done.

In my view, there is no issue with archiving (or even blanking) anything (like regular archiving) anything on a shared IP (yes, I know, detection) after even 2-3 months, and anything on a static IP (that has not been used for over 1-2 years). I would prefer just archiving everything as that leaves tracks better visible and avoids having to select what not to blank.

To reiterate my reasoning: plain vandalism on an IP is untraceable to a person. But any form of systematic vandalism (most specifically spam, but also socking, strong COI, string single-purpose editing) is always done by a certain person (/organisation). The IP is changing, the person/organisation is not. Say Mr. X. is spamming www.mrx.com to a page using IP 1.1.1.1 and we give them a level 1 warning that they should not do that, and Mr. X. is coming back 1 hour later using IP 1.1.1.2, he technically deserves a level 2 warning, not another level 1 warning. It is, obviously, the same person. Some spammers rack up 10 level-1 warnings because no-one notices that they are actually spamming. On the spam blacklist that is still enough to say 'they do not listen, we tried to warn but warnings do not arrive'. Regarding age of that: if Mr. X. in 2009 spams a handful of times (on IP 1.1.1.1), racks up a level-4 warning and stops .. and comes back in 2019 starting (on 1.1.1.2) to rack up a handful of warnings, it is still the same physical entity spamming (unless the domain changed owner, which can be seen). They may expect that rules have changed on Wikipedia, but 4 warnings in 2009 and an unheeded level-1 warning in 2019 could be enough to just blacklist to stop further disruption (on 10 years we will likely be a bit softer ..). If such user talkpage is deleted, the track of 1.1.1.1 is lost. However, we can see far back that 1.1.1.1 has spammed the same site, but without the talkpages it is very hard to detect (you need admin rights, seeing that there are deleted revids on the page). (note, we have cases where companies/entities are spamming for 8-10 years, it appears a long time, but it is not). --Dirk Beetstra ^{T C} 05:31, 13 January 2019 (UTC)

• Is there a reason why we cannot simply add an existing archive bot with a 1-year or 2-year archive time to every non-blank IP talk page that contains material older than 1 or 2 years? If I do this manually when I add a warning to an IP talk page, is there a preferred bot? --Guy Macon (talk) 16:24, 13 January 2019 (UTC)

• It would need to run from the expiry of the last block, not the time the warning was left—if an IP has been unblocked after a long period (e.g. a year-long block as a believed open proxy) and within minutes of the block being lifted the problems resume, we obviously want to know the background. I'm sure it wouldn't be difficult to code a bot to do this, but one of the existing bots couldn't be used off-the-peg. ‑ Iridescent 16:34, 13 January 2019 (UTC)

• Support whatever the details, this is a good idea. Headbomb {t · c · p · b} 06:08, 14 January 2019 (UTC)
• I like the general idea, assuming "archived" means archived and not just blanked. I also wonder if, as opposed to a bot, it wouldn't be possible to add some sort of function to existing tools such as Twinkle to semi-automate use of {{old ip warnings top}}, which doens't archive but does collapse old warnings. we could leave it up to the best judgement of the warning user, as it is now without any new policy. Beeblebrox (talk) 18:44, 19 January 2019 (UTC)

• Tentative support. I quite like the idea of modifying Twinkle, Huggle, et al. to automatically collapse old warnings when issuing new ones, since those tools are how a great many warnings are issued in the first place. Novusuna ^talk 22:08, 21 January 2019 (UTC)
• Support modifying Twinkle, Huggle etc. If we run a bot to do this, we should take into account that this will pop up as "You have a new message" for the IPs in question, which might be a little confusing and definitely counterproductive for users with dynamic IPs. Daß Wölf 23:40, 26 January 2019 (UTC)

An RfC is underway that includes a proposal, and a discussion (that interested "watchers of this page" wound enhance by participating) I hope that many will! The discussion is located at Wikipedia talk:Twinkle#RfC regarding "Ambox generated" maintenance tags that recommend the inclusion of additional sources. Thank you.--John Cline (talk) 06:10, 29 January 2019 (UTC)

The thread about the Reference Desks that was moved to a subpage seems to have about run down. Is it going to be brought to a conclusion? --76.69.46.228 (talk) 08:55, 23 January 2019 (UTC)

The discussion still seems to be active with people posting today as well and the default time for an RFC to stay open is 30 days, so there is still time. Anyone is free to request a close by uninvolved editors at WP:RFCl once the 30 days are over although this probably needs closing by a larger number of experienced editors. Regards SoWhy 12:04, 23 January 2019 (UTC)

Sorry, I didn't realize there was a default duration. --76.69.46.228 (talk) 20:50, 24 January 2019 (UTC)

Okay, we're now past 30 days (and on the relocated thread it's also being suggested that it's time to close it). Now what? --76.69.46.228 (talk) 07:58, 30 January 2019 (UTC)

It is already listed at WP:ANRFC but I would not hold my breath for a timely closure on that one. It is a very large discussion with many proposed options. The main policy question (shut down the whole thing or not) is little more than a show of hands (no real discussion / consensus-building). I would commend anyone extracts actionable information from that mess, but sometimes, RfCs simply fail... Tigraan^{Click here to contact me} 08:17, 30 January 2019 (UTC)

• EN: Dear colleagues, please comment on CentralNotice banner proposal for Public Domain 2019 Russia uploads & article contest. (18 February - 31 March , all IPs from Russia, Wp/Ws/Commons, 1 banner impression per two weeks). Thank you. JukoFF (talk) 15:02, 30 January 2019 (UTC)

Following a request at WP:SCRIPTREQ on the advice of Enterprisey, the awesome DannyS712 and Danski454 have respectively written a script and a module to automate large portions of {{2nd chance}}. I'm particularly interested in using the user script, as it automates away a large portion of the technical/legal steps in {{2nd chance}} for the new users who receive that template. I'll be sending DannyS712 some requested changes to the script, but it's just about at the level I'd like to test it on real unblock requests.

I'm here to ask for consensus to do a limited trial of this script on real blocked users. In particular, when I would've otherwise used {{2nd chance}}, I'd like to add this user script to the user's common.js and notify the user on their talk page how to use the script. The trial will last until three users have used this user script to request unblock for a second time after their unblock request was declined as {{2nd chance}}. Because this requires directly editing another user's common.js, I'd like to get the community's sign-off before doing this test. Best, Kevin (aka L235 · t · c) 19:33, 21 January 2019 (UTC)

@L235: I wanted to test the user script out on myself over at test wiki, and asked for admin and iadmin (there, not here) so I could block User:DannyS712 test and try it from that account, and be able to edit any bugs that come up. I'd prefer to do that before we start editing the common.js of a blocked use. @Xaosflux: declined my request for permissions, directing my to one of the wikis dedicated to messing around with admin powers, but if this is going to become a tool that blocked users have installed then I hope that they will reconsider. --DannyS712 (talk) 19:37, 21 January 2019 (UTC)

@DannyS712: Open an account at the beta cluster and I'll get you the testing permissions. Based on a couple tests I did here, though, it seems like it works well enough to test with a few users here. Kevin (aka L235 · t · c) 19:40, 21 January 2019 (UTC)

@L235: See your talk page --DannyS712 (talk) 19:50, 21 January 2019 (UTC)

• Ummm....you're looking for permission to forcefully add personal javascript to other users, and citing legal requirements, and this script appears to also include import scripts from other users - if so, I'm really strongly opposed to this for security concerns alone. — xaosflux ^Talk 21:33, 21 January 2019 (UTC)

  @Xaosflux: I'd be happy to, once I iron out the kinks, have it moved to the mediawiki space so that I can't edit it. The only thing my code imports is another function of mine, which likewise can be moved. We already add javascript for other users (common.js, skins, etc) under the belief that it is secure if only iadmins can edit it, which would be the case with this script once its moved. I'd don't see how this creates any new security concerns, given that this would be limited to 1) users already told to attempt a "second chance" and 2) makes no edits without being activated by the user and 3) the code itself is (imo) pretty easy to read and see that it has no hidden edits --DannyS712 (talk) 21:41, 21 January 2019 (UTC)

  Common scripts (such as vector.js, common.js) are not just secure because their write access is severely limited, but because they are highly visible (i.e. highly watchlisted). Significant changes to such pages generally undego a propose/review/execute/monitor process for each edit. Forcing changes in to arbitrary User:username/common.js files would also require that everyone who will participate in this process become an interface administrator, contrary to one of the goals of reducing this access. — xaosflux ^Talk 21:51, 21 January 2019 (UTC)

  @Xaosflux: Alternatively, every time a blocked user has an unblock request declined as 2nd chance, a note is put somewhere (a dedicated page, iadmin noticeboard?) which user it is, and then a pre-existing iadmin can add the one line of code to that user's common.js (importScript ( 'MediaWiki:Second chance.js' );) or something like that. --DannyS712 (talk) 21:57, 21 January 2019 (UTC)

  We can also package it as a gadget of some kind if the concern is not having the user's consent, but I'd expect that would take considerable texting testing Kevin (aka L235 · t · c) 00:59, 22 January 2019 (UTC) beforehand. Best, Kevin (aka L235 · t · c) 22:27, 21 January 2019 (UTC)

  @L235: Testing? --DannyS712 (talk) 22:30, 21 January 2019 (UTC)

Hi. Until I can test this out at the beta cluster, I don't think its ready for even a discussion about inclusion. Thus, this should be put   On hold until phab:T212327 is solved, since I need to be able to confirm my accounts there. --DannyS712 (talk) 04:23, 22 January 2019 (UTC)

Though I think this is a bad idea as referenced above, it should be trivial to have your alt account load this to their own user.js and have someone block your account. — xaosflux ^Talk 04:46, 22 January 2019 (UTC)

@Xaosflux: I have added the script to "my" userspace on test wiki, and have the test account import it, so if beta isn't working can you please just block User:DannyS712 test on testwiki for a week? And, can you also give me importer there so I have a variety of pages to test the script with, to ensure that there aren't any bugs? --DannyS712 (talk) 06:31, 22 January 2019 (UTC)

We could make this into a gadget and add a line to the template asking them to enable the gadget and proceed from there. << FR ^(mobileUndo) 06:41, 22 January 2019 (UTC)

@FR30799386: I'd much prefer to see that type of mechanism. From a non-technical aspect, such a request should be an option to 'make it easier' for the blocked person, not necessarily the only way we would ever unblock them IMHO. — xaosflux ^Talk 12:30, 22 January 2019 (UTC)

@DannyS712: the block is made, importer is issued even rarer than interface admin (plus you would need to get a steward to do it) - feel free to copy/paste a reasonable number of test pages there and just mark for speedy delete when done. — xaosflux ^Talk 12:28, 22 January 2019 (UTC)

@Xaosflux: Oh, okay. Thanks --DannyS712 (talk) 16:17, 22 January 2019 (UTC)

@DannyS712: I'm not actually totally sure what the current concern is. Are you worried that your account on the beta cluster will be compromised? It's a testing site, there's no content on it and accounts can be easily locked in any case. @Xaosflux: What if we obtained the blocked user's consent before adding the script? Would that alleviate your concerns at all? Best, Kevin (aka L235 · t · c) 08:48, 26 January 2019 (UTC)

@L235: Its that I can't log in to the beta cluster with my test account at all. I've tested it a bit on test wiki, and will go do some more tests now --DannyS712 (talk) 09:02, 26 January 2019 (UTC)

@L235: Hey so I have a version 2.0 of the script that should work for beta testing on users that agree. Maybe we can ask if anyone is willing to be blocked for a day to try it? --DannyS712 (talk) 10:15, 26 January 2019 (UTC)

@L235: The idea above of publishing as a gadget, and telling the user to opt-in to it sounds best to me. Additionally, process wise: this should always be optional (i.e. tasks we want an editor to perform should be able to be done even without script assistance). — xaosflux ^Talk 15:50, 26 January 2019 (UTC)

DannyS712, I would just create a new testing account for now, and not worry about a specific name on a test cluster instead of waiting for that ticket to be resolved (which could potentially be a very long time). Feel free to let me know if you need any rights on the beta cluster. SQL^{Query me!} 16:08, 26 January 2019 (UTC)

@SQL: In that case, I have made a new account. For this (my main account), can you add admin and iadmin rights? Thanks --DannyS712 (talk) 17:28, 26 January 2019 (UTC)

DannyS712, Sure thing, done! SQL^{Query me!} 17:36, 26 January 2019 (UTC)

• Do people use this template that much anymore? I'm fairly active in CAT:RFU, and I don't think I've ever seen this used. {{decline reason here}} is what is used most often now, if a template is used, and most other times when 2nd chance is an option, you'll have a non-templated response. Not really a technical comment as much of a "are we discussing something that would ever be used?" TonyBallioni (talk) 19:00, 26 January 2019 (UTC)
  • I uss it quite a lot but feel guilty doing so becuase it's not actually that plausible for the new editors to follow the technical instructions. I'm sure if it's an actual option it'd be used more. Kevin (aka L235 · t · c) 19:34, 26 January 2019 (UTC)

  @TonyBallioni: Idk, I just make the scripts lol; maybe if we have this, more people would take advantage of a second chance? --DannyS712 (talk) 19:36, 26 January 2019 (UTC)

Yeah, I figured you used it since you brought it up :) I don't think I've seen anyone else use it, though. I was talking to SQL about it, and I honestly didn't know this existed before today because I've never seen it used.

From a practical standpoint as well, I don't think the language is that useful and if I were a blocked user I'd just give up on ever being unblocked if someone templated me with it, because its a wall of text and the message I'd get was We don't trust you. I don't think a script will change the fact that the template is really poorly designed/worded for the task it is intended for. TonyBallioni (talk) 19:40, 26 January 2019 (UTC)

@TonyBallioni: Well, if you look at https://en.wikipedia.beta.wmflabs.org/wiki/MediaWiki:Gadget-secondChance.js, I tried to soften the language. Of course, for some reason its not working on the beta cluster, but it does work on test wiki and stuff, so I'll try to troubleshoot the issue --DannyS712 (talk) 19:55, 26 January 2019 (UTC)

I mean, a block is probably a good clear message that "we don't trust you". How are we supposed to respond to appeals from, e.g., VOA blocks? 2nd chance gives a good middle ground between a straight unblock (it allows you to edit real WP articles, subject only to being posted to the user talk page) and a decline (it doesn't actually change the block). Kevin (aka L235 · t · c) 20:00, 26 January 2019 (UTC)

@L235 and SQL: hey. I've been testing it out more on the beta cluster and I've run into 2 issues so far. The first is dealing with captcha, which I think I solved. The second is abuse filters. Global rule 11 (https://deployment.wikimedia.beta.wmflabs.org/wiki/Special:AbuseFilter/11) prevented me from adding external links, but I'd like to be able to see what specifically it scans for so I can change my regex accordingly. I can't see it, because its marked private. Can one of you give me admin on the deployment page, so I can fix my script? --DannyS712 (talk) 20:18, 26 January 2019 (UTC)

L235, re: how are we supposed to respond: if it’s clearly a high school kid messing around I normally unblock on their word that they won’t do it again if the unblock request is reasonable. No need for identifying helpful content or whatever. If it’s an LTA who is claiming to be reformed, a deeper discussion than a template is needed, IMO. I don’t really see a situation where I’d support using the 2nd chance procedure outside of having someone explain how to add sourced content for an unsourced content block. Either it’s way over the top (high school kids) or not enough (LTAs). Blocks of “regulars” tend to be too complex for it as well. TonyBallioni (talk) 22:58, 26 January 2019 (UTC)

@L235 and SQL: So I read the private filter, and I think I found a work-around that will stop it from messing with my script:

"&! (user_blocked & page_namespace == 3)"

However, I can't actually test it, because the global filter requires "abusefilter-modify-global" to modify. I'm sorry to keep bothering you guys, but would you mind adding me to one of the user groups that includes this? See https://deployment.wikimedia.beta.wmflabs.org/wiki/Special:GlobalGroupPermissions for the list.

Thanks so much, --DannyS712 (talk) 23:32, 26 January 2019 (UTC)

DannyS712, Done! SQL^{Query me!} 02:30, 27 January 2019 (UTC)

@SQL, TonyBallioni, L235, and Xaosflux: see the newest version at https://en.wikipedia.beta.wmflabs.org/wiki/MediaWiki:Gadget-secondChance.js. I think this is ready for some testing. There is a current AN discussion about unblocking someone under the standard offer. Maybe see if they would be willing to try it? I'm not pinging them, since this would need IAdmin approval (among others) first, and since that editor is currently unblocked (but only to participate in the AN discussion), rendering the script useless (it only works if you're actually blocked in its current form). Thanks, --DannyS712 (talk) 00:52, 31 January 2019 (UTC)

Sometimes when I am editing a longer page or section, I like to drag the corners of the edit box to take up the largest amount of space that it can on the screen. This requires some maneuvering and adjustment. It occurs to me that others may also like to do this, so it would be nice to have a single button that automatically expands the edit window to the largest size it can occupy without going offscreen. Is this doable? bd2412 T 16:58, 30 January 2019 (UTC)

@BD2412: - YOU CAN EXTEND THE SCREEN?! Why did no-one tell me? I don't know about the proposal but the issue alone is enough to be helpful! Nosebagbear (talk) 17:42, 30 January 2019 (UTC)

Or shrink it, as the case may be, assuming that you're using the 2010-era mw:WikiEditor. Just drag the little triangular-ish lines in the lower right corner of the main editing window. If there's a particular size that fits well for you, then you can set that size in your personal CSS pages. (Check WP:VPT's archives for directions.) WhatamIdoing (talk) 04:06, 1 February 2019 (UTC)

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

---

The general consensus of the editors is for the establishment of a Current events noticeboard. However, there are also reservations for the purposes of redundancy with existing WP:ITN/C process and secondly, feasibilty and usefulness of the new noticeboard in actually being a net positive for the project. Editors in favour of establishment for such a noticeboard have also highlighted that this idea deserves an exploratory trial at the very least — this would also alleviate the concerns of some of the opposing editors, in my opinion, as they would have an opportunity of seeing how the noticeboard is working in real-time and formulate their opinion accordingly. Reading everyone's opinions, I am inclined to agree that a current events noticeboard will probably be net positive. Hence, we will run the formulation of the Current events noticeboard for a minimum trial period of 9 months extending upto 1 year, after which should editors object to the functioning of the noticeboard, they should raise the issue through an AN RfC. --QEDK (後 ☕ 桜) 08:46, 19 March 2019 (UTC)

RfC on the need for and implementation of a Current events noticeboard

Latest comment: 5 years ago73 comments37 people in discussion

Should there be a noticeboard about maintaining accurate information on article subjects in the news or which are related to current events? ―MJL -Talk-^☖ 22:54, 30 January 2019 (UTC)

Support

• Support, as Proposer. ―MJL -Talk-^☖ 22:55, 30 January 2019 (UTC)
  • Okay, now that housekeeping is out of the way; I can go into more details. According to WP:PNB, Noticeboards on Wikipedia are administration pages where editors can ask questions and request assistance from people who are familiar with the policies and guidelines covered by each individual board. As far as I am aware, there is no central place where users can go to ask questions specific to News and Wikipedia. For policies, guidelines, essays, etc. on the site we have: WP:NOTNEWS, WP:BREAKING, WP:NOTCRYSTAL, and WP:CAFET (just to name a few). Generally, items in the news see a spike in activity, and I feel it might be valuable to have a single place to go for editors to discuss issues, content, and consensus. What I am proposing specifically is something like Wikipedia:Biographies of living persons/Noticeboard as I feel Current Events lie somewhere in the intersection of many different discussion boards. I consider it best for us to attempt at higher standards with articles in Category:Current events. Thank you all for your time. ―MJL -Talk-^☖ 23:42, 30 January 2019 (UTC)
• Support the nominator has been able to address my concern on whether the noticeboard would be useful. I think that it would be useful when issues and BRD's get out of hand. I see it as the intermediary between AN and the talk page of the article. The idea about WikiProjects talk pages being the place for these discussions may not always be possible, as the activity level of a WikiProject is variable and dependent on many factors (inc. time of the year). Having to rely on their activity for potentially time critical decisions or issues may leave problem(s) with an article for a while, as this issue may not merit a discussion on a more general purpose noticeboard. Having a centralised noticeboard for problems relating to current events which don't merit more general noticeboard discussions seems like a good idea. However, my support is based on the presumption that this noticeboard will be well trafficked and checked by editors experienced in the area of current events. It could end up that editors post there and a few days later someone comes along to help out; this time could have been spent dealing with the problem if it was taken to AN. Therefore, because my argument for support is based on a presumption, I will leave it as a weak support. I don't think that ITN is an appropriate place, as the scope of the proposed page would be for more than just {{ITN}} pages. Dreamy Jazz 🎷 ^{talk to me | my contributions} 10:52, 1 February 2019 (UTC) (striked part I have later decided is a bit moot)
• Support The examples in the discussion section convince me that it could be useful. Schazjmd (talk) 20:23, 2 February 2019 (UTC)
• Support Sounds reasonable, probably useful. SemiHypercube 21:28, 2 February 2019 (UTC)
• Support. I expect the proposed noticeboard to be heavily used, as there is no central venue for discussing articles on current events. In the news only covers a handful of articles linked from the Main Page, and there are many other articles that would benefit from this noticeboard. Current events attract a lot of traffic. Affected articles become volatile, and the list of affected articles is constantly changing. With this noticeboard, editors who are familiar with handling these types of situations would be able to easily see and contribute to all of the articles of this nature that need attention. — Newslinger talk 22:01, 7 February 2019 (UTC)
• Support this is a common problem and a good idea that's worth a trial. Run well, this would be a net positive for our project. --Tom (LT) (talk) 08:06, 8 February 2019 (UTC)
• Support see my comments below in neutral, hope the good outweighs the harm, need a centralized place to deal with tendentious editors who find their way to current events. SandyGeorgia (Talk) 11:21, 8 February 2019 (UTC)

  SandyGeorgia Please do not feel pressure to !vote support if you still have reservations. I would rather the proposal fail than see it succeed with reluctant supporters. It will be of no offense to me personally. Thank you for your contributions. :D ―MJL -Talk-^☖ 22:36, 9 February 2019 (UTC)

  Not to worry-- I just wanted to take my time to think about it. When an article I edit was hit with tendentious editing, I decided those folks would show up, with or without a noticeboard, so may as well have the board! Best regards, SandyGeorgia (Talk) 01:04, 10 February 2019 (UTC)

• Support Cambalachero (talk) 12:21, 8 February 2019 (UTC)
• Support Wikipedia has become an important news source for millions. We need a few more mechanisms to help support our efforts in this area and IMO a notice board is more likely to help than hinder. Doc James (talk · contribs · email) 06:18, 9 February 2019 (UTC)
• Support ―Abelmoschus Esculentus (talk • contribs) 08:22, 9 February 2019 (UTC)
• Support: We need this: a centralized place to handle urgent issues with high-impact events, for the same reason we need a BLP/N. I share some of the concerns raised by other editors but kudos to the nom for having this well thought-out as reflected in the answers and examples given. I think we're ready to give this a go. The big question is, should it be CE/N or CUR/N? Levivich 07:18, 10 February 2019 (UTC)

  Levivich, you know I never thought about where it will be located. I recommend WP:CUR/N since WP:CE is very associated with Copy Editing. Thank you so much for participating! :D ―MJL -Talk-^☖ 20:30, 10 February 2019 (UTC)

  WP:CEN links to Centralized Discussion. CURN is the only available option. power~enwiki (π, ν) 22:34, 16 February 2019 (UTC)

• Support. I think that this is definitely worth a try. Although we have noticeboards for NPOV and RS and BLP, Wikipedia clearly has a hard time dealing with current events (where historical perspective is lacking). And there is something to be said for a noticeboard that comes before the dispute has to go to ANI. I've been concerned for a long time about how we are dealing (or not dealing) with current events, and this strikes me as a very worthwhile idea. --Tryptofish (talk) 00:09, 13 February 2019 (UTC)
• Support as a good idea worth a try. ~ Rob₁₃^Talk 01:22, 13 February 2019 (UTC)
• Support - an added safety net to help ensure we're getting the article right. ^{Atsme✍🏻📧} 01:37, 13 February 2019 (UTC)
• Support at least as a trial. Too many current events cross BLP and NPOV and RS issues to make those noticeboards necessarily the best place. --Masem (t) 02:07, 13 February 2019 (UTC)
• Support 1 year trial pinged by EEng. ^Thanks,L3X1 ◊distænt write◊ 16:47, 13 February 2019 (UTC)
• Support: Totally sensible proposal, and something that could be incredibly useful in times of rapidly changing events. GN-z11 ^{☎ ★} 09:10, 14 February 2019 (UTC)
• Support - Support as potentially useful. --Jax 0677 (talk) 13:11, 16 February 2019 (UTC)
• Support - I like the idea of a trial period for this. It's a little hard to predict what shape its content will take, but it's true this occupies a great deal of space on other noticeboards. Whether we want to admit it, it concerns something that is (a) important, (b) procedurally controversial, and (c) subject to a wide range of problematic editing, such that it may be useful to centralize the discussions. — Rhododendrites ^talk \\ 17:55, 16 February 2019 (UTC)
• Support It seems the most practical way of attracting a wider variety of editors to these discussions,and keepingtogether discussions which can on occassion overload some of the other noticeboards. DGG ( talk ) 00:04, 17 February 2019 (UTC) see below changed to oppose
• Support with caveat that single-article talk page discussions are kept to article talk. This will certainly be a useful noticeboard, e.g. for posting notifications about other discussions (except WP:ITNC). I don't see much room for a systemic basis of POV pushing since everyone agrees that a current event is a current event. wumbolo ^^^ 09:33, 17 February 2019 (UTC)
• Support There are a lot of unresolved questions regarding the coverage of content related to current/recent events. Several of the current practices are questionable and there is a need for further discussion in this area to establish firm, clear and convincing consensuses on inclusion policies. A central noticeboard would help with this. SD0001 (talk) 16:01, 21 February 2019 (UTC)
• Support. The WP:RECENTISM and WP:NOT#NEWS problems (and related ones, like WP:NOT#MEMORIAL, etc.) are worsening all the time, mainly due to lack of "concentration", as it were, of community consensus results against such non-encyclopedic claptrap.  — SMcCandlish ☏ ¢ 😼  05:27, 27 February 2019 (UTC)
• Support. I see recent news items pop up in AfD a lot because of WP:TOOSOON and WP:NOTNEWS (e.g. a recent one is the 2019 Boeing 737 MAX crisis AfD) so it'd be nice if there were a centralized place to discuss such things prior to creating such an article. So as an example of a possible use case for such a proposed current events noticeboard: Just today, there was that US college bribe scandal, and I was wondering, 'would this deserve an article?', 'did someone already create an article for this?', and 'what existing articles can this news item add to?' Such a noticeboard might be a good place to get prompt answers to such questions. -- Ununseti (talk) 01:26, 13 March 2019 (UTC)

Oppose

• That's what article talk pages are for. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:50, 11 February 2019 (UTC)

  Pigsonthewing, I can't even begin to tell you how much I appreciate your dissenting opinion on this matter. Thank you for your participation! ―MJL -Talk-^☖ 14:07, 11 February 2019 (UTC)

• I think that it would be more effective to WP:REVIVE Wikipedia:WikiProject Current events than to create yet another noticeboard. We don't need a central place so that random editors can bring a dispute to a wiki-expert; we need a mobile team of editors who are willing to go directly to the affected articles (and to other noticeboards, e.g., to BLPN for a dispute about a current event involving living people) and solve problems in situ. The WikiProject format is going to be more effective model than the one in which I sit at my noticeboard and wait for someone to bring me a question. Noticeboards work better when the problems are small and portable. The disputes being described here are neither small nor portable. WhatamIdoing (talk) 20:32, 11 February 2019 (UTC)
• Oppose as placing too much emphasis on violating WP:NOTNEWS. I am however aware that current events since at least June 2016 have been not only highly unusual but also influenced, obscured, obfuscated, deflected, and utterly misrepresented in a concerted effort by multiple international groups, individuals, and publications, and therefore such a noticeboard might have some use. However, as Andy says, that's what article talkpages are for, and what WP:RSN and other venues are for. I would appreciate the opinion of, for instance, BullRangifer and Galobtter on the matter. -- Softlavender (talk) 03:05, 13 February 2019 (UTC)

  I'm aware of this RfC but haven't commented because it is pretty hard to judge whether this noticeboard would be helpful or not until it is actually created and used - simply because it depends on who (if any) shows up and what sort of issues are brought there. Galobtter (pingó mió) 09:18, 13 February 2019 (UTC)

  Galobtter, Softlavender, and L3X1, I would very much be okay with a one-year trial. That certainly could also possibly address SandyGeorgia and others' concerns as well. The noticeboard is quite different because there is no Current Events policy unlike other noticeboards. ―MJL -Talk-^☖ 18:52, 13 February 2019 (UTC)

  I cannot for the life of me figure out why violating NOTNEWS would be considered a good thing. Is too much emphasis on not violating NPOV next? And anyway, the existence of a noticeboard does not mean that only a single kind of opinion would be tolerated there. --Tryptofish (talk) 18:00, 14 February 2019 (UTC)

  Tryptofish Beats me; I don't work here. ¯\_(ツ)_/¯ ―MJL -Talk-^☖ 03:04, 15 February 2019 (UTC)

  Seriously though, They are entitled to their concerns. I am not in the position of validating them or whatnot. I just try to address them. ―MJL -Talk-^☖ 03:04, 15 February 2019 (UTC)

• OPPOSE - as running contrary to multiple WP, and functional issues. First, the talk pages are the place to talk about content per WP:TALK so this would seem setting up a competing location fighting against that, and also functionally having two locations of discussion would make it harder to identify where an edit was discussed or even have two differing consensus. It would need additional guidance and work to have things untangled, and just not worth having things tangled. Second, there really should be a 48-hour waiting period... this would obviously run contrary to NOTNEWS, BREAKING, CRYSTAL, CAFETERIA, etcetera, and less obviously it would run against DUE and NPOV. Functionally, it simply takes a while for the WEIGHT of something to develop, and for responses and further info to emerge. Plugging in that mornings feed simply is poor practice as the daily viral usually seems to not last and too often turns out to die due to falsehood. I have seen it repeatedly at the Donald Trump page, most recently the Buzzfeed flap, that posting this morning feed wastes tons of editor time on OR assertions and speculation. Posting each story du jour also simply winds up a poor narrative quality in a disjointed diary collection of mostly unremarkable tidbits. Ultimately, not EVERY mornings NYT lead is going to be a major historical item and the only way we can reliably know is in retrospect of at least a few days to see if it grows or dies. It’s also just not worth the loss in quality and reliability to be going on with the latest half-baked emerging info. Quality lies at least partly in restraint. Cheers Markbassett (talk) 21:02, 17 February 2019 (UTC)
• Oppose We already have a place where people pontificate about the news of the day – WP:ITN/C. We see some polarisation there – sports vs science; UK vs US; good news vs bad news – and the results are not very edifying or productive. It's not clear what value the proposed noticeboard would add to this. Items in the news such as The Independent Group already attract attention and discussion on their talk pages. Another noticeboard would tend to generate forum shopping and canvassing. Andrew D. (talk) 11:13, 21 February 2019 (UTC)
• Oppose per Markbassett. If you want to keep up to date what are current events, go to Category:Current events. If you wish to discuss them, use their talk page. And if it's about what appears on main page, WP:ITN/Cis the place. If there are behavioral, RS or BLP issues there, the noticeboards already exist. I can't see much of a purpose for this. --Pudeo (talk) 10:29, 24 February 2019 (UTC)
• Oppose as unnecessary the controversial current events discussions are already sufficiently prominent that we do not really need to advertise them further. The net effect of this would be to add another layer to the disputes on those subjects, which is the last thing we need. I originally supported, but I now think this i more likely to fragment discussions than centralize them. DGG ( talk ) 20:13, 28 February 2019 (UTC)

Neutral

• While I don't see anything bad with the proposal or idea, I am neutral because the proposal and extra info does not really explain if there is a need for such a noticeboard. I understand that if it exists, editors and readers will find it and so it will be used, but have there been cases relating to current events where such a noticeboard would have helped? I think if such a need is shown, so that the noticeboard would then be useful, I would move to support. Dreamy Jazz 🎷 ^{talk to me | my contributions} 17:40, 31 January 2019 (UTC) moved to support
• Neutral for now, as I too am not immediately seeing a need for this. Wikipedia talk:In the news and Wikipedia:In the news/Candidates do good jobs regarding articles for the ITN section of the main page. For more general discussion of article content, I'd expect that subject-specific noticeboeards/wikiproject pages would be more useful as editors there will be more familiar with events of the type that has happened, where to look for good sources and what (parts of) news reports written by non-specialists are useful and which (bits) are just nonsense or trivia. Beyond enough clueful people to repeatedly say that WP:NOTNEWS is a guideline that needs interpretation (not an absolute prohibition on covering news events) and that long lists of formulaic tweets from random celebrities are not encyclopaedic (if they belong anywhere it's on Wikiquote) I'm not sure what value a new noticeboard will bring. Thryduulf (talk) 23:40, 31 January 2019 (UTC)
• I'm neutral here - I've nominated pages at ITNC that clearly weren't ready simply because they were about high-profile current events and needed more editors. It's technically against the rules, but IAR is a rule too. If this makes it easier to find editors for articles such as 2019 Venezuelan presidential crisis I'm all for it -- but that article is already on the main page and suffering for a lack of contributors (there are about 4 good editors there who are overwhelmed by the IPs and news updates), so I'm not sure a noticeboard will help. power~enwiki (π, ν) 17:08, 4 February 2019 (UTC)

• Re four overwhelmed, yes. What we need is help from bilinguals, help keeping the talk page in order, help dealing with WP:TEND, etc. A good deal of time is spent dealing with socks, NOTAFORUM, and POV pushers, and just generally trying to understand what IPs are asking for on talk.

  Will a noticeboard provide that, or will it become just another noticeboard for power-hungry bullies to congregate (eg COIN)?

  My other concern is that informing even good, neutral, experienced Wikipedians about context and history re Venezuelan events so they can make helpful edits takes considerable time; in the absence of a free press or independent judiciary, even helpful Wikipedians need a lot of background to help inform their edits. How can a noticeboard help with that problem, or will it exacerbate it? How can a noticeboard help good editors with good intentions, who aren't accustomed to editing in an environment of freedom of press limitations, better participate? I am wanting to be convinced one way or another, but my overall experience with noticeboards is that they become a gathering place for abusive and uninformed tribalism. SandyGeorgia (Talk) 17:40, 6 February 2019 (UTC)

• I have moved to support, because what else can we do, but my prediction is that the tenditious editors who show up on every current event will just use the board as a gathering place for coordinating their POV launches. Let's hope I'm wrong. SandyGeorgia (Talk) 13:47, 8 February 2019 (UTC)

Discussion

• @MJL: Can you explain your rationale behind having this? --DannyS712 (talk) 23:33, 30 January 2019 (UTC)
  • DannyS712, I am glad you asked! Currently almost done typing as we speak. ―MJL -Talk-^☖ 23:36, 30 January 2019 (UTC)
    • DannyS712, Done.
• Dreamy Jazz and Thryduulf, actually I have a few examples where a Current events noticeboard could be helpful.

Example One, Wikipedia:Redirects for discussion/Log/2019 January 30#2017–2019 Iranian protests and Wikipedia:Articles for deletion/2018–2019 Iranian general strikes and protests. Both of these discussions are unrelated to one another. At issue for both is a needed understanding on the current importance of this event and what details are needed for this encyclopedia. What would be most helpful for these articles is if they were discussed in a centralized location where editors who understand the context behind these events can contribute. At the least, a central noticeboard could have been used to notify users of both discussions.

Example Two, while I do like WP:ITN and WP:ITN/C, neither are meant to discuss specific articles. Whether or not Maidan Shar attack or the Taliban should be tagged with {{Current}} currently is (and probably shouldn't always) be discussed on there.

Example Three, it is also decently well known that articles and links on the front page are more heavily vandalized. The difficulty with articles WP:ITN is that the facts are not always clear. It is also more difficult to manage since generally people may make edits on less well trafficked articles related to the event. Determining consensus in those events is much more difficult. For example, whether or not Qatar supports the Taliban. Obviously, the talk page could simply handle this for the most part, but a noticeboard would be a nice alternative to bring attention to these issues.

Example Four, Juan Guaidó had numerous content disputes. [3] [4] [5] [6] [7] This is an event where details can change by the minute. If it were not for SandyGeorgia and Kingsif working so diligently to make sure it was accurate, it would be a completely different article. We can't rely on editors like them for every single article, though.

As for why a wikiproject would not be sufficient, it could be, but I don't know how appropriate it would be. My concern with current events is similar to WP:BLP. I feel like we should have similar standards to BLP for Current Events. Why? During a current event, Wikipedia is one of the immediate search results to come up despite WP:NOTNEWS. I suspect people do this for background information on a subject (like how I might look up Jussie Smollett after the 2019 attack to learn a bit about who he is or for a refresher). Getting the wrong information in those cases can do serious damage to not only our credibility but for the health and wellbeing of others.

So there you have it! :D ―MJL -Talk-^☖ 01:58, 1 February 2019 (UTC)

• Question what's wrong with reaching out to the various wikiprojects for input when an article in their area of interest is also a current event? As a "regular" at ITN/C, my concern with your proposal is a narrow cabal of informal arbiters determining the "significance" of article content in a wide range of topics simply because the article is a current event. --LaserLegs (talk) 12:32, 1 February 2019 (UTC)

LaserLegs I suppose I have not considered whether the noticeboard being something like WP:CABAL. I suppose that is sort of an issue with all WP:CONTENTDISPUTE Forums, but you are probably right that it is exacerbated by a board having a narrower subject matter. Not to diminish your concern, but I am sort of failing to see how WP:FTN does not have sort of the same issues as the ones you described. I'm not saying they do a bad job, but theoretically that could be the case. This might not happen there because a noticeboard is supposed to bring more attention to an issue (not less) by leaving things more transparent. The ad hoc way we go about things related to current events kind of have leaves people with less of a voice in the matter if they have trouble navigating the system. As for why one can't reach out to the WikiProjects, I don't feel like that would go away with this noticeboard. In fact, when that does happen, members of the project will be able to have a place to alert more people of the issue. The job of this noticeboard would be to make those decisions that they already have to make more timely. Did I answer your question because I hope so? ―MJL -Talk-^☖ 20:55, 1 February 2019 (UTC)

Thanks MJL, you did, and it could be my concern is itself a fringe theory. Thanks. --LaserLegs (talk) 22:49, 1 February 2019 (UTC)

Question: What about ongoing or failed nominations for ITN, or articles that have not been nominated but there is a dispute about something that is in the news nonetheless? This noticeboard would cover them too? Have in mind that, at any given time, there are hundreds of articles that are "in the news" in some capacity, but only a selected handful are featured at the ITN section of the main page. Cambalachero (talk) 22:56, 2 February 2019 (UTC)

Cambalachero, yes ongoing and failed nominations for WP:ITN as well as articles that have not been nominated would be covered by this notice board but only if there is some sort of issue relating to content. I suspect that ITN articles on the main page would be frequent flyers for this board, however as they are more traffic'd. Thank you for your question! ―MJL -Talk-^☖ 23:25, 2 February 2019 (UTC)

Comment: Have in mind that topics in the news may usually involve stub or faulty articles, or even with no written articles yet (either because it's a new topic, or because the topic was overlooked until now). You should add links to the pages about creation and improvement of articles (and also when not to create new articles, despite the news). Cambalachero (talk) 00:34, 3 February 2019 (UTC)

• Comment there seems to be consensus to at least try this out. Can we perhaps get an early close? We don't need too much bureaucracy here. In the meantime, the 2019 Nigerian general election (scheduled for today GMT) appear to be postponed; current events editors may want to watch that page over the next 10 days. power~enwiki (π, ν) 16:34, 16 February 2019 (UTC)

  Power~enwiki, by all means you or another user are welcome to close it. I know I am having enough trouble as it is updating National Emergency Concerning the Southern Border of the United States (luckily, no deadline... but still..). This news cycle has been killer on me. ―MJL -Talk-^☖ 16:49, 16 February 2019 (UTC)

  I'm too involved to close the discussion, but I may create the page later today (with the caveat that it will be G6/G7 deleted if there is a consensus here not to have the page). power~enwiki (π, ν) 16:55, 16 February 2019 (UTC)

  My advice would be to keep it open longer. It hasn't really been open that long, in that RfCs typically stay open for a month unless the responses are pretty much unanimous, and this one is important enough to be listed at WP:CENT. There could still be useful input from editors who have yet to respond. --Tryptofish (talk) 20:25, 16 February 2019 (UTC)

  I created Wikipedia:Requests for comment/Current events noticeboard/Header so people can try to collaborate on how to describe this noticeboard in parallel with the request for comments. power~enwiki (π, ν) 17:51, 17 February 2019 (UTC)

Comment: Seeing this RfC reminded me of similar ideas we had in a research paper back in 2015 (see Signpost coverage here). One of the things we looked into was whether the most popular articles showed signs of stable popularity, or whether they were breaking news events that had short-term significant changes in popularity. We found that 46% of the most popular articles (over the course of a month) showed signs of spikes in popularity, and suggested that Wikipedia could benefit from a "rapid response team" that could work on those articles. I expect that this to some extent already happens, but having a central place for discussion and coordination seems to me to be a good idea. Cheers, Nettrom (talk) 15:06, 28 February 2019 (UTC)

HouseKeeping / Notifications

Extended content

This RfC is being posted in the following locations: Wikipedia:Village pump (proposals) Portal talk:Current events Wikipedia talk:Noticeboards Wikipedia talk:In the news Wikipedia talk:WikiProject Current events Including the Talk pages of its participants Wikipedia talk:Recentism Wikipedia talk:Don't misuse the Current Events template ―MJL -Talk-☖ 23:22, 30 January 2019 (UTC) Also on WP:POST/N/S — pythoncoder  (talk | contribs) 13:27, 5 February 2019 (UTC) Added to WP:CENT by Swarm. [8] ―MJL -Talk-☖ 13:37, 8 February 2019 (UTC) I've also transcluded it on my Talk Page for my own convenience. ―MJL -Talk-☖ 14:04, 8 February 2019 (UTC) Stricken and removed. ―MJL -Talk-☖ 14:05, 8 February 2019 (UTC) Further mentioned or Located at: User talk:MJL/Archive 4#No Heading Wikipedia:Requests for comment/Wikipedia proposals Wikipedia:Requests for comment/WikiProjects and collaborations Wikipedia:Requests for comment/Politics, government, and law User talk:Dreamy Jazz Wikipedia:Village pump (all) User talk:Swarm#Accepting Adoptees still? User talk:Yellowdesk ―MJL -Talk-☖ 01:32, 11 February 2019 (UTC) Arbitrary Break Later mentioned: Wikipedia talk:Naming conventions (Macedonia)/2019 RFC#Concerns about Current Readability of this Talk Page. Template talk:Current events ―MJL -Talk-☖ 03:23, 14 February 2019 (UTC) Spur-of-the-moment Mentions: Talk:2019 American Declaration of a State of Emergency— Preceding unsigned comment added by MJL (talk • contribs) 17:10, 15 February 2019 (UTC) Plus... Added to Category:Non-talk pages that are automatically signed In a reply at Talk:2019 Venezuelan presidential crisis ―MJL -Talk-☖ 15:42, 24 February 2019 (UTC) Previous Comment on Village Pumped I just opened up a RfC. Please check it out! :D ―MJL -Talk-☖ 23:12, 30 January 2019 (UTC) (moved. from here) ―MJL -Talk-☖ 20:08, 2 February 2019 (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.

I would like to suggest that as we are not "Hello" magazine we do not cover a relationship until someone is engaged, or some other defining point that may be suggested. I am concerned that without a defining point undue interest in someone's relationships is not healthy and looks like stalking. Britmax (talk) 10:21, 25 January 2019 (UTC)

Surely the most important factor is how reliable sources cover the relationship, and not what stage the relationship is at? Iffy★Chat -- 10:45, 25 January 2019 (UTC)

We should only mention relationships when they have been covered by reliable secondary sources (which Hello and gossip columns are not) and are relevant to the encyclopedic coverage of a person. As Iffy said, the coverage is more important than the stage of the relationship, but in practice it is very unlikely that any current short-term relationship will attract such coverage and be a relevant part of a person's encyclopedic biography. This doesn't require any change to current policy and guidelines, but just proper enforcement, particularly when it comes to biographies of living people. Do you have any examples where you feel that our current content inappropriately invades privacy? Phil Bridger (talk) 12:45, 25 January 2019 (UTC)

How do you know that Hello is not reliable. My guess is that they have some sort of fact-checking operation and some incentive to get their facts right. The "litigation" section of their articles lists two suits for invasion of privacy but none for making false statements. I get that Hello is read by the The Sort Of Persons With Whom We Do Not Wish To Associate, but that's different from being unreliable for statements of fact. Herostratus (talk) 03:33, 27 January 2019 (UTC)

I'm thinking that Herostratus is probably correct: Celebrity gossip magazines tend to get their facts right, and if one says that Sally Star and Joe Film are dating (and especially if several of them say the same thing), then you can generally "rely" upon them to get their facts correct. Whether to include that (reliably sourced) information is a matter of WP:DUE. If sources overall put a lot of emphasis on this relationship (e.g., more stories in gossip magazines about dating than stories anywhere about anything else), then we should include it. But I think in the typical case, User:Britmax's sense that this is undue is correct. The only difference is that I'd say that it's "WP:UNDUE", as well as regular-dictionary-definition undue. WhatamIdoing (talk) 04:02, 1 February 2019 (UTC)

Oh, absolutely on that point. We shouldn't report on dating relationships, and on non-marriage relationships unless its at the level of crypto-marriage. And not at all if there're any privacy concerns whatsoever. In fact, WP:NOTNEWS engages on this. Most people, reading only the title, assume NOTNEWS says we don't cover very recent events, when it says no such thing. But it does say "news reporting about celebrities... can be very frequent and cover a lot of trivia, but using all these sources would lead to over-detailed articles that look like a diary" and "routine news reporting of... celebrities is not a sufficient basis for inclusion in the encyclopedia". So there's your rule to cite.

I was just making the point that sometimes there's some unwarranted snobbery regarding some sources. For instance, some people would disdain Cosmopolitan as a source, but here is a piece from a Cosmo fact-checker. "Any material that is vaguely health-oriented has to be verified by a medical doctor or published medical literature" and her job is to that. "All descriptions of beauty tricks must come from interviews and are cross-checked with follow-up emails or calls from the research team.... Every word in Cosmo, surprisingly, is verified with a professional rigor that far exceeds virtually all Internet publications and daily newspapers". (Incidentally, your Important Book by your Distinguished Professor is usually not independently fact-checked.) So, I don't know what kind of operation Hello is, but I'm not going to base my assessment on snobbery. Herostratus (talk) 04:59, 1 February 2019 (UTC)

A proposal is being discussed to apply the equivalent of extended confirmed protection to any article related to conflicts between India and Pakistan. Interested editors are invited to comment on the proposal. Ivanvector (^Talk/_Edits) 15:54, 4 February 2019 (UTC)