Wikipedia:Village pump (proposals)/Archive 139

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search

Citations Archive

Wikipedia doesn't do entropy as well as we could. If you look at an article created several years ago there is a good chance that most of the sources are now redlinks or worse may have completely different content.

Should we develop a citations archive such as detailed at WP:Citation Archive? It is now technically feasible, and I suspect the Wikimedia Foundation could afford it.


  • Support as proposer ϢereSpielChequers 10:03, 15 April 2017 (UTC)Reply[reply]
  • Something like WP:WEBCITE? —  crh 23  (Talk) 18:13, 15 April 2017 (UTC)Reply[reply]
    • Yes a little like it, but while WEBCITE is optional and manual this would be automated and used on everything that isn't paywalled. ϢereSpielChequers 19:57, 15 April 2017 (UTC)Reply[reply]
  • Might the better solution be to have a system where some kind of automated process follows every added link and within a few minutes of it being added, goes to the wayback machine and requests a capture, then adds that archived URL on Wikipedia? Not convinced we need to duplicate the actual archival process. Sam Walton (talk) 22:52, 15 April 2017 (UTC)Reply[reply]
  • Either way, we don't want to overwhelm whatever bot would do this (because a bot would probably be the one adding those links) or Wikipedia's servers (which may be overwhelmed with eiher archiving basically the entire web or edits from the bot, both because we have hundreds or thousands of edits with links being added every minute). I remember that a few months ago, we had a bunch of people over at WP:THQ complaining they couldn't see their page edits right away. I found out it was related to a bug being tracked on Phabricator which eventually made its way to "Unbreak Now" status. I envision something similar happening if this isn't implemented correctly. Gestrid (talk) 04:58, 16 April 2017 (UTC)Reply[reply]
  • We average a hundred edits a minute on the English Language Wikipedia. I don't know what proportion of these include a cite, but I'm pretty sure it is much less than half. Especially as the code will have to understand the concept of a revert and not update the citations archive when someone reverts to "the last cited version". So I don't think this should add such a burden as to slow things down, most of the time it will be simply reading edits that have taken place and the pedia and other sites. Adding links should be much later when the cited sight has gone dark. Yes it will be by bot, but the bot can be throttled and could even run at quiet hours. ϢereSpielChequers 12:09, 16 April 2017 (UTC)Reply[reply]
  • Support an automated process. It does not have to be immediate, and need not affect the save. It would be OK not to archive if the item is already archived, but that might require more work to check if currently archived version is the same as the referenced version than to just do it again. Dead link fixing is tedious, and not always possible, when people use bare urls for references. • • • Peter (Southwood) (talk): 09:57, 16 April 2017 (UTC)Reply[reply]
  • Unnecessary—the Internet Archive has already automated the archival of links in use on Wikipedia, and there is a bot that already (InternetArchiveBot) that works to add these links to articles. In short, the automated process you seek already exists. Imzadi 1979  10:09, 17 April 2017 (UTC)Reply[reply]
    This. If you need the bot on some pages, users can use the linked in the revision history of any page, or can summon the bot on a collection of pages using this tool.—CYBERPOWER (Chat) 11:11, 17 April 2017 (UTC)Reply[reply]

Save MYO Wikilove

It's simple. Sometimes I make Wikilove that I want to save and be able to use again. I don't want to have to make the same ones over again. Thanks!

@Creeperparty568: Just create it in a subpage of your userspace and transclude it wherever you want to reuse it, like any other template (except you need the full name of the page like this: {{User:RexxS/Shakespearean insults}}. --RexxS (talk) 12:58, 17 April 2017 (UTC)Reply[reply]
@RexxS: I know, but I just want to be able to access it from the wikilove menu to make it easier and more convenient. — Preceding unsigned comment added by Creeperparty568 (talkcontribs)
@Creeperparty568: The feature already exists. See mw:WikiLove#How to customize. PrimeHunter (talk) 22:34, 17 April 2017 (UTC)Reply[reply]

Abolish sidebar navigation templates

We now have hundreds of sidebar navigation templates that are identical (or nearly identical) to corresponding footer navigation templates. For example {{Conservatism US}} and {{Conservatism US footer}}. It is common practice to include both in any articles related to the subject. See, for example, Paleoconservatism. I don't see any point in including the same content twice in the same article. However, it is virtually impossible to keep people from adding these templates to the articles, even when one of the two templates is already present. The only practical solution, IMO, is to abolish the practice of having sidebar navigation templates. I'm not sure what purpose these templates were designed to address that isn't already handled by footer navigation templates. For anyone opposing this proposal, please explain why we need both. Kaldari (talk) 02:01, 6 April 2017 (UTC)Reply[reply]

  • They're helpful in several ways. They're more likely to be seen than the templates at the bottom of articles. They often include images, so they contribute to the article not being a wall of text. And they help to shorten the long lines of text we have because we have no fixed width. If they're being added a lot, it means people like them. SarahSV (talk) 05:57, 6 April 2017 (UTC)Reply[reply]
  • I'm very conflicted about these sidebar navigations. There indeed is a lot of duplication here, but there has always been a space for both of these. I think the problem is that if a series box becomes a 'let's link to everything' navbox with multiple levels of 'by default' collapsing (which ppl really need to start learning means 'only-collapsed-on-desktop'), then it's no longer working as it was intended. —TheDJ (talkcontribs) 10:43, 7 April 2017 (UTC)Reply[reply]
  • The sidebar navigation should only have a few simple links without options to expand more links. Save that for the footer. Graeme Bartlett (talk) 01:53, 10 April 2017 (UTC)Reply[reply]
  • I oppose any abolishment of these things. Or any rule that prohibits their use. Definitely WP:CREEP if you ask me and some of these work fine. I use the {{forensic science}} sidebar on almost every single article I care about. There is no bottom navbar for that topic. And I also agree with SarahSV. They break up the walls of text that are in the top of articles that don't have infoboxes. --Majora (talk) 02:00, 10 April 2017 (UTC)Reply[reply]
  • Whether we need both or not, I see no harm in having them and therefore oppose a blanket abolishment of them. I would suggest that attempting to craft a more nuanced policy on nav templates may be more helpful than just trying to delete an entire category of them. Beeblebrox (talk) 02:58, 10 April 2017 (UTC)Reply[reply]
  • We should stick with navbars and scale back on sidebars IMO. Doc James (talk · contribs · email) 09:25, 10 April 2017 (UTC)Reply[reply]
  • Would there be any benefit in combining the templates for navboxes and navbars so that there is only one for any given subject, but it can be selected to display as either. This would allow user choice of output format, or could be linked to skin, etc. • • • Peter (Southwood) (talk): 09:35, 10 April 2017 (UTC)Reply[reply]
  • The more links a sidebar navigation template has, the less valuable it becomes. They should be used for tightly focused topic areas. Praemonitus (talk) 20:17, 13 April 2017 (UTC)Reply[reply]
  • Since many complain about sidebars becoming bloated with too many links, we should think about devising and enforcing guidelines on the appropriate level of comprehensiveness of sidebars. – Finnusertop (talkcontribs) 20:25, 13 April 2017 (UTC)Reply[reply]
  • Oppose – 1) options are a good thing, 2) enables navigation from the top of articles. North America1000 21:31, 16 April 2017 (UTC)Reply[reply]
  • Oppose - side bar templates are more noticeable than footer templates. Although, both are useful because if one scrolls all the way to the bottom, he/she would not need to come up to navigate. Same for those who just read the lead..Yashovardhan (talk) 11:41, 19 April 2017 (UTC)Reply[reply]
  • Oppose Sidebar templates are much handier and easier to use. Dlohcierekim 18:00, 20 April 2017 (UTC)Reply[reply]

Archiving weblinks

I would like to propose the development of a bot or program for all projects and languages that turns outdated weblinks into archived version links like in Wayback Machine. Would that be feasible and has there been an identical proposal here or at Phabricator yet?--Hubon (talk) 21:02, 18 April 2017 (UTC)Reply[reply]

@Hubon: I don't think the WMF would do this for all projects and languages, given that there are more than 700 WMF sites (translation requirements and different templates; some projects just might be too small or not important enough and a bot might be unnecessary). InternetArchiveBot is currently running on the English and Swedish Wikipedias, and Wikiwix archive links seem to be automatically added on the French Wikipedia. I'm not sure about other projects though, but IABot is apparently "in ongoing development, to support additional wikis". Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
11:55, 21 April 2017 (UTC)Reply[reply]
InternetArchiveBot is a project that is now in the process of being deployed to other wikis. If you have a Wikipedia in, start a discussion there and link to that discussion by creating a new ticket with this tool.—CYBERPOWER (Chat) 12:01, 21 April 2017 (UTC)Reply[reply]
@Jc86035: Thanks for the information! @Cyberpower678: I'm sorry, but I'm afraid I didn't quite get your message. Apart from English Wikipedia, I mainly edit in the German project. And, in fact, I already asked there about this issue but didn't really receive a proper reaction... What now?--Hubon (talk) 19:20, 23 April 2017 (UTC)Reply[reply]
@Hubon: This may interest you. I opened a discussion there, but go no response so far. Try to attract some editors to that thread. I have dewiki on my radar to deploy IABot.—CYBERPOWER (Around) 19:56, 23 April 2017 (UTC)Reply[reply]
@Cyberpower678: Thanks for your help! I did as you asked me for. Now let's hope and see... Best--Hubon (talk) 00:34, 25 April 2017 (UTC)Reply[reply]
@Hubon: Thanks. Can you point it to the proposal that can be found at de:Wikipedia:Projektdiskussion/Ein_Bot_zu_bekämpfen_von_WP:Defekte_Weblinks_(Bereitstellen_von_InternetArchiveBot_zu_dewiki)?CYBERPOWER (Message) 01:23, 25 April 2017 (UTC)Reply[reply]
Derp, never mind. I didn't see the link. :p—CYBERPOWER (Message) 01:24, 25 April 2017 (UTC)Reply[reply]

Experiment to see if training modules are helpful for new users

I'd like to run a controlled experiment with pointing new users toward these training modules, to see if providing such training modules makes newcomers more likely to stick around and become effective editors. We've done such things occasionally before — inviting 10,000 users to try The Wikipedia Adventure, for example — to mixed results, and we haven't yet found anything that actually makes a demonstrably positive difference, in terms of automated welcomes. However, I think there are a few differences that make it worth trying again with these training modules. First, the user experience is much more streamlined than any on-wiki intros / tutorials we've tested before. New users are typically overwhelmed with the abundance of links and places to go when they get started on Wikipedia. Second, compared to The Wikipedia Adventure, these training modules are much more practical, aimed at efficiently teaching the basics of how Wikipedia works and how to edit it. They've also been through a lot of iterations based on user tests and feedback from Wiki Ed classroom program student editors, to make sure they are clear and address the most common problems that new editors run into.

You can see a little more detail about what I'm proposing here: Wikipedia:Bots/Requests for approval/RagesossBot 3.--ragesoss (talk) 17:52, 18 April 2017 (UTC)Reply[reply]

  • I support this proposal. I ran the experiments for Teahouse and Wikipedia Adventure invites, and I think it is a great low-impact/high-value method for testing out new approaches to onboarding newcomers. J-Mo 17:58, 18 April 2017 (UTC)Reply[reply]
  • I'm all for initiatives like this but when I click through to an introductory module and see it's going to take me nearly half an hour to complete, I nope right out of there. I'm skeptical that someone who registers an account (presumably with some particular edits in mind that they want to make soon after account creation) would generally be up for completing hours of training modules. That said, I'm not opposed to a trial that might prove me wrong! Sam Walton (talk) 18:00, 18 April 2017 (UTC)Reply[reply]
  • Yeah, I'm quite certain that most users will not go through them. But part of the design is to offer the whole set, each with a specific topic, so that if a user is actively interested in (say) learning about how to make edits, or learn about the rules, they'll have an accessible way to dive in.--ragesoss (talk) 18:05, 18 April 2017 (UTC)Reply[reply]
  • Please gods yes. The pain point of new users getting smashed on their first article creation experience is something that needs our greatest efforts. --joe deckertalk 18:06, 18 April 2017 (UTC)Reply[reply]
  • @Ragesoss: I think this is a great idea! New user retention is a huge challenge for us, but we've done comparatively little testing of strategies to address it (J-Mo and Aaron Halfaker's work being a big exception, of course). Unfortunately, I don't have much time to offer help, since I'm in the middle of preparing for a different research project about new editor success :) My one observation is that you may want to focus specifically on testing the hypothesis that it's not just offering help information, but offering a limited, manageable set of help information that makes the difference. That would be an even more useful result. So perhaps you could use a standard welcome template, instead of or alongside nothing, as a control.—Neil P. Quinn-WMF (talk) 20:23, 18 April 2017 (UTC)Reply[reply]
  • The default situation for new users is no template at all, so I think we should at least have a control group where we do no intervention at all. I'm not opposed to a third group that gets a more standard template, but I was thinking to just start as simply as possible.--ragesoss (talk) 20:39, 18 April 2017 (UTC)Reply[reply]
  • I'm not going to oppose a trial - we don't know if this will work until it has been tried. However, this is not support of the whole deployment, that has to come after reviewing evidence of the trial. I am not too keen on automated welcoming, they seem a bit artificial, and fake. A personal note with some helpful links or even templates I feel are much more useful, as they are more encouraging to the new user. I hope that I am wrong in this - let's give a trial and see. However, this idea of training is a great one and should be incorporated into existing welcome templates. TheMagikCow (T) (C) 19:44, 21 April 2017 (UTC)Reply[reply]
  • As Sam Walton has pointed out this is a bit longwinded for new editors. Also it still has the unwelcoming here are the rules start that most welcome messages have. I've been developing a more low key, template based training welcome. Use {{subst:Welcome training}} ~~~~ to try it on a newbie. It came out of the GLAM program rather than education, but I don't think there is anything obviously GLAM in the current version. It can also be tailored for editathons by creating a version that links to your event page, and it feels more Wiki Like... ϢereSpielChequers 21:40, 25 April 2017 (UTC)Reply[reply]
  • W00t, looks nice. A test seems interesting. I do wonder however how you would measure results. I suspect that actual results of something like this, lie much further down the line, then the immediacy with which people make their first edits. —TheDJ (talkcontribs) 07:45, 26 April 2017 (UTC)Reply[reply]
    • @Ragesoss: BTW, the end of course drops you into the Program selector for wiki courses. Might want to give people a link with a ?disableprograms param or something to disable that full on wiki edu experience for this test. At least, as far as I understand you want to distribute to people outside of wiki edu. —TheDJ (talkcontribs) 08:38, 26 April 2017 (UTC)Reply[reply]

Interwiki links

Hello, I would like to propose the development of an advanced function for interwiki links (if possible, for all Wikimedia projects): When we want to insert a wiki link, we already have a function that is able to convert a URL into a wiki link. However, this does not seem to work for URLs from other language versions and Wikimedia projects. So wouldn't an appropriate improvement make sense?--Hubon (talk) 00:45, 25 April 2017 (UTC)Reply[reply]

Let's start with... "Which editor" ? :) —TheDJ (talkcontribs) 07:42, 26 April 2017 (UTC)Reply[reply]
@TheDJ: Thanks for asking! Ideally both, I guess; but otherwise rather the source editor. What do you think?--Hubon (talk) 20:50, 26 April 2017 (UTC)Reply[reply]

How would it be, if the feature "page preview" made available for not-logged-in users?

The Page Preview option (still a beta feature) is a very useful and simple feature. It helps to check what's in a link, without loading the link. This helps the user to read/work, think and find stuffs faster, without losing focus. But it could be used only in logged-in condition/ by logged-in users.

How would it be; if this feature is made available for peoples who are not logged in? RIT RAJARSHI (talk) 15:41, 25 April 2017 (UTC)Reply[reply]

@RIT RAJARSHI: See this page. With this said, I don't think it should be in beta any more. It's fine as is and should be released and enabled by default. Anarchyte (work | talk) 13:00, 27 April 2017 (UTC)Reply[reply]

Proposal that pages created through Wikipedia:Articles for deletion be Autopatrolled regardless who creates them

I am proposing that any new pages created which start with "Wikipedia:Articles for deletion/" be automatically patrolled regardless if its creator has the "Autopatrolled" user right or not. This proposal is rather to the point, but the reasons why and the benefits, not so much. I discovered an issue while attempting to patrol new pages in the "Wikipedia:" namespace, and at the present time, my ability to find pages in that namespace with issues are difficult and time-consuming to find due to most new pages created in the "Wikipedia:" namespace (probably literally 19 of 20 of non-redirect pages created) starting with "Wikipedia:Articles for deletion/". The main benefit of this is the fact that Special:NewPages will not be blogged down by all of these pages and make it quicker to locate problematic pages in that namespace (such as essays, new policies not discussed, shortcuts to other pages, etc.), and the downside is of course that they will no longer be in Special:NewPages. However, in regards to "downside" ... from my understanding, most, if not all, pages created which start with "Wikipedia:Articles for deletion/" are detected by a bot which will fix listing issues with the page if it is not listed properly per the instructions at WP:AFD, meaning regardless if it is technically patrolled, editors will see it anyways there and be able to determine if the page is eligible for any of the "G" categories of the speedy deletion criteria.

However, with that being said, this should probably not apply to new redirects created which start with "Wikipedia:Articles for deletion/" since these are not nomination pages, and thus are not detected by a bot for listing on WP:AFD. Steel1943 (talk) 18:31, 25 April 2017 (UTC)Reply[reply]

  • Oppose, besides being technically complicated, non-article pages of any kind are easily filtered out of NewPages. — xaosflux Talk 19:09, 25 April 2017 (UTC)Reply[reply]
    Yes they can be filtered out, but when looking up solely pages in the "Wikipedia:" namespace, that is where the flood of "Wikipedia:Articles for deletion/" pages appear, and thus why I'm proposing this. That, and if this can technically be done (which I'm sure it can be), I'm not understanding why that's a reason to oppose since technical implementation isn't related to human error or vandals abusing the system. Steel1943 (talk) 19:30, 25 April 2017 (UTC)Reply[reply]
    The technical implementation of "autopatrol" addition to the creation themselves is difficult. What might be considered instead is an "AutopatrollerBot" that takes a regex list of pages (or similar) that it can patrol. That said, that does remove it from a review queue--and I can imagine that AFD subpages are sometimes created in a vandalism sense. Are you comfortable letting those escape (even though they are not indexed)? --Izno (talk) 20:07, 25 April 2017 (UTC)Reply[reply]
    Alternatively, perhaps this indicates that the patroller interface needs improvement (oh, how we've heard that!) such that multiple entries, if they are not now, can be patrolled at the same time. Or even more alternatively, give autopatrolled to more people (than) the frankly-ridiculous 25-article-creation requirement allows. --Izno (talk) 20:09, 25 April 2017 (UTC)Reply[reply]
    @Izno: If this proposal doesn't pass, I support this an alternative, such as if there is a way to exclude pages with a certain prefix from results when skimming through lists of unpatrolled pages and since this option would fix more than the specific issue I brought up here. Steel1943 (talk) 21:07, 25 April 2017 (UTC)Reply[reply]
    Which alternative was that? :D I proposed three. --Izno (talk) 03:15, 26 April 2017 (UTC)Reply[reply]
    I'm not sure what you mean. I think I meant to say "an" instead of "this". Steel1943 (talk) 08:39, 26 April 2017 (UTC)Reply[reply]
    @Izno: The "Are you comfortable letting those escape" concern I believe would be absolved by the fact that a bot lists most new pages on WP:AFD if they are not transcluded properly. (If a bot didn't do that at all, my answer to your question would be a huge "no" since then, there would no longer be a first line of defense to detect these pages.) Steel1943 (talk) 21:04, 25 April 2017 (UTC)Reply[reply]
    Perhaps the transcluding bot could be modified to patrol the AFD which it is transcluding. Might feel bad to put it in that bot, but better that one (and when/if that bot dies, we know to include that as a required task, rather than have it scattered to a PatrollerBot). --Izno (talk) 03:15, 26 April 2017 (UTC)Reply[reply]
    I support such a bot - and it should also patrol any properly transcluded non-patroled AFD page. This would serve as an indication for patrolers that the specific AFD has been handled to the point that if there are any issues (including clearly bad-faith nominatios), it will be handled - the truwe purpose of this feature (just like we generally mark CSD-tagged pages as patroled). עוד מישהו Od Mishehu 03:13, 27 April 2017 (UTC)Reply[reply]
  • Support a non-mainspace patrol bot in general, for various purposes to be decided by consensus. This would include properly transcluded AFD's, MFD's, and SPI's, but could also conceivably work on things like user talk pages created by Huggle and talk pages consisting solely of WikiProject banners. – Train2104 (t • c) 23:57, 27 April 2017 (UTC)Reply[reply]


I think NPROF should redirect to WP:PROF, and a new redirect created for non-profits. Perhaps WP:NONPROF or WP:NPROFIT? We already have WP:NONPROFIT, so it is possible to free up NPROF. Many more times I will be looking for NSCHOLAR than NONPROFIT, and it took me a few extra minutes to guess at NADADEMIC which got me to the correct policy page. I created NSCHOLAR because I saw that many other editors had referenced SCHOLAR as that, and N is used ot denote the Notability guideline as opposed to some other guideline, or a sub-section of BLP. Any thoughts? L3X1 (distant write) 00:36, 22 April 2017 (UTC)Reply[reply]

No one objected, so I have been bold:

NPROF now redirects to PROF which is Wikipedia:Notability (academics)
NPROFIT and NONPROf now go where NPROF used to go, Wikipedia:Subjective importance

L3X1 (distant write) 19:24, 24 April 2017 (UTC)Reply[reply]

I wonder whether people will expect them to go to the same page as WP:ORG and WP:NGO instead. WhatamIdoing (talk) 06:04, 25 April 2017 (UTC)Reply[reply]
  • The number of shortcuts is ridiculous. There are jargon. They are a barrier to newcomers. And when people start talking in shortcuts, it dumbs down the conversation. --SmokeyJoe (talk) 06:57, 25 April 2017 (UTC)Reply[reply]
I disagree with your last statement. L3X1 (distant write) 00:28, 28 April 2017 (UTC)Reply[reply]

Net neutrality

Wikipedia should do something to try to stop Ajit Pai and the FCC's attempt at eliminating net neutrality in the US, which could lead to censorship of websites like what Comcast did with slowing BitTorrent speeds on its network before net neutrality was the law. We could blackout Wikipedia like what happened with SOPA, or just place a large banner. I'm fine with either. Either way, this attempt at eliminating net neutrality is a big deal, and it is important that this attempt be stopped to once again to prevent censorship on the Internet. We'd also need to figure out a date to protest. AnAwesomeArticleEditor (talk) 11:21, 27 April 2017 (UTC)Reply[reply]

Wikipedia has been involved far too much in politics, and adding this sort of political crusade is not really what Wikipedia is about. Collect (talk) 13:00, 27 April 2017 (UTC)Reply[reply]

That black out better not be repeated, ever. L3X1 (distant write) 00:30, 28 April 2017 (UTC)Reply[reply]

Agree w/Collect. Excepting issues where at least 90% of Wikipedia editors are in agreement (ain't happenin, even if it could be determined), Wikipedia should stay out of politics. Not sure whether I agree with L3X1, as a legitimate blackout situation is not inconceivable to me. But this isn't one. ―Mandruss  00:44, 28 April 2017 (UTC)Reply[reply]

Well Mandruss, I can think of a reason for a legit sitewide lockdown: in case of a largescale vandal bot attack or something in which the disruption is more than can be handled, or DNS attacks etc. But shutting down a site (used by EVERYONE, lets not delude ourselves) to show how powerful the Grand Sysops are, is petty and an immature thing to do. Denying a resource (which is supposed to be neutral) to protest something like is a bad idea, and doesn't (to me, at least) demonstrate Competence. My thoughts on Net Wild West Net neutrality can be discussed or not, here or elsewhere, I just really really disapprove of the Project doing stunts like that. L3X1 (distant write) 01:43, 28 April 2017 (UTC)Reply[reply]
I'm thinking of something so incredibly bad that the costs of tolerating it would exceed the admittedly high costs of a shutdown. In such a case, we probably would have 90% agreement, so I'm contradicting myself. It's probably unuseful to speak in generalities, and I can't think of a specific hypothetical offhand. It would be something worse than, say, a particular person being elected U.S. president. ―Mandruss  01:58, 28 April 2017 (UTC)Reply[reply]

RfC: Community Based De-adminship

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


The Arbitration Committee process is great for disputes among large numbers of editors where there are multiple possible remedies that could occur for a large number of editors. It doesn’t succeed as well for requests to desysop due to the bureaucratic nature, the long timelines, and the lack of community input. It is also not as successful for long term low-level abuse of tools where the admin has lost the trust of the community. I wish to propose a slight change to the current system.

I believe by giving the community a way they can start the process, along with a simplified procedure, that it will improve the system along with the trust of the community in giving people the bit more often.

Proposed Community Based De-adminship

If there is a consensus for De-adminship of a given administrator by the community at WP:Administrators' noticeboard, then a motion will be made on behalf of the community to the WP:Arbitration Committee to desysop the admin. It will still be up to the WP:Arbitration Committee to evaluate the evidence presented at the WP:Administrators' noticeboard and to evaluate if the administrator failed to act in a manner appropriate for an administrator to the extent of requiring desysop or to get any additional evidence or information needed to make that decision.

Thank you for considering this proposal. -Obsidi (talk) 23:15, 27 April 2017 (UTC)Reply[reply]



  • Oppose A perennial proposal that always seems to run into roadblocks. This one is even more vague than any of the other ones that have come up and even more open to gaming and disruption by the countless trolls that inhabit enwiki. If you have a serious complaint about abuse of the admin toolset, ArbCom is always open to hear valid complaints. Having another step before the ArbCom process is silly. --Majora (talk) 00:41, 28 April 2017 (UTC)Reply[reply]
  • Oppose The wording of this proposal is way to vague for me to comfortably endorse it. As Majora mentioned this is a perennial proposal that never seems to get more traction. Perhaps if this proposal was more definite in its explanations of the process I'd be more likely to support. As it is I can not in good conscience support this. --Cameron11598 (Talk) 00:52, 28 April 2017 (UTC)Reply[reply]
  • Oppose While brevity is often to be admired, this proposal is just too simplistic to be implemented. Any attempt to fix its vulnerabilities (vagueness, susceptibility to gaming, likelihood to flood AN with spurious requests, etc.) would soon turn it into the bureaucratic process that is currently in place through ArbCom. Eggishorn (talk) (contrib) 01:08, 28 April 2017 (UTC)Reply[reply]
  • Oppose I echo all of Eggishorn's concerns. The gaming by trolls with an axe to grind but little to no evidence already wastes to much time. MarnetteD|Talk 01:16, 28 April 2017 (UTC)Reply[reply]
  • Opposer What we really need to do is be more discretionary in our elections: ie, are they civil and able to comport themselves properly? If yes, than give tools, if not, (no matter what else they have done, tenure, GA and FA, ITIS,) they shouldn't get it. Less content editors and more vandal police. L3X1 (distant write) 01:47, 28 April 2017 (UTC)Reply[reply]
  • Oppose. This doesn't actually change anything. I like community-based desysopping as a concept, but this particular proposal isn't a step forward. Any editor can file a case request for ArbCom to take up and consider desysopping already. How does requiring consensus to file such a case request actually help anything? ~ Rob13Talk 01:54, 28 April 2017 (UTC)Reply[reply]


This already can and does happen in practice. Someone raises what the "terrible" admin did at AN, a bunch pile on, someone says take it to Arbcom and they are off. (It involves much more drama than that, but you get the picture). Alanscottwalker (talk) 02:02, 28 April 2017 (UTC)Reply[reply]

I think you're missing the ArbCom fastpath part, which does not exist today. I think one of the questions is whether ArbCom is capable of venturing outside their own structure and bureaucracy, and the prevailing view appears to be "no". ―Mandruss  02:12, 28 April 2017 (UTC)Reply[reply]


My understanding is that it is still theoretically possible for the community to desysop by consensus; the problems are the practicality of finding consensus to do so, rather than the lack of a process for doing so. If we're going to desysop through AN, why involve the committee at all? Why not just say that the 'crats can find a consensus to desysop in a relevant AN discussion? GoldenRing (talk) 23:41, 27 April 2017 (UTC)Reply[reply]

Per WP:Administrators#Review_and_removal_of_adminship, I believe the only groups that can currently remove admins are Jimbo Wales, by stewards, or by a ruling of the Arbitration Committee. Also there have been several previous requests to remove admins by the community which have failed not because anyone said that the community could already do so but because of fears of sockpuppets/meatpuppets or other "mob mentality" leading to an inappropriate desysop. This proposal is designed to go through a simplified WP:Arbitration Committee process to remove the possibility of such problems. Prior proposals have also requested that a committee of 'crats decide of a desysop should occur (see [1]), however it was opposed on the idea that 'crats are not selected for their abilities in this area (ArbCom members are), that 'crats are life-time appointments (many from a long time ago), and that it would add an additional bureaucratic organization in WP. This proposal tries to avoid all the problems previously presented. -Obsidi (talk) 23:50, 27 April 2017 (UTC)Reply[reply]
@GoldenRing: You are incorrect, which perhaps helps you better understand why many people opposed your RfA due to lack of experience/record. If an admin is elected and then takes poor actions, the only possibility to remove them is to go through the Arbitration Committee. ArbCom has historically been extremely reluctant to desysop anyone without egregious abuse of the admin tools. The current Committee, in particular, has essentially pretended WP:ADMINCOND doesn't exist. There is zero community recourse if ArbCom chooses not to act. ~ Rob13Talk 01:57, 28 April 2017 (UTC)Reply[reply]
Resolved Procedural Problem

@Obsidi: Procedural note. Remember that everything before the first signature comprises the listing entry. I don't think that should include a section heading. ―Mandruss  23:59, 27 April 2017 (UTC)Reply[reply]

I've changed it, it looks like it updated correctly now. -Obsidi (talk) 00:03, 28 April 2017 (UTC)Reply[reply]
@Obsidi: Solved the listing problem, but in a messy and unconventional way. The {{Rfc}} template is usually first. You could create "headings" without using section headings, as Introduction for example. ―Mandruss  00:10, 28 April 2017 (UTC)Reply[reply]
Ok let me see if this works (removing the rfcid).-Obsidi (talk) 00:12, 28 April 2017 (UTC)Reply[reply]

How is this any different from the current process? It all still needs to be taken to Arbcom. CHRISSYMAD ❯❯❯¯\_(ツ)_/¯ 00:50, 28 April 2017 (UTC)Reply[reply]

This goes through the simplified motions process of ArbCom and not through the normal case process. Instead it allows greater community involvement with faster resolution once it gets to ArbCom. -Obsidi (talk) 00:54, 28 April 2017 (UTC)Reply[reply]
Seeing as ArbCom would still have to review the evidence in the case and hear statements I don't see how a simple motion will fly here. Reviewing the evidence and hearing statements is a full case and full cases are always open to community involvement. In fact, during legitimate desysoping "trials" the case talk pages are usually full of community involvement. Seeking a faster resolution is the only saving grace here and frankly, it isn't that big of a saving grace. Rushing is not something that I particularly want to do in these cases. --Majora (talk) 00:57, 28 April 2017 (UTC)Reply[reply]
They will have to review the evidence presented, but hopefully all the evidence and statements will have already been presented at AN without the need for extensive process by ArbCom. -Obsidi (talk) 01:02, 28 April 2017 (UTC)Reply[reply]
"Without the need for extensive process by ArbCom" aren't familiar with how ArbCom works are you? Extensive process is kinda their thing. And seeing as there is no actual time table written into this (one of the many ways this proposal is vague) that isn't likely to change. --Majora (talk) 01:12, 28 April 2017 (UTC)Reply[reply]
Note that WP:VPI is intended for incubation of ideas and formulation of specific proposals for this page, and that would work well if it had a lot more participation. Most editors aren't interested in that part of the process, we just want to !vote on specific proposals. This is part of the reason that any significant change is very hard to achieve. ―Mandruss  01:20, 28 April 2017 (UTC)Reply[reply]

I would like to note that as to the "likelihood to flood AN with spurious requests," wp:Boomerang is always a possibility at AN, and filing a completely spurious request would likely lead to that. -Obsidi (talk) 01:18, 28 April 2017 (UTC)Reply[reply]

Boomerang is a generally weak deterrent and would be no deterrent at all to a troll that knows they are likely to face indeff anyway. Eggishorn (talk) (contrib) 01:31, 28 April 2017 (UTC)Reply[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Redirect talk pages with only banners

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.

Some pages like WT:NJournals are tagged only with a banner and nothing else. I think it's pretty reasonable to say that people who link to WT:NJournals expect to have people be taken to the same place Wikipedia talk:Notability (academic journals). [This is true in Wikipedia talk space, just like in any other talk spaces, whether mainspace, category space, etc... This can be confusing to editors, because they are told "comment here", and the page doesn't redirect to the discussion they were meant to be taken.

So I propose that we have a bot with the following logic

For an example where this is already done, see WT:NJOURNALS. Headbomb {t · c · p · b} 09:37, 14 April 2017 (UTC)Reply[reply]


  • Support, as proposer. Headbomb {t · c · p · b} 09:38, 14 April 2017 (UTC)Reply[reply]
  • Support to avoid confusion, the page and talk page should both redirect. AD 09:55, 14 April 2017 (UTC)Reply[reply]
  • Comment are you referring to articles that were merged, but there were previous discussion on the talk page of the merged article? In that case, the talk page should be preserved and not redirected, any project banners on the talk page should be reclassed as Redirect to indicate to the projects that the articles were merged, but there were previous discussions preserved. —Farix (t | c) 13:33, 15 April 2017 (UTC)Reply[reply]
    • No, this would be restricted to pages that only have banners on it, and nothing else. Pages with discussions would be skipped by the bot. Headbomb {t · c · p · b} 22:07, 15 April 2017 (UTC)Reply[reply]
      • And what about talk pages where the only "discussions" are bot messages? Should those also be redirected as well? —Farix (t | c) 11:48, 21 April 2017 (UTC)Reply[reply]
  • Support. Seems sensible enough. Gestrid (talk) 04:45, 16 April 2017 (UTC)Reply[reply]
  • Support. Letting the talk page contain only banners will be confusing, while any other ways of linking to the redirect (like using {{Talk page of a redirect}}) would be roundabout and with no benefit that I can think of. – Uanfala (talk) 13:43, 17 April 2017 (UTC)Reply[reply]
  • Support - page and talk page should both redirect.. SW3 5DL (talk) 04:53, 18 April 2017 (UTC)Reply[reply]
  • Support per nom. Yashovardhan (talk) 11:49, 19 April 2017 (UTC)Reply[reply]
  • OK. You have my axe. Herostratus (talk) 13:37, 20 April 2017 (UTC)Reply[reply]
  • Support with emphasis on the first step in the bot logic (nothing but banners, if there's anything else it should not be auto-redirected). Respectfully, InsaneHacker (💬) 19:48, 21 April 2017 (UTC)Reply[reply]
  • Support. I didn't know redirecting with the banner was possible, or I'd have been doing it this way all along. Good idea. Ks0stm (TCGE) 19:54, 21 April 2017 (UTC)Reply[reply]
I discovered this fairly recently myself, otherwise I'd have proposed this years ago! Headbomb {t · c · p · b} 11:35, 22 April 2017 (UTC)Reply[reply]
Support if all revisions of the talk page are nothing but banners. עוד מישהו Od Mishehu 21:16, 22 April 2017 (UTC)Reply[reply]
  • Support I agree with others. But what if A redirects to B and Talk:A exists (is a blue link) but Talk:B doesn't (is a red link)? Should the bot create Talk:B with banners copied from Talk:A, have admin rights and delete Talk:A per WP:CSD#G8, or do a page move from Talk:A to Talk:B? Also, other bots such as AnomieBOT would be affected, for example, when an article title previously deleted at AfD was recreated as a redirect to another article. GeoffreyT2000 (talk) 00:44, 25 April 2017 (UTC)Reply[reply]
    You raise excellent questions. My initial guess is that in this case Talk:B should be created with the banner copied from Talk:A and then Talk:A should have a REDIRECT prepended to point it to Talk:B. In general I'd be hesitant to delete Talk:A if it obscures any history. Doing a page move I think is a bad idea because the history of Talk:A may be very complicated even if it presently only has a banner. Many pages, especially project-related, have gone through multiple roles before they settled down on their present function. So the history of Talk:A may be completely unrelated to the purpose of Talk:B but make sense under the name of Talk:A. Jason Quinn (talk) 16:04, 26 April 2017 (UTC)Reply[reply]
  • Support Trying to think of a reason this might be bad but only noticing benefits. Anybody else better at playing Devil's advocate with this? Jason Quinn (talk) 16:05, 26 April 2017 (UTC)Reply[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

RfC: Linking to details regarding the offline Medical Wikipedia app

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

The offline app allows you to download all of Wikipedia's medical articles in an app to access them when you have no Internet.
Wikipedia's health care articles can be viewed offline with the Medical Wikipedia app.

Should we allow a {{sister project}} style sidebar, i.e. Template:Offline in the form of {{offline|med}}, to be placed within the external links section of medical articles for the purpose of promoting Wikipedia:WikiProject Medicine/App? — Godsy (TALKCONT) 17:36, 29 March 2017 (UTC)Reply[reply]


  • Support Prior discussion here. Part of our efforts include "giving free access to the sum of all human knowledge" to all people. This should not be restricted to just when people have a functional Internet connection (something those in the developed world take for granted). Part of our work is to improve access to knowledge in the language of people's choice and in formats that they can use. For many of those in the developing world Internet access is only avaliable for a couple of hours a day or only when they visit larger urban centers. Offline content address these limitation. We know our online content struggles to reach those in the developing world. Our offline medical apps however have been downloaded by more than 150,000 people of which about 80% are from the developing world. Doc James (talk · contribs · email) 17:50, 29 March 2017 (UTC)Reply[reply]
  • Support I wasn't a great fan of a huge banner for this, but I can't see any problems with this template, and Doc James makes a compelling case for the apps usefulness. Sam Walton (talk) 17:57, 29 March 2017 (UTC)Reply[reply]
  • support per reason [2]--Ozzie10aaaa (talk) 17:58, 29 March 2017 (UTC)Reply[reply]
  • Support: The Offline Medical Wikipedia app is an application that allows Wikipedia's medical content to be downloaded in a choice of languages in compressed ZIM format (as well as a free, open-source offline browser, Kiwix, that will natively display the compressed data, if required). Its principal purpose is to allow mobile phone users in parts of the world where internet access is restricted, intermittent, or unreliable to have constant access to our medical content. As an additional means of distribution of our content, I'd personally prefer it to be a sidebar link (like "Download as PDF" is), but I'll certainly support a link somewhere in the footers of medical articles to the WikiProject Medicine page where it is documented. --RexxS (talk) 18:24, 29 March 2017 (UTC)Reply[reply]
  • Support. There are more than a million billion of people in developing countries that only have access to the Internet for a limited time. This banner is useful for million billion of readers who can use it when they are not online. The banner is the sum of all human knowledge at your fingertips for people who don't have unlimited Internet access or who want to use it while offline. Is there a better solution? QuackGuru (talk) 19:03, 29 March 2017 (UTC)Reply[reply]
User:QuackGuru I think you mean more than a BILLION :-) Doc James (talk · contribs · email) 19:06, 29 March 2017 (UTC)Reply[reply]
Yep. QuackGuru (talk) 19:17, 29 March 2017 (UTC)Reply[reply]
  • Support - I had thought this debate had already been resolved satisfactorily in the deletion discussion. Yes, the sidebar is non-intrusive and helping users access our articles is an important part of our mission. Sizeofint (talk) 19:35, 29 March 2017 (UTC)Reply[reply]
  • Support The debate had already been resolved to almost everyone's satisfaction, and this RFC appears to be unnecessarily pointy. • • • Peter (Southwood) (talk): 19:57, 29 March 2017 (UTC)Reply[reply]
  • Support I also support this. I think anyone working in a developing countries context knows how important it is to have Wikipedia content available offline. I wonder if the people opposing this have ever lived in an area with poor internect access and poor public health, few doctors available, no access to healthcare etc.? For people like that having the offline version of medical content (in several languages) is wonderful. Due to the fact that not many people are aware of this app yet, I strongly support having the template (or any other form of awareness raising for this app) in an appropriate place of many related Wikipedia articles. Having it at the bottom right seemed like a perfect solution to me! EMsmile (talk) 20:01, 29 March 2017 (UTC)Reply[reply]
  • support is a related WMF project, and will be limited to medical articles. Jytdog (talk) 00:18, 30 March 2017 (UTC)Reply[reply]
  • Support - would also support the "inline" type being discussed below. Note, this support is contingent on the format that has already been debated multiple times - primarily that it links to an editor-controlled page. — xaosflux Talk 00:22, 30 March 2017 (UTC)Reply[reply]
  • Support - the proposal is similar to other boxes that we have, so should be understandable to people who consult Wikipedia for a variety of topics. I would particularly note that the template should also display on mobile devices (I was disappointed to find that {{Library resources box}} does not). -- (talk) 00:55, 30 March 2017 (UTC)Reply[reply]
This template should also be included in {{Sister project links}} if this goes ahead. -- (talk) 01:05, 30 March 2017 (UTC)Reply[reply]
  • Support. This really is a very worthwhile initiative for the purpose of helping more people become readers of Wikipedia – which after all should be what we all want. In previous versions, there have been problems with potential advertising or with overly-large banners, but those problems have now been solved. And putting it in EL is the right way to do it. I think this RfC helps tie up loose ends from previous discussions, by spelling out where and how the box will be used. I also would support the inline idea described below. --Tryptofish (talk) 01:10, 30 March 2017 (UTC)Reply[reply]
  • Support. Seems like a worthwhile cause that could be very helpful in regions of the world with poor internet infrastructure. ---- Patar knight - chat/contributions 02:29, 30 March 2017 (UTC)Reply[reply]
  • Support Wikipedia's health care articles are generally high quality and it is helpful to inform readers about the app which displays that content. Johnuniq (talk) 10:45, 30 March 2017 (UTC)Reply[reply]
  • Support, it's a good way to give the app visibility. Icebob99 (talk) 15:39, 30 March 2017 (UTC)Reply[reply]
  • Support per Doc James. Gestrid (talk) 04:53, 31 March 2017 (UTC)Reply[reply]
  • Support for the same reasons as at the XfD I commented at. jcc (tea and biscuits) 12:31, 2 April 2017 (UTC)Reply[reply]
  • Support — There really are no reasons to oppose beyond simply being obstructionist and wanting to hinder any improvement to the encyclopedia. It always ends up being the same people starting these pointless RfCs or who take it upon themselves to be the sole arbiters of guidelines and interpreters of policy. Carl Fredrik talk 00:37, 4 April 2017 (UTC)Reply[reply]
  • Support - Addresses offline content issues for those in the developing world with limited internet access. SW3 5DL (talk) 04:44, 7 April 2017 (UTC)Reply[reply]
  • Support seems pretty obvious per above arguments, Sadads (talk) 22:45, 11 April 2017 (UTC)Reply[reply]
  • Support, conditional on the template a) being restricted to the "see also" or "external links" sections as proposed, and b) linking to a Wikimedia-site page about the app rather than directly to one or more app stores. It's a great idea as long as its implementation follows the same principles as our other article meta-content. {{Nihiltres |talk |edits}} 15:05, 12 April 2017 (UTC)Reply[reply]
    • @Nihiltres: One other possibility that I've previously suggested is hosting the page about the app on Meta, probably at a subpage of m:WikiProject Med Foundation (because the app is available in many other languages besides English). As you mention linking to "a Wikimedia-site page about the app", am I right in thinking that you'd still be in favour if the landing page were moved to the Meta-Wiki instead? --RexxS (talk) 18:14, 12 April 2017 (UTC)Reply[reply]
      • @RexxS: Yes, definitely. {{Nihiltres |talk |edits}} 18:22, 12 April 2017 (UTC)Reply[reply]
        • Will get to the move to meta shortly. Agree with the other comments by User:Nihiltres aswell.Doc James (talk · contribs · email) 05:34, 13 April 2017 (UTC)Reply[reply]
          • There are downsides of a move to meta; namely, keeping it local means it remains in our jurisdiction (i.e. it is governed by our local policies and guidelines). I'm curious what Xaosflux thinks, due to "support is contingent on the format that has already been debated multiple times - primarily that it links to an editor-controlled page", does it matter which contingent of editors control the page? — Godsy (TALKCONT) 15:22, 13 April 2017 (UTC)Reply[reply]
            • @Godsy: It doesn't matter to me if it is a w:en: link or a meta: or a link; main point being that it leads somewhere under volunteer editorial control (as opposed to the original link to an external commercial website). — xaosflux Talk 18:00, 13 April 2017 (UTC)Reply[reply]
  • SupportDoc James has expressed a more than adequate case for expanding a feasible solution spreading the reach of human knowledge, engendering greater involvement, and expanding the avenues of access to the information contained by this project to a greater portion of the world's population. I see absolutely no reason for any opposition on my part. unak1978 00:44, 29 April 2017 (UTC)Reply[reply]


  • Oppose. Use formatting similiar to {{dmoz}} instead. KATMAKROFAN (talk) 20:28, 29 March 2017 (UTC)Reply[reply]
    • Possibly an unfortunate analogy as DMOZ has just closed down. Nevertheless it's an interesting suggestion, so could you give an example of how this might look on an article like Pneumonia, please? --RexxS (talk) 21:05, 29 March 2017 (UTC)Reply[reply]
KATMAKROFAN (talk) 21:35, 29 March 2017 (UTC)Reply[reply]
Thank you. So essentially, you'd prefer the content of the template as plain text among the external links, rather than in a box floated to the right of the page with the sister projects? That seems a possible alternative. --RexxS (talk) 22:05, 29 March 2017 (UTC)Reply[reply]
We also have Template:Commons-inline. The two are not exclusive of each other. Doc James (talk · contribs · email) 22:09, 29 March 2017 (UTC)Reply[reply]
(edit conflict)Seems a strange way to do it. The links placed there are almost always links external to the Wikimedia projects, whereas we tend to put links to Wikimedia related places (Commons for example) in a side box like the one being proposed here. Sam Walton (talk) 22:09, 29 March 2017 (UTC)Reply[reply]
  • I'm going to oppose.

    I'm sympathetic to the view that "offline reading" should be enabled.

    I do not, however, believe this is the way to do it. A systematic way, which relies not on en.WP's hack of a template, nor one which advertise a particular reader or viewer, is a) much better and b) provides the functionality for all pages, without c) the mess of a template addition to every article (within a certain scope) for d) every reader, mobile or not. To that end, there is a phabricator task for this funcitonality at phab:T113396. My final opinion: Just be patient. It's on the (WMF) radar. Courtesy ping to AGomez (WMF) who looks to have been editing the page at meta:New Readers/Offline. --Izno (talk) 12:58, 30 March 2017 (UTC)Reply[reply]

  • Yup more options for reading Wikipedia offline are coming :-) The page this template links to will discuss that option as soon as it is avaliable. The template is not specific to raising awareness about a single app but about raising awareness about offline options generally (options of course need to be free and under an open license). Doc James (talk · contribs · email) 13:16, 30 March 2017 (UTC)Reply[reply]
  • Oppose: it is not the job of each individual wiki article to make "meta" announcements of "other things that are available" related to Wikipedia. Articles are already at the borderline of being a mess in this sense, and if every special interest group within Wikipedia proceeded to add such "meta" announcements within individual articles, the result would clearly be untenable. I'm not sure why this particular announcement deserves an exception. Aureliano Babilonia (talk) 01:55, 3 April 2017 (UTC)Reply[reply]
    • Because we see it as part of our mission to provide content to those in the developing world in a format that they can use. And also this appears to have consensus. Doc James (talk · contribs · email) 23:05, 9 April 2017 (UTC)Reply[reply]
    • I'm sympathetic to your (Aureliano Babilonia's) argument; it is superficially good. The problem is that it relies on skewed priorities. At least in the short term the significant benefit (people with poor Internet access having access to Wikipedia's medical content) arguably outweighs the minor cost (us volunteers having slightly more work and slightly less organization), and in the longer term we can push for better ways to surface this sort of meta-content to users, to reduce or eliminate that cost. {{Nihiltres |talk |edits}} 15:37, 12 April 2017 (UTC)Reply[reply]



Relevant discussions preceding this RfC: Wikipedia:Miscellany for deletion/Wikipedia:WikiProject Medicine/App/Sidebar, Wikipedia talk:WikiProject Medicine/App#Sidebar, and Wikipedia talk:WikiProject Medicine/Archive 94#Sidebar. — Godsy (TALKCONT) 17:36, 29 March 2017 (UTC)Reply[reply]

it seems s support vote is best for everyone, not clear what(or why) your position is such given prior general opinion[3]--Ozzie10aaaa (talk) 18:10, 29 March 2017 (UTC)Reply[reply]
Discussion about titling the RfC
The initial heading was "non neutral". Have adjusted it so that it is.[4]. And here is the link to policy requiring the statement of the RfC to be neutral[Wikipedia:Requests_for_comment#Statement_should_be_neutral_and_brief] Doc James (talk · contribs · email) 18:19, 29 March 2017 (UTC)Reply[reply]
@Doc James: Advertising, i.e. "the act or practice of calling public attention to one's product or service", is not inherently non-neutral. However, raising awareness is inherently non-neutral. — Godsy (TALKCONT) 18:32, 29 March 2017 (UTC)Reply[reply]
Godsy you appear to dislike the app. Can you explain why? I was under the impression that we address your concerns. Doc James (talk · contribs · email) 18:34, 29 March 2017 (UTC)Reply[reply]
@Doc James: Would you find "Publicizing the offline Medical Wikipedia app" or "Promoting the offline Medical Wikipedia app" agreeable for the RfC title? — Godsy (TALKCONT) 18:40, 29 March 2017 (UTC)Reply[reply]
We could use "Linking to details regarding the Offline Medical Wikipedia app" Doc James (talk · contribs · email) 18:43, 29 March 2017 (UTC)Reply[reply]
 Done. I'll fix the existing links. — Godsy (TALKCONT) 18:46, 29 March 2017 (UTC)Reply[reply]
Godsy, although you're a relative newcomer, you must know very well by now that this encyclopedia is strongly opposed to any advertising. It is inconceivable that you do not understand that calling other editors' contributions "advertising" is rude and and offensive to them. To then edit-war your calumny back into this RfC is beyond acceptable behaviour, and I shall be considering seeking administrative assistance to ensure that you do not repeat that behaviour in future. --RexxS (talk) 18:56, 29 March 2017 (UTC)Reply[reply]
@RexxS: Changing it to raising awareness was no better. I reverted twice, then came here to discuss; Doc James changed it thrice. If you do choose to seek administrative assistance, it will likely be fruitless, as I've done nothing inappropriate. — Godsy (TALKCONT) 19:07, 29 March 2017 (UTC)Reply[reply]
@RexxS: I misspoke, I reverted twice. I was concerned about the link at {{cent}}. Best Regards, — Godsy (TALKCONT) 19:13, 29 March 2017 (UTC)Reply[reply]
Changing it to raising awareness was no better - That's simply untrue. "Raising awareness" on Wikipedia carries none of the pejorative implication of "advertising" and it's not the "euphemism" that you claimed in your edit summary, ... if you euphemize inappropriately again, I expect you to check my contributions and fix all the existing links. You don't seem to understand edit-warring either. You called the template "Advertising the Medical Wikipedia app"; Doc James changed it to "Raising Awareness of the Offline Medical Wikipedia app". That's the point where you take it to talk, not after forcing your preferred version back into this page twice more. I understand your concern about having to update links at Cent, but that's a small price to pay for not offending other good-faith editors. Quite honestly, I'd much prefer not to have to waste my time at ANI, but I remain concerned that you're not willing to own up to mistakes like 22 reverts with no reason other than the edits you reverted didn't seek consensus beforehand and calling an RfC with a non-neutral title. --RexxS (talk) 19:33, 29 March 2017 (UTC)Reply[reply]
Euphemize wasn't the best description, though it is not necessarily inaccurate; it and the rest of my edit summary was a reaction to behavior that I've come to expect from some wp:med participants. I created it at Title X (creation), Doc James changed it to Title Y (Bold), I revered it back to X (Revert) - that is the point where discussion should have taken place. Doc James shouldn't have changed it a second time (Discuss), especially as the title they changed it to was not any better neutrality-wise. The over 20 reverts you mention: Doc James added {{offline|med}} to a group of articles (Bold), I reverted the additions notifying them that the change was contentious and suggesting a venue for discussion (Revert), Doc James ignored that and restored them all (Discuss). History is important for context: Wikipedia:WikiProject Medicine/App/Banner was added to the top of a few articles, some about a year ago, and at least one with the edit summary "one week trial". I'm not sure if there was any local consensus at that point, but editors removed the banners, and they were restored by members of the WikiProject. Wikipedia:Miscellany for deletion/Wikipedia:WikiProject Medicine/App/Banner began. It was closed as "Keep, but not to be inserted into articles without obtaining consensus to do so." Editors removed the banners from the articles for a second time per that consensus, but again, members of the WikiProject restored them. Wikipedia:Village pump (proposals)/Archive 138#Use of Wikipedia:WikiProject Medicine/App/Banner on articles is opened, and finally 3 months later, the banners were removed after being present at the top of articles all that time (since the MfD) against community consensus. That's all I have to say on the matter here, as not to further detract from the RfC. — Godsy (TALKCONT) 04:26, 30 March 2017 (UTC)Reply[reply]

I think it would be worth showing the actual template in question, to allow those unfamiliar with the previous debates to get an idea of what we are discussing. --RexxS (talk) 18:29, 29 March 2017 (UTC)Reply[reply]

Thanks User:RexxS have moved to the top of the RfC. Doc James (talk · contribs · email) 18:38, 29 March 2017 (UTC)Reply[reply]

If it is advertising, then it is advertising for something benign. The real offender is the link to the "Wikipedia Shop" selling T-shirts which appears on every page. Matthew Ferguson (talk) 18:51, 29 March 2017 (UTC)Reply[reply]

The app is developed by volunteers at WPMED and Wikimedia CH. It is free and without advertising. The development cost (paying for programmers) is covered by movement funds. We are not "selling" anything so the user of the term "advertising" IMO is inaccurate. Doc James (talk · contribs · email) 19:15, 29 March 2017 (UTC)Reply[reply]
agree--Ozzie10aaaa (talk) 19:40, 29 March 2017 (UTC)Reply[reply]
Promotion/advertising/raising awareness/etc. It's semantics. I feel the reason this is an issue with some is that it represents placing a link on encyclopedia pages to a program which is not directly related to any given encyclopedia topic. Matthew Ferguson (talk) 20:40, 29 March 2017 (UTC)Reply[reply]
It's more placing a link to the data - i.e. the compressed Wikipedia content. Surely the program (offline browser) is incidental. Wouldn't the reason you suggest be as logical as having an issue with the [Download as PDF] link, which is on every article page, because Adobe Acrobat "is not directly related to any given encyclopedia topic"? --RexxS (talk) 20:48, 29 March 2017 (UTC)Reply[reply]
Invalid analogy really. 1. PDFs can be read with many programs, 2. downloading the article as PDF does not require you to download any program in particular, 3. the link gives you a PDF of the article you were on, I assume the link to the medical app will not directly link you to the article you were originally on. Matthew Ferguson (talk) 21:10, 29 March 2017 (UTC)Reply[reply]
Not really. 1. ZIMs can be read by many programs; 2. downloading the data does not require you to download any program in particular – especially as ZIM is an open and standardized file format, unlike PDF; 3. the link gives you all of Wikipedia's medical content, including the article you are on, which allows you to go to all of the other medical articles that the article has wikilinks to (unlike a PDF). --RexxS (talk) 22:16, 29 March 2017 (UTC)Reply[reply]
Yup exactly. The main WP app should be reading ZIMs soon aswell.Doc James (talk · contribs · email) 22:48, 29 March 2017 (UTC)Reply[reply]
Clicking the "download as PDF" gives me a PDF of the article I was on. Clicking this link takes me to a description page about an app which I would have to download, which I would then have to navigate to find the article again. This is what is meant by not directly related to any given encyclopedia topic. Matthew Ferguson (talk) 19:54, 30 March 2017 (UTC)Reply[reply]

I think it's about time to arrange for this RfC to be closed. I suggest to the closing admin that the overwhelming strength of argument lies with the support !votes, and that there is a strong, if not unanimous, consensus in support of the proposal. I wonder if I can ask the closer to make a judgement on whether this RfC is sufficient to allow the linked page to be moved to Meta-Wiki at some point in the future (as the app is used by multiple Wikipedias with different languages), or whether they feel a new RfC would be required if that course is to be taken? --RexxS (talk) 12:50, 27 April 2017 (UTC)Reply[reply]

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

Acces: User of delete pages

أهلا إخوتي، لقد دخلت لصفحة ويكيبيديا:إداريون ووجدت الكم الهائل من المهام التي تقع على عاتقهم، لذلك لا يستطيعون القيام بها كلها رغم أنها مهمة جدا للحفاظ على جودة الموسوعة، منها حذف الصفحات المخالفة، لذلك أقترح نزع هذه المهمة من قائمة مهامهم، وإنشاء صلاحية جديدة هي "صلاحية الحاذف" لحذف الصفحات المخالفة بكبسة زر كما يفعل الإداري، لتخفيف الضغط عليه. تقدم هذه الصلاحية للأشخاص المهتمين بمكافحة التخريب الكبير (أي صفحات تخريبية وليس جمل أو فقرات) لحذف مثل هذه الصفحات بسرعة بدل انتظار إداري أو إرهاق المسترجعين بإرجاع التعديلات حتى نترك مجالا كبيرا مفتوحا للمسترجعين والإداريين بممارسة مهامهم بكل سهولة دون مهام تثقل كاهلهم.

  • (Google Translation: Hello, my brothers, I have entered the Wikipedia page: administrators and found the huge amount of tasks that they have, so they can not do all of them although they are very important to maintain the quality of the encyclopedia, including delete the infringing pages, so I suggest removing this task from their list of tasks, A new "privilege" to delete the infringing pages at the push of a button as the administrator does, to relieve the pressure on him. This allows people who are interested in combating vandalism (such as subversive pages, not sentences or paragraphs) to quickly delete such pages instead of waiting for administrators or overloading the returnees so that we leave a lot of room for those who can easily perform their tasks without burdening them.)

Mohamed Ajjani (talk) 13:19, 30 April 2017 (UTC)Reply[reply]

Is this proposal for English Wikipedia, Arabic Wikipedia, both, neither or some other option? • • • Peter (Southwood) (talk): 18:11, 30 April 2017 (UTC)Reply[reply]
If this is for the English Wikipedia it is a play on the always denied perennial proposal of "admin-light". Considering that deletion is one of the most sensitive tools in the admin toolkit and the one that could present the most problems I don't see how this proposal will ever be viable. At least not here. Other projects have their own things. --Majora (talk) 18:25, 30 April 2017 (UTC)Reply[reply]
Personally, I do not feel overwhelmed. We seem to work through the backlogs. Not that I think "Admin light" is a bad idea per se, I just know we will never be able to work out the difficulties to make it viable. Dlohcierekim 18:42, 30 April 2017 (UTC)Reply[reply]

Clicking on images

Another proposal of mine (also for all Wikipedia versions, if possible) would be to make sure that after clicking on an embedded file in an article and entering the Commons page of that file, you get back right to the position of that image in the article when using the back-button of your browser. Up to now, this is not the case at least for the current Firefox, but instead you always end up at the beginning of the article once you have entered Commons. Would this also be worth forwarding to Phabricator in your view?--Hubon (talk) 15:31, 12 April 2017 (UTC)Reply[reply]

You'd better ask this question on Wikipedia:Village_pump_(technical). Ruslik_Zero 20:15, 12 April 2017 (UTC)Reply[reply]
Do you have "Enable Media Viewer" at Special:Preferences#mw-prefsection-rendering? Media Viewer is known to mess with the normal functioning of the back button. PrimeHunter (talk) 21:52, 12 April 2017 (UTC)Reply[reply]
@Ruslik0: Thanks for your advice! @PrimeHunter: Yes, I do, but still: If we take the article Nazi plunder and click twice on image no. 5, we get to this site. Now, if we click "back", we end up at the very beginning of the article instead of the relevant section. And it's the same with all the other Wikipedias! As recommended by Ruslik, I will now refer the issue to Wikipedia:Village_pump_(technical).--Hubon (talk) 22:30, 13 April 2017 (UTC)Reply[reply]
If Media Viewer is causing problems for you, then disable it. It's crap quality, buggy code, and I recommend against using it. -FASTILY 22:42, 15 April 2017 (UTC)Reply[reply]
@Hubon: Preservation of scroll state is a browser function (I have no trouble with Chrome or Safari). Which browser are you using ? —TheDJ (talkcontribs) 13:06, 17 April 2017 (UTC)Reply[reply]
@TheDJ: Thanks for your interest! I use the latest Firefox version. Now, do you think it would be very difficult for Phabricator to modify Media Viewer in a way that would render it compatible with all common broswers regarding preservation of scroll state? Greetings--Hubon (talk) 13:11, 18 April 2017 (UTC)Reply[reply]
I can confirm that this is a problem with Firefox. You should report it in phabricator. —TheDJ (talkcontribs) 09:55, 20 April 2017 (UTC)Reply[reply]

Note: Unfortunately, nobody answered on Wikipedia:Village_pump_(technical)... :-(--Hubon (talk) 21:04, 19 April 2017 (UTC)Reply[reply]

user:TheDJ: Many thanks for your interest! Would you mind reporting the issue on Phabricator? As I've already communicated before, I'm admittedly not at all familiar with this platform... Thus, I'd be very grateful for any help with passing on the the request to the institutions responsible. Best--Hubon (talk) 19:28, 23 April 2017 (UTC)Reply[reply]
@Hubon: Reported as T163875. You can subscribe to it using the "Subscribe button" in the right column (After you logged in using your Wikimedia account, by pressing the Mediawiki button on this page) —TheDJ (talkcontribs) 08:35, 26 April 2017 (UTC)Reply[reply]
@TheDJ: Thank you so much!!! I just did as you told me. Now let's wait and see what happens. Thanks once again and best regards--Hubon (talk) 13:53, 26 April 2017 (UTC)Reply[reply]
@TheDJ: Alright, just for your information: They've meanwhile closed the file... Best--Hubon (talk) 00:59, 1 May 2017 (UTC)Reply[reply]

Renaming Category:WikiProject Infoboxes

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.

I just want to alert people that there is currently a proposal at CFD for renaming Category:WikiProject Infoboxes to Category:Wikipedia infoboxes [5]. Personally, I have opposed this, as this is obviously a maintenance category. I don't understand the rationale behind the proposal. ---Steve Quinn (talk) 18:04, 15 January 2017 (UTC)Reply[reply]

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

Response to 2017 ban in Turkey

Have started drafting a community response. Doing so on meta[6]. Wondering peoples thoughts. Best Doc James (talk · contribs · email) 17:12, 29 April 2017 (UTC)Reply[reply]

  • An unfortunate development, this banning, but not surprising. There are frequent edit wars and article forks where political situations are involved and the article history can contain truly bad content, as can the talk page and talk page history. There is a fine line between the rights of a nation-state to control information flow across their borders and self-serving censorship. Without deeply thinking this through, it might be a great service to most people to "negotiate" with Turkey on their blocking specific articles while allowing the rest to pass through. Though sour tasting, this would allow access to 99% of Wikipedia rather than 0%. --User:Ceyockey (talk to me) 01:58, 1 May 2017 (UTC)Reply[reply]
While I see your point, I can't really get on board with it User:Ceyockey, and I think most people won't. I (and I think most people) probably don't agree with "There is a fine line between the rights of a nation-state to control information flow across their borders...". There's no fine line. Nation-states have no moral right whatsoever to control information flow across their borders, as a general rule. There could possibly be some argument at the extreme margins (state secrets and so forth). Maybe. I get your 99% versus 0% point, but that feels like a possible slippery slope, and matters of principle are in play here. Herostratus (talk) 02:08, 1 May 2017 (UTC)Reply[reply]

Recategorizing all medicine and biology articles using the more specific MeSH hierarchy

MeSH is a very important database created by the United States National Library of Medicine (NLM) to index books and journal articles in medicine and biology. It is updated annually. For 2017, it contains more than 55000 categories (they call them descriptors) which can very specifically categorize any article of biology or medicine. My idea is to import this tree hierarchy to Wikipedia. This could be achieved using AWB tool and an approved Bot account. I got already a *.xlsx file listing these descriptors from the official MeSH website. I have then converted it to a text file which is ready for mass category creation using CSV Loader Plugin of AWB. Some of these categories are already on Wikipedia, but I believe the majority are not yet. Each MeSH category will contain the following text:

Template:empty category
Template:MeSH category, including the unique MeSH ID as a key.
template:cat main
MeSH definition:
category:Medical Subject Headings, including the tree number as a key.

Examples of such MeSH categories are: Category:Anatomic Landmarks, Category:Body Regions

I think also that this idea, if applied, will reveal hundreds of new red links.

Previous discussions:

Tools needed:


  • Support Doc James (talk · contribs · email) 23:27, 18 April 2017 (UTC)Reply[reply]
  • support--Ozzie10aaaa (talk) 00:07, 19 April 2017 (UTC)Reply[reply]
  • Support - AWB and bot usage to automate the organisation of already created categories into the MesH hierarchy, and future categories at a reasonable interval. I think the automated creation of (potentially 50,000+) categories needs a more thorough proposal with a more advanced bot or significant user interaction. PriceDL (talk) 12:27, 20 April 2017 (UTC)Reply[reply]
    • Would also support the automated creation of currently nonexistent categories necessary to represent the MesH hierarchy. PriceDL (talk) 12:31, 20 April 2017 (UTC)Reply[reply]


  • This seems a misuse of the categorization system. Finding which articles are missing is not the purpose of categories (or else they should be maintenance categories, hidden from sight), normally one would create one or more lists in project space for this where the redlinks can be listed. Having 55,000 categories for this is serious overkill (do we really need Category:Peptidyl-Prolyl Cis-Trans Isomerase NIMA-Interacting 4, which has two different codes to boot?). Creating a category system using a higher level of grouping from this tree hierarchy seems a potentially good thing though, with just a few thousand categories. I also don't see how you propose to differentiate between categories with the same MeSh name (e.g. "Superficial Musculoaponeurotic System" is A01.456.505.875 and A01.598.500). The actual benefit you propose (" It will ease access to medical articles from categories.") can better be achieved by a somewhat smaller category tree than the massive one you propose. Fram (talk) 07:17, 20 April 2017 (UTC)Reply[reply]
    • @Fram: Would you suggest a way to remove very very specific categories like Category:Peptidyl-Prolyl Cis-Trans Isomerase NIMA-Interacting 4 from the hierarchy? Regarding categories with the same Mesh name, they are basically the same category but subcategorized under two different categories, that's why they have different tree numbers, but you can notice that they have the same "unique" ID number. --Brainist (talk) 07:29, 20 April 2017 (UTC)Reply[reply]
      • I don't know a way whereby a bot can decide which categories are too specific, and which aren't. It isn't as easy as saying "lowest level is not used, all higher levels are used". Perhaps something like "only go three levels deep" may be a (simplistic) solution. Or perhaps this simply isn't a good bot task after all. Creating thousands of empty mainspace categories seems like a bad idea in any case. Fram (talk) 08:48, 20 April 2017 (UTC)Reply[reply]
        • Thanks for making me aware of the duplicates, which after exclusion, the unique categories came out to be almost exactly the half, just 27900 categories. I don't think this number for categorizing all articles related to whole medicine, dentistry, veterinary medicine, biology is massive. They will be temporarily empty till I fill them. Notice that out of those 27900, there are already thousands of medical categories out there in Wikipedia which will be skipped by the bot. --Brainist (talk) 09:39, 20 April 2017 (UTC)Reply[reply]
        • Category:Peptidyl-Prolyl Cis-Trans Isomerase NIMA-Interacting 4 would be almost empty today containing just "PIN4", but after let's say 3 years, with the encyclopedia expanding, this category will contain articles about diseases caused by malfunction of this enzyme or drugs acting on it, etc. This hierarchy will be the last categorization needed for medical and biological articles, and it will be updated annually with the release of a newer version of MeSH database by NLM. --Brainist (talk) 09:51, 20 April 2017 (UTC)Reply[reply]
          • We've had PIN4 for 9 years now, and no articles link to it. I see no reason to share your optimism that in a few years time, these categories will be populated with more articles suddenly. Subdividing categories when they turn out to be overpopulated is natural; creating thousands of empty and near-empty categories in the hope that they will magically become more populated in a few years time is not something I can support though. I also note that this is much wider than just medicine: your proposal would create categories like Category:Alouattinae, which owuld be a duplicate of Category:Howler monkeys. I don't see in your proposal how you wuold deal with the many, many similar cases where we already have a category for the common name and you would create one for the MeSH name. Basically, the more I look at this, the less erason I see to do this by bot or en masse. Fram (talk) 10:33, 20 April 2017 (UTC)Reply[reply]
  • Oppose - we do need human judgement on which categories need to be created. For example, we have Category:Bonobo, so we don't need Category:Pan paniscus (on List of MeSH codes (B01)#MeSH B01.150.900 --- vertebrates, number B01.150.900.649.801.400.112.400.600); nor do we necessarily need Category:Papio anubis or its likely name Category:Olive baboon (number B01.150.900.649.801.400. While both of these items come from the organism subtree, I think similar attention would need to be given to the other subtrees. עוד מישהו Od Mishehu 11:41, 20 April 2017 (UTC)Reply[reply]
  • I'm not going to use bold in this oppose, but is this not better done at Wikidata, which already has Mesh IDs? --Izno (talk) 12:20, 20 April 2017 (UTC)Reply[reply]
  • Oppose We do not usually need this degree of specialization. There is no virtue in overly narrow categories-. For many of the MESH categroies, the WP search function will work quite well. Categoriews also normally use generally accessible terminology,; MESH is specialized. Our articles are intended for general readers. DGG ( talk ) 14:09, 20 April 2017 (UTC)Reply[reply]
  • Oppose The human touch works well for creating needed categories. We do not need more elaboration in the form of over-specialization and creating overly narrow, contra-intuitive categories. If anything, the current tree needs pruning. Dlohcierekim 18:11, 20 April 2017 (UTC)Reply[reply]
  • Oppose Please don't add them all, as it will result in many empty or useless categories, that will just have to be deleted. I think some human nouse will be required evaluate which ones are useful , and where they should be added into the already existing category tree. Graeme Bartlett (talk) 08:17, 21 April 2017 (UTC)Reply[reply]
  • Oppose we have already had very poor experiences using alternate category and tree categorisation systems in the anatomy space. Problems that we encounter are trying to morph our existing content to match systems that don't match our unique scope, style or notability or requirements. The fact is, we are a unique encyclopedia and we do not need to duplicate other categorisation systems. Wikidata would be a more appropriate mechanism to deploy MeSH data, and then link that to articles.--Tom (LT) (talk) 11:29, 22 April 2017 (UTC)Reply[reply]
  • Oppose for now The proposal doesn't seem to have given enough thought to the issues (and is not signed btw). This certainly would not work for categories without a huge amount of human help, and who would do that? Seems much more suited to Wikidata. Johnbod (talk) 15:19, 1 May 2017 (UTC)Reply[reply]


How will the bot identify which categories to give to each article? Chiswick Chap (talk) 21:37, 18 April 2017 (UTC)Reply[reply]

The bot will be used to create the categories. Categorizing article I will then do manually. Do you have a better idea to do this using a bot? --Brainist (talk) 21:43, 18 April 2017 (UTC)Reply[reply]
Some articles already have a MeSH code, so they could be classified automatically by a bot. But there are already 2,600 categories and over 30,000 articles in the scope of WikiProject medicine. Is it actually your intention to make use of all 55,000 MeSH descriptors and manually assign each of the 30,000 articles into categories based on those descriptors? --RexxS (talk) 21:54, 18 April 2017 (UTC)Reply[reply]
@User:RexxS, I think the hardest part is creating 55,000 new categories. This must be done using a bot. It is ok if I do the categorization part manually, even if it takes a while.--Brainist (talk) 23:03, 18 April 2017 (UTC)Reply[reply]
What is the benefit? Doc James (talk · contribs · email) 22:28, 18 April 2017 (UTC)Reply[reply]
@User:Doc James, the same benefits of categorization in general. It will ease access to medical articles from categories. For example without Category:Amygdala, it would be hard to find all Wikipedia articles related to amygdala's anatomy, histology, physiology, diseases, and surgeries. And as I mentioned before, It will reveal the shortage in medical content. I noticed that many MeSH descriptors don't have a corresponding Wikipedia article. --Brainist (talk) 23:03, 18 April 2017 (UTC)Reply[reply]
Okay sounds reasonable. This will also incorporate articles related to anatomy, molecular and cell biology, and physiology etc. Doc James (talk · contribs · email) 23:27, 18 April 2017 (UTC)Reply[reply]

Is the source for this bot available so we can confirm it won't break everything? Also, how will the task be separated between the bot and AWB? PriceDL (talk) 17:23, 19 April 2017 (UTC)Reply[reply]

@PriceDL: using the CSV loader plugin, the column header:
Bot using AWB tool in CSVLoader plugin
for example:
  • I should mention than unsued categoriwes can be speedily deleted; categories
##Category:Cavernous Sinus##$$##D002426##$$##An irregularly shaped venous space in the dura mater at either side of the sphenoid bone.##$$##A07.231.908.224.334##

will be used, with the general text:

template:empty category
template:MeSH category|##Unique_ID## 
template:cat main
MeSH definition: ##Description##
category:Medical Subject Headings|##treenumb##

The AWB tool is semi-automated, namely it can find the column headers within a text and replace it, but it needs a user to click the save button for each category. In order to avoid clicking the save button 50,000+ times manually, I want a bot with AWB permission to automatically click the save button (see the picture). After creating all categories, the bot will use very simple pywikibot scripts to categorize them inside each other and form the MeSH tree.--Brainist (talk) 04:07, 20 April 2017 (UTC)Reply[reply]

  • I should mention that it is part of general Deletion Policy for empty categories to be speedy deleted. Categories containing only very few items are routinely brought for discussion at WP:CFD, and almost always upmerged or removed. There is also a formal procedure for renaming categories. If anyone should add several tens of thousands of empty or almost empty categories, I expect it will be considered unconstructive. DGG ( talk ) 14:17, 20 April 2017 (UTC)Reply[reply]

Moving, copying, and editing meta links to other languages

There are many cases when an article on another language is linked only because its what best fit at that time but being not the best option, as Wikipedia is a dynamic encyclopedia creation of better suitable article could occur further in time but as I know meta links are not much undoable and then articles are mostly linked to other idioms what better suited at the time of its creation. Incredibly the fastest (if not the only) way of doing this is moving that article to other whit the name of the desired new article being linked, for then cut its content, place there the new article, save it and go back to the original article name where now is a redirection, edit its content removing the redirediction and placing there the original content, voila there is the old article not linked and the new article does be linked but this way as is reinventing the wheel is also the worst practice. Isnt there a way to deal with this? --Neurorebel (talk) 23:26, 1 May 2017 (UTC)Reply[reply]

Adding an 'infrared flash photography' page to the wiki

After reviewing your 'Pages in category “Photography by genre”' I see you are missing a listing for infrared photography and infrared flash photography on the list. I gave up wasting my time with the Wiki after you deleted 200 of my photos because I would not allow commercial use. But if you want to add an infrared flash photography page you can take what you like from my photos here:

Just no commercial use of the photos, only educational and editorial use. The link also discusses the history of infrared flash photography which I am a specialist and world leader in.

Best Regards,


We already have Category:Infrared imaging whereas Genre I would think refers to something else rather than the recording medium, method etc., itself. Yet it is worth considering a fresh look at these cats.Aspro (talk) 16:02, 27 April 2017 (UTC)Reply[reply]
Because Wikimedia Commons is the main host for images, the development of categories should be mostly there. I have uploaded images myself in the infrared category, but not used flash. Instead most are illuminated by sunlight. Anyway as soon as there is one image uploaded in that category, you are welcome to create the category. The structure on commons is untidy. There its in category "Photography by style". Subcats could be thermal infrared images, astronomical images, naturally lit NIR, artificially lit NIR (eg for animals so they are not disturbed), and you can add flash, but I see no images like that now. On commons images should have an educational use, and be free. Here images should at least be useful. Graeme Bartlett (talk) 23:29, 2 May 2017 (UTC)Reply[reply]

On-wiki requests for oversight

Looking for an unrelated thread, I came across the "Where can I request visibility of edits to be removed?" section of Wikipedia:Help desk/Archives/2016 December 14, and a new-for-me idea came to mind. What if we had a submit-requests-here page for requesting oversight, monitored by a bot that would (1) automatically oversight the request itself immediately after it was made, and (2) add it to a fully protected page that lists not-yet-handled requests, so that the oversighters could see what's waiting to be resolved? Benefits: simpler request process (it's all on-wiki; no email needed), at a central location rather than requiring everyone to make requests privately (of course, this wouldn't be a reason to tell people not to make private requests), it's all in the history of in that central location (so the oversighters can see who's making requests, if necessary) rather than being done on oversighters' talk pages and via email, it's secure thanks to the watchful bot (if you're not an oversighter, you can't see anything about the request), and if you game the system by submitting bad requests, the oversighter can reject the request just by removing the entry from the log. Downsides: it depends on the bot constantly running, and it requires a tiny bit of extra work from oversighters, as they have to remove the entry from the log as well as doing the oversight. I don't see these downsides as significant, compared to the benefits. Your opinions? As soon as I hit "save", I'm going to email the oversight list with a request for opinion from the oversighters. Nyttend (talk) 01:38, 1 May 2017 (UTC)Reply[reply]

Only problem I could see with this is that it essentially gives anyone the ability to redact history entries. A troll (or group of trolls) can force the redaction of hundreds of pages before they were stopped. The cleanup could potentially be immense.

I would like to know some stats before I comment further than that. How long does it take for normal oversight requests to be handled? I frequent IRC and I can usually find an oversighter immediately when necessary as one is usually available 24/7. How about the turn-around time for the email queue? --Majora (talk) 01:43, 1 May 2017 (UTC)Reply[reply]

I see no problem with current oversight process. I've deleted some pages requiring oversight and contacted the oversighters via e-mail. I was very pleased with the timeliness of their response-- almost immediate. Oversight requires human clue and sensitivity. Potential problems from making it bot related could be enormous and increase risk of exposure of sensitive material. Dlohcierekim 01:56, 1 May 2017 (UTC)Reply[reply]

The potential for abuse is startling. I have used oversight several times (by email) and the response has always been very fast. Only experienced editors understand what needs oversight and how to get that done, and such editors generally have email enabled. Other editors generally post somewhere like AN or ANI despite the edit notices telling them not to. Johnuniq (talk) 02:33, 1 May 2017 (UTC)Reply[reply]

  • My concern with this would be that often oversight requires multiple revisions, and from personal experience dealing with rev del and oversight for a variety of reasons, there are a limited number of admins who know how to handle revision deletion requests with the correct number of revisions (oftentimes an admin will either over rev del or under rev del). This makes me not like the idea of a bot handleing it automatically. The times I have requested oversight, the oversighters have always gotten the correct number of revisions right. Basically, if some of our admins have issues getting rev del correct for less sensitive matters, I don't think your average user is going to be able to list the revision numbers needed to the precision needed for a bot to act upon it. The email based system works best IMO. TonyBallioni (talk) 02:41, 1 May 2017 (UTC)Reply[reply]

I'm very confused why people find this problematic on abuse or technical grounds. How would someone be able to get something oversighted improperly, and why do we care about a bot's ability to handle multiple revisions? I'm suggesting that the bot oversights the request (so that we avoid drawing undue attention to the page with problematic information) but doesn't touch anything else. The bot would start with the workflow of a sandbox-clearing bot (when the page is edited, wait a period of time and then restore it to a specified condition) with a much shorter delay before clearing (30 seconds? 1 minute?), but unlike the sandbox-clearing bot, it would then oversight the edit that made the request and add a link to the log page saying basically "Oversighters, here's a request that you need to examine". An oversighter would look at the request, remove it from the log, and either do something about the request (if it warranted action) or ignore it (if it didn't). Nyttend (talk) 03:13, 1 May 2017 (UTC)Reply[reply]

@Nyttend: I misread your statement as saying that the bot would oversight the requested revisions. My bad. I've struck my comment. I don't see any issue with the current system, but after your explanation I don't see any reason to not have your proposal. TonyBallioni (talk) 03:25, 1 May 2017 (UTC)Reply[reply]
My mistake as well, Nyttend. I misunderstood the proposal. I'm still not completely convinced this would be necessary though. And even having it onwiki at all still presents problems with visibility. I'd still like to know the turn-around time for currently available oversight requests. If it is already reasonably short, this may not be that necessary. --Majora (talk) 03:37, 1 May 2017 (UTC)Reply[reply]

Logistical point: emailing oversight turns your email into an OTRS ticket. Normally those are handled by one person. There's no way for non-oversighters to directly email the oversight discussion list, so the usual way is to email the functionaries list instead, which I just did. On the substantive issue, this seems to add a lot of moving parts for not a lot of obvious advantage. In general, simple OS requests are handled pretty quickly. If a request sits around for a while, it's probably because it's not obvious that suppression is the best option. Is there a problem with the current system that you think needs solving? Opabinia regalis (talk) 03:51, 1 May 2017 (UTC)Reply[reply]

  • I don't see any advantage to this proposal, and considering the potential of an offline bot leaving the requests sitting in the open, a lot of disadvantage. The current system isn't perfect, but it serves its purpose. ​—DoRD (talk)​ 12:32, 1 May 2017 (UTC)Reply[reply]
  • My first thought is the Streisand effect. It would be trivially easy for someone to set up a bot to scrape the requests page and then the linked article or edit before it could be examined by an oversighter (we're quick but we're not bots) and copy that to some off-wiki venue for later perusal of personal details, etc. I think this strongly outweighs any potential benefits this might bring (and I'm not really convinced there are any significant benefits), so I'm firmly opposed. Thryduulf (talk) 13:58, 1 May 2017 (UTC)Reply[reply]
  • Per Thryduulf; if we can create a bot that watches the page and oversights it right away, someone else can create a bot that watches the page and makes a copy of the page before it's oversighted. Combine that with the possibility of the bot going down, and with the lack of evidence that there's a problem with the way we handle things now. We've chosen not to rely on bots to protect images on the main page; it seems unwise to rely on them for oversight requests. --Floquenbeam (talk) 14:53, 1 May 2017 (UTC)Reply[reply]
  • There's a lot of benefit to having dialogue with the submitters of requests. Ignoring the biggest hurdle (an offline bot), I think the second biggest problem with this idea is how much harder it would make it to communicate. Sometimes people email us back to say we missed something when we thought we'd finished oversighting. Sometimes we have to ask for further information. And we often have to respond to say that the request doesn't meet the criteria. If the submitter doesn't have email enabled or doesn't have an account at all, how would we contact them? Knowing their user name or their IP would be useless. Keeping all this in a ticket and corresponding via email is helpful, or by IRC. And the third stumbling block, I think, is that if the request is immediately oversighted, then there's little confirmation for the submitter that the request has gone through, or if they formatted it correctly. It's not like being able to confirm that you definitely sent an email to the correct email address. If suppression wasn't dealt with immediately, or within hours, or within days, the user would probably end up emailing anyway. And if it wasn't dealt with because it didn't meet the criteria, for example, and not because of backlog, then we double the work in that case by another oversighter having to check the same content for suitability. Julia\talk 15:02, 1 May 2017 (UTC)Reply[reply]
  • This long-term member of the suppression team is recoiling in horror at the very idea. This strikes me as a clunky, overly complicated error prone alternate process that offers little to no benefit over the current method. Email addresses are literaly free and unlimited, so that is not a real hurdle to reporting. Although using Wikiepdia's internal email system is the easiest way, it is not required and we get mail all the time from outside of the internal system. There's just too much risk here and not enough benefit. Beeblebrox (talk) 02:18, 2 May 2017 (UTC)Reply[reply]

Sorry, everyone; I didn't realise that this would be deemed such a big risk, and I was totally unaware of the importance of dialogue between oversighter and requester — I've only ever made a few requests, and as far as I remember, they always got accepted with just a "thank you", so I figured all requests were answered with "thanks, we got it" or "thanks, but this doesn't qualify". Nyttend (talk) 16:55, 3 May 2017 (UTC)Reply[reply]

No problem! It's always good to come up with ideas, even if they don't work out. (And I was totally bewildered by oversight and everything involved for, oh, like my first 4 months on the job. Or maybe more. So I get it.) Julia\talk 21:08, 3 May 2017 (UTC)Reply[reply]

Contribs link for signatures

 – by OP. ―Mandruss  16:47, 1 May 2017 (UTC)Reply[reply]

Hello, I would like to point to this discussion about a proposal of mine to also have a contributions link automatically created when adding one's signature. I think this could be a quite useful improvement, as we already have user page, talk and contribs links for all edits listed in revision histories. What do you think about that?--Hubon (talk) 16:22, 29 April 2017 (UTC)Reply[reply]

Might be a good idea. Maybe do this: [[User:Example|Example]] ([[User talk:Example|talk]] | [[Special:Contributions/Example|contributions]]). It looks like this: Example (talk | contributions). The only real problem I can envision is length. RileyBugz会話投稿記録 17:19, 29 April 2017 (UTC)Reply[reply]
This is already done for IP addresses. At one time, only usernames were linked in signatures so it is possible we could extend to include contributions too. I do agree though, that's a lot of links. Aiken D 17:21, 29 April 2017 (UTC)Reply[reply]
Take a look at Wikipedia:Tools/Navigation popups. If you enable this and hover over a user signature on a talk page or history or watchlist, you get a pop-up displaying all sorts of information about a user including a link to their contributions. StarryGrandma (talk) 00:32, 30 April 2017 (UTC)Reply[reply]
This is already done for IP addresses. Apparently not. ---> (talk) 01:08, 30 April 2017 (UTC)Reply[reply]
It is in place of the user page. RileyBugz会話投稿記録 01:19, 30 April 2017 (UTC)Reply[reply]
I sit corrected, but it's still not equivalent to what is being proposed. (talk) 01:21, 30 April 2017 (UTC)Reply[reply]
In my opinion this shouldn't be done system-wide, although any editor can choose to do it with a custom signature. It took me a few days to learn how to get to contribs quickly enough, via the page history of the user page or the user-talk page, or any other page history where the editor has edited recently. It takes 3 or 4 clicks and 5 or 10 seconds in most cases. Granted, we could say the same for the talk link, but it's already in place and thousands of editors are used to having it there (and, unlike contribs, use of user talk is a fundamental part of good editing). In any case, such a dramatic change will not be made without clear consensus in an RfC here, so we're wasting time in this discussion. If this is just "testing the water", that's more appropriately done at WP:VPI. ―Mandruss  01:40, 30 April 2017 (UTC)Reply[reply]
@Hubon: I have now belatedly read the Help desk discussion, now archived here. A couple of points:
1. You have multiple times argued that the presence of contribs links in page histories justifies them in signatures. In my view that's an argument against. As I said above, the contribs are accessed easily enough via any of a number of page histories.
2. The change is not without a cost. Except for RileyBugz's brief comment above - The only real problem I can envision is length. - the downside of this change hasn't been stated in either discussion, probably because it should be obvious. It would significantly increase the length of the code for every default signature, thus using more of the edit window for code "overhead" and less for comments. By my count the number of characters added would be (38 plus the length of the username). If we wanted the spaces on either side of the vertical bar to be non-breaking spaces ( ), that becomes (48 plus the length of the username). It would also add 11 characters to every default signature on the rendered page. (These counts assume that it would be Example (talk | contribs), consistent with page histories, not Example (talk | contributions) as shown above). And finally, the change would also result in more contribs links in custom signatures, as many of those editors would be reluctant to provide less functionality than the default. ―Mandruss  00:33, 1 May 2017 (UTC)Reply[reply]
@Mandruss: Thanks for getting involved! Now, if you ask me, I'd definitely still say it would be worthwhile – since the contribs link is in any case just as significant as the user page or user talk link, if not even more meaningful to immediately find out about the user's editing behavior and experience, their areas of interest, their activity in general etc. And as far as I'm concerned, we don't need spaces next to the middle bar at all. Though the others might take a different view... Best regards--Hubon (talk) 01:13, 1 May 2017 (UTC)Reply[reply]
@Hubon: Ok, well I think it's time for you to go to RfC or drop the issue (remember, there is a strong inertial force working against you). You would need to clearly lay out the options (I see 3 options plus "no change") and the precise costs of each option. If you want some help with that, hit me up on my talk page and we can develop it in one of my sandboxes. ―Mandruss  01:34, 1 May 2017 (UTC)Reply[reply]
  • This isn't going to fly, sorry. If it were compulsory it might be worthwhile because then there would be a uniform approach to how signatures work. However, compulsion will not work regarding signatures (see a couple of threads near the bottom of WT:Signatures as examples where even timestamps are being abused). Adding to clutter on talk pages simply to allow people to find someone's contributions in one click rather than two is pointless. As mentioned, anyone can add a contribs link to their own signature if they think their contributions warrant highlighting. Johnuniq (talk) 02:28, 1 May 2017 (UTC)Reply[reply]

In discussion at my TP, it came to light that contribs are already just two clicks away from the signature, via the sidebar of the user page. (In hindsight, Johnuniq may have hinted at this above.) Thus, this change would save only one click. With that information, the OP said they withdraw the proposal. I agree with them that an optional tool to add these links only for oneself (at rendering time) would be nice, if there is an editor with the skills, the time, and the inclination. Marked as resolved. ―Mandruss  16:47, 1 May 2017 (UTC)Reply[reply]

I added a contribs link to my own signature some time ago, and I know other users have links in their own custom sigs. I don't know if anyone finds it useful. I think *I* find it useful from time to time. Ivanvector (Talk/Edits) 23:58, 3 May 2017 (UTC)Reply[reply]

Tentative solution to promotional articles

We all know all the bearing the community does about them but promotional articles are not a problem if they are neutral enough, the real problem is the over-existence of them over other more sensitive to Wikipedias aims, then a way of balancing this could be instating the exigence that for every article about a company, brand or service, relevant or not that itscreator to before create or improve sanother more sensitive article like one of which creation or improvement is being reclaimed. This proposal being put on practice will equiparate every article about a company with other article describing another area of knowledge, being this one good article for every promotional one.

On the favor of my proposal are total neutrality and balance.

This does not mean more promotional articles but equal or less quantity of them and much more non promotional oriented ones.

--Neurorebel (talk) 23:43, 1 May 2017 (UTC)Reply[reply]
I'm really trying to parse out what exactly you are proposing here, but you haven't made it easy. Are you suggesting a quid pro quo system of some sort? You may want read my essay on how to propose policy changes before proceeding with this, as it is I wouldn't expect much of a reply because your proposal is terribly unclear. Beeblebrox (talk) 02:12, 2 May 2017 (UTC)Reply[reply]
@Neurorebel:, Like Beeblebrox, I don't really know what you are trying to say here, but one thing is reasonably clear and I will respond to that. You say but promotional articles are not a problem if they are neutral enough, but that is incorrect. Promotional articles are by definition NOT neutral. If they were neutral they would not be considered promotional. I suspect that the rest of your proposal rests on the premise that promotional and neutral are compatible, so the argument fails. Cheers, • • • Peter (Southwood) (talk): 12:11, 2 May 2017 (UTC)Reply[reply]
@Beeblebrox: YOu have perfectly resumed what i wanted to tell: Quid pro quo for articles describing brands, companies or any other profit activity, and which (for sure) already accomplish with neutrality standards.--Neurorebel (talk) 20:22, 2 May 2017 (UTC)Reply[reply]
@Pbsouthwood: Despite of my bad english and the quick redaction i think the proposal would be clear to understand at a glance if you dont fringe the terms that much, I have used another more extensive definition of promotional article and its every article that in some way involves a commercial brand or a company or any kind of campaign.
I will clarify with an example: lets suppose that someone wants to create an article about a music group hence according to my proposal that person would have to apply to two conditions: 1) Neutrality (that already it is) 2) Write or improve one article that is requested by the community before creating his desired one (this is the part of my proposal), for the sake of the example Hutchison effect .
We can resume this idea as "only good doers can involve on sensitive articles in the community".
This additional requirement would discourage any publicist that feels that his company can get beneficed even through accomplishing with neutrality standards. --Neurorebel (talk) 19:50, 2 May 2017 (UTC)Reply[reply]
Well, you've made it slightly more clear that it is a proposal for a quid pro quo system, which I would give a 0% chance of being enacted. Even if you somehow convinced the community here that this was desirable, I'm pretty sure the Wikimedia Foundation would not allow it. Many of our best articles started in pretty poor shape, created by new users with no clue. Beeblebrox (talk) 20:21, 2 May 2017 (UTC)Reply[reply]
Neurorebel, Sorry, that was the only part of your proposal that I could understand at the time. I responded as appeared appropriate at the time. It is up to you to make yourself understood, not for us to puzzle out what you might possibly mean. There are just too many ways we could get it wrong. Cheers, • • • Peter (Southwood) (talk): 05:48, 3 May 2017 (UTC)Reply[reply]
@Beeblebox: You gave me term, thanks, Better that that "poor article" be a requested one, that another one more about Justin Beaver, or what is worse that brand new hotel chain looking for free advertisement.--Neurorebel (talk) 20:37, 2 May 2017 (UTC)Reply[reply]
There is a small nod to this idea, in that new users have to have made ten edits and wait four days before creating a new article. New users can get away with making none of the ten edits in mainspace, of course, but I'm sure a number of them spend the four days improving articles. IMO it is more sensible to encourage new users to improve the existing articles than to expect them to create new ones on subjects chosen by someone else.—Anne Delong (talk) 02:09, 3 May 2017 (UTC)Reply[reply]
Anne Delong. Do you know if there are any stats on what the 10 edits usually involve? • • • Peter (Southwood) (talk): 05:48, 3 May 2017 (UTC)Reply[reply]
Sorry, Pbsouthwood, I don't know.—Anne Delong (talk) 12:25, 3 May 2017 (UTC)Reply[reply]
Neurorebel. I see no useful purpose in putting an additional obstacle before a new editor who may have good contributions in mind but no interest or knowledge relating to the list of article requests. People edit and create articles on subjects that interest them and about which they generally have some knowledge. • • • Peter (Southwood) (talk): 05:48, 3 May 2017 (UTC)Reply[reply]
@Pbsouthwood: No problem against that last, I must make me understand here, Does all that stuff about the new users come from the assumption that new user tend to create promotional articles? if not I cant figure out from where it comes besides that ten editions rules that Anne Delong mentioned, my focus is on potentially promotional articles and not on the poor new user that yet have a lot of impediments. --Neurorebel (talk) 06:01, 3 May 2017 (UTC)Reply[reply]
(ec) Neurorebel. To get back to your original proposal: There is no contravention of terms of use to write an article that in some way involves a commercial brand or a company or any kind of campaign. provided that the subject is notable and coverage is encyclopedic, i.e.: neutral, accurate, verifiable, due, etc. If an entity gains in some way by having an encyclopaedic article about it, that is a side effect which is not contrary to the purpose of Wikipedia. • • • Peter (Southwood) (talk): 06:09, 3 May 2017 (UTC)Reply[reply]
Pbsouthwood then that is the part of the terms of use that we should change since hosting overnumbered articles that talk about a company should be contrary to the purpose of Wikipedia.--Neurorebel (talk) 06:21, 3 May 2017 (UTC)Reply[reply]
I have done a lot of work at WP:AFC, where many new users write their first article, and there certainly is an overweight of such drafts that are promotional and company/organization-related. If two subjects are equally notable, but the first is about a general scientific or cultural topic and the second is about a subject through which someone can make money, chances are much greater that there will be single-purpose users, new or not, making sure that there is an article about the second topic. Also, a lot of our other editors' time is taken up in removing the promotional aspects of these articles, when they could be off improving articles about science, geography or culture. However, I think the best way to rebalance is through encouragement, not coercion. For example, if a new editor is waiting for a review of a draft about a restaurant, he could be approached to improve an article about food, or cooking equipment, or a cooking show, or about the town in which the restaurant is located.—Anne Delong (talk) 12:25, 3 May 2017 (UTC)Reply[reply]
{U|:Anne Delong} It is the posiblity that trusted editors get counted more than untrusted editors, eg. changing the system of number of editions contabilization, I agree that something should be done, however this is a laying problem ¿should Wikipedia cease of its neutrality on favour of equilibrium and hence neutrality of its global content? ¿Or should global content of Wikipedia at last not be neutral on the act of reflexing the polarization of its community and by transitiveness, the society? — Preceding unsigned comment added by Neurorebel (talkcontribs) 23:57, 4 May 2017 (UTC)Reply[reply]

Use of translation tool by unconfirmed eduitors

[Here|] it was resolved that its not possible. I dont see much sense about that decission, crap can be copy/pasted or created without any tool, if it is to much work to remove them, then let a bot do it, thats it searching for pages that are not in English and should not be so much intuitive that a bot cant do it. Translation tool is lot of useful if well employed, if has amazing good template translation and link transposition is not that bad. Also there should be a way that an unconfirmed editor could benefit from it like submitting that article to approval. At least they could warn the user before doing the translation and make him save time. --Neurorebel (talk) 00:25, 2 May 2017 (UTC)Reply[reply]

Two things:
  • Again, per the thread at the help desk, you must be in the extended confirmed group, not the much lower bar of a confirmed account
  • Forgive my bluntness, but the level of English in your comments here suggests that the restriction is working as intended. Beeblebrox (talk) 02:27, 2 May 2017 (UTC)Reply[reply]
I certainly wouldn't want a bot to translate articles for Wikipedia. ANd while "crap can be copy/pasted or created without any tool", the restriction of using this tool d'does' prevent many cases of good-faith creation of junk. עוד מישהו Od Mishehu 11:04, 2 May 2017 (UTC)Reply[reply]
@Beeblebrox: Please judge me by my articles and not by my discussions. Im trying to share ideas here, not dispatching lessons of good English. Let us leave standards at the main namespace. --Neurorebel (talk) 20:09, 2 May 2017 (UTC)Reply[reply]
Already, @Neurobel:, I'll judge you by your articles: I've looked them over, and your command of English is not sufficient to be writing and editing articles on English Wikipedia. You really should stop, and edit the Wikipedia of your native tongue, because you simply cannot write coherently in English. I've corrected some of what you've written, but other editors should look over your stuff as well, considering how long you've been editing here. Beyond My Ken (talk) 03:39, 5 May 2017 (UTC)Reply[reply]
@Mishehu: Reading comprehension: The bot that i mention is for search and destroy articles written on other languages that are not English since administrators are too busy to remove them by hand, not for plain translating articles, that what you say is an abomination, have little more faith on me.--Neurorebel (talk) 20:09, 2 May 2017 (UTC)Reply[reply]
Od Mishehu, a typo prevented you from getting pinged in the edit just above mine. Nyttend (talk) 17:05, 3 May 2017 (UTC)Reply[reply]

Project participants bot

A lot of WikiProjects have a participants page where people can sign up and say they are a member; however, those pages tend to get stale over time. I'd like to see a bot analyze the contributions of users who edit pages under a project banner and then give out a list of those editors who are, for example, in the top 25th percentile for activity. I would think that it should only run once a month, similar to how Popular Pages worked (or is it back again)? –Fredddie 21:16, 27 April 2017 (UTC)Reply[reply]

@Fredddie: see Wikipedia:Bot requests to request someone build a bot. — xaosflux Talk 00:12, 28 April 2017 (UTC)Reply[reply]
OK, but I was hoping I'd get some input on whether or not it's a good idea. –Fredddie 10:47, 28 April 2017 (UTC)Reply[reply]

That would be useful for lots of other things, like asking for help to someone that is not active or another lot of functions that people enrole just once. Whatever list of inactive members is annoying --Neurorebel (talk) 23:06, 1 May 2017 (UTC)Reply[reply]

You may be interested in Wikipedia:WikiProject Directory/All, which lists the participants (people who edit the WikiProject's talk page) and editors (people who edit the articles in its scope, even if they don't know or care about the group's existence).
If you are trying to make a list of who's edit the identified articles the most times, then it's a bit more complicated, but WP:MED does this every year. WhatamIdoing (talk) 06:34, 8 May 2017 (UTC)Reply[reply]

Continued at meta:Wikimedia Forum#Updating Wikipedia Logo

This may not be the best place for this topic, so feel free to point me elsewhere. I feel it's time to update the branding of Wikipedia. I understand this is inherently a subjective topic, but I feel the current logo a bit dated. Unlike Wikisource, Wikidata, and even the fun Wikimania logos, Wikipedia is by far the "busiest." It's also one that isn't terribly recognizable when seen from a distance, which is typically a requirement for a good logo. I know I'm going to get a lot of "don't fix it, if it's not broken". Also, I understand we're not in the business of selling anything, so we don't need to "attract" people. But I would argue that a refresh of the brand would do a lot for our community and the community we serve to feel more at home. Any feedback would be appreciated. Drewmutt (^ᴥ^) talk 21:38, 3 May 2017 (UTC)Reply[reply]

I'd agree to do some refreshment of the logo, but it should be taken with extreme care. Wikipedia logo may not be recognizable "from a distance", but it is terribly well-known and recognizable "in general", having appeared in traditional mass-media (TV, magazines) around the world; few online-only organizations get that much exposure in off-digital communication channels. Also, the missing jigsaw piece is a staple. The other Wikimedia logos are more generic, with no simple details as distinctive as this one.
Maybe removing the shadow gradient and adding contrast to the jigsaw edges would simplify its shape, making it more proffessional-looking. But more drastic changes should be avoided; any changes to the logo should make it appear "just like the same old one, just cleaner". I would also try to avoid merely turning it into its "flat" version; that would age really quickly. Diego (talk) 22:23, 3 May 2017 (UTC)Reply[reply]
Probably something best brought up at Meta? FACE WITH TEARS OF JOY [u+1F602] 02:05, 4 May 2017 (UTC)Reply[reply]
I'd like the logo to be animated as a constantly turning version of itself. bd2412 T 02:28, 4 May 2017 (UTC)Reply[reply]
@BD2412: File:Wikipedia logo puzzle globe spins horizontally and vertically, revealing the contents of all of its puzzle pieces (4K resolution) (VP9).webm? --Majora (talk) 02:45, 4 May 2017 (UTC)Reply[reply]
That would work. Is it technically feasible to have that default to being the object in the corner of the page? bd2412 T 02:55, 4 May 2017 (UTC)Reply[reply]
It doesn't look like the software can handle moving logos unfortunately. I just tried it out with a CSS switch (you can do this for any image by the way, just replace the URL with the direct upload link). It will work for the static image but not for the moving one. It just shows a blank space when the moving image is placed there. Perhaps it is just me, see if you see anything different.

If you want to try it out put the following into your personal CSS (note you do not have to actually save, previewing will activate the script)

CSS code to replace logo
#p-logo a, #p-logo a:hover {
    background: url( 35% 50% no-repeat !important;

--Majora (talk) 03:04, 4 May 2017 (UTC)Reply[reply]

I'll give it a whirl. bd2412 T 03:21, 4 May 2017 (UTC)Reply[reply]
  • While I don't oppose this idea, I would note that the Wikipedia globe logo is, unlike everything else here, copyrighted by the WMF. WP:CONEXCEPT would seem to apply. They might be open to the idea, but they would have to be part of the conversation unless we're talking about a completely different logo that does not employ any elements of the current one, and even then they probably could block it if they didn't like it. Beeblebrox (talk) 19:31, 4 May 2017 (UTC)Reply[reply]
Wait, doesn't the logo appearing on this site mean it is required to comply with the site license, which allows derivative works? Ivanvector (Talk/Edits) 19:33, 4 May 2017 (UTC)Reply[reply]
We don't have a site license. We have a text content license, image licenses, the MediaWiki software license (and each and every extensions' license). But not overall blanket license. —TheDJ (talkcontribs) 21:28, 4 May 2017 (UTC)Reply[reply]
Just a note here TheDJ. The logo is under a free license but it is also trademarked. There is a pretty extensive wmf:Trademark policy on the matter along with wmf:Visual identity guidelines that have to be followed if anything is going to change. Those two things do add a bit of constraint to any proposals of this nature. --Majora (talk) 22:07, 4 May 2017 (UTC)Reply[reply]
Plus this needs to be discussed on Meta because it will affect all language Wikipedias, unless we for some reason want a different logo here than every other language Wikipedia. Sam Walton (talk) 22:12, 4 May 2017 (UTC)Reply[reply]
Keep the current logo for brand recognition but create a system like Google where the displayed logo on Enwiki can change day to day (or per week). It should remain recognizable, but has some new flare or variation (like Google logo changes). Users can submit their version and the community picks the next weeks version like DYK. -- GreenC 19:53, 4 May 2017 (UTC)Reply[reply]
Whats stopping them ? Let's get some perspective. Google employs 10-15 people who work let's say 240 days a year at say 50 hours a week... Let's go conservative 12*240*40 == 115000 hours a year. Now sure, their doodles are hella elaborated, but I would be surprised if we can find more than 1 person interested in spending 3 hours a week for 1 doodle, more than a couple of times a year. We can't even keep the WP:Signpost running... I do agree it would be cool though :) —TheDJ (talkcontribs) 21:26, 4 May 2017 (UTC)Reply[reply]
  • Okay, I'm gonna be honest. I'm a pretty young editor, and Wikipedia's been around just about my whole life. I've seen it on computer screens around my house since I can't remember when. So, personally, the Wiki logo as it is holds a pretty nolstalgic status. I'm sure it does for a lot of other people, too. I'd say leave it. Best, Liam Gibson (talk) 22:19, 4 May 2017 (UTC)Reply[reply]

Hey guys, thanks for all the feedback so far. I'm not a fan of the spinning logo, in fact, I think it kinda exacerbates the issue. I get what you guys are saying regarding brand recognition, but I would argue that the "WikipediA" is typically more associated in people's minds than the puzzle globe. As a compromise, what do you guys think about simply using the W? Drewmutt (^ᴥ^) talk 22:57, 4 May 2017 (UTC)Reply[reply]

Is that even available for trademark? Can you trademark a single letter of the alphabet in a specific font? The letter "W", obviously, has a significant amount of prior use (even as far as other websites are concerned), and I wonder whether a specific ordinary font is sufficient for the distinctiveness test. Note that copyright isn't an issue, since WMF released the logos under a free license (probably cc-by-sa) some months ago. Nyttend (talk) 23:35, 4 May 2017 (UTC)Reply[reply]
"Can you trademark a single letter of the alphabet in a specific font?" Wordpress seem to have managed to use a W as a logo, but I guess that's a reason that Wikipedia shouldn't - so we don't get confused with Wordpress. I'm in the "ain't broke, don't fix" camp myself.Chuntuk (talk) 14:45, 8 May 2017 (UTC)Reply[reply]
Plain text in a specific font can't be trademarked in the United States (not sure about other jurisdictions). From a practical perspective (not that the law always takes this into account), it would be unduly burdensome, for example, to avoid using the letter "W" in contexts where there may be brand confusion with Wikipedia. If other stylistic elements are added, then this combination can be trademarked. (Whether or not the Wordpress logo has sufficiently modified the "W" so that its trademark would stand up in court, I do not know.) isaacl (talk) 16:08, 8 May 2017 (UTC)Reply[reply]
  • I for one don't want to get rid of the puzzle globe. It's great. Andrevan@ 23:12, 4 May 2017 (UTC)Reply[reply]
It's a big "W" I tells ya. Those of us of a certain age will remember this. If it ain't broke don't fix it. The globe is just fine. I see no reason - compelling or otherwise - to change it. Samwalton9 is correct any change needs to be discussed on Meta. MarnetteD|Talk 23:47, 4 May 2017 (UTC)Reply[reply]
  • @Drewmutt: Why are you trying to discuss a "compromise"? Did you even read the feedback? We'd have to consult with the Foundation to clarify as to whether we'd acutally be allowed to just change the trademarked logo, because if they're not on board, any such proposal is DOA. Secondly, even if they approved it, this is just one branch of Wikipedia. This would not be the place for such a proposal, as has been pointed out. Meta would be the place for a proposal affecting a wide spectrum of Wikipedias. Slow your roll. I hate to break it to you, but your proposal is an extreme long shot. Swarm 06:59, 5 May 2017 (UTC)Reply[reply]
@Swarm: Thanks for the honesty, I did read the feedback and referred to it specifically, and yep, I'm going to move this to meta and I already reached out to the WMF folks. I know it's a long shot, but that's what Village Pump is about, throw an idea out, and see if there's traction. Everything can be improved, and thankfully we had that mentality in 2006. Simply, I feel the logo a bit dated, and I think it could benefit from a facial. Drewmutt (^ᴥ^) talk 22:45, 5 May 2017 (UTC)Reply[reply]
  • Note - see also the WMF draft annual plan which includes a focus on branding and identity. Risker (talk) 05:51, 7 May 2017 (UTC)Reply[reply]
  • I think it is fine as is. I would be adamantly opposed to having it be a spinning (or otherwise moving) one. LadyofShalott 17:48, 8 May 2017 (UTC)Reply[reply]
  • Some of the ideas in this thread are absolutely awful. Suggesting the idea of an animated logo suggests one has zero concept of design. I suppose nobody remembers the web of the 90's when websites were loaded with animated elements and it, well, completely sucked. It took a while but eventually people realized that animated elements are extremely distracting to readers, just as blinking text and any flashing elements are. As somebody who remembers the last time the logo was updated (geez the time past quickly), suggesting changing the logo (even now years later) feels very tiresome because I remember how much discussion and effort went into the present logo. Quite frankly, I wish people were as willing to put as much effort into content creation or article improvement as they are with something like a logo change, which strikes me mostly as a lateral change. Jason Quinn (talk) 17:49, 9 May 2017 (UTC)Reply[reply]

RfC: LTA Knowledgebase

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
Summary:-- The answer to the question Should the English Wikipedia have an off-wiki LTA database that can only be viewed and edited by trusted editors? is yes, but there is more to discuss first.

Details and Caveats:-- The WP:BEANS argument given by many supporters seems primarily good. The opposition to this proposal, despite being outvoted roughly 1:2 in favour of support, were nearly unanimous in their concerns about possible unintended and detrimental effects of restrictions of access. Specifically, the concerns of "what do we do with the existing on-wiki LTA database" and "how do we define "trusted editor?" were widely prevalent in the discussion.

This leads us to believe that the answers to the aforesaid questions are integral for the smooth conduct of the entire process. The following themes are the issues brought up that will require successful discussions before this project can proceed:

  • Theme 1--The first issue is what to do with the existing LTA database hosted on Wikipedia. The proposers, and many of the support voters, were in agreement that the existing pages should be kept, and going forward generic information should continue to be added in order for even new editors to view at the very least the basics of a particular LTA. The exact nature of such information will need to be discussed in a future discussion, though it may not need to be a formal RFC if a decision can be easily reached and agreed upon. Either way, existing information currently on Wikipedia will not be lost. While only briefly mentioned in the RFC, a concern was raised about private information being included in this database. Consideration should be given towards how private data will be dealt with.
  • Theme 2--The second issue is in defining a "trusted editor". This must be the next phase in implementing the proposed LTA Knowledgebase. There was no answer to this question in this RFC, except that many mentioned it may not be too strict lest it deny good-faith NEWBIES editing in vulnerable areas the access required to combat LTAs. While it should go without saying, we highly encourage the editors making their proposal to consider the concerns made in this RFC when crafting the next discussion.

Signed by:


Our Long-Term Abuse (LTA) pages are an extremely valuable repository for Wikipedians doing anti-vandalism work - they inform editors on how particular vandals edit, even when those edits may seem innocent when taken out of context, let them know what to look out for in certain areas of the encyclopedia, and contain suggestions on how to treat certain users; no editor can know about the behaviour of every regular vandal. The records are also used for tracking purposes, informing edit filters for example.

But these pages aren't without their drawbacks. Vandals are often drawn to this system, either by aiming to become an LTA as some kind of badge of honour, trying to live up to their name once listed as an LTA, or by new vandals attempting to emulate the well documented vandalism methods. We should be doing a better job of denying recognition to these vandals, but this is hard to do whilst also keeping a comprehensive open record of their actions on Wikipedia. The other issue with having these records in a public space is not being able to properly document the vandals' edit patterns or our counter measures to avoid BEANS issues, leaving out information that could be valuable to anti-vandal editors.


We are therefore proposing a new tool for Wikipedians, called the LTA Knowledgebase, which would be an off-wiki database of LTA records, available for viewing and editing to only (probably approved) experienced editors. Samtar has been working on this for a little while now, and you can see a proof-of-concept version here. With this database vandal fighters will be able to both log information on more recurring vandals as well as covering their editing habits and what we're doing in response in more detail (documenting how relevant targeted edit filters work for example). This will be especially beneficial for those LTAs who we don't even document in order to fully deny recognition. LTAs won't know whether they have an entry, nor what that entry contains.

This tool will not be for extra personal information on these users; it will only encourage more behavioural details, and rules will need to be in place for tool admins to remove any personal information that is added. Requirements for access can be debated in another RfC, but the approach would likely be that users would require manual approval from a tool admin with the needed experience level somewhere between that of NPP and OTRS, requiring sufficient time and experience working on anti-vandalism work to be trusted. Future RfCs could also decide on criteria for the addition of an LTA to the tool and whether all users are able to add an entry or whether new entries might require approval by a tool admin, for example.

Subsequent discussions can be held to clarify the details and specifics so these needn't be debated here beyond suggestions and initial discussion. Sam Walton (talk) and Samtar talk · contribs 16:21, 5 February 2017 (UTC)Reply[reply]

The first question that needs to be answered is: Should the English Wikipedia have an off-wiki LTA database that can only be viewed and edited by trusted editors?

Support (LTA Knowledgebase)

  • Support - excellent idea and needed. Search should be on anything so searching on "Armenia" should find the LTA record for Ararat arev. -- GreenC 17:41, 5 February 2017 (UTC)Reply[reply]
  • Support - and probably all admins should be approved automatically on request. עוד מישהו Od Mishehu 04:38, 6 February 2017 (UTC)Reply[reply]
  • Support provided there is or will be an option to filter by active wiki and/or topic areas they're mostly active in (some LTAs are also belligerents in topic areas known to be warzones; for example Runtshit's second most favourite pastime is stirring the Israel/Palestine pot). —Jeremy v^_^v Bori! 05:06, 6 February 2017 (UTC)Reply[reply]
  • Support. This is an excellent idea, and of course it would make sense to automatically approve all sysops. Tony Tan · talk 06:19, 7 February 2017 (UTC)Reply[reply]
  • Support and make it automatic for Admins. -- Iazyges Consermonor Opus meum 06:22, 7 February 2017 (UTC)Reply[reply]
  • Support, of course, because the proposal would solve the very serious BEANS problem associated with LTA pages. A similar solution would be good for sockpuppet investigations, for the same reason. Binksternet (talk) 06:43, 7 February 2017 (UTC)Reply[reply]
  • Support Good BEANS solution (although I'll be sad to lose the innocent enjoyment of browsing that den of depravity) -- Elmidae (talk · contribs) 17:11, 7 February 2017 (UTC)Reply[reply]
  • Strong support This is much-needed! Gestrid (talk) 19:34, 8 February 2017 (UTC)Reply[reply]
  • Support per above. MER-C 05:28, 11 February 2017 (UTC)Reply[reply]
  • Support This is needed. ThePlatypusofDoom (talk) 13:08, 14 February 2017 (UTC)Reply[reply]
  • Support with the suggestion that the requirements for access should be low - anyone with any of the various admin-granted user rights (rollback, reviewer, autopatrol etc) should be approved. This will prevent it from becoming seen as a secret cabal. Hut 8.5 18:36, 14 February 2017 (UTC)Reply[reply]
  • Support I have read through the proposal, and it seems like a fantastic idea. Qaei 21:12, 14 February 2017 (UTC)Reply[reply]
  • Support as others this is needed. There are a growing number of LTA cases where the main motivation seems to be generating larger and larger LTA report entries - if these occur off-wiki and in a less conspicuous location, I'm certain some LTA disruption will cease. I'd also add, the growing use of Wikidata as a repository for certain key data sources will require something to be done to co-ordinate action against LTA cases running across multiple sites, and speaking as an English Wikipedia and Commons administrator, it's very difficult to co-ordinate action as it is when all we're dealing with at Commons is (mainly) copyright issues, once WD seriously starts to become another place to fight over sources, data and page titles (you know, the sort of shit we've been dealing with over Eastern Europe, the Balkans, Israel/Palestine for every day I've been editing) it'll be imperative we can provide our WD colleagues as much data as possible so they can deal with issues. Nick (talk) 21:17, 14 February 2017 (UTC)Reply[reply]
  • Conditional support With the proviso that the LTA pages stay useful enough so that inexperienced editors can refer to them to see the nature of the disruption and how to spot possible socks. --NeilN talk to me 21:21, 14 February 2017 (UTC)Reply[reply]
  • (edit conflict) Support As far as some of the responses regarding attention seeking not being such a big issue, even if that were true (which I wholeheartedly disagree that it isn't) patterns are also a big part of tracking and identifying LTAs and discussion of those patterns is equally as important but discussing (as in identifying) them on-Wiki kinda gives it away (and also WP:BEANS may apply) and they may begin a newer pattern that isn't as easily identified. Though I support this for many more reasons as well...Chrissymad ❯❯❯ ¯\_(ツ)_/¯ 21:25, 14 February 2017 (UTC)Reply[reply]
  • Support – We can probably hammer out the finer details in a second discussion, but a change in this general direction would be welcomed. I've always seen the LTA pages as almost diametrically contrary to WP:DENY (and publicly stating what kinds of edits to look for lets the abusive editors know exactly what kinds of edits to avoid, unless they want to be seen). One word of caution that I would advise is that the requirements for gaining access these pages should be low. I don't even think you need to have any additional user rights or a demonstrated need; anyone who is demonstrably WP:HERE should be able to see these pages on request. (Perhaps the ability the create and edit the pages could be restricted to a higher access level?) The more they are hidden, the less comfortable good-faith editors who don't have access to the pages feel. We want to find the right balance between preventing disruption and maintaining transparency in project administration. Mz7 (talk) 22:06, 14 February 2017 (UTC)Reply[reply]
  • Support - I only have a little bit of experience with LTA cases, but I think that in each case, I came to the conclusion that it wouldn't be productive to "tip our hand" by adding to the details about a user's behavior when it may not be obvious to that user that others are onto a particular strategy/habit/pattern. Of course, this may be presuming that the SPI information that goes along with the LTA cases could also be hidden, and that may not actually be intended here. — Rhododendrites talk \\ 00:48, 15 February 2017 (UTC)Reply[reply]
  • Support I think this solution is appropriate to the problem. Chris Troutman (talk) 12:21, 16 February 2017 (UTC)Reply[reply]
  • Support - details about enforcement should rightfully be hidden from the public at large. That said, access control shouldn't be strict - given that it's meant to be an anti-vandalism reference, giving all rollbackers access sound about right. — Train2104 (t • c) 20:21, 17 February 2017 (UTC)Reply[reply]
  • Support. It's a great idea! That page is like the "How to become an experienced vandals" for them. But I think only users with a certain number of construtive edit can access. By the way it's an important source for newbies too so everyone in the community knows what to do to block distruptive vandals.Justmeonhere (talk) 20:56, 19 February 2017 (UTC)Reply[reply]
  • Support the concept. Oppose some small but serious details with the implementation plan, pending a pause before the next phase for conversation to address those details. I want the benefits and agree with the idea but I would not want the current implementation direction advanced without conversation, and I really do believe there are non-controversial, low risk paths forward. The WMF recently published advice to set up a sort of LTA Knowledgebase, so there is institutional support for the concept. That support and other hints of the idea are in the November 2016 meta:Training modules/Online harassment/First draft and meta:Training modules/Keeping events safe/First draft. With many others I proposed meta:Grants:IdeaLab/Centralised harassment reporting and referral service some time ago, which is a similar concept. Blue Rasberry (talk) 20:00, 22 February 2017 (UTC)Reply[reply]
  • Support, this would be so helpful for SPI. It's frustrating to be asked to handle a case where the evidence is "same as always" or "WP:BEANS," so this would make it much easier to process complex LTA cases. However, I strongly believe that we should create some sort of threshold to prevent socks from gaining access to the database and developing new, undetectable modes of behavior, or vandalizing (?) the system. Maybe an ECP-style 30/500 will do... GABgab 04:41, 26 February 2017 (UTC)Reply[reply]
  • Support. Good idea. However access control will have to be carefully thought out. We want regular established users and vandal fighters to not have to jump through too many hoops to get access to it, but as per GAB above we don't want socks etc. -- œ 04:46, 28 February 2017 (UTC)Reply[reply]
  • Support - Having this information out in the open makes it a cat and mouse game that is impossible for us to win. Agree with others that access control is the key issue. It should be open enough to be relatively transparent (i.e. not a cabal), but restrictive enough to keep out sockpuppets. Kaldari (talk) 18:40, 3 March 2017 (UTC)Reply[reply]

Oppose (LTA Knowledgebase)

  • Oppose. There's not much I can do to prevent an off-wiki database, though I think it's probably not a good idea, I'm generally opposed to removing the information from Wikipedia. It's useful for editors to be able to look up cases to be able to recognise LTAs. It's also useful for admins to just link to the cases instead of having to provide detailed explanations each time, when blocking and so on. Here for example, an IP user could tell me all I needed to know by linking to an LTA page. Reports at AIV for example will often just say "see WP:LTA/xxx", which is something I don't think should be restricted to a trusted subset of users. More eyes on reports means more good information and less incorrect information as far as I'm concerned. Like I say, there's nothing preventing anyone setting up a private LTA database anywhere they like, but the on-wiki version is useful, so for this reason I'm landing in the oppose section. -- zzuuzz (talk) 20:00, 8 February 2017 (UTC)Reply[reply]
    • Changed my vote to meh, per my comments above and below... LTA to remain in use, which is good, but I fail in enthusiasm for the proposition. -- zzuuzz (talk) 21:29, 14 February 2017 (UTC)Reply[reply]

*Provisional oppose. Until a concrete plan is hammered out for how the existing LTA pages will be used and updated. --NeilN talk to me 14:27, 10 February 2017 (UTC)Reply[reply]

  • Oppose. Until there is a proper way to prevent abuse of this new system, and that WMF legal ascertains that this is compliant with the privacy policy. Cenarium (talk) 21:04, 11 February 2017 (UTC)Reply[reply]
  • @Cenarium: We've talked with commtech quite a bit. Not sure what you mean by "to prevent abuse of this new system," but I'm pretty sure it is compliant with the PP as it has no personal information. Dat GuyTalkContribs 17:38, 14 February 2017 (UTC)Reply[reply]
  • @DatGuy: The stated goal of this project is to collect information on users, so it is more than likely that personal information with be shared there, whether intended by the designers or not. Regardless of the alleged ills that caused the reported users, this is a problem that should be taken seriously. There should be an oversight-like system to remove personal information. ArbCom should have jurisdiction, to reduce the probability for this type of incidents and settle any such incident. We need a real assessment that this complies with the privacy policy, not just some vague feeling it does. Cenarium (talk) 23:05, 14 February 2017 (UTC)Reply[reply]
  • Oppose the "LTA as a badge of honour" conjecture is just that. I'm sure some find it amusing. But they find it amusing to be reverted. All the best: Rich Farmbrough, 23:46, 13 February 2017 (UTC).
    • @Rich Farmbrough: Not sure I can find the diffs right now but I know I'm not the only one to have reverted vandals who are quoting their LTA page or making explicit references to it. It's clear that for some this page is something they strive to build like some kind of vandalism resume. Sam Walton (talk) 00:02, 14 February 2017 (UTC)Reply[reply]
      • Diffs like this or this should suffice to demonstrate the point. IMO, this is clear indication that they don't need and should never have an LTA page. -- zzuuzz (talk) 08:05, 14 February 2017 (UTC)Reply[reply]
  • Very Strong Oppose Please, no more secrets. Look, if the requirement was going to be extended confirmed, I might consider it. But I see no reason for more cabals. Tamwin (talk) 04:42, 14 February 2017 (UTC)Reply[reply]
  • It will probably be more lenient than extconf. I believe the 'requirements' are just that the user is a good contributor, in any way shape or form. Dat GuyTalkContribs 17:38, 14 February 2017 (UTC)Reply[reply]
  • Oppose as self-defeating. The entire point of LTA is to inform editors of how to deal with serious vandalism. Moving this to a secret database which few have access to (and few would request access to, I believe) makes LTA pointless. I could only support this if the requirement for viewing was extended confirmed. Laurdecl talk 09:51, 14 February 2017 (UTC)Reply[reply]
  • Not "moving," more "adding to." The current LTA list will stay. As said above, probably more lenient than extconf. Dat GuyTalkContribs 17:38, 14 February 2017 (UTC)Reply[reply]
  • As long as it requires something like WP:PERM to have access to, I'm opposing. Laurdecl talk 07:00, 15 February 2017 (UTC)Reply[reply]
  • @Laurdecl: I don't know what you mean 'requires something like WP:PERM.' If we continue with a labs tool and not a wiki, you will click on "request account." Following a short amount of time, if you are not a vandal and some you will be accepted. For example, you would be accepted. Dat GuyTalkContribs 15:04, 15 February 2017 (UTC)Reply[reply]
  • @DatGuy: "would require manual approval from a tool admin with the needed experience level somewhere between that of NPP and OTRS" sounds to me like WP:PERM. Anyway the issue is not whether I would get accepted, but whether this would restrict casual editors from learning about LTAs. LTA is supposed to educate editors about persistent vandals they may stumble across. Most editors would not even bother requesting permission and by the time they are approved would have lost interest. Again, if access was automatically given with extconf, I wouldn't oppose. Laurdecl talk 06:19, 16 February 2017 (UTC)Reply[reply]
  • Oppose. On-wiki lists (pertaining to matters exclusively to that wiki) need to remain exclusively on-wiki. The alternate way to improve LTA would to make the on-wiki page more accessible and searchable. Steel1943 (talk) 14:12, 14 February 2017 (UTC)Reply[reply]
@Steel1943: I don't think you get the point. We want the page to be less accessible, so vandals can't look at the LTA page, completely change their behavior, and not get caught. Also, an LTA page that's easily accessible kind of goes against WP:DENY, as it gives the vandals attention. ThePlatypusofDoom (talk) 22:19, 14 February 2017 (UTC)Reply[reply]
@ThePlatypusofDoom: Oh, but I do ... since having such a database also restricts good-faith editors without whatever user right or program will be necessary to access this database from figuring out what in the world those with access are talking about, or for that matter, even know how to identify a LTA case themselves. So, the argument here is between figuring out if WP:BEANS or the risk of removing the transparency of the Wikipedia project is preferred. And with that being said, I think the latter is worse since hiding information such as this per WP:BEANS goes against some of the public domain licenses and goals of Wikipedia, especially considering that most of these LTA cases are already posted and thus have, in turn, already been agreed upon to be available to essentially any reader per the applicable license(s). In a nutshell, I worry that creating a separate, "inaccessible to some" database could have legal ramifications that I think the foundation would really rather not have to deal with. Steel1943 (talk) 22:30, 14 February 2017 (UTC)Reply[reply]
...Come to think of it, I guess I could just attempt to confirm my concern with one of the proposers of this: @Samwalton9: I know you may have some insight on this: Per my comment above, would you think there would be and legal issues with such a database, and if not, why? Steel1943 (talk) 22:33, 14 February 2017 (UTC)Reply[reply]
I'm very much not a lawyer, but I can't see why something that's been posted on Wikipedia is somehow required to stay on Wikipedia. Pages and edits are deleted and oversighted on a regular basis after all and any content copied over would be attributed in some way. The only legal concerns I could see would be around users assuming it more reasonable to post private/personal information there, but this is obviously a serious concern that would be given importance. Sam Walton (talk) 22:42, 14 February 2017 (UTC)Reply[reply]
@Samwalton9: Yeah, I was more or less asking you in the event that you knew something as part of your "other life". For a few years now, I had the assumed understanding that unless there was some sort of legal issue with keeping something on Wikipedia, the information on a page, deleted or not, could be provided to almost anyone who requests. (But of course, whether or not it stays on Wikipedia is up to the community.) Just trying to ensure that any decision established as a result of this discussion will not cause legal issues that could bite the foundation later. Steel1943 (talk) 22:49, 14 February 2017 (UTC)Reply[reply]
You'd need to ask someone from Legal for an official word on that, but either way, I think it would be reasonable to keep the text that's currently on LTA pages there (it's out in the open now at any rate) and simply not add any more to them from now on. Sam Walton (talk) 22:54, 14 February 2017 (UTC)Reply[reply]
@Samwalton9: Understood and thanks! Not sure how or who to ask "from legal" though since I'm embarrassingly not sure how to do that. Steel1943 (talk) 22:57, 14 February 2017 (UTC)Reply[reply]
@Steel1943: In the past, I've been able to contact Legal by simply leaving a message at User talk:Mdennis (WMF), and Maggie Dennis will liaise with the legal team for you. I think, however, you can also contact directly per wmf:Contact us, though I've never tried it that way. Mz7 (talk) 23:07, 14 February 2017 (UTC)Reply[reply]
  • Oppose. As an administrator on a sister project I have found the publicly viewable LTA documentation here very valuable, because a number of these abusers take their activity cross-wiki when their efforts are frustrated by anti-vandalism measures here. If this research and documentation is kept behind closed doors then my job will be more difficult. (I am not persuaded that this proposal does not deprecate public LTA tracking: publicly viewable pages would fall into disuse and cease to be a valuable resource.) ~ Ningauble (talk) 17:56, 15 February 2017 (UTC)Reply[reply]
    @Ningauble: There would certainly be plans to make sure this could be used and accessed across other language Wikipedias, but you raise a fair concern that this should be a priority before deployment. Sam Walton (talk) 18:27, 15 February 2017 (UTC)Reply[reply]
    Sam, I was referring to a sister project rather than another language Wikipedia, but the case of my personal anecdote can be generalized in various ways. The most important generalization, common to both, is explicit in my post above: "publicly viewable" wikis. ~ Ningauble (talk) 18:57, 15 February 2017 (UTC)Reply[reply]
  • Oppose on general principle of not maintaining such an archive as an off-wiki resource, and as well as limiting access to any specific group. I get the BEANSy-ness of the argument, but moving this off-wiki leaves us using an off-wiki repository for enforcement when any LTA comes back up. Access limitations to such a resource would plainly limit the ability of some editors to review such material and contribute to consensus. It should be made more usable, and some kind of archiving is a good idea, but it should stay inside the project, and available to all editors. Jim Miller See me | Touch me 19:48, 15 February 2017 (UTC)Reply[reply]
  • Strongest oppose Creating an off-wiki restricted database with the express purpose of identifying particular users? No thanks. Wugapodes [thɔk] [ˈkan.ˌʧɻɪbz] 20:06, 19 February 2017 (UTC)Reply[reply]
  • Oppose I could see such a system for off wiki info. On wiki allowed stuff should be on wiki. Also the site should be a wiki not whatever this is. Doc James (talk · contribs · email) 17:51, 20 February 2017 (UTC)Reply[reply]
  • Oppose per Steel1943. Such stuff needs to remain on wiki. If you want to make an improved interface for accessing and searching LTA pages (which remain on wiki) that's fine. Kind of like Wikipedia:AutoWikiBrowser/CheckPage: primarily used by external software but still accessible on-wiki. feminist 09:45, 21 February 2017 (UTC)Reply[reply]
  • Oppose I've been hesitating here , trying to make up my mind, and I think at the end of the day I oppose this. I tangled with one of the more notorious LTA cases early in my wiki-career, and free and easy access to the page about them helped me quickly understand what I was dealing with and how to respond appropriately. Moving it off-wiki, no matter how you do it, lowers the profile iof this important resource, possibly preventing newer users from even being aware of it. Duplicating it offline while keeping it here seems pointless. So I think we should keep it here. Beeblebrox (talk)
  • Oppose I think there are serious transparency issues that need to be addressed before I could support a proposal like this moving forward, and I'm not sure they can be. The fundamental problem is that if this is useful, it means we are using access restricted/secret information, as justification for on-wiki action that will likely involve blocking people. It is already problematic when Arbcom and other functionaries do it, but in that case, they are a very small group, of highly vetted and trusted users, and the secret information they use cannot be posted publicly. It also has various checks built in to provide review and limit abuse. It would be better if we didn't need it, but it is in the end a necessary evil. This does not appear to be such. If someone is being blocked for LTA, they should have the right to see the evidence presented against them. Moreover, if the block ends up being reviewed at WP:AN the community must be allowed to see the evidence, so they can judge the block. I would still have concerns, but at the least, I think there needs to be a way to make the entire LTA case fully public for review. Monty845 06:03, 24 February 2017 (UTC)Reply[reply]
    • If a usermass-creates attack pages, he will be blocked on evidence that only admins can see. Since all admins, and some other users, will be able to view the LTA, this will have at least as much transparency as a user who mass-creates attack pages. עוד מישהו Od Mishehu 22:20, 4 March 2017 (UTC)Reply[reply]

Discussion (LTA Knowledgebase)

What's going to happen to the existing LTA pages if this is implemented? --NeilN talk to me 16:30, 5 February 2017 (UTC)Reply[reply]

I guess that's open to discussion, the options would be to retain them since the information has been public for long enough already, archive them and provide links to the new tool which may contain extra information, or remove/delete them. I think the preferable option would be to retain/archive so that existing links still work, but include a link to the tool and tell users to add content there rather than on-wiki. Sam Walton (talk) 16:46, 5 February 2017 (UTC)Reply[reply]
I would probably oppose anything which prevented me from helping new/occasional editors (i.e., "non-approved" editors) understand what's going on by pointing to a LTA page explaining the nature of the abuse/disruption, what to look out for, etc. --NeilN talk to me 16:58, 5 February 2017 (UTC)Reply[reply]
@NeilN: Perhaps we could repurpose the on-wiki pages to provide very general descriptions, moving all the specifics and IP/account records to the tool. Sam Walton (talk) 21:11, 5 February 2017 (UTC)Reply[reply]

This is an interesting proposal and I know a case where it would help me have useful discussions about a particular LTA. Sam Walton, I don't think this is your part of the WMF, but something like this has been suggested in the new Community Health Initiative grant proposal, page 11. Had you heard of this? If so, do you have any thoughts about how it might tie in? BethNaught (talk) 17:05, 5 February 2017 (UTC)Reply[reply]

@BethNaught: Interesting - I hadn't had a chance to read that document yet and wasn't aware that such a tool was already being talked about. It seems that the resource proposed there would be broader, documenting cases of harassment and editing restrictions too. We'll speak to Community Tech to see if it's worth continuing with this tool if they're planning to work on that. Sam Walton (talk) 21:13, 5 February 2017 (UTC)Reply[reply]
Indeed, we were planning on making a similar, more broadly scoped tool that I think will account for all types of abuse. The LTA Knowledgebase as currently constructed could be adapted for this purpose, along with adding multi-project support and i18n. The harassment project as a whole is still in its very early stages, so for now I would carry on and assume there won't be any conflicts with what WMF will be working on. It is nice to see the community getting a head start and this RfC attracting support. Assuming you all are OK with joining forces (we certainly are), Community Tech will soon be in touch with Samtar, Sam Walton, and any other Sams involved :) MusikAnimal talk 16:34, 7 February 2017 (UTC)Reply[reply]

How about hosting a multilingual LTA on Meta? KATMAKROFAN (talk) 17:42, 5 February 2017 (UTC)Reply[reply]

Down the road, it is planned that there will be multilingual support, especially for dewiki. Dat GuyTalkContribs 17:47, 5 February 2017 (UTC)Reply[reply]

Please spell out the proposal ("viewing and editing to only (probably approved) experienced editors" is ambiguous). Currently it is possible to link to an LTA page in a comment or edit summary to explain an action. It is desirable to minimize such linking per WP:DENY but it is sometimes needed. Would the new system allow such links? What happens when people (an IP, a new account, an autoconfirmed account, an approved LTA operator) click them? I'm asking because if the information is available to all, why is the new system better than LTA pages? But if it's only available to approved operators, a link loses its explanatory power, although a link to generic information with a tag like an WP:OTRS ticket for more details would be good. Johnuniq (talk) 00:45, 6 February 2017 (UTC)Reply[reply]

I would think that some standard similar to ECP would be used, albeit with a bit more restrictions on time and edit number (I'm thinking 1yr/10K edits on any one project). Anyone with sysop permissions on any wiki should automatically be trusted. I do have to ask, though; is there (or will there be) an option to filter LTAs by the wiki(s) they're active on? —Jeremy v^_^v Bori! 04:59, 6 February 2017 (UTC)Reply[reply]
@Jéské Couriano: It is possible to link using toollabs:lta/publicdemo/view.php?lid=8 or via an external link. Currently its only enwiki, but when it will be expanded to other wikis there definitely will be an option to filter LTAs. There are no set requirements, but sysops will be always approved. There might be consensus on requirements in this RfC. Dat GuyTalkContribs 06:48, 6 February 2017 (UTC)Reply[reply]
Above link doesn't work, try -- Samtar talk · contribs 12:00, 6 February 2017 (UTC)