Wikipedia:Village pump (idea lab)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at Village pump (proposals). Try to be creative and positive when commenting on ideas.
Before creating a new section, please note:

• Discussions of technical issues belong at Wikipedia:Village pump (technical).
• Discussions of policy belong at Wikipedia:Village pump (policy).
• If you're ready to make a concrete proposal and determine whether it has consensus, go to the Wikipedia:Village pump (proposals). Proposals worked out here can be brought there.

Before commenting, note:

• This page is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them.
• Wondering whether someone already had this idea? Search the archives below, and look through Wikipedia:Perennial proposals.

« Archives, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57

Helper

I want to give the idea of new user group known as Helper, and their work is to help all other editors (mostly newusers). But wait, Why we need helpers?? Because new users dont know much about wikipedia, they do vandalism,etc. Example: Me (Mujtaba!). Just Think about it-- 🍁 Mujtaba 🌴 14:37, 2 June 2016 (UTC)

Other users also help newbies, but for helpers "Only helping Clearly"-- 🍁 Mujtaba 🌴 14:39, 2 June 2016 (UTC) — Preceding unsigned comment added by Mujtaba! (talk • contribs)

3rd party wikis links

Wouldn't it be better if Wikipedia had a 'See also on' section on the sidebar with links to the same subject on other wikis (including the sister-projects under Wikimedia)? I was thinking (for example) of wikia.com, ProofWiki and OSDev wiki - they all offer in-depth information or technical knowledge on specific topics. Also, I think that a link on the sidebar for authors to their Wikisource Author: pages would be more accessible than the same link at the bottom of the page. This would allow Wikipedia to remain a general-purpose encyclopedia, while still offering links for more in-depth technical knowledge. I think it will also help with WP:NOT#Wikipedia_is_not_a_manual.2C_guidebook.2C_textbook.2C_or_scientific_journal. — Preceding unsigned comment added by Mostanes (talk • contribs) 07:45, 7 May 2016 (UTC)

Please, no. It would be a spam magnet. --Redrose64 (talk) 10:25, 7 May 2016 (UTC)

If those links were appropriate, then they could be included as ==External links==. This is the recommended location for WP:SISTER links.

Also, you should keep in mind that very few people look at the (gray) side bar, and it's completely invisible for the huge percentage of readers who use the mobile website. WhatamIdoing (talk) 22:06, 21 May 2016 (UTC)

Wikipedia pages aren't even allowed to have links to other wikis; it's in Wikipedia policy. — Preceding unsigned comment added by 2601:2C1:C004:4900:BD04:8B7D:BB53:4F01 (talk) 22:09, 1 June 2016 (UTC)

Extended confirmed protection policy

Discussion

It's become necessary to begin discussing how the community will apply WP:BLUELOCK in articles outside ArbCom jurisdiction or discretionary sanctions. Rather than formulate an RFC in a hurry, let's all take a few days to hash out ideas on how to best implement ECP.

I'll begin by saying that I don't think ECP should be authorized for uses other than sockpuppetry or new, disruptive accounts that can't be controlled by semi-protection. I'm open to other uses but I'm having trouble seeing them right now. Katie^talk 15:43, 18 May 2016 (UTC)

For me, it should be the last resort. I mean, real last, not just a burst of vandalism or socking. We don't need to have the entire Wiki blue-locked. Sir Joseph ^(talk) 15:45, 18 May 2016 (UTC)

First I think we should understand, when we say "community" in the protection policy, whether we mean a priori by the community, with exceptional cases handled at a noticeboard of some sort, or whether all such discussions should be held at a noticeboard, or some other option. Ban discussions are basically required to occur at WP:AN/WP:ANI, yet the most recent case where an editor attempted to have a discussion there about a potential use of ECP is probably going to close as "no consensus" or possibly even "this doesn't seem to be the place to have this discussion", without having had a "wide" community discussion about the policy problem. (ref WP:AN#Reducing List of social networking websites from indefinite full protection to indefinite 30/500 protection). The originating RFC rejected WP:RFPP as a venue for these; what about a WP:RFPP/EPC? --Izno (talk) 15:50, 18 May 2016 (UTC)

I think an RFC is the way to go in the end. As someone who closes RFCs semi-regularly and is in the process of co-closing a big one that's muddied by a section that basically ended up as "it depends", the questions really have to be stated in a 'support/oppose' or 'yes/no' manner. It's the only way to effectively gauge consensus. How about something like:

• Do administrators have discretion to apply ECP in the same manner as they use discretion to apply other forms of protection?
• Is ECP authorized for persistent sockpuppetry?

There are obviously other questions to be asked, but these two are a start. I hesitate to propose a 'what if admins do not have discretion' as I think the first question should be answered, well, first. Katie^talk 16:02, 18 May 2016 (UTC)

It may be interesting to see the current usage of blue-lock protection. The following are the articles that have the {{pp-30-500}} template in the article text:

The only listed article that doesn't fall under Gamergate, ARBPIA, or the caste sanctions is Real Madrid C.F. I'll notify the admin who placed that protection that we are having a discussion here. Only five *article talk* pages are under blue-lock protection; they are at the end of the list and are all ARBPIA or Gamergate. EdJohnston (talk) 03:06, 19 May 2016 (UTC)

Going by the presence of {{pp-30-500}} doesn't give the full list, since that template is merely a visual reminder: it's not obligatory to add a prot icon template to protected pages. Nor does it provide any reasons for the use of WP:30/500. The full list is here. --Redrose64 (talk) 11:20, 19 May 2016 (UTC)

The number of extended confirmed users won't be confirmed unless everyone edits at least once since 9 April 2016 (UTC). 333-blue 11:53, 19 May 2016 (UTC)

I notice in comparing the lists, that there are four pages under 30/500 protection not listed by EdJohnston, those omitted are Haaretz, Im Tirtzu, Talk:Nair and Category:Temple Mount. Also, EdJohnston lists Jerusalem, but despite the blue padlock, that page is only semi-protected, and has been since 05:19, 28 February 2011 - it has never been 30/500 prot, so this edit by SSTflyer (talk · contribs) was in error. --Redrose64 (talk) 13:25, 19 May 2016 (UTC)

The admin who applied 30-500 protection at Real Madrid F.C. has now changed it back after someone pointed out the issue. EdJohnston (talk) 13:42, 19 May 2016 (UTC)

I don't think Haaretz should have 30/500 protection. It's an article about a newspaper. Has that page experienced vandalism excessive enough to warrant that? Sir Joseph ^(talk) 13:58, 19 May 2016 (UTC)

If you think Haaretz should be changed, why not ask the protecting admin, User:Rami R. If no agreement can be found, the matter could be raised at WP:AE for a decision. I only saw one recent POV-pushing edit on that article by someone who had less than 500 edits. That User:BoredSocks is now blocked by Rami R. You'd expect a sock to use a more imaginative name. EdJohnston (talk) 20:09, 19 May 2016 (UTC)

Since Haaretz has been tagged as falling under ARBPIA since 2014,[1] I felt that applying ECP would be uncontroversial. However if any admin feels otherwise, s/he may feel free to remove protection. Rami R 07:45, 20 May 2016 (UTC)

• We've needed something like this for a long time. Until now, there was no intermediate level of protection between "anyone with an account, ten edits, and four days' tenure"—which prevents the vast majority of casual vandalism and presents at least a moderate obstacle to all but the most determined sockmasters—and "only administrators". I've seen several cases where articles have ended up under long-term full protection or we've just had to accept that every few weeks somebody is going to have to block a load of socks and oversight some libellous edits. So, used sparingly, I support the use of ECP/bluelock at admin discretion where semi has been/would be ineffective and the alternative would be full protection. Perhaps the protecting admin should be required to record their rationale on the talk page (and preferably link to the diff in the protection log so that it can be easily reviewed)? This might help prevent over-use and might also prevent removal by a well-meaning admin who assumes it's being over-used. HJ Mitchell | Penny for your thoughts? 07:30, 20 May 2016 (UTC)

Well, we did have such an intermediate level of protection – pending changes level 2 – but that did not receive consensus by the community to implement anywhere. I would say that 30/500 is actually a large step up from PC2. Mz7 (talk) 17:09, 22 May 2016 (UTC)

• I generally oppose any bluelock that could be enacted by a single or small group of people. So no lone administrator (except where use in a topic area has been authorised) no local consensus (otherwise you will get walled gardens where a small group can easily lock out new editors). So some form of AN discussion with a *wide* notification. Only in death does duty end (talk) 07:57, 20 May 2016 (UTC)
• I supported the 30/500 protection on any article experiencing vandalism issues. Semi-protection is still inefficent because a vandal account may be autoconfirmed, and to vandalize semi-protected pages, for full protection it seems quite aggervating and stressful to me. KGirlTrucker87 ^{talk what I'm been doing} 22:03, 21 May 2016 (UTC)
• I think the thrust of the RfC should be answering 1) who should have the authority to implement this level of protection, and 2) when would implementation be appropriate. Here are a few options:

1. Option A: Allow use only by the Arbitration Committee (community cannot use it; most restrictive)
2. Option B: Allow use only by prior community consensus at AN, ANI, village pump or RfC for reasons to be decided on a case-by-case basis
3. Option C: Allow administrators to apply at their discretion only against persistent sock puppetry or continued use of new, disruptive accounts where other methods (such as semi protection) have not controlled the disruption (verbatim what ArbCom stipulated for WP:AE and WP:AC/DS 30/500 applications)

   Option C alt: Allow use only by prior community consensus at AN, ANI, village pump or RfC only against persistent sock puppetry or continued use of new, disruptive accounts where other methods (such as semi protection) have not controlled the disruption

4. Option D: Allow administrators to apply at their discretion to prevent persistent or egregious disruptive editing (in the same manner semi, PC, and full protection are currently applied; least restrictive)

We could have the community vote support/oppose for each option. What other options could we make available? Mz7 (talk) 04:03, 23 May 2016 (UTC)

• I don't really understand why this is particularly controversial. Maybe I'm missing something. The ArbCom resolution specifies that it is authorized for certain areas, but does not specify it is unauthorized in others (even though Wikipedia:Protection_policy interprets it both ways in different sections), and if it did, that would be policy making. Furthermore, the wording under expectations clearly opens use broadly beyond ArbCom sanctioned topics.

Bluelock is objectively a protection level intermediate to semi and full. The same rationale should be applied for escalation and reduction of protection.

Further, I would support the broad empowerment of admins to reduce fully protected pages to blue locked, with immediate restoration of full if disruption resumes. Overall, I expect it can be a useful tool for reducing the number of fully protected pages, and not, as some seem to fear, of widespread escalation of semi articles. TimothyJosephWood 13:09, 26 May 2016 (UTC)

In comparison with Full Protection, two particular points of contention spring immediately to mind - Talk pages; Admin removal of the extended confirmed bit - with a third a few moments later - indefinite length. Suggest we should certainly want to put questions on the first two to the community as part of any RfC; and likely the third also. - Ryk72 ^'c.s.n.s.' 12:48, 2 June 2016 (UTC)

Draft of an RFC introduction

I started this per the discussion at AN simultaneously with Katie's post here. --Izno (talk) 15:50, 18 May 2016 (UTC)

Extended confirmed protection is a new level of protection which prevents certain editors from editing protected pages of that type. Those editors must have made at least 500 edits and have been editing for at least 30 days. The edit protection was instituted due to an RFC earlier this year, mostly with the intent of providing for the then-existing arbitration enforcement scope. The Arbitration Committee recently clarified by motion the extent to which the protection level can be used as a form of arbitration enforcement. They declined to answer the question of how it should be used outside that scope. Current policy allows for the protection level to be added as the result of a community discussion. What a community discussion means in the context of the protection policy seems to be ambiguous: A recent request at WP:AN#Reducing List of social networking websites from indefinite full protection to indefinite 30/500 protection would seem to indicate that many editors at that noticeboard believe it to be of the "widely discussed" kind of community, whereas "community" discussion in the context of a ban is a discussion at a noticeboard such as WP:AN or WP:ANI. In addition, Per WP:AN#Extended confirmed protection, there appear to be administrators applying the protection without either the remit from ARBCOM or the community. Given that this is the case, what does the community think "the community" means in the context of this protection level? The previous RFC indicated that WP:RFPP is not an acceptable level. Is it a discussion at WP:AN/WP:ANI, a discussion at a new community page (such as WP:Requests for page protection/ECP), or should it be authorized broadly within a certain scope a priori by the community (a la the ARBCOM clarification)? If a prior, what is that scope? Straw poll Community discussion is at a noticeboard Community discussion is a broader discussion about use

Wikipedia:Trading card game

Should we revive this project? This might take some work, but I think it could be done. BlackVolt (talk) 20:13, 18 May 2016 (UTC)

You're a bit late to the party. Realistically, even if there weren't competition, it's likely very few people would buy it; the Wikipedia merchandise store is more of a morale-boost than a realistic commercial proposition, and I doubt it brings in as much as 0.1% of cash raised from donations. (Bear in mind that while the 3500–20,000 active editors love Wikipedia, to most of the remaining 7 billion people in the world "branded Wikipedia merchandise" sounds about as appealing as Donald Trump pornography.) ‑ Iridescent 20:21, 18 May 2016 (UTC)

That doesn’t appear to be a trading-card game, rather a fairly typical trivia/quiz game. AFAICT the only WP-specific aspect is a type of question that involves guessing the relative rank, by page-views, of a given set of articles. I would expect a trading-card game to have a prominent element of simulation—of either editing WP or using it for research—which expectation seems to accord with the ideas on the Talk page so far.—Odysseus1479 00:02, 19 May 2016 (UTC)

Odysseus has a point. That game is barely even related to Wikipedia. Plus, we can do this online (card program). BlackVolt (talk) 13:42, 19 May 2016 (UTC)

If there isn't any dissent within a few hours, I'll move this to proposals. BlackVolt (talk) 15:29, 19 May 2016 (UTC)

Alright then. BlackVolt (talk) 17:39, 19 May 2016 (UTC)

Reinstate visual editing for English

I think that this is a good idea because, without all of the loading glitches that there were before, it was a useful tool. I was recently on the Spanish wikipedia, and it has visual editing enabled, and it was a lot better and easier to understand. It was just too glitchy before. Now I might just have it disabled, please comment if you still have it, but this is something I want to see back, especially because the English Wikipedia is the one with the most information on it, it should have all of the features. [User:Williditor|Williditor] ([User talk:Williditor|WikiWilly]) 16:02, 19 May 2016 (UTC)

"Editing mode" at Special:Preferences#mw-prefsection-editing chooses your editor. PrimeHunter (talk) 16:05, 19 May 2016 (UTC)

I don't see that; I guess that you mean "⧼visualeditor-preference-betatempdisable⧽". --Redrose64 (talk) 16:18, 19 May 2016 (UTC)

It's a drop-down menu right below that. PrimeHunter (talk) 16:48, 19 May 2016 (UTC)

Thank you! Now should I delete this, or not? I don't know village pump rules very well ;) — Preceding unsigned comment added by Williditor (talk • contribs) 13:17, 20 May 2016

@Williditor: No, never delete a thread that somebody else has replied to, except within the provisions of WP:TPO. Just let it be, and once there has been no further comment for a period, the archiving bot - in this case ClueBot III (talk · contribs) - will move the thread to the most recent of the archive pages. --Redrose64 (talk) 20:21, 20 May 2016 (UTC)

Enabling "⧼visualeditor-preference-betatempdisable⧽" removes the menu. PrimeHunter (talk) 18:02, 19 May 2016 (UTC)

The new 'welcome' screen should help some editors find the visual editor if they accidentally disabled it or defaulted to the wikitext editor. You may also want to see mw:Help:VisualEditor/User guide#Switching between the visual and wikitext editors on how to switch between them. Whatamidoing (WMF) (talk) 22:15, 21 May 2016 (UTC)

Template for City, State?

The standard usage on Wikipedia for a city, state is to link to Rockville, Maryland as [[Rockville, Maryland|Rockville]], [[Maryland]] would a template (call it CSL) which would look like {{CSL|Rockville, Maryland}} which would turn into the above link be useful? This would end up being used considerably, I think, so I thought I would ask here rather than the requested template page. (Not sure if it is too US Centric)Naraht (talk) 20:08, 19 May 2016 (UTC)

I have no opinion on the template proposal, but I want to point out that such links can already be made a little shorter with the “pipe trick”: typing [[Rockville, Maryland|]], [[Maryland]] avoids repetition of the city name while producing the same result, Rockville, Maryland. This should work for any title containing a comma or parentheses.—Odysseus1479 20:21, 19 May 2016 (UTC)

Why did you mean by "the standard usage"? If there were a standard (as in "standardized") way to link US cities, there should exist a policy or guideline regarding it and there is (to my knowledge) no such thing. (It's always risky making statements about non-existence so if I'm wrong, please correct me.) Yes, there's a common way its done, but that's different. Lacking an official way of linking US cities, people do it according to editorial judgment. With that said, if such a template were created WP:OVERLINK must be kept in mind. You wouldn't want to keep linking Maryland over and over again in some article mentioning many cities in Maryland. Personally I think templates introduce complexity to the wikisource that turns away new editors so we should often prefer slightly more verbose code if it's easier to decipher for non-wikitext experts. Unless we'd be dealing with many many cities, perhaps it's best just to use the longhand. Jason Quinn (talk) 21:38, 19 May 2016 (UTC)

It should be [[Rockville, Maryland]] giving Rockville, Maryland, see WP:SPECIFICLINK. There should be no need to use two links when one works perfectly well. If people don't know where Maryland is, they're not likely to know where Rockville, Md is either. --Redrose64 (talk) 22:32, 19 May 2016 (UTC)

Agree with Redrose64. If you intend the link the city, there's probably no good reason to also link the state. A template to make it easier to overlink is a bad idea. Dicklyon (talk) 20:45, 20 May 2016 (UTC)

Editors' Main Page

Idea: Start a sort of "main page for Wikipedia editors", essentially a combination of the Dashboard, the Signpost, and a few other features, such as these:

• Today's article in need of sources
• This week's stub for expansion
• An "In the news" type feature from the Signpost
• The Tip of the Day
• WikiProjects where the Main Page has portals (in the page header) Chickadee46 (talk) 23:59, 20 May 2016 (UTC)

• I think the Wikipedia:Community portal could use some updates instead. I'd probably drop the giant hunk of "things to do" to just above the motto and that kind of gets you what you're looking for. -- Ricky81682 (talk)`

Thanks! Yes, that's just about what I was looking for. Chickadee46 (talk) 00:41, 21 May 2016 (UTC)

Great. I'd hit the talk page and see if there's a better way to organize it to what you're thinking. As I said, the things to do section is quite busy. -- Ricky81682 (talk) 10:21, 22 May 2016 (UTC)

Additional Preference options for watchlist pages that have changed?

Moved to Wikipedia:Village pump (technical) § Allow additional Preference options for watchlist pages that have changed?

 – Redrose64 (talk) 19:51, 22 May 2016 (UTC)

Category Idea

Hello all!

I'm not sure if this is the right place for this. If not, I'll be happy to post in the proper place if you could tell me where that is!

I have an idea for categories. As I don't yet know proper terminology for either categorization or coding, I have an example which I hope makes my idea clear. I'll be happy to make more examples or talk to anyone who gets what I mean! :)

Now to the actual example.

Category "Law Museums in the United States" exists

Law Museums in United States = Law Museums in "CountryName" = "MuseumType" in United States

Automatically create 2 categories.

Law Museums in "Country" (which "Law Museums in the United States" will be moved to, and create empty categories "Law Museums in China", "Law Museums in Greece", etc.)

"MuseumType" in United States (which "Law Museums in the United States" will be moved to, and create empty "History Museums in the United States", "Science Museums in the United States", etc.)

JonathanHopeThisIsUnique (talk) 03:24, 23 May 2016 (UTC)

@JonathanHopeThisIsUnique: You posted substantially the same suggestion at Wikipedia talk:WikiProject Categories#Idea - per WP:MULTI, this is not good practice, so please decide which one should remain, and replace the other with a link to the one which remains. --Redrose64 (talk) 08:46, 23 May 2016 (UTC)

@Redrose64:Hello Redrose, and thanks for replying!

Sorry for the multiple similar suggestions in different places; I didn't know how to do them properly.

I want to keep the discussion in whichever place is the better one, but I'm not sure which that would be. If both are equally good, I'd like to keep it here. Also, I don't know how to do the proper links, and what else, if anything, I should do. I'd be grateful for help/link to relevant help page!

I really appreciate your help. :) JonathanHopeThisIsUnique (talk) 17:33, 23 May 2016 (UTC)

I've removed the other one. You make links by using double square brackets, as I did in my post of 08:46, 23 May 2016, more at Help:Link. --Redrose64 (talk) 20:05, 23 May 2016 (UTC)

Future Ping

I think it would be a great idea to setup either a future ping, or a webpage listing username, article, date and reason for ping. Many articles need to be updated after a certain date, and it's up to the editor to remember to go to that article and edit. If I know that in three weeks I will need to update, I should be able to either setup a future ping, or it might be easier to have a page with a bot that pings based on the entry. Sir Joseph ^(talk) 13:40, 23 May 2016 (UTC)

You might be interested in phab:T88781. Whatamidoing (WMF) (talk) 17:16, 23 May 2016 (UTC)

Thanks. That looks interesting, hope someone picks it up.Sir Joseph ^(talk) 17:28, 23 May 2016 (UTC)

We have {{Update after}}. Works by categories and a visual "dated info" tag rather than notifications, though. – Finnusertop (talk ⋅ contribs) 22:42, 23 May 2016 (UTC)

Also note the various general-purpose, free-of-charge reminder services available on the web. They send you an email at the date and time you specify, with the note you specify. Not at all of them sell your email address to spammers. I hesitate to suggest the one I use, but you can email me if you're interested, and there are probably others that are as good or better. I generally oppose reinventing wheels, where perfectly good wheels already exist. ―Mandruss ☎ 13:19, 26 May 2016 (UTC)

Collaboration Inquiry

Hi, all.

First of all, if here is not the correct place to post this, please just let me know. I'll be happy to move it.

Last year I created a website called BetterWaysWiki https://betterwayswiki.com/. It was created as a place where people can share better-ways ideas to do things. Sharing high-quality better-ways ideas, I think, will help to accelerate human advancement to achieve higher quality-of-life.

The website itself has the following key points behind it:

1. Its most basic idea is a container for formal articles that focus exclusively on straight away highlighting what are the available better ways of doing things that can actually benefit me (from the readers' point of view) and also how it benefits me (from the readers' point of view). This forces the contributors to first able to explain why and how the new ideas are more beneficial than the existing ones
2. Content to be attractively (hopefully virally) spread via social media.
3. Free, wiki-based and community-sourced.
4. To inspire new ideas that are far better and bigger; fast and continuously.

The About Us and Help pages can be found at https://betterwayswiki.com/us/ and https://betterwayswiki.com/help/ respectively.

I've posted a few articles on the website, and on hand, I still have a few hundred other potential subjects.

Undoubtedly I'll need a lot of help to grow the website to make it as valuable as possible to as many people as possible. After some thoughts and some consultations with Wikipedia community engagement staffs, I decided to pitch the idea here to try to get some valuable feedbacks, pointers and, hopefully, supports. For Wikipedia itself, I believe that BetterWaysWiki can help contribute to bringing in more visitors especially for niche and not yet widely known subjects - BetterWaysWiki articles are just summary of better-ways ideas; it almost certain needs to include links to other sources like Wikipedia for details of each component inside.

So please don't hesitate at all to give me your thoughts, questions or requests here as I'll consider it for the future of BetterWaysWiki. — Preceding unsigned comment added by 203.126.130.140 (talk) 10:19, 26 May 2016 (UTC)

Dealing with attack pages

I would like to open a discussion, prompted by an actual incident which may not be fixable but perhaps we can discuss how to prevent it going forward.

Most of you are aware that it is not difficult for an editor to create a brand-new page which contains blatantly false or harassing information. These creations are often detected early, tagged as CSD G10 and deleted quickly. The admin dashboard highlights any such candidate in red, and is one of the highest priorities for deletion. Because of this rapid response, it is possible that many editors have not run across such pages. However, in the course of a year the number of such pages probably numbers in the hundreds, perhaps thousands.

I see two potential problems. One potential problem is based upon my belief that Google is very quick to spider new pages and may be faster at this than in the past. I don't have specific knowledge about the Google process so I might be mistaken on this, but my impression is that if an attack page was deleted quickly in the past it might never show up in a Google search and if Google is quicker about adding pages to their list this might change.

However, that's not my main concern. My main concern is that we permit other parties to copy and reuse material from Wikipedia. Some of these third parties are quite aggressive and quite timely and make copies of such pages before they are deleted. In the specific case which prompted this discussion (which I will not link for obvious reasons) an attack page was created, deleted within seven hours of creation, but scraped by an outside party in the interim. A Google search of the subject's name brings up content, probably false but embarrassing.

While the official response appears to be that we have no control over third parties I think it is our moral duty to think through whether we can do better.

My off the top of the head thought is that we might change your procedure so that any new article created by some class of editors (perhaps unconfirmed) is non-indexed and not subject to the creative Commons license until it has been reviewed by the NPP.

I fully realize this is a nontrivial concept, and might require changes to the media wiki software, but I'd like to find some way so that if some third-party does scrape such content we have a legal basis for requesting removal.--S Philbrick(Talk) 13:27, 26 May 2016 (UTC)

Google indexes new pages so quickly that I've always assumed they were scraping Special:Newpages or one of its equivalents. All of those are already noindexed, so if we flag unreviewed new articles as noindexed too, the cynic in me says that'll also get ignored. —Cryptic 03:05, 28 May 2016 (UTC)

I suspect that there's a difference between "spidering a noindexed page to find pages that aren't noindexed" and "adding a noindexed page to Google as a search result." (Not in the least that the former is slightly hard to prove, whereas the latter is glaringly obvious.) So I wouldn't be surprised if Google respects noindex on the pages even if it doesn't respect it on Special:Newpages. In any case, there's no real harm in noindexing new articles until they've been reviewed, since reviewing is incredibly fast and will be near-instantaneous for anything dealing with major breaking news (which is the only case where the difference of a few hours before a page is indexed is likely to matter.) --Aquillion (talk) 04:12, 28 May 2016 (UTC)

@Cryptic: Interesting point, but that may be testable, if I understand correctly. We could create a test article, make sure it is no-indexed at creation, and see if it is scraped by Google. I can be cynical, but I think our relationship with Google is solid enough that if they are indexing a no-indexed article, they will fix it.--S Philbrick(Talk) 18:14, 28 May 2016 (UTC)

I'm reasonably sure that they wouldn't index such a page now; my cynicism was for what I'd expect them to do after we started noindexing all new pages.

Back on subject, or at least closer to it—we might get some benefit from removing the {{noindex}} transclusion from {{db-g10}}, so that search engines, mirrors, etc. have at least some chance of picking up the current revision (which should just be the speedy template, with the original attack page blanked). I don't have even anecdotal data on how quickly they pick up changes to new pages they've already indexed, though. —Cryptic 23:17, 28 May 2016 (UTC)

Ah, I catch your point - I agree.--S Philbrick(Talk) 22:44, 29 May 2016 (UTC)

Ability to Move Questionable New Pages to Draft Space

There is currently a discussion at WT:New pages patrol about dealing with skeleton articles with very little content by new editors. At present these articles are commonly proposed for deletion. The only policy question is how long should a new page patrol reviewer wait before proposing these articles for deletion. The question has been raised of whether PRODding these articles is biting the newbie, and whether some other approach should be taken. One idea that has some support is that a reviewer should be able to move an article from article space to AFC draft space if it clearly isn't appropriate for article space. Since there is presently no rule saying that this can't be done, but no rule saying that it can be done, it will be a case of Ignore All Rules. However, if rules need ignoring on a regular basis (rather than a one-time basis), then maybe rules should be changed. Moving new articles by new editors that clearly don't belong in article space into draft space seems to me to be a reasonable compromise, neither going too far to encourage new editors and avoid the dreaded "bite" nor being too aggressive toward new editors. Comments? Robert McClenon (talk) 02:15, 28 May 2016 (UTC)

You might want to take a look at Wikipedia talk:Drafts#RFC: Clarification over main-space to draft-space moves, which closed without consensus fairly recently. —Cryptic 03:00, 28 May 2016 (UTC)

This is a foolish idea. AfC, as I have described previously, is undermanned and is not designed to work as an incubator or filter for substandard articles in the article namespace. The suggestion that PROD'ing new articles is BITEy behavior seems ludicrous to me. Almost every time I nominate an article for deletion the n00b editor makes a WP:OTHERSTUFFEXISTS argument, because too much of the content on Wikipedia is sub-standard therefore creating the impression that substandard content is fine here. AfC is not project to adress the community's collective lack of backbone. Chris Troutman (talk) 11:10, 28 May 2016 (UTC)

I agree with Chris above. If editors new or old want to bypass AfC in getting their article to mainspace, they are taking a conscious risk. They should know what mainspace is for and that failing to adhere to certain standards results in deletion. I find it improbable that new editors – those who have demonstrated not being keen on AfC by moving their article to mainspace directly – would be interested in making effort within that very process if their substandard article is moved there.

We should consider what is the profile of editors who won't through AfC when they clearly should have. Are they editors who are frustrated by AfC declining their drafts over and over again? Maybe, and these are exactly the kind of editors who either need to go through AfC or face the possibility of deletion. I'm not talking about giving them a lesson or punishing them – if they keep moving bad content to mainspace it's proof that they are immune to either. Ultimately, we are here to build an encyclopedia. To that end, keeping mainspace clean is paramount, and reserving AfC for people who actually listen to advice is also a priority. – Finnusertop (talk ⋅ contribs) 11:40, 28 May 2016 (UTC)

Thank you. So is it the opinion here that very inadequate articles by new editors that would otherwise be proposed for deletion should be proposed for deletion? There is argument about how quickly new articles should be in NPP before deletion tagging (e.g., immediately, 10 minutes, an hour), but is it being said that very inadequate articles by new editors should be treated like very inadequate articles? Does that mean (and I agree) that keeping crud out of the encyclopedia trumps the "bite" guideline? Robert McClenon (talk) 14:01, 28 May 2016 (UTC)

This proposal is a really really really bad idea. Draftspace is already full of clutter, of problematic BLP, promotional, possible copyvio etc material, that sits there for months and years and is very difficult to remove. We should not create new mechanisms for increasing the amount of that clutter. There is actually an open RfC at Wikipedia:Village pump (policy)#RfC: Proposed draftspace deletion about possible extra ways of deleting pages from draftspace. While that RfC is not likely to succeed in its current form, it does show a considerable sentiment for doing something to make deletion of problematic draftspace pages easier (Right now G13 only applies to AfC pages, so MfD is the only option for deletion, unless some other CSD criterion applies). PRODDing a new page in mainspace, even within a few seconds from its creation, is not really particularly bitey. There is no immediate risk of deletion, and the creator of the page has 7 days to improve the page - plus he/she can just unPROD the page. Leaving the new page in the mainspace, with or without the PROD tag, makes it much more likely that other users will notice it, and will either help to improve it to some minimally acceptable standard, or CSD/AFD the page. On the other hand, if the page is quickly moved to Drfatspace, it will most likely just fester there for weeks, months or years will little or no attention from other users. The end result will likely be the opposite of what the authors of this proposals intend. Nsk92 (talk) 15:44, 28 May 2016 (UTC)

• I second Chris troutman. AfC is meant, in short, to review articles for their mainspace aptitude. Flooding us with non-suitable drafts is not going to improve anything. If I come across a poor draft while reviewing, I will continue to decline them and offer the user feedback, but I don't see how moving a ton of drafts from one place to the other will in any way improve its chances if the editor isn't keen on improving them or if the subject is non-notable. Best, FoCuS contribs; talk to me! 18:24, 28 May 2016 (UTC)
• I disagree with the proposal but I would accept a greater encouragement and detailed explanation for when admins can userify/draftify a page that has been deleted. Currently that can be done after an AFD and otherwise admins can take deleted content and do that. It should also be a consideration if a prod has expired but deprodding it and moving is just as bitey to me as deleting it. From there, AFC can be a consideration but it should be the choice of the creator not other people. Someone who doesn't care to listen to an admin or anyone else who says that the page isn't sufficient is just going to make AFC miserable. -- Ricky81682 (talk) 19:07, 28 May 2016 (UTC)

I'll spit a couple points into the wind here. We're not going to create an unsustainable AfC clutter with this proposal. A new article in mainspace that would otherwise be proposed for deletion will be converted to an unsubmitted AfC draft. If the author chooses to improve and submit the article to AfC, they may. If they do not, it will be deleted in 6 months per G13.

I feel that those participating in this discussion are overestimating the capabilities and thickness of the skin of new editors. I don't think we can assume that they fully appreciate what's required to get past NPP (or AfC). The difference with NPP is that they aren't really given an opportunity to learn when their submission is summarily tagged to high heaven several minutes after submission. Also nothing about the assertion that promptly nominating new articles from new editors is not bitey is ringing true for me. I can't imagine how that experience wouldn't be disheartening. ~Kvng (talk) 03:26, 29 May 2016 (UTC)

The potential harm possibly caused by pricking the skin of some particularly thin-skinned newbies when their articles are PRODDED is a true infinitesimal compared with the great harm that implementing your proposal would actually create. But consider a different point. Most newbies have no idea what draftspace is and will not understand what happened if they see their article yanked out of mainspace and moved to draftspace. Most likely many of them will regard that act as a form of deletion, and will be not simply pricked but actually bitten by it. Nsk92 (talk) 05:25, 29 May 2016 (UTC)

• AfC is a voluntary process. Editors, new or not, don't have to submit their pages (even though it's strongly recommended for COI editors). That's the way it should stay, because AfC only works if the editors read the reviews, make appropriate changes and resubmit. We have two areas besides mainspace for drafting articles: User subpages, appropriate when a single editor is starting a new topic, and Draft space, where editors can work together to get a page up to minimum standards. There's really no point in moving a problem article into either of these spaces unless (1) there is at least one editor interested in improving it, and (2) the topic meets Wikipedia's standards for inclusion in the first place. The best way to determine these things is with the usual processes - PROD, Speedy deletion tagging or AfD, depending on how problematic the article is, with appropriate notifications. The page may still end up being userfied, moved to Draft space or put through AfC, but with less chance of it being abandoned. I can see two situations, though in which an editor from NPP might shortcut the process and move a very inappropriately written article on a good topic to Draft space: one would be if there had been a discussion with the article's creator, who agreed to keep working on the draft; the other would be if the originating editor was no longer active and the NPP editor was planning to fix up the page personally, but couldn't do it right away. This would take up a lot of time and I don't think it would happen very often.—Anne Delong (talk) 13:16, 29 May 2016 (UTC)

I am of two minds on this issue. I think it would be beneficial to have this as an option for NPP reviewers however I am mindful that this can be seen as a kind of 'back door delete'. I believe the primary purpose of NPP is to insure that new articles meet a certian minimum standard. In most cases, where there is an editor who is activly working on a new article PROD is useless and stubbing the article will be restisted as well. In those cases moving to draft is the best option and I believe forming some consensus to allow this will help avoid IAR drama down the road.

As to the matter of 'filling up AfC' I believe this is less of an issue because the only articles I thing this should apply to are ones where there is an active author. If there is no active author stubbing is, in my opinion, the proper solution for an article likely to pass notability and PRODing otherwise. (This assumes the article is not caught in one of the 'mass dePROD' events - then we end up clogging up AfD. I also note I get more complaints about AfDing articles which could have been PRODed than vice versa.) Jbh^Talk 13:31, 29 May 2016 (UTC)

How are technical changes implemented?

I'm thinking of proposing something that requires technical coding etc to implement..(creating a log of the history of all unblock requests going forward showing whether they had been granted/approved to increase transparency)..if people thought this was a good idea how would it go about being implemented (who would code it etc...I certainly don't know how)..68.48.241.158 (talk) 13:12, 28 May 2016 (UTC)

This could be done now with Wikipedia:Tags. --Izno (talk) 15:36, 28 May 2016 (UTC)

the idea would be to create a page that would list all unblock requests (perhaps all blocks too) and also whether they had been granted or denied...so people can scan down and take a look with links to the talk pages...this can be done with what you suggest above? who creates this if it's improved as an idea?68.48.241.158 (talk) 16:09, 28 May 2016 (UTC)

If you click on WP:RFU you will see a table of the open unblock requests. If the user's request is declined or if they are unblocked, the user disappears from this list. Possibly this is what you wanted. For the list of all current blocks, see Special:BlockList. The record of all blocks ever issued can be seen in Special:Log. EdJohnston (talk) 17:01, 28 May 2016 (UTC)

but there's no transparency because you can't see the total history of unblock requests..and have any sense whether they are being handled appropriately over time/be able to take a look at ones from the past....I'm concerned there are a small number of block happy admins dealing in this area and they are chasing off potential new editors to Wikipedia...68.48.241.158 (talk) 17:18, 28 May 2016 (UTC)

i'd like to see a log like the one you linked to but dealing with the history of unblock requests..68.48.241.158 (talk) 17:20, 28 May 2016 (UTC)

You can see the history of open unblock requests here. When they are removed, they have been declined or accepted, but you can't tell what happened without going to the user's talkpage. -- The Voidwalker ^Discuss 17:28, 28 May 2016 (UTC)

right, that's the problem...but I'll have to bring that up elsewhere first...I was just curious how something that needs a technical implementation is implemented...68.48.241.158 (talk) 17:29, 28 May 2016 (UTC)

There is plenty of transparency, it is just not indexed the way you like. Unblock requests are tracked through categories, and while the software does track what pages are in a category now it does not log when they are added and removed.

This means you can get the information but it will take some effort on your part. There is the block log, this logs every block and unblock. Choose your time period, look up all the blocks, then go through the talk page history on each one to see how it turned out.

This will take some work so I guess it depends on how much you want this information. We do have an API if you want to try and automate it. HighInBC 17:35, 28 May 2016 (UTC)

right, there's no transparency because one would have to jump through major hoops to get any big picture sense of what's going on...but that's a debate for later and elsewhere...I'm trying to learn how things like this are implemented technically...what is API? I'm not personally experienced in any way at coding..would I be responsible for putting it in place?68.48.241.158 (talk) 17:41, 28 May 2016 (UTC)

Since you appear to be the only person who wants this, then yes, you would have to do it yourself unless you can persuade someone else to do so; the WMF devs are not your slaves. As HighInBC correctly says above, this is a complaint that you don't like the way we currently index the information in question rather than a question of the information being somehow hidden, so "transparency" doesn't come into it. ‑ Iridescent 17:58, 28 May 2016 (UTC)

because I said anyone is my slave...and we're even discussing a proposal here..thanks for the helpful and thoughtful post!!68.48.241.158 (talk) 18:07, 28 May 2016 (UTC)

It's actually possible to watch addition and removal of pages in categories now. Create an account and log in. Go to Category:Requests for unblock‎. Click the star tab to watch the category. Click Watchlist. If the "Hide:" line has a check mark at "page categorization" then remove it, or change the setting permanently at Special:Preferences#mw-prefsection-watchlist. You can watch up to 30 days back. PrimeHunter (talk) 23:08, 28 May 2016 (UTC)

okay, that's interesting...still don't think it solves the transparency issue I'm after in terms of a straightforward log that memorializes it all going forward so people can get a sense of what's going on..68.48.241.158 (talk) 00:37, 29 May 2016 (UTC)

The mw:API is a means to access the logs and content of Wikipedia through an automated tool. I don't think anybody is going to do your research for you, but the information is there if you want to get it. HighInBC 18:14, 28 May 2016 (UTC)

(edit conflict) I'd also add that I don't think you have any idea of the scale of what you're suggesting, when you talk about logging every unblock—let alone every block—at a single page. As of June 2014 (which is when the logs stop for technical reasons owing to the Labs move), 90,165 unblocks and 2,693,123 blocks had been performed. ‑ Iridescent 18:17, 28 May 2016 (UTC)

trivial as far as data size..still interested in learning how technical tools are implemented if it's been determined by consensus that they are desired...are there tech people that volunteer to code things or what?68.48.241.158 (talk) 18:27, 28 May 2016 (UTC)

There are basically 2 mechanics - either someone writes a tool to perform their analysis and post results (possibly a bot that you can request someone else create and run if they want to at WP:BOTREQ) or you get programmers to create a module and load it, or change the core mediawiki software to do something like this for you by creating a Wikipedia:Bug reports and feature requests. — xaosflux ^Talk 02:21, 29 May 2016 (UTC)

okay, for example. above someone linked to "Special:blockedlist" which has all current blocks...this is a page/function that must not have existed at some point in time and was then created...how was it created and by who?68.48.241.158 (talk) 13:04, 29 May 2016 (UTC)

Hello User:68.48.241.158 I think you are referring to Special:BlockList. That display contains a list of blocked users, merged with information from the block log. I don't know the name of what developer wrote that code, and it has been part of the core for what seems to be at least 10 releases. You may want to follow up on mediawiki-l to see where to find the history of that section of code.

Changes to the functionality of the blocklist are normally going to be outside the scope of the English Wikipedia, as they affect the software base - not the encyclopedia project. You can propose changes or enhancements to the software here: Wikipedia:Bug reports and feature requests ("Requesting a change" and "Reporting a bug" are basically the same thing - the creation of a "task" that software developers can choose to pick up or not). If you are a programmer, you can pick it up your self and get to programming, then request your new software section be merged to the main code base, or added as an extension. While I do report "bugs", I'm not currently involved with programming so don't have a lot of details on the "how" of all of the steps.

As to your idea, "unblock requests" are not really something that exists as far as the software is concerned - they are just edits; and they don't necessarily always occur as edits, unblocking requests can also be made by email, via UTRS, on IRC, etc.

If you want people to come up with ides for changing how these requests are processed careful consideration of all options will need to be decided. Also, are you only trying to solve this for the English Wikipedia? Rolling in software changes is something that affects everyone who uses mediawiki - thus the care needed. Additionally, if you want this to be consistently usable, you would need the community to agree to a policy that a specific mechanism must be used to the exclusion of others, and I don't think you would get much support on that.

— xaosflux ^Talk 17:30, 29 May 2016 (UTC)

thank you for the excellent info and thoughtful reply.68.48.241.158 (talk) 17:44, 29 May 2016 (UTC)

(edit conflict) Under its old name of Special:IPBlockList (despite the name, it was always a list of all blocked users), it's been a part of MediaWiki since Nupedia days, back when Wikipedia was small enough that Jimbo approved the blocks personally. If you're interested, User:Throbbing monster cock appears to have been the first registered account to be blocked from Wikipedia. ‑ Iridescent 17:56, 29 May 2016 (UTC)

• We have parallel threads going here and at Wikipedia:Village pump (proposals)#Unblock Requests Transparency. This goes against WP:MULTI. --Redrose64 (talk) 13:04, 2 June 2016 (UTC)

Locking Involved Sport Players During Big Final

As seen with Yannick Ferreira Carrasco (forgot how to add link as I'm watching final now), it's become quite noticeable in and out of Wikipedia that during big sports finals, especially football,with the Euro's coming up aswell you get people changing names short facts and intros. I think that maybe we should consider blocking sports personals involved. Though I'm not sure if it will be possible to implement or really stop the problem. I'm sure we'll see changes to the wikipage of the player who scores the winner.

Pages are only protected when persistent vandalism has occured, not per-emptively. See WP:NO-PREEMPT. Protection is done on a case-by-case basis and not blanket topics. – Finnusertop (talk ⋅ contribs) 22:03, 28 May 2016 (UTC)

Also, during major sporting events is exactly when we don't want to lock the biographies of the players involved, since by definition that's the period when there's most likely to be new information published about them. ‑ Iridescent 17:33, 29 May 2016 (UTC)

Prevention of Link Rots

Link rot is starting to become prevalent in many articles with references to old blog posts that no longer exist. My idea is to start using Internet Web Archives as a way to keep the cited resources available for others to access and refer to.

For example: See this article's 1st reference link. If you click on the first reference link, it will link you to "Page not found" error page. This is an issue if Wikipedia continues to cite resources without the ability to obtain a snapshot of what the resources look like.

Tom mai78101 00:25, 30 May 2016 (UTC)

@Tom mai78101: addressing this problem came up #1 in the wishlist survey a few months ago, and it’s being tackled; see the Meta page for progress reports. There is also a related thread on m:Wikimedia Forum at the moment.—Odysseus1479 05:09, 30 May 2016 (UTC)

@Odysseus1479: Thanks for letting me know about this. Tom Mai (talk) 16:43, 2 June 2016 (UTC)

Create a "history merger" user group

Around 2 weeks ago, there was a proposal at Wikipedia talk:Page mover to include the mergehistory right in the user group. However, this proposal was generally shot down by the community, mainly because the two rights are very different to each other. That's why I'm putting forward the idea of creating a new user group, specifically for history merges. There are very large backlogs at both Wikipedia:WikiProject History Merge and Category:Possible cut-and-paste moves, some of which go years back. Few admins are active in those areas, so I feel that the creation of this permission would help to clear the backlog. This user right would be especially helpful for those who constantly find themselves tagging articles with {{histmerge}}, but unable to perform the merge themselves. Omni Flames ^{let's talk about it} 07:07, 31 May 2016 (UTC)

• Can this be done without giving non-admins deletion and page restoration rights? I don't think this is technically feasible. I think a better proposal would be to sort those by date. Wikipedia:Requests for history merge works pretty fast and doesn't seem to have a backlog so we may just need to start listing the oldest ones there or something. -- Ricky81682 (talk) 08:25, 31 May 2016 (UTC)
  • Actually it seems more like they just need to be checked. That doesn't require an admin. The bot may been over-enthusiastic about tagging. -- Ricky81682 (talk) 08:31, 31 May 2016 (UTC)
• I generally support unbundling, but I think this one will be hard. To make this into a proper right you must also have delete/restore permissions. For legal reasons the WMF requires that the community does an RfA-like review process before handing out those permissions. History merges are also one of the very few actions that cannot be reverted (without great effort), so the the bar for handing out this permission is going to be higher than template editor/page mover. I think few people would pass these hurdles, but wouldn't pass an RfA? —Ruud 09:41, 31 May 2016 (UTC)
• Would tend to agree that history merges can be pretty darned tricky! The admins who handle them on a regular basis are some of the ones I admire most.  OUR Wikipedia (not "mine")! Paine  11:21, 31 May 2016 (UTC)
• These certainly can get messy - it may be possible to use Special:MergeHistory - but complicated or messy mergers require delete/undelete access - and the "undo" process can be a nightmare. — xaosflux ^Talk 13:18, 31 May 2016 (UTC)
• I generally agree with most unbundling proposals, but I also think this is one that is technically infeasible. As others have mentioned, mergehistory requires (or implies?) being granted deletion and restoration rights, and due to actual legal implications the bar to be granted those permissions is quite high; WMF has stated they want users to pass "an RfA-like process" before being granted those permissions. Along with sorting as Ricky81682 suggested, it might be a good idea to train some users to clerk the requests, if we think that there are some that aren't actually history merge candidates, or are otherwise problematic. Ivanvector 🍁 (talk) 14:29, 31 May 2016 (UTC)
  • Clerking for this is an interesting idea, if it'll help with the backlog – I might even been interested looking into that, if training went along with it... --IJBall (contribs • talk) 20:05, 31 May 2016 (UTC)
• I'm a strong supporter of unbundling, but this (along with page deletion and blocking) is one of the few things I don't think should be unbundled. If we're looking for a "next" thing to unbundle, I'd recommend page protection given the frequent small backlog at WP:RFPP and the time-sensitive nature of such requests (with the bright line that protecting any page you've edited is grounds for immediate removal of the user right). ~ Rob^Talk 16:18, 31 May 2016 (UTC)
  • NeilN, who was one of the more active Admins at RfPP before he went on work-related hiatus, wasn't much in favor of spinning out a "Page protector" unbundle. I suspect there would be far more (Admin) "pushback" against a Page protector unbundle proposal than there was against Page mover (which actually went pretty smoothly...). --IJBall (contribs • talk) 20:10, 31 May 2016 (UTC)
    • @IJBall: Oh, I have no illusions that it would be easy (or even doable) right now. But things are slowly changing for the better. I've been here a year now and the environment at RfA and regarding user rights is markedly different than it was when I arrived. The biggest progress has been made in non-admins quietly taking on tasks once done almost exclusively by admins. Take TfD as a case study. Here's the backlog at the start of an RfC on allowing non-admins to close TfDs as delete. It's a tad hard to see exactly how many discussions were open since the transcluded pages have since been closed, but you can see just how far back it went. And lots of them were open, it wasn't just one per date in most cases. Now check out the backlog at WP:TFD today. It doesn't exist almost exclusively because non-admins have taken over a role that was under-served by the administrator population. ~ Rob^Talk 05:44, 1 June 2016 (UTC)
• Hmm, this one is hard. On one hand, this new right would help clear backlogs, but on the other hand, it has the potential for even worse abuse than page mover has. I don't know whether this right would be used frequently, anyway, or if it's going to be one of these relatively little-used, mostly temporary rights like account creator. Kylo, Rey, & Finn Consortium (formerly epicgenius) (talk) 02:04, 1 June 2016 (UTC)
• Let's take a clearer look at the reason given to demonstrate a need for this right: Wikipedia:WikiProject History Merge has large bot-generated lists of what a bot believes are cut-and-paste moves. Category:Possible cut-and-paste moves contains a large bot-generated list of possible cut-and-paste moves that a now inactive bot thought were cut-and-paste moves. Any user can look through those pages and apply {{histmerge}} to the positive results, which adds them to Category:Candidates for history merging (which currently has no backlog), where requests are generally handled promptly. There is no real need for this user right, or at the least, one has not been expressed here yet.—Godsy^(TALK_CONT) 03:38, 1 June 2016 (UTC)
• Agree non-admin history merging would be tricky. Folks make a good point that this is bundled with delete/restore permissions... and there's no precedence for that I think. While the backlog is huge, I'm thinking that it should be left (for now) to the admins more experienced in the field. If the WMF is involved here, perhaps it also makes sense to hold off on taking any action until it's clearer for them what the approach will be. FYI, the aforementioned RFC is still open. Someone can probably close it around now — Andy W. (talk · ctb) 18:36, 1 June 2016 (UTC)
• I've done history merges. Such a merge is a messy activity and potentially uses a lot of the admin tools. It is something that would be hard to unbundle. Since revisions can disappear due to a history merge, such a merge is about as sensitive as WP:Revdel in its overall effect. As User:Godsy points out, pages that someone tags with {{histmerge}} tend to be handled promptly and there is seldom a backlog. Unless the guy who does most of the history merges is on vacation. EdJohnston (talk) 21:19, 1 June 2016 (UTC)
• Including, if history-merging X to Y, what to do with Talk:X and Talk:Y and all their possible multifarious sub-pages. And what to do if X and Y are WP:Parallel histories with each other or with already-existing deleted edits sitting under the undeleted edits. Anthony Appleyard (talk) 21:33, 1 June 2016 (UTC)
• Oppose If a user is given the right to perform some action, then the user should also be given the right to reverse the action. In order to reverse a history merge, the user needs the delete and undelete tools and lots of patience. --Stefan2 (talk) 21:53, 1 June 2016 (UTC)

• Stefan2, you do realize that this is VPI right? This page isn't for oppose/support, but rather it's for developing and discussing ideas. Did you even read the heading? "Stalwart "Oppose" and "Support" comments generally have no place here". Omni Flames ^{let's talk about it} 22:02, 1 June 2016 (UTC)
  • Omni Flames, see WP:NOTAVOTE. The use of 'oppose' and 'support' at the beginning of a line never carries a meaning. It's always the rest of the text on the line which matters. --Stefan2 (talk) 22:20, 1 June 2016 (UTC)
    • @Stefan2:Actually, each merge log entry has an "Unmerge" link at the end; All a merger would need to do is use that link, click the merge button at the bottom, and the old history will be back where it came from. The only issue is that these merges must be undone in reverse order to when they were done if the same pages are involved. There may also be a redirect revision trhat needs to be reverted afterwards (if all the revisions have been merged away), but I doubt that mergers would run into this issuer a lot. עוד מישהו Od Mishehu 11:59, 2 June 2016 (UTC)

• It's a great idea to allow experienced non-admins to use the tools available with the mergehistory user-right. It's limited enough that incompetence can be easily un-done by an administrator (and the bit summarily revoked). I would be even more enthusiastic about giving wider access to an even-more-limited tool that only allowed merges where the edit history was completely non-overlapping (which is the typical case for cut-and-paste moves) and where the actions were written to a log that could be easily watchlisted to spot incompetence (or simple one-off goofs). This would be very low-risk and would free up administrators to do the more complex merges. As someone who has slapped {{histmerge}} on many a page that was copy-and-pasted from an WP:Articles for creation submission or a draft article, and as the person who added the |details= parameter to the histmerge template back in 2013, I would find having this userright very helpful to me and very helpful in freeing up the time of administrators who do the simple history merges today because nobody else can. davidwr/(talk)/(contribs) 03:26, 2 June 2016 (UTC)
• Here's an example of how an E-Z limited history merge user right might work: Write code or an external tool which would:

• Verify that the two pages have completely non-overlapping histories
• Verify there are no protection issues (such as the editor not being able to write to both pages, or the pages having non-identical permissions) that would warrant administrator intervention
• Merge the histories
• Create a redirect page with a new {{redirect to newer history-merged page}} template, which would include parameters linking to the oldest and newest edits of the "old page" (the page where the redirect now lives) and the oldest edit of the destination page prior to the move.
• Log all of the above details in a public log that can be patrolled
• Optionally, if the editor opted in, log all of the above to the editor's own user-sub-page log (editors considering a future RfA may want to do this)
• In addition, the tool would have a built-in undo feature: Within a short time period (say, 1 hour), the editor could "undo" his actions in an automated fashion. This would take some coding but it would not run afoul of the WMF's rule about non-admins seeing deleted edits. It would need to delete the redirect, but as the redirect was created by the editor in question and one it was deleted, only an admin could bring it back, I don't see the Foundation having any issues. The "undo" feature wouldn't be available if certain things had happened in the meantime, such as if either the original source page (now a redirect) or target had been moved or deleted or had their permissions changed or if the original sourced had been edited at all.
• For convenience, any administrator could use the "undo" feature without regard to the 1-hour (or whatever time period it turns out to be) time limit.

davidwr/(talk)/(contribs) 03:45, 2 June 2016 (UTC)

• The apparent acronym "E-Z" hereinabove should be replaced by plain explicit "easy", if that is the meaning. Here in Britain I (and likely many others in Europe) read it first as "ee to zed" and was wondering what the letters stood for; plus association with the expression "A-Z" meaning "all the alphabet, complete". Anthony Appleyard (talk) 04:49, 2 June 2016 (UTC)
• And cases where the pretext and/or the posttext have heads and/or tails of redirects (sometimes mixed with bot edits and cut-and-paste-and-revert sequences) which are WP:Parallel histories when the useful edits with text are not parallel. And check first for existing deleted edits. Anthony Appleyard (talk) 04:56, 2 June 2016 (UTC)
  • When fixing WP:NFCC#9 violations, I've come across lots of files which are used in both the article namespace and in the draft namespace, and where it may be beneficial to merge the draft to the article. Very often, the draft may have one late edit where a bot comments out some categories, but in that situation it may still be beneficial for the project to merge the pages (as long as the late bot edit isn't included in the merged content). This seems to be an example of the kind of complex mergers with parallel histories which you mention. I'm not sure that these mergers can be fixed with the special page which this user right grants access to. I suspect that the delete and undelete tools are needed here. --Stefan2 (talk) 12:23, 2 June 2016 (UTC)

• It's a nice idea, but in practice this won't be very helpful. My experience with mergehistory is doing incomplete merges that time out my browser and need to be fixed by delete --> move --> undelete in the end anyway. There are very few cases in which it actually works, and I would - as usual - prefer that RfA be fixed rather than more partial unbundling which would still require the calling in of admins to do much of the work. Ajraddatz (talk) 04:57, 2 June 2016 (UTC)

Customized templates to deal with specific and persistent problems.

• Proposal withdrawn, and thanks so much to Finnusertop for making me aware of editnotices. Mmyers1976 (talk) 16:13, 31 May 2016 (UTC)

I would like to propose a new policy/guideline of allowing the customization of templates to deal with persistent and specific editing problems on articles that are not covered by general templates. The main type of problem this would address is when multiple editors pass through an article and make the same good faith but incorrect edit to an article. An example is Berenstain Bears, where there is an ongoing problem of people thinking they are correcting the spelling of the name by changing it to 'Berenstein. As I assume good faith, I assume most of the people who are doing this are simply failing to check the talk page before making this edit, and therefore are unaware that the regular editors of this page have confirmed the correct spelling multiple times. A template at the top of the article might prevent these good faith edits, something like this is what I had in mind:

I have discussed this with one other editor on the talk page, her main objection seems to be that there is no precedence for this, but I believe that WP:BOLD and WP:IGNORE may apply, as at one time certainly all of Wikipedia's now-standard practices were innovations. But perhaps new policy or guideline allowing such customized templates but giving criteria for their use and format would prevent prevent forseeable problems. Can anyone think of possible problems with this and possible guidelines to prevent those problems? Mmyers1976 (talk) 15:49, 31 May 2016 (UTC)

What's wrong with editnotices? E.g. editing the article Muhammad displays this editnotice. In contrast to maintenance templates, they are not displayed to all readers but just to people who click to edit. They also reach editors who fail to check the Talk page. – Finnusertop (talk ⋅ contribs) 16:00, 31 May 2016 (UTC)

I don't see the issue with putting that on the talk page. Many article talk pages have a message to the reader customized for that specific page. Sir Joseph ^(talk) 15:55, 31 May 2016 (UTC)

Talk page notices, and editnotices are the way for this, and maybe html comments in the text for some extreme situations. Article content should be primarily for the benefits of the readers, and this doesn't really provide them a benefit. — xaosflux ^Talk 16:09, 31 May 2016 (UTC)

Wow, I had no idea that editnotices are even a thing. These seem to address the problem perfectly, thanks so much! Mmyers1976 (talk) 16:10, 31 May 2016 (UTC)

@Mmyers1976: Please note, that to get one made you should have to place a request. One of the template editors will be able to action it for you. — xaosflux ^Talk 16:20, 31 May 2016 (UTC)

Interactive Globe

It is generally accepted that different map projections create wildlify different impressions from the same data Gall-Peters Projection, Mercator Projection, Dymaxion Map.

The suggestion is to create a simple interface to which a user can upload a map created in a one of a range of projections, dragging their map to fit over a 'template' of that projection. This would then automatically re-project the map onto a simple globe that could be manipulated in an online viewer using the mouse.

Clearly this would involve some effort, but the storage space for processed maps need not be significantly larger than the original files, and the viewer could be quite light.

The final implementation would users to process maps already uploaded to Wikipedia and place a clickable 'view as globe' icon next to any, map on a wikipedia page that had been processed.

Stub Mandrel (talk) 06:55, 1 June 2016 (UTC)

Integrating New Research Findings.

New reliable research findings are published regularly. See, for example the PLoS – Public Library of Science at: http://www.plos.org/ and many otters mentioned at: https://www.lib.utexas.edu/engin/guides/alumni.html

When Wikipedia becomes a complete repository of the world’s knowledge, then each of these newly published research findings will: 1) confirm an existing knowledge claim, 2) introduce a new knowledge claim, or 3) cast doubt on an existing knowledge claim.

I recommend we begin thinking about this influx of new knowledge systematically. For example, if Wikipedia provided a place where each newly published journal was analyzed, then each new article could be (tentatively linked) to the corresponding existing Wikipedia page. For example there is a recently published research paper titled: “The Great Migration and African-American Genomic Diversity” See: http://journals.plos.org/plosgenetics/article?id=info:doi/10.1371/journal.pgen.1006059 If this article presents new and reliable findings, then these findings have some bearing on the existing Wikipedia article on these subjects such as Great Migration (African American)

Under this proposal, the existing Great Migration article might have a (dedicated) Talk page section that links to the newly published research article. This link would have been created (semi-automatically) by the person who browsed the new research article. Over time, editors of the existing article can evaluate the newly published research to determine if it warrants a citation within the existing article, or requires the text of the existing article to be altered to reflect these new findings. In any case, interested readers can browse these newly published research articles to stay up-to-date on the topic. --Lbeaumont (talk) 13:18, 1 June 2016 (UTC)

We need a lot lot more volunteers to look at all those new papers. The idea is good in principal, and for example I use a Google scholar alert on several topics (eg langbeinites) and can then update articles I have written. Before we can just apply deltas from new publications, we first have to have 100% coverage of the knowledge in old publications. Perhaps a librarian can assess this for the whole of Wikipedia. I suspect Wikipedia is still less than 1%. For some narrow topic we may be able to have 100% coverage though. We also have the deletionists and minimalists that think a lot of what is published is not worth reporting in Wikipedia, or is too deep or technical for existing articles. However I believe that we need to have Wikipedia broader and deeper in knowledge. Graeme Bartlett (talk) 00:36, 2 June 2016 (UTC)