Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia
  (Redirected from Wikipedia:PROPS)
Jump to: navigation, search
  Policy   Technical   Proposals   Idea lab   Miscellaneous  

New ideas and proposals are discussed here. Before submitting:

« Older discussions, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125
Centralized discussion
Proposals: policy other Discussions Ideas

Note: inactive discussions, closed or not, should be archived.

Regulation Committee and alternatives to consensus[edit]

Bumping thread for 30 days. ceradon (talkedits) 04:22, 2 August 2015 (UTC)

Members of the community are invited to give their thoughts at a request for comment to discuss Wikipedians' alternatives to consensus, and the formation of a proposed Regulation Committee. Thank you, --ceradon (talkedits) 04:20, 2 August 2015 (UTC)

I would like to put a timeline on a wikipedia page[edit]

Maybe a timeline of American history.

Something like this:

All I have to do is get the following <script> and <div> tag on to one Wikipedia website, to test it out. It looks like this:

<script src="" type="text/javascript"></script> <div id="TheTimelinePlace"></div>

Can I test this on one page?

Jroehl (talk) 20:03, 14 August 2015 (UTC)

  1. No. We're not going to automatically load any script from some other server – a server that has a different privacy policy and could change the script at any time without us knowing about it.
  2. Perhaps you'd like to look at Category:Timeline templates to find local options. WhatamIdoing (talk) 03:42, 15 August 2015 (UTC)

Well WhatamIdoing, I would be glad to donate a computer to wikipedia to display the timelines. I only worked on this for 5 years. Is there somebody that I can talk to about this?

We could eventually put up thousands of timelines and help millions of kids understand history better. Jroehl (talk) 20:30, 16 August 2015 (UTC)

As WhatamIdoing has correctly told you, there are no circumstances in which any page on Wikipedia or any other Wikimedia project will ever embed content from a non-WMF site. If you want to hear it officially, you can email or ask on the talkpages of Mdennis (WMF) or Jimbo Wales, but neither will tell you anything different; transcluding material hosted elsewhere, over which we have no control, would be problematic for any number of reasons. See any of the entries in this list for the correct way to handle timelines on Wikipedia. ‑ iridescent 08:54, 17 August 2015 (UTC)
  • Hello, Jroehl. I'm sorry for your disappointment. The timeline you link is very elegantly done. I do not know if it is technically feasible to replicate the effect within Wikipedia itself, but it would be lovely if we could. The issue is not the computer that would display the timelines but, as WhatamIdoing and iridescent note, issues around the inability to control material hosted at other sites. There are also likely to be issues around the other site's policies. That site's TOS, for instance, forbids storing or hosting content for remote loading by other web pages. So, even if it were permitted here, it is prohibited there. Unless somebody here knows, perhaps people at WP:VPT could discuss whether it is possible to any way replicate that kind of work in this environment. While there would need to be community support to develop a new approach to timelines, it's certainly open for discussion. :) --Maggie Dennis (WMF) (talk) 12:28, 17 August 2015 (UTC)
Jroehl, is the code available under a free software license? WhatamIdoing (talk) 20:30, 17 August 2015 (UTC)

Yes WhatamIdoing, Maggie Dennis (WMF) and iridescent the "free software license" framework for the timeline is here:

I wrote the software to display the data on the timeline myself. I would donate all the code, which is 12,000 lines long. It has hundreds of features, that I can't explain here, that could be rolled out over several months.

I think this would be one of the most impressive enhancements to Wikipedia in years.

All you would need to do is add a SCRIPT and a DIV tag to every Wikipedia page that needed a timeline. My system can create a timeline for ANY Wikipedia article in 10 seconds or less. It is so simple.

It would be tricky to do a Spanish and German (and so forth) version, but we can deal with that later.

I initially wrote it so MY children could better understand history.

Hopefully ALL children could better understand history because of this.

I will donate a computer to wikipedia and set it up for them, then do some demonstrations. Wikipedia will have complete control and authentication authority for the whole thing.

Thanks Jeff Jroehl (talk) 22:30, 19 August 2015 (UTC)

It looks like you've picked the BSD three-clause license, which is great. We've got the computers. What we need is to get you connected to User:Coren or someone else associated with Tool Labs. If Coren isn't online now, then I'll look around for someone else to help you after I finish dealing with my current high-priority interruption.  ;-) WhatamIdoing (talk) 23:47, 19 August 2015 (UTC)

Thanks WhatamIdoing, I hope we can change Wikipedia for the better. Lets move forward with dispatch! Jroehl (talk) 19:41, 20 August 2015 (UTC)

Oh, WhatamIdoing, I hope you feel better soon! Jroehl (talk) 21:39, 20 August 2015 (UTC)

The problem with August is that so many people go on vacation. I suggest that you start with the list of preliminary tasks at wikitech:Help:Tool Labs#Quick start. Those are mostly things you'll have to do on your own anyway, and perhaps by the time you've gotten through that list, we'll have found the right person for you. Thanks for your patience and persistence. WhatamIdoing (talk) 17:39, 27 August 2015 (UTC)

Oh, well, Maggie Dennis (WMF), WhatamIdoing and iridescent. I have timelined all of English Wikipedia, so you can a timeline of any article at a new demonstration website I have set up. I am going to wait for a couple of days so everybody can get back into "work mode.". Then I will tell you the name of the website, here, so everybody can "kick the tires", so to speak. This really has been an awful lot of work. lol Jroehl (talk) 21:22, 30 August 2015 (UTC)

Self-removed vandalism[edit]

Something that has been bugging me for a while is that sometimes an IP will make a vandalising edit, then immediately undo their own edit. This is obviously done with the intention of then posting the link to the vandalised version elsewhere and disparaging the project and/or the subject concerned. This means that the IP can't be warned using the standard templates, which say that you have undone the vandalism. Should there not be a version of the template that says "I know you vandalised x article with y diff". Jmorrison230582 (talk) 22:29, 23 August 2015 (UTC)

We can't presume to know the editor's motive in these situations. This type of editing is generally treated as edit testing and is covered by four levels of templates at WP:WARN. The message for {{Uw-test2}} begins with "Please refrain from making test edits in Wikipedia pages, even if you intend to fix them later." Higher levels introduce the word vandalism. ―Mandruss  22:37, 23 August 2015 (UTC)
That begs the question: How can we even know that those IPs would get the warning messages? Unlike us registered users, who have our own user pages and get a notification each time someone leaves a message on our talk pages, there're just no way to notify an IP like how a registered user is notified via point-to-point communications. And I'm saying this because I've tested this myself by leaving a message on the talk page of my IP address, logging out and then refreshing Wikipedia. No notification what-so-ever. The way I see it, Wikipedia needs to set up a new filter and a new tag for this kind of edits and a user, registered or anonymous, needs to be blocked immediately after the admins determine that the edit was vandalism rather than sincere mistake. Of course, the best way to fundamentally solve this problem is to get everyone to register before editing anything.
P.S. If anyone could show me how to warn an IP point-to-point, please feel free to show me by uploading a screenshot, since fair use of screenshots are allowed here. Cédric Leave it to registered users! =D 01:32, 24 August 2015 (UTC)
IPs don't get Echo notifications, but they should still get the orange "You have new messages" bar. This was recently discussed at Wikipedia:Village pump (technical)#Question about IP talk pages. SiBr4 (talk) 10:57, 24 August 2015 (UTC)
What if they were using public libraries, internet cafés or even mobile devices using data plans, which get themselves assigned a different IP address every time they edit? Then how do we guarantee that they would get the warnings? Cédric Leave it to registered users! =D 14:29, 24 August 2015 (UTC)
We can't. In my experience, however, it is actually rather rare for test edit vandalism from one person to appear from multiple IPs, so the risks are rather low. Most IP hopping comes from dedicated vandals who already know we're not big fans. Resolute 14:50, 24 August 2015 (UTC)
With all due respect, just because it's low on English Wikipedia does not mean it's also low on other Wikiprojects. Also, you're acknowledging that we can't guarantee that they would get the warnings. So why taking the risk?
P.S. I just conducted a test on a "static" IP address and the "orange bar of doom" did appear. Now I would love to see someone conducting similar tests on dynamic IP addresses (a group of different IP addresses that are assigned each time a device is connected). Cédric Leave it to registered users! =D 18:19, 24 August 2015 (UTC)
I have had much trouble contacting someone with a dynamic IP. Eman235/talk 19:55, 24 August 2015 (UTC)
Honestly, I don't care about other Wikipedias. However, I don't think the basic nature of vandals changes with language. And of course I am acknowledging that we can't guarantee an anon user who makes a test or vandal edit gets the warning. That is obvious. It also, in my opinion, does not represent a significant issue. Resolute 20:24, 24 August 2015 (UTC)
The fact that you don't care about other Wikipedias is the reason why you don't see IP vandalism a significant issue. Cédric Leave it to registered users! =D 00:19, 25 August 2015 (UTC)
That is a frankly idiotic interpretation of things, actually. There is neither a correlation nor a causation between IP vandalism and other Wikipedias. Also, your position requires you to invent opinions of your own and assign them to me. And I will thank you to not do that in the future. What I did say is that (1) Anons who make vandal-like test edits (with or without self-reversion) rarely IP hop to continue making such edits, and (2) the fact that it is not always easy to communicate with such anons is not a big problem. What I did not comment on is the significance of IP vandalism itself as an issue. Resolute 00:38, 25 August 2015 (UTC)
Why don't just go ask around? I'm pretty sure many admins of small Wikipedias would be glad to tell you that they have to deal with IP vandalism, from hoppers or not, on a bloody daily basis. If that's still "not a big problem" in your eyes, I don't know what is.Cédric Leave it to registered users! =D 04:47, 25 August 2015 (UTC)
I'm not sure how you propose we solve this problem. You've alluded to forcing people to register, but surely you know that's a non-starter. –xenotalk 09:25, 25 August 2015 (UTC)
Cedric, as you are obviously unable or unwilling to comprehend what I am saying and continue to invent your own opinion to assign to me, this discussion is at an end. Resolute 14:09, 25 August 2015 (UTC)
We have {{uw-selfrevert}} for use in such cases: Noyster (talk), 22:50, 1 September 2015 (UTC)

Make it easier to regain control of a compromised account[edit]


It's snowing. Sorry for proposing such a failure. I'll do better next time.—cyberpowerChat:Offline 04:23, 27 August 2015 (UTC)

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

Hi guys. It's me again with another proposal. Though it doesn't happen often, accounts can become compromised, and it's usually very difficult, if not impossible, to regain control and prove that the account is under the control of the original user.

I'm proposing to add another layer of security, that can be activated optionally, per user. Many of use hashes to prove that we are who we are.

My proposal is that the MediaWiki software allows users to save a hash and set what encryption was used to create it. The hash obviously consists of something other than a password.

If a user finds that their account is compromised, or that they can't login anymore, the can click/tap on the restore access to account link in the login screen. The restore access form consists of two textboxes. The first textbox is the username that is compromised, the second asks for the unencrypted has string. When submitted, MW encrypts the hash based on the set setting and checks if it matches the stored string.

If the generated hash matches the stored hash, all existing sessions become invalidated, aka the account is forcefully logged off on all devices, and all the tokens associated with the account get recycled. A new session is started on the computer that provided the hash and the user is now directed to the account setup process, where they provide and email and password. Once complete, some kind of indication, such as the username turning orange for a day or a log entry, shows the Wiki community that a hash login took place. This can serve as evidence that account control has been re-established.

Upon failure of providing the correct hash, the account will get locked out, and all devices will get logged out, until the proper hash has been provided. a log entry stating a failed hash login attempt will be made.

Optional addition A: 3 failed hash attempts will result in a permanent lock out.

Setting the hash initially: To set the hash for the first time, the account password must simply be provided. An optional additional password can be set for the hash only.

Changing the hash: To change the hash under normal circumstances, the password that was being used when the hash was last changed, or created, must be provided, along with the optional password if set.

Optional addition B: The hash must be changed if a hash login was used.

Optional addition C: Hash login is disabled if there is a block on the respective IP.

Optional addition D: Hash login will be disabled for 24 hours on 3 failed attempts.

How to !vote: If you support the proposal in general, !vote support. If you also support the optional add-ons, !vote support in the respective sections for A, B, C, and D. Finally, if you oppose, then !vote in the oppose section.—cyberpowerChat:Limited Access 16:24, 24 August 2015 (UTC)


Support A[edit]

Support B[edit]

Support C[edit]

Support D[edit]


  1. Oppose — Procedurally speaking, usually you should actually have a new MW extension largely already written and proven to be stable before getting people to vote to enable it on the project. Furthermore, this is something that spans not just enwiki but has implications for all other projects under the wikimedia umbrella, as well, due to SUL. As such, once you write and test the feature (or work with a developer who's capable of doing so), I'd strongly recommend you propose a discussion on meta—not here—as that would be the more appropriate venue for wikimedia-wide input. --slakrtalk / 21:48, 24 August 2015 (UTC)
  2. Oppose - This is actually less secure than your existing password, which is at least salted. If your password is compromised, there's no reason to assume that your super secret hash phrase wasn't as well. Furthermore, allowing users to choose broken hashing functions (which are actively encouraged!) is just asking people to shoot themselves in the foot. ^demon[omg plz] 01:00, 25 August 2015 (UTC)
  3. Oppose: I'm sorry to land here but I don't think this is necessary; it's not a solution in search of a problem but it seems like it would fix something that's not a major issue at present. If you want more security, use an alt on public devices, make your password more secure and different to your passwords for any other website, don't stay logged in and, if worst comes to worst, get the compromised account blocked and make a new one. Lock-outs after incorrect hash entries could cause problems; there's the struggle and excessive complication of needing an additional password and the wasted time it would take to code this. Bilorv(talk)(c)(e) 17:58, 25 August 2015 (UTC)


  • Account lockout on incorrect hash entry seems like an invitation for mischief. –xenotalk 16:28, 24 August 2015 (UTC)
    Good point. I hadn't considered that. Give me a sec...—cyberpowerChat:Limited Access 16:31, 24 August 2015 (UTC)
    I made a change. How's that?—cyberpowerChat:Limited Access 16:37, 24 August 2015 (UTC)
  • Is this a big problem here? GenQuest "Talk to Me" 20:33, 24 August 2015 (UTC)
    I haven't seen it recently, but I don't see the downfall to adding this level of security.—cyberpowerChat:Online 21:00, 24 August 2015 (UTC)
    What you're overlooking is that any such change has costs in terms of developer time, added complexity, and potential instability. Those costs have to be justified. ―Mandruss  21:09, 24 August 2015 (UTC)
    From my view as a developer, it shouldn't be too difficult to implement this, and not too time consuming, given the existing code setup. But then again, I'm not a MW dev.—cyberpowerChat:Online 21:47, 24 August 2015 (UTC)
  • Urgh, this process is all a bit wordy and complex for me, any chance we could have a visual representation (flowchart etc.) of how this would work? My name isnotdave (talk/contribs) 16:09, 25 August 2015 (UTC)
    • So prove it. Show what you are trying to accomplish. Right now, it seems pointless. GenQuest "Talk to Me" 16:13, 25 August 2015 (UTC)
  • On a tangent, is it currently possible to log out of remote web sessions? Altamel (talk) 14:52, 26 August 2015 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
  • @Altamel: when you click logout, it logs you out of all sessions you might have open. Legoktm (talk) 07:25, 28 August 2015 (UTC)

Template Inappropriate title-soft[edit]

I'd like to propose Template:Inappropriate title-soft to be used on articles where there is a requested move but there is no content dispute between the two titles proposed. In the following template:

the guideline Wikipedia:Accuracy dispute is wikilinked in bold. This distracts the reader's attention, and improperly creates the impression that content in the article in unreliable.

I propose the following:

This uses the purple move template style, and avoids the use of the orange exclamation mark.

Note, Risk perception studies say that icons used to warn users of a danger should always use different symbols to notifications of issues that don't directly threaten them. There's a paper called Crying Wolf: An Empirical Study of SSL Warning Effectiveness that evaluated how users interact with different warning symbols. The key takeaway from the paper was to make sure that warnings that can harm a user's privacy or security (SSL errors) should use warnings like bright crimson pages, and not dialog boxes that look like system clock errors. -- Callinus (talk) 05:35, 26 August 2015 (UTC)

  • I wanted a shorter one that had only text similar to {{move portions}} and didn't have bold text. The phrase "improper for Wikipedia" also doesn't describe some scenarios. I wanted a tag so that articles tagged could have less jarring language but the easier thing is just to not tag the article page. -- Callinus (talk) 05:59, 26 August 2015 (UTC)
Hmm, I thought there was a template for a move discussion banner for article pages, but I can't find it. Maybe yours is filling that gap. Your template itself looks fine to me, as long as it's not duplicating something we already have. Ivanvector 🍁 (talk) 15:19, 26 August 2015 (UTC)
  • Support: what Ivanvector said. GenQuest "Talk to Me" 16:18, 26 August 2015 (UTC)
  • Support I think this is an improvement, and it would be an easy way to tag RMs without automatically denigrating the current title. WhatamIdoing (talk) 17:50, 27 August 2015 (UTC)
  • Oppose: suggestions or disputes on the talk page, particularly of such a minor nature, shouldn't generate any notices on the article page. Such banners have no time limit so they can remain essentially forever, serving as a bureaucratic distraction for those trying to read the article. Praemonitus (talk) 04:48, 29 August 2015 (UTC)
  • SupportI agree with the fact that the orange exclamation point is unsettling. Tortle (talk) 17:28, 29 August 2015 (UTC)

Editor pages and editor designated hyperlinks for editors[edit]

In the context of falling numbers of "editors" on en Wikipedia I've been wondering about any possible ways to reduce negative and increase positive experience of working in Wikipedia.

At present, as I write this, I look towards the top of the screen and I see, "Editing Wikipedia:Village pump (proposals) (new section)", emphasis added. We describe our activities as editing. We call each other editors. Why, in this context, are we given a "User page" and not an "Editor page" Why at the end of an edit does our signature read [[User:FooEditor|FooEditor]] and not [[Editor:FooEditor|FooEditor]].

I appreciate that, in English, the word "Editor" is slightly longer than the word "User" and it is my guess that this may have been a motivation for original usage. However the reverse is true in many other languages might, potentially, follow an enWikipedia lead.

English: editor, . user, . contributor, .

Arabic: < محرر. المستخدم. مساهم. <

Dutch: editor. gebruiker. bijdrage,.

Filipino: editor,. paggamit,. kontribyutor,.

Finnish: editori,. käyttäjä,. rahoittaja,.

French: éditeur. utilisateur. contributeur,.

German: Editor. Benutzer, . Beitragszahler.

Greek: εκδότης,. χρήστη,. συνεισφέρων,.

Hebrew: < עורך,. משתמש,. תורם,. <

Irish: eagarthóir,. úsáideoir,. ranníocóir,.

Italian: Editor,. utente,. collaboratore,.

Norwegian: redaktør,. bruker,. bidragsyter,.

Persian: < ویرایشگر،. کاربران. کمک،. <

Polish: redaktor. użytkownika. czynnikiem,.

Russian: редактор,. Пользователь,. вкладчик,.

Spanish: editor. usuario,. colaborador,.

Turkish: editör. Kullanıcı,. katkıda bulunan.

On the basis of the original (Google translate assisted) research above it also seems to me that "editor" (and derivations) is far more widely used across languages than derivations of user. (The immediately offered Greek translation presented "editor").

It seems to me that the split use of designation in this website so as to use both "editor" and "user" is just another manifestation of planet Wikipedia gone astray. Readers are also users but editors do more than this.

Certainly, unless an editor had previously operated under an IP, when someone creates an account they are not yet an editor and yet, as soon as an edit is made (which may even involve the creation of a personal page) that person will be. In any case, these pages are meant as a basis for editor interaction.

I think that there is a good case for rebranding "User" reference as "Editor" references.

GregKaye 08:08, 28 August 2015 (UTC)

That's all very well but it feels like WP:BIKESHED to me. BethNaught (talk) 08:31, 28 August 2015 (UTC)
Even though it is a little bit of WP:BIKESHED, I still believe that its a good idea. I support this and BethNaught seemed to do their research. Tortle (talk) 17:26, 29 August 2015 (UTC)
BethNaught Tortle If it is to any extent like WP:BIKESHED I don't think that it is greatly so. Its a legitimate change that could be efficiently actioned. If a decision were made all it would take would be a one time application of bots to make all the changes and we would be Editors, done. There would be nothing to resolve in a second meeting. It would also present a good example of the use of precise, less ambiguous description. GregKaye 16:27, 31 August 2015 (UTC)
Well I agree with the change but a lot of pages and policies reference user pages and if all of the uses arent tracked down, it could confuse new editors. Im sure there are plenty of uses that are on talk pages and archives too that will need to be fixed. I would be willing to help out if there is a consensus agreed on the change but it is an undertaking. Tortle (talk) 16:34, 31 August 2015 (UTC)
  • Oppose. User (computing) is a standard term and most user accounts never make an edit. If the idea is that users are automatically renamed to editors if they make an edit then it will cause confusion, for example for people who are called user on some wikis and editor on others, for users who have no intention to edit the encyclopedia but just ask a question somewhere, and for editors who are still called user in texts which are both for users and editors and cannot change wording for individuals. PrimeHunter (talk) 17:18, 31 August 2015 (UTC)
  • Oppose. I agree with PrimeHunter. By definition, we who are active on WP interact only with others who are active, and not with users who read, browse, use, refer to our encyclopedia-that-anyone-can-edit, but who don't edit it. In other words, we see only editors, and that can give us a wrong impression of the "typical user". Also, I see very little need for such a change, and a heckuva lot work and disruption and confusion that it would cause. It's not quite change for change's sake, but it is WP:BIKESHED. --Thnidu (talk) 06:40, 1 September 2015 (UTC)

Log of articles proposed for deletion[edit]

There should be a log of articles proposed for deletion on each day; the daily log being a subpage of Wikipedia:Proposed deletion. That makes it easier to see whether an article has been prodded before. If you use Twinkle to prod an article, Twinkle should automatically add the article to the daily log. Finally, if you manually prod an article without using Twinkle, a bot should automatically add the article to the daily log if you have not already done so. GeoffreyT2000 (talk) 01:37, 29 August 2015 (UTC)


I would like to propose a change to linking:
When one hovers one's mouse over a link such as WP: OTRS, the result is Wikipedia: OTRS, which is no use to anyone [chocolate fireguard, ash-tray on a motor-bike and so on]. It means 'Volunteer Response Team'. It's obvious to 9,9999 readers out of 10,000 what website he or she is on. If he/she is not sure, a glance at the top of the screen should suffice. The only time a link is understood is if it is self-explanatory; i.e. WP: SELFPUB (which, for the one person in 10,000 who does not understand it, would be: 'Wikipedia: Self-published'), or it is clicked-on.
It would be a lot better if the hovering produced something like: 'Wikipedia: Volunteer Response Team', which would, I'm sure, be enough for most readers. It would certainly save a lot of unnecessary clicking.

What do other editors think? Is it at all possible, because I've no idea how to do it?

RASAM (talk) 13:03, 29 August 2015 (UTC)

There's a gadget for that! Go to your gadget settings, and check the box by "Navigation popups, article previews and editing functions popup when hovering over links". That should do it. --Ashenai (talk) 17:26, 29 August 2015 (UTC)
For me, hovering over a redirect link actually gives the target page title (e.g. "Wikipedia:Volunteer Response Team" for WP:OTRS), because the User:Anomie/linkclassifier user script replaces the mouseover text. It doesn't include the section name for links to redirects to sections, though: the mouseover for WP:SELFPUB is "Wikipedia:Verifiability". SiBr4 (talk) 17:32, 29 August 2015 (UTC)
It does for me; this is what it looks like for me when I mouseover your SELFPUB link. I'm not sure what's causing the difference. I use WP:Twinkle, but I don't think that does anything to the mouseovers. --Ashenai (talk) 17:48, 29 August 2015 (UTC)
I'm not using popups; I was referring to the mouseover created by Anomie's linkclassifier. My comment was meant as a reply to the original post rather than your comment, as indicated by the indentation level. SiBr4 (talk) 18:48, 29 August 2015 (UTC)
There are some pagenames on Wikipedia that are very jargony and should be moved to something more self explanatory with the jargon name available as a shortcut for those who know it. That should fix the problem you identified. But the Wikipedia part of the link is needed, it shows you are linking to something in Wikipedia space and not an article of the same name. Wikipedia:Copyrights and Copyrights link to very different pages. The vast majority of our readers will never leave mainspace so it is fine that mainspace has no prefix. But the other spaces need the space name in the link. ϢereSpielChequers 14:21, 2 September 2015 (UTC)

A Proposition[edit]

I recently made a proposition for a redesign of the community portal that would fix bugs and give a more modern less cluttered look. I would like more people to participate in the discussion. Heres the link- Wikipedia talk:Community portal#A Proposition Thanks Tortle (talk) 17:21, 29 August 2015 (UTC)

Prefix suggestion: TP: for Template:[edit]

My idea is so that we could make search "fstr". We already have WP: for Wikipedia:, so let us have that prefix. Gamingforfun365 (talk) 01:26, 30 August 2015 (UTC)

  • Oppose For the reasons in WP:PEREN#Create shortcut namespace aliases for various namespaces. In particular, the Template namespace is generally not linked often enough that saving the typing of 6 characters is likely to be at all worthwhile and there's nothing available to use for the corresponding talk pages. Anomie 13:27, 30 August 2015 (UTC)
  • "TL:" would be a much better suggestion for this, as templates can already be linked to with the {{tl}} template. --IJBall (contribstalk) 15:43, 30 August 2015 (UTC)
    Won't work, because "tl:" is the interwiki prefix for the Tagalog Wikipedia. "tp:" is currently not an existing interwiki prefix (and an unassigned ISO 639-1 code). SiBr4 (talk) 16:01, 30 August 2015 (UTC)
  • support Definitely useful, as a guy who pulls up templates more that articles.—cyberpowerChat:Online 20:19, 30 August 2015 (UTC)
  • Support as TP:. But what about the template talk namespace? TT: is the Tatar language, so TPT? Eman235/talk 22:46, 30 August 2015 (UTC)
    "tpt" is Tlachichilco Tepehua in ISO 639-3. Anomie 22:11, 31 August 2015 (UTC)
  • Question: Why not just use {{tl}}? Seems to me a Template talk shortcut would be more useful. — (talk) 04:18, 31 August 2015 (UTC)
    The idea is to be able to write TP: (case insensitive) in the search box to save typing six characters. But if an alias is made then some editors will also write it in saved links. TP sounds like talk page so it may confuse some users. Assuming TP is only defined for the English Wikipedia or Wikimedia wikis in English, it may also confuse people who expect it to work at other wikis. PrimeHunter (talk) 13:26, 31 August 2015 (UTC)
    That can easily be addressed by creating a T prefix for Talk: TP for Template: and TT: for Template talk:—cyberpowerChat:Online 14:52, 31 August 2015 (UTC)
    That would require either changing the existing tt: prefix or making all namespace and interwiki prefixes case-sensitive (both of which would break a lot of links globally), as well as deleting/renaming all pages starting with T:, which include some often-used shortcuts to template pages. Hardly easy. SiBr4 (talk) 15:29, 31 August 2015 (UTC)
  • Support, for ease of finding templates. bd2412 T 13:41, 31 August 2015 (UTC)
  • Support for search box usability. — (talk) 22:24, 1 September 2015 (UTC)
  • Comment Since {{tl}} and similar templates can be used for linking to templates in discussions, a shortcut like this would only really be useful in the search box (and maybe edit summaries). I just recalled Kipod having written a user script that gives Template: namespace search results in the search dropdown for queries starting with "{{" about a year ago (discussion), and wrote this simple JS script to expand "TP:" as well as "{{" into "Template:" in the search box. That allows the functionality of the proposed namespace alias, without it needing to actually be created (and changed in case of a conflicting future namespace/interwiki prefix). SiBr4 (talk) 14:22, 3 September 2015 (UTC)

Merge proposed of how-to essays on hyphens, dashes and minus[edit]

FYI: Pointer to relevant discussion elsewhere

Proposal at Wikipedia talk:How to make dashes#Merge proposed, to merge Wikipedia:Hyphens and dashes essay (2012) to Wikipedia talk:How to make dashes how-to page (2011).  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  00:10, 31 August 2015 (UTC)
PS: Elements of the merge-from essay, when it was written in a form proposing changes to MOS's treatment of dashes, were previously discussed at Wikipedia:Village pump (policy)/Archive 101#Hyphens and endashs (concluding with no consensus to make such changes); the merge discussion newly opened is about merging the how-to and summary material, which does not introduce MOS or other changes.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  00:14, 31 August 2015 (UTC)

Efficient search for policies and guidelines[edit]

I have a request for improvement, and I was advised to bring it here from WP:Teahouse/Questions by User:Cullen328.

It’s possible to search through the whole of Wikipedia's style guidelines by using the search box at WP:MOS. Could the same be done for all policies and guidelines (and other widely accepted pages), without having to sift through things like deletion discussions and controversial essays? Thanks. — (talk) 03:31, 31 August 2015 (UTC)

The obvious solution that comes to mind is to make it work the same as MOS by e.g. moving WP:V to Wikipedia:Policies and guidelines/Verifiability. Is this a bad idea? — (talk) 03:36, 31 August 2015 (UTC)
In that conversation, I recommended Wikipedia:List of policies and guidelines as a starting point. Cullen328 Let's discuss it 03:39, 31 August 2015 (UTC)
@Cullen328: That would mean clicking on each link, doing a ctrl+F, navigating back, clicking on the next link, etc. Far more tedious than what I’m asking for here, which is a list of policies and guidelines containing the search term. But thanks anyway. — (talk) 04:03, 31 August 2015 (UTC)
I am not saying that the list provides the full functionality of the MOS search box, but rather that if such a search function is established, those are the pages that should be searched. So, this list would be an essential tool implementing that search function. Cullen328 — continues after insertion below
Ohhh. Sorry for misinterpreting. Yes, that’s a good idea, to start whatever the solution might be with those pages first. — (talk) 04:27, 31 August 2015 (UTC)
In the interim, let's say for example, that I am looking for our notability guideline for people. I look at the list, see that it has a section on notability guidelines, click that, and see our notability guideline for people. Very intuitive and easy to navigate. So, I would not dismiss the every day usefulness of that list. Cullen328 Let's discuss it 04:19, 31 August 2015 (UTC)

A more generally useful solution might be a search function that searched all articles linked to in the given article without recursion (i.e. not searching the articles linked in the linked articles, etc.). That would allow searching the list of Policies and Guidelines as well as other lists. --agr (talk) 12:14, 31 August 2015 (UTC)

You might be able to achieve the desired goal by searching for any page that contains {{Policy}} or {{Guideline}} (and similar). WhatamIdoing (talk) 17:37, 1 September 2015 (UTC)
I didn’t think wikitext was searchable. Is it? And what if you don’t know whether there exists a policy, guideline, information page, etc. about the subject at hand? A custom boolean search may be an option, if raw wikitext is searchable. — (talk) 22:28, 1 September 2015 (UTC)
The new CirrusSearch engine has the insource: keyword for searching pages' wikitext source, and support for regex search. There is also hastemplate: to search for pages using a certain template. SiBr4 (talk) 08:58, 2 September 2015 (UTC)
All of which adds up to: I think you should post a question at WP:VPT about whether any of the Cirrus search/regex experts over there can think of a way to build a link that will search policies and guidelines. WhatamIdoing (talk) 17:47, 2 September 2015 (UTC)
I posted a notification of this discussion, since it seemed to make more sense to have this in one place. Thanks. — (talk) 23:21, 2 September 2015 (UTC)
This is not possible right now, without changes to Extension:Inputbox. I was hoping that abusing it's prefix param would work, but it seems prefix search is in a category of it's own and doesn't mix well with other search options. There are multiple ways that the search itself can support this usecase though Higher prio for pages containing the relevant header templates or search in pages that link to Wikipedia:Policies and guidelines. Neither is perfect of course, but it sort of works. To make it as accurate as possible, we could let the header templates add a hidden category, so that we could use the "incategory:" modifier (modifiers only really work as ANDs, not as ORs). But first, you'd have to adapt the extension I fear. —TheDJ (talkcontribs) 16:05, 3 September 2015 (UTC)
So if I understand, our best options are either we add all P&G pages to the same category, or we add a prefix (à la “Manual of Style/…”) to their titles. Is this right? And would we be able to include essays and supplementary pages like WP:BRD in whatever we might end up doing? — (talk) 22:35, 3 September 2015 (UTC)

Bot to help cleanup MDY and DMY dates[edit]

I'm sure many of you have seen {{Use mdy dates}} or {{Use dmy dates}} on a page. These are maintenance templates indicating when the page was last checked to ensure all the dates are consistent, and used according to the template. See MOS:DATETIES for a bit more. Both templates (and the header categories they create) indicate that a bot is expected in the future to come around and fix this stuff up. I have proposed said bot, and was redirected here for more discussion. I feel there is a need for the bot, since there are hundreds of thousands (over 10% of all articles) of pages that would need to be updated and checked monthly, and it would be impossible otherwise. So I bring it before you, is this bot needed, or is there some other solution to this issue? Jerod Lycett (talk) 22:18, 31 August 2015 (UTC)

  • I would have no problem with this, provided such a bot would leave the reference 'accessdate' parameters alone, as many pages use mdy or dmy dates for reference 'dates' (and dates in the article itself, of course), but specifically use ISO dates for reference 'accessdates' and 'archivedates' (which is fully consistent with MOS:DATEUNIFY). --IJBall (contribstalk) 03:05, 1 September 2015 (UTC)
  • WP:CITEVAR allows any consistent citation style, including cases where the citation style calls for a different date format than the rest of the article. Also, citation templates need not be used, and general references are allowed, which means it would be hard for the bot to tell the difference between a reference and other parts of the article. Finally, any dates that are part of titles or quotations must be left alone. There is no special markup for titles, and there are a variety of ways to indicate quotations, so it is difficult for bots to tell whether or not a date is part of a quotation or title. I don't think a bot can be written that will work reliably. Jc3s5h (talk) 03:20, 1 September 2015 (UTC)
    • In light of these concerns I think I'll have to withdraw. Jerod Lycett (talk) 07:29, 1 September 2015 (UTC)

Come see the New WikiProject Wikipedia![edit]

{{WPW Referral}}

Forced rename[edit]

Due to our username policy we don't allow certain types of names in Wikipedia accounts. Currently this is enforced by blocking accounts that breach that policy, with hard blocks for people we don't want to come back and soft blocks for those who we don't actually want to block, we just want to change their username.

Forced rename would be a gentle alternative to soft blocking. If an admin sets a forced rename on an account such as Acme studio IP dept then the next time Acme studio IP dept logs in they would see a screen that explains why Acme studio IP dept isn't an acceptable name for a Wikipedia account and prompts them to enter a new name. The rename would then take place and Meg at Acme studio IP could continue editing.

Obviously this would require some IT resource, but we need to demonstrate that we have consensus to implement this before it has a chance of being developed.

To avoid problems with SUL, rogue admins and different languages Forced rename would only work on accounts with fewer than 1,000 global edits that have edited on the wiki where an admin forces them to rename. IE an admin cannot force a rename on someone who doesn't edit on their wiki. ϢereSpielChequers 13:57, 2 September 2015 (UTC)

Perhaps this should be accessible to bureaucrats only. Renaming accounts was formerly a bureaucrat task (and thus all knowledge is there), and all current bureaucrats come from that time. Jo-Jo Eumerus (talk, contributions) 14:55, 2 September 2015 (UTC)
I think what WereSpielChequers is suggesting would probably push the user into Special:GlobalRenameRequest, and any resulting requests would still be handled by global renamers (née bureaucrats). –xenotalk 16:03, 2 September 2015 (UTC)

I propose an alternative solution, making the username policy more obvious. There is a "Help me choose" option here, but unless you click(hover over it, but we're going mobile in this world) you have no idea that it links to the username policy. If the policy was clearer I think it'd prevent more people from making the mistake. As is, they violated policy, so why not block them? Jerod Lycett (talk) 17:21, 2 September 2015 (UTC)

  • Because our policy says not to block people who make innocent mistakes in naming their accounts but are otherwise not causing problems.
  • Because Wikipedia:Don't be evil is an accepted community principle.
  • Because sometimes admins make mistakes, e.g., believing that a name is a promotional business account when it actually turns out to be a fictional company or something that isn't a company name at all. WhatamIdoing (talk) 17:45, 2 September 2015 (UTC)
We have a username policy. They violated it. We either need to change our policy, which is what I feel the proposed change above is about, or make it more clear that the policy exists. Jerod Lycett (talk) 18:10, 2 September 2015 (UTC)
Yes, we have a username policy. The username policy itself says that only some violations of the username policy should be responded to with blocks. "Violate policy" does not mean "get a block". Blocks are not the only way to reply to policy violations. WhatamIdoing (talk) 18:45, 2 September 2015 (UTC)
Yes, however in the case of a username it is. Now, are you going to discuss the original proposal or my alternate proposal? Jerod Lycett (talk) 18:53, 2 September 2015 (UTC)
Which word does "it" refer to? In case of a username that violates the username policy, the only way to reply to that violation is for an admin to go forth and violate the username policy again, by blocking a user despite W:U saying "Users who adopt such usernames, but who are not editing problematically in related articles, should not be blocked. Instead, they should be gently encouraged to change their username" (emphasis in the original)? "Two wrongs make it right" doesn't make any sense, so you must mean something else. WhatamIdoing (talk) 19:07, 2 September 2015 (UTC)

Enabling VisualEditor for existing accounts which are dormant or inexperienced[edit]

Over the last few months, we slowly expanded the availability of VisualEditor as an option for new editors. This is now complete, which means that all accounts registered from now on get the choice to use VisualEditor.

Though VisualEditor is useful to both experienced and new users alike, we are yet to offer any choice to existing, inexperienced users. People with an existing account can and do opt-in to use VisualEditor, and there are a number of experienced editors (like those who read this page) who choose to use it. However, the vast majority of people are casual, irregular editors who come back every few months or so (or never). They do not change any of their settings, and most of them likely don’t even know they can. Offering VisualEditor to them as merely an opt-in preference is hiding it away.

Consequently, I think we should make VisualEditor available to all existing, inexperienced accounts, and for dormant accounts. By this I mean those who have not yet made many edits (fewer than 1000), and those who haven’t edited at all for a while (perhaps three to six months). I am not suggesting a change of status for active, experienced editors, as many of you have made the decision to not use VisualEditor, which I respect. This change would also not provide VisualEditor to anonymous editors, who I think deserve a separate community conversation about how that can take place, at some point in the future.

  • For casual, inexperienced editors, this would mean that they don't need to know about preferences to have access to both the wikitext editor and VisualEditor.
  • For any returning experienced editors, access to both the wikitext editor and VisualEditor would just be one of the many other changes in the software that will have rolled out each week since they were last around (like the performance improvements to MediaWiki made over the last few months).
  • For all experienced, active editors, your current preferences will of course be honoured. For the thresholds I have proposed, about 20,000 editors; if you are reading this, you know about the Village Pump, so this almost certainly means you. If you have VisualEditor enabled, it would remain enabled. If you don't, then it would remain disabled.

The location of the preference switch will be moving soon to the "Editing section of Special:Preferences. This will bring the English Wikipedia into line with the majority of other Wikipedias, like French, Russian, or Italian; see this link to the French Wikipedia's preference screen for what that will look like. This will not mean that VisualEditor is "complete" or that it is out of "beta" though – there are still lots of improvements yet to make, not least integrating wikitext and visual editing together properly and removing the hack of having a second edit tab that jumbles up the interface. I have no intention of forcing anyone to use VisualEditor.

The choices about whether, at which thresholds, and exactly when to do this, are up for a discussion, and I would appreciate suggestions. I think this change would be a reasonable change without disrupting things for most users. Thoughts?

Jdforrester (WMF) (talk), Product Manager, VisualEditor – 17:55, 2 September 2015 (UTC)

Sounds like a low impact plan to me. —TheDJ (talkcontribs) 15:33, 3 September 2015 (UTC)
+1. This would be very helpful for the education program, especially for making sure all the student editors who just created accounts in the period before the VE rollout hit 100% all end up with the same settings.--ragesoss (talk) 16:51, 3 September 2015 (UTC)
  • Hold on. Where is the statistical data on the impact of the change with new editors that was promised? And what is the advantage of changing the preferences of accounts that are minimally or not active? And since the issue of preferences is raised, would it not be better to do some user education on preferences instead of changing them without editor participation? On what basis is it assumed that the editors had not made a conscious decision to leave VE not included? That calls for some A/B testing before implementation. I'm still baffled why VE has been activated in the Wikipedia/project namespace, an area that requires user signatures on more than half its pages, based on a single user's request. Risker (talk) 19:00, 3 September 2015 (UTC)
    TL;DR: This proposal is mostly based on what is best for inexperienced users, and server performance issues. The real question is how to solve the server issues without adversely disrupting things for any editor group.
    Where is the statistical data on the impact of the change with new editors that was promised?
    Did you mean the statistical data about the A/B test? The report and data from that is on meta. Did you mean the gradual release to new users? As promised, after the first step in that process last month, I reported back on how well it went, before increasing the rate to a larger proportion and monitoring from there.
    If you're looking for detailed numbers, there's an awful lot of statistical data provided in our dashboard at but it's not very friendly, I'm afraid. (Cleaning that dashboard up so that those who don't have as much time and patience to pour through it is on our list of things to fix.)
    And what is the advantage of changing the preferences of accounts that are minimally or not active?
    Enabling VisualEditor in Beta Features for ever-more users adds a mess and (albeit minor) cost to the database, and thus site performance. There are already almost a quarter of a million accounts opted-in to VisualEditor, and letting this continue to grow (by more than another hundred thousand each month) is not great, technologically, and needs to be fixed for site stability reasons. (I hate to invoke WP:PERF, but…)
    More importantly, however, Beta Features is not and has never been designed for anything other than users actively opting in to new things – it's both confusing and poorly designed for this use case, wherein ever more users get accounts only to find that the system has them "opted in" to having something they haven’t actually explicitly opted into. I don't to be part of adding even more confusion to editing Wikipedia; it's already too hard.
    And since the issue of preferences is raised, would it not be better to do some user education on preferences instead of changing them without editor participation?
    Though I think that educating users is a worthy initiative, that's the equivalent of suggesting we write clearer warning labels on people’s tax forms – for most people in the target audience they would never be seen, and for everyone who already knows, it would just get in the way. Education features are a serious area for further work, regardless of whether the user is writing content or engaging in a discussion.
    On what basis is it assumed that the editors had not made a conscious decision to leave VE not included?
    As you will see in the A/B test report, over 99% of users made no changes to their preferences about VisualEditor; 35 users opted out, and 110 opted in.
    That calls for some A/B testing before implementation.
    A careful A/B test over several months might be worth considering with some interstitial or otherwise calls to action ("Hey there, do you want to opt in to our old skin with more buttons?" and so on for a variety of options), but I do not think it would be appropriate for this use case.
    Yours, Jdforrester (WMF) (talk) 00:30, 4 September 2015 (UTC)
  • No for experienced editors. It's annoying as hell when you step away for a few months and have your preferences changed. They were not set the way they are by accident. Additionally, the changes are often incredibly difficult to figure out how to reverse for the average editor. I often spend the first day after I come back from a long break reading VPT archives which is frankly ridiculous. Ambivalent for new editors, though looking at the last half hour on my watchlist I note VE still has serious problems. Jenks24 (talk) 19:44, 3 September 2015 (UTC)
    @Jenks24: Understood. How many months do you think would be adequate, if not three? Six? Nine? The scientific research done on people who stop editing shows that a timespan longer than a month and less than six months is most likely to be useful for this. If an editor is inactive for more than a month, they are likely to not be active for a long while. If they are going to come back after this long period of inactivity, it will mostly likely be between six months and one year since their most recent edit. [1] and [2] (PDFs both) may be of interest. I appreciate that there are always outliers, but the goal is to set preferences in a way that works for the majority of users. Jdforrester (WMF) (talk) 01:10, 4 September 2015 (UTC)
    @Jdforrester (WMF): what benefit will it be to the long-term user if they return? I admit I haven't read either of those papers, but just skimming the abstracts it doesn't seem to address that? If someone has made 50,000 edits in the 'old', wikimarkup style, surely getting used to VE will actually be more difficult than just doing things as they've always done. From personal perspective, the more things that are different coming back from a break the more difficult it is to get back into the swing of editing. I appreciate that in a lot of cases changes need to be made and I'm not saying "change nothing", but I fail to see the benefit of making an unasked for change to long-term experienced editors simply because they take an extended break. For example, look at all the unlinked names at WP:WBE (meaning they haven't edited for a month) – can you imagine any of them being pleasantly surprised when they log back in to find that VE has been activated on their account? If things are too hard or too different these returning editors will simply not bother. I don't think timeframe is the right way to be looking at this. Jenks24 (talk) 02:01, 4 September 2015 (UTC)
    +1. That VE would just be one of the many other changes in the software that will have rolled out each week since they were last around (like the performance improvements to MediaWiki made over the last few months) is quite a stretch to claim. By "performance improvements", I presume you mean HHVM, which is AFAICT a totally back-end change having no effect whatsoever on user settings, quite unlike VE. BethNaught (talk) 19:49, 3 September 2015 (UTC)
    @BethNaught: About 150 changes went live to this wiki just this morning (as happens every Thursday for all Wikipedias), and though individually most of the changes are relatively minor, collectively they make quite a change over time, especially when we’re talking about several months.
    HHVM, though an excellent piece of work, was done almost a year ago, and wasn't what I meant. Beyond my team working on VisualEditor to make it faster, I'm talking about the brilliant work done by my colleagues working on other things, from the Performance team to the Discovery department. For example, in just the last month the former have cut the average "firstPaint” time from roughly 1.3s to 0.8s, making the site feel massively faster for the majority of users. (You can play with a few of their numbers on their performance dashboard.) Similarly, the latter are working to redesign of the Search interface, over-hauling it to provide better, more accurate and more useful results for our readers and editors alike. Some early examples were presented at the public meeting this morning, and the slides are on Commons (PDF).
    By the bye, the impact of HHVM was to make loading VisualEditor about 10% faster, which we believe led to an increase in VisualEditor's use on wikis where it is used more widely, so it's not quite true to claim that back-end changes have no effect on user experience and take-up. :-) Jdforrester (WMF) (talk) 01:25, 4 September 2015 (UTC)
    Jenks24, that is a direct result of VisualEditor having been activated in Wikipedia namespace without any notice or discussion with the community as a whole. Editors who are used to working in project space all know that VE doesn't work there - or it didn't until about 36 hours ago. The majority of edits to Wikipedia space require either (a) a signature - not possible to do in VE or (b) a template that isn't in VE's "dictionary" or (c) both. I've asked for this to be reverted at T100067. Risker (talk) 20:22, 3 September 2015 (UTC)
    This was us responding to a user request, and has been reverted pending community reconsideration. It’s off-topic to this proposal, but happy to discuss in another thread or (probably better) on the discussion on WP:VE/F? Jdforrester (WMF) (talk) 00:32, 4 September 2015 (UTC)
As someone both using the VE for a lot of my edits (not all) and someone who teaches new users to edit with Wikipedia, I think the Visual Editor does make life a lot easier for the inexperienced editor. I doubt most of these recent signups who wer not currently opted-in even know that the Visual Editor exists, let alone have made a conscious choice to stay opted-out. I don't think it unreasonable to roll it out to these folks (assuming some clear explanation is put on their User Talk page along with step-by-step opt-out instructions, if they desire to do so). What the threshold of "newness"/"inexperienced" should be? I'd say start small - signedup in the last 2 months and less than 100 edits. Wait and see how that group react. Do they rush to opt-out? Do they use the VE? Do they complain? If nothing very bad happens, gradually expand the parameters to increasingly wider groups of people while there appears to be benefit in doing so. Then when it's only the more experienced editors left (say, signup over 1 year ago or more than 1000 edits), leave a message on their User Talk page reminding them of the availability of the VE and how to opt in.Kerry (talk) 07:29, 4 September 2015 (UTC)

Is this the proper place to request WP articles?[edit]

Is this where such a request goes? From someone who may know more on a specific subject? I'm wanting a chemistry/molecular neuro-biology buff to create one on the drug-compound "2-methylamino-1-phenyl-propane.HCl". Apparently, it is among the very most simple and most natural-neurotransmitter-like drugs to work both as a MAT inhibitor (à la cocaine) and Mu-G-coupled protein receptor agonist (à la heroin). (talk) 20:23, 2 September 2015 (UTC)

You mean Methamphetamine? DMacks (talk) 20:30, 2 September 2015 (UTC)
To answer the original question, no, you're looking for Wikipedia:Articles for creation. Jerod Lycett (talk) 19:05, 3 September 2015 (UTC)

Allow users to delete pages within their own userspace[edit]

This would get rid of WP:CSD#U1 as it is, and speed up admins' CSD backlog. User talk space will not be included in this proposal. Eat me, I'm a red bean (talk | contribs) 03:40, 3 September 2015 (UTC)

WP:CSD#U1 and WP:CSD#G7 are easy to evaluate and process so the reduced admin load is insignificant. If users can delete in their own userspace then safeguards would be needed against some things like moving articles to your userspace and delete them. It has been suggested before but I think the general feeling among editors is that developers should rather spend their time on other things. There are also issues like users being able to wipe {{Sockpuppet}} from their visible user page history. PrimeHunter (talk)
The requested move process could be used for moving mainspace pages to your userspace. Eat me, I'm a red bean (talk | contribs) 05:37, 3 September 2015 (UTC)
If there are a lot of CSD in the cat at any one time, a bot calls it a backlog, but it's usually cleared very quckly. True backlogs are things like complex AfD that no one wants to take he risk of closing, or Hist merges that are very complicated to do, or SPI cases. Those are backlogs, but not clearing out routine CSD and PROD. --Kudpung กุดผึ้ง (talk) 05:51, 3 September 2015 (UTC)
See also WP:PEREN#Grant non-admins admin functions within their user space. SiBr4 (talk) 11:35, 3 September 2015 (UTC)
I agree with PrimeHunter. U1 and G7 are not a significant part of the speedy-deletion workload. JohnCD (talk) 11:39, 3 September 2015 (UTC)
The problem could be solved by applying the requested moves process, as mentioned earlier. Eat me, I'm a red bean (talk | contribs) 11:43, 3 September 2015 (UTC)
It would appear the two admins I can see that have replied think this isn't needed. As a user who has used CSD on my user pages several times, it is usually done in minutes. I don't think there is a need for this. Jerod Lycett (talk) 19:04, 3 September 2015 (UTC)

Moving deleted revisions[edit]

Administrators should be able to move deleted revisions along with non-deleted ones when they move pages. GeoffreyT2000 (talk) 01:56, 4 September 2015 (UTC)