Jump to content

Wikipedia:Village pump (proposals)/Archive 165

Add links
From Wikipedia, the free encyclopedia
Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

WikiProject: prefix

Pretty strong sense that such a thing would be undesirable ~ Amory (u • t • c) 19:03, 30 January 2020 (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.

There should be a page prefix exclusively possible for WikiProjects. They clutter the search for “Wikipedia:” and need to be separated. E Super Maker (😲 shout) 00:30, 21 December 2019 (UTC)

Agree....policy and gudlines should aswell....so we can search them like the MOS.--Moxy 🍁 03:14, 21 December 2019 (UTC)
Not sure what the problem is. Project namespace seems to be correct for all of this. (And, of course Project: is an alias for Wikipedia:, so Project:GERMANY redirects to Wikipedia:WikiProject Germany). Or do you want to remove all WP: shortcuts for Wikiprojects? That would break 15 years' worth of links, no thanks. —Kusma (t·c) 08:36, 21 December 2019 (UTC)
No, It wouldn’t remove WP: shortcuts, because some of them redirect to mainspace pages. E Super Maker (😲 shout) 00:29, 22 December 2019 (UTC)
Yes it would, WP: is a redirect to Project: (localized as Wikipedia:). We would have to keep every single page and turn it in to a cross-namespace redirect to maintain that (or retarget WP: and that is even worse). — xaosflux Talk 14:08, 22 December 2019 (UTC)
@E Super Maker: can you be more specific? Here is an example project: Wikipedia:WikiProject Military history. What are you proposing it be renamed to? — xaosflux Talk 01:56, 22 December 2019 (UTC)
Think he is proposing it to be WikiProject:Military history. Happy Festivities! // J947 (c) 03:30, 22 December 2019 (UTC)
Correct! E Super Maker (😲 shout) 13:48, 22 December 2019 (UTC)
  • Any prefix can already be created in any namespace. It seems they're proposing to create WikiProject "namespace". I am not convinced this is a good idea though. – Ammarpad (talk) 05:12, 22 December 2019 (UTC)
  • I assume the idea is to be able to more easily sort thorough policies or other pages in the "wikipedia:" namespace? It would be helpful to understand why the proposal concerns wikiprojects in particular (would you want separate namespaces for essays, policies, etc?). Is the "clutter" making it difficult to find a specific kind of page? I think the proposal would benefit from a bit more explanation/specifics. Forbes72 (talk) 07:01, 22 December 2019 (UTC)
  • OPPOSE Poorly thought out and explained proposal. For what I do understand, I see no need. GenQuest "Talk to Me" 13:24, 22 December 2019 (UTC)
  • Strong Oppose now that this has been clarified that this isn't about a naming convention, but about creating an entirely new namespace just for "wikiprojects". Not to mention having to move at least many thousands of pages (these) and breaking the WP: namespace shortener. — xaosflux Talk 14:06, 22 December 2019 (UTC)
I’m not really seeing how this would break WP:. E Super Maker (😲 shout) 14:24, 22 December 2019 (UTC)
@E Super Maker: "WP:" goes to "Project:" which goes to "Wikipedia:" So WP:MILHIST goes to Wikipedia:MILHIST, so at the very least you'd have to leave all those pages in Wikipedia space (thus not shrinking the pages in it at all) and make redirects to this new namespace - or break things. — xaosflux Talk 14:38, 22 December 2019 (UTC)
@Xaosflux: There's no reason why you can't redirect from WP:MILHIST→WikiProject:Military History. Cross-namespace redirects from the Wikipedia namespace are allowed. --Ahecht (TALK
PAGE) 18:31, 7 January 2020 (UTC)
@Ahecht: oh sure, but it means that you won't get rid of the page "Project:Military History" at all, and the result is that now you have two pages. With the proposal goal of removing "clutter" on namespace 4 - this wouldn't remove anything. — xaosflux Talk 18:42, 7 January 2020 (UTC)
This sounds like a really good thing for a bot to do. E Super Maker (😲 shout) 15:28, 22 December 2019 (UTC)
  • Oppose I do not, really, understand why projects would be deemed important enough to deserve their own namespace; while some—MILHIST, mentioned above for example—are superlative, "industry-leading", of their kind, many projects are effectively moribund. ——SN54129 14:10, 22 December 2019 (UTC)
  • Oppose per others. No real need. Happy Festivities! // J947 (c) 19:19, 22 December 2019 (UTC)
  • Support CNR – We don't have to move anything anywhere, we can have a namespace alias WP:CNR like MOS:. And it would be very useful to have one (WikiProject:), though I'm not sure what the abbreviation should be (PJ:? WPJ:?). There are so many confusing shortcuts. For example, WP:TERRORISM goes to WP:WikiProject Terrorism, but WP:TERRORIST goes to WP:Manual of Style/Words to watch#Contentious labels. WP:RACIST points to the same section, but WP:Racism goes to WikiProject:Discrimination. WP:MUSIC goes to a notability guideline; MOS:MUSIC to the MOS section; what's the shortcut for WP:WikiProject Music? It's WP:WPMU... not exactly the first think you'd think of, eh? But unlike WP:MUSIC, WP:ALBUM doesn't go to the notability guideline; instead it goes to the WikiProject; the notability guideline is WP:NALBUM. I think it's technically possible to have a namespace alias so I'd support a CNR like WikiProject:Foo (or WPJ:Foo or something for short) that would point to "Wikipedia:WikiProject Foo", and then we could have WPJ:TERRORISM, WPJ:MUSIC, WPJ:RACISM, and it wouldn't be confused for the WP: (policy or guideline, including notability guideline) or MOS: (manual of style) prefixes using the same shortcut. So WPJ:MUSIC would point to the WikiProject, WP:MUSIC to the notability guideline, and MOS:MUSIC to the MOS section. – Levivich 19:24, 23 December 2019 (UTC)
    @Levivich: please note, MOS: is not a "namespace alias" it is a collection of CNRs and are all in the article namespace. I have a feeling that some wiki-technical phrases are getting confused in this discussion. — xaosflux Talk 02:29, 24 December 2019 (UTC)
    Xaosflux, thanks for clarifying. I thought a CNR and a "namespace alias" was the same thing. What's the difference? We could probably all benefit from an education in the terminology. But semantics aside, replace "namespace alias" in my comment with "CNR"-what do you think? – Levivich 03:17, 24 December 2019 (UTC)
    @Levivich: so, the main name for pages that are in namespace 4 (NS_PROJECT) is Project:, for example you can go to Project:Administrators' noticeboard. "Wikipedia" is a namespace alias that also goes to NS_PROJECT, and is also our localized name for NS_PROJECT. Additionally "WP" is another namespace alias for NS_PROJECT. All those "MOS:" pages are in the main namespace, and are just standard redirects that redirect the link back in to the project namespace. You could create more mainnamepace redirects such as WPJ:MILHIST that go to Wikipedia:WikiProject Military history - but it will still be the same target - in the same namespace. It is possible to create new custom namespaces, and localized names and aliases for them - that appears to be what Sophivorus is proposing here. — xaosflux Talk 03:52, 24 December 2019 (UTC)
    P.S. namespace aliases such as WP=>Project are done automatically and are fixed, whereas things like MOS: are just normal redirects and must be created and maintained as pages. — xaosflux Talk 03:54, 24 December 2019 (UTC)
    Ahh I see, thanks for the explanation, I've updated my !vote. It seems CNRs are a very easy way for any WikiProject that wants to to create a shorter or clearer shortcut. I just created WikiProject:Music and WPJ:Music redirects to WP:WikiProject Music. I would support that becoming a convention (with WPJ: being for WikiProjects, MOS: for MOS pages, and WP: for policies, guidelines, and essays). – Levivich 04:15, 24 December 2019 (UTC)
    There's a consensus as mentioned in WP:CNR for no new mainspace CNRs. Galobtter (pingó mió) 04:20, 24 December 2019 (UTC)
    From six years ago; consensus can change, etc. – Levivich 04:28, 24 December 2019 (UTC)
  • Oppose I see no indication of any problem this proposal is attempting to solve. * Pppery * it has begun... 05:35, 24 December 2019 (UTC)
  • Support Namespaces are actually pretty cheap; we've got about 10 currently on enWiki (Portal, Book, Draft:, TimedText:, Module:, and their talk namespaces) and another 6 defined-but-unused namespaces. Why would we want to create a new namespace? mw:Manual:Using_custom_namespaces#Why_you_would_want_a_custom_namespace gives the main reasons, but some use cases I see here:
Search all and only WikiProjects; useful for new editors (or old editors trying to find the Domestic Pigeon Task Force)
No more conflicts between shortcuts; just as H:R and WP:R go different places, we could have PJ:M go to MilHist and WP:M go to Wikipedia:Mediation.
Links will be categorically shorter; WikiProject:Linguistics is shorter than Wikipedia:WikiProject Linguistics
They aren't life changing gains, but there are tangible benefits to this idea. I don't see any real downside either besides the set-up cost of migrating the existing pages. Xaosflux seems to think that's more trouble than it's worth, and usually they know better than me on things like this. However I don't think the goal is shrinking Project:, but reducing shortcut conflict among other stuff I mentioned above. So if we get the benefits of a new namespace, I'm not concerned about leaving redirects behind to prevent breakage because we've done it a number of times before: we left CamelCase redirects behind after switching from UseModWiki (see {{r from CamelCase}}), and we kept redirects from Wikipedia:Wikiportal/* after the move to the new Portal: namespace until an RFD 5 years later found consensus to delete the redirects. I'm opposed to handling this using CNRs from mainspace like MOS: pages because that's a mess that honestly should also be fixed by adding a new namespace. This may actually be an opportunity to figure out how we would do that. Wug·a·po·des​ 11:25, 24 December 2019 (UTC)
  • Support per Wugapodes explanation above. I always dislike seeing arguments for not doing something because "a lot of pages will move". We do that every day; we also have moved thousand of articles when needed (such in a recent election NC change). If that is the only reason not to do something, that is a pretty weak reason. I also agree with Leviv that the current project namespace is a mess with similar redirects using MOS/WP and being inconsistent to where they redirect. This too can be easily solved with the move proposed. --Gonnym (talk) 11:44, 24 December 2019 (UTC)
  • Oppose cross-namespace redirects, we don't need to clutter mainspace with more of them. For that matter, the cross-namespace redirects WikiProject:Music and WPJ:Music created during the course of this discussion should be deleted. Very weak oppose about an actual new namespace; I don't think it'd be wrong, it just seems rather pointless. When it comes to search clutter, I find much more of that from archives of old deletion discussions and such than I do from WikiProject pages. In practice I've seldom seen confusion over whether a shortcut refers to a policy or a project, as context is usually sufficient. But if confusion really is a concern, you could as well encourage the use of shortcuts like WP:WPVG over WP:VG instead of asking for a whole new namespace with associated shortcut when the existing WP shortcuts will need to hang around for some time anyway to avoid breaking links in old discussions and edit summaries. Anomie⚔ 14:10, 24 December 2019 (UTC)
  • Oppose solution in search of a problem. Headbomb {t · c · p · b} 15:45, 24 December 2019 (UTC)
  • Oppose new namespace as the saved keystrokes don't justify the overhead of a new namespace (with associated guidance etc) - there are already 30+ namespaces to select from when using Advanced Search, having "Project" namespace and "WikiProject" namespace would confuse newbies (we already see confusion of portals vs wikiprojects), we'd potentially get forks of wikiproject in other namespace, there would be questions about whether task forces belong in that namespace ... DexDor (talk) 22:22, 24 December 2019 (UTC)
  • Just a heads up that there is a discussion at RfD concerning the redirects that Levivich created. Merry Christmas! // J947 (c), at 23:44, 24 December 2019 (UTC)
  • Strong support per Wugs. Soumyabrata (talk • subpages) 07:54, 25 December 2019 (UTC)
  • Support. I've often wished I didn't have to type all of "WP:WikiProject". And, having it broken out as its own namespace means I can search just in that namespace. Makes sense to me. -- RoySmith (talk) 16:04, 25 December 2019 (UTC)
  • Super hard oppose. WikiProjects are dying (like Portals) and we're proposing to give them their own space? It's not like they need the room to grow. People who want to search in that namespace can do something like Special:Search/Wikipedia: intitle:WikiProject. We also do not need an XNR for this, as previously agreed (no new XNRs). Most WikiProjects, if they need it, have a shortcut. Inconsistencies in shortcuts can and should be remedied at WP:RFD, not by adding another new namespace. In short, I really don't see a problem here that needs a solution. --Izno (talk) 16:36, 25 December 2019 (UTC)
  • oppose as the Wikipedia space is supposed to be for things like wikiprojects. You don't have to type all of "WP:WikiProject" as normally when you have to type it is a template that point to a project, and that is in template space. Anyway the prefixes are already excessively cluttered with useless things that make life difficult when you do a rename. (for draftification, userfication) Graeme Bartlett (talk) 05:03, 29 December 2019 (UTC)
  • If I were going to recommend potentially disruptive page moves, I'd suggest moving AFD to another namespace. That's a h-u-g-e percentage of pages in the Wikipedia: namespace, and it's almost never what you want (or you only want those pages, and the rest is in your way). WhatamIdoing (talk) 06:05, 2 January 2020 (UTC)
    Wow, I did not realize AFD pages were >40% of all Wikipedia namespace pages (435000 out of 1065045). Does make sense though, with ~50-100 AfDs a day for >15 years. Galobtter (pingó mió) 06:24, 2 January 2020 (UTC)
  • Support for AFD and WikiProject: It would remove the "wikipedia" namespace clutter. DrewieStewie (talk) 20:27, 4 January 2020 (UTC)
  • Oppose, solution in search of a problem. Stifle (talk) 10:10, 6 January 2020 (UTC)
  • Support I have myself thought of this need for years; seems an easy fix. Can't think of any problems it would cause. --Jayron32 13:19, 7 January 2020 (UTC)
  • Oppose for mostly what xaos said above and a dash of WAID. Killiondude (talk) 18:40, 7 January 2020 (UTC)
  • Oppose because of how much chaos it could cause, and early opposers make good points. >>BEANS X2t 13:50, 10 January 2020 (UTC)
  • Oppose and delete per above. ―cobaltcigs 17:32, 10 January 2020 (UTC)
  • Oppose - A solution looking for a problem, Also opposing due to this proposal not being at all informative as to the whys or the benefits. –Davey2010Talk 13:01, 13 January 2020 (UTC)
  • Oppose - I think the potential advantages (thanks to Wugapodes for listing them) are outweighed by the addition of unnecessary complexity. The Wikipedia: namespace is intended for administration of the project, and WikiProjects are part of the administration of the project. -- Black Falcon (talk) 05:59, 15 January 2020 (UTC)
  • Oppose having additional namespaces is quite confusing. The WP/MOS difference was already annoying enough. No need to add to the complexity. CaptainEek Edits Ho Cap'n!⚓ 00:51, 17 January 2020 (UTC)
  • Strong Support. I see no reason not to. this is an excellent idea. --Sm8900 (talk) 14:12, 22 January 2020 (UTC)
  • Alternative suggestion - Change the software to allow "Partial page name aliases" similar to these but where the alias is expanded by the software, so WPP:foo would be expanded to Wikipedia:WikiProject foo and WPT:foo would expand to Wikipedia Talk:WikiProject foo. This would require a change to WikiMedia software, so it would be many months away after it was approved as a proposal here. If this is desired, I recommend staring a new proposal. (edited after other users added more comments) davidwr/(talk)/(contribs) 21:07, 27 January 2020 (UTC)
  • Oppose per WP:BROKEN. What problem does having these in the Wikipedia namespace cause? —David Eppstein (talk) 21:06, 27 January 2020 (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.

Bot to move coordinates into infobox

Many infoboxes for places (schools, building, etc.) support geo coordinates in the infobox. These are usually displayed in the infobox and at the article title. There are articles with such infoboxes that have coordinates at the title only. I think this is rarely, if ever, a consious decision to display the coordinates only at the title. It probably happens mostly when an infobox was added to an article that already had coords at the title and they just weren't moved to the infobox, or "missing coords" are added to an article by an editor who did not realize/notice they could/should go into the infobox. I propose a bot move such coordinates into the infobox. JJMC89 has volunteered to do this. This would not affect any coords that are displayed "inline" anywhere else in an article. This should be straightforward, except in some cases with both an "inline" coord in the infobox and a "title" coord outside the infobox that aren't identical. Those would probably have to be handled manually. MB 02:19, 31 January 2020 (UTC)

A bot would also need to confirm that the omission of title was not intentional. I don't have any precise information at the moment but there are articles where multiple things are discussed, and some of the things have {{coord}}. MediaWiki makes certain assumptions about coordinates that have title. There should only be zero or one per page, and if one, it affects "what's near here" that can be used. Johnuniq (talk) 02:49, 31 January 2020 (UTC)

New approaches to "Simple English Wikipedia"

I recently stumbled upon this seemingly wonderful invention. I see great potentials in it. I see shortcomings in it, also - but not ones like the complaints that pollute its article's Talk Page. There, the complaints all seem to center around a kind of "English Language Bias". This is not helped by the fact that use-of-language seems to be Simple's only expressed selling point;

I believe it's a disservice to limit Simple's described audience to that. (It also opens up Simple to unwarranted criticism - particularly from those with a kind of English-only prejudice.)

I would argue that additional stated benefits should include concision and convenience. Its articles, nor writing guidelines don't need to change - they already appeal to these benefits. My first suggestion is that these benefits be put right on its front page, as well as the main Wikipedia article.

I'm highly technical and language-fluent, yet there are some articles in English's main Wikipedia that are so laborious and/or highly technical that it's a difficult read. This is not a complaint. This is, of course, what one wants from an encyclopedia! But sometimes I don't want to attain a PhD on a subject, but instead just a general perusal.

Doubtless Simple would benefit from more articles, ergo: more authors. For this, I don't think the challenge is a lack of people willing to write for it, but rather a lack of people aware of it. A decade and a half after its creation, and I only just stumbled upon it - and not from Wikipedia. I inadvertently found an article from a search engine. I should have seen a reference to it long ago on Wikipedia, itself.

This leads to my next suggestion, and this is an admittedly bold one; a "Simple" tab right next to the |Article|Talk| tabs. Right on top. Obviously, only for main-English articles for which there is a corresponding Simple article.

My fervent belief is this would create a massive wave a new awareness of Simple's existence, and a concomitant flood of new authors. Only then could Simple reach its potentials, therefore its true value.

     —  BoringJim (talk) 21:14, 25 December 2019 (UTC)

This has been discussed before (a quick search shows Wikipedia:Village_pump_(proposals)/Archive_66#Examples_TAB_beside_Article_tab_and_discussion_tab as an example). It could be possible to add at least a local script to include "Read on Simple English Wikipedia" or something if the interwiki to simple: exists. I doubt this would get integrated to mediawiki core. Problem at least for non-logged in users, we really wouldn't want to run a script an reformat the page every single time a page was read - and this wouldn't be effective for mobile readers. This could possibly be done as a gadget for logged in editors. — xaosflux Talk 23:04, 25 December 2019 (UTC)
What about a less complicated (dare I say, simpler) solution? We have {{commonscat}} and similar templates that can be added to let users know we have more content elsewhere. I don't know that we have that for simple, {{Simple}} is a redlink. Beeblebrox (talk) 21:43, 4 January 2020 (UTC)
You can also add the following code to your Special:MyPage/common.js. This code could also be added to MediaWiki:Common.js to apply to the entire wiki. The code will show a "Simple" tab as described by BoringJim if there is a language link to Simple English Wikipedia in the language list.
mw.loader.using('mediawiki.util').done(function(){
	var sl = $('#p-lang .interlanguage-link-target[lang="en-simple"]').get(0);
	if (sl && mw.config.get('wgNamespaceNumber') === 0) {
		mw.util.addPortletLink('left-navigation', sl.href, 'Simple', 'ca-simple', 'View this page on the Simple English Wikipedia', 's');
	}
});
– BrandonXLF (talk) 03:44, 7 January 2020 (UTC)
That's interesting and I thnak you for sharing it. However, I think when it comes to the casual reader they don't really look much at those tabs, but they might notice a tag in the article itself. Beeblebrox (talk) 20:42, 13 January 2020 (UTC)
There's an existing script to do this: User:Operator873/SimpleWPTab.js. In regard to deploying something like that for everyone, I think it would be really helpful to help spread awareness that the project exists. Vermont (talk) 10:52, 16 January 2020 (UTC)
It'll be helpful because those learning english may not know simplewiki exists, and, in addition, editors who see it may want to edit the simplewiki. I support that being added to common.js. We also may want to consider mentioning it in school project pages and such. Computer Fizz (talk) 17:43, 16 January 2020 (UTC)
After looking it over some more, this should only be added to vector.js, not common.js, because it doesn't work with monobook, a seperate version can be made for that skin. Additionally, for the point about how casual readers may not look at the tab, how about the things that look like userboxes that mention things like the Wiktionary, Wikiquote, etc, when applicable, there can simply be one created to say "The Simple English Wikipedia has an article about title", or something similar. Does everyone agree with this? Computer Fizz (talk) 17:58, 16 January 2020 (UTC)
Computer Fizz, you also have to consider that the about script would make a request to the server for every person reading Wikipedia, seems like something that would be much better implemented in a Mediawiki extension of something. – BrandonXLF (talk) 04:40, 19 January 2020 (UTC)
@BrandonXLF: I think at first we should just use the top right box, then after that's been going for several months have another discussion about a Simple English tab. Perhaps there could be a bot to add and remove the boxes. The one problem though is that sometimes simple english can have different tiles than english (i.e. we say "movie" instead of "film") Computer Fizz (talk) 08:18, 19 January 2020 (UTC)
Computer Fizz, are you talking about the templates like {{Wiktionary}}? Those are added on a per-page basis and are generally placed near the bottom of the article from what I've seen. One could be created at the name {{Simple}} for the Simple English Wikipedia, that would be a good start since it doesn't involve any major changes.– BrandonXLF (talk) 08:28, 19 January 2020 (UTC)

@BrandonXLF: I think this would be better placed at the top, but i'm not entirely sure. I will see about drafting a simple template in my userspace tomorrow (37 after midnight for me right now), and if enough people like it I'll move it to template:simple. Computer Fizz (talk) 08:38, 19 January 2020 (UTC)

@BrandonXLF: Does this look good to you, and anyone else present in this discussion? Computer Fizz (talk) 21:37, 19 January 2020 (UTC)
Computer Fizz, I think it's good. I'd prefer if it said "on the Simple English Wikipedia" though. You'll also need one that uses {{sister-inline}}. – BrandonXLF (talk) 20:33, 20 January 2020 (UTC)
@BrandonXLF: Changed the text to "on the Simple English Wikipedia", but the inline template doesn't seem to support text for Wikipedias. Could you try making what you're thinking of in your own subpage? Computer Fizz (talk) 01:52, 21 January 2020 (UTC)
Computer Fizz, I made the two templates using Module:For nowiki at User:BrandonXLF/sandbox/3. Feel free to move them to your userspace. – BrandonXLF (talk) 02:16, 21 January 2020 (UTC)
@BrandonXLF: No at this point what we need to do is get the go ahead from a closing admin to move it into the template namespace and start adding it to pages. Computer Fizz (talk) 03:04, 21 January 2020 (UTC)
  • @BoringJim: I appreciate your enthusiasm, initiative, and good will. There are many aspects of Wikipedia which people would enjoy if we made those tools and projects more accessible. Regarding Simple English Wikipedia, the situation is complicated, and in 20018 there was a proposal to close it. If things do not change in the near future I expect another proposal to close within a few years. Lots of people would have their own explanation for this, but briefly, the project has some problems which have brought it to the point where practically all Wikipedia outreach intentionally avoids directing new editors and readers to that project. Blue Rasberry (talk) 19:15, 16 January 2020 (UTC)
@Bluerasberry: True, simple english does have problems, but none of those problems will be solved by closing it. One such issue is that more people need to know about the wiki, which is being solved right now.Computer Fizz (talk) 21:22, 16 January 2020 (UTC)
It'd probably make sense to get people in this conversation who know how the Simple English Wikipedia works. User:Bsadowski1 and User:Djsasso are admins on both simplewiki and enwiki. User:BRPever is a sysop there and a global sysop, and User:Vermont is a sysop there and also at Meta. WhatamIdoing (talk) 19:00, 21 January 2020 (UTC)
Well I would love to see a tab here of some sort that contained simpler versions of articles (be that as part of this wiki or as a link to simple) as lots of this wiki's articles you need a degree to read and are of no use to younger readers or ESL people. But I don't know how likely it is to occur. It seems to me something along those lines comes up on this page every year or so with some support and some against. -DJSasso (talk) 19:03, 21 January 2020 (UTC)
I think having a tab to SEWP is a good idea and will help in solving some of those problems shown in 2018 (I think most of them). It is very difficult for us to do any offline events, Workshops, and outreach activities because unlike other medium-sized language wikis where most of the editors are from a specific region, editors from Simplewiki are scattered all over the world.--BRP ever 21:09, 21 January 2020 (UTC)
A few thoughts from me... I'm a SEWP sysop and member of the community for some time now. The aforementioned tab script and it's SEWP companion, (enWPTab.js, introduce pretty awesome functionality for me, personally. However, I do agree that hitting the API every single time a page is loaded by every user using this script would tax the system after a while. It would have to be reworked, ideally as an extension as BrandonXLF stated. Next, I'd like to take a moment to address the point brought by Bluerasberry regarding the future of SEWP. In the sited proposal's closing remarks, LangCom quite clearly stated:

Please note that in the future, consistent with the above, requests to close this project that are based on "no language code" or "not different enough from English" may be closed speedily. Requests to close this project that are based on "inactivity" or "vandalism" will probably also be closed speedily, unless things change pretty radically at Simple English Wikipedia.

As far as "merger" requests go, LangCom certainly likes the idea of Simple English content being more accessible from English Wikipedia. Whether that should be accomplished through merging the projects or merely better coordination between the two projects is a matter for the communities to decide, not LangCom. In light of that, we will not entertain a request to "close and merge" unless it is presented as the consensus of both communities, and unless at least the broad outline of a plan to accomplish that is in place.

As such, I feel SEWP is project that will remain active for quite sometime to come. With that in mind, I find the closer integration of the two projects, either from a "Simple English" tab or button or {{Simple}} tag to be ideal for both projects. Granted, I see the future need for the SEWP community to arrive at a consensus to redefine the appropriate MOS to more readily complement a user experience swapping from the technical and high-leveled language of enwiki to the more basic and readable version of SEWP. The articles contained on enwiki are very thorough, well written, and technically in-depth for the most part. However, this praise is also the very problem SEWP seeks to correct. SEWP works to have articles written in a manner that is easily read by the student, the adult English student, and those not interested in technical explanations.
I got a bit long-winded here, but in summary, I would support a trial integration of the two projects. I find the tab is the better implementation, but it would need to be reworked from the script. SEWP isn't going anywhere and the communities of both as well as readers would be better served by close integration, but not merging. Operator873talkconnect 21:34, 21 January 2020 (UTC)
Personally I feel like the tab is a pretty big leap for a first step, but if people awnt that I'm okay with it. The one concern thoug his that sometimes english and simple can have different article titles, like movie vs. film, and we'd need some sort of way to tell it to point to a different title, perhaps with a magic word? Speaking of which, whether or not this tab will be an extension or javascript is another concern,an extension could be much more optimised but javascript would be easier to get added. Computer Fizz (talk) 01:23, 24 January 2020 (UTC)
Computer Fizz, we could query Wikidata for the page name on the Simple English Wikipedia since they should both be linked to the same Wikidata item.– BrandonXLF (talk) 22:12, 25 January 2020 (UTC)
@BrandonXLF: Not all pages are in Wikidata, but it does seem like a good idea to include for those who are, since it's both guaranteed to work if it is, and because it gives more of an incentive to keep wikidata up to date. Although this would most likely be an extension and not Javascript, are you any good at making extensions? Computer Fizz (talk) 22:15, 25 January 2020 (UTC)
Computer Fizz, they should all be on Wikidata, but if they aren't, we can fallback to seeing of the page of the same name exist on the SEWP. I would not say I'm good at making extensions, but I could try to make something. – BrandonXLF (talk) 22:19, 25 January 2020 (UTC)

@BrandonXLF: Sounds like a fantastic idea. Not sure how ENwiki goes about getting consensus for this stuff though, so I can't be of much help there but I can put in my strong support and post on phab. Computer Fizz (talk) 22:21, 25 January 2020 (UTC)

I have worked on the Simple English Wikipedia from 2018 until 2019, when I was blocked there two times. Anyway, I have proposed the following solution to the aforementioned problem. Firstly, there would be a tab called "Simple" between the "Article" and "Talk" tabs, no matter what skin is used. The "Simple" tab would use a different namespace called "Simple:" (e.g. if the article title is "SpaceX", clicking at the "Simple" tab would direct you to "Simple:SpaceX"). If you have concerns that the readers would not notice the "Simple" tab, do not worry. Many IP users encounter the talk page because they simply do not know what the "Talk" means in Wikipedia. --Soumyabrata (talk • subpages) 06:55, 23 January 2020 (UTC)
The Basque Wikipedia does something similar, with a kid-focused namespace. See w:eu:Frantzia (look for the button at the top with the colorful font) as an example. Most articles don't have an article in their kids' version. WhatamIdoing (talk) 17:30, 23 January 2020 (UTC)
  • I missed this discussion apparently, but trying to integrate Simple more closely with English would be a Bad Idea. SEWP should burn to the ground; if there wasn't enough support to close it, then at least we don't have to actively encourage its development from here. I, for one, would strongly oppose any effort to make the existence of SEWP even remotely more visible. –Deacon Vorbis (carbon • videos) 18:01, 23 January 2020 (UTC)
    • I would put it a little more gently. I think simple.wiki suffers from an unclear, self-contradictory, or simply impossible rationale. I haven't kept up, but years ago at least, the theory seemed to be that simple was just another language, and that the content would not be dumbed down, it would just be written using a restricted vocabulary.
      But of course that just isn't possible, not unless you want to increase the length of articles to the point that they become effectively unreadable for other reasons. It sounds good to say that you don't really understand something unless you can explain it to your grandmother, but unless you have an unusual grandmother, it just isn't true.
      When I've looked at simple.wiki articles on technical topics, they are either stubs with essentially no content, or they aren't written in Simple English.
      There might be an argument for a simplified Wikipedia (simplified in content, not just language). But we shouldn't pretend it's just a language. It would be a separate encyclopedia and there's no way it could support a one-for-one mapping of articles; some topics just could not be covered. --Trovatore (talk) 18:20, 23 January 2020 (UTC)
      • Think of it. I'm a vandal/blocked/pov/fringe/racist editor. I can't edit the main article or don't have consensus or whatever, but hey, there's a tab to an article on another Wikiproject I can use. And the Admins/editors on en.wiki won't have power there/be bothered to look at it, etc. Doug Weller talk
That's a really good argument against this idea. Unless there is some way to mitigate that problem, I do not believe a tab of any sort can be implemented successfully. Vermont (talk) 16:01, 24 January 2020 (UTC)
From my understanding, the project isn't acting as though it's an entirely different language. Take a look at simple:WP:HOW. The intention is to create articles that describe things in a way much more easily understandable. And yes, many of the more technical topics do not have great articles about them, but it's a constant work in progress, as are all projects. Vermont (talk) 16:01, 24 January 2020 (UTC)
Entirely different is not the issue. What I'm saying is, I'm skeptical that "language" is the right model at all. The page you pointed me to says [t]he language is simple, but the ideas don't have to be. What I'm saying is, that doesn't work. Complex ideas are frequently impossible to express clearly and efficiently in simple language. That's my objection to the whole simple.wiki concept. --Trovatore (talk) 19:25, 24 January 2020 (UTC)
Opposed Simply English has serious sourcing problems that would overwhelm our editors and lower the value of our information.--Moxy 🍁 23:44, 24 January 2020 (UTC)
  • Comment — In desktop mode, I can see the "Simple English" tab between "Article" and "Talk" tab, which redirects you to Simple English article.
Edit: You will not see this, because the tab is disappeared. --Soumyabrata (talk • subpages) 07:04, 1 February 2020 (UTC)

Using a metatemplate for non-free file tags

Most non-free file tags have a "To the uploader: " instruction box that is pretty much identical for all of them. Because of this, a while ago I did write Template:Uploader information to hold the text of this instruction box for present and future non-free file tags, as using a metatemplate makes it easier to write new non-free file tags and to do mass changes on old ones. I did apply it to some templates but as someone observed on this talk page I should probably ask in a single place if this is a good move before continuing. Jo-Jo Eumerus (talk) 14:08, 29 January 2020 (UTC)

Seems like a sensible use of a meta template to me. Significantly reduces redundant code, standardize the message so it can more easily be improved and in general makes maintenance easier. ‑‑Trialpears (talk) 15:28, 29 January 2020 (UTC)
Sure. If as you say it's the same text that is repeated, no reason why it can't use a template. --Gonnym (talk) 15:39, 29 January 2020 (UTC)
Gonnym There is a bit of variation between each template as they often suggest certain rationale tags or the like; the metatemplate has a |additional notes= parameter so that one can add extra text if it's necessary. Jo-Jo Eumerus (talk) 15:44, 29 January 2020 (UTC)

No objection. Jo-Jo, I have combined all your edit requests into one. I hope this okay — Martin (MSGJ · talk) 00:00, 1 February 2020 (UTC)

I don't think that's a problem. Anyone who had the templates on their watchlist will have seen the edit through which the edit requests were originally added. Jo-Jo Eumerus (talk) 08:52, 1 February 2020 (UTC)

I want to revive the Tampa bay buccaneers subproject on nfl.

Is this the right place to say it? New3400 (talk) 23:31, 2 February 2020 (UTC)

@New3400: I suggest starting a discussion at Wikipedia_talk:WikiProject_National_Football_League RudolfRed (talk) 05:27, 3 February 2020 (UTC)
This is about as close to unanimity as we get here. If the Foundation wants guidance as to what the en-wiki community thinks, they have it here. - Jmabel | Talk 06:18, 31 January 2020 (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.

Shortcut

The January 27 Signpost "From the editor" column describes the several years-long and ongoing paid advocacy abuse by Status Labs (formerly Wiki-PR), including their community ban from the English Wikipedia, their global ban imposed by the Foundation, a cease-and-desist letter sent in 2013, and six recent and ongoing paid advocacy abuses reported by the Wall Street Journal last month. Foundation officials told the Signpost that they would only take further action if the English Wikipedia community requests such "through its usual governing processes." Accordingly, this RFC asks the Wikimedia Foundation to enforce the Terms of Use against Status Labs violations, such as by reporting infringement of the Computer Fraud and Abuse Act, seeking civil penalties for those violations, and any other actions which the Foundation's attorneys believe will most likely halt the ongoing abuses. 07:30, 27 January 2020 (UTC)

Support

  1. Support as proposer. EllenCT (talk) 07:30, 27 January 2020 (UTC)
  2. Support per nom. The reputation of Wikipedia for trustworthiness relies, at a fundamental level, on our ability to enforce WP:NPOV against attacks from commercial interests. Undisclosed paid promotional editing by Wiki-PR and its peers threatens that. Strong action is needed to address this existential danger, and the WMF seems well positioned to provide it. Sdkb (talk) 08:44, 27 January 2020 (UTC)
  3. Support per WP:TOU. ——SN54129 09:46, 27 January 2020 (UTC)
  4. Support, this is a clear case where a community ban is not fully effective and WMF can assist in ensuring the abusive editors do not return. Seraphimblade Talk to me 09:52, 27 January 2020 (UTC)
  5. Support clearly the community's attempts to prevent their abuse have failed, so we require action from the WMF. SmartSE (talk) 10:07, 27 January 2020 (UTC)
  6. Support yes please - David Gerard (talk) 10:42, 27 January 2020 (UTC)
  7. Strong support: this isn't a rogue IP-hopping troll, but a large-scale company making it very clear they have no interest in Wikipedia's mission and even less respect for following our Terms of Use. Though our volunteer editors in this area do an exceptional job, it's one of the most boring and frustrating and least rewarding tasks on Wikipedia—it's a clear place for the WMF to step in and make sure things get enforced. We should give them a mandate to do so. If legal action against Status Labs will make them less likely to continue editing, great. If it has a chilling effect on other PR companies or companies looking to turn us into an advertising platform, great. — Bilorv (talk) 10:50, 27 January 2020 (UTC)#
  8. Strong Support - community efforts can only really act as mitigation, further action is needed. UPE, in this co-ordinated wilful breach style, is probably the biggest threat to Wikipedia. It also is an issue that the Community is happy to work with the WMF on, making it both clear-cut and a priority for the off-wiki "San-Fran Hammer". Good hunting. Nosebagbear (talk) 11:10, 27 January 2020 (UTC)
    This should also be taken to support action against any successor organisation, including but not limited to self-claimed links, shared directors, multiple shared operators etc etc. Nosebagbear (talk)
  9. Support based on my reading of the C&D and the Signpost, and the assumption the situation has been accurately reported. SportingFlyer T·C 11:38, 27 January 2020 (UTC)
  10. Support I insist that the WMF start spending its profit on lawyers to stop Status Labs, and all their affiliates, and all successor organizations to same. Chris Troutman (talk) 11:46, 27 January 2020 (UTC)
  11. This should also apply to First Page Management LLC as well and not just Status Labs or maybe any LLC based in Austin Texas to prevent this spam from happening again— Preceding unsigned comment added by 75.100.152.244 (talk) 11:53, 27 January 2020 (UTC)
    • "First Page Management" and "Blue Land Partners" both share the same address in Austin, TX with Status Labs and are mentioned in the press with Darius Fisher (Status Labs CEO) or similar. Blue Land Partners is not a real estate company, but a digital marketing firm which works on Facebook. There will be lots more names. BTW i checked the Wiki-PR website for an address - none given - but it's still running, you can still send in your email address to contact them, still the old Wikipedia advertising on offer. Smallbones(smalltalk) 16:44, 27 January 2020 (UTC)
  12. Support wholeheartedly Csgir (talk) 12:58, 27 January 2020 (UTC)
  13. Support, this shouldn't still be an issue. >>BEANS X2t 13:33, 27 January 2020 (UTC)
  14. Support per above. I would have expected WMF to act earlier, given they were aware of the situation, but anyway. Time to teach other ToU violators a good lesson. Brandmeistertalk 14:01, 27 January 2020 (UTC)
  15. Support. No questions asked. They have violated the neutral point of view policy, the policy on paid editing, and have circumvented blocks repeatedly. They should be shut down by any means necessary, in defense of the encyclopedia. I would suggest a WP:SNOW close, but I think this should go the full thirty days just to make sure that the strongest case possible can be made against Status Labs. InvalidOS (talk) 14:13, 27 January 2020 (UTC)
  16. Support It's about time the WMF showed some spine on this, instead of leaving the unpaid community to try and clear up after these well-funded promotional outfits. Yunshui 雲水 14:26, 27 January 2020 (UTC)
  17. Support The WMF needs to enforce their ToS and get these wastes of time off the site permanently. --moonythedwarf (Braden N.) 14:36, 27 January 2020 (UTC)
  18. Support: For the benefit of the project, support making this request. Also, if not already done, please inform the community liaison, the ARBCOM, the Executive Director, and the Board, especially Jimbo Wales and Doc James of this discussion. Alanscottwalker (talk) 15:04, 27 January 2020 (UTC)
  19. Support The volunteer editors of Wikipedia have donated our time and energy to make and maintain an educational resource. For all of Wikipedia's known shortcomings, it is increasingly respected as that most remarkable achievement in the Internet of 2020, not being a commercial dumpster fire. Status Labs and all their ilk are parasites upon the Wikipedia community. We owe it to our readers to oppose these hacks by any means within our grasp. And the Foundation owes us their aid. XOR'easter (talk) 15:09, 27 January 2020 (UTC)
  20. Strong support - my full view is at Wikipedia:Wikipedia Signpost/2020-01-27/From the editor (add) I'll post this RfC there and at WP:COIN Smallbones(smalltalk) 15:26, 27 January 2020 (UTC)
  21. Support - The situation has gotten this bad because of lack of enforcement. It's like graffiti when not cleaned up encourages more graffiti. -- GreenC 15:51, 27 January 2020 (UTC)
  22. Support, and as we like to say around here, my support is for taking action against Wiki-PR/Status Labs broadly construed. I support action against Status Labs and any successor organizations, subsidiaries, etc. They have acted contrary to the ToU and to community policy and haven't shown any indication of wanting to play by the rules, so time to escalate. creffpublic a creffett franchise (talk to the boss) 16:01, 27 January 2020 (UTC)
  23. Support per all of the above - Argento Surfer (talk) 16:28, 27 January 2020 (UTC)
  24. Strongest possible support I don't know why we even need an RFC for this. This type of paid editing is beyond the small time fiverr garbage and is a completely deceptive and fraudulent practice. By not pursuing this, it sends a message that the policies are just there to scare people, rather than to be enforced. The hard work is already done, they know the identities of these violators, now do something about it. Praxidicae (talk) 16:34, 27 January 2020 (UTC)
    • @Praxidicae: Re why do we need an RFC for this: I am very much not comfortable with the WMF independently taking this on without community approval. Even if the community decides to delegate to the WMF the authority of taking legal action against such groups in general, it should come from a community decision originally. This should be part of a category of things which are ultimately up to the decision of the community (with Legal having veto power, I would guess), and this RFC sets a good precedent. --Yair rand (talk) 17:57, 27 January 2020 (UTC)
  25. Strong support. We need help with this. SarahSV (talk) 17:00, 27 January 2020 (UTC)
  26. Support - The way Status Labs/Wiki-PR etc. behaves is unacceptable. They are continuing to do what they used to do, despite all the actions and warnings of the WMF and the community. And it's not just them, their activity may encourage other PR companies to start working on Wikipedia. For years, the community has been trying to stop this - now, I think we should expect the Foundation to take a strict action against this. Ahmadtalk 17:04, 27 January 2020 (UTC)
  27. Support - yes, please enforce the TOU on this group.
     — Berean Hunter (talk) 17:15, 27 January 2020 (UTC)
  28. Support. Allowing continued abuse like this not only erodes our trustworthiness, but drives away legitimate volunteer contributors. -- RoySmith (talk) 17:24, 27 January 2020 (UTC)
    Note: you can transclude User:RoySmith/TOUSL banner on your user page to help publicize this. -- RoySmith (talk) 17:41, 27 January 2020 (UTC)
  29. Support. This is a large-scale organization based around abusing Wikipedia, and causing substantial harm. I would also recommend that the WMF pursue this partly with the aim of deterring future actions by similar organizations. --Yair rand (talk) 17:57, 27 January 2020 (UTC)
  30. Support. Not only should the WMF enforce the terms of use as stringently as possible, but possibly pursue monetary damages as well. oknazevad (talk) 18:16, 27 January 2020 (UTC)
  31. Support no-brainer. buidhe 18:36, 27 January 2020 (UTC)
  32. Support - no doubt they'll just close down and spawn another company to continue on as before, but we have no other recourse. Apart from, you know, the WMF actually prioritizing software development competently. MER-C 18:52, 27 January 2020 (UTC)
  33. Support, obviously. —David Eppstein (talk) 19:05, 27 January 2020 (UTC)
  34. Support The Foundation exists to help volunteers by taking institutional actions volunteers cannot. Clearly the community needs help in dealing with this issue and we have struggled to protect the encyclopedia with the tools we have. The Foundation should seek compensatory and punitive damages to offset the cost of protecting the encyclopedia from their violations of the terms of service, and to deter future organizations from violating the terms of service in a similar manner. — Wug·a·po·des​ 19:12, 27 January 2020 (UTC)
  35. Strong support Headbomb {t · c · p · b} 19:27, 27 January 2020 (UTC)
  36. Support I commented at The Signpost article. We have a case of multi-year exploitation of Wikimedia community resources, including volunteer labor, financial pool, and good will. If the barrier to enforcement is the Wikimedia Foundation legal team seeking Wikimedia community encouragement, then take that encouragement now and protect us editors and our readers with enforcement of our terms of use. I would also appreciate the Wikimedia Foundation legal team investing in the creation of cultural products for the Wiki community to understand what to expect of legal services in this and other cases. I often push back at Wikimedia Foundation investment in its own staff. However, for legal services, I would not want to crowdsource this, and I am happy for the WMF to manage this centrally, and I appreciate attention and engagement from WMF legal in the scope of its responsibility. Of the activities in which the WMF engages, legal services is one with greater encouragement from the wiki community. Blue Rasberry (talk) 19:40, 27 January 2020 (UTC)
  37. Support--Goldsztajn (talk) 20:03, 27 January 2020 (UTC)
  38. Conditional support but only with concurrence of the WP:Arbitration Committee. This can be by a simple resolution, no need for them to open a new case. I see cases like this in the future, so I want to set a precedent for ARBCOM involvement. Having ARBCOM on board does two things: 1) If there are reasons NOT to go to the WMF that are not public, they can put the break on this before it gets to the Foundation, and 2) having both the "elected representatives" and the community explicitly on board with this will speak louder to the WMF than only having one or the other. I will discuss "future situations" in the discussion below. davidwr/(talk)/(contribs) 20:09, 27 January 2020 (UTC)
  39. Support after reading the Signpost article, I was alerted to the severity of this problem. Taewangkorea (talk) 20:29, 27 January 2020 (UTC)
  40. Strong support - Enough is enough, If they're not going to listen to the advice on wiki and ignore the cease-and-desist letter than they should feel the full force of the law, We as a community and WMF as the organisation should not have to put with this. –Davey2010Talk 20:33, 27 January 2020 (UTC)
  41. Support - The English Wikipedia is a volunteer community, and undisclosed paid editing is against our terms of use. Status Labs (or whatever they change their name to in the future) should not be violating their ban and continuing to violate our terms of use. Clovermoss (talk) 20:43, 27 January 2020 (UTC)
  42. Support -- Hopefully enough people sign on to force this to become its own subpage. -- llywrch (talk) 21:09, 27 January 2020 (UTC)
  43. Support - The community needs to give the Foundation a very strong mandate and deliver to the entire world a message that we believe in our mission. – Finnusertop (talk ⋅ contribs) 21:19, 27 January 2020 (UTC)
  44. Support GMGtalk 21:24, 27 January 2020 (UTC)
  45. Support obviously.Pharaoh of the Wizards (talk) 21:29, 27 January 2020 (UTC)
  46. Support this is the kind of thing I want the foundation to do. Protect our interests when the community can not. Applause to the foundation for asking the community even though it seems like there may be snow here. ‑‑Trialpears (talk) 21:39, 27 January 2020 (UTC)
  47. Support as they've clearly shown—many times over—they have no intention of working within the established policies and guidelines. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 21:41, 27 January 2020 (UTC)
  48. Makes sense, but I support this with the understanding that it's up to the WMF's lawyers to determine which legal course of action, if any, has any prospect of obtaining effective relief. May I also say that I find it somewhat amusing that we, the Wikipedia community, are now in corpore climbing the Reichstag to make legal threats? Sandstein 21:45, 27 January 2020 (UTC)
    I'm glad someone appreciates the irony. It's difficult for me to, after looking at some of the things which the legal department has been spending money on. I hope this is at least a light at the end of the tunnel and might give us some options to deal with the Upwork freelancing issues. EllenCT (talk) 23:02, 28 January 2020 (UTC)
  49. Support This is one of the very few things we actually need the foundation for. it's bad enough when they waste resources on unnecessary or counterproductive projects, it's worse when they do not support productive projects, but refusing to do the critical actions needed to protect the community and the projects is the bottom line. DGG ( talk ) 22:00, 27 January 2020 (UTC)
  50. Support per Sandstein. Interesting, perhaps we must all now cease editing per WP:NLT. Or perhaps this is politely reporting a legal problem. Gråbergs Gråa Sång (talk) 22:03, 27 January 2020 (UTC)
  51. Strongest possible support. It is blatantly obvious that this situation is an epidemic and that the organization that banned Fram have an obligation to Wikipedia's editors and readers to deal with this as harshly as possible. —pythoncoder (talk | contribs) 22:21, 27 January 2020 (UTC)
  52. Support. If there is any action that the Foundation can take that they are not already doing, I urge them to take it. Espresso Addict (talk) 23:03, 27 January 2020 (UTC)
  53. Support Wikipedia is known as a site to help combat misinformation on the internet by providing unbiased facts. We shouldn't let Status Labs change this. Daylen (talk) 23:20, 27 January 2020 (UTC)
  54. Support 100000% needed, 10000% wanted. Also WMF, if the name of the company changes this should not deter your efforts to pursue legal action. This needs to stop. This is why the TOU was changed, so please do something about it. I know a case may be expensive, but this needs to stop. Dreamy Jazz 🎷 talk to me | my contributions 00:56, 28 January 2020 (UTC)
  55. Strongest possible support. IHMO, all paid editing should be banned. Catgirllover4ever (talk) 02:28, 28 January 2020 (UTC)
  56. Support obviously. L293D (☎ • ✎) 02:30, 28 January 2020 (UTC)
  57. Strong support this and similar organisations are a critical threat to Wikipedia's ability to provide unbiased information. – Teratix ₵ 02:55, 28 January 2020 (UTC)
  58. Support As far as I'm aware, the WMF typically trys to avoid suing people who contribute, for better or for worse. I'm generally in agreement with this position, as legal threats aren't something anyone editing in good faith should have to worry about. I also despise unnecessary invocations of the CFAA, especially since TOU violations have been found to not be CFAA issues, Aarron Swartz notwithstanding. However, this group is not editing in good faith, and we as the community have exhausted all of the options available to us. It is up to the WMF to use resources we alone can not to deal with this pervasive issue. --AntiCompositeNumber (talk) 03:14, 28 January 2020 (UTC)
  59. Support for the widest ranging and most thorough-going action against this particular outfit and all similar corrupters of the encyclopaedia that WMF Legal considers possible. It has to hurt before these people will get the message. Mccapra (talk) 04:48, 28 January 2020 (UTC)
  60. Support - fighting promotional editing is a rather useless exercise with WMF's floodgates wide open, and no proper follow-up from WMF on the more egregious cases. This at least will make a statement (though the larger companies will likely not care even a little bit, they will just continue under a different flag) which may make some companies think twice. But WMF, can you finally make an effort in upgrading our system to be able to better handle/combat these? This is surely not the only company that does this. Thanks. --Dirk Beetstra T C 05:09, 28 January 2020 (UTC)
  61. Support - if the WMF has resources to sue the NSA and Turkey, why can't it take action against a company clearly violating its Terms of Service? Darylgolden(talk) Ping when replying 05:30, 28 January 2020 (UTC)
  62. I'm just going to pile on here. – John M Wolfson (talk • contribs) 06:25, 28 January 2020 (UTC)
  63. Support. Something must be done about this problem. —Bruce1eetalk 06:59, 28 January 2020 (UTC)
  64. Support. Pretty obvious something needs to be done at a higher level here. ♠PMC♠ (talk) 07:31, 28 January 2020 (UTC)
  65. Support, obviously.ThatMontrealIP (talk) 07:44, 28 January 2020 (UTC)
  66. Support. We need to send an unambiguous message to WMF that we want them to do this. It is fair for this to be necessary before they act, as they have acted against the community preferences before, raising shitstorms of note. By making this a clear request from the community, we indicate that in this we are on the same side and they can act on our behalf with our support to do the job they are there to do. I see this RfC as both necessary and sufficient for WMF Legal to throw the book at Status Labs. · · · Peter Southwood (talk): 07:55, 28 January 2020 (UTC)
  67. Support Our encyclopedia needs to be protected from those who want to misuse it for their own commercial gain. PamD 08:00, 28 January 2020 (UTC)
  68. Support. If someone is violating the law and profiteering from it, the WMF needs to pursue all legal options to stop this. Regards SoWhy 08:53, 28 January 2020 (UTC)
  69. Support. In this circumstance, it's beyond our (WP community) power to enforce your (WMF) TOS to the extent necessary to protect your mission. DMacks (talk) 12:25, 28 January 2020 (UTC)
  70. Support. This is the perfect example in which WMF should get involved to support its projects and its communities, and spend some money to defend them; instead of squandering donors' money in 'rebranding' nonsenses nobody asked for. —MarcoAurelio (talk) 12:39, 28 January 2020 (UTC)
  71. Support - Seems like more drastic measures are needed at this point. Kaldari (talk) 12:40, 28 January 2020 (UTC)
  72. Support Jakob.scholbach (talk) 12:42, 28 January 2020 (UTC)
  73. Support This is an area where action by WMF is clearly wanted and necessary, because they are the only one who can take legal action in this case. — Preceding unsigned comment added by Vexations (talk • contribs)
  74. Support Obviously. The community has no recourse here other than WMF action. shoy (reactions) 15:30, 28 January 2020 (UTC)
  75. Yes please. In more generality, paid editing is one area where the WMF could possible help WP editors, as privacy issues make the fight one that is very difficult to do in the open. —Kusma (t·c) 15:45, 28 January 2020 (UTC)
  76. Support absolutely. WMF should legally pursue this, and all other companies that profit by breaching our Terms of Service – and have a proactive approach of doing this on an ongoing basis. ‑‑YodinT 15:49, 28 January 2020 (UTC)
  77. Strong support In this situation, we should err on the side of being too aggressive in removing these, and taking legal action. If a company is notable, genuine editors will create articles and there will be no loss of knowledge. Paulmlieberman (talk) 17:53, 28 January 2020 (UTC)
  78. Support - a ban only makes sense if enforced, a un-enforced ban is a call for others to do the same. - Nabla (talk) 18:05, 28 January 2020 (UTC)
  79. TOU enforcement is exactly the kind of support that the WMF could and should be providing to its communities, and $100 million a year pays for enough lawyers to get it done. Levivich 18:39, 28 January 2020 (UTC)
  80. Support When the ToU was re-written, more attention was placed to prohibit harmful activity. Here, the community position that a corporation's activity was harmful, and so the WMF should be acting on the community's behalf to get an end to the activity. The banning of the corporation should be enough to engage the WMF for any enforcement; having RfCs should be un-necessary. ~~Ebe123~~ → report 18:56, 28 January 2020 (UTC)
  81. Conditional support per davidwr. While having the WMF take action on its own would be great, it would be a slippery slope to allow for WMF to act in the name of the community at large without an RfC to demonstrate consensus. Even if this RfC and/or an ArbCom declaration seem to be mere formalities, we should not delegate the decision of what is and is not important to the community to the WMF entirely. <RetroCraft314 /> 21:39, 28 January 2020 (UTC)
  82. Support Integrity requires maintenance and this is more than volunteers should handle. Johnuniq (talk) 22:12, 28 January 2020 (UTC)
  83. I'm not clear why the community has to ask the WMF for this, but if we do, then I so ask.—S Marshall T/C 23:47, 28 January 2020 (UTC)
  84. Support Inasmuch as this RfC constitutes the "normal governing process" referred to by the WMF (are all TOU violations enforced through RfC's?) then yes, it should be used to send this message.  Spintendo  00:40, 29 January 2020 (UTC)
  85. Support per Integrity. GenQuest "Talk to Me" 00:51, 29 January 2020 (UTC)
  86. Support Like S Marshall above, I'm not sure why we need to put pressure on the WMF about this, but hey... Pichpich (talk) 04:07, 29 January 2020 (UTC)
  87. Something needs to be done with this. J947 (c), at 04:30, 29 January 2020 (UTC)
  88. Support Enough community time and resources have been wasted on dealing with this same group, and they've flouted their willful violation of our terms of use with the press. It's clear that they have no respect for our policies or practices, so asking the foundation and their legal team to step in on our behalf is, unfortunately, the last option left. OhKayeSierra (talk) 10:15, 29 January 2020 (UTC)
  89. Support per all of the above, this abuse must stop. Roger (Dodger67) (talk) 12:19, 29 January 2020 (UTC)
  90. Support for the sake of eliminating the ridiculous "waiting for the community to request" excuse for the WMF not enforcing its own Terms of Use. Yes, we want you to enforce it. Let the lawyers work out the details. Ivanvector (Talk/Edits) 17:07, 29 January 2020 (UTC)
  91. Support: Wikipedia's ability to serve its basic function as a provider of reliable, neutral facts is imperiled by this sort of abuse. Do everything that can be done to stop it. -Bryan Rutherford (talk) 17:17, 29 January 2020 (UTC)
  92. Support The only useful thing the Foundation does for the project is to protect and support the project where its volunteers cannot. This is a perfect example of what they should be doing to protect the project. --Jayron32 17:22, 29 January 2020 (UTC)
  93. Support OhanaUnitedTalk page 21:51, 29 January 2020 (UTC)
  94. Support although I'm doubtful as to how much effect this will actually have on WMF's eventual decision. --Joshualouie711talk 01:07, 30 January 2020 (UTC)
  95. Support - It is high time the Foundation spent the donations given to it to properly support and defend the community that makes those donations possible. This should have been a no-brainer. Any paid-editing firms discovered in the future should meet the same legal fate, otherwise the Terms of Use serve no real purpose. — Coffee // have a ☕️ // beans // 10:27, 30 January 2020 (UTC)
  96. Absolutely. While it could lead to a game of "whack-a-mole" it could also serve as a warning to others and prevent future abuse. Regardless, should be done. ~ Amory (u • t • c) 18:52, 30 January 2020 (UTC)
  97. Absolute 100% Support - if not, what are the options for volunteers? Maybe, pick one of the following: (1) continue doing what you've been doing and ignore paid editing, (2) stop editing WP all together in protest, (3) find a way to be compensated for your work, (4) encourage WMF to eliminate anonymity for editors who create/expand business articles and (5) create a Business WP. Just throwing out some initial thoughts...Atsme Talk 📧 21:45, 30 January 2020 (UTC)
    Comment - it's good idea to come up with ideas for new policies, e.g. "eliminate anonymity for editors who create/expand business article." If done right that could really help, e.g. we could know that an employee of the company "General Gunk" was editing the General Gunk article and perhaps ban them and the company. But if they keep on coming back with new socks, what do we do them? Site banning? But what if they keep on coming back with new socks. Sooner or later, somebody would ultimately have to take them to court if they just keep on defying the rules. That's what needs to happen with the Wiki-PR case. Six years is just too long to wait! Smallbones(smalltalk) 22:56, 30 January 2020 (UTC)
    @Smallbones: while I agree that it is good to come up with new ideas, I would be against a policy that would require some schoolkid working on a project that involved creating or writing an article about a business to have to give up his anonymity. It would have a large chilling effect. davidwr/(talk)/(contribs) 23:34, 30 January 2020 (UTC)
    Sorry if I wasn't clear, my point was not that "eliminating anonymity for business articles" is the perfect idea for a new policy (any new policy will have pluses and minuses), but that ultimately, when you have a policy-violator who just won't quit, that strong enforcment of the policy is needed. Smallbones(smalltalk) 23:49, 30 January 2020 (UTC)
  98. Strong support - every wasted second editors and admins spend on weeding out the garbage to defend Wikipedia's already oft-questioned integrity is time forever stolen that could've been better spent creating reputable, informative articles. Please do whatever is necessary to help. LovelyLillith (talk) 00:19, 31 January 2020 (UTC)
  99. Support The WMF is the only body that can take plausible and effective legal action against these spammers, through its legal counsel. They should act against any and all present and future business entities and all involved individuals who own, operate and manage these sockpuppet farms. And the WMF should publicize those legal actions as a deterrent against bad actors. Cullen328 Let's discuss it 02:14, 31 January 2020 (UTC)
  100. Support fully. I can't imagine why one would not want the community consensus enforced to the greatest extent possible. For further rationale, User:Bri/What's wrong with undisclosed paid editing. This entity's product is the worst example of the ill coming from UPE, and their business model is entirely based on UPE. There is no conceivable circumstance under which they would be welcome editors. ☆ Bri (talk) 05:37, 31 January 2020 (UTC)
  101. Support It is clear that policy changes and administrator upkeep can keep Wikipedia only a little bit clean. Without enforcement against repeat (and in this case corporate) rule breakers, we cannot hope to seriously tackle improper edits. Llemiles (talk) 18:53, 1 February 2020 (UTC)
  102. Support ~ ToBeFree (talk) 16:41, 3 February 2020 (UTC)

Oppose

  1. This would be a waste of money. Legal whack-a-mole. The costs would dwarf any actual outcome and the TOU are technically unenforceable anyway. If we are asking the WMF to spend cash to pursue legal action, then it needs to be against named individuals with long histories of harassment of editors and admins, of which the WMF is well aware of, before we start on the paid editing. Only in death does duty end (talk) 17:29, 29 January 2020 (UTC)
    That is something that the WMF should follow legal advice about. They have said that the reason for not taking action is that the community has not asked them to, not because the advice that they have received is that such action would not be successful. We are in a position to remove that barrier to action. Phil Bridger (talk) 17:52, 29 January 2020 (UTC)
  2. Oppose per OID. I think shutting down promotional spammers is something everyone can agree on, so I'm not sure that an RFC saying "go get 'em" is what WMF is referring to with regards to "usual governing processes". I think they want something a bit more substantive indicating against which specific parties the enforcement should take place and the manner in which said enforcement is to be carried out.--WaltCip (talk) 18:05, 29 January 2020 (UTC)
    The specific party and manner is specified in the RFC statement. 2601:647:5E80:1850:A400:BF31:236E:767B (talk) 18:32, 29 January 2020 (UTC)

Neutral

Discussion

  • Clearly this group of undesired individuals likes changing their name. Would a tweak to the RfC to in effect create a standing request to act against any future form of this organisation be beneficial, or is it better to just run a new RfC each time a new variant is identified? Nosebagbear (talk) 11:10, 27 January 2020 (UTC)
  • Is this only an "English Wikipedia" problem? The information above suggests this may be a "global" problem, if so I'm a bit confused as to why WMF legal is asking that they get a request from only the enwiki community? — xaosflux Talk 20:21, 27 January 2020 (UTC)
    • Although it is a global problem, I'm glad the WMF sees itself as serving the community, not dictating to it. If I recall, a few years ago they tried to push down something to one of the national Wikipedias and the pushback caused a huge uproar. They rolled back their change and thankfully seem reluctant to make that mistake again. davidwr/(talk)/(contribs) 20:26, 27 January 2020 (UTC)
      • @Davidwr: is enwiki the only sizable project affected here - or is this going to have to be repeated over and over at eswiki, dewiki, ptwiki etc. Perhaps these global type issues should go on meta-wiki so it can get global audiences? — xaosflux Talk 20:32, 27 January 2020 (UTC)
        • I don't think it makes a difference whether it will also affect other projects. We're asking for these actions based on the effect this is having on enwiki alone. I think that other projects could make similar requests to the WMF without requiring consulting enwiki, and that the WMF could take legal action based on issues from any individual project. --Yair rand (talk) 20:39, 27 January 2020 (UTC)
          • @Yair rand: obviously WMF legal team is a very limited resource - and if they are really taking a stance of needing each community to buy in the could become exhausted in having to file the same request over and over for each community to the same respondent. I'm all for fixing our local problem - but this really seems like a think-of-all projects situation. Is there a specific attributable response from legal that this has to be dealt with project-by-project? — xaosflux Talk 21:13, 27 January 2020 (UTC)
            • My guess is that they need a minimum of one community to request action with plausible cause. The size of the community may not be critical, but large can't do any harm. We could ask. · · · Peter Southwood (talk): 09:17, 28 January 2020 (UTC)
WMF legal team can be supplemented by outside counsel. It would be different if this were 2001 and there wasn't the money. DGG ( talk ) 22:03, 27 January 2020 (UTC)
Xaosflux. I believe the plaintiff would be the WMF itself and not each community. As the WMF and its servers hosting all projects are under US jurisdiction this works well because so is Status Labs which is in Texas. It should be sufficient that en.wiki reaches a consensus and WMF should be able to carry out the suit for all of its projects which are under the same Terms of Use. Consensus here is a catalyst to get the ball rolling.
 — Berean Hunter (talk) 22:43, 27 January 2020 (UTC)
Sure, but enwiki !=US wikipedia anymore then it is Australia wiki, nor any less then the Spanish Wikipedia wouldn't have standing in the United States. — xaosflux Talk 23:54, 27 January 2020 (UTC)
If they are acting on breach of WMF terms of use, it should not matter which projects are involved, only that they have requested WMF to do something about it, so that it is clear that WMF legal is not encroaching on the community self-governance and has community support. I think this is the right way for them to go about it. · · · Peter Southwood (talk): 09:25, 28 January 2020 (UTC)
  • I see other promotional companies trying to do this in the future. I recommend starting a new RfC or two for how to handle future cases like this. The first RfC would be to decide what we as a community should do to deter, fix, and disrupt such editing in the future. As just one idea, articles about certain companies or industries and their products could be put under mild "discretionary sanctions" regimes, with the remedy being that such articles can be placed under WP:Protection policy#Pending changes protection or WP:Protection policy#Extended confirmed protection in response to suspected WP:Paid editing or other WP:Spamming. The second RfC would discuss setting up a quick-response communications channel between the community, probably but not necessarily by way of the WP:Arbitration Committee, and a representative of the WP:Wikimedia Foundation. This way, if it became clear the community wanted the Foundation to take legal or other action against a different spam-house beyond what can be done "locally," the process would already be in place. davidwr/(talk)/(contribs) 20:24, 27 January 2020 (UTC)
    • We could do with a third RFC, specifically requesting technology improvements that increase capacity for dealing with this crap. The WMF should commit to spending whatever proceeds there are from the lawsuit on such improvements. MER-C 21:03, 27 January 2020 (UTC)
      • I'm all for spending money on technology improvements whether there is any lawsuit or not. I don't think an RfC is required for that, but it might help get their attention. Also, I'm not sure I want to "bind the hands" of the Foundation when it comes to lawsuit proceeds. For example, they may want to "not look greedy" (appearing greedy is bad for PR) and pledge in advance to donate net proceeds of any lawsuit to an unaffiliated organization. I don't want to interfere with that if they choose to make that pledge. davidwr/(talk)/(contribs) 21:21, 27 January 2020 (UTC)
  • Would a maintenence category for articles which have been affected by paid whitewashing be useful? — Preceding unsigned comment added by Pbsouthwood (talk • contribs) 09:25, 28 January 2020 (UTC)
  • While I certainly agree that WMF should be pursuing legal action against persistent corporate TOU violators who are profiteering off our volunteer efforts, there's also more that we can be doing internal to enwiki. We need to be more aggressive about deleting spam. It's disheartening to see arguments at AfD along the lines of, Everything is backed by WP:RS, so it has to stay. All that says is, As long as it's well-written spam, it's OK. Even worse is the WP:BOGOF crowd, who seem determined to legitimize the abuse. There must be some kind of self-hate thing going on there. For the most part, we're not stupid. We recognize spam when we see it. A brand new user (plus or minus the autoconfirmed threshold) drops down a perfectly formatted, carefully referenced, 1000-word puff piece, complete with studio-quality publicity photos. There should be a WP:CSD for that. And if that's too far a leap for people, then we should at least be working hard to change the culture at AfD to get those things gone fast. We've got, for example, 600-ish entries from 2019 in Category:Wikipedia articles with undisclosed paid content. That's 600 commissions paid to spammers. We need to hit them where it hurts. If their articles don't get published, they don't get paid. -- RoySmith (talk) 15:12, 29 January 2020 (UTC)
  • I often do a kind of negative variant of WP:BOGOF on corporate articles at AfD: if the article looks unsustainable I add such references as I can find or at least mention them in my AfD rationale, this being so that the AfD deletion has demonstrably taken account of the best possible evidence, so that this can be extended to subsequent CSD G4 or 2nd AfD after a repost. Regarding RoySmith's point about the balance, I do think it can be made more harsh, so that the client perceives negative consequences as soon as their commissioned spammer's effort has been deleted at AfD. The community has put in the scrutiny effort once, so post-AfD why shouldn't the article automatically be blocked from re-creation other than by admin action? AfC should be the only way back (and should take full consideration of the AfD consensus). And would it be possible to provide a search return to Google etc. not of the deleted article but of a simple text such as "An article of this name was deleted on grounds of non-notability", as a further disincentive to spammers' clients finding themselves with a lot less than they thought they were purchasing? AllyD (talk) 14:42, 30 January 2020 (UTC)

Hey all. Will share this with the rest of the board. Undisclosed paid promotional editing is something I have long considered a serious threat to the reliability of Wikipedia. Doc James (talk · contribs · email) 04:10, 30 January 2020 (UTC)

Doc James, much appreciated! If you're able to, please let us know how it's received. Seraphimblade Talk to me 04:34, 30 January 2020 (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.

Displaying "Smart Citations" Next to Scholarly References on Wikipedia

My name is Josh Nicholson and I am the co-founder and CEO of scite. scite is a new platform that allows anyone to see how a scientific paper has been cited, not just how many times and, specifically, if it has been supported or contradicted. We do this by analyzing millions of scientific articles, extracting the citation context, and then applying our deep learning model to identify citation statements as supporting, contradicting, or mentioning. We recently announced an integration to display our smart citations with BioTechniques (https://www.future-science-group.com/fsg-and-scite-partnership) and Europe PMC (http://blog.europepmc.org/2020/01/europe-pmc-integrates-smart-citations.html) and have signed indexing agreements with a handful of major publishers to analyze their full-text (BMJ, Karger, Future Science Group, Rockefeller University Press, and Wiley).

I believe that displaying scite's "smart citations" next to scholarly references in Wikipedia would make Wikipedia even more of an amazing resource for humanity and wanted to see if this is possible. I know I am not the first third-party company trying to integrate with Wikipedia but I think because citations are so central to Wikipedia and what we're doing at scite is really trying to evolve them there may be a way (https://www.wiley.com/network/latest-content/all-citations-aren-t-created-equal). You can see what such an integration could look like on references here. From a technical perspective, I think it should be quite simple (we offer integration via API or a small HTML snippet).

I'd love to hear your thoughts on this and would be happy to answer any questions.

Thanks so much, Josh

PS you can see an example of my own research here which should give you an idea of how scite works on an article you've never seen: https://scite.ai/reports/chromosome-mis-segregation-and-cytokinesis-failure-nM3vVr — Preceding unsigned comment added by Jdiogenes86 (talk • contribs) 14:21, 24 January 2020 (UTC)

@Jdiogenes86: Thanks a lot for your interest in improving Wikipedia. This indeed looks quite neat.
At this stage though, I don't think a consensus can be established to allow you to directly edit the WP articles to add scite data to them. What you can do is one or both of:
  • Create a bot that scours through papers cited on WP, looks up the scite info for them, and identify the ones that have too high contradiction rates. This data can be posted to a subpage (such as User:Jdiogenes86/contradicted papers) so that editors can manually review them.
  • Create a user script to allow editors to see these scite links next to the citations on articles.
For building a bot, there is the Action API and the newer REST API. The former is associated with good client-side libraries like mwclient and pywikibot.
You may also want to contact the folks at WT:WikiProject Academic Journals and WT:WikiProject Science. SD0001 (talk) 10:39, 27 January 2020 (UTC)
Let me start by saying that I think the concept of smart citations sounds very intriguing and is worth exploring. That said, implementing it would not be a small decision, but a big deal decision that requires the involvement in the signoff of the community. While I think @SD0001: identifies some good tools, as well as some places for further discussion, I suggest the cart is before the horse — we are not quite ready to fine tune the implementation, we need a lot more information before going ahead. I anticipate a lot of pushback about the notion of wholesale incorporation of material from an outside vendor without significant review.
One specific suggestion is that it might be useful to utilize a test wiki such as this (or perhaps there is a more suitable option). I'd like to see this in action on some real articles which could be copied over to the test wiki, but I want to see it in a testing environment before I see it in Wikipedia itself.--S Philbrick(Talk) 18:27, 27 January 2020 (UTC)
This is also discussed on the WikiCite mailing list (on Google Groups). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:13, 27 January 2020 (UTC)
I like the general concept but it would be a very bad idea if Wikipedia was seen as endorsing any particular company or any particular proprietary product. The general concept of "smart citations" sounds good, but before adopting it, the protocols would have to be in the public domain. Ideally, any implementation would be in the public domain and not rely on data whose access would benefit any person or for-profit entity. That said, we do have precedent for putting things like {{IMDB}} at the end of movie articles, even though this links to the Internet Movie Database, which is run by a for-profit company. I'm just saying that as long as it sounds like someone will benefit financially from your idea, it will have a very hard time gaining traction. Also Jdiogenes86, please read WP:Conflict of interest and WP:Paid editing. davidwr/(talk)/(contribs) 21:31, 27 January 2020 (UTC)

@Sphilbrick: Thank you for the useful suggestions and feedback. I anticipated that this was not something that would just immediately or easily be rolled out to all pages linking to science articles. However, I figured it was worthy of discussion and I am happy to receive such constructive feedback from various members of the community already. In particular, I think your suggestion to build a tool for editors seems like a good practical first step. I am talking to two members from the Wikimedia team soon and I will bring up this idea and others on our call. I'll also reach out to WT:WikiProject Academic Journals and WT:WikiProject Science to get their feedback when I get some time. Thanks again!

@Davidwr: I fully agree with you that it could be dangerous for Wikipedia to endorse products and companies. And, obviously, I am biased and stand to potentially gain financially from such an integration between scite and Wikipedia, even if only indirectly. With that said, I am not sure there is a way to fully implement such an idea in the public domain now or ever. Here is why I think that:

1) In order to provide smart citations, scite (or anyone for that matter) needs access to the full-text of scientific articles. As you may be aware, most research articles are under restrictive copyright licenses held by the publishers. We have signed licesning agreements with these publishers to be able to text mine their papers in order to create the scite website. As part of these agreements, we cannot re-distribute the full-text articles or the citation snippets to any third party. We can and do share citation tallies (the counts of the citations organized by classification) and are happy to open these up even further. However, these numbers without the snippets or links to the snippets themselves, would not be useful in the proposal above. I think it is necessary if we are to classify a citation statement as supporting, contradicting, or mentioning that readers can easily verify this information. It would be doable, of course, but it would be a silly implementation.

2) Citations, let alone smart citations like we are implementing, are still mostly closed and not in the public domain. There has been a massive effort to open citations (https://i4oc.org/), which we applaud, but even this implementation, which is fundamentally more basic than what we are proposing is having difficulty.

Thus, I think the question we should be asking is not can this be made open or not (I don't think it can given the restrictions from publishers) but do we think the benefits of this resource (allowing millions of people to see how a study has been cited, specifically if it has been supported or contradicted) outweigh the costs (driving traffic to a for-profit company). Maybe there is some agreement between wikimedia and scite that could limit any overreach scite would have? This we would certainly be open to discussing.

Also, I appreciate the links to paid posts and COI policies of Wikipedia, I was aware of such policies at a high level I hope that it is clear to everyone reading these messages that I have no intent of trying to misrepresent myself or scite. — Preceding unsigned comment added by Jdiogenes86 (talk • contribs) 19:42, 28 January 2020 (UTC)

@Jdiogenes86: The failure of the perennial proposal Use reCAPTCHA may give you some background for preferring "free" - as in non-proprietary - solutions to problems. If a non-profit entity was doing work similar to yours as a public good, the "who will get rich" issue would be much less of an issue, or likely it wouldn't be an issue at all, assuming the non-profit had good governance, good accountability, had no highly-paid employees, and was otherwise seen as a responsible non-profit. Hopefully, as academic research moves more towards a "free access journal" model, even the non-free-access journals will open up their abstracts, bibliographies, and other "meta data" more than they already do. davidwr/(talk)/(contribs) 20:39, 28 January 2020 (UTC)
@Davidwr: Thanks for the context and history on reCAPTCHA. It makes sense that a non-proprietary solution was implemented there. If such a non-proprietary solution existed for scite, it would indeed make sense to go with that. However, there is no alternative (non-profit or for-profit) that offers what scite offers today. Moreover, if scite were a non-profit it would not have the resources to do what it does, which is quite costly computationally—our funding comes primarily from NIH and NSF SBIR grants which require companies to be for-profit. Why not implement what exists today *freely* to the potential benefit of many millions of people and if a non-profit alternative is created it could then be used in place of scite? Surely, being able to easily see if a scientific report has been contradicted or supported or more generally how something has been cited has more value than seeing who was the lead actor in a recent movie via IMDB, which has been made an exception somehow (their CEO must be better at making his/her case;)). In this scenario, the "worst" outcome is that one private company (scite) benefits from it and that doesn't seem so bad given the upside and the possibility to put some checks in place against potential behavior. I guess the other thing that I think is worthy of mentioning is that wikipedia does link to scientific aritcles that are closed and run by profit publishers, this seems like it would fit under the same umbrella, no?

Thanks again for the discussion and for the help with formatting on these replies. Jdiogenes86 (talk) 22:49, 28 January 2020 (UTC)

Pinging User:JLaTondre, User:Headbomb, and User:OlEnglish, who have worked on Wikipedia:WikiProject Academic Journals/Journals cited by Wikipedia/Questionable1. WhatamIdoing (talk) 21:32, 30 January 2020 (UTC)
Right now, I'm not seeing much use for... whatever this is supposed to be. Taking a random paper like "https://scite.ai/reports/10.1103/PhysRevLett.23.935", we see it's been mentioned 83 times or something. I don't really see what a reader would gain from knowing that in relation to the claim the citation is meant to support in Quark ("Quarks were introduced as parts of an ordering scheme for hadrons, and there was little evidence for their physical existence until deep inelastic scattering experiments at the Stanford Linear Accelerator Center in 1968"). Even if, somehow, the paper had "42 support" in Scite.ai, that still wouldn't mean it supports what we are using it for.
It might be a resource that's useful to editors, so if someone wants to write a WP:User script making use of Scite.ai, sure. But for readers? I don't see it. Headbomb {t · c · p · b} 21:41, 30 January 2020 (UTC)

@Headbomb: Thanks for chiming in. However, I am not sure I follow your argument. It is not useful for readers to see if the reference that underpins a sentence or argument is reliable or not but it is useful for an editor to see it? This might be true if scientific articles did not receive citations over time but they do and these citations can and do change the interpretation/validity of the article itself. This debate can be informative for readers.

Looking at one example in WP:Marriage and health you can see the third sentence says,

"There are gender differences in these effects which may be partially due to men's and women's relative status.[1]"

This reference, mentioned 7 times on that page, however has been contradicted, which can be seen on scite very easily: https://scite.ai/reports/10.1007/s11199-011-9968-6. I think this would be useful information for readers and editors to see. Of course this is just one study on one page. I'm now looking at this more systematically and hope to be able to share a report soon. In brief, I've compiled a list of all scientific articles linked on Wikipedia and am now crossreferencing them against scite. I think such an analysis will be interesting and informative about the scientific foundations of Wikipedia. Jdiogenes86 (talk) 15:10, 2 February 2020 (UTC)

Can I ask..what is the protocol for calling a vote similar to other proposals? Jdiogenes86 (talk)

References

  1. ^ Wanic, Rebekah; Kulik, James (12 May 2011). "Toward an Understanding of Gender Differences in the Impact of Marital Conflict on Health". Sex Roles. 65 (5–6): 297–312. doi:10.1007/s11199-011-9968-6.
A more interesting proposal would be something like having a bot report on talk pages, where a bot compiles a list of possibly contradicted/outdated citations. Headbomb {t · c · p · b} 19:23, 2 February 2020 (UTC)
Here's what I see as the best chance for you to get something like this implemented on Wikipedia.
  • Form a non-profit associated with your company, with an agreement that it can use your technology for specific non-profit purposes only, e.g. doing a project on Wikipedia for open access journals only
  • Do this demonstration project and openly license the results and interface used on Wikipedia. In detail, non-profit doing the computation, output only for open access journals, interface (or link) to the non-profits site is freely licensed.
  • Best if the non-profit has some continued funding. We wouldn't want to do this for just 2 years and then have to remove all the links!
  • The non-profit could have an editor (maybe even a Wikipedian in Residence) inform other editors on article talk pages that the links are ready and where to find them, but unaffiliated editors make the actual decision to insert them.
  • You get your proof-of-concept at large scale, all the technology developed along the way, except for the part owned by the non-profit.
I think that would have a 50/50 chance of flying after the details are worked out.
But take away any part of it, I don't think it would fly. Smallbones(smalltalk) 02:04, 4 February 2020 (UTC)
If this is somehow used on Wikipedia, limiting this only to open access journals is silly. Debunked/unsupported claims in closed access journals are just as important to flag as those from open access journals. Headbomb {t · c · p · b} 21:44, 5 February 2020 (UTC)

@Jdiogenes86: The idea is certainly interesting, although with some issues others have pointed out. Looking at the link you posted, I have a few questions:

  • You mention that the citation is contradicted twice. This really makes it sound like it is contradicted in two different papers, but really it is two instances in the same paper. Can a paper simply reference another several times to influence how it is portrayed on your software? Have you looked into whether this (citing something multiple times) could happen more frequently in supporting or contradicting papers?
  • Does scite take into account if a paper contradicting another paper is itself heavily contradicted?
  • Looking further into the article you linked, six of the results are from one paper: "Marital Quality and Health: A Meta-Analytic Review". I would say that none of those contradict it. Here are the two marked as contradicting it:
    • "While our failure to detect overall gender differences in the relationship between marital quality and health endpoints may appear counter to previous narrative reviews (Kiecolt-Glaser & Newton, 2001; Wanic & Kulik, 2011 b), those prior reviews made suggestive, but not strong claims about the empirical status of gender differences, marital quality, and health outcomes. Moreover, both the interpersonal-orientation and subordinate-reactivity hypothesis focus on "the pathway from negative marital conflict behaviors to physiological functioning""
    • "We found no significant gender differences in the relationship between marital quality and cardiovascular reactivity or cortisol responses, counter to prior reviews (Kiecolt-Glaser & Newton, 2001; Wanic & Kulik, 2011b). Methodological differences between our meta-analysis and prior narrative reviews account for much of the difference."


I'm working on a report now that analyzes all scientific articles on Wikipedia, which is nearly done. Once it is, I will share it here and the data will be made open under a CC BY NC license. I think it will greatly inform this discussion about possible next steps if any. Thanks to everyone for the feedback and questions. Jdiogenes86 (talk)

Bot request for User signature changes

Please see relevant new discussion at Wikipedia:Bot_requests#Bot_for_lint_errors, essentially I want to get someone to write a bot, then run a bot through some ancient (at first) signatures reformatted by user on varios talk pages (errors on all page spaces), this will fix one main "important" category of errors and some fixes will flow into others. This will allow identifying current users with errors in thier bespoke signatures and advise them to correct span or font issues in the same, reduce overheads going forwards etc.121.99.108.78 (talk) 10:01, 28 January 2020 (UTC)

When I said that this should go to VPR (Village Pump/Proposals), I meant that there should be an actual proposal made at VPR, with a clear explanation of what exactly is proposed and what problems this would address (with an estimated number of affected pages for each 'error'), with a full RFC on the matter. Having more people at WP:BOTREQ won't establish consensus that the proposed task request is a good idea or not. Headbomb {t · c · p · b} 15:55, 28 January 2020 (UTC)
Headbomb, please review the proposal below and comment, adjust or give guidance as required.

Amend signatures that cause lint error

My proposal is to seek approval by consensus to allow adjustments and reformatting of editor signatures which have either formatting errors or depreciated parameters that cause various Lint errors. These errors appear on various talk pages across all page spaces and cause errors mainly in the Tidy bug affecting font tags wrapping links Cat. (currently showing 5,220,072 errors). These errors date from 2006 onwards, fixing these errors would also, in some cases flow through to fix other errors not in the Tidy Cat., help identify current signatures that continue to cause these errors, reduce the overhead in running and maintaining affected pages while making it easier to navigate through the error reports.121.99.108.78 (talk) 07:34, 29 January 2020 (UTC)

  1. I want to emphasize that you appear to be talking about a number in excess of FIVE MILLION TWO HUNDRED TWENTY TWO THOUSAND AND SEVENTY TWO PAGES, apparently including an unknown and conceivably larger number of additional unidentified pages.
  2. This is not required, but I suggest/request you log in. It's awkward dealing with IPs, and particularly unhelpful when you're making such a massive bot request.
  3. Headbomb said above you should include "a clear explanation of what exactly is proposed". I don't feel your proposal is very clear about what changes you want to make, and I find it entirely opaque regarding the unknown number of unidentified "other" groups of changes you want to make.
  4. Headbomb said above you should identify "what problems this would address". You have given no indication whatsoever how or why these changes would be beneficial to us. I do not consider lint-numbers inherently significant.
  5. Given the above I can't really say anything about your proposal with certainty, other than it's big and unclear. However want to note that moments ago I opened a proposal for a new Village Pump page. There are a number of big issues I hope to raise there, and I believe it is possible that one of those issues might directly exterminate any rationale or desire for your bot run. So unless there's urgent need and immediate benefit, I'm in no rush for such a massive bot at this time.
    Oppose, at least until a more clear explanation and immediate benefit is provided. Alsee (talk) 12:48, 29 January 2020 (UTC)
As someone who has spent a considerable amount manually fixing linter errors myself, I must concur with every point that Alsee raised. Although we're already beginning to see readability issues in talk page archives from deprecated HTML, it's not a serious enough issue to warrant the resources necessary for changing countless signatures, and even if it was, a bot is hardly the way to do it, given that no two lint issues are alike, and require different fixes depending on the lint issue. OhKayeSierra (talk) 15:51, 29 January 2020 (UTC)
  • As someone that's written a bot for this purpose, I wanted to chime in here. There are really three separate issues here:
  1. Signatures with issues caused by the switch from Tidy to RemexHTML that cause formatting to bleed onto other parts of the page
  2. Signatures with issues that cause them to display differently under RemexHTML than they did under Tidy (usually fonts and colors not being applied to text) but that don't affect other parts of the page
  3. Signatures that generate Linter errors but appear identical under Tidy and RemexHTML
In the first case, fixing the signatures is important, and has an immediate benefit. However, identifying the error and fixing it in a manner that is consistent with the editor's intent cannot be done automatically. User:Ahechtbot was programmed to run against a manually-created listed of problematic signatures that appeared on hundreds or thousands of pages, but generating and testing these lists is too time consuming for signatures that only affects tens of pages, so there is a long tail problem. The only way to automate it would be to replace the signature with a default unformatted signature, but even that isn't straightforward (just look at the trouble that archiving bots have with certain sigs).
In the second two cases, I don't see any urgency to fix the pages that justifies making edits to literally millions of pages. Linter errors are just that -- errors that show up in a list on an obscure page somewhere but don't do any harm. If you're worried about polluting categories, there's a drop-down that allows you to filter out talk pages. In the long term, a better solution would be to modify the parser so that it goes back to interpreting <font>[[Foo]]</font> as [[Foo|<font>Foo</font>]], which would take care of a majority of the errors. There are other cases, such as <font>[[Foo|Foo</font>]] which more likely to be problematic and are less straightforward, but could also be corrected by the parser if there is a desire to do so. --Ahecht (TALK
PAGE) 16:48, 29 January 2020 (UTC)
Thanks for the expert info Ahecht. That's pretty much what I was thinking. I believe the real problem here may be well-intentioned-harm that the Foundation has done to Wikitext. The Foundation is working to redefine Wikitext, some individual changes may have been fine, but some are bad. I plan to show that harm on the new Pump page, and explain the long term Foundation strategy behind those changes. (Spoiler alert: Making Wikitext user-hostile is ok because everyone should be using VE instead.) Alsee (talk) 19:34, 29 January 2020 (UTC)
Thanks all, I am going to try to run some numbers in the background, but to clarify it is ~5mil or so errors, not pages, often one talk page will contain multiple versions of the same signature and error.121.99.108.78 (talk) 06:57, 30 January 2020 (UTC)
It's easy enough to get the numbers from the Toolforge DB replicas, although I don't see how User:Alsee121.99.108.78 got 5,222,072 unless someone has somehow fixed half of them in the past 5 days. I count 2,034,469 instances across 712,180 pages. That would still be a lot of bot edits, just to change the colors of some links in user signatures. If we're reasonably confident that user signatures are the only instances remaining, it might make more sense to just ask that Linter no longer report this "error". Anomie⚔ 13:23, 3 February 2020 (UTC)
Ah, probably the count came from Special:LintErrors rather than the linked Special:LintErrors/tidy-font-bug. If that's using the method of estimation I guess it probably is, then "Note: The counts for categories are not exact, but are based on estimates" is what happened there. Yes, those estimates can easily be off by that much or more. Anomie⚔ 13:30, 3 February 2020 (UTC)
OhKayeSierra and User:Ahecht, I wonder whether it'd be possible to make a list of high-traffic talk pages with lint errors, and set about fixing just those. Ancient talk page archives don't feel like a high-priority task, but https://wiki.riteme.site/w/index.php?title=Wikipedia:Village_pump_(technical)&action=info says there are four lint errors on that page today, and those might be worth cleaning up. Whatamidoing (WMF) (talk) 00:03, 31 January 2020 (UTC)
I'm not sure I see a reason to fix pages like that. It would just add needless work, correcting invisible errors as they are introduced. On the page you linked to, none are actually bad signatures with the "Tidy bug affecting font tags wrapping links" linter error. One is a typo leaving out an apostrophe when bolding something, one is someone removing text from a substed template and accidentally removing a closing <span> tag, one is someone using <font> tags (which are deprecated, but still supported) in their signature, and one is someone deliberately giving an example of text formatting that doesn't work. A better solution to reducing errors on high-traffic pages would be to (a) scour the prefs database for editors with signatures that generate linter errors and notify them somehow and (b) have something like an editfilter warning to warn editors that their edits are introducing markup errors. --Ahecht (TALK
PAGE) 01:20, 31 January 2020 (UTC)

:Oppose until I can take an IP seriously. >>BEANS X2t 13:34, 3 February 2020 (UTC)

Sorry, wasn't having a great day. >>BEANS X2t 13:38, 6 February 2020 (UTC)
  • Oppose - I'd imagine there's a whole ton of problems when it comes to Lint and sigs ..... For instance my 2013 sig heavily used </font>.... I don't see how fixing these can really be achievable and if they could then there wouldn't really be any benefits to such a huge move, Sure for instance font is deprecated but it still shows and I assume it will continue to carry on showing .... –Davey2010Talk 20:27, 5 February 2020 (UTC)

Editors profile on Wikipedia

I want to submit the following proposal. Why not make the profiles of the editors look a little more professional by making available (optional) details about yourself like a photo, educational background, the city and country and so on. That will look more professional and of course, the information that you additionally put, will be optional. I think that will improve Wikipedia even more.— Preceding unsigned comment added by Albi Ndoni (talk • contribs) 16:01, 4 February 2020 (UTC)

Albi Ndoni You can already put most of the information you describe on your user page if you wish. Your user page is for introducing yourself to the Wikipedia community in the context of your Wikipedia editing or use. It isn't a place to tell anything and everything about yourself, though; please see WP:USERPAGE for what is considered to be acceptable user page content. 331dot (talk) 16:12, 4 February 2020 (UTC)

I assume you're talking about editors' user pages? Some people do exactly that. Some people don't bother. Some people intentionally don't do it so as to preserve their anonymity. In general, we leave decisions about how editors manage their own user pages pretty much up to them. Personally, I think the emphasis should be on the quality of the content that's being produced, not who's producing it. -- RoySmith (talk) 16:16, 4 February 2020 (UTC)

I agree with the last point. I don't keep a user page myself, and only reveal personal details (apart from my name) when it is relevant to the context, for example it may be important in a discussion for people to know what my reading level of a particular language is. If you want to know more about me then I'm sure you could find enough in my editing history to distinguish me from the handful of other people who share my name, but I prefer not to make it too easy to do so. If you want to make it easier for editors who wish to do so to supply details then there are almost certainly templates that format things professionally, or you could write one yourself, but this is not part of Wikipedia's core mission. Phil Bridger (talk) 19:26, 4 February 2020 (UTC)

Correct me if I'm wrong, but don't we generally discourage the use of PII where unnecessary? A userpage (not a "profile") is generally for sharing information relevant to editing Wikipedia, primarily interests and language proficiency. Anything more in depth is discouraged, with common sense dictating that you wouldn't want to give trolls more ammunition against you than they already have - especially if you're an admin or work in an area that's filled with partisans. —A little blue Bori v^_^v Onward to 2020 20:25, 4 February 2020 (UTC)

@Albi Ndoni: I suspect what you’re looking for is the template {{Infobox Wikipedia user}}, which allows you to display that information in a format similar to the Infoboxes found in many articles. Of course, you don’t need to fill out every field. You can find examples of how to use the template here. —pythoncoder (talk | contribs) 21:32, 4 February 2020 (UTC)

Because of Identity theft, a degree of caution is needed.--Dthomsen8 (talk) 02:33, 8 February 2020 (UTC)

Non-native English Formatting: No Indentions on Paragraphs

World Book Encylopedia Encyclopaedia Britannica

(indentation)As we can all see in the above examples, there are no indentations at the beginning of paragraphs on English Wikipedia, but there are in World Book and EB. American and British English are both important parts of English, and after reading some books from those regions and getting an education in the USA, I've become convinced that indentations at the beginning of paragraphs are definitely a part of the English language on some level, even if they can be shown not to be used in some circumstances or to be looked down upon in some manuals. I suspect this issue has come up before many times, but I would like to bring it up again if only so that you all can know that there are and will always editors dissatisfied with the current state of affairs regarding paragraph indentation. I urge the community to respect the culturally distinct formatting used by the English language speakers (especially American English, etc) and not force us to use what I would see as an alien or continental non-indented paragraph convention. It would be a sign of respect for the history of the English language pre-Wikipedia to just go ahead and use the conventions of the English language as they truly are and not as we might wish them to be or plan them to be. At bare minimum, we ought to be allowed in some circumstances and on some pages to write in our native language unimpeded, especially pages marked for American English. Thank you for your time and consideration. NOTE: Because I personally feel this topic is likely to impugn the authority of the powers that be on this website on some level, I do not plan to follow up to any responses here because I am in dread fear that I may be blocked if I use the wrong wording here. Even to bring up this topic may accidentally cause myself to get a ban. But I feel quite passionate about this, and I think that as an editor of several years and many edits, my continued silence would make me complicit in what I would see as a mistake. I make the post in a spirit of friendliness with a hope to improve the encyclopedia by returning to what I see as bona fide English instead of "hip & cool" no idents on paragraphs. Because of the likely/possible controversy of my proposal, I reiterate that will not respond to pings on the issue. Thanks again. Geographyinitiative (talk) 04:33, 14 January 2020 (UTC)

You seem to think we will ruthlessly crush a dissent as powerful as reads up... asking ... for indents... Friend, I don't think you have anything to worry about. Then again, since you don't care about the reaction, I guess this is just a fun time dance party now? (Also, you may notice that while print works that you linked are indented, internet pages are routinely not. It's because writing for print and for the screen are Different Activities, with Different Rules. --Golbez (talk) 04:39, 14 January 2020 (UTC)
I wonder if paragraph indents are something users can create with their .css or .js settings? --jpgordon𝄢𝄆 𝄐𝄇 04:42, 14 January 2020 (UTC)
Ayup. Something along the lines of div#mw-content-text p { text-indent: 2em; } in your CSS will do it. —Cryptic 04:45, 14 January 2020 (UTC)
  • I know the MOS-ites are a powerful crew not to be crossed, but I don't think they've escalated to acquiring community bans for raising the topic of paragraph indenting, please feel free to engage the conversation, it makes it much easier to discuss it. Jpgordon raises a good point that what you really need to show is a significant group of English writers who indent online paragraphs. I've not spotted that but for all I know I just don't note it. Nosebagbear (talk) 12:22, 14 January 2020 (UTC)
    • We don't even need to show that other websites do it. We just need to show that editors want it. User:Geographyinitiative, the code that User:Cryptic posted should let you have indented paragraphs. It might be good to try it out, and see how well it does (or doesn't) work for you. Just put it in Special:MyPage/common.css (and don't worry about the warnings – malicious code could screw things up, but this isn't malicious, and if it doesn't do what you want, then you just go back to the same page and edit it to remove that code). WhatamIdoing (talk) 18:53, 21 January 2020 (UTC)
  • I just pray that nobody blocks or bans the user for using that CSS code. – Levivich 01:05, 4 February 2020 (UTC)
I have spent my while life indenting paragraphs. The issue here is that we don't do it just because everyone else does. I am suppose I would be open to "discussing" a change but will not likely change the css code to accommodate this. I don't think I would "correct" such an article (haven't previously thought about it) with consistent indented paragraphs should should I run into it. Without clear guidance or a mandate (consensus) I would certainly object to editorial sanctions if someone did use indention's (a code allowing it), unless maybe there were issues like: It was objected to (changed or reverted) because of our current practices and it was reverted without discussion.
Also, I would be more responsive to a discussion where I don't see "I reiterate that will not respond to pings on the issue". Change may be a good thing but someone "might" have had reasoning to want to present questions to the initiator. I am not a fan of "discuss it here but leave me out of it" that seems to be presented. Otr500 (talk) 13:13, 8 February 2020 (UTC)

Proposal: Community-based process for granting the CheckUser and Oversight permissions (similar to an RfA)

I don't think it is fair that the community has no say who gets to be a CheckUser and who gets to be an oversighter. I propose that the requirements be similar to an RFA (having an account and being extended confirmed), however, an additional requirement would be that the candidate must have signed the access to nonpublic information. If a candidate is nominated and has not signed it, the candidate would be asked to sign it or if they choose not to sign it, they cannot be nominated. Interstellarity (talk) 23:55, 8 February 2020 (UTC)

Community comments were invited for the last round of appointees, at least: Wikipedia:Arbitration Committee/CheckUser and Oversight/2019 CUOS appointments –xenotalk 00:41, 9 February 2020 (UTC)
(edit conflict)As an opening thought, while an ARBCOM member's usage of OS/CU (which is mainly informative) could operate without an admin's toolkit, many of the tasks that a CU/OS role is meant to fulfill would require an admin rights - CU rights in particular are normally used when considering socking issues, which is inherently tied up with blocking. If that then required a separate person to action you'd be duplicating effort. Beyond that, Wikimedia Legal have said that access to even general deleted content requires a full RfA, I suspect a more general community discussion wouldn't be enough to tick that box. Nosebagbear (talk)
Still, that's all about the candidate pool, certainly the community could do the consideration of CU/oS rights, however, I'm not sure how much help it would serve. The community gets encouraged to provide feedback on CUOS candidates when ARBCOM considers them (at least in my time), and I've not seen individuals accepted who've had significant community resistance. Nosebagbear (talk) 00:47, 9 February 2020 (UTC)
Suggest reading though this somewhat recent discussion before deciding if you want to have a new one Interstellarity. (Wikipedia:Village_pump_(idea_lab)/Archive_29#Idea_Poll_-_independent_CUOS_Elections). — xaosflux Talk 00:55, 9 February 2020 (UTC)
@Xaosflux: I didn't know this has been discussed before. I read through the discussion. Not sure what to do from here. Should we continue with the discussion or should I delete this post? Interstellarity (talk) 01:04, 9 February 2020 (UTC)
@Interstellarity: up to you, if you want to continue by all means continue; if you want to withdraw your proposal for now just leave a note below and it will eventually be archived. Best regards, — xaosflux Talk 01:07, 9 February 2020 (UTC)
@Xaosflux: I will let the proposal run and see where the consensus goes from here. Interstellarity (talk) 01:08, 9 February 2020 (UTC)

Notice of re-proposal to merge all volumes of The Lord of the Rings to its main article

FYI
 – Pointer to relevant discussion elsewhere.

The AfD suggesting merge/delete and redirect has closed, and another discussion about merging all three LotR volumes' articles into The Lord of the Rings has now opened at Talk:The Lord of the Rings#Proposed merge of The Fellowship of the Ring etc into The Lord of the Rings, as of February 4.

Listing this here because I think this renewed proposal has implications (one way or the other) for our treatment of other multi-part works, including non-fiction ones (cf. Das Kapital, and Das Kapital, Volume I through Das Kapital, Volume III), and non-book ones (e.g. separate TV episode articles, and many other such things). This is a bit of a meta-discussion, on what concerns/plans/wishes/complaints can be considered to simply override WP:GNG for alleged broader WP:ENC rationales.

Also, I find this procedurally a bit dubious. The AfD closed with a consensus against deletion (in a proposal to merge and delete then redirect), albeit not an overwhelmingly strong one. A back-to-back proposal to merge and delete then redirect via off-AfD talk page discussion seems a bit out-of-process, even if the AfD closer expressed some uncertainty on the matter (and that last bit means the proponent is surely acting in good faith to clarify/resolve, not trying to forum-shop). I think this verges on WP:CENT-worthy, however, because zero relevant talk pages were notified, even of the affected articles and of WikiProject Middle-earth (though all four articles received a merge tag; some process was followed). I have rectified the missing notifications (also to WikiProjects Fiction, Fantasy, Novels, and Literature, and WP:PM). Nevertheless, the discussion has been going on since Feb. 4 without many people knowing about it other than a few who followed it directly there from AfD. Perhaps the notices today are sufficient to draw in a lot more eyes and brains to consider the matter. I'm not listing it at CENT yet, but would not object if someone else wanted to. I think the horse is too far out of the barn to close it as out-of-process, so it just needs to run with sufficient input for a proper consensus.  — SMcCandlish ☏ ¢ 😼  10:24, 9 February 2020 (UTC)

I agree, for what it's worth. I only saw the discussion because you posted it here. The Drover's Wife (talk) 10:32, 9 February 2020 (UTC)

100K Edit Star

We have the 100K Edit Star, shown here. Should we award a 200K Edit Star, perhaps 300K, etc.?--Dthomsen8 (talk) 02:25, 8 February 2020 (UTC)

Although edit counts go into the millions, stopping at 400K or 500K would include most of the editors over 100k. See Wikipedia:List of Wikipedians by number of edits for details.--Dthomsen8 (talk) 03:25, 8 February 2020 (UTC)
This would appear to be a singular waste of time. Anyone who's been around for that length of time (there are only 174 of them, many of whom haven't edited for years and quite a few of whom were actually unauthorized bots) is pretty much by definition going to have enough experience on Wikipedia to know that once you get past around the cutoff of around 1000 edits that separates "inexperienced" from "experienced", edit count is one of the most meaningless metrics on Wikipedia. (I could have racked up 10,000 search-and-replace typo fixes with a script in the month or so it took to make this single edit; it doesn't mean it has 1⁄10000 of the value of fixing an instance of "doe snot".) If anyone really feels the urge to pretend a high edit count somehow makes them important, they're already perfectly capable of putting "I have 200,000 edits!!!!" in 50-point dayglo type on their userpage. ‑ Iridescent (303,408 edits at the time of writing and not pretending that makes me some kind of super-user) 09:15, 8 February 2020 (UTC)
So true. · · · Peter Southwood (talk): 16:52, 8 February 2020 (UTC)
Hmph. BD2412 T 22:38, 8 February 2020 (UTC)
I oppose anything, such as this proposal, that values quantity over quality of edits. Phil Bridger (talk) 21:47, 8 February 2020 (UTC)
Sheesh this award is just for fun. It should be noted that bots were removed from the list many years ago. Also, most of the names on that list are still editing. I know because they are hard to catch up with. MarnetteD|Talk 23:21, 8 February 2020 (UTC)
Additionally this award simply acknowledges quantity - it in no way shape or form "values" that number over quality. BTW there are numerous Wikipedia:Barnstars to be awarded for quality editing. MarnetteD|Talk 23:29, 8 February 2020 (UTC)
Perhaps I expected too much form my proposal. An easier approach than to "award" the stars with a bot would be to create the stars, and let the users award them to themselves or to friends who qualify.--Dthomsen8 (talk) 23:38, 8 February 2020 (UTC)
Oppose per Iridescent and Bridger. It may be just for fun, but it remains that a vast number of editors don't and wouldn't see it that way. I long ago stopped displaying the Wikipedia:Service awards because they were becoming increasingly misleading. To proclaim that I am now a Master Editor (or Illustrious Looshpah) (soon to be promoted to Auspicious Looshpah) would be a gross and embarrassing overstatement of my contribution to this project. Those awards are likely here to stay as a result of inertia, but we don't need to be doing things to increase the magnitude of the problem. Edit count means less than nothing. ―Mandruss ☎ 23:59, 8 February 2020 (UTC)
I tend to agree with the critics above. Cute badges like this are primarily for noobs and semi-noobs. There's a certain subset of incoming people (especially video game players) for whom "badges" or "achievements" are personally meaningful, and there's even a small subset of people for whom this sort of thing is appealing always and forever, but its a pretty small slice of the editorial pool. And some of us who don't psychologically need these things will display them anyway, as noob encouragement. But anyone who's hit the 100K edits mark (by whatever means) is probably already over it; they don't need new badges for 200K and 500K to encourage them to keep participating and feeling good about it. They're already here for the long haul, and [we sure hope!] for WP:HERE / WP:ENC reasons. And noobs are not going to be encouraged any further by 200K awards than by 100K awards, which already seem like they're almost impossible to achieve when you're that green.  — SMcCandlish ☏ ¢ 😼  01:00, 9 February 2020 (UTC)
Heh. An edit count of 100,000 still seems almost impossible to achieve and I've been here for thirteen years. Give me ten more and I might make it. Useight (talk) 15:55, 10 February 2020 (UTC)
That comment prompted me to have a look when I got to 100,000 edits, and I was disappointed to find that I'm not even half way there despite my similar length of tenure. I think I need to pull my socks up by doing in ten edits what I currently do in one. Phil Bridger (talk) 17:59, 10 February 2020 (UTC)
Try getting into the counter-vandalism game, it's great for inflating your edit count! Automatic tools, just click one button to revert an edit, and every rollback you do counts double since you then post on the user's talk page! You'll get to 100k in no time at all. creffpublic a creffett franchise (talk to the boss) 18:04, 10 February 2020 (UTC)
@Dthomsen8: We already have Barnstars and Wikipedia:Service_awards. If you want to create a new award, I suggest you create a new Barnstar that can be awarded like any other. RudolfRed (talk) 01:59, 9 February 2020 (UTC)

More money on referencing

Apologies if this is not the right forum for my question/proposal. I frequently notice how clunky and difficult it is to generate proper references on Wikipedia. I am at a loss to understand how a tool that works quickly and properly to expand references is not part of the standard interface. Yes, there is the citations gadget, but it does not work half the time and takes forever the other half of the time. And there is WP:Refill. And there is the manual cite web/book/journal tool under cite on the main toolbar. But none of these are fast and reliable built-in solutions. I don't understand why things are so clunky on a site where one of the most important aspects of what we do is providing proper referencing. So if there is proposal to be made here, it is perhaps that Wikimedia, or whoever has the money to hire a team, should get on this?ThatMontrealIP (talk) 20:12, 8 February 2020 (UTC)

The ultimate problem is that there is no reliable method to gather the citation information from any arbitrary web site, as the information is not presented uniformly. For better or worse, the more seamless a tool is, the more people will assume it is reliable. Reusing citation data is perhaps a more achievable goal, using Wikidata as a central repository. Unfortunately that won't help editors add new citations. It's been a while, but last time I added some assertions to Wikidata and then added citations for them, I went down a rabbit hole of creating items for every part of the citation. Unless that has gotten easier, it's pretty cumbersome. isaacl (talk) 21:18, 8 February 2020 (UTC)
Yes, it is no doubt tedious. But if it is doable by a human in a couple of minutes, it is certainly doable by software (perhaps with a dash of AI) much more quickly. I don't see why significant funds have been not expended on this. It is just a matter of looking up the URL, intelligently parsing the site, and formatting that as a reference. At minimum most cites will include the html title tag, which fills in the title part. it is not a trivial software job, and not an impossible one either. But it is certainly doable and I do not understand why it is not a priority to make it part of the principal interface. Or maybe they are already working on it?ThatMontrealIP (talk) 21:30, 8 February 2020 (UTC)
I'm not sure if this is exactly the same issue, but it has long been a bugbear of mine that it is far easier, with the automatic tools available, for editors to nominate an article for deletion than it is to add references from sources such as books and academic articles indexed by Google Books and Google Scholar. Anything that encourages editors to actually look for sources has my support. Phil Bridger (talk) 21:46, 8 February 2020 (UTC)
There is a tool that automatically generates citation data from a website, it's called Zotero. It's a little cumbersome to set up: you have to install an application on your computer and a browser extension. It also doesn't work for every website, but the times that it does work, it can save quite a bit of time. More info can be found at Wikipedia:Citing sources with Zotero, and feel free to ask me any questions you might have because I think that page is a little outdated now. --Secundus Zephyrus (talk) 21:49, 8 February 2020 (UTC)
Secundus Zephyrus, thanks for that. Integrating something like Zotero into the interface is exactly what i am talking about. Zotero is open source. At the moment we are relying on user-generated tools like ReFill to fill refs. Why isn't the WMF working on this? Zotere is Open source so it is an example of something that could be forked to work. There should be a bulletproof way to add refs reliably, and lots of money should be thrown at it until there is. At the moment we just have hacks, workarounds and optional gadgets, many of which were written by external parties. Phil Bridger's point that it is easier to AFD an article than it is to add references is a point well taken.ThatMontrealIP (talk) 22:17, 8 February 2020 (UTC)
Here is what the WMF research section says they are working on, sources-wise.ThatMontrealIP (talk) 22:21, 8 February 2020 (UTC)
This isn't the place for it, but I do somewhat wonder whether this is the type of thing that leaning on some of our partners, ranging from Google to the Open Software Foundation and trying to nudge towards some vaguely more co-ordinated form of presenting the key info would be worthwhile. I'd have absolutely no complaints about the WMF working towards a zotero-esk approach, but I'm well aware of how tough it could be to do. Sometimes I find a ref and extracting the information manually can be tough enough - AI is not automatically better at recognition tasks. Nosebagbear (talk) 00:37, 9 February 2020 (UTC)
@ThatMontrealIP: Zotero is already integrated into the interface: the VisualEditor and 2017 wikitext editor have a truly built-in tool for adding (and expanding) citations, powered by Citoid, which in turn uses Zotero. SD0001 (talk) 12:34, 10 February 2020 (UTC)
Handling PDF's from a URL could certainly be improved. When I look at PDFs' properties there is usually a date given. The author though in there is pretty useless. In the visual editor I would like to see it handle patents and theses. Does it handle news paper sites to generate a cite news? Graeme Bartlett (talk) 22:11, 10 February 2020 (UTC)

Proposal: Procedural removal of admin rights who have not used the admin tools for a significant period of time (maybe 5 years)

There is no consensus on the question as to if there should be a minimum requirement for logged activity requirements to retain the administrator toolset. As such there will be no change to the WP:ADMIN policy.

Longer version: this RfC was essentially two groups of people with diametrically opposed views of the proposal saying opposite things and talking past one another. While some proponents on both sides gave more in-depth reasoning the core arguments were "They have no need for the tools, and there's no proof admins who only make unlogged actions exist" and "No problem has been demonstrated and unlogged actions should count." In my view, both of these lines of reasoning are valid in a policy RfC. While the "no problem shown" objection can be overcome by a sufficient bulk of the community disagreeing with it and thinking that there is a problem, that bulk wasn't reached here.

At the same time, there was a slight majority of the community in favour of having an updated activity requirement and their reasons for wanting it were equally valid. In situations like this, the correct closure of the RfC is no consensus, and since our system requires consensus to change policy, no changes will be made at this time. TonyBallioni (talk) 01:24, 11 February 2020 (UTC)

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

This reduces the number of administrators that probably have no use for the tools. Interstellarity (talk) 00:48, 18 December 2019 (UTC)

@Interstellarity: just for reference, the following 62 admins have not made a "log entry" in over 5 years:
Could we also get the total number of admins (and/or "active admins"), against which we can callibrate the figure of 62 below? Britishfinance (talk) 21:21, 10 January 2020 (UTC)
{{NUMBEROFADMINS}} → 852; WP:List of administrators says 501 active, 423 semi-active, 215 inactive. —Cryptic 05:35, 11 January 2020 (UTC)
List of admins without recent logs
user_name user_editcount user_registration Last edit Last log user_group
Cecropia 12514 20031226204625 20191022150441 20080116071815 sysop
Wrp103 7568 20040707133428 20191112160840 20080725032125 sysop
SpuriousQ 17821 20050605102221 20191207061429 20090109162447 sysop
Morven 18628 20030217073253 20190826065552 20090310163226 sysop
Wassupwestcoast 12006 20060906233639 20190228005532 20090906232236 sysop
XDanielx 4227 20070714072421 20190325204656 20091107065713 sysop
Ramitmahajan 10153 20060413080259 20191020121100 20100106163958 sysop
Camembert 18980 20020225154311 20191123190341 20100107024947 sysop
Nixdorf 7257 20021125001815 20191030081008 20100213130534 sysop
MrDarcy 7619 20050118204417 20190528232918 20100316023857 sysop
Frazzydee 8083 20031108025139 20190218235834 20100419025606 sysop
Chairboy 8128 20040816075811 20190407231616 20100620140434 sysop
K1Bond007 25919 20030805032410 20181216220208 20100819063220 sysop
Cyrius 19544 20031224195156 20191116053720 20100915033929 sysop
Deiz 16055 20051227160345 20190803124709 20101108100031 sysop
Sn0wflake 7221 20040716065200 20190831191726 20101226235035 sysop
Eliz81 15671 20061011183314 20191013012235 20101227032204 sysop
Zoicon5 24862 20030716184616 20191024020920 20110307203217 sysop
Grue 6498 20040828134246 20191008070242 20110325203151 sysop
Where 7158 20051225023642 20190601001131 20110810012028 sysop
Butseriouslyfolks 16742 20070104201720 20190921211035 20111011054725 sysop
Wickethewok 16435 20060119092227 20191213044304 20111013041227 sysop
XJaM 11297 20020225170337 20190825020524 20111110175229 sysop
Ilyanep 6912 20030507214927 20191002160608 20111111212023 sysop
RG2 13297 20050828070336 20190829133416 20111130043959 sysop
David.Monniaux 17008 20030913115900 20191129114207 20111203144756 sysop
TheoClarke 7495 20050115211715 20191015124008 20120205000347 sysop
Thatcher 28285 20060208173441 20191107202508 20120208195226 sysop
Saravask 21952 20050924041106 20191020094040 20120303213457 sysop
Oliver Pereira 5880 20020225155115 20190804195141 20120424152352 sysop
Dbenbenn 19217 20040113200123 20190811084109 20120430033021 sysop
Hawstom 4771 20030903223732 20191117225231 20120507020802 sysop
MarkGallagher 9530 20041104161518 20190206004550 20120808080955 sysop
Kotra 8949 20051122065114 20190903033759 20120821001625 sysop
Stevenj 14746 20030201213757 20191212180342 20120908204551 sysop
GeeJo 25989 20050614000131 20190929175402 20121213005056 sysop
Berig 20774 20060818154821 20191025140412 20130225124844 sysop
Kaisershatner 17296 20040727151618 20190307214736 20130319161302 sysop
Marianocecowski 19921 20041116131605 20191206094100 20130417122210 sysop
Ryan Norton 12338 20050301062750 20190717062946 20130424031459 sysop
InShaneee 15944 20041110060942 20191204082928 20130513102952 sysop
Ortolan88 10334 20011116235623 20191203032312 20130630192102 sysop
Chris G 20244 20060827072922 20190518074733 20130801113933 sysop
MattWade 23192 None 20190508203016 20130816163708 sysop
Evercat 16369 20030416021703 20190809175834 20130829000244 sysop
Caltrop 3569 20020605160936 20190930014319 20130830211814 sysop
Sethant 4501 20061218000947 20191115235547 20130916030709 sysop
WAvegetarian 7422 20050531090821 20191001063657 20131212024446 sysop
Drilnoth 51237 20081025231019 20190806041058 20140303022300 sysop
DanielCD 31536 20040620130607 20191211134320 20140303144106 sysop
Ev 12895 20050329053116 20190924015323 20140311154438 sysop
BozMo 14039 20040405151455 20190809144049 20140630075330 sysop
Faithlessthewonderboy 31588 20070717014639 20190718172849 20140703144520 sysop
Atama 17307 20061122234324 20190910124251 20140710234952 sysop
Aqwis 5680 20061021144019 20190902140353 20140731212735 sysop
Jeepday 27568 20061029134933 20191202222909 20140806091020 sysop
Oren0 7324 20060906205054 20190721063208 20140809195528 sysop
Refdoc 3141 20030104001937 20181216200355 20140810175513 sysop
Gwalla 8644 20040114014814 20190929233348 20141001204457 sysop
Mindspillage 10665 20040622061129 20181208052138 20141009171655 sysop
Gimmetrow 45176 20060503140850 20190705233811 20141016184922 sysop
JohnOwens 8117 20021009035258 20191113154346 20141124000904 sysop
Resolved sidebar about bureaucrat activity
— xaosflux Talk 01:16, 18 December 2019 (UTC)
Regarding 'crats, we do proactively track these (as unlike admins 'crats have a "use it or loose it" rule) - see Wikipedia:Bureaucrat activity (there are no current issues). — xaosflux Talk 01:18, 18 December 2019 (UTC)
@Xaosflux: I also found one bureaucrat, Cecropia, has not used their bureaucrat permissions for a while. Interstellarity (talk) 01:24, 18 December 2019 (UTC)
@Interstellarity: yes the 'crat activity policy calls for crat activity (not necessarily a logged action) at least once every 3 years (it is trivial to meet if you are participating in that facet) - we have 2 'crats potentially up for removal next april unless they re-engage. — xaosflux Talk 01:27, 18 December 2019 (UTC)
@Xaosflux: OK, that's clear. I have changed my proposal so it affects only admins, not bureaucrats. Interstellarity (talk) 01:31, 18 December 2019 (UTC)
  • Support, and it's about time we implemented such a rule. BD2412 T 01:47, 18 December 2019 (UTC)
  • Support, five years is reasonable. Randy Kryn (talk) 02:02, 18 December 2019 (UTC)
  • Comparing this to WP:INACTIVITY, is this also temporary thing, to be reversed upon request? Or, "You need to run the WP:RFA gauntlet again"? I assume we'd want the same one-month/several-days alerting. And, if we do this, I'd certainly update WP:INACTIVITY so all this information is on one place. And, Five years is too long. -- RoySmith (talk) 02:40, 18 December 2019 (UTC)
  • This needs some detail: per RoySmith, is this reversible on request?; is the admin notified beforehand and what about gaming the system? Johnuniq (talk) 03:10, 18 December 2019 (UTC)
  • I am sure there is a definitive number somewhere, but a quick look at https://wiki.riteme.site/w/index.php?title=Special:ListUsers&limit=500&group=sysop turns up between 1000 and 1500 admins. There are 63 on the inactive list above. That amounts to around 4 to 6 percent of the total number of admins. Personally, that is too small a slice of the population to be concerned above considering the goal here is to reduce the # of admins who have no use for the tools. Now, if the % was up around 15% or 20%, I'd be on-board. --User:Ceyockey (talk to me) 04:10, 18 December 2019 (UTC)
    We have 852 current admins. — xaosflux Talk 04:26, 18 December 2019 (UTC)
  • Worth considering is that there are certain administrator-restricted actions that don't create a log entry. I recall that there are some Main Page tasks that can only be carried out by administrators (as I recall, because they involve editing through full protection of some kind), which are not logged actions; however, there are several administrators who specialize in this area and probably don't have a lot of (or possibly any) logged admin actions. There are also some "actively editing" admins who may be using other aspects of the admin permission (e.g., looking at deleted revisions for appropriate purposes, such as rescuing useful references). I think probably more value would come from increasing the minimal total activity level (edits + admin actions) per year in order to maintain admin tools. On the other hand, when looking at compromised admin accounts (which is the main justification for removing the bit), there was no particular correlation between activity of the account and likelihood of compromise. Risker (talk) 05:27, 18 December 2019 (UTC)
    The "the only admin thing I ever do is look at deleted versions" admin seems to be a bit of a unicorn, I've heard of this, but can't recall ever meeting one. — xaosflux Talk 05:31, 18 December 2019 (UTC)
    There are at least two that I know of, one of whom is on the list above. I'd also suggest it's the primary use of admin tools of a bunch of others (including a certain Mr. Wales). I do recall at least two admins who temporarily gave up the bit saying that the only thing they really missed when they continued editing without the bit was not being able to see deleted stuff; they didn't mind not feeling obligated to do the general mop work. Risker (talk) 06:17, 18 December 2019 (UTC)
    Admins who only want tool access to do non-logged actions should probably not have the tools in the first place. They are called 'tools' for a reason. The expectation and obligation is that they will be used to do the general mop work. Only in death does duty end (talk) 09:56, 18 December 2019 (UTC)
    @Only in death: - that seems dubious. The system could have been set up to record any fully protected edit as a logged action, but it would still be the same work. More relevantly, I would count handling the administrative bit around DYK as as general mop work as my closes in AfD. There is more than one way to serve. Nosebagbear (talk) 10:11, 18 December 2019 (UTC)
    FWIW editing through protection is recorded by Special:AbuseFilter/942, created by xaosflux for this very purpose, I believe. ~ Amory (u • t • c) 18:10, 18 December 2019 (UTC)
  • Oppose so as long as we don't have ways to count unlogged admin actions. Which include (but not only that) edits to protected pages and denials of admin actions. Jo-Jo Eumerus (talk) 09:14, 18 December 2019 (UTC)
  • Oppose- What Jo-Jo Eumerus said. Editing protected pages, investigating deleted articles, and such are admin actions but if they're not logged it's misleading. I'm also not a fan of pressuring admins to make a token action every now and then just to hang on to the tools. Reyk YO! 10:08, 18 December 2019 (UTC)
  • VPI? - this is a good idea, but perhaps should have a stint in VPI to resolve potential issues. There'd be a single initial irksome bump, but we could handle this by communicating to any admin getting close and either they can just make that action, or if they can point to non-logged admin work, then they can just be strained out of the list to remove. Nosebagbear (talk) 10:14, 18 December 2019 (UTC)
  • Oppose All admins have a use for the tools ie building an encyclopaedia. Since we are talking about users who are active, no harm is done by therm possessing them, even though they may not be actively engaged in admin work. There is no cap on the number of admins. Hawkeye7 (discuss) 18:37, 18 December 2019 (UTC)
  • Support any time frame. My prefernce would be 6 months. The admin flag isn't a trophy, it's a tool. If the user stopped being admin, for any reason, then they should not have the flag. I've also seen admins who actively log in once a year around the same date and do 1-3 edits. I'd even support a clause that prevents gaming the system, which can be verified on a case-by-case bases. --Gonnym (talk) 18:46, 18 December 2019 (UTC)
  • Oppose per Reyk and Hawkeye. Perhaps gently ask people to help out with some backlogs that require admin tools, but no need to force them. The only use for the proposal I can see is that we wouldn't overestimate the number of admins willing to block, protect, or delete, but I don't see anyone using the admin number for anything serious anyway. —Kusma (t·c) 20:14, 18 December 2019 (UTC)
  • Striking for now as I did not understand the proposal, and now that I do, I would like more time to think about it. — Wug·a·po·des​ 13:13, 26 December 2019 (UTC) Oppose If the users are active, find a backlog and ask if the admin would mind chipping away at it. Odds are, if they are still active, they are using the tools, just not taking logged actions. If the editor is not active, I think this is moot because inactivity requirements would kick in before this. Wug·a·po·des​ 11:42, 26 December 2019 (UTC)
    @Wugapodes: I think this is aimed at admins that are making trivial edits-per-year just to stay admins, those that may no longer meet the requirements for restoration if they were to have access removed. — xaosflux Talk 12:54, 26 December 2019 (UTC)
    They'll have to make one edit and delete/undelete a user subpage if this proposal passes. Won't make a substantial difference to people who do the minimum required to stay admins, but will de-admin those who refuse to game the system. —Kusma (t·c) 11:03, 27 December 2019 (UTC)
    Ironic, considering I would rather retain the admins who refuse to game the system even if they aren't making a ton of logged actions. I think I'm still leaning oppose at the moment. People who game the current system will probably continue to do so if we change the requirement from X edits in Y days to X logged actions in Y days. The only casualties of such a change will be people who have some kind of moral conviction against gaming that new system. That's the opposite outcome from what I would want. — Wug·a·po·des​ 00:16, 28 December 2019 (UTC)
    Apply this immediately, with no warning period. Then there can be no gaming. * Pppery * it has begun... 03:25, 28 December 2019 (UTC)
  • Support Except the waiting period is too long. I actually like the idea of 6 months, proposed by Gonnym. Puddleglum 2.0 04:33, 29 December 2019 (UTC)
  • Oppose Per Jo-Jo. Galobtter (pingó mió) 04:38, 29 December 2019 (UTC)
  • Oppose in its current form. Although I agree that administrators should use their tools to keep their tools, I think that the issue of logs not counting all admin actions means I cannot support this. To clarify, I think that viewing deleted edits is an administrator action which deserves counting, as they may be emailing users the deleted content when appropriate or using it for improvements to non-deleted pages. Dreamy Jazz 🎷 talk to me | my contributions 17:42, 2 January 2020 (UTC)
  • Oppose too many issues brought up for me to support this in current form. DrewieStewie (talk) 20:26, 4 January 2020 (UTC)
  • Oppose The concept is flawed. Many uses of the admin toolset are not logged, so there is no way to verify that an admin is not using it or not. Editing through protections, for just one example. The tools should not be removed unless it is shown they are being abused or misused. --Jayron32 20:37, 4 January 2020 (UTC)
  • Support In my experience administrators who rarely if ever use their administrative powers are usually not involved in admin-related work, and are often quite out of touch with accepted standards, so that when at last they do make a rare admin action it is often way out of line. A significant proportion of them, in my experience, have been admins since the early days of Wikipedia, when virtually anyone who had been editing for a couple of months or so could become an administrator, and many people did so, without any relevant knowledge or experience, and without any interest in doing admin work, and have never been involved enough in administrative areas to be aware of policies and accepted practices. Of course the number of such administrators has declined over the years, but there are still some of them around, and from time to time I have seen one or another of them do things which are unacceptable.
Some of the objections listed above on the face of it appear to make sense, but in fact don't stand up to examination. For example, the remarks about administrators who only deny admin actions, not perform them. Yes, it is true that a decision that an admin action should not be performed is as much an administrative decision as a decision that it should be performed, but to be realistic what kind of administrator only ever decides not to take action, and never to take action? In the very unlikely event that there is someone who does that, I would be very interested to have his or her explanation as to how that can be constructive. Then we are told about administrators whose only use of the tools is to view deleted content. In my opinion that is a very good reason for the proposal, not against it. Administrators are given the power to view deleted content in order to be able to perform administrative tasks that require such viewing, not just as a kind of special privilege. If someone is an administrator purely so they can use that power for their own use, not in order to perform administrative tasks, then they should not be an administrator. And yes, of course people can think up possible justifications, such as "they may be emailing users the deleted content when appropriate or using it for improvements to non-deleted pages", but how realistic is it to suggest that there really are lots of administrators who use their admin powers for uses of that kind sufficiently frequently to make a significant impact, while never doing any other admin tasks, over the course of many years? It could happen, and just conceivably there may be someone somewhere who does that, but it is unrealistic to imagine there is a large enough number of such administrators to outweigh the very real damage done by the out-of-touch admins that I mentioned above. Likewise, it is correctly stated above that "Editing through protections" (presumably meaning admin-only protections) is an admin action that is not logged, but again, how realistic is it to suppose that there are administrators who use that ability often enough for it to be a significant useful contribution, while never doing any of the far more common and significant admin tasks? JBW (talk) Formerly JamesBWatson 20:55, 4 January 2020 (UTC)
As I write below, editing the main page is a service that isn't formally logged. Another reason for looking at deleted articles would be to check the deletion was in policy. For example, I just did a bunch of look-ups regarding the arbitration case open on RHaworth. It would be possible to patrol deletions and bring errors to deletion review without ever hitting undelete. Espresso Addict (talk) 01:28, 5 January 2020 (UTC)
  • Support and explicitly reject the red herring that "not all admin actions are logged". If we're talking in the short term, this is a real factor. If we're talking about a period of years it is not. An admin who is only using the viewdeleted right or other unlogged admin rights for five years isn't doing admin work, and that's what the community gave them the extra permissions for, so if they aren't doing admin work, they don't need the tools. One of the inactive admins who was just removed had one admin action in all of the 2010s, a single revdelete, and they didn't even do it right. This is exactly the kind of thing we should be actively curtailing with reasonable requirements like "maybe do some real admin work once every five years or so." Beeblebrox (talk) 21:05, 4 January 2020 (UTC)
  • Oppose What problem is this trying to solve? There are processes to remove inactive editors, and rogue admins. Therefore, the people this would be seeking to remove the tools from are active editors who have not transgressed. Their trustworthiness was tested when they became admins, and they have done nothing to break it since. --Scott Davis Talk 21:29, 4 January 2020 (UTC)
  • Strong support I would support 3 years also. Likewise we should not count using admin tools less than one in let's say half a year, otherwise admins could game the system and make an admin edit every once in a while, just to avoid having their admin rights removed. Debresser (talk) 21:35, 4 January 2020 (UTC)
  • Support per User:JBW. I really can't add anything to his thoughtful analysis. Except perhaps that two or three years would do me also. Bishonen | talk 21:41, 4 January 2020 (UTC).
Bishonen I too think 5 years is longer than necessary, and 3, or perhaps even 2, would be better, but I think getting the change in some form, no matter what the time limit, would be a great improvement on the present situation. JBW (talk) Formerly JamesBWatson 21:51, 4 January 2020 (UTC)
@JBW: Yes, we really don't want this to fail because people suggest different lengths of time. That is not the focus of the discussion, and I hope the closer here counts all supports, no matter the time, together. Bishonen | talk 21:56, 4 January 2020 (UTC).
  • Strong support although I would also support a shorter length of time as a few others have mentioned. I support reasonable activity requirements for every permission beyond extended-confirmed. It's sensible. Things change, and the only way to stay current is to be actively involved. Extra permissions are granted for those editors to make greater additional contributions beyond the editing that everyone can do. If they're not making those contributions, they don't need the permissions. Schazjmd (talk) 22:06, 4 January 2020 (UTC)
  • Comment Not ready to support or oppose yet, but I was concerned about the possibility of demoralizing a useful editor who maybe isn’t using their tools but is at least contributing, so I checked edit histories. We have 2 sysops with 0 edits in 2019, 9 with 1, 6 with 2, 6 with 3, 8 with 4, 8 with 5, 7 with 6, 7 with 7, 1 each with 8, 9, 10, 11, 14, 15, 21, 29, 40 edits in 2019. (I’m not going to post names, but if anyone wants to check my work just email me and I’ll send it.) --valereee (talk) 23:34, 4 January 2020 (UTC)
  • Oppose unless unlogged actions such as editing the main page are included. There are several competent, active admins who serve primarily in that capacity and rarely if ever use the other components of the toolset. I do, however, take JBW's points on looking at deleted articles & declining requests for admin action; while these are administrative actions, if one never undeletes a wrongly deleted page or deletes a correctly speedy-tagged article over 5 entire years then something is going wrong. Espresso Addict (talk) 01:19, 5 January 2020 (UTC)
  • Strong support I do not think any administrator who has no logged action in five (5!) years is using their tools effectively at all. A simple look at ANRFC, CAT:RFU shows that there is work to be done, that is not being done. I do not understand the "unlogged admin actions exist" rationale as I cannot imagine being granted a toolset for the explicit purpose of using them and then choosing to do none of it for 5 years, it makes absolutely no sense. --qedk (t 桜 c) 21:43, 5 January 2020 (UTC)
    Just to clarify as Bish and JBW wrote above, I am acceptable to a 5-year period (as proposed). --qedk (t 桜 c) 21:46, 5 January 2020 (UTC)
  • Support; I think the suggestion that there are highly-active admins who never delete, undelete, block, or protect anything is somewhat of a red-herring. Also support any period of 2 years or longer. Stifle (talk) 10:09, 6 January 2020 (UTC)
  • Support: admin status is not a right; admin should demonstrate active use of their tools. Support any range above 2 years; 5 years seems too long. --K.e.coffman (talk) 01:57, 7 January 2020 (UTC)
  • Oppose: Personally, I honestly don't really know if I've taken particular advantage of logged admin powers recently - does reviewing deleted histories count, for example? I think the real consideration should be whether admins have stopped editing. I'm not a "red herring." For me, 5 years isn't that long a time, by the way. I've been editing Wikipedia for nearly 20 now. --The Cunctator (talk) 04:26, 7 January 2020 (UTC)
    You deleted a page just a few months ago. — xaosflux Talk 04:34, 7 January 2020 (UTC)
    While we're on the subject, are statistics on other admin actions such as page moves, file moves and template edits being kept? They are not listed as admin actions by the edit counter, but are still part of the admin tool set, and are frequently used. Hawkeye7 (discuss) 21:31, 10 January 2020 (UTC)
  • Support if DYK(+cascade) recognised, weak oppsoe if not - If the full-protected edit abuse filter is used, then I'd be on board (that is, either a logged action or an edit to a protected page). I'm reticent to think an appreciable amount of admin work could be done (in the scale of a multi-year timespan) purely by looking at deleted content. Preference for 2 years, support anything for 2+ years. I do however, feel that those editing protected (usually DYKers) need exemption, there's a filter log but it doesn't track cascaded protection. If they can be "caught" then I think it's a good positive, otherwise it's a weak negative . Nosebagbear (talk) 11:53, 7 January 2020 (UTC)
  • Question: I see some editors are commenting about main page and DYK pages. If we have a group of admins only editing these pages and don't actually use the tools for other admin actions, won't a better solution be to create a new user-group that gives them the right to edit these pages? --Gonnym (talk) 12:40, 7 January 2020 (UTC)
    @Gonnym: I know at least one editor that is working on a "main page editors" group proposal. — xaosflux Talk 12:45, 7 January 2020 (UTC)
  • Weak Support – If "need for the tools" is a primary concern and experience in using them important, then there should be a requirement that admin actions be taken regularly (and removing the privilege after a lapse of five years too lenient). However, what does some arbitrary time limit solve? If unused admin accounts are a security risk, there needs to be other action taken. If inexperienced admins start blundering about, there should be other, quicker ways of addressing the problem. I note that all the editors on the lapsed list above have edited in the 2018–19 time frame, even if their total edit counts are often surprisingly low. I don't like potentially driving away experienced, careful editors by applying some arbitrary time limit that doesn't really solve anything. Dhtwiki (talk) 21:39, 7 January 2020 (UTC)
  • Support assuming filter 942 hits are considered admin actions. Only using the view deleted content part for 5 years sounds unfeasible, but if this hypothetical person comes to BN asking for their bit back shortly after desysoping just go ahead and grant it. ‑‑Trialpears (talk) 23:05, 9 January 2020 (UTC)
    After seeing more and more people trying to find the unicorns and failing I would be fine with remocing it without checking the edit filter as well, but if someone comes complaining at WP:BN that the bit was removed when they were using it for deleted contribs. ‑‑Trialpears (talk) 13:50, 20 January 2020 (UTC)
  • Support per JBW. -FASTILY 00:26, 10 January 2020 (UTC)
  • Support You're simply not an admin if you haven't done anything on the project for five years. I'd also strongly support it being brought down to two years, seeing as admins lose their rights after one year in any case. Lugnuts Fire Walk with Me 09:50, 10 January 2020 (UTC)
  • Weak oppose in its current form. Concept works, but there are problems with unlogged admin actions. Also, I a not sure about being an activ/e admin/user. >>BEANS X2t 13:45, 10 January 2020 (UTC)
  • Oppose: a solution in search of a problem. Yes, there are issues with tools being kept by inactive admins, but just a few percent of admins fall under the scope of this proposal and this issue is relatively small compared to the enormous existential problem we have that there are too few admins, not too many. If you want to debate adminship, try talking about how to increase the number of RfAs or how to increase admin retention. — Bilorv (talk) 16:48, 10 January 2020 (UTC)
  • You are right Bilorv, but maybe the better solution is to show a more realistic view to the community of true number of admins in WP? Why inflate our perception of the size of the admin core when a material percentage have been missing for 5 years? Britishfinance (talk) 18:11, 10 January 2020 (UTC)
  • Inflate by 62? I certainly didn't know the current number of admins to within 62 people before reading this discussion. I'd rather not waste more time arguing over what I continue to view as a solution in search of a problem, so I appreciate the ping but I'd prefer to receive no further pings in this discussion. — Bilorv (talk) 18:27, 10 January 2020 (UTC)
  • Does it really matter either way? If someone is not using the tools then what does it matter whether they have the theoretical ability to do so? Surely a much greater problem would be that of admins who do use the tools, but use them badly? Phil Bridger (talk) 17:25, 10 January 2020 (UTC)
  • Support. Per JBW; perhaps definition of activity can be tightened to capture more actions, but as per JBW's comments, these are still pretty unlikely scenarios, and the core problem of non-functioning admins reviewing confidential information/making out-of-date actions, is a problem. It would also help to clarify how many admins we have in WP. Britishfinance (talk) 18:07, 10 January 2020 (UTC)
  • oppose, a solution looking for a problem. What is the problem, really? If someone has admin tools and they do not use them... the problem is...? The only significant problem I can see above is statistical, the list of admins are inflated, and yes that may be a problem, as some already explained. The simpler solution is to improve the stats about admins. Instead of only "we have 1000 admins", or "we have X active admins", make list of how many did at least N blocks / deletions / undeletions / revdels / etc. in the previous M months.(I am an admin, not very active, mostly a few deletions a month). - Nabla (talk) 18:40, 10 January 2020 (UTC)
  • Support as long as it is (a) with ample notice; (b) with right of refusal ("no, I'd like to keep this bit, I view deleted articles and such often enough that I find the bit useful"); and (c) without prejudice, so the removed status will be restored upon request. --jpgordon𝄢𝄆 𝄐𝄇 18:58, 10 January 2020 (UTC)
  • Support. As @K.e.coffman: made it perfectly clear: adminship is 100% a privilege. I just gave the administrators access to a list of 34 provisional admin candidates, and we should make good use of it to renew the admin pool. Perhaps two years will suffice? ミラP 04:50, 11 January 2020 (UTC)
  • Support. Two years seems long enough to me, but five years makes it pretty obvious that you're mostly just wearing a hat, not helping with backlogs. Another consideration is the principle of least privilege, which suggests that accounts should only have the privileges they need. The more accounts we have with admin access, the easier it is to find one with a terrible password and compromise it. Our website has been subject to brute-force attacks in the recent past, so this isn't just some obscure, theoretical issue. NinjaRobotPirate (talk) 12:12, 11 January 2020 (UTC)
  • Support. To User:Risker, User:Espresso Addict, and anyone else posing the hypothetical of admins using non-logged privileges to improve the encyclopedia without ever performing a logged action, I issue a challenge: I would like to see some real examples, please. Because I'm not finding them. I started going through the logs of users who had edited the main page recently, then similarly for DYK queues, and found no examples that did not have a logged delete/protect/block within the past several months, much less for the multiple years proposed as the new standard. Frankly, if these people exist, I would expect them to be coming forward themselves, to point out the protected edit requests they fulfilled, the bad deletions they have raised at DRV (or ANI or wherever), the WP:G4 deletions they have declined after looking at deleted material, etc. All without a single logged action for multiple years. I am willing to go so far as to assert that no such admin exists; prove me wrong if you can. Also to be clear, if someone has examples of privileged users reading deleted edits without connection to any sort of admin work, I would consider those to be examples in favor of this proposal. We do not want users to be able to creep through libels, copyright violations, and exposed private information unless they need to do so for administrative tasks. That is why this is an advanced privilege in the first place! Indeed, for anyone saying this is a "solution looking for a problem", I say the opposite: unchecked, unmonitored eternal access to deleted edits is a problem posing as a solution, a problem that should never have been built into the system in the first place. It is time we fixed that problem. --RL0919 (talk) 17:13, 11 January 2020 (UTC)
@RL0919: I'm mainly thinking of the admins who maintain the main page. There was a long period, not recently, when I rarely if ever performed a logged admin action but did patrol main-page errors, copy edit DYK queues and update ITN. There doesn't seem to be a way to analyse logged actions for an admin in the way the edit counter displays edit count by month; that would be interesting. Espresso Addict (talk) 23:50, 11 January 2020 (UTC)
That would be interesting, but more important is that with the edit filter mentioned above, we do have a way to identify protected page edits that are not included in the standard logs. A formal RfC to establish a new standard for admin actiivty should include that. Which means the main things missing are reviewing deleted edits and denying requested admin actions, so the scope for the hypothetical untrackable admins is even smaller. --RL0919 (talk) 03:49, 12 January 2020 (UTC)
The proposal as written seems to exclude actions captured by the edit filter but not the log. Espresso Addict (talk) 03:54, 12 January 2020 (UTC)
  • Support 5 years, only counting actual admin logged actions. This would align more with the cut off for reinstatement at BN. A bot could check for these, perhaps monthly. Don't bother with any countdown warnings. The real test of this would be shown after it is implemented: how many admins get removed via this process that re-request at WP:RFA and pass shortly after? If this become a significant number, revisit. — xaosflux Talk 18:48, 11 January 2020 (UTC)
  • Oppose - solution in search of a problem, and an overall net-negative. Anecdote: I used to be an administrator here, and went on a year-and-a-half hiatus. When I came back, I no longer had admin privileges. I'm not going to ask for them back - I'm not that active here anymore, nor do I really want to be. But if I had still had the bit, I probably would have probably used it occasionally to the benefit of the project. Removing the bit from inactive administrators doesn't really help anyone. Rami R 19:58, 11 January 2020 (UTC)
  • Comments
    • This proposal looks a little loose and it is unclear what the outcome would be because of introduced caveats and the nature of the proposal seems to have changed. Unclear wording. Some are supporting leaving no notice which is flawed and a bit rude. If the proposal called for leaving a talkpage notice, and emailing the admins for those that have it enabled, asking them to post at the bureaucrats' noticeboard justifying why they should keep the tools then that would be more satisfactory to the community. Accommodating for some of the concerns in the comments above, this would also allow the opportunity for the odd cases of admins that never make any logged actions to still be heard. If they explain themselves adequately then they could retain the tools but the matter could be left to the consensus of the bureaucrats. I still think that the wording needs to be refined.
    • The !voting above is still a local consensus. If the wording were well-adjusted then you would need to setup an RfC and advertise at AN and CENT. I think it is premature for that.
       — Berean Hunter (talk) 20:53, 11 January 2020 (UTC)
      @Berean Hunter: This RfC is held at a centralized venue and listed at CENT, thus consensus here is not LOCALCONSENSUS. --qedk (t 桜 c) 16:04, 12 January 2020 (UTC)
  • Support Per JBW. I have come close to the 1 year mark of no admin actions in the past but I still think some time limit is needed. I think 6 months is too short and five years absurdly long. 1-2 years seems about right. Inactive admins (not using the buttons) are also a security risk and clearly a consideration in this matter. Cheers, Mark Ironie (talk) 21:09, 11 January 2020 (UTC)
  • Oppose Doesn't count unlogged actions, such as Main Page updates. If I shifted my admin work away from AIV to focus just at T:ITN, then my tools would be removed under this standard. SpencerT•C 20:11, 12 January 2020 (UTC)
@Spencer: No system is going to be perfect, but I have to question how relevant this specific reason is. Is there evidence that there has ever been an admin who would've been desysopped because literally the only thing they did for three straight years was update the main page? Beeblebrox (talk) 20:33, 13 January 2020 (UTC)
Not that I can think of, and I'm not familiar with any of the names on the list being active at ITN (can't speak to DYK). That said, I think that if we're going to be taking away tools, that the criteria need to be well constructed. Additionally, for further rationale, I believe this proposal is a solution in search of a problem. Best, SpencerT•C 04:43, 14 January 2020 (UTC)
@Beeblebrox: There's Gatoclass who uses the tools to edit fully-protected pages for DYK and made no logged admin actions from 2016 until 2019 [1].-- P-K3 (talk) 16:56, 17 January 2020 (UTC)
  • Oppose, it's not like we have a limited number of admin slots. As long as someone is not abusing the tools and has not left Wikipedia entirely (which we already handle), there is no harm in them continuing to have them. Besides, such a measure would only require a token gesture, such as creating a userspace subpage and deleting it, to get around. We only desysop for inactivity when the admin apparently has no interest at all in editing Wikipedia for an extended period, and that's exactly as it should be. Seraphimblade Talk to me 20:35, 12 January 2020 (UTC)
  • Support - Personally I'd prefer 1-2 years over 5, If the user for whatever reason hasn't used their tools for 5 years then they should be removed. –Davey2010Talk 21:25, 12 January 2020 (UTC)
  • Support Per JBW. Pharaoh of the Wizards (talk) 03:57, 13 January 2020 (UTC)
  • Oppose per Bilorv, this is indeed a solution in search of a problem. The real problem is the dearth of RFAs, not the retention of unused tools by a minuscule minority of admins. GABgab 04:57, 13 January 2020 (UTC)
I'm not seeing how addressing one problem precludes from addressing the other. Beeblebrox (talk) 20:44, 13 January 2020 (UTC)
  • Oppose - Inactivity removal for inactive admins already exists. This proposal just tells active admins who mostly edit articles to "go block a vandal" or "go delete a spam page" every five years. Reaper Eternal (talk) 16:15, 13 January 2020 (UTC)
  • Oppose I'm not sure what this proposal is supposed to accomplish. As long as a sysop is not abusing their privileges, who cares how frequently they use it? As is, there already is precedent for removing sysop rights based on inactivity, so there isn't really anything to gain by making this procedural. The nom themselves stated that this would only apply to a grand total of 62 users, out of over 1000 sysops. Clearly, this isn't a very pressing issue. --PuzzledvegetableIs it teatime already? 18:29, 13 January 2020 (UTC)
Because there is a provable, recurrent problem with admins who haven't been doing admin work for a prolonged period suddenly deciding to dive back in and misusing the tools or misunderstanding current norms for their use. I have seen cases of admins who haven't used their tools in over a decade, but so long as they make one edit every year, they keep their adminship. There was one extreme case where a user had never used the tools, yet had them for something like 12 years, and could've just dove in and started blocking people and deleting content at any time right up to the day they were finally removed for total inactivity. And even then, under policy at that time, they would've had two years to ask for the tools back and they would've been granted. Does that really seem like a good idea? Beeblebrox (talk) 20:40, 13 January 2020 (UTC)
It doesn’t sound good, and that is why I’m fine with sysop rights being removed on a case by case basis. However, making this into a rigid procedure is a bit overkill. We’re essentially worried about a problem that is easy to fix after the fact, and that is only applicable to a grand total of 62 users, simply because of a few incidents in the past. --PuzzledvegetableIs it teatime already? 03:12, 14 January 2020 (UTC)
  • Support per what he said. GenQuest "Talk to Me" 04:30, 14 January 2020 (UTC)
  • Oppose The "solution in search of a problem" has not been disproved. This along with the continual "deadmin those who don't edit enough" proposals being reduced further and further indicate what I consider a disturbing trend. Getting rid of more and more sysops simply makes those who hold the position more and more of a clique power-group who wield more power than they really should. Originally the admin bits were to be no big deal - and yet this site continues to make it a bigger and bigger deal with proposals such as this. Not that I really care for myself, but be careful what you wish for. — Ched (talk) 04:50, 15 January 2020 (UTC)
  • Support (with comeback restrictions) . If the admin decided to comeback they should not be allow to use admin tools for a short time. (5 year admin inactivity = 5 week no special admin tools no exceptions) Regice2020 (talk) 08:51, 15 January 2020 (UTC)
  • Support Security 101 actively vet your admins and remove inactive admins. We provide anyone that wants a list of inactive admin accounts to take over - the list of 215 admins that have not done anything for the past 3 months. A good security improvement would be to remove admin after 3 months inactivity, to be automatically returned on request when coming back to activity... And give admins a reasonable number of returns e.g. 5 returns before loss of rights - lots of people have gaps in there support of wikipedia - we all have alternative lives :) But there does need to be some protection. RonaldDuncan (talk) 16:46, 15 January 2020 (UTC)
  • Support It's bad practice to allow the list of admins to become contaminated with those who never act in that capacity: (1) it encourages hat-collecting/retention; (2) it makes it more difficult for users who need to talk to an admin to find one who is actually active; (3) it gives power to people who don't have up-to-date knowledge of the tools and (even more important) the community; and (4) it provides users with a spurious aura of power/respect to which they are no longer entitled. I'd say that five years is far too long; two would be better but I'd go along with five. No concerns about the 'unlogged admin activity' issue; that is a real edge-case. The number of people usefully acting as an admin for five years without ever doing anything that gets logged as an admin action must be vanishingly small. MichaelMaggs (talk) 17:32, 15 January 2020 (UTC)
  • Oppose Hi everyone! I'm one of those "unicorns" that xaosflux doubts exists. My most frequent use of my Admin powerz is to look at deleted pages. Once in a while I'll move a page because when I created it I screwed up the name. But I rarely use the other powerz in part because I don't look for fights where I can flaunt those abilities & intimidate other users. I'm here to do something that might surprise people: write & improve content. (This is the kind of selfless, benevolent effort that made Wikipedia one of the top 10 websites. Not fancy software or spending 2 years drafting a 2030 strategy plan.) I do keep them at hand as I in case they are needed, but often I can find another way to solve a problem. BTW, I believe I'm fairly up-to-date on policies & whatnot, & if I'm a little rusty I know where to go to refresh my memory. (Hmm. I ran for ArbCom lately, & no one acted as if I didn't know that stuff.) As someone else said above, this is a solution in search of an answer, & all this does is create Yet Another Hoop for me to jump thru just to contribute. -- llywrch (talk) 00:31, 16 January 2020 (UTC)
If Llywrch can't be a unicorn, then at least a bicorne makes a good substitute
  • @Llywrch: sorry, but I think I'm going to have to confiscate your horn - while you are certainly on the light side for logged admin power usage you are well outside of the 5 year threshold I mentioned. Not only have you certainly logged admin activity in the last 5 years, but you have indeed logged admin activity in each of the last 5 years (Here are some spot examples from your own log: 2019, 2018, 2017, 2016, 2015). — xaosflux Talk 00:45, 16 January 2020 (UTC)
    Not only safe for a 5-year threshold, but even for a 2 or 3 year limit. I think this speaks to a lot of the unspoken concern that may exist among admins who worry that they could lose access easily, almost accidentally. The reality is that even if you think you aren't very active, just being around to comment on this discussion means you are almost certainly more active than the people who would be affected by this proposal or any largely similar proposal. --RL0919 (talk) 00:58, 16 January 2020 (UTC)
  • Support – activity requirements serve two purposes: they increase security, and they encourage people to use the tools they have been given. We already have activity requirements for bureaucrats, checkusers, oversighters, stewards, and OTRS, all of which are way more stringent than one action in 5 years. There's even talk of having activity requirements for non-admin perms such as new page patrol and AfC. One logged action in 5 years is not too much to ask. – bradv🍁 03:12, 16 January 2020 (UTC)
    We already do already have activity requirements for new page reviewer namely 12 months, same for page mover and probably others. Crouch, Swale (talk) 14:33, 8 February 2020 (UTC)
  • Support I would join the oppose side if anyone made an argument for the correct amount of time. If not 5 years, is it 7, 10, or what? We take enough care with the management of admin rights that it seems reasonable to me to remove them when not in use after a certain amount of time. I recognized that there are unlogged admin rights, but to me, making at least 1 edit every 5 years (or whatever is the appropriate amount of time, whether longer or shorter) is a reasonable bar to demonstrate awareness that we monitor the userright. Blue Rasberry (talk) 19:21, 16 January 2020 (UTC)
  • Support It's pretty simple: if the community trusted a user to have extra tools it was with the understanding that those tools would be used to improve the project. Keeping the tools "just in case" they might find them useful or just because they like the status or just to look at otherwise-hidden pages is not using them to improve the project. Even the "non logged admin actions" argument is largely illusory, as Llywrch's experience above demonstrates. I don't see anything in all the arguments above to indicate that an admin using the tools only in ways that are escaping the logs is actively improving the project. Eggishorn (talk) (contrib) 19:54, 16 January 2020 (UTC)
    • Well Xaosflux may have made a persuasive point, but there is one other non-logged function Admins perform that has not been mentioned here: closing discussions, both at WP:AN/I, & those listed at Wikipedia:Administrators' noticeboard/Requests for closure. Which is where I've been most recently been working -- or at least until I was forced to cut back on my activities here 15 months ago. (And there is another non-logged function -- speaking offline as a representative of en.wikipedia -- where being able to mention having the Admin bit gives one a bit more credibility than simply saying "I have made a lot of edits". But were there a way to acknowledge Wikipedians who are more involved for longer periods than others, I'll admit that this would not be an issue.) -- llywrch (talk) 21:10, 16 January 2020 (UTC)
  • Support – I do think that the current administrator inactivity policy is too lenient. In general, administrators should be expected to use the tools they are given on a regular basis. Not doing so may be harmful because policies and best practices may change over time as Wikipedia matures and develops a better understanding of the best administrative responses to various situations. One logged action every five years is probably still too lenient, but it is stricter than the lenient policy we currently have. Mz7 (talk) 21:14, 16 January 2020 (UTC)
  • Comment – for those interested in more of these "unicorns", Gatoclass and Art LaPella are two more examples. It is only a bit of an exaggeration to say that they trigger filter 942 more times in a month that they've ever made logged actions. I think I understand the motivation behind this proposal, but I'm not particularly certain what problem it will solve. It is still trivial to game – one edit per year plus one logged action per five years. It feels like it will add another layer of bureaucracy to an already bureaucratic process. If we agree that lifetime appointments are not a Good Thing, then we should go about fixing the systemic issues instead. With the current system, it's unwise to let one's admin powers lapse, because RfA is not very pleasant or easy to go through. So, if an admin hopes to be more active in the future, then it makes perfect sense to make token edits to avoid the issue (but as we know, not all dreams come true). The current inactivity system is very specific-numbers-oriented because it doesn't really involve community review (it's largely done by a bot overseen by a few bureaucrats). If there were to be more community oversight (think like a steward confirmation on meta), then the cases of last 50 edits date in the past 5-10 years would not sneak through. It also really depends on what the community wants admins to be. In terms of raw numbers of users with the sysop bit, I think the majority is from a time where No Big Deal meant "you've been around for a while and we trust you not do anything dumb, so here's +sysop if you ever need it" whereas now we generally expect RfA candidates to demonstrate competency in a variety of administrative areas to have any chance of passing. It's also important to note that most inactivity proposal have failed in the past. I, for one, am not a fan of what we have already. I think either just not bothering with inactivity desysops (recent compromises have been of abundantly active accounts) or doing a more thorough admin-by-admin review (hopefully coupled with a lower bar at RfA...) are better than the system we have right now. Maxim(talk) 15:20, 17 January 2020 (UTC)
    @Maxim: I think my dreams of unicorns are getting stretched a bit :) Originally this referenced an admin who claimed to only ever look at deleted content - but extending it to protected editing isn't too hard - as it was only meant to be an absolute cut off for why there are no logs at all. Both of your example admins have logged admin actions within the last 3 months. — xaosflux Talk 15:50, 17 January 2020 (UTC)
    Xaosflux, oooops, I'm sorry for misinterpreting you... :-/ I got totally focused on the logged actions part. Maxim(talk) 15:53, 17 January 2020 (UTC)
  • Oppose no need, more bureaucracy, discourages users from returning to such work. Crouch, Swale (talk) 19:55, 17 January 2020 (UTC)
  • Oppose I don't think there is a problem. I do know that I have gone at least two consecutive calendar years without a logged action, but I was in the top half of active admins in number of logged actions in calendar 2019. If I lost the mop, I don't know that I would want to put myself through the current process of RfA. - Donald Albury 20:26, 17 January 2020 (UTC)
  • Support per bradv🍁 and  Beeblebrox - Occasional use of privileges is a reasonable expectation for administrators, and a reasonable baseline for security. Category:Administrative backlog shows that there is no shortage of tasks, simple or complex, for an admin to take on if they have a free hour or so in a given 5 year period.Dialectric (talk) 20:38, 17 January 2020 (UTC)
  • Oppose. The admin toolkit is a privilege based on trust, not a job with obligations. If someone is participating in the community, and has earned the trust to use advanced tools, there is no need to remove them unless they are misusing them, showing the trust was misplaced. Enough with the Chinese water torture of trying to find bureaucratic ways to remove adminship from people; seems there's a new proposal in this direction every month or so! If someone with a rusty "admin" label, however you choose to define it, is not causing any harm, why not just let them be and perhaps some day they will use the tools to the net benefit of the encyclopedia? Martinp (talk) 21:00, 17 January 2020 (UTC)
  • @JBW: wouldn't this proposal create the very problems you're suggesting? The 1st thing someone who gets a message about loosing their tools is going to do is go straight to Category:Candidates for speedy deletion and possibly preform bad deletions. And I don't think we could remove tools without warning (and I wouldn't support that). Crouch, Swale (talk) 21:20, 17 January 2020 (UTC)
    Sure we could. We could put it in ADMINNEWS, wait a month, then do it. Everyone doesn't really need an engraved invitation. — xaosflux Talk 22:18, 17 January 2020 (UTC)
  • Support Over 60 people are still admins with advanced permissions that they have not used since those advanced permissions were given much more freely, they haven't used them in over five years, they don't need them, things are very different on the wikipedia and the www since then, remove them immediately would be my position. Govindaharihari (talk) 18:15, 18 January 2020 (UTC)
  • oppose I have some concerns on the actual logging of some aspects of admins using tools as described above, there are some solutions in the pipeline for part of that but they arent here. The other issue I have is that as volunteers we take on roles for the community, some of these roles can cause COI most of us manage those periods of potential COI with no fanfare. I've just stepped down after 6 years in a leadership role President/Vice President of an affiliate, during that time there were a lot of demands on my time for the community that restricted my on WP activity. In those 6 years I still followed changes and shifts in policy, edited articles, ran workshops, and other things using the mop but also in balance with my role serving the Affiliate as a volunteer at times meant that there were many areas where it wasn't prudent to act as admin blocking/unblocking, deleting/restoring, protecting or not despite the correctness of such action because they could be conceived as giving the affiliate an editorial control over content. Yes I did log activities like account creation, cleaning up post workshops, deleteing images uploaded as a demonstration, there are many other things in a persons life that may cause an active editor to stop using the mop for periods of time after 5 years. I accept that the a question could be asked lets have a clear process of discussion over time, that starts before then, rather than create a group hunters stalking, waiting for the foot over the line moment to bag 'em selves an admin. Gnangarra 13:55, 19 January 2020 (UTC)
    • @Gnangarra: hi there Gnan. I see good faith users with concerns around long term non usage of advanced permissions, you say you see hunters stalking, waiting for the foot over the line moment to bag 'em selves an admin. please assume good faith wp:agf thanks Govindaharihari (talk) 16:03, 19 January 2020 (UTC)
      • @Govindaharihari: heres the interesting thing why cant we also assume good faith in the admins, if they are doing no harm then why take the mop away. 15 years experience on here, tells me that this isnt an issue but the stalking will be. I also said lets have a clear process of discussion that starts before 5 years. What I propose at 3 years just a simple notice by bot something like its has been 3 years since the system recorded any admin actions from your account, if you no longer need them please contact a Bureaucrat to remove them. You can reapply at any time for the mop to be reinstated without issue.. Then repeat the message at 4 years also add If you have been using the mop please contact WP:BN with a diff to report there may an issue logging admin actions.... then at 4 years 6 months It is has been 4 years 6 months since you logged an admin action please post to WP:BN to confirm you still need the mop"... finally at 5 years It has been 5 years and you have not performed a recorded admin action, you may soon find that the mop has been removed without prejudice. you have 14 days to post at WP:BN the reason why you need the tools, or can request bureaucrat to contact you by email if there is reason that cant be made public. A Bureaucrat will review your activity then contact you by email to confirming the removal of the mop. Should the user convince the bureaucrat to continue holding the mop the crat would put a time limit on how much longer they should be given to perform an admin action at which stage the bot would notify at WP:BN that time is up and the mop should be removed. The process is then a minor procedural action that happens in the background notification are automated by a bot supervised by Bureaucrats, its not something editors need to commentate on. For those who have currently passed the 5 year mark they should given the 4 year 6 month notice in good faith recognising they have served the community for a long time and let the process commence from there. As has been said by Govindaharihari the process is it not a hunting party looking to bag 'em selves an admin is it? Gnangarra 04:16, 20 January 2020 (UTC)
    • I just saw the list above of people with the Admin bit who haven't used it in 5 years. (My first reaction is of surprise that some of these people are still around: 6 of them joined Wikipedia before me!) As Gnangarra points out, some do contribute in inobvious ways, such as Mindspillage who is a former member of the Board of Trustees. At the vary least, if this proposal is implemented they deserve a warning that if they don't perform an admin action in the next 30 days it will be removed. (Some might simply consent to losing it if asked.) -- llywrch (talk) 18:37, 8 February 2020 (UTC)
  • No thanks. It feels like we are getting a constant stream of these proposals now. Once, administrators served for life and this rule became ill-fitting when Wikipedia started maturing. We changed the rules so that inactive accounts could no longer be administrators. Then we changed it once or twice more, as we watched the rule play out in practice and needed to refine it. That sort of fixed the whole problem of administrators never losing their permissions. It should not have opened the door to a constant tinkering with what is "good enough" from an admin. We decide that sort of thing in the course of events, not by trying to pre-set an arbitrary threshold and constantly changing its definition. Things here are fine. AGK ■ 13:46, 20 January 2020 (UTC)
  • Oppose, this appears to be a solution in search of a problem. Is there any evidence of actual harm caused by non-use of admin privileges? I see no benefit to instituting yet more bureaucracy to fix a non-existent problem. older ≠ wiser 14:00, 20 January 2020 (UTC)
  • Oppose Not all admin actions are logged. This isn't really solving any issue. -DJSasso (talk) 18:52, 20 January 2020 (UTC)
  • Oppose I agree with removing privileges from fully-inactive accounts, but if someone is active in the community, there's no reason to remove the bit because it might possibly be used incorrectly. --SarekOfVulcan (talk) 19:20, 20 January 2020 (UTC)
  • Oppose per many arguments above. Furthermore: the biggest problem we face is attracting and retaining admins, not removing them. --Dweller (talk) Become old fashioned! 14:53, 21 January 2020 (UTC)
  • Oppose. To me, adminship is about trust, civility, and knowledge. If a person, who I previously thought to be trustworthy, civil, and knowledgeable hasn't done anything to provide evidence of no longer being so, then the status quo remains. Useight (talk) 19:08, 21 January 2020 (UTC)
  • Oppose per user:Seraphimblade and user:Reaper Eternal -- PBS (talk) 19:30, 21 January 2020 (UTC)
  • Weak oppose in current form though basic reasoning is correct (and I have not given fullest scrutiny) Proposal needs to be framed as a modification of WP:INACTIVITY. From a security viewpoint leaving inactive admins around just increases the attack surface. With absolutely no disrespect to anyone a long length of inactivity may in some cases mean capability, currency and/or judgement may have become impaired. But RL commitments do come up people and quite rightly they may need to stand back for a while. Key point is any modification needs to be in the context of a specific change to WP:INACTIVITY in my opinion.Djm-leighpark (talk) 21:11, 21 January 2020 (UTC)
  • Support per JBW and Beeblebrox. Doing one logged action every five years is hardly an onerous demand. Boing! said Zebedee (talk) 04:46, 22 January 2020 (UTC)
  • Weak oppose - Do we actually have a problem with inactive admins forgetting how the tools work? This seems like it would lead admins to do some pointless token admin action every 5 years, and I can't see how that would benefit the project. ~~ OxonAlex - talk 17:32, 22 January 2020 (UTC)
  • Support per many well-reasoned arguments above. I would support a shorter time period as well, but five years is a nice low bar to start. CThomas3 (talk) 06:02, 24 January 2020 (UTC)
  • Oppose – Making no edits or anything at all is one thing, but this seems like a solution in search of a problem that provides little-to-no benefit to the project. Master of Time (talk) 22:50, 24 January 2020 (UTC)
  • Support per JBW et al Levivich 03:51, 25 January 2020 (UTC)
  • Meh The ancient (in Internet terms) problem this is trying to solve is admins are simultaneously "just editors with some extra buttons" and authority figures. Separate the two as much as practical, and the problem vanishes. There is no fundamental reason why deleting a page (which doesn't annihilate the data; it just sets a database flag) and passing judgment on users need to be linked. It's simply path dependence. UseModWiki had "superuser" functions protected by password (simply copying standard Unix permissions), and then when MediaWiki was cooked up to replace it, it copied this "ordinary user and superuser" construct, and then this ossified because of standard human cognitive biases (status quo bias, change aversion). This has already been implicitly recognized by separating out some functions like checkuser and template editor, but only because the status quo became untenable enough to get people to acquiesce to the changes. --47.146.63.87 (talk) 06:00, 27 January 2020 (UTC)
  • Strongly support concept but understand that it's "not do-able as proposed" since we don't log all admin-required activity. How about a counter-proposal: Administrators who do not use the tool for 2 years and every year thereafter they would be notified and asked if they wanted to keep the bit. They would also be notified that if they did not say "yes" or did not use the tool in a way that is logged, they would automatically be desysopped after 5 years of their last logged action or the last time they said "yes, I want to keep it," whichever is later. They would get additional warnings every month for at least 6 months prior to being desysopped. No admin would be desysopped under the proposal for 5 years after the approval of this proposal, but they could still be desysopped for overall inactivity under current rules. Oh, personally, I think the term should be 2 years, not 5, with the first notice given after 1 year of "appearent non-use," but 5 years is much better than forever. davidwr/(talk)/(contribs) 20:57, 27 January 2020 (UTC)
  • Oppose unless/until we can detect and incorporate non-logged administrative actions including viewing deleted files, closing AfDs, etc. There are many different ways of using the administrative tools and we shouldn't force out the ones who are doing useful administrative editing in non-logged ways. —David Eppstein (talk) 21:00, 27 January 2020 (UTC)
  • Comment I'm not entirely against stripping admin rights away but it would be nice to check in with those users that have been inactive for a long period(s) of time. Maybe require some form of two-factor authentication for admins? (That would toss the security concerns to the wayside, IMO.) Five years of inactivity is pretty long but I'm against discouraging potential returnees from working on Wikipedia again. Back Home (talk) 14:25, 29 January 2020 (UTC)
  • Oppose. Not everything an admin has access to is logged, so it's impossible to fully know whether or not the admin tools have been used. -- Tavix (talk) 14:33, 29 January 2020 (UTC)
  • Comment: if there are concerns over the counterproductive removal of administrator tools from editors who use them for non-logged tasks, such as editing through protection or viewing deleted content, why not simply allow these editors to provide evidence of this to avoid losing the kit? For example, when notified that admin permissions are due to be revoked, an editor who works in Main Page-related content could provide a recent diff of an update to a protected template, or one who reviews deleted articles could name one they checked recently, and the timer would reset. – Teratix ₵ 09:55, 1 February 2020 (UTC)
  • Strongest Support Admins have to go through the RFA process. This means that they actively chose to request the tools. They were granted them. Five years is a really long time. That's 1/4 of the entire time that Wikipedia has existed. Jerod Lycett (talk) 21:43, 1 February 2020 (UTC)
  • Support because this is true: "administrators who rarely if ever use their administrative powers are usually not involved in admin-related work, and are often quite out of touch with accepted standards". This on the other hand, "Many uses of the admin toolset are not logged, so there is no way to verify that an admin is not using it or not" is basically irrelevant; it is not feasible that someone is actively working as an admin yet never once in five years peforming a single admin-logged action. This isn't about percentages, so heavy use of non-logged tools doesn't matter. And if it came down to it – if it turned out that enacting this would cost us a couple of actual active admins – just change the logging to have fewer gaps. This is a website, not an archaeological site, and we can bend it to our needs on-the-fly.  — SMcCandlish ☏ ¢ 😼  22:25, 2 February 2020 (UTC)
  • Oppose: Still have concerns per those listed (See change of !vote below and comments): Per Jo-Jo Eumerus (no way to count unlogged admin actions), Hawkeye7 (no harm is done and no cap on the number), DrewieStewie (too many issues with this), Jayron32 (flawed), ScottDavis (there are ways to remove inactive editors, and rogue admins), Bilorv (a solution in search of a problem. ...there are too few admins, not too many), Spencer (focus' on T:ITN), Llywrch (unicorn that helps), Martinp (it is a position of trust not obligation), and finally per Gnangarra (assume good faith in the admins, if they are doing no harm then why take the mop away). Comments: I will add that while I feel some of the "Supports" have good faith reasoning (especially SMcCandlish I feel it is somewhat misplaced. Is there not procedures in place to recall admins? If so then why seek to "automatically" remove them? That is my issue! I have been here just a little while (compared to some) but mostly have trust in Admins and have voted for them on that premise not on how active they may be. If there is an issue with one or more then lets discuss it at the proper venue on a case-by-case basis. Shouldn't that really be how it is done? Otr500 (talk) 14:05, 8 February 2020 (UTC)
More comments: This will not be just a cut-and-dried !vote as issues of the maximum timeline have evolved that will likely involve yet another RFC. I am a non-admin so have a very neutral opinions. If any editor(s) wishes to curtail the inactive admins (62 seems like a lot) ping me at the proper place. We can discuss it, ping the admin, see what is going on (or get no response), and make a community based decision if there are net positive reasons for removing the tools.
For some likely strange reason that seems a better solution. If they were "automatically" given the rights then maybe let's discuss "automatically" removing them. Otr500 (talk) 14:19, 8 February 2020 (UTC)
Otr500, what "procedures in place to recall admins" are you talking about? We fairly notoriously don't have procedures in place to recall admins, which is the primary reason this proposal exists in the first place; at the moment the only three ways admin status can be removed are (1) following a full-scale arbitration case, (2) by the WMF as an office action (something unlikely ever to happen again given the backlash on the one occasion they tried it), or (3) as a temporary emergency measure under Level I/II in the case of an obviously compromised account or an account which is causing disruption and has not provided an explanation of their actions. ‑ Iridescent 14:27, 8 February 2020 (UTC)
Yeah, there are no recall procedures. Some admins voluntarily agree to abide by some, when they were doing their RfAs, but the community never developed any, and, well, people can change their minds, so it wouldn't be binding anyway, even if we did. And most admins did not tacitly agree to such things, anyway. As for ArbCom, our official "active desysopping" channel, they only do it in cases of egregious actual abuse, not risk. The proposal here is consistent with other means the community has enabled for auto-desyopping inactive admins under various (time-lengthy) conditions. It's not a punishment, it's a basic security measure. Any admin simply inactive as one (or entirely) for 5 years due to real life would be welcomed back without any big deal.  — SMcCandlish ☏ ¢ 😼  00:53, 9 February 2020 (UTC)
  • Support An admin who does not perform logged admin tasks, in most cases will not need the admin-rights. A shorter term is - in my opinion - advisable but as a courtesy an admin should be warned after six months. The Banner talk 14:29, 8 February 2020 (UTC)
  • Support; I find the opposes completely unconvincing. The only reason anyone has admin status is to use it for the benefit of the project; some hypothetical admin who's managed to go a whole five years without a single logged action and is too lazy to spend the five minutes it would take to wander over to CAT:CSD and accept/decline a single deletion request, but nonetheless wants to cling on to the toolset solely so they can snoop through deleted revisions isn't just not a positive to Wikipedia, they're a security risk and an active net negative. As far as I'm concerned five years is still ridiculously lax and we should be thinking more in terms of six months, but if we're going to start we have to start somewhere. ‑ Iridescent 14:33, 8 February 2020 (UTC)
    I agree entirely but didn't want to be the one to put it into such sharp relief. >;-)  — SMcCandlish ☏ ¢ 😼  00:44, 9 February 2020 (UTC)
  • Support - five years is a very long time to go without a single logged admin action, for all practical purposes such admins are not using their advanced permissions for the benefit of the community. Realistically they are also out of date with current usage practices. In fact I would say that 2-3 years would be probably more reasonable limit.--Staberinde (talk) 11:37, 9 February 2020 (UTC)
  • Very Weak Support I do support this kind of policy to be in place. However, a 5 year time seems like a lot to me. I would say about 2-3 years, as Staberinde said above. I also do support a system that another user said above that some admins will make a few edits at the same time each year to keep the system the same. I would support a system to prevent admins from doing that, as I would call that Gaming the system, as a user stated above. If the time does change, I may do a stronger support. However, considering the usefulness of a policy like this in place, I will opt to do a very weak support, and not go with an oppose or a neutral. --TFFfan (talk) 01:03, 10 February 2020 (UTC)
  • Support (change of !vote): Per User:SMcCandlish (Any admin simply inactive as one (or entirely) for 5 years due to real life would be welcomed back without any big deal.), and User:Iridescent ("cling on to the toolset" and "if we're going to start we have to start somewhere"), and agree "five years is still ridiculously lax". Otr500 (talk)
Comments and concerns: Can someone provide clarification: What is the end result of Slight tweak to lengthy inactivity policy and the closing of "admins who have not used the admin tools for a prolonged period (5 years is mentioned) will usually be required to reapply via Wikipedia:Requests for adminship."? If that still stands would this proposal clarify the "tweek" or just add mud to the water with the addition of "(maybe 5 years)"?
Concerns: I saw above mention of AFD and not being admin logged actions. If this is true and an AFD closure requires Admin action (use of tools say per deletions) why is that not recorded as a logged Admin action? Why are other "uses of the tools" not counted as logged actions? It would seem that any "use of the tools" (actions a regular editor cannot make) would be counted. How hard would it be to "log" Admin edits to the main page?
My misunderstanding was the removal of tools for inactivity. "Inactivity" is only if an Admin has "no edits (deleted or otherwise) or log actions for one year". I do not think Adminship should be a lifelong "appointment" or a trophy "if" the tools are not used for the benefit of the community. We give the tools to those we trust ---but--- that is surely with expectations that they will be used. I still have concerns over non-logged Admin actions and wonder how many on the list that would actually include. Concerns of an Admin gaming the system (logging an action "just to retain the tools") should be a concern and reasons to consider a solution. I saw that none of the names in the list were linked to and since those on the list may assuredly be affected by this is there a reason they wouldn't be notified (pinged) of this discussion? Otr500 (talk) 14:18, 10 February 2020 (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.

Proposal: “are you sure” page when clicking on “log out” before logging out

Should we establish an "are you sure?" page before logging out? It is frustrating how many countless times on my iPhone 6S (where I use desktop Wikipedia since I don't like the mobile interface) I accidentally press "log out" and have to log in again when I try to click on "contributions". Will this proposal go far? I dont know. But I thought it was worthy to propose at the Village Pump in good faith considering how often this has happened to me and how much of a nuisiance this has become for me. You might find this silly, you may trout me or put me in the village stocks if you think that. Cheers! :) DrewieStewie (talk) 04:39, 1 February 2020 (UTC)

You aren't the first person with this issue, and certainly not the last. You can install User:Fred Gandt's confirmLogout[1] (source) script and it will prompt you before letting you log out. At this point, it should really be a gadget. --AntiCompositeNumber (talk) 04:49, 1 February 2020 (UTC)

References

  1. ^ Copy the following code, edit your user JavaScript, then paste:
    {{subst:lusc|1=User:Fred Gandt/confirmLogout.js}}
Thanks for that. Works a treat. Reyk YO! 04:56, 1 February 2020 (UTC)
  • Interesting. I've been using User:Writ Keeper/Scripts/logoutConfirm.js, but it didn't seem to work reliably. I'd get the dialog asking for confirmation, but I'd get logged out regardless of how I answered. Somewhere along the line, somebody suggested adding:
#pt-logout { display: none; }

to my common.css. That has the effect of hiding the logout link completely, so it's not even clickable. That's what solved the problem for me. See also T217914. -- RoySmith (talk) 05:32, 1 February 2020 (UTC)

  • I think that DrewieStewie has come up with a good idea. I too edit using using the desktop site and a smartphone, and occasionally log out accidentally. The question is whether the problem should be dealt with in the basic editing interface, or with a user-installed add on tool. Cullen328 Let's discuss it 07:14, 1 February 2020 on that dev(UTC)
  • I would also support this proposal. It is frustrating to log out with a fat-fingered press on one device, only to find that, on another device that I was logged in to, I now have to log back in again. As a new admin, I felt it sensible to enhance the complexity of my password, so this has now become even more of an annoyance. Nick Moyes (talk) 23:38, 1 February 2020 (UTC)
What I've done is to create a 2nd account for myself, User:RoySmith-Mobile, that I use on my phone. I suggest that all admins do this. It's too easy to lose or misplace a phone, or have it stolen. And then there's a device out there with you logged into an admin account. Not using your admin account on a mobile device reduces your exposure. It also reduces your exposure to accidentally committing carnage. If a mis-tap can log you out, it can also delete a page or block a user. -- RoySmith (talk) 02:19, 2 February 2020 (UTC)
  • RoySmith, does Wikimedia lack a "revoke device login" page? It should create one like any other SSO service. The concept is simple. You go to a page to review devices which are or have recently logged into your account, according to user agent, operating system, IP address, etc. Don't recognize one or don't like the looks of it? Revoke its login permissions immediately and it is logged out remotely. Elizium23 (talk) 23:32, 8 February 2020 (UTC)
@Elizium23: There's Special:Logout, but that's all or nothing. I'm not aware of anything as fine-grained as you describe. I agree that it would be a good thing to have. -- RoySmith (talk) 00:01, 9 February 2020 (UTC)
See my comment above about User:Writ Keeper/Scripts/logoutConfirm.js; sounds like the same issue. -- RoySmith (talk) 02:19, 2 February 2020 (UTC)
  • Support. Recently moved to a new phone and I keep hitting the logout link accidentally. This is needed. oknazevad (talk) 02:08, 2 February 2020 (UTC)
  • Support as a enabled-by-default gadget. However, I feel that there is an underlying problem of being able to accidentally press any button when on mobile. >>BEANS X2t 13:38, 3 February 2020 (UTC)
  • This sounds like an interface design flaw. Fix the design rather than inflict an 'are you sure' on all users regardless of device. —Trappist the monk (talk) 14:20, 3 February 2020 (UTC)
  • Strong oppose per Trappist the monk above, I am heartily sick of all these distracting and timewasting "extras". If some people prefer a workaround for natural fumbling then that should be made a configurable user option. — Cheers, Steelpillow (Talk) 16:19, 3 February 2020 (UTC)
  • Support for basically the same reasons as DrewieStewie. Would it be possible to make this a setting? That was editors could choose one-click (default/current) or confirmation request option? Springee (talk) 20:10, 3 February 2020 (UTC)
  • Support: I don't have many issues with this myself, but I support. It wouldn't be such a big deal, except that, unlike on other sites, when you log out of Wikipedia, it logs you out of all devices. Whether this is intended or not, I'm not sure. Amaury • 22:06, 3 February 2020 (UTC)
@Amaury: It's intentional. See T37220. -- RoySmith (talk) 04:33, 6 February 2020 (UTC)
@RoySmith: It's not a huge inconvenience for me, personally, in any case. I've gotten around this by clearing my history—cache, cookies, etc.—to "log out" from Wikipedia—or any site, really, but Wikipedia is the only one that acts like this—when using public computers instead of clicking the log out link. Amaury • 15:24, 6 February 2020 (UTC)
Amaury, Just to be clear, I agree with you. I think it's a mis-feature. I was just pointing out that it's an intentional mis-feature :-) -- RoySmith (talk) 16:32, 6 February 2020 (UTC)
  • Oppose trying to slip in some enwiki-only javascript hack for this that would be on by default. Suggest someone file a software feature request after reviewing similar work in phab:T217914. Neutral for a local opt-in-only gadget to "Add confirmation prompt to logout"- provided that (a)It is well documented including what use cases are and are not supported, and (b)Some maintainers want to maintain this new gadget. — xaosflux Talk 15:50, 6 February 2020 (UTC)
  • Support in theory. It's a real problem and this would help, assuming it isn't too much of a technical burden.

    What if there was just more whitespace between Contributions and Log out? That would accomplish much the same thing, making it harder to accidentally click it, without as many moving parts. --Dennis Bratland (talk) 17:48, 6 February 2020 (UTC)

    @Dennis Bratland: anyone can propose a software change such as Move the "log out" option to an actions menu under the username in vector, place the username and this menu at the far right similar to how it is in timeless. (Example of how it is in timeless can be seen here— xaosflux Talk 18:31, 6 February 2020 (UTC)
    If going that far, preferences would probably be good to nest in there too, as it is not highly used and is directly related to the user. — xaosflux Talk 18:33, 6 February 2020 (UTC)
    Yes, heard you the first time. --Dennis Bratland (talk) 19:06, 6 February 2020 (UTC)
  • Oppose you also used to get a page confirming logging in but that also doesn't appear necessary (unless its the person's first time) this would just needlessly complicate things and potentially cause security issues (if someone pressed log out and left their computer not realizing they weren't logged out). It should instead be an opt in in the user preferences or just a script people can use. Crouch, Swale (talk) 14:15, 8 February 2020 (UTC)
  • Only as opt-in - I am generally fine with the suggestion itself, but as I have no interest in using it I would strongly oppose having one forced upon editors.--Staberinde (talk) 11:48, 9 February 2020 (UTC)
  • Support: I am a somewhat active editor (subjective) across a broad range of subjects but I lack the "skills" some enjoy. When I log in on my phone I use the desktop version. I have also inadvertently logged out several times. Lacking programming skills I rarely use "scripts" and the css part is daunting. With this in mind (I am sure many are rowing the same boat) I would think something along the lines of an "opt in", in the user preferences (configurable user option?), might be a less contentious solution. Otr500 (talk) 15:06, 11 February 2020 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_165&oldid=1092751179"