Wikipedia:Village pump (proposals)/Archive 102

Yes, that would make sense, and tweaking the text would be painless.--JayJasper (talk) 03:53, 15 May 2013 (UTC)

While I still think there should be something that can be done based on the number of created articles, I like the tweaked text as well and I agree that it is considerably less painful.Naraht (talk) 20:13, 15 May 2013 (UTC)

Would it be a good idea to write a bot that changes http links to

This is a good idea, but I would like to see some human oversight just in case. Ideally, I would like to see a human confirm each changed link is valid and contains the same information, but that is probably too much to ask. Perhaps spot checking by a human would be a good alternative. 64.40.57.162 (talk) 01:52, 14 May 2013 (UTC)

Both the original idea and 64's addition sound good to me. Perhaps, though, instead of a human checking each link (which would kinda defeat the purpose of using a bot), something like User:MadmanBot could check to make sure the http and https versions were the same. Ignatzmice•talk 02:43, 14 May 2013 (UTC)

I was thinking you could download both http and https pages, and do some simple check (eg: that it's about the same size and is not an error page). I think MadmanBot is comparing the set of words on each page - a similar approach would probably work well here (unless the link is to a binary file, in which case it's probably exactly the same anyway). --h2g2bob (talk) 23:50, 14 May 2013 (UTC)

You don't want to do this. What you actually want is to use seems to be called a "protocol-relative link". Just type //example.com rather than http://example.com or https://example.com (must include single square brackets, or it will be parsed as plain text). WhatamIdoing (talk) 14:57, 14 May 2013 (UTC)

That's kind of cool. I came across {{sec link auto}} which I think uses this. I worry a little that editors may think that the link is broken if they see a url without a protocol! Besides, my secret motive is to increase use of https for everyone, not just those using the https version of wikipedia. --h2g2bob (talk) 23:50, 14 May 2013 (UTC)

Using an encryption protocol slows transfer time, which some readers may not care to experience. If the lack of encryption is a concern for people, they can just use HTTPS-Everywhere instead (as I do). Praemonitus (talk) 23:15, 14 May 2013 (UTC)

Https everywhere is mostly installed by geeks, I'd love everyone to access the secure sites. It gives them a chance of safely logging in or maintaining their privacy. When done right, https is only slower on the first fetch. Hopefully that won't impact the user experience too much. --h2g2bob (talk) 00:14, 15 May 2013 (UTC)

It's not Wikipedia's job to force people to to maintain their privacy. I, for one, don't give a toss who knows what links I follow from Wikipedia, and we shouldn't be linking to sites that need a password anyway.

Phil Bridger (talk

) 08:45, 15 May 2013 (UTC)

I agree. Forcing users into using https because we think they should is a bad idea. However, if this were something that could be enabled as a user pref or gadget, something opt-in, I'd not oppose that.--Fyre2387 ^{(talk • contribs)} 20:03, 15 May 2013 (UTC)

I'd like to propose that discussion of all community-sanctioned naming conventions (i.e., those in Category:Wikipedia naming conventions) be aggregated at Wikipedia talk:Article titles. This method has been successful in other areas of the project and would, in the case of naming conventions, greatly improve the efficiency of consensus building.   — C M B J   08:33, 14 May 2013 (UTC)

I don't understand this proposal. Do you mean "please place a list of Category:Wikipedia naming conventions on the talk page of the Article titles policy?" Do you mean "please merge the contents of more than 150 naming conventions into the Article titles policy?" WhatamIdoing (talk) 14:59, 14 May 2013 (UTC)

The proposal is that #redirect [[Wikipedia talk:Article titles]] be placed on all discussion pages in Category:Wikipedia naming conventions. Inactive threads on those pages would be archived and active threads would be moved to the new location.   — C M B J   05:28, 15 May 2013 (UTC)

We do that for some smaller groups, like related warning templates and some WikiProject subpages. I'd favor this if the volume at the individual pages was low. WT:AT itself already has a moderate traffic load. If the others tend to add up to a similar volume, then we might be better unifying them on their own page (all the naming conventions except the main policy get a merged talk page), rather than making WT:AT super-busy. WhatamIdoing (talk) 17:05, 15 May 2013 (UTC)

I perform a task to identify

Why don't you join an existing group, like Wikipedia:WikiProject Copyright Cleanup or Wikipedia:WikiProject Images and Media/Non-free? WhatamIdoing (talk) 15:02, 14 May 2013 (UTC)

That would be reasonable if there were only a handful of such violations popping up from time to time and one could simply say "Hey, there's a bunch of 10c vios, let's just clean it up." That's not the case, however, as there are thousands of violations and more are added every day. It is a never ending task that either needs a bot or a dedicated group to be dealt with effectively. (Or, of course, a change of the policy so that 10c is no longer an issue, but as far as I can tell, that's not going to happen). -- Toshio Yamaguchi 16:59, 14 May 2013 (UTC)

Per my latest count, there are currently around 12,000 10c violations on the project, corresponding to approximately 2.5 % of overall NFC. -- Toshio Yamaguchi 17:55, 14 May 2013 (UTC)

A bot might have advantages, but if you are looking for a group of people this fact remains: you will never get a larger group of you start off by excluding all the people who have already shown an interest in this issue and in joining a group to work on it (i.e., all the people who have already joined a copyright-related group). WhatamIdoing (talk) 22:12, 14 May 2013 (UTC)

Thanks for volunteering for this cleanup stuff, Toshio. Out of curiosity, have you got any estimate about what percentage of these apparent 10c violations are purely formal (e.g. forgotten or misspelled article titles in the FUR, easily fixable), and how many are substantial (e.g. images added to articles they were not originally intendend for)? Fut.Perf. ☼ 05:48, 15 May 2013 (UTC)

I guess that the majority of 10c violations are not easily fixable (a substantial amount of the violations are sports team logos being reused on articles about yearly events, such as here). Also, for a lot of the violations, the issue is not primarily 10c, but a violation of NFCC#8 (such as decorative uses of logos or uses of non-free images without critical commentary on long pages such as XXXX in YYYY, like 2011 in Science). -- Toshio Yamaguchi 09:32, 15 May 2013 (UTC)

I, and I'm sure others too, don't need useless pop-ups to tell you what you just did, like "Your edit was saved" or "This page has been added to your watch-list" {There may be others}. I.E.: When I click on save I don't need a confirmation of success my action, only a notice in case it didn't worked, which we already have. Pop-ups like this just add to page loading time and have no practical use at all. Enhancing the interface is one thing, adding useless and annoying features seems to me just pleasing the programmers playing around with silly additions that nobody needs or wants. I sure understand that they in part live in a different world, not spending much time if any at all on what editors actually looking for. The last notification system is just the latest example of how the IT guys get ahead of the editors and implement changes that are not widely accepted but forced on them anyway. I'd like to hear some honest answers, straight forward and w/o any excuses. Thanks.

I agree. I don't really like either of those new features and wish I could turn them off. I don't really like the new notification feature either (except that it mentions things outside the talk page sometimes).

talk

) 02:38, 11 May 2013 (UTC)

Actually, the saved edit feature provided a statistically significant boost to the odds of newcomers staying around and contributing more. You may be confusing "Wikipedia" with "a website where every feature is built to be immediately relevant to you". Ironholds (talk) 03:07, 11 May 2013 (UTC)

@Ironhold: You resonce is nothing short of an excuse w/o back-up.

talk

) 03:19, 11 May 2013 (UTC)

• "Edit saved": See Giving new Wikipedians feedback post-edit and meta:Research:PEF. It disappears after 3 seconds.
• "X has been added to your watchlist." Clicking the watchlist button used to send the user to an entirely different page. Confirmation is a good thing, especially for new users. It disappears after 3 seconds.
• These 2 items ^^ are in the sitewide javascript, and are good for new users (who we're trying to encourage), and "disabling" it for individuals would not decrease page load times. Not even by a millisecond.
• Notifications: We (Wikipedians) have been asking for better notification-systems (and better talkpage-threading systems) for years. Various groups of developers have pounded their heads against these incredibly complex problems for years and years. We're now getting the first taste of that software update, which will vastly change (and thereby horrify some people) the talkpage system. I, for one, will be happy to not have to explain how to "sign and indent your talkpage messages" and that "no, there's no way to be notified when a discussion you've contributed to (or are interested in) has been updated". I've been unimpressed with the ranting and insults that some editors have been throwing at the devs recently. Yes, there was a major problem for the first week of Echo, and now it's fixed (IPs now get hard-to-ignore colored banners again). Smaller problems will also be fixed as time goes on (links to diffs, etc). They'll be fixed a hell of a lot faster if bugreports weren't mixed together with insulting diatribes. Being Rude is Not Magnificent. –Quiddity (talk) 04:07, 11 May 2013 (UTC)

• You may be my new favourite person, good sir. Ironholds (talk) 08:08, 11 May 2013 (UTC)

+1 —

talk

12:30, 11 May 2013 (UTC)

Edit saving confirmation: How to turn it off

The edit saving confirmation can be turned off by adding .postedit { display: none;} to your common.css. -- Toshio Yamaguchi 08:48, 11 May 2013 (UTC)

Ditto for watchlist confirmation, by adding .mw-notification-tag-watch-self {display: none;} - grumblejustneededapoliterequestgrumble. –Quiddity (talk) 20:02, 11 May 2013 (UTC)

• Thanks Toshio Yamaguchi. At least I can get rid of one annoying feature (even so I should be able to turn it on or off in my preferences but for such, there is too much ignorance from computer freaks that think they know what's best for all of us). Again, thanks for helping me disable one annoyance. If you you have other scripts on hand that works on the "added to your watchlist" popup or any other feature that adds to loading time and might not be wanted or needed by longterm contributors please let me know, here now or on my talkpage later. Much appreciated,
  talk
  ) 22:27, 11 May 2013 (UTC)

  There are hundreds, if not thousands, of these "features". It's not possible for create a page that will list every single possible feature that someone might want to change, and every possible alternative for that feature, and have that page actually be useable by a human. If you want total control, then you will have to get your own website and run only the version of Mediawiki that appeals to you. If you don't want to do that, then you'll have to find a way to live with consensual reality, which is that WP:You don't own Wikipedia, which means that the website can be changed at any time without your (or my, or our) consent or knowledge. This is the basic fact of wikilife: This website is not owned by the users. This website is owned by a non-profit corporation, whose legal purpose is not running the website in a way that gains your approval.
  As for the specific examples you list, I've been very grateful to see the watchlist message on the multiple occasions when it didn't add the page to my watchlist correctly, and the "Your edit was saved" has occasionally been reassuring (far more reassuring than silence if the previous action produced a blue screen of server unhappiness). I'm pretty good at ignoring positive confirmation messages (I have more skills to verify that it worked than a brand-new user, after all), but I am pleased that these exist and that someone isn't optimizing this website for power users like me. WhatamIdoing (talk) 22:39, 13 May 2013 (UTC)

  Sure it's possible. Firefox did it. Certainly not something you want on the main preferences page, but hey, it is possible. -— Isarra ༆ 15:19, 16 May 2013 (UTC)

  Are you thinking about Firefox's "about:config" system, which is the most frightening geeks-only prefs page I've seen for years? I honestly don't believe that page is useable by normal people. WhatamIdoing (talk) 00:46, 18 May 2013 (UTC)

  As a non technical but very heavy user , I too would like a secondary page giving clear and simple ways to alter aspects of the interface. there are all sorts of tweaks I would like to make,to focus on the parts i use, and I edit enough to make it worthwhile to go to the trouble. (like when I was spending 8 hours a day writing in MSWord, I had several dozen of customized commands and buttons, none of which required actually learning the macro language.) This is something which can be customizable without interfering with the function of the site for anyone else. BUT I ask whether having extensive local css would slow down page loading or saving? DGG ( talk ) 23:27, 17 May 2013 (UTC)

  but forthe feature mentioned, I find the confirmations being discussed here exceedingly useful, and they have saved me from many errors. DGG ( talk ) 23:27, 17 May 2013 (UTC)

 Not done Thank you for trying to improve Wikipedia! While we will not be implementing this proposal, for the reasons mentioned below, we do appreciate your input! – Philosopher ^{Let us reason together.} 03:55, 18 May 2013 (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.

---

As an engineer I strongly recommend that all articles in Wikipedia should use only SI UNITS as far as measurements are concerned. The IMPERIAL UNITS should be discarded completely. There is no purpose in using different types of measurements in the 21st Century, 3rd. Millenium. If there is an international system to express measurements, let's use it only.200.148.82.67 (talk) 14:43, 13 May 2013 (UTC)

English Wikipedia is written for a general English-speaking readership, not only for engineers and scientists.

Phil Bridger (talk

) 14:51, 13 May 2013 (UTC)

Right. The sum of all human knowledge must include

International System of Units. ChristineBushMV (talk

) 19:00, 13 May 2013 (UTC)

(after edit conflict with TortoiseWrath) Are imperial and US customary measurements not part of the sum of all human knowledge? Wikipedia's job is to present information in a way that its readers can understand, and, for many of our anglophone readers, this means including non-SI units alongside SI units. My personal preference, as someone who is old enough to have been brought up on imperial units and

Phil Bridger (talk

) 20:46, 13 May 2013 (UTC)

• Unimaginably strong oppose. As a scientist myself, I use SI units daily; though I would favor their exclusive use, it's simply not the case, and a majority of our readers (non-scientist Americans) would be completely alienated by values like "6 Mm²," "190 kJ," "8.3 dm³," and "124 kPa." These units are great, and I'm of the opinion that they ought to be used by all, but Wikipedia does not take sides on social issues, and this is certainly one of them. It's still best to display those measurements alongside "2.317 million sq. mi," "45 Cal," "8.8 quarts," and "36.6 in Hg," respectively.  — TORTOISEWRATH 20:37, 13 May 2013 (UTC)
• Recommendation duly noted. Praemonitus (talk) 23:46, 13 May 2013 (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.

Hi I would like to propose that template which people can put on templates and projects and articles be created so that they can take the page they want to be created. Paladox2014 (talk) 13:56, 15 May 2013 (UTC)

I really don't understand tis proposal, are you meaning to say we should create a template that should notify editors a page needs editing? Cuz if so, I believe that exists. Tech Addict, Fan-Ficion Writer, and Aspiring Filmaker 14:37, May 15, 2013 (UTC)

As I understand it, Paladox means a template like this:

This article does not exist yet. The article has been taken by User:Example who will create it.

If not, then Paladox needs to clarify the proposal, as in that case I don't seem to understand as well. -- Toshio Yamaguchi 15:02, 15 May 2013 (UTC)

Wouldn't it be better to just start the article, maybe adding a template:under construction. Rmhermen (talk) 16:34, 15 May 2013 (UTC)

This sounds like a

WP:OWN issue. Wikipedia editors don't get to "reserve" certain articles they intend to create, this isn't a race or contest, and if someone else does create an article you had intended to create, there are no rules preventing you from working on it. --Jayron32

03:31, 17 May 2013 (UTC)

I have been viewing the list of protected pages here (Category:Wikipedia_protected_pages) and have found several examples to demonstrate this, the most notable being (Laura_Wilson, protected 2009), and an extensive number of articles which are semi-protected from random edits with no reason listed under the protection log.

Proposal: These articles should be de-protected in a graded manner with a set timeline. If articles are extremely controversial, then the articles should be protected for a maximum of five years.

Considerately,

Duplicate section removed Often, these pages are protected for other factors. They are often unprotected upon request at

WP:RFPP. Overall, I can't see any benefit to mass-unprotecting all of these pages - which may have been protected at the subjects request, or due to a sockpuppetry spree, or other factors. Also, the article you linked to (Laura Wilson) is protected with the reason "BLP issues - please email me before removing". Therefore, I can't see how this will gain consensus. Mdann52 (talk

) 12:56, 16 May 2013 (UTC)

 : I'm sure many articles are protected for good reason. I'm arguing against the indefinite nature of these protection. indefinite is a very long time.

talk

) 23:37, 16 May 2013 (UTC)

Some things are meant to be protected indefinitely, like Main Page and Template:Infobox, because the risk of vandalism is just too high. -- King of ♥ ♦ ♣ ♠ 02:37, 17 May 2013 (UTC)

It is not an onerous step to request unprotection at

WP:RFPP for any article which is protected which you believe should be unprotected. Indeed, it happens several times per day. --Jayron32

03:29, 17 May 2013 (UTC)

I understand that those 'root' pages need to be protected, but if you look on the list Category:Wikipedia_protected_pages_without_expiry, there are a huge amount (1,652) on the list (although several are probably misclassified). I think it's presumptuous for editors to indefinitely lock certain articles, and gaining the ability to moderate all changes.

Comment LT90001 probably doesn't realize this, but

move-protected pages, as well as pages with full protection. So really, the 1,652 number isn't as bad as it seems. Howicus (talk

) 00:50, 18 May 2013 (UTC)

Comment Administrators do not generally lock pages they are active editors of (vandalism-prevention is sometimes an exception) and they do not lock them and then moderate what changes are made to the article. Usually someone asks for page protection, an uninvolved admin decides if it is appropriate and for how long, and gives a reason in the protection log. Other admins might change this although they probably will ask the first admin about their reasons. The admin who locks an article is generally not involved in processing edit requests on the talk page of locked articles. That would be to much like

WP:Own. Rmhermen (talk

) 17:27, 18 May 2013 (UTC)

Please add your comments on whether or not we should have an interwiki link to Hindi Wikipedia on our mainpage in this discussion. Thanks, ThaddeusB (talk) 02:38, 19 May 2013 (UTC)

This proposal seeks to establish the community consensus regarding the introduction of fixing the navigation bar to the top of the window. It will bring the look and feel more in line with other famous sites out there, as well as, in my opinion, make it more personal, which may lead to better editor retention.

I have made a crude mock up in case I haven't described it well. 1 2 The design is irrelevant; it is a demonstration of positioning.

This would have the side effect of making the new echo notification system a lot more visible.

Thoughts? 930913(Congratulate) 22:15, 8 May 2013 (UTC)

@Theopolisme:Just a note that I've started a quick mockup css, just add @import "//en.wikipedia.org/w/index.php?title=User:A930913/fixnav.css&action=raw&ctype=text/css"; to Special:MyPage/vector.css 930913(Congratulate) 07:01, 9 May 2013 (UTC)

Doesn't work for me; all that happens is the "Updated since last visit" in a page's history is now highlighted in screaming green. Ignatzmice•talk 12:21, 9 May 2013 (UTC)

If this isn't working, simply go to the page and copy that text directly into your skin's CSS (or common CSS). Ignatzmice•talk 13:01, 9 May 2013 (UTC)

Related proposal: mw:A sticky navigation. --MZMcBride (talk) 02:39, 10 May 2013 (UTC)

Our friendly designer from Echo strikes again! Theopolisme (talk) 02:10, 11 May 2013 (UTC)

I've thrown together a really simple interactive mockup/demo for an idea that you can play with here. It's not perfect, and I built it inside of 2 hours, so buggy. --Jorm (WMF) (talk) 21:13, 20 May 2013 (UTC)

Discussion

• Support (or is this section for actual discussion, not voting? Feel free to rearrange). With the caveat of not everyone uses JavaScript, this is a great idea. (Maybe it doesn't have to use JS. Remember
  frames?) It would keep the "new messages" notification (and the Notifications notifications!) where you could see them. Not sure how much use it would be besides that, but it would look nice, definitely. Ignatzmice•talk
  22:40, 8 May 2013 (UTC)
  • This could be done with CSS. There are even some script around that fix the entire top area (including the tabs) to stay visible during scrolling. — Edokter (talk) — 22:48, 8 May 2013 (UTC)
    • In that case, the only drawback would be "It's not very useful", which would be outweighed by "Yes it is, for this one thing". There could even be (yet another!) gadget to turn it off. Ignatzmice•talk 22:52, 8 May 2013 (UTC)
• Wikipedia...omg lulz so Web 2.0. But I like it. @Edokter: do you know what that script is called? If you smack a bit of sexy shadow CSS on the bottom I think you could hit it big. Theopolisme (talk) 01:00, 9 May 2013 (UTC)
• Maybe. This would certainly increase visibility. However, in general I don't like fixed tabs; they take up too much space. Right now I have 4 lines on top of each webpage: "Editing Wikipedia:Village...", "File Edit View History", the actual tabs, and the URL bar. A fifth would be very cluttersome. And some browsers have even more stuff on top. And this is assuming mobile is excluded. -- Ypnypn (talk) 02:25, 9 May 2013 (UTC)
• I hate losing screen real estate to links that I almost never click. Please don't do this, and if you're going to anyway, then please post a script that will get it off my screen. I also don't see the point: is it really critical for me to see those links every single second while I'm reading an article? I understand (and hate) Amazon's decision to do this (I might not care as much if I had a much larger screen), but really: why? Do you think I'll have a desperate need to click on my contributions or my sandbox in the middle of reading a page? WhatamIdoing (talk) 16:41, 9 May 2013 (UTC)
• This is a classic instance where a few people want it, and most people don't, hence a custom user script is indicated. See an old (monobook era) version at meta:Help:User style/floating quickbar#Fixing the user toolbar. Once it's working properly in vector, copy it into a new section underneath Help:User style#Fix the sidebar's position while you scroll. Hope that helps. –Quiddity (talk) 22:22, 9 May 2013 (UTC)
• Conditional support. I support this if and only if it is opt-in. Oppose making it the default, because it would take valuable space at the top of my browser window. -- Toshio Yamaguchi 12:01, 10 May 2013 (UTC)
• Conditional support. Also support this only if opt-in, and pressing Page Down or Space actually scrolls one visible page, instead of that plus height of the fixed area. Oppose making it the default. cmɢʟee୯ ͡° ̮د ͡° ੭ 18:52, 10 May 2013 (UTC)
• Oppose as a default change - this seems premature. Stated reasons either don't currently apply in practice, or just aren't good reasons in general in my book.

Link persistence for notifications and whatnot is completely unnecessary - the way mediawiki is set up, nearly every action takes one to the top of a new page where the personal toolbar is clearly visible. This may at some point change, at which point a new skin implementing a more persistent style of navigation not just for personal, but general site navigation, would be required, but we do not currently use a model where infinite scrolling and inline editing and commenting are standard or even supported.

Screen real estate is valuable and should place emphasis on the content, not the user. This is an encyclopedia, not a social network or what have you, and while some principles apply across the board, many do not, and even those that do carry different weights on each. I would argue that saying 'facebook/whatever did it' is not a valid reason for anything by itself. If there is a specific reason facebook/whatever did it that applies here, however, that's another matter, but the reason is what should be considered first and foremost and I don't think the reason applies here for this particular case.

So this might be useful for some folks, but in general it is just not apt to be a good change given present software behaviour as well as the specific skin layout otherwise. -— Isarra ༆ 21:43, 14 May 2013 (UTC)

What about making a Special page Recommended Watchlist in which Admins can add pages and its link can be near current watchlist. So pages which need more attention will be watched through recommended watchlist special page, for a certain period of time.

Also protected pages will be automatically included in the recommended watchlist after the protection time is ended, for a certain period of time. KhabarNegar (talk) 00:14, 20 May 2013 (UTC)

What's the normal ph level for the human body? — Preceding unsigned comment added by 24.4.159.220 (talk • contribs) 16:35, 20 May 2013‎

This isn't the right place for your question. Try asking at "

talk

) 10:39, 20 May 2013 (UTC)

Moved to Wikipedia:Village pump (miscellaneous) § Flow

 – -- Toshio Yamaguchi 22:42, 20 May 2013 (UTC)

1. WP:ATD-R results in the deletion of an article. Although the history still exists and the article's title is still being used as a redirect, the entirety of its content has been removed. A lot of these bold edits end up having to be discussed, because frankly, it's a drastic move. For example, that's why I proposed the deletion of Wikipedia:Articles for deletion/Tons of Funk
   at AFD, even though after its deletion, it was redirected to another article. Had I done this boldly, the people who voted keep in that AFD would have forced the discussion to happen at the talk page anyway. Thus, my official stance is that all ATD-R does is delay the inevitable discussion from happening.
2. The people who participate at talk page discussions are the ones who either (1) watch the article in question, (2) watch
   WP:AFD
   is extremely popular. Users who don't usually edit comic book articles might end up participating in comic book AFDs due to its appearance at AFD's main page. A lot of these merge and redirect discussions just go overlooked, but if these processes were merged into AFD, we would be encouraging the most participation possible. I've participated in many deletion discussions about articles that I would never have crossed by had it not been for AFD. A lot of these discussions ended in "Redirect" and "Merge".
3. When coming across a problematic redirect, our first question is to wonder what we should do with it. Should it be deleted? Renamed? Turned into its own article? Sometimes it just isn't as clear-cut as we would like it to be. Thankfully, that's why we have WP:Redirects for discussion where anyone can propose to discuss a problematic redirect without choosing a "keep, delete, rename" allegiance beforehand. However, our current policies force us to choose a side before opening a discussion when it comes to articles. If you think it should be deleted, go to AFD! If you think it should be merged, use this specific tag! If you want it redirected, just do it, wait for someone to revert and then talk about it on the talk page! But if you want to value the community's input before making a decision, your only hope is to open a section at the talk page and hope that enough people respond. And once that section reaches a consensus, you'll most likely end up doing one of those Deletion or Merge processes afterwards. Frankly, this is just counter-productive. It would be best if we could just open an AFD page where anyone can voice their concerns without outright crying Delete!

Making AfD more like RfD would be a good thing. And that's why I think all these processes should be merged and renamed "Articles for discussion". I know this isn't the first time someone has proposed this, but I think it's time we reopen the conversation. Feedback ^☎ 23:16, 12 April 2013 (UTC)

Have you read the FAQ?

I don't like this page's name. I want to rename it to Articles for discussion or something else.

Please see Wikipedia:Perennial proposals#Rename_AFD. Note that all of the "for discussion" pages handle not only deletion, but also proposed mergers, proposed moves, and other similar processes. AFD is "for deletion" because the volume of discussion has made it necessary to sub-divide the work by the type of change.

How exactly does your proposal solve the problem (high volume) that necessitated the subdivision in the first place? WhatamIdoing (talk) 01:01, 13 April 2013 (UTC)

I know it's been discussed before. I've read at least 3 different threads where the idea has been proposed. But like I said, I think its time we reopen the conversation. It's just counter-productive for us to keep these tasks separate, and I'm hoping we can form a consensus to overhaul it. Feedback ^☎ 01:47, 13 April 2013 (UTC)

I don't see how the proposal to merge the discussions will result in a higher backlog. It will be the same exact "volume" that we have right now. The difference is that instead of having these conversations scattered around Wikipedia, we'd have them all in one place. Frankly, if you think AFD's current backlog is large, imagine all the merge and redirect discussions going on talk pages right now that just aren't being viewed due to the relative unpopularity of said pages. That's the real backlog, and we would be doing a great service by merging them all into AFD. Plus, the less time people use discussing on talk pages means that even more users will participate at AFD. There are only positives here. I don't see the negatives. Feedback ^☎ 01:47, 13 April 2013 (UTC)

I dispute the statement that

That distinction, although important, is irrelevant to the common reader. Whoever read

Corwood Industries yesterday and decides to look it up again today would be dumbfounded when they find that it redirects to Jandek. To the reader, the page is gone. If they want to know why it's gone, they could see that the discussion took place at Wikipedia:Articles for deletion/Corwood Industries and a consensus was achieved to redirect the page. This isn't an extra layer of bureaucracy. This is the proper way to handle the removal of content from the encyclopedia. Sure, someone could still access the page history, but for all intensive purposes, the article that used to be there has been removed from the encyclopedia. That's how it would seem to the common reader and that's who we should have in mind when forming these policies. Feedback ^☎

04:34, 14 April 2013 (UTC)

• As per
  WP:Administrators' noticeboard/Requests for closure#Wikipedia namespace in the section, Wikipedia:Village pump (proposals)#Wikipedia "Merge" like WP:RM or WP:AFD, there is a related recent discussion that is awaiting closure.  Unscintillating (talk
  ) 16:07, 14 April 2013 (UTC)
  • Archived to WP:Village pump (proposals)/Archive 98#Wikipedia "Merge" like WP:RM or WP:AFD. Flatscan (talk) 04:16, 18 April 2013 (UTC)

I want to bring you an example. On April 12, I proposed to merge

Two questions:

1. Why didn't you just boldly merge the pages in the first place?
2. Why do you think that a routine merge proposal ought to get a response in less than three days? WhatamIdoing (talk) 16:20, 15 April 2013 (UTC)

I won't argue that your suggestion isn't sound, but from experience, it just isn't practical. People would revert it and decide to discuss it. Case in point, someone took a non-notable

Talk:The Funkadactyls and the discussion then ended up going to AFD anyway. This is what we're dealing with on Wikipedia. And this is just an example of the many problems this proposal would fix. Feedback ^☎

20:37, 15 April 2013 (UTC)

That's not been my experience, but perhaps I've done more of it than you.

Also, if you wanted outside feedback, rather than comments from the people already at those articles, why didn't you follow the directions at

Wikipedia:Proposed mergers#Requests for assistance and feedback? WhatamIdoing (talk

) 04:53, 16 April 2013 (UTC)

I already linked you to an example where making such a decision boldly forced everyone to jump through hoops to get something done. This happens and it happens a lot. Whether it's happened "in your experience" is irrelevant. And as for PM/Requests, I could have also gone to RFC, or FSR. But there are just more hoops! You are suggesting that I go through the trouble of asking people to participate when AFD automatically gets enough followers to begin with. The aformentioned merge discussion continues to have 0 replies while the AFD has 4. It's evident that the practical thing to do is to have these discussions at AFD instead. Feedback ^☎ 15:45, 16 April 2013 (UTC)

I'm asking you to go through the same number of hoops. Remember that step when you listed the AFD at the AFD page? I'm asking you instead to list the proposed merge at the proposed merge page instead. AFD doesn't "automatically get enough followers" for people to notice an unlisted AFD, just like proposed merges don't automatically get enough followers for people to notice an unlisted PM. WhatamIdoing (talk) 21:00, 16 April 2013 (UTC)

• Strong support: It is often difficult to get reasonable discussion from neutral observers for any of these discussions. Ryan Vesey 16:27, 15 April 2013 (UTC)

• Long overdue. This is just bureaucracy getting in the way. I've seen perfectly good AfD discussions closed simply because the nominator is not proposing deletion. Any discussion that decides whether an article will cease to exist independently should occur at a central location. Though a remark: If an article would be a suitable candidate for
  WP:PROD but the nominator wishes to merge and/or redirect it, then they can just do so BOLDly, and if they get reverted, take it to AfD. This mimics the usual PROD process. -- King of ♥ ♦ ♣
  ♠ 10:16, 17 April 2013 (UTC)
• Support - That happened to me atleast twice. I concur with King of Hearts and wholeheartedly Support centralisation.
  talk
  ) 10:20, 17 April 2013 (UTC)
• At some point in time the general mindset has developed that AfD is only for deletion, and no decision other than delete/keep/no consensus can be made, going so far that even when there is a clear consensus for merge or redirect (as acknowledged by the closing admin), the article will still be kept because it's an AfD. That is unfathomably stupid on so many levels. This proposal would eliminate that stupidity, so strong support. --Conti|✉ 10:44, 18 April 2013 (UTC)
• Support centralization per King of Hearts' rationale. He sums up my opinion perfectly. Imzadi 1979 → 10:48, 18 April 2013 (UTC)
• Support people treat AFD like this already, including myself, since the proposed merge process is largely ineffective. --Rschen7754 10:57, 18 April 2013 (UTC)
• Strong support. Ironholds (talk) 12:37, 18 April 2013 (UTC)
• Comment: I have no strong objections to the general idea, but I think the specific title "Articles for discussion" is potentially vague / confusing for less-experienced users; it might mislead some into thinking that all significant changes to articles need to be discussed there rather than being
  boldly applied. --SoledadKabocha (talk
  ) 19:58, 18 April 2013 (UTC)
• Support. I agree with a number of points here. The merger process has been, in my experience, ineffective at generating discussion. There also is some unnecessary bureaucracy at AfD: I've seen AfDs closed for proposing mergers or redirects (although I have admittedly advocated for these closings at times in the past). Additionally, I've seen AfDs with a consensus to merge closed as keep, with the closing admin stating that merges must be discussed on the talk page instead, despite existing consensus. I believe this proposal would address these issues rather well, but I must concur with SoledadKabocha that a better name than 'Articles for discussion' could be chosen. (Thus my grand return to Wikipedia begins…) CtP (t • c) 21:38, 18 April 2013 (UTC)
• Question - Should obvious redirect articles, such as a
  talk
  ) 00:52, 19 April 2013 (UTC)

  As I said in my comment, if an article is uncontroversial enough that it would fall under PROD if deletion were being proposed, then a BOLD redirect is fine. -- King of ♥ ♦ ♣ ♠ 01:08, 19 April 2013 (UTC)

• Oppose. A real problem has been cited, but this is the wrong solution.
  As has been pointed out on numerous occasions, a merger cannot be carried out in the same fashion as a deletion (i.e. by pressing a button). It often requires a significant amount of time, planning, effort and discussion (before and during the process), along with a higher degree of familiarity with the subject than can be expected of participants in an outside process. That's why it makes sense to organize such matters on the articles' talk pages.
  Chris the Paleontologist has "seen AfDs with a consensus to merge closed as keep, with the closing admin stating that merges must be discussed on the talk page instead, despite existing consensus." Such a closure is flat-out wrong. AfD isn't the correct venue in which to propose a merger, but if such a consensus is reached (as an alternative to deletion), it's entirely valid. The correct course of action is to tag the source article with {{
  David Levy
  01:39, 19 April 2013 (UTC)
• Support So many times I have seen discussions on talk pages either lay ignored or argued by the same people involved in the article. AfD is a better venue, especially since some of the outcomes result in the deletion/dissapearance of the article in question. And I support the name change to Articles for Discussion, but I have a feeling that'll be a different discussion for a different day. One step at a time. Angryapathy (talk) 01:41, 19 April 2013 (UTC)

  If a merger proposal is ignored, the merger may simply be carried out. The proposal isn't required in the first place; it's an optional request for input/assistance. That's one of several respects in which merger proposals are fundamentally different from deletion nominations. We needn't shift routine article improvement discussions to a separate venue. —

  David Levy

  01:57, 19 April 2013 (UTC)

  Not really. We have two cases: either it's potentially controversial or it's not. If it is, then even if the merger proposal is ignored, the merger should not be carried out. If not, then yes, just carry it out; no one is suggesting we get rid of the ability to merge without discussion entirely. In deletion we have

  WP:PROD for that. -- King of ♥ ♦ ♣

  ♠ 02:02, 19 April 2013 (UTC)

  One of the purposes of proposing a merger instead of simply performing it is to determine whether it's controversial. If no one objects (and no other evidence of controversy exists), it's okay to simply proceed with the merger. No administrative tools are involved (and no content is made inaccessible), so anyone can undo the merger and revive the discussion. It's simply a form of

  David Levy

  02:31, 19 April 2013 (UTC)

  Before you can start discussing how to merge, you must decide whether to merge. And that is something which AfD can perfectly handle. -- King of ♥ ♦ ♣ ♠ 09:49, 19 April 2013 (UTC)

  As noted above, AfD cannot "perfectly handle" all merger proposals. It depends on the context.
  If an article has been nominated for deletion, it's reasonable to discuss merging as an alternative. If the article's very existence is seriously challenged (and relocating its content elsewhere is viewed as a viable alternative to deleting it outright), "merge" is a reasonable AfD outcome.
  But if deletion isn't requested, there's nothing to be gained (and a great deal to lose) by shifting the discussion to a separate forum. In such a circumstance, a merger proposal is an ordinary article content discussion, with no outside process or administrative intervention required. What often is required is input from persons knowledgeable on the articles, their subjects and their sources, discussing the proposed merger over a period likely to exceed AfD's arbitrary duration. It might be a while before editors respond (depending on how much traffic a talk page receives), in which case such a wait is necessary. Artificially accelerating the discussion by shifting it to AfD and closing it after a week or two is actively counterproductive. It greatly reduces the likelihood of soliciting input from editors whose knowledge enables them to understand how the articles' subjects relate, thereby greatly increasing the likelihood of reaching the wrong decision (which will either be undone or never be carried out). This already is an issue, as evidenced by the numerous talk pages littered with years-old {{

  David Levy

  14:26, 19 April 2013 (UTC)

• Oppose. Merges and Smerges and conversion to redirect are not deletion discussions. Redirects that are put forward as "Redirect or Delete but the article and content must not stay" are in practice already welcome at AfD. Merges and Smerges require a lot more care than is appropriate for a seven day discussion. Generally the motivation comes frmo the article to be merged, but then needs to be negotiated at the target, and then things get complicated beyond the scope of a seven day discussion. A disputed merge would be more appropriately listed as an RfC. However, what we need is more bold editing and less process, contrary to the likely effect of this proposal. From the AfD perspective, AfD is a well functioning polished process but so overloaded it is ripe to bust or collapse. Pushing ill-aligned difficult merge discussions, and a large proportion of straightforward merge discussions into it may break its back. --SmokeyJoe (talk) 02:10, 19 April 2013 (UTC)
• Oppose Deletion is a restricted function and so requires a special process. AFD is that process (along with PROD and CSD) and is already overloaded. Discussions at AFD are usually poorly attended, especially by editors who have some clue about the topic in question. For a fresh example, see
  WP:TLDR. Warden (talk
  ) 10:27, 19 April 2013 (UTC)
• Oppose - merges and redirecting may be done by any registered user, subject to BRD; deletion is a restricted action, subject to strict policy, and possible only by admins. These should not mix. עוד מישהו Od Mishehu 10:52, 19 April 2013 (UTC)
• Oppose per Warden. He says what I would have said had I said it before he said it. --Jayron32 13:40, 19 April 2013 (UTC)
• Strongly support We have way too many venues to discuss things such as this. The arguments that closing an AfD should be as simple as pushing a button make no sense to me. Why should it be like that? So that people who are trying to rack up a high score can play the AfD game with no thought involved? That doesn't seem like a good reason to me. Gigs (talk) 16:12, 19 April 2013 (UTC)

  You've misunderstood. No one is arguing that "closing an AfD should be as simple as pushing a button". The point is that carrying out a decision to delete a page is accomplished in this manner. Consensus is achieved at AfD. Then an admin pushes a button, which deletes the page.
  Conversely, when a discussion results in consensus to perform a merger, we have no such button to make it happen. It requires actual editing, which often follows a great deal of planning and collaboration. Article talk pages exist for the purpose of accommodating such discussion. It's ordinary article revision, which is fundamentally different from deletion. —

  David Levy

  17:20, 19 April 2013 (UTC)

• Oppose. This discussion is a demonstration of how formal procedures lead to voting, rather than constructive discussion with everyone aiming for consensus as is more commonly found on article talk pages. When I first commented above I did so without prefixing my remarks with a bolded recommendation, in the hope that others would do the same, but, as is normal for centralised discussions such as the village pump or AfD, this has degenerated into a vote with different sides taking entrenched positions, so I have to give my bolded "oppose" to ensure that my opinion is taken into account. Let's not subject editorial decisions such as merging to the same adversarial procedures. I could say much more, but SmokeyJoe, Colonel Warden and David Levy have expressed my thoughts better than I could do myself.
  Phil Bridger (talk
  ) 17:37, 19 April 2013 (UTC)
• Support - The net result may be fewer deletions, more merges and redirects when everything is more properly on the table. The overlap justifies consolidation, and allows to (perhaps) discuss more and vote less. Dennis Brown - 2¢ © Join WER 18:48, 19 April 2013 (UTC)

  The option of merging and redirecting already is on the table at AfD. In no way does the current format limit the options to "delete" and "keep as a standalone article".
  An AfD debate can result in a number of different outcomes. This doesn't mean that such solutions should be proposed there. For example, there might consensus that an article shouldn't be deleted, but it requires cleanup. That doesn't mean that cleanup proposals should be made at AfD.
  Merging essentially is a form of cleanup. It isn't comparable to deletion and needn't be routinely discussed in a special forum. —

  David Levy

  19:04, 19 April 2013 (UTC)

  Of course they are, that isn't the point. The point is that often someone might not know the best course of action, but know a stand alone article isn't the right answer. Having to choose from multiple places doesn't insure a better outcome, and may actually prevent the best possible outcome for each situation. At the end of the day, we serve ourselves best by having a system that simplifies the process of discussing a "problem" article, and doesn't require a nominator to determine the best possible outcome in advance. Dennis Brown - 2¢ © Join WER 22:01, 19 April 2013 (UTC)

  If someone believes that deletion should be considered (but isn't certain that it's the best solution), he/she can list the article at AfD (and can even mention merging as a possible alternative). This occurs under the current system; no change is required to enable it.
  If someone specifically wants to merge the article with another (and doesn't believe that deletion should be considered), there's no need to list it at AfD; the best discussion forum is the article's talk page (for reasons that I've explained above). The proposal, if implemented, would remove that option. It wouldn't make things any easier for editors who wish to discuss both deletion and merging, who already can do so at AfD. —

  David Levy

  22:43, 19 April 2013 (UTC)

  No need to

  bludgeon the discussion, I'm aware of the current system and have participated in it extensively for many years. To say this would take away the ability to use the article talk page stretches credibility to the breaking point. Dennis Brown - 2¢ © Join WER

  11:07, 20 April 2013 (UTC)

  I'm discussing the matter in good faith, with no intention of overwhelming others or ignoring their evidence. I disagree with you, but I'm not attacking you or disrespecting your opinion. I'm sincerely attempting to understand your argument and alleviate any possible misunderstanding on my part or yours.
  Given your familiarity with the current system, why do you assert that the proposed change is necessary to enable combined deletion/merger listings at AfD?
  Regarding the use of article talk pages, I'm unsure of what you mean. The idea calls for all merger proposals to occur at AfD. —

  David Levy

  12:00, 20 April 2013 (UTC)

  From my experience, most merges don't happen at

  WP:Proposed merges to begin with, it happens with ordinary discussion on talk pages, a more informal process. This wouldn't prevent that. My argument is based on participating in over 1600 AFDs over the years, and having first hand experience with virtually every possible scenario. Doesn't make me right, but it does mean I'm familiar. Any time an article goes to any of these venues, the underlying problem is "This probably doesn't need to be a stand alone article", so consolidating them will mean a higher likelihood that all options will be considered, not just the default option for that particular venue. I'm shocked Warden doesn't like this, as it will likely mean fewer deleted articles, more merged content, more participation and a broader cross-section of the community reviewing each case. It means simplicity and a system that can be easier to use for the community as well. And the very name "Articles for discussion" can create an atmosphere that is seemingly less hostile that "Articles for DELETION", perhaps resulting in less voting (ie: the useless per nom !votes...) and more actual discussion. Human nature is funny that way. And by all means, express your opinion but please don't "alleviate" anything. While surely unintentional, it makes it sound as if the other person's !vote is based on ignorance or lack of experience. Dennis Brown - 2¢ © Join WER

  16:06, 20 April 2013 (UTC)

  From my experience, most merges don't happen at

  David Levy

  18:08, 20 April 2013 (UTC)

  Note: Via this message,

  David Levy

  12:39, 29 April 2013 (UTC)

• About the volume: we tag about 200 articles per week for merging. Only a small fraction of these actually get listed at PM as being controversial or otherwise wanting input from people outside the regular editors at the page. The OP, for example, started this discussion one hour after proposing a merge. He never listed it at PM, where it would have turned up on several hundred watchlists. He just tagged it, put two sentences on the talk page, and then complained here that nobody commented fast enough to satisfy him.
  
  CAT:AFD has almost 500 AFD debates open at the moment. The daily AFD pages are already very slow to open. And if you add in 200 PMs... well, then you'll get what you expect. And if you're not going to list all of them, then we go back to the original question: why should we list PMs at AFD (opening them up to the possibility of unexpected deletion, because there's no way to prohibit people from !voting to delete what you only wanted to merge) when listing them at PM (whenever people like the OP choose to list them) seems to get the job done just as well? WhatamIdoing (talk
  ) 20:14, 19 April 2013 (UTC)

  Right, most merger discussions don't really require a community discussion, just agreement on the talk page. So we won't be overwhelmed. that very few come to central page for them contributes to having it neglected, and is a reason to bring it into a more visible procedure. DGG ( talk ) 19:47, 21 April 2013 (edit) (undo)

  Right, most merger discussions don't really require a community discussion, just agreement on the talk page.
  This proposal calls for "all the merge and redirect discussions going on talk pages" to instead occur at AfD. —

  David Levy

  19:53, 21 April 2013 (UTC)

• Oppose Been thinking about this since proposed. Fence sitting. D. Levy (above) has it right I think, and I'm off the fence. The Merger discussion needs to take longer than the AfDelete discussion, because it takes that time for knowledgeable editors to make their way to the talk pages of the merge requests. This proposal will overwhelm AfD, and we will unavoidably lose (good content and potentially good) articles because of the discussion-time limitations there. We can use help, by the way, working on the oldest (back-end) articles at Category:Articles to be merged after an Articles for deletion discussion. Thanks. GenQuest ^{"Talk to Me"} 23:58, 19 April 2013 (UTC)
• Oppose - Merger discussions can be longer than deletion discussions need to be, and the sheer volume of deletion discussions means that they need their own place. Lukeno94 (tell Luke off here) 10:08, 20 April 2013 (UTC)
• Oppose per my exact same comment I made several years ago at Wikipedia talk:Articles for discussion/Proposal 1, which remains largely unchanged (with minor edits):

  I don't understand why a blessing from an admin is necessary on anything except a deletion or non-deletion as far as AFDs are concerned. Also, perhaps I'm against this notion of, as opposed to keeping discussions on major editorial actions (such as merging) local and strictly amongst those users who are actively collaborating on an article, having "community exposure" on each and every single major editorial action made on every article on Wikipedia. Article talk pages, not a centralized community venue, are the places to discuss such editorial changes. I think we've gotten so lock-step into just typing in simple !votes for literally everything (like what we're all doing here now) instead of actually having a discussion, which has been at least what I have experienced in the last few merge proposals I have brought up (even though it's been a while, now). I also have to echo some of the concerns that Colonel Warden brought up such as overloading the already-overloaded (IMO) AFD queue.

  Also per Colonel Warden's statements made above today. --MuZemike 17:26, 20 April 2013 (UTC)

• Support Many redirects are mergers are noncontentious, and don't need a discussion; but may are, and they are usually a question of notability. Notability is best judged by discussion, and the discussion is best at a centralized place where all the possibilities can be considered. The idea that redirects and merges are just ordinary editing is long obsolete, if it was ever true. We now accept that an afd close can force a redirect or a merge, and many do. And, it still does happen that a redirect or merge is a disguised deletion--and this will succeed if attention is not paid. The way of getting attention is to list at AfD. Articles for discussion is what it really is, and people increasingly do bring articles there even if they are not sure they should be deleted, in order to get a community devision. It's the best way yto get a good result. . Six years ago, AfDs would be summarily closed as inappropriate if the purpose were other than deletion, which is now rarely argued. It is good to have a discussion sometimes not to bring about what one wants, but to see what is wanted. We passed this once, 4 or 5 years ago, but forgot to implement it. let's do it now. DGG ( talk ) 06:28, 21 April 2013 (UTC)

  The idea that redirects and merges are just ordinary editing is long obsolete, if it was ever true.
  They aren't ordinary editing? What nonstandard tools are involved?
  We now accept that an afd close can force a redirect or a merge, and many do.
  An AfD debate might result in the determination that an article requires cleanup (copyediting, better sourcing, etc.). That doesn't mean that AfD is the correct venue in which to request cleanup.
  Articles for discussion is what it really is, and people increasingly do bring articles there even if they are not sure they should be deleted, in order to get a community devision.
  I'm not 100% clear on what that means, but yes, editors are welcome to list an article at AfD if they're unsure of whether it should be deleted or merged. As you've noted, this already occurs. So why is the proposed change needed? Why should all merger discussions be held at AfD?
  We passed this once, 4 or 5 years ago, but forgot to implement it. let's do it now.
  We passed a proposal to shift all merger and redirection discussions to AfD? Please provide a link. —

  David Levy

  07:33, 21 April 2013 (UTC)

  Wikipedia talk:Articles for discussion/Proposal 1 is likely what you are looking for. We had the consensus, what was lacking was the follow through on implementation. Dennis Brown - 2¢ © Join WER 11:48, 21 April 2013 (UTC)

  That was a proposal for a setup in which "anyone could optionally move a disputed merge to AfD, retitled Articles for Discussion". This is a proposal for "all the merge and redirect discussions going on talk pages" to be replaced by "merging them all into AFD". —

  David Levy

  16:26, 21 April 2013 (UTC)

• Comment: Again, I would like to reiterate that this proposal does not mean AfD will be the place to discuss how to merge an article into another, but merely whether it should be done (depending on its level of individual notability). The ultimate merging process will be discussed on the talk page, as always. -- King of ♥ ♦ ♣ ♠ 08:30, 21 April 2013 (UTC)

  ...which is exactly what's done now when an AfD debate results in a decision to merge. As discussed above, we needn't shift all merger proposals there to enable this to occur. The current system facilitates it.
  Most merger suggestions, many of which have nothing to do with the subject's "level of individual notability" (instead focusing on simple matters of length and organization), are best suited to the relevant articles' talk pages. Routine editing discussions don't belong in outside forums. Article talk pages exist to accommodate them. —

  David Levy

  16:26, 21 April 2013 (UTC)

• Support, standardization and uniformity and centralization would be a good thing. — Cirt (talk) 18:17, 21 April 2013 (UTC)
• Support. The current system is confusing for new users. It can take a good while for users to get their heads around our different notability criteria and precedents at AfD, and it is easy for them to choose the wrong venue. Putting all these discussions in one place with one procedure would make things simpler, and the less steep our learning curve is the better chance we have of retaining editors.

  If doing this makes the daily logs too slow to load we should fix this by technical means - there's no need to throw out a promising proposal because it doesn't match the exact page structure we have at the moment. For example, we could link all the discussions in the daily logs instead of transcluding them, and in addition create daily logs sorted by the subcategories in

  WP:DELSORT with the current AfD structure. — Mr. Stradivarius ^{♪ talk ♪}
  15:32, 22 April 2013 (UTC)

  It can take a good while for users to get their heads around our different notability criteria and precedents at AfD,
  And the solution is to send more discussions there (including many that have nothing to do with notability)?
  and it is easy for them to choose the wrong venue.
  Under the proposed change, users attempting to discuss ordinary editing (reorganizing content by transferring it from one page to another) on the relevant articles' talk pages would be informed that they've "chosen the wrong venue" and forced to file a special listing at an outside forum, where editors who've never seen the articles before will reach a binding decision by an arbitrary deadline. This is supposed to make things easier and less intimidating?
  Putting all these discussions in one place with one procedure would make things simpler, and the less steep our learning curve is the better chance we have of retaining editors.
  Why stop with these discussions? Why not eliminate article talk pages entirely and move all content discussions to AfD? "Want to discuss expanding an article, rewording a section, or updating some of the sources? Take it to AfD. We're making things simpler by putting everything in one place with one procedure." —

  David Levy

  17:27, 22 April 2013 (UTC)

• Support, since many AfD discussions result in mergers and/or redirects anyway as it is; AfD is, de facto, "Articles for Discussion". Miniapolis 21:41, 26 April 2013 (UTC)

  AfD discussions result in all sorts of outcomes other than deletion. It might be determined that an article requires cleanup (copyediting, better sourcing, etc.). Should we transfer all cleanup requests to AfD? —

  David Levy

  00:26, 27 April 2013 (UTC)

• Support This is pretty much happening already, and a lot of mergers and redirects touch on notability and other topics at which regular AFDers are expert. This would also, hopefully, reduce the distressing number of "hanging" merger and redirect proposals. Ray^Talk 23:36, 26 April 2013 (UTC)

  This is pretty much happening already,
  Merger discussions are being barred from talk pages and preemptively sent to AfD?
  and a lot of mergers and redirects touch on notability and other topics at which regular AFDers are expert.
  A lot don't. Many merger discussions relate strictly to considerations of article length and organization (and have nothing to do with notability or anything similar). Routine article content discussions don't belong in a special forum. The articles' talk pages exist specifically to accommodate them.
  This would also, hopefully, reduce the distressing number of "hanging" merger and redirect proposals.
  ...by enforcing an arbitrary deadline instead of waiting for someone knowledgeable on the articles' subjects and their relationship to participate. Then we'll have a huge backlog of merger decisions instead of merger proposals (because, as discussed above, we have no "merge" button to press). Numerous talk pages already are littered with years-old {{

  David Levy

  00:26, 27 April 2013 (UTC)

• Support for borderline cases. Merge and redirect have long been possible outcomes at AfD, and I have for many years observed that the backlog at those other pages make it very unlikely for a decision, discussion, or any outcome whatsoever to occur at the other venues in a timely fashion. However, I believe these venues should be retained for complex or highly controversial merge and/or redirect proposals. AfD is perfect for borderline cases: pages that could stand to be deleted, but a merge or redir accomplishes the same outcome. Pages like these are simple to review, and the merge tends to be a copy-paste of a paragraph into the destination article. However, the community at AfD would be incapable on the whole of evaluating a complex merge or split proposal. —/Mendaliv/^2¢/_Δ's/ 21:54, 28 April 2013 (UTC)

  As discussed above, in borderline cases (in which someone is unsure of whether an article should be deleted or merged), the current system permits an AfD listing (in which both options, along with other possible solutions, are considered). No change is needed to enable this; it's how things work now.
  The proposal calls for "all the merge and redirect discussions going on talk pages" to instead occur at AfD, which you obviously don't support. —

  David Levy

  22:31, 28 April 2013 (UTC)

  When I said borderline above, I should have said "notability-based". That is, I support the rolling of pure merge or pure redirect proposals into AfD where such proposals' rationales are based on relatively bright-line notability (as well as

  undue weight issues? I think AfD at present requires very different skills, and to force the entirety of proposed merges onto AfD would either disrupt the culture this proposal hopes to harness, or result in a large number of ignored merge/redirect requests just as under the present system. —/Mendaliv/^2¢/_Δ's

  / 23:06, 28 April 2013 (UTC)

  Thanks for clarifying. Depending on its implementation, I might support a proposal to shift disputed mergers based on notability concerns and

  David Levy

  23:37, 28 April 2013 (UTC)

  This proposal does not take away the ability of an editor to boldly merge two articles, or boldly use ATD-R. If an editor feels that his edit doesn't require a formal discussion, then by all means, he/she can edit boldly. However, if an editor feels that these decisions require a discussion, then this proposal says they should go to AFD instead of the article's talk page. At AFD, they will get more participation and a much clearer community consensus. Feedback ^☎ 11:59, 29 April 2013 (UTC)

  Yes, I understand your proposal. I've explained why most merger discussions belong on articles' talk pages and why shifting all of them to AfD wouldn't result in "more participation and a much clearer community consensus". —

  David Levy

  12:18, 29 April 2013 (UTC)

  This can be handled by a slight tweak, instead of "that require a discussion". make it "that are disputed". DGG ( talk ) 02:49, 2 May 2013 (UTC)

  "Proposed mergers lacking consensus (for or against)" might be a better description. (Otherwise, a single editor could block a strongly supported merger and send the matter to AfD by opposing it without explanation.)
  In a no-consensus situation, I still see no need to transfer the actual discussion to AfD (especially if it's already active on the article's talk page). A possible alternative is a notification system, similar to RfC, though which messages are posted at AfD to invite its editors to participate. —

  David Levy

  03:45, 2 May 2013 (UTC)

  You keep replying to everybody with basically the same points. Take a chill pill and try to avoid spamming the discussion. All of your 22 above posts are available to everyone who participates in the discussion, you don't need to repeat them under every single vote. Feedback ^☎ 01:34, 4 May 2013 (UTC)

  Good-faith discussion ≠ "spamming". Some of my comments are repetitious because I'm attempting to interact with editors casting votes without addressing relevant concerns previously expressed. Some of the supporters misunderstand what you've proposed (in part, most likely, because the section heading refers to "WP:Proposed mergers" instead of all merger discussions), and they evidently aren't reading the previous messages in which the discrepancy was explained.
  It's odd that you wrote the above complaint in response to a message in which I expressed partial agreement with a supporter and suggested a possible implementation not previously mentioned. —

  David Levy

  21:33, 4 May 2013 (UTC)

  I see why it can cause confusion, but think the title is still adequate. I'm asking to merge the three processes above. Merge, Blank-&-Redirect and Deletion discussions should all be done at AFD. Feedback ^☎ 02:19, 5 May 2013 (UTC)

  I'm not blaming you for the misunderstanding. (Having read your comments, I found your proposal clear.) I'm explaining why my replies have been partially repetitive: some editors seem to be skipping past earlier messages, including those in which you explained that the idea is to relocate all merger discussions (not merely those listed at

  David Levy

  03:59, 5 May 2013 (UTC)

  Given the number of people whose comments basically amount to "I didn't read Feedback's clearly explained proposal", I'm adding a nutshell in this edit that summarizes the key points that people keep missing. Perhaps it will result in comments that have something to do with this proposal, rather than with some imaginary proposal. WhatamIdoing (talk) 04:21, 6 May 2013 (UTC)

  Apparently not. —

  David Levy

  16:54, 9 May 2013 (UTC)

• Support: merge discussions in talkspace are woefully underdiscussed;
  Talk:Men and feminism#Split and merge was proposed last March and didn't get any input until this February, and as of May, still no action has been taken. At the same time, with AfDs often getting relisted, I suppose that a standard 14-day limit with an early close option of seven days may be a good idea to ensure enough input for both merge and deletion discussions. Sceptre ^(talk
  ) 04:44, 5 May 2013 (UTC)

  How, in your view, would such a change be beneficial?
  Let's assume, for the sake of discussion, that an AfD listing would generate more input (despite the lack of urgency brought about by the threat of deletion). And let's assume that the decision is to merge. Then what? Who's going to perform the merger?
  As noted above, numerous talk pages contain {{

  David Levy

  05:56, 5 May 2013 (UTC)

• Comment: This proposal is based upon the premise that AfD debates receive a great deal of participation not because of their subject, but because they occur at AfD. This simply isn't true. They attract attention because they're about potential deletions — last-resort administrative actions that most users cannot undo.
  It doesn't make sense to think that we can take other topics (with far less urgency and no administrative intervention needed), slap an "AfD" label on them and magically duplicate the amount of feedback received via the current format. We'll simply end up diluting (and overburdening) the entire process, while simultaneously shifting the discussion away from the eyes of the editors most capable of addressing the relevant concerns (who might not show up within a week or two, but will be willing and able to provide assistance when they do arrive). —
  David Levy
  06:21, 5 May 2013 (UTC)
• Oppose. Merges and splits are content issues and should be part of the
  WP:WIAFA, etc. (as oppose to the more blank-and-white deletion policies and guidelines), and thus will most likely not be able to post more helpful comments. Thus, this would become a fruitless exercise that adds to an already overburdened AFD process, with closing admins just posting the AFD-merge tag without actually performing the merge, and we are back to square one. IMO, it is more efficient to just go with the BRD cycle and subsequent dispute resolution steps involving merges and any other content related issues, rather than moving each and every such discussion to a central "Articles for discussion". Zzyzx11 (talk
  ) 18:35, 5 May 2013 (UTC)
• Support - It seems to me that many people above object to a perceived effort to bureaucratize the merger and redirection process and make it a function of administrators rather than of non-administrative editors. I'm not afraid of this. This seems to be a streamlining and a rationalization of a process in which there ALREADY are bureaucratic processes for mergers and redirections which is (justifiably) little used, and which will continue to be used only in controversial cases. I like the idea of renaming things FOR DISCUSSION rather than FOR DELETION, since Keep is a frequent and legitimate outcome of that process and I have dealt with more than one newcomer to WP who has been thoroughly put off that their undersourced-but-legitimate contribution to the encyclopedia had been prejudged to be unworthy by unseen forces and was slated for doom. "For Discussion" is less menacing to newcomers. It makes sense to me to have as few deletion/discussion boards as possible so that participation is broader and roosts are not ruled by a small handful of agenda-driven editors as well. So this is a win/win/win/win from my perspective: it makes things more rational, less bureaucratic, less menacing, more participatory. Carrite (talk) 15:59, 9 May 2013 (UTC) Last edit: Carrite (talk) 16:02, 9 May 2013 (UTC)

  This seems to be a streamlining and a rationalization of a process in which there ALREADY are bureaucratic processes for mergers and redirections which is (justifiably) little used, and which will continue to be used only in controversial cases.
  As discussed at length above, this is not merely a proposal to merge the outside processes, and it would not affect only "controversial cases". The idea is to shift all merger and redirection discussions (including those currently held without any sort of external listing) to AfD on a mandatory basis. The use of articles' talk pages for this purpose would be disallowed. —

  David Levy

  16:54, 9 May 2013 (UTC)

  The proposal isn't limited to actions that are currently discussed on article talk pages, but would also explicitly disallow bold redirection, requiring any redirection to be discussed even when that action is obviously correct, such as in the case of duplicate articles. That's a vast increase in in bureaucracy. There may be a case for mergers and redirections to be listed at at a consolidated "articles for discussion" if they are contested and discussion at article talk pages doesn't result in consensus, but that's a very different proposal from this one.

  Phil Bridger (talk

  ) 18:39, 9 May 2013 (UTC)

  That's an outright lie. Like I said above: "This proposal does not take away the ability of an editor to boldly merge two articles, or boldly use ATD-R. If an editor feels that his edit doesn't require a formal discussion, then by all means, he/she can edit boldly. However, if an editor feels that these decisions require a discussion, then this proposal says they should go to AFD instead of the article's talk page.". I'm not campaigning to rid Wikipedia of bold editing. I'm only asking for the discussions to all be held at AFD. That's why I only want"WP:Proposed Merges" to be merged into AFD, not the whole merge process. Feedback ^☎ 18:47, 9 May 2013 (UTC)

  Feedback, you misunderstand the process, and IMO that's where the biggest problem in this discussion is coming from. Here are the facts:

  • 98% of the mergers requiring discussion are handled on article talk pages.
  • Only 2% of the mergers requiring discussion are handled at PM.

  When you combine "mergers requiring a normal discussion at the article talk page" (98%) with "mergers requiring an extraordinary discussion elsewhere" (2%), you get "all mergers requiring a discussion" (100%).

  Do you understand that "two percent of mergers requiring a discussion" is noticeably less than "all mergers requiring a discussion"? You say on the one hand that you want ""all mergers requiring a discussion" to be handled at AFD—that'd be 100%—and then you turn around and say you "only want 2% (i.e., the tiny fraction of mergers requiring discussion that require more than normal discussion and thus get listed at PM) to be merged to AFD".

  So make up your mind: do you want 2% of mergers requiring a discussion to be handled at AFD, or do you want 100% of mergers requiring a discussion to be handled at AFD? WhatamIdoing (talk) 19:40, 9 May 2013 (UTC)

  Feedback, how is it an outright lie that your proposal said "Thus, my official stance is that all ATD-R does is delay the inevitable discussion from happening.", and the very title of this discussion calls for the merging of

  Phil Bridger (talk

  ) 19:51, 9 May 2013 (UTC)

  Yes, I think ATD-R should be done away with. That's because ATD-R says that you should act boldly first and only discuss it if the change is disputed. It's an impractical guideline, and it's the only one that tackles the process of replacing articles with redirects. That's why I believe it should be merged into AFD. In this new AFD, uncontroversial merges and redirects will still be able to be performed boldly. It's up to editorial judgment whether to propose it at AFD or not. All of this has been made very clear above. Feedback ^☎ 21:00, 9 May 2013 (UTC)

  That comment is self-contradictory. You say that you want to do away with the policy that says "any user can boldly redirect to another article", but then say that redirects will still be able to be performed boldly. Can they or can't they?

  Phil Bridger (talk

  ) 21:18, 9 May 2013 (UTC)

  I want to eliminate the policy that says redirections should be carried out boldly and only discussed if they are disputed after the fact. I believe that to the average reader, replacing articles with redirections is the same as deleting. They won't know the bureaucratic differences when they find out that

  Corwood Industries no longer is an article, but instead redirects to Jandek. All they will know is that an article that used to be in the mainspace is no longer there. Therefore, I believe we should discuss potentially controversial redirections at AFD before carrying them out. Feedback ^☎

  21:27, 9 May 2013 (UTC)

  The current policy says "can", not "should".

  Phil Bridger (talk

  ) 21:39, 9 May 2013 (UTC)

  Phil Bridger (talk

  ) 21:51, 9 May 2013 (UTC)

  That's an outright lie.
  Please

  David Levy

  20:24, 9 May 2013 (UTC)

  Whether he lied or spoke a mistruth out of confusion is not really important. Let's not try to sway the discussion. I apologize if anyone interpreted any bad faith from my comments. Feedback ^☎ 21:00, 9 May 2013 (UTC)

  I neither lied nor spoke a mistruth out of confusion. Your proposal, and your most recent comments, are perfectly clear in saying that you want to remove the policy that says that articles can be boldly redirected.

  Phil Bridger (talk

  ) 21:20, 9 May 2013 (UTC)

  Whether he lied or spoke a mistruth out of confusion is not really important.
  The distinction between dishonesty and misunderstanding is quite important. You unambiguously alleged the former.
  Let's not try to sway the discussion.
  Depicting one's opponent as a liar certainly could be perceived as an attempt to

  David Levy

  21:46, 9 May 2013 (UTC)

Feedback, you've just removed this summary:

This page in a nutshell: This is a proposal to list all (200+ each week) proposed merges at AFD (in addition to 500+ AFDs each week). This includes: Pages that would be blanked and redirected without needing any administrator intervention Proposed merges that are not expected to be contentious (98%) Proposed merges that are expected to be contentious and therefore are currently listed at WP:PM (2%)

with the claim that it isn't true. Can you explain what, exactly, isn't true? Can you revise it to make it accurately reflect your proposal? Can you, again, tell me why you keep talking about "all mergers requiring discussion" being held at AFD, and then telling people that you don't mean "all" when you say "all"? WhatamIdoing (talk) 22:27, 9 May 2013 (UTC)

It could be that I am confused as to what you mean by "contentious". My proposal is very simple and some of you are blowing it out of proportion. I just want proposed merges and AFD to be merged into "Articles for Discussion", while also expanding its scope to also include potentially controversial redirections. Uncontroversial/bold merging which aren't proposed at WP:PM will still continue in the same capacity. I've said it before and I'll say it again, I want to merge AFD with PM, not the entire merge process. Feedback ^☎ 13:41, 10 May 2013 (UTC)

You've repeatedly stated that your proposal applies to all merger discussions currently appearing on articles' talk pages. Do you not understand that most aren't listed at

WP:PM

? You initiated such a discussion less than an hour before authoring this proposal. You even cited it as an example. 12:50, 11 May 2013 (UTC)

I don't know if I'm just being terribly unclear, but you keep misunderstanding the proposal. I will try and make it clear:

1. Community consensus has deemed it necessary for people to start a thread at AFD if they wish for an article to be vanished from the main-space. A lot of those discussions end in "merge" and "redirection" due to the overlapping nature of all three processes involved (i.e. Merging usually results in the elimination of most of an article's content, while redirection usually ends up in the "blanking" of an entire article). If it has become the norm for AFDs to end in one of four ways (the fourth being a "keep"), then I believe people should be able to propose any of the four at AFD.
2. At Articles for discussion, people will be able to nominate a problematic article for discussion while proposing a (1) merge, (2) a redirection, (3) a deletion, (4) or even a keep. In fact, users should also be allowed to bring up problematic articles for discussion even when they haven't decided what action to take. They can nominate it at AFD just to spark a discussion without the requirement of crying "delete" or "merge" beforehand.
3. As part of the creation of Articles for discussion, I feel that "Proposed merges" would be redundant. Whatever purpose it is fulfilling now will be taken up by Articles for discussion.
4. ATD-R is a confusing rule, as it allows editors to perform redirections first and only discuss it after someone disputes the change. This rule would have to be abandoned if redirection proposals are officially part of the AFD process. Uncontroversial redirections can continue to be performed outside AFD, just like uncontroversial deletions and uncontroversial merges.
5. No one is refuting the importance of talk page discussions. Talk pages are part of the foundation of the encyclopedia. Editors can continue to propose modifications on talk pages including merges, redirections, etc. A talk page consensus will continue to suffice. However, it will be encouraged for editors to bring up articles for discussion at AFD, if only to increase the amount of participation and scrutiny, as well as remove any doubt as to whether the consensus is approved by the community-at-large.

Hopefully that makes it clearer. Feedback ^☎ 14:40, 11 May 2013 (UTC)

Community consensus has deemed it necessary for people to start a thread at AFD if they wish for an article to be vanished from the main-space.

This is because most editors lack the technical capability to delete/undelete pages. Conversely, anyone can perform/undo a merger or redirection.

A lot of those discussions end in "merge" and "redirection" due to the overlapping nature of all three processes involved

They end that way because those are alternatives to deletion.

(i.e. Merging usually results in the elimination of most of an article's content,

I assume that you mean that most of the prose isn't copied over. I don't know whether that's true (and I'm curious as to that information's source). Either way, the rest of the text isn't deleted. It remains accessible via the revision history.

If it has become the norm for AFDs to end in one of four ways (the fourth being a "keep"), then I believe people should be able to propose any of the four at AFD.

AfD discussions also result in the determination that an article requires cleanup (copyediting, better sourcing, etc.). Should cleanup be proposed at AfD too?

At Articles for discussion, people will be able to nominate a problematic article for discussion while proposing a (1) merge, (2) a redirection, (3) a deletion, (4) or even a keep.

You want people to list articles at AfD to propose that they be kept? Why?

In fact, users should also be allowed to bring up problematic articles for discussion even when they haven't decided what action to take.

As discussed above, users already are permitted to list articles at AfD when they're undecided on whether deletion, merging or redirection is called for.

As part of the creation of Articles for discussion, I feel that "Proposed merges" would be redundant. Whatever purpose it is fulfilling now will be taken up by Articles for discussion.

"Whatever purpose it is fulfilling now". These words are telling, as you truly don't seem to know what purpose it serves.

Are you aware that some uncontroversial mergers are listed there (when editors wish to request assistance with their implementation)?

ATD-R is a confusing rule, as it allows editors to perform redirections first and only discuss it after someone disputes the change.

How is that confusing? It's an ordinary application of the

WP:BOLD

principle, which applies to editing in general.

This rule would have to be abandoned if redirection proposals are officially part of the AFD process. Uncontroversial redirections can continue to be performed outside AFD, just like uncontroversial deletions and uncontroversial merges.

What change are you proposing? Are you under the impression that the current policy encourages users to intentionally perform controversial redirections without advance discussion?

No one is refuting the importance of talk page discussions. Talk pages are part of the foundation of the encyclopedia. Editors can continue to propose modifications on talk pages including merges, redirections, etc.

• "The difference is that instead of having these conversations scattered around Wikipedia, we'd have them all in one place."
• "Frankly, if you think AFD's current backlog is large, imagine all the merge and redirect discussions going on talk pages right now that just aren't being viewed due to the relative unpopularity of said pages. That's the real backlog, and we would be doing a great service by merging them all into AFD."
• "If an editor feels that his edit doesn't require a formal discussion, then by all means, he/she can edit boldly. However, if an editor feels that these decisions require a discussion, then this proposal says they should go to AFD instead of the article's talk page."
• "Merge, Blank-&-Redirect and Deletion discussions should all be done at AFD."
• "I'm only asking for the discussions to all be held at AFD."
• "I want to bring you an example. On April 12, I proposed to merge
  WP:PM
  .)

—

David Levy

15:40, 11 May 2013 (UTC)

I don't understand your point by quoting my past comments on the last one. I was proving a point that AFD garners more participation than talk page merge discussions. That's just a fact. I also believe people should be allowed to have these discussions at AFD instead of the talk pages. I'm also pretty sure most users will take up on that offer. What are you confused about? - It seems to me that you're just trying to filibuster this discussion. Feedback ^☎ 17:22, 11 May 2013 (UTC)

Feedback, I asked above for you to resolve the contradiction in your position regarding

Phil Bridger (talk

) 17:59, 11 May 2013 (UTC)

I don't understand your point by quoting my past comments on the last one.

Over and over, you've clearly and unambiguously described a proposal to shift "all" merger and redirection discussions from articles' talk pages to AfD. Others have reiterated this numerous times over the past three weeks, with zero contradictions by you (including instances in which you replied directly, sometimes confirming this interpretation) until now.

I was proving a point that AFD garners more participation than talk page merge discussions. That's just a fact.

I've explained that this is because they pertain to potential deletions — last-resort administrative actions that most users are unable to reverse.

You proposed a merger, grew impatient after 30 hours, and nominated the article for deletion (without even mentioning the possibility of merging). Then, because of its faster/larger turnout, you cited the resultant discussion (in which no one supported your deletion request and the question of whether to merge remained unresolved) as evidence that AfD is a better forum in which to discuss mergers.

Your proposal is based upon the incorrect premise that AfD debates receive a great deal of participation because of where they occur, enabling us to drop in non-urgent discussions and generate the same response simply because an "AfD" label appears.

I also believe people should be allowed to have these discussions at AFD instead of the talk pages.

Again, a user undecided on whether deletion or merging/redirection is called for already is permitted to list the article at AfD.

It seems to me that you're just trying to filibuster this discussion.

Please stop hurling accusations of bad-faith conduct. As strongly as I disagree with you, at no point have I questioned your motives.

I await your responses to my other questions and comments. —

David Levy

18:33, 11 May 2013 (UTC)

• I don't understand, let alone agree with, the premise that merging three backlogged processes will help any of them. Warden, Phil Bridger, and others have expressed very well the serious problems with this idea.
  talk
  ) 20:40, 14 May 2013 (UTC)

• Absolutely support. In all my time at AfD, a significant portion of discussions have had outcomes other than deletion/no deletion, be it transwiki, redirect, rename, merge, incubate, etc.; AfDiscussion seems a much better way to handle it. As for concerns about a backlog -- there wouldn't be more discussions than the current sum of the merged areas, they would simply be channeled through a single already popular medium to ensure optimal participation. :) ·
  ✉
  00:32, 18 May 2013 (UTC)

• Conditional Support - User should still be able to BOLDly merge and redirect articles where they believe it is reasonably uncontroversial. There is no need to triplicate bureaucracy for 3 variations of the same thing, it would also be easier no for a non-expected outcome to occur. An article which the nom would prefer deleted could be merged with another article for example if enough people wanted it. This isnt necessarily a bad thing. - Nbound (talk) 15:51, 21 May 2013 (UTC)

I want to create or help to create like a Teahouse but in the Spanish Wikipedia. It sure will help.??? Thoughts??

Contact

user:SarahStierch who was very involved in the creation of the Teahouse. I don't think she knows all the technical details, but I bet she knows who does, and she should be able to give you excellent advice on how to proceed.--SPhilbrick(Talk)

01:33, 18 May 2013 (UTC)

I'm most certainly volunteering to help out and I am starting a plan in my sandbox. It may take some time so I may be beaten to it by Sarah! Chihin.chong (tea and biscuits) 20:05, 21 May 2013 (UTC)

Convenience Over Discussion through Chat Box

Although I am new to Wikipedia editing,my suggestion is that, all us Wikipedians can actually discuss issues and improvements via a direct automated chat box similarly like the Facebook or Twitter where everyone could have direct messages conversed throughout every webpage(s) related to Wikipedia- similar that to a chat room.

Talk Page

Improvements on Talk pages are necessary. The concept of Facebook or Twitter chat boxes to channel message can actually be upgraded through the talk page(s) of Wikipedia, where talk page is sometimes more complex and somehow, misleading. Chat box is more often a trend for today's computer generation system as it provide a speedier conversation process to all Wikipedians in order to have a smooth analysis, discussion, and most importantly time saving factor- whereby all these features could be considered as cost free and a more convenient element for a chat box system.

Security and Legal (only to those who joined in as Wikipedia members)/(Account holders)

Privacy and personal security are always the priority for every online users as I basically think that Wikipedia could be a safer social network that could protect accounts and secure private and confidential data of user's account from other online spywares or cyber threats. Generally, chat box is often a suitable method to communicate with each other as we could assume that the only people who could edit another person's Wikipedia web page contents must be encouraged to create an account and add on any other article's owner(s) into a group list, in which this is a system being widely applicable by websites like Yahoo, MSN, and G-mail. This design can actually help to protect all users' Wikipedia articles from unwanted online vandalism such as: plagiarism, or any other copyrighting violations, as well as editing with false information and issues that might cause sensitivity mainly described as (racism, unnecessary criticism, profanity and so on.) Although based on Human Rights Act 1998, officially, each and every individuals are given a right to criticize and participate into opinion based discussions, but according to the law some countries have tight statutory legislation. Censorship is required to avoid any legal issues and misrepresentation. Anyway, back to the chat box proposal, I think it's a good idea to come up with something fresh and new that will contribute to the Wikipedia with even greater convenience.

This proposal accepts any kind of discussion(s), if there are better ideas, please feel free to contribute by dropping by and suggest useful ideas. No offensive words or argument(s) are allowed. Only opinion based and pure discussions are needed. AAZIO (talk) 08:14, 18 May 2013 (UTC)

• Why? In my opinion, what we currently have perfectly fits Wikipedias needs. What would that discussion system achieve that we cannot currently achieve with our talk pages? Granted, the current system might be confusing for many new users. But I see too many potential problems with such a system (stalking, harassing .... ) which in my opinion would outweigh the benefits. -- Toshio Yamaguchi 12:45, 18 May 2013 (UTC)

• A further comment You say:"the only people who could edit another person's Wikipedia web page contents must be encouraged to create an account and add on any other article's owner(s) into a group list"

That isn't going to happen per the 2nd point of the Wikimedia Founding principles. -- Toshio Yamaguchi 12:51, 18 May 2013 (UTC)

• The point of Wikipedia talk is to advance the encyclopedia (improving the articles, better organization, attractive presentation) and all of that discussion needs to be accessible to all who participate and records of it kept so we know when and why and by whom. Our current talk pages do that although not always easily. Chat does not seem to me to fill these needs. We don't have a need for real-time chat - questions might not be answered for days or months - there is no time limit. Also there is a new talk page system being developed called ... Rmhermen (talk) 17:07, 18 May 2013 (UTC)
  • I confirmed that protection can be added without a reason - which rather surprised me. Beside my test edit I only noticed one of the last 500 protection log changes without a reason. Still I would support a change requiring a reason to be present (We already have for a version of this for article edits). Rmhermen (talk) 17:45, 18 May 2013 (UTC)

• To:Toshio Yamaguchi"Well, I can see that there are some good feedback based on this proposal. As per your opinion,I kinda agree with you about the potential problems with the so called "chat system" that I've proposed (stalking, harassing....) in which it might eventually be cyber threats. That is why I have proposed some security measures based on the edits. As per Rmhermen, he pointed out that he supported security system to be developed or should I interpret: "improved" adequately with reason to be present. So in my opinion, it may not "outweigh the benefits" as you've mentioned, reason: because everything is worth to be given a try, especially for security and protection. I agree with the registration (as according toWikimedia Founding principles 2nd point) and chat box proposed by me sound kinda absurd though, but since you said although "the current system might be confusing for many new users", I hope to hear from you that, are there any other improvements that could be proposed to avoid such case? If Wikipedia could construct a rather easier method for new users, wouldn't it be great to have so many people to express their talents through editing articles based on Wiki system? Let's put the talents aside first, editing is kinda useful for most users to share what they know to the rest of the world, so I hope you can send in more feedback to improve such system so that in the future it will reduce the complexity of edits with Wiki. Anyway, thank you very much for your utmost kind advice, because I'm actually new to Wikipedia myself (just joined in since 13 May 2013). Hope to hear from you. Let's make Wikipedia a better place for learning. AAZIO (talk) 03:55, 19 May 2013 (UTC)
  • As WhatamIdoing points out below, Flow is already being worked on, which tries to address the issue with the current system being confusing for new editors. However that doesn't really seem to be like a live chat (at least not at this point). -- Toshio Yamaguchi 22:49, 21 May 2013 (UTC)
• Major changes to talk/discussion approach are already being planned. WP:Flow will first replace user talk pages, and later (possibly much later) spread to other discussion pages. This is a massive, major, complex change. The devs have done a lot of study on how different types of users interact with the existing talk pages (which are basically a kludge created because a proper system couldn't be created at the time), but they're just getting started. It's going to require a lot of time, energy, and patience while they get the new system sorted out. WhatamIdoing (talk) 18:52, 19 May 2013 (UTC)

1. WP:ATD-R results in the deletion of an article. Although the history still exists and the article's title is still being used as a redirect, the entirety of its content has been removed. A lot of these bold edits end up having to be discussed, because frankly, it's a drastic move. For example, that's why I proposed the deletion of Wikipedia:Articles for deletion/Tons of Funk
   at AFD, even though after its deletion, it was redirected to another article. Had I done this boldly, the people who voted keep in that AFD would have forced the discussion to happen at the talk page anyway. Thus, my official stance is that all ATD-R does is delay the inevitable discussion from happening.
2. The people who participate at talk page discussions are the ones who either (1) watch the article in question, (2) watch
   WP:AFD
   is extremely popular. Users who don't usually edit comic book articles might end up participating in comic book AFDs due to its appearance at AFD's main page. A lot of these merge and redirect discussions just go overlooked, but if these processes were merged into AFD, we would be encouraging the most participation possible. I've participated in many deletion discussions about articles that I would never have crossed by had it not been for AFD. A lot of these discussions ended in "Redirect" and "Merge".
3. When coming across a problematic redirect, our first question is to wonder what we should do with it. Should it be deleted? Renamed? Turned into its own article? Sometimes it just isn't as clear-cut as we would like it to be. Thankfully, that's why we have WP:Redirects for discussion where anyone can propose to discuss a problematic redirect without choosing a "keep, delete, rename" allegiance beforehand. However, our current policies force us to choose a side before opening a discussion when it comes to articles. If you think it should be deleted, go to AFD! If you think it should be merged, use this specific tag! If you want it redirected, just do it, wait for someone to revert and then talk about it on the talk page! But if you want to value the community's input before making a decision, your only hope is to open a section at the talk page and hope that enough people respond. And once that section reaches a consensus, you'll most likely end up doing one of those Deletion or Merge processes afterwards. Frankly, this is just counter-productive. It would be best if we could just open an AFD page where anyone can voice their concerns without outright crying Delete!

Making AfD more like RfD would be a good thing. And that's why I think all these processes should be merged and renamed "Articles for discussion". I know this isn't the first time someone has proposed this, but I think it's time we reopen the conversation. Feedback ^☎ 23:16, 12 April 2013 (UTC)

Have you read the FAQ?

I don't like this page's name. I want to rename it to Articles for discussion or something else.

Please see Wikipedia:Perennial proposals#Rename_AFD. Note that all of the "for discussion" pages handle not only deletion, but also proposed mergers, proposed moves, and other similar processes. AFD is "for deletion" because the volume of discussion has made it necessary to sub-divide the work by the type of change.

How exactly does your proposal solve the problem (high volume) that necessitated the subdivision in the first place? WhatamIdoing (talk) 01:01, 13 April 2013 (UTC)

I know it's been discussed before. I've read at least 3 different threads where the idea has been proposed. But like I said, I think its time we reopen the conversation. It's just counter-productive for us to keep these tasks separate, and I'm hoping we can form a consensus to overhaul it. Feedback ^☎ 01:47, 13 April 2013 (UTC)

I don't see how the proposal to merge the discussions will result in a higher backlog. It will be the same exact "volume" that we have right now. The difference is that instead of having these conversations scattered around Wikipedia, we'd have them all in one place. Frankly, if you think AFD's current backlog is large, imagine all the merge and redirect discussions going on talk pages right now that just aren't being viewed due to the relative unpopularity of said pages. That's the real backlog, and we would be doing a great service by merging them all into AFD. Plus, the less time people use discussing on talk pages means that even more users will participate at AFD. There are only positives here. I don't see the negatives. Feedback ^☎ 01:47, 13 April 2013 (UTC)

I dispute the statement that

That distinction, although important, is irrelevant to the common reader. Whoever read

Corwood Industries yesterday and decides to look it up again today would be dumbfounded when they find that it redirects to Jandek. To the reader, the page is gone. If they want to know why it's gone, they could see that the discussion took place at Wikipedia:Articles for deletion/Corwood Industries and a consensus was achieved to redirect the page. This isn't an extra layer of bureaucracy. This is the proper way to handle the removal of content from the encyclopedia. Sure, someone could still access the page history, but for all intensive purposes, the article that used to be there has been removed from the encyclopedia. That's how it would seem to the common reader and that's who we should have in mind when forming these policies. Feedback ^☎

04:34, 14 April 2013 (UTC)

• As per
  WP:Administrators' noticeboard/Requests for closure#Wikipedia namespace in the section, Wikipedia:Village pump (proposals)#Wikipedia "Merge" like WP:RM or WP:AFD, there is a related recent discussion that is awaiting closure.  Unscintillating (talk
  ) 16:07, 14 April 2013 (UTC)
  • Archived to WP:Village pump (proposals)/Archive 98#Wikipedia "Merge" like WP:RM or WP:AFD. Flatscan (talk) 04:16, 18 April 2013 (UTC)

I want to bring you an example. On April 12, I proposed to merge

Two questions:

1. Why didn't you just boldly merge the pages in the first place?
2. Why do you think that a routine merge proposal ought to get a response in less than three days? WhatamIdoing (talk) 16:20, 15 April 2013 (UTC)

I won't argue that your suggestion isn't sound, but from experience, it just isn't practical. People would revert it and decide to discuss it. Case in point, someone took a non-notable

Talk:The Funkadactyls and the discussion then ended up going to AFD anyway. This is what we're dealing with on Wikipedia. And this is just an example of the many problems this proposal would fix. Feedback ^☎

20:37, 15 April 2013 (UTC)

That's not been my experience, but perhaps I've done more of it than you.

Also, if you wanted outside feedback, rather than comments from the people already at those articles, why didn't you follow the directions at

Wikipedia:Proposed mergers#Requests for assistance and feedback? WhatamIdoing (talk

) 04:53, 16 April 2013 (UTC)

I already linked you to an example where making such a decision boldly forced everyone to jump through hoops to get something done. This happens and it happens a lot. Whether it's happened "in your experience" is irrelevant. And as for PM/Requests, I could have also gone to RFC, or FSR. But there are just more hoops! You are suggesting that I go through the trouble of asking people to participate when AFD automatically gets enough followers to begin with. The aformentioned merge discussion continues to have 0 replies while the AFD has 4. It's evident that the practical thing to do is to have these discussions at AFD instead. Feedback ^☎ 15:45, 16 April 2013 (UTC)

I'm asking you to go through the same number of hoops. Remember that step when you listed the AFD at the AFD page? I'm asking you instead to list the proposed merge at the proposed merge page instead. AFD doesn't "automatically get enough followers" for people to notice an unlisted AFD, just like proposed merges don't automatically get enough followers for people to notice an unlisted PM. WhatamIdoing (talk) 21:00, 16 April 2013 (UTC)

• Strong support: It is often difficult to get reasonable discussion from neutral observers for any of these discussions. Ryan Vesey 16:27, 15 April 2013 (UTC)

• Long overdue. This is just bureaucracy getting in the way. I've seen perfectly good AfD discussions closed simply because the nominator is not proposing deletion. Any discussion that decides whether an article will cease to exist independently should occur at a central location. Though a remark: If an article would be a suitable candidate for
  WP:PROD but the nominator wishes to merge and/or redirect it, then they can just do so BOLDly, and if they get reverted, take it to AfD. This mimics the usual PROD process. -- King of ♥ ♦ ♣
  ♠ 10:16, 17 April 2013 (UTC)
• Support - That happened to me atleast twice. I concur with King of Hearts and wholeheartedly Support centralisation.
  talk
  ) 10:20, 17 April 2013 (UTC)
• At some point in time the general mindset has developed that AfD is only for deletion, and no decision other than delete/keep/no consensus can be made, going so far that even when there is a clear consensus for merge or redirect (as acknowledged by the closing admin), the article will still be kept because it's an AfD. That is unfathomably stupid on so many levels. This proposal would eliminate that stupidity, so strong support. --Conti|✉ 10:44, 18 April 2013 (UTC)
• Support centralization per King of Hearts' rationale. He sums up my opinion perfectly. Imzadi 1979 → 10:48, 18 April 2013 (UTC)
• Support people treat AFD like this already, including myself, since the proposed merge process is largely ineffective. --Rschen7754 10:57, 18 April 2013 (UTC)
• Strong support. Ironholds (talk) 12:37, 18 April 2013 (UTC)
• Comment: I have no strong objections to the general idea, but I think the specific title "Articles for discussion" is potentially vague / confusing for less-experienced users; it might mislead some into thinking that all significant changes to articles need to be discussed there rather than being
  boldly applied. --SoledadKabocha (talk
  ) 19:58, 18 April 2013 (UTC)
• Support. I agree with a number of points here. The merger process has been, in my experience, ineffective at generating discussion. There also is some unnecessary bureaucracy at AfD: I've seen AfDs closed for proposing mergers or redirects (although I have admittedly advocated for these closings at times in the past). Additionally, I've seen AfDs with a consensus to merge closed as keep, with the closing admin stating that merges must be discussed on the talk page instead, despite existing consensus. I believe this proposal would address these issues rather well, but I must concur with SoledadKabocha that a better name than 'Articles for discussion' could be chosen. (Thus my grand return to Wikipedia begins…) CtP (t • c) 21:38, 18 April 2013 (UTC)
• Question - Should obvious redirect articles, such as a
  talk
  ) 00:52, 19 April 2013 (UTC)

  As I said in my comment, if an article is uncontroversial enough that it would fall under PROD if deletion were being proposed, then a BOLD redirect is fine. -- King of ♥ ♦ ♣ ♠ 01:08, 19 April 2013 (UTC)

• Oppose. A real problem has been cited, but this is the wrong solution.
  As has been pointed out on numerous occasions, a merger cannot be carried out in the same fashion as a deletion (i.e. by pressing a button). It often requires a significant amount of time, planning, effort and discussion (before and during the process), along with a higher degree of familiarity with the subject than can be expected of participants in an outside process. That's why it makes sense to organize such matters on the articles' talk pages.
  Chris the Paleontologist has "seen AfDs with a consensus to merge closed as keep, with the closing admin stating that merges must be discussed on the talk page instead, despite existing consensus." Such a closure is flat-out wrong. AfD isn't the correct venue in which to propose a merger, but if such a consensus is reached (as an alternative to deletion), it's entirely valid. The correct course of action is to tag the source article with {{
  David Levy
  01:39, 19 April 2013 (UTC)
• Support So many times I have seen discussions on talk pages either lay ignored or argued by the same people involved in the article. AfD is a better venue, especially since some of the outcomes result in the deletion/dissapearance of the article in question. And I support the name change to Articles for Discussion, but I have a feeling that'll be a different discussion for a different day. One step at a time. Angryapathy (talk) 01:41, 19 April 2013 (UTC)

  If a merger proposal is ignored, the merger may simply be carried out. The proposal isn't required in the first place; it's an optional request for input/assistance. That's one of several respects in which merger proposals are fundamentally different from deletion nominations. We needn't shift routine article improvement discussions to a separate venue. —

  David Levy

  01:57, 19 April 2013 (UTC)

  Not really. We have two cases: either it's potentially controversial or it's not. If it is, then even if the merger proposal is ignored, the merger should not be carried out. If not, then yes, just carry it out; no one is suggesting we get rid of the ability to merge without discussion entirely. In deletion we have

  WP:PROD for that. -- King of ♥ ♦ ♣

  ♠ 02:02, 19 April 2013 (UTC)

  One of the purposes of proposing a merger instead of simply performing it is to determine whether it's controversial. If no one objects (and no other evidence of controversy exists), it's okay to simply proceed with the merger. No administrative tools are involved (and no content is made inaccessible), so anyone can undo the merger and revive the discussion. It's simply a form of

  David Levy

  02:31, 19 April 2013 (UTC)

  Before you can start discussing how to merge, you must decide whether to merge. And that is something which AfD can perfectly handle. -- King of ♥ ♦ ♣ ♠ 09:49, 19 April 2013 (UTC)

  As noted above, AfD cannot "perfectly handle" all merger proposals. It depends on the context.
  If an article has been nominated for deletion, it's reasonable to discuss merging as an alternative. If the article's very existence is seriously challenged (and relocating its content elsewhere is viewed as a viable alternative to deleting it outright), "merge" is a reasonable AfD outcome.
  But if deletion isn't requested, there's nothing to be gained (and a great deal to lose) by shifting the discussion to a separate forum. In such a circumstance, a merger proposal is an ordinary article content discussion, with no outside process or administrative intervention required. What often is required is input from persons knowledgeable on the articles, their subjects and their sources, discussing the proposed merger over a period likely to exceed AfD's arbitrary duration. It might be a while before editors respond (depending on how much traffic a talk page receives), in which case such a wait is necessary. Artificially accelerating the discussion by shifting it to AfD and closing it after a week or two is actively counterproductive. It greatly reduces the likelihood of soliciting input from editors whose knowledge enables them to understand how the articles' subjects relate, thereby greatly increasing the likelihood of reaching the wrong decision (which will either be undone or never be carried out). This already is an issue, as evidenced by the numerous talk pages littered with years-old {{

  David Levy

  14:26, 19 April 2013 (UTC)

• Oppose. Merges and Smerges and conversion to redirect are not deletion discussions. Redirects that are put forward as "Redirect or Delete but the article and content must not stay" are in practice already welcome at AfD. Merges and Smerges require a lot more care than is appropriate for a seven day discussion. Generally the motivation comes frmo the article to be merged, but then needs to be negotiated at the target, and then things get complicated beyond the scope of a seven day discussion. A disputed merge would be more appropriately listed as an RfC. However, what we need is more bold editing and less process, contrary to the likely effect of this proposal. From the AfD perspective, AfD is a well functioning polished process but so overloaded it is ripe to bust or collapse. Pushing ill-aligned difficult merge discussions, and a large proportion of straightforward merge discussions into it may break its back. --SmokeyJoe (talk) 02:10, 19 April 2013 (UTC)
• Oppose Deletion is a restricted function and so requires a special process. AFD is that process (along with PROD and CSD) and is already overloaded. Discussions at AFD are usually poorly attended, especially by editors who have some clue about the topic in question. For a fresh example, see
  WP:TLDR. Warden (talk
  ) 10:27, 19 April 2013 (UTC)
• Oppose - merges and redirecting may be done by any registered user, subject to BRD; deletion is a restricted action, subject to strict policy, and possible only by admins. These should not mix. עוד מישהו Od Mishehu 10:52, 19 April 2013 (UTC)
• Oppose per Warden. He says what I would have said had I said it before he said it. --Jayron32 13:40, 19 April 2013 (UTC)
• Strongly support We have way too many venues to discuss things such as this. The arguments that closing an AfD should be as simple as pushing a button make no sense to me. Why should it be like that? So that people who are trying to rack up a high score can play the AfD game with no thought involved? That doesn't seem like a good reason to me. Gigs (talk) 16:12, 19 April 2013 (UTC)

  You've misunderstood. No one is arguing that "closing an AfD should be as simple as pushing a button". The point is that carrying out a decision to delete a page is accomplished in this manner. Consensus is achieved at AfD. Then an admin pushes a button, which deletes the page.
  Conversely, when a discussion results in consensus to perform a merger, we have no such button to make it happen. It requires actual editing, which often follows a great deal of planning and collaboration. Article talk pages exist for the purpose of accommodating such discussion. It's ordinary article revision, which is fundamentally different from deletion. —

  David Levy

  17:20, 19 April 2013 (UTC)

• Oppose. This discussion is a demonstration of how formal procedures lead to voting, rather than constructive discussion with everyone aiming for consensus as is more commonly found on article talk pages. When I first commented above I did so without prefixing my remarks with a bolded recommendation, in the hope that others would do the same, but, as is normal for centralised discussions such as the village pump or AfD, this has degenerated into a vote with different sides taking entrenched positions, so I have to give my bolded "oppose" to ensure that my opinion is taken into account. Let's not subject editorial decisions such as merging to the same adversarial procedures. I could say much more, but SmokeyJoe, Colonel Warden and David Levy have expressed my thoughts better than I could do myself.
  Phil Bridger (talk
  ) 17:37, 19 April 2013 (UTC)
• Support - The net result may be fewer deletions, more merges and redirects when everything is more properly on the table. The overlap justifies consolidation, and allows to (perhaps) discuss more and vote less. Dennis Brown - 2¢ © Join WER 18:48, 19 April 2013 (UTC)

  The option of merging and redirecting already is on the table at AfD. In no way does the current format limit the options to "delete" and "keep as a standalone article".
  An AfD debate can result in a number of different outcomes. This doesn't mean that such solutions should be proposed there. For example, there might consensus that an article shouldn't be deleted, but it requires cleanup. That doesn't mean that cleanup proposals should be made at AfD.
  Merging essentially is a form of cleanup. It isn't comparable to deletion and needn't be routinely discussed in a special forum. —

  David Levy

  19:04, 19 April 2013 (UTC)

  Of course they are, that isn't the point. The point is that often someone might not know the best course of action, but know a stand alone article isn't the right answer. Having to choose from multiple places doesn't insure a better outcome, and may actually prevent the best possible outcome for each situation. At the end of the day, we serve ourselves best by having a system that simplifies the process of discussing a "problem" article, and doesn't require a nominator to determine the best possible outcome in advance. Dennis Brown - 2¢ © Join WER 22:01, 19 April 2013 (UTC)

  If someone believes that deletion should be considered (but isn't certain that it's the best solution), he/she can list the article at AfD (and can even mention merging as a possible alternative). This occurs under the current system; no change is required to enable it.
  If someone specifically wants to merge the article with another (and doesn't believe that deletion should be considered), there's no need to list it at AfD; the best discussion forum is the article's talk page (for reasons that I've explained above). The proposal, if implemented, would remove that option. It wouldn't make things any easier for editors who wish to discuss both deletion and merging, who already can do so at AfD. —

  David Levy

  22:43, 19 April 2013 (UTC)

  No need to

  bludgeon the discussion, I'm aware of the current system and have participated in it extensively for many years. To say this would take away the ability to use the article talk page stretches credibility to the breaking point. Dennis Brown - 2¢ © Join WER

  11:07, 20 April 2013 (UTC)

  I'm discussing the matter in good faith, with no intention of overwhelming others or ignoring their evidence. I disagree with you, but I'm not attacking you or disrespecting your opinion. I'm sincerely attempting to understand your argument and alleviate any possible misunderstanding on my part or yours.
  Given your familiarity with the current system, why do you assert that the proposed change is necessary to enable combined deletion/merger listings at AfD?
  Regarding the use of article talk pages, I'm unsure of what you mean. The idea calls for all merger proposals to occur at AfD. —

  David Levy

  12:00, 20 April 2013 (UTC)

  From my experience, most merges don't happen at

  WP:Proposed merges to begin with, it happens with ordinary discussion on talk pages, a more informal process. This wouldn't prevent that. My argument is based on participating in over 1600 AFDs over the years, and having first hand experience with virtually every possible scenario. Doesn't make me right, but it does mean I'm familiar. Any time an article goes to any of these venues, the underlying problem is "This probably doesn't need to be a stand alone article", so consolidating them will mean a higher likelihood that all options will be considered, not just the default option for that particular venue. I'm shocked Warden doesn't like this, as it will likely mean fewer deleted articles, more merged content, more participation and a broader cross-section of the community reviewing each case. It means simplicity and a system that can be easier to use for the community as well. And the very name "Articles for discussion" can create an atmosphere that is seemingly less hostile that "Articles for DELETION", perhaps resulting in less voting (ie: the useless per nom !votes...) and more actual discussion. Human nature is funny that way. And by all means, express your opinion but please don't "alleviate" anything. While surely unintentional, it makes it sound as if the other person's !vote is based on ignorance or lack of experience. Dennis Brown - 2¢ © Join WER

  16:06, 20 April 2013 (UTC)

  From my experience, most merges don't happen at

  David Levy

  18:08, 20 April 2013 (UTC)

  Note: Via this message,

  David Levy

  12:39, 29 April 2013 (UTC)

• About the volume: we tag about 200 articles per week for merging. Only a small fraction of these actually get listed at PM as being controversial or otherwise wanting input from people outside the regular editors at the page. The OP, for example, started this discussion one hour after proposing a merge. He never listed it at PM, where it would have turned up on several hundred watchlists. He just tagged it, put two sentences on the talk page, and then complained here that nobody commented fast enough to satisfy him.
  
  CAT:AFD has almost 500 AFD debates open at the moment. The daily AFD pages are already very slow to open. And if you add in 200 PMs... well, then you'll get what you expect. And if you're not going to list all of them, then we go back to the original question: why should we list PMs at AFD (opening them up to the possibility of unexpected deletion, because there's no way to prohibit people from !voting to delete what you only wanted to merge) when listing them at PM (whenever people like the OP choose to list them) seems to get the job done just as well? WhatamIdoing (talk
  ) 20:14, 19 April 2013 (UTC)

  Right, most merger discussions don't really require a community discussion, just agreement on the talk page. So we won't be overwhelmed. that very few come to central page for them contributes to having it neglected, and is a reason to bring it into a more visible procedure. DGG ( talk ) 19:47, 21 April 2013 (edit) (undo)

  Right, most merger discussions don't really require a community discussion, just agreement on the talk page.
  This proposal calls for "all the merge and redirect discussions going on talk pages" to instead occur at AfD. —

  David Levy

  19:53, 21 April 2013 (UTC)

• Oppose Been thinking about this since proposed. Fence sitting. D. Levy (above) has it right I think, and I'm off the fence. The Merger discussion needs to take longer than the AfDelete discussion, because it takes that time for knowledgeable editors to make their way to the talk pages of the merge requests. This proposal will overwhelm AfD, and we will unavoidably lose (good content and potentially good) articles because of the discussion-time limitations there. We can use help, by the way, working on the oldest (back-end) articles at Category:Articles to be merged after an Articles for deletion discussion. Thanks. GenQuest ^{"Talk to Me"} 23:58, 19 April 2013 (UTC)
• Oppose - Merger discussions can be longer than deletion discussions need to be, and the sheer volume of deletion discussions means that they need their own place. Lukeno94 (tell Luke off here) 10:08, 20 April 2013 (UTC)
• Oppose per my exact same comment I made several years ago at Wikipedia talk:Articles for discussion/Proposal 1, which remains largely unchanged (with minor edits):

  I don't understand why a blessing from an admin is necessary on anything except a deletion or non-deletion as far as AFDs are concerned. Also, perhaps I'm against this notion of, as opposed to keeping discussions on major editorial actions (such as merging) local and strictly amongst those users who are actively collaborating on an article, having "community exposure" on each and every single major editorial action made on every article on Wikipedia. Article talk pages, not a centralized community venue, are the places to discuss such editorial changes. I think we've gotten so lock-step into just typing in simple !votes for literally everything (like what we're all doing here now) instead of actually having a discussion, which has been at least what I have experienced in the last few merge proposals I have brought up (even though it's been a while, now). I also have to echo some of the concerns that Colonel Warden brought up such as overloading the already-overloaded (IMO) AFD queue.

  Also per Colonel Warden's statements made above today. --MuZemike 17:26, 20 April 2013 (UTC)

• Support Many redirects are mergers are noncontentious, and don't need a discussion; but may are, and they are usually a question of notability. Notability is best judged by discussion, and the discussion is best at a centralized place where all the possibilities can be considered. The idea that redirects and merges are just ordinary editing is long obsolete, if it was ever true. We now accept that an afd close can force a redirect or a merge, and many do. And, it still does happen that a redirect or merge is a disguised deletion--and this will succeed if attention is not paid. The way of getting attention is to list at AfD. Articles for discussion is what it really is, and people increasingly do bring articles there even if they are not sure they should be deleted, in order to get a community devision. It's the best way yto get a good result. . Six years ago, AfDs would be summarily closed as inappropriate if the purpose were other than deletion, which is now rarely argued. It is good to have a discussion sometimes not to bring about what one wants, but to see what is wanted. We passed this once, 4 or 5 years ago, but forgot to implement it. let's do it now. DGG ( talk ) 06:28, 21 April 2013 (UTC)

  The idea that redirects and merges are just ordinary editing is long obsolete, if it was ever true.
  They aren't ordinary editing? What nonstandard tools are involved?
  We now accept that an afd close can force a redirect or a merge, and many do.
  An AfD debate might result in the determination that an article requires cleanup (copyediting, better sourcing, etc.). That doesn't mean that AfD is the correct venue in which to request cleanup.
  Articles for discussion is what it really is, and people increasingly do bring articles there even if they are not sure they should be deleted, in order to get a community devision.
  I'm not 100% clear on what that means, but yes, editors are welcome to list an article at AfD if they're unsure of whether it should be deleted or merged. As you've noted, this already occurs. So why is the proposed change needed? Why should all merger discussions be held at AfD?
  We passed this once, 4 or 5 years ago, but forgot to implement it. let's do it now.
  We passed a proposal to shift all merger and redirection discussions to AfD? Please provide a link. —

  David Levy

  07:33, 21 April 2013 (UTC)

  Wikipedia talk:Articles for discussion/Proposal 1 is likely what you are looking for. We had the consensus, what was lacking was the follow through on implementation. Dennis Brown - 2¢ © Join WER 11:48, 21 April 2013 (UTC)

  That was a proposal for a setup in which "anyone could optionally move a disputed merge to AfD, retitled Articles for Discussion". This is a proposal for "all the merge and redirect discussions going on talk pages" to be replaced by "merging them all into AFD". —

  David Levy

  16:26, 21 April 2013 (UTC)

• Comment: Again, I would like to reiterate that this proposal does not mean AfD will be the place to discuss how to merge an article into another, but merely whether it should be done (depending on its level of individual notability). The ultimate merging process will be discussed on the talk page, as always. -- King of ♥ ♦ ♣ ♠ 08:30, 21 April 2013 (UTC)

  ...which is exactly what's done now when an AfD debate results in a decision to merge. As discussed above, we needn't shift all merger proposals there to enable this to occur. The current system facilitates it.
  Most merger suggestions, many of which have nothing to do with the subject's "level of individual notability" (instead focusing on simple matters of length and organization), are best suited to the relevant articles' talk pages. Routine editing discussions don't belong in outside forums. Article talk pages exist to accommodate them. —

  David Levy

  16:26, 21 April 2013 (UTC)

• Support, standardization and uniformity and centralization would be a good thing. — Cirt (talk) 18:17, 21 April 2013 (UTC)
• Support. The current system is confusing for new users. It can take a good while for users to get their heads around our different notability criteria and precedents at AfD, and it is easy for them to choose the wrong venue. Putting all these discussions in one place with one procedure would make things simpler, and the less steep our learning curve is the better chance we have of retaining editors.

  If doing this makes the daily logs too slow to load we should fix this by technical means - there's no need to throw out a promising proposal because it doesn't match the exact page structure we have at the moment. For example, we could link all the discussions in the daily logs instead of transcluding them, and in addition create daily logs sorted by the subcategories in

  WP:DELSORT with the current AfD structure. — Mr. Stradivarius ^{♪ talk ♪}
  15:32, 22 April 2013 (UTC)

  It can take a good while for users to get their heads around our different notability criteria and precedents at AfD,
  And the solution is to send more discussions there (including many that have nothing to do with notability)?
  and it is easy for them to choose the wrong venue.
  Under the proposed change, users attempting to discuss ordinary editing (reorganizing content by transferring it from one page to another) on the relevant articles' talk pages would be informed that they've "chosen the wrong venue" and forced to file a special listing at an outside forum, where editors who've never seen the articles before will reach a binding decision by an arbitrary deadline. This is supposed to make things easier and less intimidating?
  Putting all these discussions in one place with one procedure would make things simpler, and the less steep our learning curve is the better chance we have of retaining editors.
  Why stop with these discussions? Why not eliminate article talk pages entirely and move all content discussions to AfD? "Want to discuss expanding an article, rewording a section, or updating some of the sources? Take it to AfD. We're making things simpler by putting everything in one place with one procedure." —

  David Levy

  17:27, 22 April 2013 (UTC)

• Support, since many AfD discussions result in mergers and/or redirects anyway as it is; AfD is, de facto, "Articles for Discussion". Miniapolis 21:41, 26 April 2013 (UTC)

  AfD discussions result in all sorts of outcomes other than deletion. It might be determined that an article requires cleanup (copyediting, better sourcing, etc.). Should we transfer all cleanup requests to AfD? —

  David Levy

  00:26, 27 April 2013 (UTC)

• Support This is pretty much happening already, and a lot of mergers and redirects touch on notability and other topics at which regular AFDers are expert. This would also, hopefully, reduce the distressing number of "hanging" merger and redirect proposals. Ray^Talk 23:36, 26 April 2013 (UTC)

  This is pretty much happening already,
  Merger discussions are being barred from talk pages and preemptively sent to AfD?
  and a lot of mergers and redirects touch on notability and other topics at which regular AFDers are expert.
  A lot don't. Many merger discussions relate strictly to considerations of article length and organization (and have nothing to do with notability or anything similar). Routine article content discussions don't belong in a special forum. The articles' talk pages exist specifically to accommodate them.
  This would also, hopefully, reduce the distressing number of "hanging" merger and redirect proposals.
  ...by enforcing an arbitrary deadline instead of waiting for someone knowledgeable on the articles' subjects and their relationship to participate. Then we'll have a huge backlog of merger decisions instead of merger proposals (because, as discussed above, we have no "merge" button to press). Numerous talk pages already are littered with years-old {{

  David Levy

  00:26, 27 April 2013 (UTC)

• Support for borderline cases. Merge and redirect have long been possible outcomes at AfD, and I have for many years observed that the backlog at those other pages make it very unlikely for a decision, discussion, or any outcome whatsoever to occur at the other venues in a timely fashion. However, I believe these venues should be retained for complex or highly controversial merge and/or redirect proposals. AfD is perfect for borderline cases: pages that could stand to be deleted, but a merge or redir accomplishes the same outcome. Pages like these are simple to review, and the merge tends to be a copy-paste of a paragraph into the destination article. However, the community at AfD would be incapable on the whole of evaluating a complex merge or split proposal. —/Mendaliv/^2¢/_Δ's/ 21:54, 28 April 2013 (UTC)

  As discussed above, in borderline cases (in which someone is unsure of whether an article should be deleted or merged), the current system permits an AfD listing (in which both options, along with other possible solutions, are considered). No change is needed to enable this; it's how things work now.
  The proposal calls for "all the merge and redirect discussions going on talk pages" to instead occur at AfD, which you obviously don't support. —

  David Levy

  22:31, 28 April 2013 (UTC)

  When I said borderline above, I should have said "notability-based". That is, I support the rolling of pure merge or pure redirect proposals into AfD where such proposals' rationales are based on relatively bright-line notability (as well as

  undue weight issues? I think AfD at present requires very different skills, and to force the entirety of proposed merges onto AfD would either disrupt the culture this proposal hopes to harness, or result in a large number of ignored merge/redirect requests just as under the present system. —/Mendaliv/^2¢/_Δ's

  / 23:06, 28 April 2013 (UTC)

  Thanks for clarifying. Depending on its implementation, I might support a proposal to shift disputed mergers based on notability concerns and

  David Levy

  23:37, 28 April 2013 (UTC)

  This proposal does not take away the ability of an editor to boldly merge two articles, or boldly use ATD-R. If an editor feels that his edit doesn't require a formal discussion, then by all means, he/she can edit boldly. However, if an editor feels that these decisions require a discussion, then this proposal says they should go to AFD instead of the article's talk page. At AFD, they will get more participation and a much clearer community consensus. Feedback ^☎ 11:59, 29 April 2013 (UTC)

  Yes, I understand your proposal. I've explained why most merger discussions belong on articles' talk pages and why shifting all of them to AfD wouldn't result in "more participation and a much clearer community consensus". —

  David Levy

  12:18, 29 April 2013 (UTC)

  This can be handled by a slight tweak, instead of "that require a discussion". make it "that are disputed". DGG ( talk ) 02:49, 2 May 2013 (UTC)

  "Proposed mergers lacking consensus (for or against)" might be a better description. (Otherwise, a single editor could block a strongly supported merger and send the matter to AfD by opposing it without explanation.)
  In a no-consensus situation, I still see no need to transfer the actual discussion to AfD (especially if it's already active on the article's talk page). A possible alternative is a notification system, similar to RfC, though which messages are posted at AfD to invite its editors to participate. —

  David Levy

  03:45, 2 May 2013 (UTC)

  You keep replying to everybody with basically the same points. Take a chill pill and try to avoid spamming the discussion. All of your 22 above posts are available to everyone who participates in the discussion, you don't need to repeat them under every single vote. Feedback ^☎ 01:34, 4 May 2013 (UTC)

  Good-faith discussion ≠ "spamming". Some of my comments are repetitious because I'm attempting to interact with editors casting votes without addressing relevant concerns previously expressed. Some of the supporters misunderstand what you've proposed (in part, most likely, because the section heading refers to "WP:Proposed mergers" instead of all merger discussions), and they evidently aren't reading the previous messages in which the discrepancy was explained.
  It's odd that you wrote the above complaint in response to a message in which I expressed partial agreement with a supporter and suggested a possible implementation not previously mentioned. —

  David Levy

  21:33, 4 May 2013 (UTC)

  I see why it can cause confusion, but think the title is still adequate. I'm asking to merge the three processes above. Merge, Blank-&-Redirect and Deletion discussions should all be done at AFD. Feedback ^☎ 02:19, 5 May 2013 (UTC)

  I'm not blaming you for the misunderstanding. (Having read your comments, I found your proposal clear.) I'm explaining why my replies have been partially repetitive: some editors seem to be skipping past earlier messages, including those in which you explained that the idea is to relocate all merger discussions (not merely those listed at

  David Levy

  03:59, 5 May 2013 (UTC)

  Given the number of people whose comments basically amount to "I didn't read Feedback's clearly explained proposal", I'm adding a nutshell in this edit that summarizes the key points that people keep missing. Perhaps it will result in comments that have something to do with this proposal, rather than with some imaginary proposal. WhatamIdoing (talk) 04:21, 6 May 2013 (UTC)

  Apparently not. —

  David Levy

  16:54, 9 May 2013 (UTC)

• Support: merge discussions in talkspace are woefully underdiscussed;
  Talk:Men and feminism#Split and merge was proposed last March and didn't get any input until this February, and as of May, still no action has been taken. At the same time, with AfDs often getting relisted, I suppose that a standard 14-day limit with an early close option of seven days may be a good idea to ensure enough input for both merge and deletion discussions. Sceptre ^(talk
  ) 04:44, 5 May 2013 (UTC)

  How, in your view, would such a change be beneficial?
  Let's assume, for the sake of discussion, that an AfD listing would generate more input (despite the lack of urgency brought about by the threat of deletion). And let's assume that the decision is to merge. Then what? Who's going to perform the merger?
  As noted above, numerous talk pages contain {{

  David Levy

  05:56, 5 May 2013 (UTC)

• Comment: This proposal is based upon the premise that AfD debates receive a great deal of participation not because of their subject, but because they occur at AfD. This simply isn't true. They attract attention because they're about potential deletions — last-resort administrative actions that most users cannot undo.
  It doesn't make sense to think that we can take other topics (with far less urgency and no administrative intervention needed), slap an "AfD" label on them and magically duplicate the amount of feedback received via the current format. We'll simply end up diluting (and overburdening) the entire process, while simultaneously shifting the discussion away from the eyes of the editors most capable of addressing the relevant concerns (who might not show up within a week or two, but will be willing and able to provide assistance when they do arrive). —
  David Levy
  06:21, 5 May 2013 (UTC)
• Oppose. Merges and splits are content issues and should be part of the
  WP:WIAFA, etc. (as oppose to the more blank-and-white deletion policies and guidelines), and thus will most likely not be able to post more helpful comments. Thus, this would become a fruitless exercise that adds to an already overburdened AFD process, with closing admins just posting the AFD-merge tag without actually performing the merge, and we are back to square one. IMO, it is more efficient to just go with the BRD cycle and subsequent dispute resolution steps involving merges and any other content related issues, rather than moving each and every such discussion to a central "Articles for discussion". Zzyzx11 (talk
  ) 18:35, 5 May 2013 (UTC)
• Support - It seems to me that many people above object to a perceived effort to bureaucratize the merger and redirection process and make it a function of administrators rather than of non-administrative editors. I'm not afraid of this. This seems to be a streamlining and a rationalization of a process in which there ALREADY are bureaucratic processes for mergers and redirections which is (justifiably) little used, and which will continue to be used only in controversial cases. I like the idea of renaming things FOR DISCUSSION rather than FOR DELETION, since Keep is a frequent and legitimate outcome of that process and I have dealt with more than one newcomer to WP who has been thoroughly put off that their undersourced-but-legitimate contribution to the encyclopedia had been prejudged to be unworthy by unseen forces and was slated for doom. "For Discussion" is less menacing to newcomers. It makes sense to me to have as few deletion/discussion boards as possible so that participation is broader and roosts are not ruled by a small handful of agenda-driven editors as well. So this is a win/win/win/win from my perspective: it makes things more rational, less bureaucratic, less menacing, more participatory. Carrite (talk) 15:59, 9 May 2013 (UTC) Last edit: Carrite (talk) 16:02, 9 May 2013 (UTC)

  This seems to be a streamlining and a rationalization of a process in which there ALREADY are bureaucratic processes for mergers and redirections which is (justifiably) little used, and which will continue to be used only in controversial cases.
  As discussed at length above, this is not merely a proposal to merge the outside processes, and it would not affect only "controversial cases". The idea is to shift all merger and redirection discussions (including those currently held without any sort of external listing) to AfD on a mandatory basis. The use of articles' talk pages for this purpose would be disallowed. —

  David Levy

  16:54, 9 May 2013 (UTC)

  The proposal isn't limited to actions that are currently discussed on article talk pages, but would also explicitly disallow bold redirection, requiring any redirection to be discussed even when that action is obviously correct, such as in the case of duplicate articles. That's a vast increase in in bureaucracy. There may be a case for mergers and redirections to be listed at at a consolidated "articles for discussion" if they are contested and discussion at article talk pages doesn't result in consensus, but that's a very different proposal from this one.

  Phil Bridger (talk

  ) 18:39, 9 May 2013 (UTC)

  That's an outright lie. Like I said above: "This proposal does not take away the ability of an editor to boldly merge two articles, or boldly use ATD-R. If an editor feels that his edit doesn't require a formal discussion, then by all means, he/she can edit boldly. However, if an editor feels that these decisions require a discussion, then this proposal says they should go to AFD instead of the article's talk page.". I'm not campaigning to rid Wikipedia of bold editing. I'm only asking for the discussions to all be held at AFD. That's why I only want"WP:Proposed Merges" to be merged into AFD, not the whole merge process. Feedback ^☎ 18:47, 9 May 2013 (UTC)

  Feedback, you misunderstand the process, and IMO that's where the biggest problem in this discussion is coming from. Here are the facts:

  • 98% of the mergers requiring discussion are handled on article talk pages.
  • Only 2% of the mergers requiring discussion are handled at PM.

  When you combine "mergers requiring a normal discussion at the article talk page" (98%) with "mergers requiring an extraordinary discussion elsewhere" (2%), you get "all mergers requiring a discussion" (100%).

  Do you understand that "two percent of mergers requiring a discussion" is noticeably less than "all mergers requiring a discussion"? You say on the one hand that you want ""all mergers requiring a discussion" to be handled at AFD—that'd be 100%—and then you turn around and say you "only want 2% (i.e., the tiny fraction of mergers requiring discussion that require more than normal discussion and thus get listed at PM) to be merged to AFD".

  So make up your mind: do you want 2% of mergers requiring a discussion to be handled at AFD, or do you want 100% of mergers requiring a discussion to be handled at AFD? WhatamIdoing (talk) 19:40, 9 May 2013 (UTC)

  Feedback, how is it an outright lie that your proposal said "Thus, my official stance is that all ATD-R does is delay the inevitable discussion from happening.", and the very title of this discussion calls for the merging of

  Phil Bridger (talk

  ) 19:51, 9 May 2013 (UTC)

  Yes, I think ATD-R should be done away with. That's because ATD-R says that you should act boldly first and only discuss it if the change is disputed. It's an impractical guideline, and it's the only one that tackles the process of replacing articles with redirects. That's why I believe it should be merged into AFD. In this new AFD, uncontroversial merges and redirects will still be able to be performed boldly. It's up to editorial judgment whether to propose it at AFD or not. All of this has been made very clear above. Feedback ^☎ 21:00, 9 May 2013 (UTC)

  That comment is self-contradictory. You say that you want to do away with the policy that says "any user can boldly redirect to another article", but then say that redirects will still be able to be performed boldly. Can they or can't they?

  Phil Bridger (talk

  ) 21:18, 9 May 2013 (UTC)

  I want to eliminate the policy that says redirections should be carried out boldly and only discussed if they are disputed after the fact. I believe that to the average reader, replacing articles with redirections is the same as deleting. They won't know the bureaucratic differences when they find out that

  Corwood Industries no longer is an article, but instead redirects to Jandek. All they will know is that an article that used to be in the mainspace is no longer there. Therefore, I believe we should discuss potentially controversial redirections at AFD before carrying them out. Feedback ^☎

  21:27, 9 May 2013 (UTC)

  The current policy says "can", not "should".

  Phil Bridger (talk

  ) 21:39, 9 May 2013 (UTC)

  Phil Bridger (talk

  ) 21:51, 9 May 2013 (UTC)

  That's an outright lie.
  Please

  David Levy

  20:24, 9 May 2013 (UTC)

  Whether he lied or spoke a mistruth out of confusion is not really important. Let's not try to sway the discussion. I apologize if anyone interpreted any bad faith from my comments. Feedback ^☎ 21:00, 9 May 2013 (UTC)

  I neither lied nor spoke a mistruth out of confusion. Your proposal, and your most recent comments, are perfectly clear in saying that you want to remove the policy that says that articles can be boldly redirected.

  Phil Bridger (talk

  ) 21:20, 9 May 2013 (UTC)

  Whether he lied or spoke a mistruth out of confusion is not really important.
  The distinction between dishonesty and misunderstanding is quite important. You unambiguously alleged the former.
  Let's not try to sway the discussion.
  Depicting one's opponent as a liar certainly could be perceived as an attempt to

  David Levy

  21:46, 9 May 2013 (UTC)

Feedback, you've just removed this summary:

This page in a nutshell: This is a proposal to list all (200+ each week) proposed merges at AFD (in addition to 500+ AFDs each week). This includes: Pages that would be blanked and redirected without needing any administrator intervention Proposed merges that are not expected to be contentious (98%) Proposed merges that are expected to be contentious and therefore are currently listed at WP:PM (2%)

with the claim that it isn't true. Can you explain what, exactly, isn't true? Can you revise it to make it accurately reflect your proposal? Can you, again, tell me why you keep talking about "all mergers requiring discussion" being held at AFD, and then telling people that you don't mean "all" when you say "all"? WhatamIdoing (talk) 22:27, 9 May 2013 (UTC)

It could be that I am confused as to what you mean by "contentious". My proposal is very simple and some of you are blowing it out of proportion. I just want proposed merges and AFD to be merged into "Articles for Discussion", while also expanding its scope to also include potentially controversial redirections. Uncontroversial/bold merging which aren't proposed at WP:PM will still continue in the same capacity. I've said it before and I'll say it again, I want to merge AFD with PM, not the entire merge process. Feedback ^☎ 13:41, 10 May 2013 (UTC)

You've repeatedly stated that your proposal applies to all merger discussions currently appearing on articles' talk pages. Do you not understand that most aren't listed at

WP:PM

? You initiated such a discussion less than an hour before authoring this proposal. You even cited it as an example. 12:50, 11 May 2013 (UTC)

I don't know if I'm just being terribly unclear, but you keep misunderstanding the proposal. I will try and make it clear:

1. Community consensus has deemed it necessary for people to start a thread at AFD if they wish for an article to be vanished from the main-space. A lot of those discussions end in "merge" and "redirection" due to the overlapping nature of all three processes involved (i.e. Merging usually results in the elimination of most of an article's content, while redirection usually ends up in the "blanking" of an entire article). If it has become the norm for AFDs to end in one of four ways (the fourth being a "keep"), then I believe people should be able to propose any of the four at AFD.
2. At Articles for discussion, people will be able to nominate a problematic article for discussion while proposing a (1) merge, (2) a redirection, (3) a deletion, (4) or even a keep. In fact, users should also be allowed to bring up problematic articles for discussion even when they haven't decided what action to take. They can nominate it at AFD just to spark a discussion without the requirement of crying "delete" or "merge" beforehand.
3. As part of the creation of Articles for discussion, I feel that "Proposed merges" would be redundant. Whatever purpose it is fulfilling now will be taken up by Articles for discussion.
4. ATD-R is a confusing rule, as it allows editors to perform redirections first and only discuss it after someone disputes the change. This rule would have to be abandoned if redirection proposals are officially part of the AFD process. Uncontroversial redirections can continue to be performed outside AFD, just like uncontroversial deletions and uncontroversial merges.
5. No one is refuting the importance of talk page discussions. Talk pages are part of the foundation of the encyclopedia. Editors can continue to propose modifications on talk pages including merges, redirections, etc. A talk page consensus will continue to suffice. However, it will be encouraged for editors to bring up articles for discussion at AFD, if only to increase the amount of participation and scrutiny, as well as remove any doubt as to whether the consensus is approved by the community-at-large.

Hopefully that makes it clearer. Feedback ^☎ 14:40, 11 May 2013 (UTC)

Community consensus has deemed it necessary for people to start a thread at AFD if they wish for an article to be vanished from the main-space.

This is because most editors lack the technical capability to delete/undelete pages. Conversely, anyone can perform/undo a merger or redirection.

A lot of those discussions end in "merge" and "redirection" due to the overlapping nature of all three processes involved

They end that way because those are alternatives to deletion.

(i.e. Merging usually results in the elimination of most of an article's content,

I assume that you mean that most of the prose isn't copied over. I don't know whether that's true (and I'm curious as to that information's source). Either way, the rest of the text isn't deleted. It remains accessible via the revision history.

If it has become the norm for AFDs to end in one of four ways (the fourth being a "keep"), then I believe people should be able to propose any of the four at AFD.

AfD discussions also result in the determination that an article requires cleanup (copyediting, better sourcing, etc.). Should cleanup be proposed at AfD too?

At Articles for discussion, people will be able to nominate a problematic article for discussion while proposing a (1) merge, (2) a redirection, (3) a deletion, (4) or even a keep.

You want people to list articles at AfD to propose that they be kept? Why?

In fact, users should also be allowed to bring up problematic articles for discussion even when they haven't decided what action to take.

As discussed above, users already are permitted to list articles at AfD when they're undecided on whether deletion, merging or redirection is called for.

As part of the creation of Articles for discussion, I feel that "Proposed merges" would be redundant. Whatever purpose it is fulfilling now will be taken up by Articles for discussion.

"Whatever purpose it is fulfilling now". These words are telling, as you truly don't seem to know what purpose it serves.

Are you aware that some uncontroversial mergers are listed there (when editors wish to request assistance with their implementation)?

ATD-R is a confusing rule, as it allows editors to perform redirections first and only discuss it after someone disputes the change.

How is that confusing? It's an ordinary application of the

WP:BOLD

principle, which applies to editing in general.

This rule would have to be abandoned if redirection proposals are officially part of the AFD process. Uncontroversial redirections can continue to be performed outside AFD, just like uncontroversial deletions and uncontroversial merges.

What change are you proposing? Are you under the impression that the current policy encourages users to intentionally perform controversial redirections without advance discussion?

No one is refuting the importance of talk page discussions. Talk pages are part of the foundation of the encyclopedia. Editors can continue to propose modifications on talk pages including merges, redirections, etc.

• "The difference is that instead of having these conversations scattered around Wikipedia, we'd have them all in one place."
• "Frankly, if you think AFD's current backlog is large, imagine all the merge and redirect discussions going on talk pages right now that just aren't being viewed due to the relative unpopularity of said pages. That's the real backlog, and we would be doing a great service by merging them all into AFD."
• "If an editor feels that his edit doesn't require a formal discussion, then by all means, he/she can edit boldly. However, if an editor feels that these decisions require a discussion, then this proposal says they should go to AFD instead of the article's talk page."
• "Merge, Blank-&-Redirect and Deletion discussions should all be done at AFD."
• "I'm only asking for the discussions to all be held at AFD."
• "I want to bring you an example. On April 12, I proposed to merge
  WP:PM
  .)

—

David Levy

15:40, 11 May 2013 (UTC)

I don't understand your point by quoting my past comments on the last one. I was proving a point that AFD garners more participation than talk page merge discussions. That's just a fact. I also believe people should be allowed to have these discussions at AFD instead of the talk pages. I'm also pretty sure most users will take up on that offer. What are you confused about? - It seems to me that you're just trying to filibuster this discussion. Feedback ^☎ 17:22, 11 May 2013 (UTC)

Feedback, I asked above for you to resolve the contradiction in your position regarding

Phil Bridger (talk

) 17:59, 11 May 2013 (UTC)

I don't understand your point by quoting my past comments on the last one.

Over and over, you've clearly and unambiguously described a proposal to shift "all" merger and redirection discussions from articles' talk pages to AfD. Others have reiterated this numerous times over the past three weeks, with zero contradictions by you (including instances in which you replied directly, sometimes confirming this interpretation) until now.

I was proving a point that AFD garners more participation than talk page merge discussions. That's just a fact.

I've explained that this is because they pertain to potential deletions — last-resort administrative actions that most users are unable to reverse.

You proposed a merger, grew impatient after 30 hours, and nominated the article for deletion (without even mentioning the possibility of merging). Then, because of its faster/larger turnout, you cited the resultant discussion (in which no one supported your deletion request and the question of whether to merge remained unresolved) as evidence that AfD is a better forum in which to discuss mergers.

Your proposal is based upon the incorrect premise that AfD debates receive a great deal of participation because of where they occur, enabling us to drop in non-urgent discussions and generate the same response simply because an "AfD" label appears.

I also believe people should be allowed to have these discussions at AFD instead of the talk pages.

Again, a user undecided on whether deletion or merging/redirection is called for already is permitted to list the article at AfD.

It seems to me that you're just trying to filibuster this discussion.

Please stop hurling accusations of bad-faith conduct. As strongly as I disagree with you, at no point have I questioned your motives.

I await your responses to my other questions and comments. —

David Levy

18:33, 11 May 2013 (UTC)

• I don't understand, let alone agree with, the premise that merging three backlogged processes will help any of them. Warden, Phil Bridger, and others have expressed very well the serious problems with this idea.
  talk
  ) 20:40, 14 May 2013 (UTC)

• Absolutely support. In all my time at AfD, a significant portion of discussions have had outcomes other than deletion/no deletion, be it transwiki, redirect, rename, merge, incubate, etc.; AfDiscussion seems a much better way to handle it. As for concerns about a backlog -- there wouldn't be more discussions than the current sum of the merged areas, they would simply be channeled through a single already popular medium to ensure optimal participation. :) ·
  ✉
  00:32, 18 May 2013 (UTC)

• Conditional Support - User should still be able to BOLDly merge and redirect articles where they believe it is reasonably uncontroversial. There is no need to triplicate bureaucracy for 3 variations of the same thing, it would also be easier no for a non-expected outcome to occur. An article which the nom would prefer deleted could be merged with another article for example if enough people wanted it. This isnt necessarily a bad thing. - Nbound (talk) 15:51, 21 May 2013 (UTC)

I'm overwhelmed by curiosity over Wikipedia's style of edit, but at the same scope, I find that besides plain and simple webpage(s) being brought up and edited in Black and White, can we just think of transforming Wikipedia into a more colourful, lively, and attractive source for learning? My point here constitutes about, if something like a colour tool kit could be manifested into the

Further Idea(s): Kids love colourful views, for example, if Wikipedia could come up with an idea by assembling/recruiting more experts to create colourful mind maps in which children may find these sources interesting and attractive + less complicated words used. (revised) This, in turn can also help younger viewers to understand better, effectively, and efficiently. Although still considering myself new to Wikipedia, This topic can still be improved and discussed through more opinions and suggestions. Feel free to join in for more brain storming session as I believe that ideas are light bulbs that updates the societal changes. Everyone, let's triumph for a better future through ideas and knowledge.AAZIO (talk) 06:31, 19 May 2013 (UTC)

• Opinion(s):
  • I'm not exactly sure what you're asking for. Are you wanting colourful backgrounds? Side bars? The text itself? I hardly think any of that furthers our encyclopedic mission. — Huntster (t @ c) 07:09, 19 May 2013 (UTC)
    • Huntster, Everything mentioned as above by you, and why is that so? things like mind maps can actually be done if further research are carried out. Can you explain why? Anyway, Thank you for the opinion.AAZIO (talk) 07:28, 19 May 2013 (UTC)
  • We already encourage the addition of images to articles, which can be of many kinds such as photographs, maps and diagrams and should make use of colour where appropriate. Your language above about memory capacity is not quite clear, but if you are saying that over 70% of memory capacity is used for colour then that claim is simply bizarre. Which experts' research came up with this figure? It sounds more like the kind of junk statistic that would be presented in a cheap course in design or marketing rather than anything based on psychological research.
    Phil Bridger (talk
    ) 08:14, 19 May 2013 (UTC)
  • @
    Phil Bridger Sorry, you can mark me wrong about the junk statistic, since it is an opinion based discussion, but I need some solutions. All we want is to discuss about improvements and changes, not just comments. True, I agree about my language may be unclear, perhaps I should change it to "brain power" instead. I agree with you that "photographs, maps and diagrams should make use of colour where appropriate", but those are all different from mind maps. If you have better ideas or solutions, then do you mind sharing them out? We are talking about improvements anyway.. AAZIO (talk
    ) 08:43, 19 May 2013 (UTC)
    • Is there (already) consistent use of colour in tables? Or does this vary on a project-by-project basis? I find some colour-coding, in the absence of a key, confusing. e.g. is it obvious here United Kingdom in the Eurovision Song Contest#Contestants what the dark red signifies? Martinevans123 (talk) 11:35, 19 May 2013 (UTC)
  • We actually can use color in our edits with HTML, but I've never seen a reasonable use for it other than in tables where it corresponded to a value (e.g.,
    political parties). This type of thing should not be done by individual editors because it will just turn Wikipedia into MySpace, a gaudy mess. If there's any scientific benefit to adding colors and decorations, it needs to be done by an outside group that can actually prove it's useful. Otherwise we shouldn't touch it with a ten-foot pole. I have no confidence in editors redesigning the whole site ad hoc and throwing pink and yellow boxes everywhere because "It could help readers differentiate between each thing". —Designate (talk
    ) 12:01, 19 May 2013 (UTC)
    • You don't need to know HTML. You can use color right now if you want. I just don't see the point. This is supposed to be a reference work, not a fruit salad. WhatamIdoing (talk) 18:59, 19 May 2013 (UTC)

1. Brainstorming is best carried out over at WP:Village pump (idea lab). This page is more for well-defined proposals.
2. See Wikipedia:Writing better articles#Use color sparingly - for reasons of accessibility, and to avoid turning off the various demographics who would not appreciate widespread color-for-color's-sake.
3. See This recent thread regarding mindmaps, and also this blog post about Wikidata tools that are under development. (They're a long way off, from being a stable resource, but will be fantastic when they arrive).

HTH. –Quiddity (talk) 02:12, 22 May 2013 (UTC)

• I'm not at all clear how this would be beneficial, but I can think of one big way in which expanding our reliance on color could be substantially problematic. Nyttend (talk) 23:28, 22 May 2013 (UTC)

I propose a needed feature for wikipedia is to automatically determine the ratio of citations in an article to the number of words so that articles can be sorted on this to find the least well supported articles as targets for improvement.

Certainly the quality of citations trumps the quantity. But those articles with a ratio of zero or approaching zero are easy targets for improvement.

There are 221,284 articles tagged as needing additional references, 316,316 tagged for unsourced statements, and 234,733 tagged for lacking sources. These should be easy targets for improvement. Have fun. Praemonitus (talk) 00:31, 23 May 2013 (UTC)

Recent events have highlighted the need for more effective communication between our software developers and the Wikipedia community. When software changes happen without enough input from the community, there are usually problems. When the community reacts against changes because of unforeseen problems, this in turn can alienate the developers from the community and creates a cycle that perpetuates the lack of communication. Right now, announcements and requests for input tend to happen in places other than this wiki. Even when they do not, they are posted to high traffic noticeboards such as the Village Pumps, which are hard for many people to keep up with.

I propose that we create a Developer’s Noticeboard on Wikipedia. Developers and Wikipedians who are subscribed to the software mailing lists could post advance notice of changes, and there would then be a centralized place for discussion to occur. Staying abreast of important software changes would no longer require watching multiple wikis, email lists, or noticeboards. ⇌ Jake Wartenberg 23:53, 7 May 2013 (UTC)

Suggestion: I think the first sentence should talk about more effective communication, not more communication. WMF staff already puts a lot of time and effort into communications. I think the issue is how those resources are spent, not how much are spent. -Pete (talk) 15:39, 8 May 2013 (UTC)

Done. Thanks ⇌ Jake Wartenberg 02:13, 9 May 2013 (UTC)

Question: How much of the opposition is because many of the participants (including me) only found out about the proposed specs and UI when it was deployed? I'm not sure there was an announcement that most users would have seen as a matter of course at the specs (or wireframing/UI mock-up) stage, but if there was, I missed it, and I would have liked the chance to comment/give feedback then. The Crab Who Played With The Sea (talk) 16:29, 10 May 2013 (UTC)

• Support a noticeboard if it is separate from
  WP:VPT clearly, as a place for Wikimedia developer announcements, not general tech discussion. We post on VPT all the time (it's the number one edited project namespace page for my work account), but people seem to think it's too noisy. I don't think that, as an experiment, a noticeboard devoted to Wikimedia technical announcements would hurt. Other ideas that have floated around are newsletters, eventually incorporating notifications for subscribed editors, and lots of other things. We also already publish mandatory Wikimedia engineering reports on MediaWiki.org and the blog, and lots of other things, but I would be happy to post announcements to a Wikimedia tech noticeboard specifically devoted to key feature updates. And we can still try other communication methods or close the noticeboard if it doesn't work. In the long run though, the volume and velocity of work by the Wikimedia Foundation engineers, designers, product managers, and data analysts is only going to increase. We're already discussing moving MediaWiki (for all 800 wikis) to a weekly release cycle instead of every two weeks. We already bust our butts trying to announce changes, and we still get shit thrown at us every time someone is surprised or annoyed. I think now is a good time for English Wikipedia to think of ideas for how it wants to hear announcements about upcoming changes. Steven Walling (WMF) • talk
  00:06, 8 May 2013 (UTC)
• Or maybe we could have automatatic local duplication of the Wikitech-ambassadors list... --Yair rand (talk) 00:13, 8 May 2013 (UTC)
  • Note that's not something that needs Foundation support. Someone could just have a bot receive messages from that mailing list and post notifications of new threads on-wiki. Anomie⚔ 12:08, 10 May 2013 (UTC)
• Strong support. If I recall correctly, the WMF (or was it the devs?) have previously vetoed this idea because enwp isn't the only project around, and they feel it wouldn't be fair or a good use of their time to do "special" announcements here that aren't done elsewhere. So if anyone is about to deploy that argument: I can only say that from the perspective of an enwp editor...that's not a reason to continue to dig yourselves this hole. We, sitting here on enwp, would really like to know about upcoming deployments. You, sitting there in San Francisco and such, would really like us to stop being shocked at and, increasingly, reflexively opposing code changes. Many devs and staff, like Steven and Oliver, do bust their butts to let us know things, but they're limited by the fact that there's just no effective local place to tell us these things. A real noticeboard here, on enwp, is indisputably the best way for you guys to get us, the enwp community, to stop being shocked by these things. That you're also not telling, say, svwp, or enwikt, or any other project about upcoming deployments is probably a sign that you ought to work on your communication strategies, not a sign that it wouldn't save you spectacular amounts of grief if you were better able to notify the community(ies) of things you're working on. You know, from bitter experience, that the enwp community isn't going to follow you to mediawiki.org and ferret out what changes you're planning on making to code that affects enwp. That strategy, the making us come to you, isn't working, even if it's what's technically "fair", and as a result you guys are catching some serious nastiness and dug-in opposition to nearly anything you say from the community here. Please, pleeeeease consider a newer strategy: just telling us what changes you're planning on making, in a centralized location, on the project your changes will be affecting. You can tell svwp and enwikt too, if you want, or not - we won't judge and we probably won't notice either way anyway - but please don't not tell us and create more grief for yourselves just because you don't want to have to tell the Xhosa Wikiquote or something. A fluffernutter is a sandwich! (talk) 00:41, 8 May 2013 (UTC)
• Support Fluffernutter really hit the nail on the head with the word "reflexive." Sometimes it is indeed better to ask forgiveness than permission, but better communication could prevent a large amount of nastiness. ~ Amory (u • t • c) 02:10, 8 May 2013 (UTC)
• Support - worth a try. See also Wikipedia:Petition to the WMF on handling of interface changes. Rd232 ^talk 04:18, 8 May 2013 (UTC)
• I think it's worth a try, but I don't expect it to work. It will just change the complaint from "I hate this surprising change" to "Even though they posted it to some page I don't read, nobody personally informed me about it, so I was still surprised and I still hate it".
  Think back to the discussion about turning on the Mediawiki default for watchlists, which places un-read pages in bold-faced type. It was discussed at Village Pump (proposals) for a month, it was advertised at CENT, and it had overwhelming support and almost no opposition from a couple of dozen editors. Then the change was made, and suddenly people are screaming at the devs (who were utterly blameless) pushing stuff off on the community without consulting them. I don't recall seeing any apologies for that bit of slander, either: people who were informed of the month-long open discussion generally just complained that near-unanimity from a couple dozen editors didn't count as a community consensus, rather than striking their mistaken comments about the devs. And the feature is still crippled by default, which means that most editors don't even know that it exists.
  So think about those people. Think about the people for whom a month-long open discussion, not at VPT and additionally well-publicized at CENT, was just a trivial sideshow that happened to disagree with the True Community Consensus™ (defined as "any statement that agrees with the speaker's personal opinion"). Do you honestly expect those editors to accept a posting at a noticeboard as a valid method of communicating with "the community" unless each and every one of those editors individually chooses to read the noticeboard? I'm thinking that the only thing that would actually work is that recent proposal for blocking people until they acknowledge receipt of the message. These people seem to behave like the people who start the stupid petitions every time Facebook makes a change to its interface—hating on it for a couple of months, and then not even quite being able to remember how the old version worked. I think that we might all be better off with an explicit policy of not listening to en.wp about general design issues (which 99% of editors are no more capable of providing advice to the devs than 99% of Facebook users) but, of course, dealing promptly with practical things, like templates or bots breaking. WhatamIdoing (talk) 04:33, 8 May 2013 (UTC)
  • Completely and 100% agree that the changes are just an immediate anger that will subside rather quickly once people get over the newness. (personally, I found that it took me all of five minutes to adjust to the section edit link moving) Having yet another noticeboard isn't going to 1) make people any less pissy about changes, and 2) won't force people to read when changes are coming. EVula // talk // ☯ // 05:04, 8 May 2013 (UTC)

  I think there's a distinction to be drawn between informing and asking permission. WhatamIdoing is right that asking permission from the enwp community for a code change is pretty much a non-starter; we specialize in failing to agree on anything, and anyway, one project shouldn't have veto power over MW-wide code. However, there's some ground to be gained in informing the community of these changes, even without asking our permission. If there were a reliable location people could check to find out "The code for X will be changing on date Y," it would save us tons of after-the-fact VPT threads ranging from "OH MY GOD WHAT HAPPENED TO X??" to "X suddenly changed and now there are salamanders crawling out of my vector.js, what do I do?" It probably wouldn't prevent all the "X-changers must die" threads, but those are never going to be entirely killable anyway. Why not pick the low-hanging anger-fruit and at least improve things incrementally? A fluffernutter is a sandwich! (talk) 14:28, 8 May 2013 (UTC)

  If each and every one of these people actually read (and remembered reading) the announcements on the noticeboard, then sure. But they won't, so I don't think it will matter in actual practice. It might be a nice gesture, but ultimately a fruitless one. WhatamIdoing (talk) 16:07, 8 May 2013 (UTC)

• Oppose: I don't think the answer to a sprawling system of mailing lists, IRC channels, local wikis (and their noticeboards), and global wikis (with their noticeboards and central notices) is to create yet another forum for announcements and discussion. This feels very similar to the proposed
  Wikipedia:WMF noticeboard.

  Given the existence of dedicated mailing lists such as wikitech-ambassadors and the entire Wikitech wiki, I can't see it being a great idea to create a noticeboard here that nobody will use. I agree that technical changes need better advertising, discussion, and feedback. m:Tech/Ambassadors has some thoughts on this (including its associated talk page) and there may be other ways to address the underlying issue here, but I don't think yet another noticeboard is what we want or need. --MZMcBride (talk

  ) 05:02, 8 May 2013 (UTC)

• Oppose per all the reasons Max outlined. Plus, I have a sneaking suspicion we've discussed this before...development talk should be centralized somewhere (either on meta, mw.org, wikitech), not regulated to a noticeboard on a single project. ^
  ^{[omg plz]}
   05:06, 8 May 2013 (UTC)
  • @^demon: No one is proposing that we centralize developer discussions on to English Wikipedia. What's being proposed is that we separate out announcements about WMF work from the stream at WP:VPT, which is pretty noisy. Folks like me, Oliver, and others already spend no small amount of time advertising and discussing changes relevant to this project locally, so all we'd be doing is moving those announcements and hopefully gaining some additional visibility. Steven Walling (WMF) • talk 07:23, 8 May 2013 (UTC)

    Yes, this. The devs, overworked souls that they are, probably wouldn't even be affected by the creation of such a noticeboard. It would be the domain of the community-facing staff, whose job it is to communicate these changes to us, to do the posting and the talking. And if they're willing to do that, why not let them have a noticeboard to do it at? A fluffernutter is a sandwich! (talk) 14:28, 8 May 2013 (UTC)

    I suspect that you're right, and I certainly hope this is true, because given a choice between "the engineer does actual work" and "the engineer talks about working", I pick actual work every single time. WhatamIdoing (talk) 16:07, 8 May 2013 (UTC)

Who's Max? --Closedmouth (talk) 07:42, 8 May 2013 (UTC)

Max is the first M in MZMcBride. 64.40.54.112 (talk) 03:09, 11 May 2013 (UTC)

• What McBride said. As a developer, frankly I'd like there to be less noticeboards. It'd be really nice if, when announcing a relevant upcoming or potential change, I could just put the announcement in one place such that everyone who cares could see it and discuss it. Instead there are already more places than I even know of, and indeed more than anyone could reasonably be expected to use and follow cross-project, and adding further project specific ones won't solve anything when folks can't even follow feedback on all of the existing ones already. Unfortunately, while these are real issues here, I just don't see this as a solution. -— Isarra ༆ 05:14, 8 May 2013 (UTC)
  • Cross-wiki watchlists, then? Rd232 ^talk 05:22, 8 May 2013 (UTC)
• The problem isn't so much that people don't see announcements from the dev's (and chasing them to a noticeboard isn't likely to help visibility that mcuh, imho), but that by the time interface changes are "proposed" they are often presented as a fait accomplit. Just encourage the developers to say, for example, "we want to replace the OBOD with something, do you think this is a good idea?" Then wait for a consensus to occur on the change, suggesting different options if/as needed and remembering that changes that affect many people should require a very broad on-wiki consensus and may require advertising elsewhere is participation is lacking. Similarly, don't present huge packages that change everything or use extremely long presentations. Proposals/presentations that are short, simple, with the various changes split out as separate proposals even if they are meant to be part of a larger package, will result in higher participation than TLDR proposals. The location of the proposal is barely even relevant compared to the attitude and approach of making the proposal in the first place. – Philosopher ^{Let us reason together.} 06:30, 8 May 2013 (UTC)
  • Yes, it's the development process that's the problem (cf WP:interface changes). There needs to be more exposure of what thinking has gone into different decisions, and what sort of evidence base is being used. Some of the problem is the community not having input into the process; some of it is the community simply not knowing why things are being done, which contributes to a feeling that a change is arbitrary. Rd232 ^talk 11:04, 8 May 2013 (UTC)
  • It sounds like you're still expecting the devs to get our permission to make visible changes. They don't need it, and our interests are not best served by having any power over the devs' work. Design by an ad hoc committee of hundreds of mostly ignorant amateurs is always a disaster. We don't let the coders and designers control our decisions about achieving NPOV on a contentious article; they shouldn't all us to control their decisions about the website. WhatamIdoing (talk) 16:17, 8 May 2013 (UTC)
• Technical discussion is already so fragmented, another noticeboard isn't going to help (relevant xkcd). We should utilize the current methods and fix the current problems (why is
  WP:VPM???). I'm on the wikitech-ambassadors mailing list, and nearly everything gets announced there, and in non-tech speak too. Legoktm (talk
  ) 07:38, 8 May 2013 (UTC)
  • To appease those who refuse to involve themselves with mailing lists, we could have a bot or script that automatically reposts relevant messages from wikitech-ambassadors to a noticeboard page here on enwiki, which users could then watchlist. — This, that and the other (talk) 08:33, 8 May 2013 (UTC)
• Support a centralised, on-wiki noticeboard where the WMF communicates planned interface changes. Furthermore, I suggest that a structure similar to
  WP:VPT. wctaiwan (talk
  ) 12:32, 8 May 2013 (UTC)
• Support - Brilliant idea!, →Davey2010→→Talk to me!→ 14:36, 8 May 2013 (UTC)
• Oppose -- I agree that communication is at the root of recent problems, but don't think that creating a new venue for communication will address that. I would rather see a solution that involves clear and inclusive development and articulation and goals, of transition plans, of backup/contingency plans, etc. I don't think there's any compelling reason that product development staff can't find more effective ways to communicate and develop and execute plans within the existing communication tools. -Pete (talk) 15:39, 8 May 2013 (UTC)
  • I want to note, my opposition isn't strong -- I don't see problems resulting from such a noticeboard. I just don't think we should allow ourselves to believe that the creation of a new venue will solve a problem involving complex communication dynamics. -Pete (talk) 15:42, 8 May 2013 (UTC)
• Oppose for all the reasons already said. Communication is needed throughout the development program with proper feedback and consultation. A noticeboard will only allow this not to happen with a response of "well we posted it on the noticeboard" when the complaints start to come in of an implementation that nobody was aware of or expecting. SpinningSpark 16:36, 8 May 2013 (UTC)
• Sigh. Communication is a two way process. Speaking and listening, writing and reading. Screaming into a well is not communicating with the community. Reading reports from your developers is not communicating with the community. You can make many changes that the community will never notice, but when you make a change that they might notice, you should really feel assured that they will notice, and some of those will object to the change. It is (at least in my opinion) your duty to seek out those objecting opinions and discover how the proposed change can be made with the least disruption. Surprise is a wonderful military tactic, but it's not a good way to win friends and build trust. It's true that FB complainers don't remember the way things used to be -- there are so very many of those ways, after all -- but the overwhelming memory is that the FB developers are screwing with them, and they don't like it. This is not a good way to encourage participation in an abstract undertaking like building an encyclopedia. I'm much more likely to want to see my grandkids, and will put up with a good deal more to do so. htom (talk) 18:18, 8 May 2013 (UTC)
• Oppose People will always be upset by change. This will just be another board they don't read and they will still be upset that they weren't personally told that the changes were coming. This doesn't help anything and if anything is more likely to wheel spinning. People get over change remarkably fast once the newness wears off. -DJSasso (talk) 18:34, 8 May 2013 (UTC)
• Indifferent I'm mostly indifferent on this because if this is deemed needed in addition to the messages I send out to wikitech-ambassadors, then I guess it needs to be done. I hoped those on -ambassadors could do much of the actual dissemination on the various 'pedias/projects because having someone local to the wiki, both in language and in expertise, is better at communicating what the real issues/changes will be for that community specifically, whereas I have to be fairly general for the exact opposite reasons (I'm English-only and not an expert in all the projects' methods/standards). I personally try to send out important/interesting-looking deployments to the -ambassadors list every Friday (when I send out the weekly Deployment and Roadmap update emails). There's way too much detail in those raw emails for most projects, even on a technical village pump (the intended audience is WMF Engineers and Volunteers). User:Greg (WMF) (talk) 18:55, 8 May 2013‎
• Support if it would help but I'm not sure it would. We already have Village pump (technical) and a few other venues where the techies normally hang out. I think it makes some sense though to have a specific place where the developers (both the WMF and non WMF ones) can talk and discuss issues and notify the comunity.
  talk
  ) 20:00, 8 May 2013 (UTC)

• Comment: what about putting a Developer's Noticeboard on Meta, to counter the objection of giving too much prominence to English Wikipedia's concerns? Until cross-wiki watchlists arrive, that has an obvious downside, but that might be a good usecase for a sort of "cheap cross-wiki watchlist", where a bot mirrors pages from Meta to a protected copy of the page on English Wikipedia, so that edits on Meta can be seen here (notably, appearing in the watchlist). Rd232 ^talk 20:37, 8 May 2013 (UTC)
  • @Rd232: MediaWiki developers (staff and volunteer) already have MediaWiki.org, and mostly use Wikitech-l, which is one of our most high-traffic mailing lists. Developers don't really need another discussion space, the proposal is a lot more about how to advertise user interface changes to people who aren't developers. With that in mind, and considering the fact that Meta has very little real community of its own, I don't think a wiki noticeboard there would be much help. Steven Walling (WMF) • talk 08:01, 9 May 2013 (UTC)
  • @Steven Walling (WMF): - yes I know developers don't need another internal discussion space, but they do need a space where they can engage with non-developers on issues where non-developers can usefully give input, and in ways where they can clarify their thinking etc. I suggested Meta because that emphasises that the purpose is engagement with the Wikimedia community; and suggested the cross-wiki watchlist bot thing because putting it on Meta without something like that would be pointless. Rd232 ^talk 08:19, 9 May 2013 (UTC)
• Sigh. I understand what the developers are talking about with having so many places to communicate. If there was just one place to watch, I'd watch that. I've just signed up for the wikitech-ambassadors mailing list, but when it was first announced I was of the impression that it was a mailing list for people who were willing to *act* as ambassadors, and who understand at least 50% of what is on VPT and wikitech-l and so on. (Incidentally,I watch both of them, but understand well under 10% of wikitech-L and under 20% of VPT.) I looked at the messages about moving the section edit button on wikitech-ambassadors-L, and the thread title is "Breaking change notice", which suggests to me that it's something for other developers to be aware of, not that a significant UI change is about to take place, so I'm not sure I'd even have opened that thread if I had been subscribed at the time. It seems that most of the 150 or so subscribers are actually developers or WMF staff, so I've got the feeling it's a bit of an echo chamber. There does not appear to be any significant discussion there; few threads seemed to have responses. So, what I would like to see is a central location where I can find out about changes that will affect me as a user, particularly UI changes, that provides complete information on what will change (both what will be new and what will be eliminated), provided at least two weeks before the change will happen. That way, if there are serious concerns about the change (like the fact that Notifications has major accessibility and usability issues), they can be addressed before there's a raging torrent. Oh, and it needs to be written in plain language; the reason so few "regular" editors watch VPT is that they can't understand the vast majority of what is there. And whatever you do, don't send people to bugzilla. If this means a project-specific noticeboard, I'll be happy, and I'll put it on my watchlist. Risker (talk) 04:41, 9 May 2013 (UTC)
• Neutral, leaning oppose I frequently speak to both developers and Wikipedia editors, so I'm on the fence. In my opinion, while the community can't be prevented from making this noticeboard, I don't feel it would resolve the issues we tend to have. Developers must keep track of many things each day, and often don't have the time for another page to watch. I think the community can improve on the current system by working for more participation in discussions about rather-sweeping features changes. For example, I strongly feel that the consensus generated on this page (without a full RfC) for the changes to the watchlist was inadequate for such a change. I do not think we can keep faulting developers for what I view as at least partly the community's fault.--Jasper Deng (talk) 05:58, 9 May 2013 (UTC)
• I can't see what harm it could possibly do, and I think many users would appreciate it. — This, that and the other (talk) 11:32, 9 May 2013 (UTC)
• Meh. I have ambivalent feelings about this proposal. I'm not fundamentally opposed to it, and I don't think it'll cause problems, so it's probably worth a try, but I don't really expect it to solve the underlying issue.

  On the one hand, anything that can facilitate communication between the community of users and that of developers is a Good Thing™. Steven and Oliver seem to see this proposal as beneficial for the work they do, and both E2 and E3 already have a strong presence and local hub pages on enwiki, so an Editor engagement noticeboard on enwiki wouldn't seem out of place.

  On the other hand, I agree with Whatamidoing when they say "It will just change the complaint from 'I hate this surprising change' to 'Even though they posted it to some page I don't read, nobody personally informed me about it, so I was still surprised and I still hate it'."

  I'm also worried about the expectations. The proposal seems to be for a page where developers (or their community-facing colleagues like Steven, Oliver and I) post announcements; but the name "Developer's noticeboard" sounds to me like "A place where we put stuff for developers to notice", and that's not quite the same thing, so we'd need to make it clear what the page would be.

  Alternative 1: Notifications. It seems to me that this noticeboard would be yet another suboptimal workaround to a proper channel for topical notifications. Echo/Notifications was once presented as the solution to this problem, but "public announcements" are currently listed as "out of scope". I don't know what the timeline is (if any) for the support of topical public announcements in Echo.

  Alternative 2: Bot notifications. In the shorter term, as people have already mentioned above, there are already a myriad of venues for people to learn about upcoming changes; the wikitech-ambassadors is the one we're currently advertising. I'd prefer we consolidate venues and utilize the ambassadors list first, rather than create other venues.

  If the issue is that people don't (want to) use mailing lists, we have a list for people to sign up to get ambassador-related notifications on their talk page, but in practice it's not used much and not kept in sync with the mailing list. I imagine it wouldn't be too hard to subscribe a bot to the mailing list and have it post every first message of a thread to people's talk page. Would someone with technical skills be willing to help with this? The bot could also additionally post to a Developer's hub if people are really attached to the idea, and prefer to see messages in their watchlist rather than on their talk page.

  HTH. guillom 13:01, 9 May 2013 (UTC)

  • I think that there's something to be said for bot notifications. If every WMF project had a designated page for such announcements, the devs could automatically inform everyone of what was planned. Individuals at each project could manually flag announcements as being relevant or not, e.g., by adding something like Y Yes, affects us or N Not applicable—only affects Arabic wikis or whatever they wanted. That might reduce the amount of time that devs spend on communication (more talking == less coding). We could eventually develop an expectation that if you didn't choose to watch that announcement list, or didn't understand what it meant, then your surprise was purely your own fault.
    That would leave us only with the problem of people expecting every single tweak to the UI to be up for discussion, with "me" always outvoting everyone else (times every single "me" on a project). It might be helpful to explicitly manage expectations about responses. UI information pages might link to an informational page about the proven problems of crowdsourcing design, and the fact that people often appreciate changes once they've had a chance to get used to them. Feedback pages might benefit from a note that says something like "We normally review and prioritize feedback about once a week. Don't expect immediate, personal responses. Given a choice between spending an hour silently fixing the bug and spending an hour telling each person who reported it that we're going to fix the bug, we're going to choose fixing the bug." Part of the irritation seems to arise from people expecting ANI-speed responses, and that's not a desirable prioritization of our limited dev resources. A little more education might help, or, at least, it might give us a shortcut to responding to the inevitable complaints. WhatamIdoing (talk) 16:55, 9 May 2013 (UTC)
• Support to the extent that "more effective" includes "at an earlier stage" per my question above. The Crab Who Played With The Sea (talk) 16:29, 10 May 2013 (UTC)
• Support. This can be like the Arbcom noticeboard, which exists purely for the sake of giving the Committee a place to post annoucements. Arbcom and their clerks don't spend much time posting announcements at the noticeboard, so why would we expect the WMF people to spend lots of time at it? They're already spending time making announcements at other pages, like VPT; we're not trying to get them to do something that they're not already doing. Nyttend (talk) 19:44, 20 May 2013 (UTC)

Transclude it to VPT

I agree with WAID, but if somebody wants to try something, then create

Tech news now available

Greetings. Partly due to this discussion, and partly due to previous plans, a weekly tech newsletter is now available. I've taken the liberty of subscribing VP/T to it (see Wikipedia:Village pump (technical)#Tech news — 2013, week 21, and feel free to subscribe a Developer's noticeboard in addition to or instead of VP/T.

If you think this is useful, please help us and contribute to it by adding newsworthy items to the next edition. This will help ensure good communication between users and developers. Also consider subscribing to tech news on your personal talk page, and joining the tech ambassadors list.

This is certainly not perfect and there's room for improvement, so I'll gladly take any feedback you have, here, or at m:Talk:Tech/News. guillom 19:24, 20 May 2013 (UTC)

Thanks for your efforts, Guillaume. They are appreciated. I think this will be helpful. 64.40.54.118 (talk) 03:02, 25 May 2013 (UTC)