Jump to content

Wikipedia:Village pump (proposals)/Archive 102

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

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

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

Wikipedia 2.0

I see that yet another editor has given up (after 31,851 edits). We have seen a large number of editors come and go, and now have a declining number of active editors. While this will clearly level off at some point, and stabilize, it is useful to continue to look for ways to make Wikipedia a more reliable source. A WP:Wikipedia 2.0 would help, a stable version that was professionally created, by real named people who are experts in their field. We could probably even pay them, as I see that WMF has more money than they know what to do with it. Is this a failed project? No. Do editors get burned out and quit? Yes. Apteva (talk) 18:39, 7 May 2013 (UTC)

Citizendium? There is an issue of maintaing active editors and drawing in new ones, but I don't think forsaking the Wiki(p|m)edia model is a fix. ~ Amory (u • t • c) 18:44, 7 May 2013 (UTC)
Well that's not going to happen. But we could have a discussion about what Wikipedia might look like in 2020, if it survives til then. Wikipedia's future is too rarely thought about holistically, and such an exercise might be interesting. Rd232 talk 18:49, 7 May 2013 (UTC)
Just like WP 1.0, 2.0 would be a CD, or DVD, and not something subject to revision. It would just take the best of WP and turn it into something that could be used by us even, as a reliable source. Apteva (talk) 18:52, 7 May 2013 (UTC)
Actually, a better name for the next CD version would be to use the year it was created, such as WP:Wikipedia 2020. Apteva (talk) 18:58, 7 May 2013 (UTC)
It's worth taking these meatball:GoodBye statements with a grain of salt. Frequently, if you check back in a couple of weeks, you'll find that the editor has reappeared. WhatamIdoing (talk) 20:48, 7 May 2013 (UTC)
I often wonder how much real-world work experience some portions of our community have had. The comings and goings of experienced users are no mystery to someone with experience in service or labor workplaces. One day the guy next to you will just realize they don't want to do it anymore and will walk out the door, maybe without saying a word, maybe yelling and screaming, or maybe politely explaining that they just need a change and have are moving on. It happens all the time. For work that is completely voluntary and totally unpaid what is surprising is that there are so many of us that stick around. Realistically, the day will come for almost any user when they just don't want to do this anymore. It doesn't mean there is something fatally wrong with the project, its just simple human nature. Beeblebrox (talk) 21:07, 7 May 2013 (UTC)
This, x1000. I won't try to elaborate, you summed it up well. –Quiddity (talk) 05:33, 8 May 2013 (UTC)
That being said, I think a stable version of Wikipedia that contains only subjects of academic interest and is geared toward schools is an excellent idea and have advocated for it before myself. The answer I got was "good idea, go ahead and do it." Obviously I felt that was a rather large task to take on myself but i would be very interested in forming a group to create a fork like that, not on cds but on the internet so it could be updated, just not by anyone who wanted. I imagine something done by using the import tool to transfer over stable versions of good articles on such topics. It would only take a few dozen people to maintain something like that. Beeblebrox (talk) 21:11, 7 May 2013 (UTC)
All of the "stable release" and "selected release" type projects, are (or should be...) listed somewhere within the pages, at Wikipedia:Version 1.0 Editorial Team, and meta:Static content group.
If any of you want to help re-energize these projects, one good way would be to help track down all the related endeavours that haven't been indexed yet (eg this gadget, which we don't seem to know much about, despite there being a slashdot article about buying up the remainder so that we can send them to kids without internet). This is not a wheel that needs to be re-invented - it's a wheel that has many many children, some of which have been overlooked for too long. Go update the lists of what we've accomplished so far! –Quiddity (talk) 05:33, 8 May 2013 (UTC)
  • Support Support Support Excellent suggestion! User:WikHead is another editor who has left 100,000+ solid edits. From time to time we all feel frustrated and many of us are still trying to find the answer of the question we sometimes face "What do you get by doing (almost) a full time job in Wikipedia?"
    If they have enough money in hand, they can start an "Editors' grant"! --Tito Dutta (contact)
  • Oppose: An unnecessary division of resources. Suppose you split off the best 10,000 articles into its own wiki? You've now got 10,000 articles that are full of red links and have very little cross-linking. Why would people go there? Praemonitus (talk) 23:15, 8 May 2013 (UTC)
  • Comment: Beware the "late daycare fine" effect [1] Now many people give their time and effort for free, but once it becomes commercial, people will game the system. Worse, those who don't get on the payroll may feel their efforts are unrewarded in comparison and even more may leave. cmɢʟee୯ ͡° ̮د ͡° ੭ 19:05, 10 May 2013 (UTC)

Updated maps of US cities for 2010 census

Articles on many US cities, towns, and census-designated places, especially on the west side of the country, such as that on Republic, Washington, include maps such as this one, which were created by Shereth in 2007. These maps are now outdated, since the 2010 census added many new census-designated places (such as Curlew, Washington, previously with an article as an unincorporated community), as well as changes to geographic boundaries of communities.

I commented to Shereth about this in August, a couple months before he announced his retirement, asking whether plans existed to update the maps with 2010 census data. I have since become familiar with GIS and the census's shapefile sources, and am considering undergoing this myself. This would entail not only creating the maps, but implementing a bot (I'm fairly familiar with the bot creation and approval process) to update images in the articles, as well as create template-based articles on new CDPs without articles and update outdated sentences on those with articles ("...is an unincorporated community" -> "...is a census-designated place"). I would need to further research templates such as this one, to see if I could convince the bot to perform such tasks as moving the link to Malo in that template to the CDPs section.

Would any other Wikipedians appreciate this? I've posted a link here to WikiProject Maps, as well.  — TORTOISEWRATH 01:18, 3 May 2013 (UTC)

To illustrate what I mean, I've created a mockup of what the final maps would look like. Obviously, they will be vector and not raster, and be created and uploaded with a script, rather than me spending 27 years making them myself.
  • 2000 data
    2000 data
  • 2010 data
    2010 data
Note the plate carrée projection on my map. I didn't bother to check what projection Shereth used, and am open to suggestions for projection. Plate carrée is, of course, easiest to implement, and would reduce the size of SVG files (for instance, boundaries along particular parallels/meridians could be losslessly encoded as horizontal or vertical pen movements, rather than absolute polygonal points. </nerd>
Also check the map file on Commons; I've annotated my map with notes on the changes that would be made from the 2007 maps.  — TORTOISEWRATH 01:05, 4 May 2013 (UTC)
Appreciation to the above editor for suggesting these changes, although I really don't see how the 2010 census data affects a city or county map, which is governed by state law and not by the census. (I don't see the difference in the Ferry County maps, for example, except one makes the county look skinnier than the other.) My caveat is that one size may not fit all uses, and I hope TortoiseWrath will elucidate on his or her proposal. Why should this be done, in other words? GeorgeLouis (talk) 03:44, 4 May 2013 (UTC)
The US census, in addition to recognizing incorporated cities, towns, and villages, defines census-designated places to (from that article) "provide data for settled concentrations of population that are identifiable by name but are not legally incorporated under the laws of the state in which they are located." In the above maps, the 2010 data added 13 CDPs to the county, making the older one (with CDPs from 2000) outdated.
In addition, in the last thirteen years, many cities/towns/villages/CDPs (such as Everett, Washington, off the top of my head) have annexed new land or had otherwise had their boundaries changed, thus making the older maps not only outdated but inaccurate.  — TORTOISEWRATH 04:01, 4 May 2013 (UTC)
To clarify: these problems affect the entire United States, especially rural areas, not just the state of Washington; I'm just using places in WA as examples because they're those with which I'm familiar.  — TORTOISEWRATH 04:03, 4 May 2013 (UTC)
  • Yes please, please, please. Outdated data is the scourge of all our place-related articles. Please do. Red Slash 16:05, 4 May 2013 (UTC)
    • I wouldn't normally have put this through the proposal process, because of that, were it not for that this could affect tens of thousands of articles. I'm glad to see someone thinks like I do.  — TORTOISEWRATH 16:58, 4 May 2013 (UTC)
      • Because I have a generally good feeling about this, I'm going to start work on the bot to create and upload images to Commons; once I figure out which projection to use (it looks like WP:MAPS recommends equirectangular for most maps of this type, which is awesome), there won't be many more changes needed to the maps should they be implemented.  — TORTOISEWRATH 17:55, 4 May 2013 (UTC)
  • Comment - Shereth, the author of the original maps, has expressed interest in doing this, which is great. He is also proposing the implementation of this WikiProject Maps-compliant color scheme. Which scheme do you all prefer; the compliant one or the old one that I've used above?  — TORTOISEWRATH 16:55, 5 May 2013 (UTC)
  • Definitely support. We need to continue using the ones currently in use until something better appears, and this is definitely better, as long as you can get the proportions right. I'd suggest that you omit the bodies of water, since those make it harder to tell where the boundaries are; the point of these maps seems to be showing the boundaries (as exact as you can be at this scale) of the municipalities and CDPs, and we need maps that can do that. The current scheme is a good deal better, because the other one clogs it up with lots of other elements, like major roads. Such a map is helpful, of course, but that's why we have a map1 parameter: the primary map needs to be one that shows just the location of the city and its boundaries, and a secondary one can be created to show rivers, highways, things in other counties, etc. Nyttend (talk) 05:10, 6 May 2013 (UTC)
    • I completely agree with you. I think I've found a way to get the proportions to where they feel correct, and I've been talking to Shereth about who will perform the actual implementation (we both want to do it). In regards to water bodies, though, I added them to assist in presentation of places like Michigan; I'll experiment with ways to omit them, as they result in unnecessary complication and embarrassingly large SVG filesizes (5MB+ in some cases).  — TORTOISEWRATH 00:45, 7 May 2013 (UTC)
  • Definite yes to updating maps for those places that have changed, though for the many entities that did not have any boundary changes it may not be necessary. With regards to textual updates, I'd suggest some care is needed. A CDP is for the most part an unknown designation other than among census wonks. For the most part, if these places were previously unincorporated communities, then they should remain described as unicorporated communities, regardless of whether the Census Bureau decides to compile statistical data for them as a CDP. This might mean adding text about the CDP status (and when defined) rather than replacing existing text. older ≠ wiser 00:57, 7 May 2013 (UTC)

Discussion from Shereth's talk page

I've moved this here. The discussion, should it continue, shall continue below.  — TORTOISEWRATH 21:55, 10 May 2013 (UTC) I just saw, following my proposal along those lines, your comment on Ixnay's talk page late last year, which came a month or so after I asked you about that. Because you're no longer particularly active, I presume this isn't something you'd continue to like to take on yourself, but please let me know if you're planning to so that I don't accidentally do it for you.  — TORTOISEWRATH 03:21, 5 May 2013 (UTC)

Hello! Actually, not too long ago I put some effort into just this sort of thing. I already have the script written and it is capable of generating all of the maps we need; the effort got stalled when I tried to get some input from other editors with regards to map standards such as colors and content. If there is still some interest in this sort of thing I'd be happy to fire it back up. Feel free to take a look at Wikipedia:WikiProject_Maps/US_locations and let me know what you think. Shereth 15:05, 5 May 2013 (UTC)
I would recommend coming up with a color for unincorporated areas, as well as standardizing the map projection, but those conventions otherwise look great! At least two Wikipedians have expressed interest in this... which doesn't make it sound important, until you consider that the older maps are blatantly outdated and often completely incorrect, which is a problem. 'Tis a shame I can't do it myself.  — TORTOISEWRATH 16:43, 5 May 2013 (UTC)
Also, I don't personally like the look of adding roads to the maps; this draws attention away from the cities. See: KISS principle.  — TORTOISEWRATH 16:45, 5 May 2013 (UTC)
I am largely in agreement with you regarding the roads, but I guess that's part of what stalled things before; when you only have the input of one or two editors it's hard to really get any kind of useful consensus. If you want to nudge a few other folks in the direction of the page I linked you and spark up a little discussion, I don't think it'd take much work to settle on a finalized set of conventions and go ahead and generate the maps. For what it is worth, there is a standard for projections; see Wikipedia:WikiProject_Maps/US_locations/Technical_specifications, linked on the earlier page, if you hadn't already. Shereth 16:50, 5 May 2013 (UTC)
Ah, I hadn't seen that. The WPM specifications for location and locator maps both use equirectangular projections, which seems odd to me, but I'd been going with it. Of course, equirectangular projections can reduce SVG filesize (as one could use h2 or something for boundaries along, say, the 49th parallel). Also, I don't know if this is covered in the above specification, but including a mini-map of the state, as had been done before, is a good idea.  — TORTOISEWRATH 17:09, 5 May 2013 (UTC)
See File:Baldwin_County,_Alabama,_Daphne_highlighted_(2012).svg for an example of the maps I'd been working on, which are in the same style as the old ones. I haven't gotten my script to align the state beautifully as you had; I don't know if that's a bad thing.  — TORTOISEWRATH 17:23, 5 May 2013 (UTC)

Sorry to triple-post, but Nyttend has raised a good argument at VPR: "The current scheme is a good deal better, because the other one clogs it up with lots of other elements [...] the primary map needs to be one that shows just the location of the city and its boundaries, and a secondary one can be created to show rivers, highways, things in other counties, etc." After picturing how the different styles of maps would appear in the place of where they are now in infoboxes, I feel that I agree with him—it would be best for the project to keep the primary maps showing locations of cities as simple as reasonably possible, and I think your maps in the old style fulfill this meaning in existence well.

Because, as you said, I doubt either of us could ever build consensus around switching to the new-style maps (there's simply not enough interest in cartography of minor US communities around here); as such, I would suggest updating the demographic data in articles and updating the maps to versions mimicking the old style, but with updated boundaries of communities. I would be more than happy to do either or both of these if you don't want to (or are sort of "meh" about it), considering how fed up I've been with the outdated data across the US.

Once that's done, you could feel free to continue trying to build consensus on the new-style maps and how/where they should be used in articles. What do you think about this idea? Do you want to take it to the idea lab to see which variety and presentation of map the community would prefer?

Sorry to keep pestering you about this; it's something I really want to see done, and I don't think anyone would disagree with a simple update to the existing maps, as I've outlined above.  — TORTOISEWRATH 20:49, 6 May 2013 (UTC)

I'm certainly not adverse to taking a step "back" in terms of the maps' content, but I really would like to see a little more in the way of consensus than two or three editors' opinions. The only reason I am hesitant to act a little more boldly is because of what happened previously. To break it down to its most simplest, what happened was I proceeded with the map generating and uploading with a small consensus and went along merrily for several thousand edits until running into some vociferous opposition when I happened onto some of the articles that they maintained. There's nothing quite so upsetting as putting in all that hard work just to run into recalcitrant roadblocks.
That said, it's fairly trivial for me to turn layers on and off in the script I've written, and I don't disagree that spitting out a run of maps based primarily upon the old ones would, at the least, be an improvement. I think the only thing we really aren't strictly in agreement on at the moment is which projection to use .. I have to confess to being really quite stuck on the Albers projection, it just seems much more aesthetically pleasing to me! Shereth 21:48, 6 May 2013 (UTC)
If you're hesitant to move forth even with the old maps, I'd be glad to continue work on my script, which I imagine functions similarly to yours. I would also like to see a "real" consensus if you were to make a change, as you would if you were to base the maps on that WikiProject proposal, but I don't think there should be a problem with simply updating the old ones (as long as you upload them under a new filename; I've seen some ugly arguments in that regard on Commons).
If you choose to upload a new batch of maps, do you have a script set up to implement them into articles? As far as I can tell, this would necessitate the following:
  • Locating usage of the old maps, "dot" locator maps, pushpin maps, and other maps in the |map1 attribute of infoboxes on community articles
  • Creating articles for communities without them based on a template, including detailed demographic information and geographic details
  • Updating community type information in existing articles (the changing of "...is an unincorporated community" to "...is a census-designated place" and the like)
  • Adding population, area, population density, and maps to infoboxes and demographic data to the bodies of articles without them (such as the current incarnation of Curlew, Washington)
  • Rearranging links in templates such as Template:Ferry County, Washington to reflect new place type definitions
This would be fairly trivial for me to implement, but I don't know how experienced you are with wiki-editing bots or how you inserted the images originally.
Also, regarding projection: I completely agree that the Albers projection is more aesthetically pleasing; the equirectangular projection does, however, cut down file size. I've been looking into algorithmic north-south stretching with equirectangular SVGs, and it seems very doäble. From what I've seen of people using the technique in their cartography, it could very well replicate the Albers projection while keeping longitudinal correspondences intact.
If the map and data changes are something you'd be comfortable with, I'd say go for it; otherwise, I will. It's going to happen, it's just a matter of who should get blamed for it. I understand that you have been left with a bad taste in your mouth (is that why you "semi-retired"?), so I very much understand if you'd rather not make such a large change by yourself, and I would be glad to do it for you if you so wish.  — TORTOISEWRATH 23:02, 6 May 2013 (UTC)
Found this because Tortoise linked my name. Is there any chance you could do the following sequence of events? (1) Continue the discussion of what to include in the new maps until we've reached consensus. (2) Create and upload the new maps. (3) Get as-close-to-projectwide consensus as possible (perhaps at the same location as the maps discussion; I can't remember where it is) for the new maps. (4) Start uploading, and point complainers to the consensus instead of having to deal with the criticism yourself. Even if people complain about the new maps, at least this way we'll be able to add them to pages where people aren't complaining. Nyttend (talk) 03:50, 7 May 2013 (UTC)
I would support that. By the way, the discussion is at WP:VPR#Updated maps of US cities for 2010 census.
Also, directed at Shereth, I have great news regarding projection in case I end up making the maps. This great news is best summarized with a gallery:
I was going to put a gallery here, but I suddenly had a massive problem with my script.
To get these to look right, I utilized a vertical scale factor of sec(central latitude), as suggested to me by NNW. These maps' lack of water features (or omission thereof) is tentative.
By the way, if you know off the top of your head, approximately how long does your script take to generate a map for a community? My runtimes are suspiciously high (20–180 seconds per map in counties it's done before, depending on whether I include the state mini-map; up to an hour in counties it hasn't), but I have some ideas for additional caching and optimization, which I do intend to implement if I am the chosen one, because having the map generation take until September isn't what I had in mind.
Please check VPR for my additional thoughts on this. (Perhaps we should move this discussion over there, to try to get the community involved?)
Oh, and in case you haven't guessed yet, I'll state it outright: I want to do this. I don't know whether I should attribute that to some negative thing like ego or editcountitis, but I know that you also want to do this, and I respect that, because there's no taking away the fact that the principle is yours...and that you're an admin, and those are scary. ;-)
In about seventeen nutshells, here's the plan I'm suggesting:
  1. This entire talk page discussion will be moved somewhere else (either here or idea lab), because keeping it here is stupid
  2. TortoiseWrath will attempt to get community input on:
    • What color scheme should be used
    • What projection should be used
    • What should be included on the maps
    1. If no significant input is obtained, maps will fall back on whatever's traditional or easiest, depending on the mood of the person making them
  3. TortoiseWrath or Shereth, as chosen by a community vote, rock-paper-scissors, whatever, will:
    1. Create and upload updated versions of community maps using the same color scheme as before
      • These maps may or may not include water features
      • Maps both with and without water features may be uploaded under unique designations
      • If either of us can get a bot on Commons with file mover permissions, the old maps MAY be renamed to have (2007) at the end of the name, to reduce confusion
    2. Update articles to include these maps in place of older ones, pushpin maps, or lack of maps
    3. Update articles to reflect changes in census designation
    4. Add census data to articles on former non-CDPs
    5. Create articles for CDPs without them
  4. Shereth, possibly in collaboration with Ixnayonthetimmay (I don't know how that's working on your end), will continue work on Wikipedia:WikiProject Maps/US locations
    • If a consensus can be built, these maps will be generated, uploaded, and implemented by Shereth
  5. As long as someone maintains interest, whichever map set is in use at the time will be updated annually (possibly at the same filename, to reduce server load) to reflect changes in stuff
Let me know what you'd like to do.  — TORTOISEWRATH 02:06, 9 May 2013 (UTC)
Added gallery. (And yeah, my state-scaling subroutine is broken; I'm working on it.)  — TORTOISEWRATH 04:07, 9 May 2013 (UTC)

Discussion resumes

Please place further comments here.  — TORTOISEWRATH 21:55, 10 May 2013 (UTC)

Updating and improving pages? Yes, please!. I'm not sure if this moderation of data happens before or during the running of the bot/tool/whatever, but if you need any help with beforehand Iowa data moderation, please leave me a note on my page - I'm not terribly active generally, but can probably spare a little time here and there to help out. – Philosopher Let us reason together. 21:14, 12 May 2013 (UTC)
Comment Since I haven't reached any opposition thus far, I'm going to work on fixing the state sizing and launching the script unless Shereth contacts me fairly soon saying that he'd like to do it.  — TORTOISEWRATH 20:39, 13 May 2013 (UTC)

Year with comma

Moved to Wikipedia:Village pump (technical)#Year with comma. King of ♥ ♦ ♣ ♠ 11:30, 12 May 2013 (UTC)

Wikipedians meeting point

Is it possible to make a Wikipedians Meeting Point ?

The purpose is for interact with other wikipedians on Wikipedia.

What do you think ? It's a good idea ? --CortexA9 (talk) 05:59, 12 May 2013 (UTC)

  • I dunno... there's already the Village Pump and its many incarnations. I would say we don't really need it—we're an encyclopedia, not a social networking site. But that's just my opinion. Ignatzmice•talk 17:07, 12 May 2013 (UTC)
  • (Keeping WP:NOTSOCIAL in mind) some editors add others in Facebook or Google Plus. I have got some editors in friend list in Facebook. There are few IRC channels where I have seen editors discussing on general topics. There is Teahouse and Reference Desks as well. Sometimes we have a chat on editor's talk page too!
    A edito talk page may be created for this purpose where any editor can go and have a chat, like Use talk page for sandbox warning! --Tito Dutta (contact) 17:19, 12 May 2013 (UTC)
    • Theres also a lot of area meetups like the one in DC yesterday. Aside from that the way things are going we'll have it soon enough. It seems like everything else is being changed to mimic facebook including the new login page and the new notification pages. I just hope the new visual input tool doesn't look like timeline! Kumioko (talk) 17:26, 12 May 2013 (UTC)
Is there anywhere I can whine about the new login to, Kumioko? I hate the way it looks. TheOriginalSoni (talk) 17:52, 12 May 2013 (UTC)
If you don't like Wikipedia looking like Facebook, the new notifications box and the login screen are the least of your worries once this goes live in a couple months. 78.149.172.10 (talk) 18:01, 12 May 2013 (UTC)
Is it going to be opt-in or forced? TheOriginalSoni (talk) 18:31, 12 May 2013 (UTC)
Eventually forced - the WMF's wording is "you should expect that this system - or one like it - will eventually become mandatory". That talk-page is interesting reading for anyone in any doubt as to how much the WMF holds "consensus" in contempt, as it consists mainly of various WMF people saying that they don't need to ask, because they're sure abolishing talk pages and replacing them with a WMF-owned social network where every conversation is one-on-one on the walls of the relevant users (that isn't hyperbole, that really is what's planned) is what everyone wants. Note the WMF spokesman saying, without bothering to actually ask the people who use it every day, that "there are no strengths of the existing system, only interesting work arounds for its flaws". 78.149.172.10 (talk) 19:38, 12 May 2013 (UTC)
There are several venues in which to complain, there is the Village pump (technical), Jimbo's talk page is a popular venue with high readership and there are several Wikimedia pages as well to discuss them. Frankly none of them are going to matter because the community has shown that we cannot make decisions for ourselves so the WMF isn't going to ask, they are going to direct. Much as the Syfy channel lost a lot of its support when they went away from their Scifi topic area Wikipedia will do so as well when they target the casual IP editor over the ones that stay and contribute actively. All these changes that are being done are tailored to try and attract more editors and keep them but what the WMF continues to fail to understand is that it isn't the editing interface driving people away, its the culture here. When you treat new editors like lepers and treat each other like animals most people won't want to participate. Kumioko (talk) 19:49, 12 May 2013 (UTC)
Which part of
"Ok, on talkpages, you have to type : (colons) to indent your messages. Don't forget to increment the number of colons you're using, if replying to a reply! You also have to type four tildes (that's the key up there, oh, hold down shift; or you could also click here or here) at the end of each new message, in order to make your username and the timestamp appear..."
do you enjoy explaining to newcomers, the most? (e.g. my History of Science professor who I'm trying to convert into a regular Wikipedian). I like the part about how we achieve talkpage indents, by using the definition list element, utterly-improperly. That really confuses them! </sarcasm>
I'm looking forward to Flow (once the bugs are worked out). Because as much as I enjoy the hipster lifestyle, I'm not overly attached to old interfaces just because I'm used to them. Rather than complaining abstractly about the planned changes, why don't you go submit feedback and bugreports that helps them improve it? Suggestions that aren't mixed with veiled/blatant insults, are usually quite well received... –Quiddity (talk) 21:31, 12 May 2013 (UTC)
I entirely agree that the current talk system is confusing, and the WMF have a technical fix for that which works fine on other wikis, but which they refuse to activate on en-wikipedia because it conflicts with Jimmy Wales's "Project Athena" scheme to rebuild English Wikipedia into a social network. The "Flow" proposal is not a plan to address the issues of indenting and signing - it is a plan to abolish talkpages completely. Apologies for the boldface shouting, but the WMF are doing their best to obfuscate just what they have planned until it goes live and it's too late to complain, and people have a right to know just what Jimbo and co have planned for them. 78.149.172.10 (talk) 21:48, 12 May 2013 (UTC)
Actually, your so-called "technical fix" (LiquidThreads) is pretty dodgy. I, for one, would not want it coming near enwiki, and even the person who coded it probably doesn't support its installation here. — This, that and the other (talk) 10:20, 13 May 2013 (UTC)
My other project uses liquid threads for comment pages. While it is theoretically useful there (for people to engage each other and discuss a topic, rather than to improve content), it has implementation issues with the creation of subpages. You can find a LQT page without context for everything up thread and it can completely throw off context in awful ways. I would not want it on English Wikipedia as a result. --LauraHale (talk) 10:35, 13 May 2013 (UTC)
What the heck does Jimbo have to do with it??? He's just a fundraiser/scapegoat, at this point. (And semi-regular editor). Bringing his name into (almost any) discussion seems confusing/distracting/inflammatory. –Quiddity (talk) 22:29, 12 May 2013 (UTC)
The devs say that it is not possible to use LiquidThreads on a project this size. The code can't actually handle the volume. WhatamIdoing (talk) 22:48, 13 May 2013 (UTC)
Jimbo is brought up on various occasions as the man who can make a change if he wishes to do so. IMO he's a wimp that's just trying to stay out of trouble, like taking sides or even have his own opinion on an issue only if he really has to. Forget about bringing him up in any confrontational issue as he's just a political correct smooth talker without substance in his saying. Of course, that's just my personal opinion of him and while some will agree with my "judgment", others will not. But Wikipedia and their editors are not immune to real live judgment.TMCk (talk) 01:00, 13 May 2013 (UTC)
By the way, that's a real person that you're talking about. It's conventional not to publicly insult other people, even when you disagree with them. WhatamIdoing (talk) 22:48, 13 May 2013 (UTC)
"Abolishing" talkpages in some sense might not be the worst thing. On many articles, the talk discussions suggestions are swept under the carpet and we pretend nothing's wrong. Putting the talk page's Table of Contents at the bottom of articles, although not without its risks, would probably do more to crowdsource reader feedback than if the current Article Feedback Tool were fully deployed. FallingGravity (talk) 01:18, 13 May 2013 (UTC)

"Before creating an article, please read Wikipedia:Your first article."

I see "Before creating an article, please read Wikipedia:Your first article." when I click a redlink. Would it make sense for Wikipedia to check to see if I have previously created an article and *not* include it if I have created at least 1 (or maybe 10) articles?Naraht (talk) 01:34, 13 May 2013 (UTC)

Why? You aren't actually forced to read that page every time. It does you no harm and wastes none of your time being there. --Jayron32 02:06, 13 May 2013 (UTC)
Just fyi, the text comes from MediaWiki:Newarticletext. FallingGravity (talk) 05:37, 13 May 2013 (UTC)
Just looking at making it smarter in that regard, the text generator in MediaWiki:Newarticletext is pretty smart already, just looking to see if that could be made smarter still using information about the user.Naraht (talk) 13:33, 13 May 2013 (UTC)
I believe that the software is having trouble distinguishing between article creation and page moves in some instances, so we can't actually implement that idea with any reliability. WhatamIdoing (talk) 22:50, 13 May 2013 (UTC)
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 https links? It would be fairly easy to use the rules from https everywhere to change the links where the site supports it. Making this change would improve security and privacy for users. One reason I suggest this is that DuckDuckGo already does this for its search results. So, is this a good or bad idea? --h2g2bob (talk) 23:46, 13 May 2013 (UTC)

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)

Aggregate discussion of naming conventions

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)

NFCC 10c task

I perform a task to identify WP:NFCC#10c violations as outlined at User:Toshio Yamaguchi/NFCC task. It is nearly impossible for one person alone (me) to work through all the violations in a reasonable time. I therefore propose to create a dedicated group for this task (something like a taskforce or WikiProject) so that more people can work on that task together in a coordinated way. This proposal is for evaluating whether such a group would be desired by the Wikipedia community, whether there would be people willing to join and how that group were to work. -- Toshio Yamaguchi 08:53, 14 May 2013 (UTC)

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)

Superfluous pop-ups

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.TMCk (talk) 01:42, 11 May 2013 (UTC)

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). Kumioko (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.TMCk (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)
+1 — Scott • 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, TMCk (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)

SI Units of measurement

 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. WP:MOSUNIT already recommends SI units for articles about scientific topics, but in the US and among older readers in the UK and in some other English-speaking countries SI and other metric units are not widely understood, so we should use both systems in other articles. Phil Bridger (talk) 14:51, 13 May 2013 (UTC)
Right. The sum of all human knowledge must include imperial measurements for a minority group of English-speaking users because the English language, which insists on being the world's lingua franca, can't adopt international systems like the metric system or the 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 £sd, is to use SI and/or other metric units, but for much of our readership, especially in the US, these are gobbledygook. 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 Mm2," "190 kJ," "8.3 dm3," 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.

New template

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:
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)

RfC: Pending changes Level 2

An RfC is open on whether to implement pending changes level 2 protection, closed in a previous RfC as "no consensus". Deadbeef 06:14, 18 May 2013 (UTC)

Mandatory expiration of indefinite edit locks

Indefinitely protecting articles leads to the so-called "mission creep" where an increasing number of pages become locked indefinitely, creating a divide between users (who often have little interest in administrative matters and will not contribute to articles) and a priveleged administrator group. This is counter to Wikipedia's inclusive attitude and there is no basis for indefinitely protecting an article, as current attitudes towards a wide range of topics are not necessarily indicative of attitudes several years from now.

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, LT90001 (talk) 12:45, 16 May 2013 (UTC)

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. LT90001 (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.

I specifically refer here to articles placed under protection that has lasted over a year.

  • It is switching from an inclusive model of editorial role to a gatekeeper model of articles.
  • Moderated input is against Wikipedia's interests and ethos.
  • Simply seeing a lock, I suspect, is enough to deter users from randomly editing (which is scarce enough as it is).
  • The rollback mechanism already exists.
  • Editorial misuse is possible, especially if reasons are not openly stated on the protection log.
  • Similar cherry-picking of content in line with an editors' interest is plausible. Although unlikely, an opaque system can't be monitored effectively.
  • Changes in world events, societal attitudes, and the short attention spans of trolls for many articles means that a perpetual edit lock or moderated edits is not warranted.
  • Although an apparatus for manually de-protecting exists, but it is not fair for the majority of Wikipedia users to know about or have to use this obscure mechanism.
  • There is no reason why vast majority of indefinitely protected articles should be protected indefinitely. This means forever! Why not just a year or two and then subsequently renewed?

Can anybody see my point of view here on this? I just think it has the potential for abuse, deters random edits, and is unwarranted for the vast majority of pages! Indefinite is a very long time! LT90001 (talk) 00:32, 18 May 2013 (UTC)

Comment LT90001 probably doesn't realize this, but Category:Wikipedia protected pages without expiry lists pages with any form of protection applied to them. This includes Wikipedia:Pending Changes, Semi-protected pages, and 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)

RfC regarding a proposal to include a sentence about Carnap's paper in Quine's dispute of this paper

content dispute
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Comment is invited upon including a sentence about a paper written by Carnap in a discussion of that paper by Quine. The RfC is found here. Brews ohare (talk) 00:26, 19 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.

Discussion notification: Should Hindi Wikipedia be included among our mainpage interwiki links?

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)

Fixed Navigation Bar

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)

Making a Special page Recommended Watchlist.

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)

Normal pH of the human body

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 "Wikipedia:Reference desk/Science". — SMUconlaw (talk) 10:39, 20 May 2013 (UTC)

Flow

Moved to Wikipedia:Village pump (miscellaneous) § Flow
 – -- Toshio Yamaguchi 22:42, 20 May 2013 (UTC)

Merging WP:Proposed mergers and WP:ATD-R into Wikipedia:Articles for deletion

I believe it is counter-productive to have three different venues for these discussions. If you believe an article should be deleted, you have to go to WP:AFD. If you believe an article should be merged into another, you have to open a discussion in the destination's talk page and list it at WP:PM. If you believe an article should be replaced with a redirect, the official recommendation is to just do it boldly and then discuss it on the talk page when someone refutes it. Here are my problems with the current system:

  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:PM, or (3) stumble upon the discussion by happenstance. By contrast, 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 WP:ATD-R results in the deletion of an article. The important difference between redirection and deletion is that the former can be performed and reverted by any editor, whereas deletion can only be performed or reverted by an admin, so is a much more drastic move than redirection, and as such is an exception to the normal wiki "anyone can edit" process, so requires much more detailed policy around it. Requiring redirection to go through the same process as deletion would simply result in more unnecessary bureaucracy around it, rather than treating it in the same way as any other normal editing process that anyone can revert. Phil Bridger (talk) 18:38, 13 April 2013 (UTC)

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)

I want to bring you an example. On April 12, I proposed to merge Colossal Connection into The Heenan Family. It's been almost 3 days and no one has yet to comment on the proposal. But after nominating the article for deletion last night, it took just FOUR hours for someone to respond. This is just proof of what I'm trying to get at here. AFD is just more effective than all the other processed because it is extremely popular. We need to take advantage of that so that our merge discussions don't suffer. Feedback ☎ 20:15, 14 April 2013 (UTC)

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 The Funkadactyls article the other day and turned it into a redirect. A rookie editor disagreed, started an edit war, then began a discussion at 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)
  • 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. TheOriginalSoni (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 WP:SCHOOLOUTCOMES redirect, still be WP:BOLDly redirected without taking it to AfD? Michaelzeng7 (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 {{afd-merge to}} and the destination article's talk page (where any necessary organization should occur) with {{afd-merge from}}.
    The solution is to inform such administrators that they're acting inappropriately, not to shift all merger discussions to AfD. —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 bold editing, not unlike removing inappropriate material, adding brand new material, or reformatting an article to improve its flow. All of these are routine revisions, the discussion of which is the reason why article talk pages exist.
    Merger proposals also serve other purposes, of course. They're made by editors who wish to solicit feedback on how to carry out a merger and those who don't feel comfortable doing so themselves. Again, these are normal talk page discussions. They might take a while, and they often require the knowledge of those who've read/edited the relevant sources/articles and are familiar with the subjects and how they relate to each other. Such discussions aren't comparable to deletion debates. As noted above, a merger can't be performed by pushing a button.
    It makes as much sense to send merger discussions to AfD as it does to send cleanup discussions or expansion requests there. Merging is a form of editing, not deletion. —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 {{afd-merge from}} tags describing mergers that never took place (with the source article either surviving or being merged into a more appropriate target).
    Even when "merge" is the correct outcome at AfD, it doesn't bring the process to a tidy conclusion. (We have no "merge" button to press.) Instead of contributing to the backlog of merger proposals, we contribute to the backlog of merger decisions waiting to be acted on, the only material difference being that no helpful input is even being requested (because the decision already has been made — by parties less knowledgeable on the subjects and their relationship).
    User:Feedback noted that a merger proposal generated no response after "almost three days" (not nearly long enough to wait, incidentally), but an AfD listing generated a response within four hours. Well, yeah. Editors spoke up because they saw the article nominated for deletion (an administrative action that most users cannot reverse) and didn't want that to occur. In no way does this help us to perform the proposed merger, which still requires actual editing to carry out. It merely increases the congestion at AfD.
    And routinely handling merger proposals at AfD won't magically generate more participation; it will simply dilute (and overburden) AfD. As I said, it's the possibility of deletion that elicits quick responses. If we change AfD to a forum in which discussions don't necessarily relate to deletion, the community will react accordingly. WP:PM already serves as a central location at which proposed mergers may be advertised. I can't imagine why anyone believes that an "AfD" stamp (with no actual threat of deletion) will somehow send people running to comment. We'll just have a bunch of merger listings clogging AfD (with few generating meaningful input in the week or two before they're closed) — which could have been constructive discussions if they'd been held on the articles' talk pages, with no artificial deadline imposed (thereby enabling knowledgeable parties to participate).
    Imagine treating other content concerns this way. Someone wants to trim, expand, reword or reorganize an article, and instead of discussing it on the talk page, we send them to AfD and demand that a binding decision be reached within a week or two. That isn't much different from what's been proposed above. —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 this AFD which has been relisted twice without attracting any comment. Mergers and redirections are, by contrast, something that may be done by ordinary editing and so do not need concentrating in a special place. Such action blurs with other structural changes to articles such as re-sectioning or sorting and the best place for such discussions is on the talk page(s) of the pages in question. If the discussions are poorly attended then the processes of WP:BRD, WP:RFC and WP:3O may be used to attract attention. So, we have plenty of process already and the problem is a lack of interested editors. Changing the process will not resolve the problem and would make it worse by making AFD even more 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 WP:Proposed merges to begin with, it happens with ordinary discussion on talk pages, a more informal process. This wouldn't prevent that.
    Its section heading notwithstanding, the proposal is for "all the merge and redirect discussions going on talk pages" to be replaced by "merging them all into AFD". As a specific example, the proposer cited a merger discussion not listed at WP:PM.
    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.
    We already have a venue in which all options can be considered: AfD. I don't object to the idea of renaming that forum to make this fact clearer, and I'm not sure that I even object to the elimination of WP:PM. I object to the proposed relocation of all merger discussions to AfD.
    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.
    I wasn't referring to your understanding of Wikipedia or position regarding the proposal. Note that I wrote "possible misunderstanding on my part or yours" (emphasis added), by which I was referring to the possibility that one or both of us misunderstood the other's comments (perhaps leading us to talk past each other). This appears to have been the case. —David Levy 18:08, 20 April 2013 (UTC)
    Note: Via this message, User:Feedback just confirmed that "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." —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 Category:AfD debates where all the discussions were transcluded. We could also consider more closely integrating 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. RayTalk 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 {{afd-merge from}} tags documenting mergers decided upon at AfD but never carried out. —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 WP:NOT) issues, which are the bread-and-butter of AfD. I support this because the "rules of procedure" for AfD already explicitly allow this, or at least can be amended to allow it with little disruption. I admit, this may well apply to the vast majority of proposed merges. But what of the remaining ones? Merges proposed more for stylistic or prosaic concerns, or splits for that matter? Or 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 WP:NOT issues to AfD (even when outright deletion isn't sought).
    But if there isn't an active dispute, this shouldn't be a first-line measure. Unlike deletions, mergers needn't even be proposed. Lacking evidence/suspicion of controversy, editors are encouraged to simply merge articles as they see fit. Even when a merger is instead suggested on the article's talk page, this doesn't necessarily indicate that it's controversial. (It might simply mean that the editor seeks advice on how to carry out the merger or doesn't feel comfortable on a mechanical level.)
    In the case of a notability/WP:NOT-based merger that's contested (either opposed or reverted, with no clear consensus emerging on the talk page), I can understand why an AfD listing might be helpful. —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 WP:PM) to AfD. Some users are supporting the proposal without realizing that. (One stated that AfD "won't be overwhelmed" because "most merger discussions don't really require a community discussion, just agreement on the talk page." Another stated that "to say this would take away the ability to use the article talk page stretches credibility to the breaking point." Both equated the proposal with an earlier one calling for disputed merger requests to optionally be transferred to AfD.) —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 {{afd-merge from}} tags from years ago, describing AfD-determined mergers that have never occurred. Instead of contributing to the backlog of merger proposals, we'll contribute to the backlog of merger decisions waiting to be acted on. The latter is worse; the material difference is that no helpful input is being solicited (because the decision already has been made — by parties less knowledgeable on the subjects and their relationship). —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:BRD cycle. As previously stated by others, any user can perform or revert mergers and splits, and thus do not need admin intervention. Also, a merge discussion can usually take more than the seven-day AFD deadline because content issues need to be resolved. This includes whether it should be a full merge (pasting all or most of the content from the source article to the target page) or a selective merge (selecting only part of the content that should be merged). I disagree with the assumption that by moving all merger discussion to AFD, they will automatically receive more participation and become a better efficient way to "achieve consensus". Again mergers, especially selective merges, are content issues. Many participating in the normal AFD discussions will not know the intricacies of the subject of the articles to judge the 'gray area' of what verifiable content to keep and what to remove, and how to merge all this material in line with WP:BETTER, WP:WIAGA, 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 WP:ATD-R into Wikipedia:Articles for deletion? If you have changed your "official stance" then tell us by striking point 1 of your proposal and replacing it with your changed proposal, but don't accuse me of lying. 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)
    Corwood Industries is an excellent example of where taking the article to AfD was a total waste of editors' time, as it was an obvious case for redirection. Your proposal would produce many more such time-wasting discussions. Phil Bridger (talk) 21:51, 9 May 2013 (UTC)
    That's an outright lie.
    Please assume good faith. If Phil's statement was inaccurate, there's no reason to believe that this was intentional. Oddly, you haven't accused the numerous supporters who've misunderstood your proposal of lying.
    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.
    Like WhatamIdoing, I'm beginning to doubt that you fully grasp the current setup. You're referring to bold mergers (which you don't seek to change) and WP:PM (where outside feedback/assistance is sought). Do you understand that most mergers fall somewhere in-between?
    The mere act of discussing a prospective merger doesn't necessarily mean that it's controversial and requires debate. Very often, it relates more to considerations of how to proceed (e.g. what text to retain and how to integrate it). And even when the question of whether to merge is raised, this isn't materially different from other disagreements about what content to include and how to organize it.
    All of this is ordinary editing, the discussion of which you inexplicably seek to transfer from the relevant articles' talk pages to a separate, time-restricted forum. How, in your view, would this be helpful? Why should merging be divided into "proceed without any discussion" and "file a formal request at AfD"? Do you realize how unusual it is to forbid suggesting/discussing edits on an article's talk page? —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 sway the discussion.
    I apologize if anyone interpreted any bad faith from my comments.
    When has anyone suggested that you're acting in bad faith? —David Levy 21:46, 9 May 2013 (UTC)
Feedback, you've just removed this summary:
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 Colossal Connection into The Heenan Family." (You did so on the latter's talk page and did not list the discussion at 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 WP:ATD-R, but instead of answering the question you have repeated the contradiction in your point 4 by saying that you want to get rid of the guideline that says that redirection can be performed boldly, but then saying that it can be performed boldly. Don't be surprised that people are confused by what you say when what you say is so blatantly inconsistent. 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. Beeblebrox (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. :) ·Salvidrim!· ✉ 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)

Teahouse for Spanish Wikipedia

I want to create or help to create like a Teahouse but in the Spanish Wikipedia. It sure will help.??? Thoughts?? User:Technical 13 thinks it is a great idea Can anyone help me??...Thanks Miss Bono (zootalk) 14:13, 16 May 2013 (UTC)

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)

Chat box/ Automated Discussion Room

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)

Merging WP:Proposed mergers and WP:ATD-R into Wikipedia:Articles for deletion

I believe it is counter-productive to have three different venues for these discussions. If you believe an article should be deleted, you have to go to WP:AFD. If you believe an article should be merged into another, you have to open a discussion in the destination's talk page and list it at WP:PM. If you believe an article should be replaced with a redirect, the official recommendation is to just do it boldly and then discuss it on the talk page when someone refutes it. Here are my problems with the current system:

  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:PM, or (3) stumble upon the discussion by happenstance. By contrast, 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 WP:ATD-R results in the deletion of an article. The important difference between redirection and deletion is that the former can be performed and reverted by any editor, whereas deletion can only be performed or reverted by an admin, so is a much more drastic move than redirection, and as such is an exception to the normal wiki "anyone can edit" process, so requires much more detailed policy around it. Requiring redirection to go through the same process as deletion would simply result in more unnecessary bureaucracy around it, rather than treating it in the same way as any other normal editing process that anyone can revert. Phil Bridger (talk) 18:38, 13 April 2013 (UTC)

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)

I want to bring you an example. On April 12, I proposed to merge Colossal Connection into The Heenan Family. It's been almost 3 days and no one has yet to comment on the proposal. But after nominating the article for deletion last night, it took just FOUR hours for someone to respond. This is just proof of what I'm trying to get at here. AFD is just more effective than all the other processed because it is extremely popular. We need to take advantage of that so that our merge discussions don't suffer. Feedback ☎ 20:15, 14 April 2013 (UTC)

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 The Funkadactyls article the other day and turned it into a redirect. A rookie editor disagreed, started an edit war, then began a discussion at 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)
  • 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. TheOriginalSoni (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 WP:SCHOOLOUTCOMES redirect, still be WP:BOLDly redirected without taking it to AfD? Michaelzeng7 (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 {{afd-merge to}} and the destination article's talk page (where any necessary organization should occur) with {{afd-merge from}}.
    The solution is to inform such administrators that they're acting inappropriately, not to shift all merger discussions to AfD. —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 bold editing, not unlike removing inappropriate material, adding brand new material, or reformatting an article to improve its flow. All of these are routine revisions, the discussion of which is the reason why article talk pages exist.
    Merger proposals also serve other purposes, of course. They're made by editors who wish to solicit feedback on how to carry out a merger and those who don't feel comfortable doing so themselves. Again, these are normal talk page discussions. They might take a while, and they often require the knowledge of those who've read/edited the relevant sources/articles and are familiar with the subjects and how they relate to each other. Such discussions aren't comparable to deletion debates. As noted above, a merger can't be performed by pushing a button.
    It makes as much sense to send merger discussions to AfD as it does to send cleanup discussions or expansion requests there. Merging is a form of editing, not deletion. —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 {{afd-merge from}} tags describing mergers that never took place (with the source article either surviving or being merged into a more appropriate target).
    Even when "merge" is the correct outcome at AfD, it doesn't bring the process to a tidy conclusion. (We have no "merge" button to press.) Instead of contributing to the backlog of merger proposals, we contribute to the backlog of merger decisions waiting to be acted on, the only material difference being that no helpful input is even being requested (because the decision already has been made — by parties less knowledgeable on the subjects and their relationship).
    User:Feedback noted that a merger proposal generated no response after "almost three days" (not nearly long enough to wait, incidentally), but an AfD listing generated a response within four hours. Well, yeah. Editors spoke up because they saw the article nominated for deletion (an administrative action that most users cannot reverse) and didn't want that to occur. In no way does this help us to perform the proposed merger, which still requires actual editing to carry out. It merely increases the congestion at AfD.
    And routinely handling merger proposals at AfD won't magically generate more participation; it will simply dilute (and overburden) AfD. As I said, it's the possibility of deletion that elicits quick responses. If we change AfD to a forum in which discussions don't necessarily relate to deletion, the community will react accordingly. WP:PM already serves as a central location at which proposed mergers may be advertised. I can't imagine why anyone believes that an "AfD" stamp (with no actual threat of deletion) will somehow send people running to comment. We'll just have a bunch of merger listings clogging AfD (with few generating meaningful input in the week or two before they're closed) — which could have been constructive discussions if they'd been held on the articles' talk pages, with no artificial deadline imposed (thereby enabling knowledgeable parties to participate).
    Imagine treating other content concerns this way. Someone wants to trim, expand, reword or reorganize an article, and instead of discussing it on the talk page, we send them to AfD and demand that a binding decision be reached within a week or two. That isn't much different from what's been proposed above. —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 this AFD which has been relisted twice without attracting any comment. Mergers and redirections are, by contrast, something that may be done by ordinary editing and so do not need concentrating in a special place. Such action blurs with other structural changes to articles such as re-sectioning or sorting and the best place for such discussions is on the talk page(s) of the pages in question. If the discussions are poorly attended then the processes of WP:BRD, WP:RFC and WP:3O may be used to attract attention. So, we have plenty of process already and the problem is a lack of interested editors. Changing the process will not resolve the problem and would make it worse by making AFD even more 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 WP:Proposed merges to begin with, it happens with ordinary discussion on talk pages, a more informal process. This wouldn't prevent that.
    Its section heading notwithstanding, the proposal is for "all the merge and redirect discussions going on talk pages" to be replaced by "merging them all into AFD". As a specific example, the proposer cited a merger discussion not listed at WP:PM.
    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.
    We already have a venue in which all options can be considered: AfD. I don't object to the idea of renaming that forum to make this fact clearer, and I'm not sure that I even object to the elimination of WP:PM. I object to the proposed relocation of all merger discussions to AfD.
    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.
    I wasn't referring to your understanding of Wikipedia or position regarding the proposal. Note that I wrote "possible misunderstanding on my part or yours" (emphasis added), by which I was referring to the possibility that one or both of us misunderstood the other's comments (perhaps leading us to talk past each other). This appears to have been the case. —David Levy 18:08, 20 April 2013 (UTC)
    Note: Via this message, User:Feedback just confirmed that "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." —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 Category:AfD debates where all the discussions were transcluded. We could also consider more closely integrating 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. RayTalk 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 {{afd-merge from}} tags documenting mergers decided upon at AfD but never carried out. —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 WP:NOT) issues, which are the bread-and-butter of AfD. I support this because the "rules of procedure" for AfD already explicitly allow this, or at least can be amended to allow it with little disruption. I admit, this may well apply to the vast majority of proposed merges. But what of the remaining ones? Merges proposed more for stylistic or prosaic concerns, or splits for that matter? Or 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 WP:NOT issues to AfD (even when outright deletion isn't sought).
    But if there isn't an active dispute, this shouldn't be a first-line measure. Unlike deletions, mergers needn't even be proposed. Lacking evidence/suspicion of controversy, editors are encouraged to simply merge articles as they see fit. Even when a merger is instead suggested on the article's talk page, this doesn't necessarily indicate that it's controversial. (It might simply mean that the editor seeks advice on how to carry out the merger or doesn't feel comfortable on a mechanical level.)
    In the case of a notability/WP:NOT-based merger that's contested (either opposed or reverted, with no clear consensus emerging on the talk page), I can understand why an AfD listing might be helpful. —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 WP:PM) to AfD. Some users are supporting the proposal without realizing that. (One stated that AfD "won't be overwhelmed" because "most merger discussions don't really require a community discussion, just agreement on the talk page." Another stated that "to say this would take away the ability to use the article talk page stretches credibility to the breaking point." Both equated the proposal with an earlier one calling for disputed merger requests to optionally be transferred to AfD.) —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 {{afd-merge from}} tags from years ago, describing AfD-determined mergers that have never occurred. Instead of contributing to the backlog of merger proposals, we'll contribute to the backlog of merger decisions waiting to be acted on. The latter is worse; the material difference is that no helpful input is being solicited (because the decision already has been made — by parties less knowledgeable on the subjects and their relationship). —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:BRD cycle. As previously stated by others, any user can perform or revert mergers and splits, and thus do not need admin intervention. Also, a merge discussion can usually take more than the seven-day AFD deadline because content issues need to be resolved. This includes whether it should be a full merge (pasting all or most of the content from the source article to the target page) or a selective merge (selecting only part of the content that should be merged). I disagree with the assumption that by moving all merger discussion to AFD, they will automatically receive more participation and become a better efficient way to "achieve consensus". Again mergers, especially selective merges, are content issues. Many participating in the normal AFD discussions will not know the intricacies of the subject of the articles to judge the 'gray area' of what verifiable content to keep and what to remove, and how to merge all this material in line with WP:BETTER, WP:WIAGA, 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 WP:ATD-R into Wikipedia:Articles for deletion? If you have changed your "official stance" then tell us by striking point 1 of your proposal and replacing it with your changed proposal, but don't accuse me of lying. 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)
    Corwood Industries is an excellent example of where taking the article to AfD was a total waste of editors' time, as it was an obvious case for redirection. Your proposal would produce many more such time-wasting discussions. Phil Bridger (talk) 21:51, 9 May 2013 (UTC)
    That's an outright lie.
    Please assume good faith. If Phil's statement was inaccurate, there's no reason to believe that this was intentional. Oddly, you haven't accused the numerous supporters who've misunderstood your proposal of lying.
    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.
    Like WhatamIdoing, I'm beginning to doubt that you fully grasp the current setup. You're referring to bold mergers (which you don't seek to change) and WP:PM (where outside feedback/assistance is sought). Do you understand that most mergers fall somewhere in-between?
    The mere act of discussing a prospective merger doesn't necessarily mean that it's controversial and requires debate. Very often, it relates more to considerations of how to proceed (e.g. what text to retain and how to integrate it). And even when the question of whether to merge is raised, this isn't materially different from other disagreements about what content to include and how to organize it.
    All of this is ordinary editing, the discussion of which you inexplicably seek to transfer from the relevant articles' talk pages to a separate, time-restricted forum. How, in your view, would this be helpful? Why should merging be divided into "proceed without any discussion" and "file a formal request at AfD"? Do you realize how unusual it is to forbid suggesting/discussing edits on an article's talk page? —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 sway the discussion.
    I apologize if anyone interpreted any bad faith from my comments.
    When has anyone suggested that you're acting in bad faith? —David Levy 21:46, 9 May 2013 (UTC)
Feedback, you've just removed this summary:
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 Colossal Connection into The Heenan Family." (You did so on the latter's talk page and did not list the discussion at 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 WP:ATD-R, but instead of answering the question you have repeated the contradiction in your point 4 by saying that you want to get rid of the guideline that says that redirection can be performed boldly, but then saying that it can be performed boldly. Don't be surprised that people are confused by what you say when what you say is so blatantly inconsistent. 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. Beeblebrox (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. :) ·Salvidrim!· ✉ 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)

Derive a More Colourful Wikipedia in the Future?

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 Toolbox at the Wiki sidebar, then editors could actually use colour in their edits in order to make Wikipedia's webpage(s) to be attractive enough for learning and researching. Basically, majority of the human beings could learn effectively through colours based on quantitative habits. (revised)

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)
    • 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)

Article citations to words ratio filter

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)

Mass removal of old indefinite rangblocks under controlled conditions

There is clear support that there should be a limit to the duration of range blocks. However, a new discussion should be started for clarity to determine just how long that limit should be. Kudpung กุดผึ้ง (talk) 04:40, 25 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.

Adding RFC on this proposal to generate wider input. TheOriginalSoni (talk) 22:28, 22 March 2013 (UTC)

The original discussion for this thread can be found at the VP archives. the original proposal was to restrict all rangeblocks to only checkusers because of the many potentially productive users who get caught in them.

I think the OP's main concern is the number of innocent bystanders who get caught in those rangeblocks, unable to ever return again to editing Wikipedia. I suggest that we can do it by one other way -

  • We unblock every rangeblock which was placed over a year ago (or some other time period as decided) , except the most nefarious of cases. All these recently unblocked users shall fall under a special category where their edits shall be monitored by other willing editors and admins to patrol such high-risk account edits. If the editors shows consistent reasonable good-faith edits over a period of time, admins can remove their names from this category. Editors showing bad-faith or disruptive edits can be indef-blocked again with a nuking of their contributions without warning.

Forgot to sign- So signing late TheOriginalSoni (talk) 07:10, 20 March 2013 (UTC)

Thanks for the suggestion. I appreciate the help. In the 5 years I've been working the issue, the community has never cared enough about good editors being blocked to do anything. It doesn't appear that this time will be any different, but I'd love to be proven wrong. 64.40.54.205 (talk) 12:20, 13 March 2013 (UTC)
Strong support, and I'd be willing to step up to the plate for the monitoring too. Tazerdadog (talk) 20:45, 19 March 2013 (UTC)

Support OriginalSoni's idea. If it's something that I could do for a long time on WP without putting my ass at risk of a block because of incompetence (which it seems like my deletion career is heading down) then i'm sure as anything up for it. MIVP - (Can I Help?) (Maybe a bit of tea for thought?) 22:15, 22 March 2013 (UTC)

  • Support. IP address ranges should never be blocked for such long periods of time, unless they're the most nefarious of cases. Nyttend (talk) 21:44, 24 March 2013 (UTC)
  • Support. A probationary period sounds reasonable. I dislike the idea of indefinite, wide-ranging blocks, and this would make it easier for users to contribute. NinjaRobotPirate (talk) 14:54, 28 March 2013 (UTC)
  • Strong support. I would not be here, commenting on this proposal, if I had not had the opportunity to contribute anonymously. Such permanent rangeblocks probably deter many potentially prolific users, and I strongly believe that they are not in the best interest of Wikipedia. --Mathnerd 101 (talk | contribs) 14:24, 3 April 2013 (UTC)

Bumping thread to stop bot from archival TheOriginalSoni (talk) 07:19, 10 April 2013 (UTC) Unarchiving thread for further discussion TheOriginalSoni (talk) 08:42, 17 April 2013 (UTC)

  • I am not sure I fully understand the details of this proposal, which seems to conflate accounts with IP addresses and ranges, at the same time appearing to recommend renewed indef IP blocks. I would not be in favour of mass-unblocking all the many thousands of open proxies we have range-blocked, which also happen to regularly appear with 'fake' unblock requests, and/or which demonstrably still belong to hosting companies (most of the older range blocks fall into this category and are still nefarious). I would prefer a liberal examination of individual ranges, from a central list say. We can mark which have been reviewed, and unblocked, and it will be easier to track future edits from any unblocked range. -- zzuuzz (talk) 09:59, 17 April 2013 (UTC)
I think I did mix up IP blocks and rangeblocks. My intention was mainly rangeblocks; but I do support a review of the old IP blocks. TheOriginalSoni (talk) 10:10, 17 April 2013 (UTC)
  • Support. No IP block should last more than 5 years, rangeblock or not. You simply can't expect it to stay the same in that time. We should start with blocks issued 5 or more years ago, unblocking everything that passes a proxy check. For those that remain open proxies, they should still be reduced to something like 5 years from today's date. -- King of ♥ ♦ ♣ ♠ 10:03, 17 April 2013 (UTC)
  • Strong support - I think that all IP blocks (range or othewrwise) should be no longer than 2 years except in the case of open proxies (and these should be checked more often than that). This includes CheckUser blocks (to be monitored by CheckUsers) as well as anything else. עוד מישהו Od Mishehu 11:15, 17 April 2013 (UTC)
  • Support - Most vandals that attack WP from IP addresses quickly lose interest in WP and move onto other things. After a year or so, it should be safe to un-block. Leaving block in place may be prohibiting valuable edits from good-faith IP editors. Of course, exceptions can be made for especially problematic situations. --Noleander (talk) 11:54, 17 April 2013 (UTC)
  • Mixed feelings I've dealt with range blocks in the past and the problem is that a heck of a lot of spamming/vandalism comes from specific parts of the world, mostly China (and India as well, but to a lesser extent). For instance, on one of my wikis, I was blocking individual IP's who were spamming from China=based IP addresses at the rate of over three per day, for a good portion of a year until I finally got sick of it and blocked all of China (at which point they started using open proxies instead until I finally blocked those too). I worry that opening up those range blocks might cause some chaos as editors who work on antivandalism try to block individual spamming IP addresses while the spammer is merrily hopping around from IP to IP. I remember years ago I had one editor here from India-based IP's merrily chatting away on different talk pages as he reset his IP literally every minute. Those range blocks were put in place for a reason. Assigning "everyone" to watch for trouble from those IP's may mean that "nobody" is watching for trouble from those IP's. Most antivandalism editors don't know how to start a sock puppet investigation. I agree that old blocks should be lifted, but I think a sudden mass lifting of all old range blocks might cause a fair amount of trouble, and exactly how long is "old" is up for debate as well. Banaticus (talk) 17:55, 19 April 2013 (UTC)
We can get over that issue by making all those editors' edits work something like "Pending Changes" where their edits will be made public only when another editor approves it. All such IP's user pages could have a permanent banner notifying them of the same, and we could have a special category to be monitored for those changes. If any IP in this list shows disruptive behaviour, the rangeblock for that IP is re-added. Additionally, those banners could have one link for vandal-fighters to report them for reban. TheOriginalSoni (talk) 16:09, 20 April 2013 (UTC)
Pending Changes is unlikely to work for this use case. You can't apply it to all edits by a certain IP or user, and thus to work it would have to be used on a lot of pages, which it's not currently according to the guidelines about where it's appropriate to apply it. Steven Walling • talk 17:35, 30 April 2013 (UTC)
I do not have a lot of experience in such proposals, and so if anyone thinks that this proposal should be one of those in the watchlist notices, please get it added. Thank you, TheOriginalSoni (talk) 16:09, 20 April 2013 (UTC)
I've pinged VPT for discussion on how it should be implemented. TheOriginalSoni (talk) 10:04, 7 May 2013 (UTC)
I've requested for a closure of this proposal. TheOriginalSoni (talk) 05:09, 14 May 2013 (UTC)

Unarchiving thread awaiting closure TheOriginalSoni (talk) TheOriginalSoni (talk) 20:18, 22 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.

Developer's Noticeboard

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. ^demon[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)
  • 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 m:GMD going to 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 the Arbitration Committee noticeboard--i.e. announcements on the noticeboard itself, discussions on the talk page--may make it easier to follow and prevent it from duplicating the functionality of 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. Kumioko (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 checkY 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 Wikipedia:Village pump (technical)/Announcements and transclude it to the top of WP:VPT the same way WP:ANRFC is transcluded to the top of WP:AN. That way people can watchlist VPT/A or just look at VPT. But I doubt it will make a difference. 64.40.54.112 (talk) 03:25, 11 May 2013 (UTC)

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)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_102&oldid=1144527046"