The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
My reading of the discussion is that the consensus leans most towards opt-in gadget. There is more support than there is opposition for this change, and while Toshio Yamaguchi's proposal targeted this to new users, several people mentioned wanting this as opt in, and at least one of the opposes' rationales - that the top bar is cluttered - would be mollified by this being opt-in. Yes, the gadgets window is getting cluttered, as one supporter said, but that's a small price to pay for a utility that people want. I recommend to Toshio that if he wants new users to have access to this, that he should investigate methods of introducing new users to gadgets. Perhaps through the welcome messages (which may already have a link? I don't know). Sven ManguardWha?22:45, 12 September 2012 (UTC)[reply]
For convenience and as a help for new editors, I propose to make a new link to the pages in ones userspace that would be displayed at the top of all Wikipedia pages when you are logged in. So instead of seeing
Toshio Yamaguchi My talk My preferences My watchlist My contributions My sandbox Log out
like I do right now, I would see something like
Toshio Yamaguchi My talk My preferences My watchlist My contributions My subpages My sandbox Log out
Given one's sandbox is also one of their subpages, I'd say just replace "my sandbox" with "my subpages". And that certainly would be a useful addition in my mind as well. Resolute22:07, 5 August 2012 (UTC)[reply]
The large majority of registered users have no subpages so I think the link would be unnecessary and confusing for most users if it was displayed for everybody. I don't think MediaWiki can test whether there are any subpages and only display something if there are. We can make a user script to add the link. I don't know much JavaScript but I made a working test. Add the below to Special:MyPage/common.js (for display in all skins) or Special:MyPage/skin.js (for display in your current skin):
importScript('User:PrimeHunter/My subpages.js');
It could also be a gadget in preferences but I'm not sure it's worth it. A long list of gadgets makes it harder to find the important ones. PrimeHunter (talk) 22:48, 5 August 2012 (UTC)[reply]
Actually, this makes me think, it would be great if the toolbox contained a link to all of the subpages of the page you are on. The current process is pretty difficult. RyanVesey22:54, 5 August 2012 (UTC)[reply]
Of course, you can always do a search for "User:Toshio Yamaguchi" and the search bar should autocomplete your subpages in a drop-down menu. That's the approach I usually take. • Jesse V.(talk)02:59, 6 August 2012 (UTC)[reply]
Yes, I know that :) This is mainly targeted at new users, who often might not know this and I see no particular reason to hide the link to the subpages behind a barrier so that you have to click My contributions first. PrimeHunter above said "The large majority of registered users have no subpages". I don't have any statistics, so I can't comment on this. I think the first articles a new user creates are often of a quality insufficient for mainspace, so this could encourage more use of user subpages by new editors and perhaps avoid some Why was my page deleted? questions. -- Toshio Yamaguchi (tlk−ctb) 06:09, 6 August 2012 (UTC)[reply]
There is a small benefit to including it, but the line is meant to be for core functions (userpage, talk, etc) and is already very cluttered, especially for new users. I'm not sure adding a relatively low-use report here is worthwhile. Andrew Gray (talk) 12:08, 7 August 2012 (UTC)[reply]
Support. Add this to gadgets. I also like the idea of a subpages link in the sidebar toolbox menu to find subpages of any page. Add that as a gadget too. There seems to be this phobia about adding more gadgets. I think this is clueless. Anything that helps editors is a good thing. If there is a need to separate higher-value gadgets from lesser-value gadgets (and who judges that?) then create 2 gadget tab pages in preferences. We need to stop this "just say no" naysayer attitude lately on Wikipedia to new ideas. Editors are leaving in droves. Ask yourself why? As for adding either one as a default gadget maybe we can do so after awhile after having it an an optional gadget. There is plenty of room for more stuff in the sidebar especially if we add more menus. Look at all the closed menus in the MediaWiki sidebar. See mw:Main page sidebar. --Timeshifter (talk) 19:06, 8 August 2012 (UTC)[reply]
Note that this proposal is to add this link to those at the top of the page (the "Personal tools" area), not to the sidebar. Also note that adding a second tab of gadgets is not something we can do locally, as it would require a change to the extension code itself. BTW, I doubt editors are "leaving in droves" because of a lack of gadgets. Anomie⚔19:34, 8 August 2012 (UTC)[reply]
They are leaving for many reasons, all of which should be addressed, and not naysayed, or ignored. Ryan Vesey suggested putting a subpages link in the sidebar toolbox menu. I agree. Maybe a table of contents could be added to Special:Preferences#mw-prefsection-gadgets. That would allow more gadgets to be added, and still be able to find them fairly easily. While waiting for the change to mw:Extension:Gadgets to allow more tabs. You are a developer. Maybe you can work on that, or suggest it to others. --Timeshifter (talk) 21:24, 8 August 2012 (UTC)[reply]
Add this to toolbox menu in sidebar. I suggested adding this to gadgets also. But I don't see a reason registered users should not have easy access to their subpages. I could use that myself. So I prefer it in the toolbox, or if that is not possible due to all the naysayers on Wikipedia lately, then add this to gadgets. A gadget that puts it in the toolbox, or on the top of the page. Why is there this phobia against making life easier for editors? --Timeshifter (talk) 05:24, 16 August 2012 (UTC)[reply]
Support - there should be an easily accessible link to 'my subpages' somewhere, and at the moment there isn't. I don't particularly mind if it goes in the top bar or on the sidebar, but we should add it somewhere. Robofish (talk) 13:59, 16 August 2012 (UTC)[reply]
Comment I've been away and was pleasantly surprised to see a link to "my sandbox". This is wonderful and should have been done long ago. New users boldly experiment w/ articles and get told to experiment in the sandbox. Now they have a clear link to a place for experimentation. Dlohcierekim04:10, 22 August 2012 (UTC)[reply]
Oppose. The number of people this would benefit is far outweighed by those it would only confuse and those for whom it would simply have no use, as most do not use many subpages, and the gadgets list is already quite cluttered. Barring adding it as an option to an existing tool, this sort of thing is best imported instead to personal js for those with the knowhow to know what it means. As for those of you saying you would support a sidebar link, the sidebar is for general project stuff. That page-specific stuff was added to the toolbox is unfortunate, as it adds to the confusion of the interface when in vector there is also a dropdown in the page tools specifically for more page tools, but it does not mean that user-specific personal stuff might as well be added as well when there is also a toolbar specifically for that at the top right of the page. -— Isarra༆16:47, 7 September 2012 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I think both of these are high value links that a new or even a veteran editor would find useful. The only negative I can think of would be an increased workload for the Article creation/New page patrollers. Kumioko (talk) 11:13, 8 August 2012 (UTC)[reply]
Support Teahouse link in Interaction menu. Editors are leaving in droves. Anything that attracts and assimilates more editors, especially women, is a good thing. There is plenty of room for more stuff in the sidebar especially if we add more menus. Look at all the closed menus in the MediaWiki sidebar. See mw:Main page sidebar. "Assimilation is the process by which the BorgWikipedia integrate beings and cultures into their collective." ;) I also support putting a search link in the sidebar. In the meantime I have to use this JavaScript import gadget. --Timeshifter (talk) 21:15, 8 August 2012 (UTC)[reply]
Very strong support When I work with new editors, two of the most common questions I get are "How do I create an article?" and "How do I get help from experienced editors?". This would help fix that. David1217What I've done17:04, 11 August 2012 (UTC)[reply]
Comment I'm supportive of both these additions. Article creation wizard is self-explanatory, but I'm wondering if new users will know that Teahouse is a place to get help. 64.40.54.58 (talk) 14:06, 12 August 2012 (UTC)[reply]
Reservations: To quote: two of the most common questions I get are "How do I create an article?" and "How do I get help from experienced editors?".
Article creation was left out of the sidebar in the past, because we didn't want more cruft that we needed to instantly delete again. I agree however that it is one of the most common issues that new users are faced with. Perhaps however, it would be wise to redo part of that first page of the ACW again, because it already looks 'polluted' again with rules and tips. If needed, make step 1 an click trough tutorial of 4 pages with a bit more tasks. Line one should be: "Become an editor before you become an article author" :D
I'm all for the Teahouse, but seriously, how will people get there any better by a sidebar link (Why would you ever click on something named 'teahouse' if you need help). In my opinion, clean out Help:Contents or create a new Help:Welcome or a Help:Your first steps and if need be make the Help link a bit more prominent by moving it into section 1. —TheDJ (talk • contribs) 13:07, 13 August 2012 (UTC)[reply]
A lot of editors, even relatively active ones don't know what the Teahouse is or what its for. I receive Email's periodically asking about it form people who don't want to look, as a couple have said, "Stupid" by posting to a WP Talk page. Since I get one or 2 a week, it seemed like a problem that could easily be addressed with a link. Essentially as was said above 2 of the common questions are where can I find help and how do I make an article. These should be prominantly displayed without forcing the users to dig for it. Lets be honest, if you don't know what the Teahouse is, you probably aren't going to search for it. Additionally, with our new search filters to prevent Google from displaying non article stuff, in order to find them accurately you have to search for them by Namespace and a lot of folks won't know that. Frankly I would like to include a link to the User page creation wizard too but I knew that would never pass so I didn't try. Kumioko (talk) 14:13, 13 August 2012 (UTC)[reply]
That's not what I meant. You are confusing problem and solution. Your problem is that people can't find a good place to be helped. Your solution is to add a new link. I'm saying that what is behind the current links is probably the problem and that changing the content there might be a better solution. If i'm gonna look for help, i'll click Help. If that lands me at Help:Contents, then in all honesty, I think I'd get lost. So instead of adding more information (By adding a link to every page), consider creating better user guidance behind the current targets. So perhaps we should change the Help link in the side bar to point to a new help system that is better at getting people where they need to be, instead of dumping them in the index of an incomplete and confusing book. One of the first items of that guide might very well be 'Visit our Teahouse, where fellow editors will help you with any problem you have in a friendly and welcoming atmosphere." —TheDJ (talk • contribs) 17:22, 13 August 2012 (UTC)[reply]
With respect I am just trying to find a relatively low impact solution to a problem. Yes there are many problems that need to be fixed and you bring up some excellent points but using the case in point, if we meet such opposition to adding a link, how much are we going to see doing a major revamp of Help as you suggest? Kumioko (talk) 17:40, 13 August 2012 (UTC)[reply]
At the 'it will stare everyone in the face'-level, you will find much more opposition than one level down, no matter what you propose. I think a Help revamp would be much less controversial than you think, IF you put in the time to build it right and don't launch it too early. —TheDJ (talk • contribs) 19:43, 13 August 2012 (UTC)[reply]
These days I think it would have more success coming from someone else but me. With my recent history if I said cats meow someone would argue they purr. You may be right that it could get more support but I don't think the community would support much with my name associated to it at this point. Kumioko (talk) 20:01, 13 August 2012 (UTC)[reply]
I don't know if this will cheer you up, but for what its worth, there is a project that wants to take on improvements to Help:Contents, so maybe we'll see some movement in that direction sooner than you think! Agree it would be great to make it easier for new editors to find the help they're looking for, Teahouse included, where this is appropriate in the interface. Siko (talk) 20:56, 13 August 2012 (UTC)[reply]
That's great news but if the links are buried in Wikipedia and are not easily accessible to people then we are not advocating their use. We frequent editors know where to go, but the casual editors and the folks who don't edit all the time do not, nor should they be expected to know that they need to go digging for help. I would also say that I am perfectly fine with the decision not to put these links on the side menu but IMO if that decision is based on the premise that we are going to make more work for ourselves and we don't want more work, then that is a very wrong reason. Kumioko (talk) 21:22, 13 August 2012 (UTC)[reply]
Comment There is the concern of the Teahouse being flooded with reference questions and so forth. While we surely need more questions and we're here to serve as a space where people ask questions about CONTRIBUTING and EDITING, I fear that there could be a flood of IP's coming by and our hosts will be burdened with questions that they didn't sign up to answer, so to say. SarahStierch (talk) 17:58, 13 August 2012 (UTC)[reply]
I've just spent five minutes thinking about this, and finally worked out that by reference questions you mean questions of the form "my plane tickets haven't arrived yet, where is your local office located?". Yes, there would very likely be a large influx of such questions. --Demiurge1000 (talk) 11:09, 14 August 2012 (UTC)[reply]
Oppose AFC is the only option for IP editors, but logged in editors have a better chance creating articles in mainspace where they belong and where others might help them improve them. And the Teahouse is for newly registered editors - so not appropriate for the sidebar. ϢereSpielChequers18:32, 13 August 2012 (UTC)[reply]
Fwiw, there is a strong desire and ongoing project, to overhaul and update as much of the Help system as possible. It's ongoing in various places, but Wikipedia:Help Project is attempting to provide a focus and center for the works. -- Quiddity (talk) 01:13, 14 August 2012 (UTC)[reply]
Comment. Support Help:Contents and Help:Teahouse in sidebar. "Teahouse" implies a more social help community. "Help:Contents" sounds like the more typical impersonal help pages people are used to on many websites. My proposal for moderators was a first attempt to help resolve content disputes in a more authoritative, but more cooperative way. Wikipedia is sorely lacking in cooperation of a more social, friendly nature. 90% (I believe) of editors and admins are male, and the common consensus of many people is that Wikipedia is a fanboy clique with a strong off-putting groupthink. "Teahouse", like salon, is understood by feminists and cooperative people in general. So they will click the link. It is the Facebook effect. Or Wikipedia can continue to live in the past if it wants to, and naysay most new ideas, per kneejerk normal at the Village Pumps. --Timeshifter (talk) 02:11, 14 August 2012 (UTC)[reply]
Question - as a Help Desk regular, I have to ask why not also a direct link to that page. We get far more questions there than the Teahouse does.--ukexpat (talk) 13:02, 14 August 2012 (UTC)[reply]
Support, these pages need to be seen by new editors. They all have these two questions and this should help solve that. Swordman97 (talk)
Just a thought but why don't we add the Article creation wizard under interacton, create a new group entirely for Help, move the existing Help from interaction to the new Help group along with links to the Help desk, Help:Contents and Help:Teahouse? Kumioko (talk) 20:28, 14 August 2012 (UTC)[reply]
An interesting proposal, but much larger scope than the current thread-topic encompasses. I'd recommend looking over here (WP:Village pump (proposals)/Sidebar redesign) for old code-to-copy (and old discussions to skim through), and making up a clear demo of all the changes you suggest, and starting a new thread in a few days. -- Quiddity (talk) 22:03, 14 August 2012 (UTC)[reply]
Comment My concern is that it's hard to make clear what the Teahouse is for in the limited space available, and that it will likely result in a large influx of misplaced questions. Note that links in the sidebar do get a huge amount of traffic:
I'm worried that the Teahouse, which is supposed to be a calm and personal experience, will simply be overwhelmed. Perhaps Wikipedia:Questions would be a more suitable addition to the sidebar, with the title "Questions" or "Ask a question". It does allow us to highlight the Reference Desk a bit more too, which I do think more readers should know about. Or does it overlap too much with Contact Wikipedia?
As for Help, as Siko mentioned above I'm going to be proposing a major redesign of this page in the next few weeks. Nothing's finalised yet, but I can definitely say that both the Teahouse and Article Creation Wizard will feature prominently there. the wub"?!"22:45, 14 August 2012 (UTC)[reply]
That's fine. I had just suggested adding a couple links I thought would be non-contentious and easily done. I don't have the desire or energy these days to get embroiled into another major contentious food fight. For what its worth though if we create these things like the Teahouse and the ACW then we should advocate their use not bury them in the site so only those that are familiar with the site know about them. It defeats their purpose. If we are going to be worried about making more work for ourselves then we shouldn't even start. It defeats the purpose of the pedia IMO. Kumioko (talk) 23:25, 14 August 2012 (UTC)[reply]
Your idea, Kumioko, of a separate help menu could address some of wub's concerns too. People can choose the help method they prefer: Help:Contents, Help:Teahouse, Help desk, Wikipedia:Questions. Additional menus are a good way to help people navigate. Look at MediaWiki.org's sidebar. Its sidebar menus are directed at their audience, of course, but it illustrates the usefulness of more menus. Wikipedia's menus would focus on Wikipedia's readers and editors. --Timeshifter (talk) 05:09, 15 August 2012 (UTC)[reply]
Oppose both. Unnecessary clutter that would not be used by the majority. Also, there are any number of ways that an article can be created, and if an editor wants to use a particular method they can bookmark it on their computer. As for the Teahouse I am unsure how useful it is for the project and since it is not high usage a generic link is not required. -- Alan Liefting (talk - contribs) 02:17, 19 August 2012 (UTC)[reply]
Support Teahouse, oppose Article creation wizard. The Teahouse has proven to be very effective for new editors, who often use the sidebar to try and find a place to get help. My reservation about the article creation wizard is that it is essentially a choose your own adventure where most of the options end in death. By which I mean, it is rather designed to discourage the kinds of articles we don't want, instead of help people. It's the kind of resource we should only send someone to if they have no idea if the article they want to start is a suitable topic or not. Steven Walling • talk00:43, 3 September 2012 (UTC)[reply]
Oppose both - AfC has very specific uses, which doesn't really merit advertising it on the sidebar, and there's also just too much stuff there already anyway. If the help link that is currently there isn't getting folks to the right place, that is a problem with the help link currently there which will not be solved by adding more stuff under it, though it would make the sidebar that much more daunting. -— Isarra༆08:39, 4 September 2012 (UTC)[reply]
Main objection: because Introduction is just as likely (or more so, arguably). Additionally, the Help Project is in the midst of overhauling our collection of tutorials (eg see Help:Introduction to referencing/1 which is brand new, and shows the sidelink-style layout that is planned for future updates elsewhere. (instead of the current Top-tab style, which is confusing for a number of reasons)) —Quiddity (talk) 03:10, 9 September 2012 (UTC)[reply]
"Actually, maybe there should be a button, that when you click 'Move', that it says 'Hey, do you think this might be controversial?' 'Yes' 'Thank you, we've made the request for you and everything's done.'"
— Jimmy Wales, Closing speech, Wikimania 2011
The current process for proposing page moves is for the proposer to subst the Requested move template onto the article's talk page. A bot then adds the request to the list at WP:Requested moves. Unfortunately, instructions on how to request a move are hard to find, and many users, even experienced users, might have difficulty placing a move request because of this. I've put together a script at User:Yair rand/ControversialMoves.js which adds a checkbox to the "Move" page, with the text "Do you think this move might be controversial?" next to it. Once checked, the "Move page" button changes to a "Propose moving the page" button, and when submitted, it substs the proper template onto the talk page, adds the text entered into the "Reason" box below it, and adds a signature onto the end. The script itself (as well as maybe the details of implementation) probably need some work, but what do people think of the general idea? I think that we really should be cracking down on unnecessary complexities in getting things done on Wikipedia, and the page move proposing process seems to me like a classic example of an area where things are too complicated, without reason for them to be. --Yair rand (talk) 04:52, 14 August 2012 (UTC)[reply]
Comment There is a move tool already on Commons that actually takes care of all steps, even for anonymous users. I'd support a default gadget like that in a heartbeat. —TheDJ (talk • contribs) 11:55, 14 August 2012 (UTC)[reply]
Huh, I didn't know about that gadget. It's very well done. However, the situation is rather different here on Wikipedia. On Commons, requesting a move is about getting a file mover or admin to perform the action, with one of seven simple reasons given, as opposed to on Wikipedia, where making a request is about inviting discussion on a potentially controversial issue (otherwise it would either be just moved or sent to WP:RM/TR), so I'm not sure how much could be borrowed from the Commons gadget. --Yair rand (talk) 03:09, 15 August 2012 (UTC)[reply]
Support. This is moving in the right direction. Something that has a similar functionality for merge and copy would also be great. Every time I have to look up the procedures and relearn the whole process, and I am never sure I am getting it right. • • • Peter (Southwood)(talk): 13:48, 14 August 2012 (UTC)[reply]
Support The RM process is very confusing as is, especially with the auto-listing feature currently being broken. A simple solution like this would make everyone's life a whole lot easier. Cheers, Zaldax (talk) 19:37, 20 August 2012 (UTC)[reply]
Support. On the evidence, the backlog at RM is a pretty clear indication that the current system needs all the improvements to efficiency that we can give it. --Tryptofish (talk) 19:47, 20 August 2012 (UTC)[reply]
Good idea, however, before we do it, consider that if it works, we're likely to get a deluge of flaky RMs, because lots more people will not be dissuaded. So maybe we can take the opportunity to add some coaching, with links to WP:AT and WP:MOS and suggest that people look at relevant sections before proposing a move. Maybe have a list of reasons for moves, with more specific links on each? Like change capitalization, change punctuation (hyphen, dash, apostrophe), add parenthetical, remove parenthetical, add diacriticals, remove diacriticals, make primarytopic claim, make more precise, make more concise, make more recognizable, etc. Or we could make the script smart enough to compare the titles, suggest what the reason must be, and link to the explanation about it, and suggest a look. Dicklyon (talk) 03:36, 21 August 2012 (UTC)[reply]
So it looks like there's support for the idea. Any opinions on the specifics of implementation? Two issues are: whether to keep the move page as a separate page or have it as a popup like the Commons gadget, and what to do for move-protected pages/non-logged-in users. --Yair rand (talk) 07:13, 28 August 2012 (UTC)[reply]
Thanks, I think keeping the special move page as a separate page works well as it gives editors plenty of opportunity to review their options, and this avoids making too many changes to procedure at once.
Ideally any technical moves such as move-protected pages/non-logged-in users would go straight to showing the "Propose moving the page" button, with admins only being given an option of a "move" button.
Don't know if there could be some way of extending this to cases where there's an existing article at the target. Perhaps that would be covered by changing the wording to match WP:RM/TR with text along the lines of "Is there already an article at the target title, or do you think this move might be controversial?" Alternatively, another checkbox could be added for "Is there already an article at the target title?" which would have the same effect of bringing up the "Propose moving the page" button. . . dave souza, talk10:32, 3 September 2012 (UTC)[reply]
Another option might be to just have it automatically check whether an article already exists at the target title, and have it change the button if there is. --Yair rand (talk) 22:12, 9 September 2012 (UTC)[reply]
An automatic reminder or alert would be good, but how would it cope with a situation where the move is ok under WP:MOR as the target is a redirect with just one line in its edit history? If the button changed automatically to a "Propose moving the page" button, there would have to be a way to actually move the page: I suppose that would limit such moves to admins who can delete the target page. . . dave souza, talk20:21, 11 September 2012 (UTC)[reply]
Ask for an edit summary when rollback in used from watchlist
I've noticed a big difference in the way rollback acts between your watchlist and when viewing a diff. In the latter case, it asks for an edit summary and there is an 'ok' and 'cancel' button, effectively given you an opportunity to stop the rollback. The former does not provide this prompt - it just goes. Often this can lead to frustration, accusations, and general bad faith assumptions.
I don't figure this needs support of the community, but I figured its best to have this formal discussion just for future referencing.
I'd like to propose that:
A) The watchlist rollback be adjusted to act like the diff rollback
B) That both highlight 'cancel' by default in the prompt, providing another level of protection from misclicks or misenters.
I just get "Rollback successful" either way - and that's the way I want it, if I'm using rollback I want to spend as little energy as possible reverting vandalism. Maybe you have a custom gadget or script running? Franamax (talk) 17:38, 18 August 2012 (UTC)[reply]
(Thanks, Franamax, for any old edit.) I'm not noticing a difference on server rollback. Twinkle rollback, however, presents an edit summary box when you click that one. elektrikSHOOS (talk) 17:59, 18 August 2012 (UTC)[reply]
I don't know about anyone else, but I've never intentionally used the rollback link from my watchlist. The times I've wanted raw rollback have all been from user contribution pages, for the vast majority of vandalism reversion I prefer at least a generic vandalism removal summary. That said, if someone is clicking on a an raw rollback link for some reason, it should respond the same everywhere, which by default is to roll back without further inquiry. What may be a good idea would be to educate editors about the .css code to remove rollback links from their watch lists, and maybe adding it to a preferences menu. — Preceding unsigned comment added by Monty845 (talk • contribs) 04:30, 19 August 2012
OpposeVandalism is pretty obvious. Can't imagine an edit summary needed for the stuff that I have rollbacked. I am very conservative about it but curses and filthy language do not need an explanation. Vandalism seems to explain it well enough. Actually it is self-explanatory.Mugginsx (talk) 22:36, 23 August 2012 (UTC)[reply]
You've sidestepped the issue being raised here. It's not about needing an edit summary to explain the rollback; it's about adding a prompt so that when you accidentally click rollback, you aren't rushing to revert yourself before getting mugged by the community.
Oppose - I know LTA when I see it, even when just seeing it on my watchlist. Whenever an edit summary is needed, Rollback is not used, plain and simple.--Jasper Deng(talk)22:47, 23 August 2012 (UTC)[reply]
You've completely sidestepped the point here and likely voted based on the header of this section. In either case it needs to be removed from the watchlist. No rollback should be performed without checking an edit anyways, and all too often it bounces around as your watchlist loads and gets clicked on, instantly rolling back without any check. - Floydianτ¢14:48, 24 August 2012 (UTC)[reply]
I'm sorry but I also have to oppose that. I don't need annoying prompts wasting my time especially when I have LTA. If this becomes a feature it must allow an opt-out for me.--Jasper Deng(talk)23:58, 24 August 2012 (UTC)[reply]
Oppose. Rollback is designed as a tool for cleaning up clear and/or large-quantity abuse or vandalism. Adding the option for an edit summary changes the tool. If I need an edit summary, I just use the undo button if it's one edit to revert or the edit button from a comparative view to revert several edits at once, like I did here. —C.Fred (talk) 14:38, 24 August 2012 (UTC)[reply]
And if you don't notice that you accidentally clicked it, you're chastised. I know it is designed for vandalism, but its placement at the end of an entry in the watchlist makes it very susceptible to moving around as the page loads. - Floydianτ¢14:48, 24 August 2012 (UTC)[reply]
That sounds like a problem with the js used on the watchlist, although from what I understand someone recently committed a fix for at least some of the problematicness there. As for accidental clickings, just explaining that it was an accident should be enough; such happens, and given the thing on this project about assuming good faith, folks shouldn't be jumping to the chastising in the first place, so that likewise seems more their problem than one with the tool. Or am I mixing this up with a less habitually backstabbing project? -— Isarra༆17:06, 7 September 2012 (UTC)[reply]
Decided to voice a formal oppose. Server rollback is designed to be a quck, one-step action. That's why it's only supposed to be used in certain ways, and is only given to trustworthy editors who ask for it. If you would like the option of adding an edit summary, use Twinkle instead, which can perform more or less the same way (albeit implemented slightly differently) or undoing the edit manually. In response to the watchlist concerns above, there do exist cases where rolling back directly from the watchlist is acceptable, such as obviously vandalistic edits like page blanking or repeated vandalistic edits from the same editor. elektrikSHOOS (talk) 15:01, 24 August 2012 (UTC)[reply]
As I noted in my testing above, the rollback button in your watchlist functions identically to the rollback button in a diff, so I'm also not entirely sure what you're intending this proposal to address, either. elektrikSHOOS (talk) 15:04, 24 August 2012 (UTC)[reply]
I suppose the Twinkle one is the one that does it properly. Again, if you aren't checking the edit, you shouldn't be rolling back - Why does it exist on the watchlist? The point, again, is not about wanting to add an edit summary, but to not have a series of edits performed without even a simple "You are about to rollback X edits. Continue?". Perhaps I'd like an opt-in to the link on the watchlist... - Floydianτ¢00:07, 25 August 2012 (UTC)[reply]
You're kind of missing the whole point of rollback, though - it's designed to be used in situations where speed is more important than leaving an edit summary and explaining yourself. This has been well established by years of consensus to be an acceptable response to certain edits. By prompting the user to leave an edit summary, you essentially turn it into the undo button, which defeats the purpose of its existence. (Also, just a helpful reminder to you, you can hide the rollback button from appearing on your watchlist by adding .page-Special_Watchlist .mw-rollback-link {display:none;} to your vector.css page.) elektrikSHOOS (talk) 00:14, 25 August 2012 (UTC)[reply]
Strong support - This would be a great boon to touch pad/screen users. For those who oppose, would you support if there was an option in preferences to turn edit summary prompt back off (though with the default set to on)? There are many ways to implement this if adding preferences. Such as having preferences for: whether the link should or should not show on the watchlist; whether there should be an edit summary prompt when clicked on from the watchlist (or recent changes, for that matter), etc. I would think that this would be the best of all worlds. And I think edit summary usage should default to on, both for several of the reasons already noted, and because only experienced rollbackers should be rolling back with no edit summary. And doing so would only be a quick trip to preferences. - jc3720:32, 29 August 2012 (UTC)[reply]
I would prefer to have default off as I don't believe the majority of admins and rollbackers use a mobile device. In your situation, it's already possible to turn it off with a CSS trick.--Jasper Deng(talk)00:45, 30 August 2012 (UTC)[reply]
Oppose - Rollback is the most straightforward way to revert nonconstructive edits. If you need to ask for an edit summary, it isn't so straight forward anymore. There's always undo, Twinkle and of course, manual reversion. Michaelzeng7 (talk) 20:56, 15 September 2012 (UTC)[reply]
Renaming of "Featured" to differentiate icon with quality-level
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
I'm closing this RfC per a WP:AN request. The result of the discussion is that there is no consensus to call featured articles something other than "featured", with about two thirds of commentators opposed to such a change. Sandstein 07:43, 13 September 2012 (UTC)[reply]
Okay, now before the vultures start attacking, here's my reasoning:
Sorry.... in retrospect that was rather a strong opening, and I am sorry if anyone took offense to it. This proposal was not created to rustle anyone's feathers, and I hope is not seen as some random outsider trying to come in from nowhere and try to dictate how the Featured projects should be run. My aim was to bring up a healthy discussion on a topic that I don't think has ever been brought up before. Something that I have personally found to be a major pet peeve and wanted to gauge the public opinion surrounding this issue to, indeed, work out of it is an issue at all. My reasoning is below.
"Featured" implies that the article has achieved this status by being prominently place somewhere (in Wikipedia's case, on the main page).
There may be some vague link between exceptional article quality and an article being featured on the main page, but without anything like "our best work" above the FA text on the main page, we cannot assume our readers will pick up on this. They may very well assume it to be 'another' DYK that just got picked out from the bunch.
It certainly was a huge shock to me when I found out that you could have articles at 'featured article status' that had never been featured on the main page - because FA is actually a level of article quality, not a symbol of being featured on the main page
[If I am wrong up to this point, please let me know. This is what I understand after some investigation into the matter]
So, I suggest we rename the featured article status to, for example, "great article" or "excellent article", or "best article" or something like that to then make it obvious that we are talking about levels of quality here.
Then when the star is added, it is simply a badge of honour to recognise that the article has also been featured on the main page at least once throughout its lifetime.
One consequence of this decision would be that Wikipedia:Featured article candidates will be renamed to Wikipedia:________ article candidates. Perhaps a new forum, specifically designed for setting up a calender for FAs of the day can be set up. Perhaps one is already set up that I don't know about) Then TFA can pretty much stay as is.
This is here to spark intelligent debate over this matter. Please do not shut it down with a policy shortcut, or with an attitude of "its too hard" or "its too complicated" etc. (without a proper argument to support your view)
Support in principle, but only if a better name can be found. I agree that "Featured" is not optimal, but so far have not seen a better alternative suggested. Oppose objections based on traditional usage, there is enough inertia on Wikipedia without institutionalising it. • • • Peter (Southwood)(talk): 10:25, 20 August 2012 (UTC)[reply]
Exemplary is the best so far, as suggesting that the article is a good example to be followed, but I am not convinced that it is much better than Featured. Most of the others are over the top. • • • Peter (Southwood)(talk): 09:34, 22 August 2012 (UTC)[reply]
Support at least discussing the idea, and my suggestion would be something like exceptional, as that meaning accurately describes such articles as both "rare" and "superior". —Torchiesttalkedits15:46, 20 August 2012 (UTC)[reply]
Strongly support Renaming - I'd be fine with "Article of quality" or "Quality article", based directly from the term already used by assessment. I'd also be fine with "exceptional" or even "noteworthy" as well. I strongly oppose words like "good/better/best/great/excellent/top/awesome/supreme/perfect/etc." as too subjective, and giving too much the impression of finality or being completed/"done". - jc3719:22, 20 August 2012 (UTC)[reply]
Support I find the adjective featured to be a misnomer. The articles are not noted for their prominence, but rather their quality. I'd be in favor of a high quality/quality for FA/GA or calling these exemplary articles, which is what they truly are.--TonyTheTiger (T/C/BIO/WP:CHICAGO/WP:FOUR) 21:58, 20 August 2012 (UTC)[reply]
Theoretically, if we rename featured to exemplary, and then rename start to D level, then we can have the ABCDEFG - or Alphabet quality system (A, B, C, D, Exemplary, Featured, Good) - sounds rather catchy! :D--Coin945 (talk) 06:12, 21 August 2012 (UTC)[reply]
Oppose – I'm just not seeing a problem with the use of the word 'Featured'. In part it's preferable for being a relative term, rather than an absolute like "Great" or "Excellent". For the latter form to be meaningful, you really need to hold a review by a body that is independent of Wikipedia. Sorry. RJH (talk) 03:34, 20 August 2012 (UTC)[reply]
Per the Wiktionary, the verb 'feature' means to "ascribe the greatest importance to something within a certain context". Kind of what we're doing. Front page appearance is an additional outcome that many editors seem to appreciate; not everybody does, however. Regards, RJH (talk) 18:19, 19 August 2012 (UTC)[reply]
I understand the prestige that comes with having your article on the main page. My point is that if nobody understands that your page has been chosen because of its exceptional quality, then it's a bit of a waste. I think this is a two-pronged attack. Rename FA to something else to differentiate being top-notch quality and being featured on the main page, and then make it clear that we only "feature" something on the main page if it is top-notch quality. The consequence of this is that we will also be able to feature good article (I rememeber reading a discussion about this somewhere - people wanting to allow Good Articles to be featured on the main page).--Coin945 (talk) 00:58, 20 August 2012 (UTC)[reply]
Oppose Featured articles have always (or basically always) been around here. I mean, the whole process (criteria, FAC, FAR, etc), not the articles themselves. A change like this would break a very long standing tradition, and would force to rename or modify hundreds of pages, along with interwikis, and to fix several templates to keep it all working... and for which gain? If a change gives more problems than solutions, or give big problems while not solving anyone (we may like it, or not, or just take it as it is, but there's not really a "problem" with the current name), then it's better to be conservative. There's no need to change for the mere sake of changing. Cambalachero (talk) 04:02, 20 August 2012 (UTC)[reply]
Oppose - Agree with the concerns by Cambalachero, a change would break a long standing tradition and could force the rename or modify several pages and fix several templates. As such, there's no need to change it just for the sake of changing. Lord Sjones23 (talk - contributions) 04:19, 20 August 2012 (UTC)[reply]
Oppose - a traditional name - fitting or not - is THE NAME. Perhaps explain what it means more often, - I remember that it came up when I was welcomed to Wikipedia and I had NO IDEA what that meant, --Gerda Arendt (talk) 07:44, 20 August 2012 (UTC)[reply]
I disagree... I don't like the idea of sticking with a bad idea just because of traditional reasons. It's a very outdated idea. I thought that in the 21st century, we'd decided that if we hind a better solution to a problem, the only logical choice would be to switch. Isn't that what evolution is? Resistance to change due to tradition is a very silly idea imo. --Coin945 (talk) 10:02, 20 August 2012 (UTC)[reply]
"Very silly idea", a featured phrase! You got me wrong: I am not against changing structures and procedures, rather the opposite ;) But why change a name? Would you change yours to Bill because Coin might seem too small? Of the suggestions below, I don't prefer any to what we have. "Great article" would share GA with Good article, not a great idea. - Did you ask the people who run FA and TFA what they think? --Gerda Arendt (talk) 16:54, 20 August 2012 (UTC)[reply]
The main point of the proposal was to gauge the public opinion, before we went ahead with something bigger. However, you are right. It probably is time to link the FA and TFA pages here since there seems to be some momentum.--Coin945 (talk) 06:10, 21 August 2012 (UTC)[reply]
Ps: "featured" is more neutral than the alternative suggestions, FAs are of different quality, some 6-year-old ones would not meet today's high standards --Gerda Arendt (talk) 07:48, 20 August 2012 (UTC)[reply]
Just on that last point, how would it be any different to the rest of the naming system? Good article - what does that even mean...? If we were trying to creating a new type of article called good article here in 2012, the entire discussion would be filled up with arguments of "how do you define good" etc. Featured may be a more neutral word, but it is completely misleading and frankly, very confusing. And the last part of your sentence proves my point exactly. Yes, articles that have been featured on the main page, both past and rpesent, are of very different qualities. This way having a featured article star does not insinuate any sort of quality, but instead merely points out that the article has been featured on the main page.--Coin945 (talk) 09:58, 20 August 2012 (UTC)[reply]
Oppose. All the supporting arguments so far would apply equally to renaming the Olympic medals. There's nothing actually "golden" about a 1st place finish. Renaming the Olympic medals would be a bad idea, for the obvious reasons, and those reasons apply equally to the idea of renaming any Featured content. - Dank (push to talk) 16:32, 20 August 2012 (UTC)[reply]
Oppose this is pain for no gain. Per RJH (above), the word "featured" is perfectly cromulant here. An article is "featured" on the Wikipedia:Featured articles page. A subset of FA's become TFA's (Today's Featured Article) which are on the front page - and that process often involves what amounts to another review stage (over and above WP:FA) at WP:TFAR. I agree that it used to be that every FA wound up being TFA - but since the rate of FA creation is now slightly more than one per day - that's no longer possible. But the articles are all featured somewhere - so the name is still applicable. Going through and renaming every occurrence of "FA" to whatever this proposal would require is an arduous and unnecessary task. There are better things for busy people to be doing than this. SteveBaker (talk) 16:38, 20 August 2012 (UTC)[reply]
Oppose. The term "Featured Article" is ingrained within the Wikipedia community. It should not be renamed unless there is a very good reason to change it. I'll admit, it's a little vague, but changing it now could confuse new users even more. I may change my mind if someone suggests an exceptionally brilliant replacement.--SGCM(talk)21:48, 20 August 2012 (UTC)[reply]
Oppose—FAs are featured on Wikipedia:Featured articles, which is prominently linked from the bottom of the TFA space on the Main Page. Any renaming of FAs would also have to include the Featured Lists, Featured Topics, Featured Pictures, Featured Sounds and Featured Portals, all of which are featured in their own places of honor, and only some of which are included on the Main Page. You can't discuss renaming one of the six types of Featured Content without equally discussing them all. Imzadi 1979→22:24, 20 August 2012 (UTC)[reply]
There was consensus to add Featured Sounds to the Main Page when Features Lists were added. However, the FS process has shut down. There has never been a proposal that's gained consensus to add the Featured Topics or Featured Portals to the Main Page.
Then, perhaps that is where we should be heading as well. Especially considering that newbies (sorry, I extrapolate from my own personal experiences), have no idea what either are, and will feature much "featured" content that never gets the recognition is deserves.... e.g. what are featured topic creators aimng for? Self-satisfation? Working to complete a Wikiproject task force? NO reward at the end of all their hard work? Why not a main page spot?!! :D--Coin945 (talk) 04:51, 23 August 2012 (UTC)[reply]
Again though, "Featured" in this context doesn't mean "Featured on the Main Page"; all of the types of Featured Content are listed on their corresponding lists, featuring them there instead. Imzadi 1979→06:59, 21 August 2012 (UTC)[reply]
Because it is an established name with recognition and a long history, used across 6 projects (Featured pics, etc). Because it would be a ton of work, and for what? Because you don't care for the name. I'm not seeing the point, frankly. KillerChihuahua?!?13:52, 21 August 2012 (UTC)[reply]
Oppose There is no name that would accurately convey exactly what an FA is, and there is no reason to change from a word that a lot of people understand. Johnuniq (talk) 10:45, 22 August 2012 (UTC)[reply]
Oppose, unless someone comes up with a really good alternative. The OP and the people supporting this don't seem to understand what Featured Articles actually are. FAs aren't of "exceptional article quality"; aren't "the best of Wikipedia"; aren't "exemplary"; aren't "noteworthy"; aren't "prime". The FA process measures onlywhether an article complies with Wikipedia's arbitrary set of style guidelines, provides a reasonably comprehensive view of the topic, and is fully and accurately cited. There are some articles which undoubtedly meet the FA criteria but couldn't possibly be described as "Wikipedia's best work" (1, 2, 3, 4, 5); there are a lot more articles which are of superb quality but will never meet the FA criteria. (FA criterion 1c—"a thorough and representative survey of the relevant literature"—excludes a large number of topics from making it to FA, just because they've been the topic of so much coverage it's impossible to thoroughly cover it; see Nature, James I of Scotland and Roman Republic as just a few of hundreds of examples.) – iridescent12:59, 22 August 2012 (UTC)[reply]
Even though you said "FAs ... aren't 'the best of Wikipedia'", you linked to WP:WIAFA, which states quite clearly, "A featured article exemplifies our very best work". You are either discussing policies that are foreign to you or ... something else. Toccata quarta (talk) 04:35, 23 August 2012 (UTC)[reply]
Oppose The current name has served us fine for years and doesn't seem to confuse most readers or editors. To me it also sounds more refined than the proposed alternatives. Furthermore, the FAs are chosen to be singled out (for excellence) by a process--in that sense featuring or featured are not misnomers at all. wctaiwan (talk) 05:10, 23 August 2012 (UTC)[reply]
Oppose as Featured is an accurate and compelling name. We want these articles to seem featured in the eyes of readers. It's why we put so much work into them. Steven Walling • talk00:52, 3 September 2012 (UTC)[reply]
Oppose I don't think any of the names given below work better than Featured. The issue is less with the name and more with that we're not terribly good with promoting our best work, methinks. Sven ManguardWha?14:45, 3 September 2012 (UTC)[reply]
Also, the criteria were expanded to focus on more than just prose quality. Now FAs are checked for compliance with the MOS, image use policy, sourcing, quality of sources, comprehensiveness of content, and other items, not just the quality of the writing. Imzadi 1979→22:16, 21 August 2012 (UTC)[reply]
Ahhh that makes sense. Yes, that does sound rather self-complimentary. I understand why the old name was change, and even to some degree why it was changed to that specifically (there was a plan to feature wiki's best work on the main page, ergo featured ~ best). I am still convinced that this has been a pet peeve for many editors for ages, and it should be rectified.--Coin945 (talk) 04:47, 22 August 2012 (UTC)[reply]
The actual renaming
Possible replacement names for featured article (please place your own suggestions here too):
Exemplary article
Great article - (logical progression after "good")
Excellent article - (logical progression after "good")
Exceptional article - (describes articles as both "rare" and "superior" - as Torchiest said :D)
Best article - (identifying these article as the best that Wikipedia has to offer)
Quality article - (these articles are of an exceptionally high quality)
Perfect article - (fits all the criteria that a "perfect" Wikipedia article should have)
Top article - (at the very top of the quality table)
Fine article
First-class article
Prime article
Premium article
Supreme article
Super article
Taking the proposition further, for a replacement name I would probably go for Best article, as the page on Featured article criteria says: "A featured article exemplifies our very best work and is distinguished by professional standards of writing, presentation, and sourcing". In Pretzel's main page redesign, he renamed "Featured Article" to "Best of Wikipedia". It states what these articles are clearly and concisely. I think this would be a good way to go.--Coin945 (talk) 15:50, 20 August 2012 (UTC)[reply]
(edit conflict) See my comment above. You don't seem to understand what a Featured Article actually is. The process does not measure "excellence", let alone declare articles to be "exceptional"; it measures only whether an article fully complies with Wikipedia's style and sourcing standards, and thus (hopefully) won't embarrass Wikipedia if it's featured (hence the name) on the main page. – iridescent13:17, 22 August 2012 (UTC)[reply]
Comment – Assigning a superlative like Supreme article or even Exceptional article to a page is a sure-fire way for Wikipedia to lose credibility. It darn well better have won a Pulitzer prize first. Regards, RJH (talk) 21:06, 22 August 2012 (UTC)[reply]
Some historical context
Just to give us some idea of the history of the article-quality titles, so we get a better understanding of what we're dealing with here, can someone explain how we ended up with a quality-control system that consists of both letters (in a school-grade system) like A, B and C & then also words like start, stub, good, and featured? It seems like a really confused system. Also, on a side note, I don't understand the purpose of A (at least anymore). The logical progression always seems to go stub --> start --> c --> b --> good --> featured. I just saw an article that was both at A level and a Good article, and that got be wondering: what does good article even mean....? --Coin945 (talk) 16:13, 20 August 2012 (UTC)[reply]
The standard explanation, in brief: A, B, C (and start) are project-based ratings, FA and GA are community-based ratings. One project may rate a article B-class for decent coverage of content related to the project topic, while another project may consider it C or start for minimal coverage of its project topic (not all projects use C ratings, which were a later addition). It's not uncommon for one aspect of a topic to be better covered than other aspects, leading to different project ratings. FA and GA are not reviews within a topic area, so reflect somewhat broader reviews of overall content, writing, image use, and so on. If an article has been approved by a project's A-class review and also the community GA review, both will appear on the talk page. Gimmetoo (talk) 17:15, 20 August 2012 (UTC)[reply]
Most wikiprojects do not actually use the A rating, preferring to count anything below good status as B. (C was actually introduced only comparatively recently, as something between B class and Start class.) One good example of a project which does still use the A class is the military history project, who place A class as somewhere between GA and FA, requiring an FA-style assessment. As another historical note, in case no one else has mentioned it, you may be interested to know that the "featured articles" project was preceded by a system called "brilliant prose". This is back in Wikipedia's earliest days. J Milburn (talk) 21:35, 20 August 2012 (UTC)[reply]
The Highways Project has its own A-Class Review (used primarily by the U.S. Roads and Canada Roads projects) that also operates as FAC-light to assess articles as above GA and below or ready to be nominated for FA. Our ACR requires that an article be a GA before review as well, so M-553 (Michigan highway) is both a Good Article (it's listed on WP:GA), and an A-Class article (it was reviewed at WP:HWY/ACR). That just means it's a Good Article that is no longer at GA-Class, again that's possible because GA status and GA-Class are technically distinct. (see below).
The Stub-Class is an analog to the stub-sorting project, and typically it's reserved for short or unorganized articles. Start-Class is the next level up in terms of content and organization; I liken it to being the start of a decent article. That's followed by C, B, GA-Class (technically distinct from GA), A-Class and FA-Class (also technically distinct from FA). A project doesn't have to award GA-Class to an article listed as a GA; in fact USRD has had a few examples where a GA failed to meet the project's B-Class criteria, even though it was awarded GA status, so the article would have been both a C-Class and a GA before they were improved. Imzadi 1979→22:24, 20 August 2012 (UTC)[reply]
Huhhhhh..... wow... I finally get it now.. :D Thankyou for all your wonderful insight. Your insights into the article quality system on wikipedia have enlightened me, and I'm sure many others as well. (BTW, why aren't there Wiki page on the history of different aspects of Wikipedia, such as this, or AFD, or talk pages etc... now, THAT, i would love to read). :D I think the question that must be asked next (considering that the main argument is: "is all that hard work worth a name", I want to explore how confusing that one name is to people. It may seem trivial, but it's those trivial things that annoy/confuse/agitate people a bit, each time they come into contact with them, but they come into contact with them constantly! (like a fly buzzing passed your face that you have to swat away --> little effort + frequent = very annoying). If the title can be changed once, it surely can be changed again. I want to know why the title got changed from "brilliant prose" to "featured article" int he first place. Perhaps the knowledge behind this change this will either strengthen my argument, or alternatively put another nail in the coffin. Do any of you know the answer to this?--Coin945 (talk) 14:52, 21 August 2012 (UTC)[reply]
Plus, Imzadi1979 if what you say is true, and that GA-Class is technically distinct from GA, and FA-Class is technically distinct from FA, don't you find this very confusing? In an age (at least this is how I understand it) where we are trying to reposition Wikipedia as being a brand open and accepting of newbies/the non-editor to reel them in (new main page, WYSIWYG editing etc., should we try to make things as easy as possible for them?--Coin945 (talk) 14:57, 21 August 2012 (UTC)[reply]
On what you were saying about "Liken[ing start-class] to being the start of a decent article", I think in 2012 this is wrong in regards to Wikipedia articles. Perhaps in the past one sentence articles would suffice as stubs, but nowadays they get deleted within an instant (I disagree with this sentiment, but, wadaya gonna do..). Nowadays, what you describe as a start article, I would liken much more to a stub article - the only way a stub article can survive Special:Newpages is for it to be what would've passed for a start-class article 6 years ago. Perhaps start-class is obsolete. Perhaps it is misnamed. We need to realise that these traditions have stayed here for so long while time has moved on. Technology has moved on. And most importantly, WE have moved on. We need to change the structure of our site to keep up with the way Wikipedia works in 2012.--Coin945 (talk) 15:08, 21 August 2012 (UTC)[reply]
I don't find it confusing that GA status and GA-Class assessment are separate. One is a status awarded by a community-based review process, and the other is a WikiProject-level assessment. Take, for example, a hypothetical article on a highway in Wisconsin. It's tagged by the USRD project and the Wisconsin project. Let's assume that someone took it to GAN, and it passed. Now it's a Good Article and it's been reassessed as GA-Class because both projects make that status equivalent to that assessment. OK, now the article is reviewed at ACR for USRD and promoted. Because the Wisconsin project wouldn't necessarily have to honor our ACR, the article would be A-Class for USRD and GA-Class for WI, but it's still listed on WP:GA because it's still a Good Article. A-Class doesn't change the little green icon on the article, nor does it remove the article from the WP:GA list.
For another example, Prairie Avenue would have once been tagged for USRD before the US Streets project was formed. (USRD deals with state highways, not city streets). It's a FA, but if it were still tagged for USRD, it would fall as a Start-Class article on our assessment scheme. (It's missing a junction list, which USRD requires in addition to a route description and a history section for C- or B-Class assessments.) The assessment classes are distinct from any status awarded through the community review processes. Imzadi 1979→22:22, 21 August 2012 (UTC)[reply]
I'm sorry, what you have just described is actually very confusing and counter-intuitive to me. I understand the argument that articles can be part of different wikiprojects, which all have different criteria for different quality-levels but:
I thought over time the separate ways of analysing article quality (in different wikprojects etc.) had all been merged into one - thereby standardising how article quality is seen throughout Wikipedia
I think an article is only as good as its lowest quality-level. If you have a featured article that is stil considered a start-class article in the USRD rating system, what that says to me is that the article doesn't have all it's supposed to have after all, and that the article should lose its FA status. An FA article should have addressed all the FA criteria for the various Wikiprojects that make it up. Therefore it just doesn't make sense to me that you can have an FA article while the Wikiprojects rate it as something less.... *confused face*.--Coin945 (talk) 04:47, 22 August 2012 (UTC)[reply]
Think of it this way. A Good Article usually means GA-Class, and a Featured Article usually means FA-Class but there will be exceptions. WP:MILHIST once assessed its Featured Lists as FA-Class because the project didn't use FL-Class. Yes, the classes usually line up with the community ratings from GA/FA/FL, but there is no requirement that they do so. Some projects use non-standard classes, there is a B+ rating in use by some projects that's above B-Class, and MILHIST has CL-, BL- and AL-Class for lists. (See Wikipedia:WikiProject Military history/Assessment.) Featured Pictures and Featured Sounds can be assessed as FM-Class (Featured Media) instead of just File-Class for projects that care to make the distinction, but some projects don't assess files at all. So no, there hasn't been full standardization, and they're probably won't be for quite a while, if ever. Imzadi 1979→10:44, 22 August 2012 (UTC)[reply]
Hmm... then perhaps standardisation is where we should be heading instead on this rename. I've always thought it weird that we have all this quality levels for articles but only 2 for lists. Why don't we follow WP:MILHIST's lead and get these to be the norm?--Coin945 (talk) 13:41, 22 August 2012 (UTC)[reply]
Alternate proposal - consider review of all A-class for merger into GA or FA (pending GAN or FAC)
Actually, I would support a reorganization of GA, A-class ranking and FA-class - as above - we review all A-class articles and maybe rename 'GA' to 'A' - or just leave A out all together...Casliber (talk·contribs) 22:24, 24 August 2012 (UTC)[reply]
The community at large cannot enforce this upon WikiProjects that choose to conduct their own A-class reviews. A proposal like this must be made at those projects, individually. - Floydianτ¢22:53, 24 August 2012 (UTC)[reply]
A-Class, IMHO, is a step between GA and FA, a chance to get extra reviewer input to say it's better than "Good" even if it's not "Featured" level yet. Since there isn't a community-based process, and only WikiProject-level processes, I don't think a discussion here could tell a WikiProject it has to stop using A-Class. Also, there is a fair gulf between the requirements of the GA and FA criteria, and A-Class recognizes that an article fits in between those two levels. Imzadi 1979→23:09, 24 August 2012 (UTC)[reply]
Hmmm.. i dunno. Getting rid of GA would be a good idea. If we're arguing about how valid article quality terms are, "good" is about as vague as you can get. It is a real bitch that we'd have to get every. single. wikiproject to take up the new system... I wonder if theres a way to standardise the way article quality is done around here... It's been 10 years, and I think we've moved past the 'lets just plow right ahead with our own approaches, and tackle those bridges when we come to them' stage. Btw, as I said above, I've always thoguht it weird that we only have 2 quality levels for lists. Why havent we changed that al;ready. All we have to do is have a list level to match every article level. They wont have the same criteria, of course, but it seems like a pretty jolly idea, doesn't it? :D--Coin945 (talk) 13:30, 25 August 2012 (UTC)[reply]
GA, and the review part of FA should be merged to WP:Peer review (as all three are mostly redundant to each other, and this would consolidate resources). If FA is only to determine whether specific content is to be placed on the main page (or at P:FC), then that's all it should be. - jc3717:10, 27 August 2012 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Closing Wikipedia:Wikiquette assistance
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
WQA, as commented on by the participants of this RfC, is a noticeboard that is doing Wikipedia, and it's editors, more harm than good. The consensus below indicates that WQA in it's current state, is not going to work and needs to be shut down. There was also a consensus that there needs to be an intermediary process between the talkpage and ANI, now that WQA is closed. What that intermediary process is to be is not shown by this RfC, despite several pointers made towards WP:3O and WP:RFC/U. Also, concerning the opposition to the closure of WQA, many were fearing that it would be redirected to ANI, and that is not the case, and this RfC was clearly opposed to it's redirection there. The statements didn't say that ANI couldn't handle it, but that it would be a pile on to the drama already there, and the fact that it would cause more issues being at ANI, than WQA. There were also some below who stated the shotgun should not be fired before we realize that there will be a big mess to clean up (in other words, we need the intermediary process before the closure), but it was not a central part of the consensus. After that, a few were still supporting keeping WQA open on the basis that it still solves 1 in 12 cases, and it's better than none or that this is just a bad day (figuratively) for WQA. Despite the arguments to keep WQA open, the consensus is to 1) Close WQA 2) Find an alternative 3) Not redirect it to ANI. -- DQ (ʞlɐʇ) 21:22, 15 September 2012 (UTC)[reply]
Wikiquette alerts is a noticeboard made to resolve problems about civility and Wikiquette. Right now, it's a noticeboard to vent at each other and the problem is not resolved (yes, in some cases it works but in the grand majority...). A lot of the disputes get referred to other noticeboards (which is not good), and the newcomers always receive a boomerang effect and leave unhappy. I've used WQA before, and that did not work well, with the other party leaving Wikipedia.
The hiarchy is currently "Talk page -> WQA -> AN/I -> RfC/U -> ArbCom. If a dispute is not resolved through the talk page, it does not have much chance at WQA, and AN/I should be able to handle civility complaints (and it already does). In brief, WQA is failing and is just a place to vent and kill each-other. ~~Ebe123~~ → report22:03, 19 August 2012 (UTC)[reply]
Keep-Improve I have found it useful for starting a case against a couple of obnoxious sock puppets (possibly the same one, now that I think of it). I have found twice that hostile admins fare better there than mere hoi poli editors who lose patience with them. (It's also fun to be taken there and prove that the person who brought you is really the hostile one :-) Nevertheless, I do think it's good to have a place to go to deal with constant, insidious low level sexist/racist/homophobic/ethnicphobic/etc. comments that don't quite make it to WP:Ani level. Something hostile editors have to think about and some may even learn from. Maybe Dispute Resolution Wikiproject should take firmer control of it to improve it, assuming it's not in charge already. Does it need more structured formatting for initial complaints, etc. CarolMooreDC13:22, 26 August 2012 (UTC)[reply]
Comments on original proposal
I would support a close of WQA, and I think there's clear data that shows the need. In my work as a fellow, WQA was one forum that I did research on, and the results were quite poor. In the survey I ran, only 8% of participants felt that WQA was an effective process for resolving disputes, and this was reflected in my analysis of disputes for the month of May - 21.4% of disputes were resolved as a result of WQA - a majority of the other disputes went unresolved because the participants continued to bicker at WQA. Closing WQA is not a new idea - it has been proposed for deletion three times, and discussed elsewhere numerous times. Those that favour keeping WQA open state that it serves a useful function - conduct disputes that do not require admin intervention can be addressed there. That may be the case, but a majority of the time the discussion will end up with parties at each others throats. This doesn't do much to resolve a dispute - and I think we can do without it. I don't think there's a real need to replace WQA with anything - this month WQA saw 14 disputes, and in May only 17. Some may say that this amount of threads creates little impact and therefore makes it harmless - I disagree, as does the numbers. I therefore think we should mark WQA historical, and encourage hashing out issues on a user talk page - if this is ineffective at resolving the issue it can either be dealt with at ANI, or at a user conduct RFC. Once this change is made, it's up to us to encourage social change - close frivolous threads. But this is needed. StevenZhangHelp resolve disputes!23:45, 19 August 2012 (UTC)[reply]
I would also support the closure of WQA. I have never been involved in WQA, but I found the discussions there quite poor. I also agree with the concerns posted by Stephen Zhang: we should make this historical and encourage hashing out issues at user talk pages. However, if this proves to be ineffective at resolving the issue, it can be dealt with at ANI or at a user conduct RFC. In any case, this closing is needed. Lord Sjones23 (talk - contributions) 23:50, 19 August 2012 (UTC)[reply]
I though I made it clear in the "hiarchy" "Talk page -> WQA -> AN/I -> RfC/U -> ArbCom", so without WQA, it would go to the next. ~~Ebe123~~ → report00:51, 20 August 2012 (UTC)[reply]
I support closing WQA as well. It's a step in the dispute resolution chain that seldom produces meaningful results. If there are a few cases where WQA is actually effective, I think we can incorporate that into a new process, or maybe even an existing one. If people are nervous about closing it down, I'd be okay with making it a "conditional close", pending some other decision about where to re-route the current WQA complaints. Shooterwalker (talk) 01:04, 20 August 2012 (UTC)[reply]
Regarding the hierarchy: I would propose to simply cut it to "Talk page -> AN/I -> ArbCom", concentrating the WQA and RFC/U functionality at AN/I. The influx of "freed" Wikipedians would help to make the AN/I a solid first instance, capable of cutting off the traffic to ArbCom in most cases. Though indeed it is a separate discussion. — Dmitrij D. Czarkoff (talk) 01:18, 20 August 2012 (UTC)[reply]
The idea is to try to resolve problems without admin intervention. Does it work? Usually not, but sometimes it does. Deleting this page won't change the total wikidrama at all, just move it, most likely to ANI. Better a newbie wander into WQA with Editor X deleted my post off their talk page then post that to the shark tank ANI. Consider this example where a thread was [4] closed with that rude "shut up" tag -- does that stop anything? Nope, problem just goes to ANI. Less disruptive to let users talk it out on a lower traffic board. On an environment that (allegedly) prides itself on not bureaucracy there really ought to be a mostly free form, non bureaucratic place for users to vent and feel supported. We're kind of a screwy place and it's easy for new editors to end up feeling miffed, and WQA provides a place for them to go. The usual sequence is not WQA->ANI etc. It's WQA-> (users eventually figure out they're not going to get the other guy "punished" and the need to figure out how to get along.) Nobody Ent01:30, 20 August 2012 (UTC)[reply]
Okay, well, that does sound like a useful function. I don't intend to cast a !vote one way or another, but I suppose if enough editors see it the way you do, and are willing to devote time to such an activity, no harm done. Shawn in Montreal (talk) 01:37, 20 August 2012 (UTC)[reply]
If we only closed WQA and did nothing, I'd completely agree with you - the disputes would simply roll over to ANI and nothing would be achieved. But we need to encourage social change - I don't disagree that it will be hard to achieve, but we need to work together on it. Closing WQA is a first step - we then need to rewrite WP:DR to include more self-help info - encourage hashing out disputes on a talk page. If that's unsuccessful, then AN can assist. I acknowledge the work done by those at WQA, but I think we need to rethink how things are done, and closing WQA in my mind is a step in the right direction. Let's close it for a month and see how things go. If things get out of control we can always reassess the situation. StevenZhangHelp resolve disputes!01:50, 20 August 2012 (UTC)[reply]
Oppose: funny I favor a keeping a board that I frequently ridicule. But believe it or not I have been in disputes where the threat of dragging someone to WQA resolved the situtation. IMO all WQA needs is for volunteers to issue stern warnings, and inform violators that continued misbehavior will result in a perp walk to ANI.– Sir Lionel, EG(talk)02:13, 20 August 2012 (UTC)[reply]
Seems like the threat of escalation is still there - it's just AN/I or an RfC rather than a WQA. I agree that WQA might hypothetically work if plenty of active volunteers patrolled it and made a point of intervening in every discussion - but that doesn't happen much in practice - so it's really an empty threat: "If you can't agree in our discussion here on the talk page, I'll take it to WQA and we'll talk about it there instead."...Meh. SteveBaker (talk) 14:35, 20 August 2012 (UTC)[reply]
Support closing Only on Wikipedia would we have thought it a good idea to have a bureaucracy/public embarrassment forum for bad etiquette. Gigs (talk) 13:28, 20 August 2012 (UTC)[reply]
Support It's obviously not working - and it is quite possibly fanning the flames in some disputes. RfC seems to be a more effective mechanism. SteveBaker (talk) 14:30, 20 August 2012 (UTC)[reply]
Oppose. Nobody Ent has pointed out the way that WQA has been helpful in its way. I think it's a matter of not having overly high expectations. If you don't find it productive (and once you become an experienced editor you probably won't find it productive), then no one forces you to go to it to initiate anything. And I think it's telling that the opening proposal actually uses an outdated name for the page. --Tryptofish (talk) 14:35, 20 August 2012 (UTC) Fixed: [5]. --Tryptofish (talk) 19:26, 20 August 2012 (UTC)[reply]
Support. As far as I can tell, WQA almost never works. I wish we could come up with a lightweight process devoted to handling interpersonal disputes that actually worked, but with herding cats as hard as it is, I'm not sure what such a process would look like. I suspect it would have to be supplied with sharp teeth to be useful in actually resolving things, and, well, if we're going to send people to a board with teeth, we might as well just direct them to ANI and see how that works out. I would very much be open to a proposal for a new, toothful interpersonal-dispute process if it turns out after the close of WQA that these sorts of disputes aren't handled well by the rest of the DR chain (talk, RfC/U, ANI...). A fluffernutter is a sandwich! (talk) 14:48, 20 August 2012 (UTC)[reply]
Throughout the project, breaches of the expected level of decorum are common. These violations of the community's standards of conduct are unevenly, and often ineffectively, enforced. (1,2) — English Wikipedia Arbitration Committee
Support. too retrospective and blaming, needs to be more about finding solutions not highlighting problems. The number of dispute resolution places needs to be streamlined. Casliber (talk·contribs) 15:47, 20 August 2012 (UTC)[reply]
Support closure. Take for instance the current revision: none of the six threads has improved matters, and one or two seem to have actually increased the drama. Looking through the archives this state of affairs doesn't seem to be at all uncommon. Nobody Ent raises some valid points about occasions on which the board does fulfil a useful role, but the balance of evidence suggests that Casliber's "too retrospective and blaming" is an accurate assessment. Alzarian16 (talk) 15:58, 20 August 2012 (UTC)[reply]
Support The cost/benefit ratio seems to be unfavorable. I suspect that the rare instances in which a good outcome results would have had a good outcome anyway. WhatamIdoing (talk) 18:16, 20 August 2012 (UTC)[reply]
Support - sigh, unfortunate. I agree that IRL having a mediated place for individuals to "get it out", and to try to helpfully nudge editors who may be in contention towards collegiate wikiquette seems like a good thing. However, I'm not sure of its direct effectiveness in a typewritten environment that isn't in "real time". Seems like this has mostly devolved into each person taking their time to figure out how to better "get" the "other guy", and push their "side". So all this seems to be doing is moving a discussion thread, than actually doing any more resolving than can be done on any talk page. All that said, I think it would be great if editors who are regular helpers there, would write up a helpful guidance page based upon what they have currently learned while helping there, so to help others in future such situations. - jc3718:57, 20 August 2012 (UTC)[reply]
Strong strong oppose - AN/I is for administrative actions that need to be used (blocking, etc.) If someone crosses etiquette, that is by no means a reason to require admin action. If you have a dispute with a user, WQA needs to be the first place to go, and failing that, RFC/U, and failing that, Arbcom. Admin action is only needed if the person is or remains disruptive. --MASEM (t) 19:16, 20 August 2012 (UTC)[reply]
WQA is not the only way to stop such issues going to ANI. There's no point keeping it just because we can't be bothered to try alternatives. Rd232talk19:21, 20 August 2012 (UTC)[reply]
Inasmuch as "wikiquette" refers to being civil to one another - and that seems to be the crux of most issues WQA handles - it is an administrative matter if it's intractable. WP:CIV is a policy and a pillar, and editors who habitually break policies and pillars are quite likely to find themselves on the losing end of a block, topic-ban, or other administrator(s)-imposed sanction. If your point is that going to ANI for a first instance of incivility is overkill, I'll agree, but I disagree with the general notion that ANI can't handle civility concerns. A fluffernutter is a sandwich! (talk) 19:27, 20 August 2012 (UTC)[reply]
I disagree on both points. We do not want people running to ANI because for playground-type annoyances. It already gets bogged down in petty events already and definitely should not be encouraged as the first point of dispute resolution after trying a talk page approach. But more importantly, ANI is specifically needed when admin tools are required. Most situations that go to WQA do not require admin but simply words of caution. If ANI starts taking up too much of these, I can pretty much assure that there will be enough spite by admins having to take up this task that all parties involved in disputes may simply find themselves blocked if the issue is petty enough. There's a reason why we have ArbCom at the top of this chain, they're people that the community believe can best help resolve behavioral problems, not admins. WQA, even if the arguments turn sour, works as a page to expose more editors to such issues and seek some type of resolve and if that or the non-binding RFC/U fails, then maybe admins should be in play. --MASEM (t) 19:42, 20 August 2012 (UTC)[reply]
"[A]ll parties involved in disputes may simply find themselves blocked if the issue is petty enough" sounds more like a solution then like a problem to me. I believe Wikipedia should become more generous on short-term blocks in case of conduct policies' violations. — Dmitrij D. Czarkoff (talk) 23:10, 20 August 2012 (UTC)[reply]
...up until you find yourself blocked along with an IP because the IP didn't like you took off the fact that "Justin Beiber is the best ever!" off an article about Abraham Lincoln and told you out on ANI. Yes, I would really really really really hope admins don't jump on a situation in that manner, but if ANI becomes overloaded with petty cases, the admins will become jaded and intolerable of any minor struggle. Certainly experienced editors will become upset at enforcement like this, and I can only imagine what newer editors would think The rigors of WQA act as a buffering point to prevent ANI from dealing with petty arguments that have no place on ANI. --MASEM (t) 23:21, 20 August 2012 (UTC)[reply]
On Fluffernutter's first point, it disturbs me that you, Masem, think admins should not block editors for recalcitrant invivility, and that only ArbCom should police that pillar. ArbCom, in Nobody Ent's quote above, seems to be complaining that the admin corps isn't doing it or doing it well. --Anthonyhcole (talk) 18:20, 22 August 2012 (UTC)[reply]
Support - I don't think it can be reformed, and the only way to do any better is to get rid of it. I would strongly suggest not sending people to ANI instead though - taking people away from there was one of the few virtues it had. Wikipedia:Third opinion or similar might be a better alternative - a lot of the problem with WQA was mixing up civility issues with content disputes, and 3O allows volunteers more flexibility to provide input on both, whilst focussing on the core of the dispute and not trying to litigate blame unnecessarily. A bit of "that wasn't nice/helpful, but let's move on and focus on the core of the dispute, which seems to be..." is often what's needed, when it isn't simply some clarification about policy etc. Rd232talk19:21, 20 August 2012 (UTC)[reply]
Support, it is about time. Experience shows that essentially nothing ever gets resolved at WQA anyway and I don't see evidence that WQA discussions actually reduce drama and incivility. Nsk92 (talk) 19:26, 20 August 2012 (UTC)[reply]
Tentative support I have never seen it achieve anything. It was a brave and well-intentioned initiative, but I think it has irredeemably failed. --John (talk) 19:32, 20 August 2012 (UTC)[reply]
Tentative support It seems like many people tend to skip it anyway, and head straight to ANI with civility issues. I will note that incivility is sadly still a significant problem, and as such I'm worried that this may result in a flood of minor disputes being left unresolved and simmering, or heading to ANI while too small for action. Cheers, Zaldax (talk) 19:44, 20 August 2012 (UTC)[reply]
Support Currently WQA serves to delay cases being heard at ANI or Arbcom but doesn't actually seem to accomplish much per se. I find this extra step needlessly bureaucratic when ANI/AN are capable of handling civility disputes, at least to a larger extent than WQA. Sædontalk19:47, 20 August 2012 (UTC)[reply]
Support - Re-using part of my entry into WQA's 2011 deletion discussion WQA is like AN/I's redheaded stepchild, the petty things people don't want to deal with just get shunted out of sight out of mind. What it is is a tattletale board, an "editor X was mean to me! BAWWWWWWWWWW!" outlet to drag someone to do when an editorial dispute isn't going your way...or it is going your way, and you want to keep your foot on your wiki-opponent's neck. Tarc (talk) 19:49, 20 August 2012 (UTC)[reply]
Support WQA is beyond useless. It is a stupendously ineffectual mud pit in which ideologues, edit warriors, prissy civility nannies, and the mock-offended wrestle and spout sanctimonious rhetoric at each other. It can't even hand out a good trouting. Nuke it from orbit. Skinwalker (talk) 20:11, 20 August 2012 (UTC)[reply]
Comment I will say that, having been at WQA here and there, the one thing I like about it is being able to talk about civility concerns in an open forum where outside input can be provided without feeling like you are trying to get somebody punished. The problem is that outside input is rarely offered. Usually you just have involved parties bickering, with some complaining about possible sanctions when the purpose is actually to avoid sanctions. Taking anything to ANI is horrific and RfC/Us are not for minor spats. Unfortunately, civility will always be a problem so nothing will solve that, but we still need a noticeboard for these sorts of minor civility issues that is not as confrontational as ANI.--The Devil's Advocate (talk) 20:23, 20 August 2012 (UTC)[reply]
Support or give it teeth. Don't get me wrong, it is very important to enforce our civility policy. But I oftentimes feel alone in this opinion. Every time I tried to actually accomplish something at WQA I was laughed away, because the board has no binding power and the policy it seeks to police is without consensus. With a strong userbase opposing civility blocks in all but the most egregious cases, disagreements brought to WQA only linger and fester. Until we as a community take civility seriously, WQA would remain a place where conflicts are heated up, not cooled down. ThemFromSpace21:23, 20 August 2012 (UTC)[reply]
Support not sure if my vote actually matters here since the consensus to burn this baby down is pretty clear so yes, today WQA, tomorrow all the other useless dramaboards.VolunteerMarek22:58, 20 August 2012 (UTC)[reply]
It's not WQA that needs teeth, the civility policy itself handicaps any enforcement of civility by making it very difficult to block for it: Wikipedia:CIVIL#Blocking_for_incivility. With current policy you can get away with large amounts of incivility. This is particularly the case if you are otherwise productive (except for driving away other editors that is) or are an established editor.
At times editors do modify their behaviour, even if grudgingly.
The survey demographics did not question inexperienced editors and focussed on experienced editors. High profile disputes with experienced editors are usually caused by long term issues and are also outside the remit of WQA; expecting a discussion which typically goes stale after 3 days to resolve that sort of issue is asking too much.
WQA can provide support or validation for editors who are subject to incivility, even if the incivility can't be dealt with; most of the threads at WQA would be promptly closed at ANI as they do not require administrator action; so the question then should be: does WQA do a better job than the individual editors re-discussing things on the talk page? I would say yes.
RE: The survey - the criteria for selection was 10+ edits in total to dispute resolution forums over a 24 month period. Remember: perception is important. 39% (92 respondents) had requested assistance and 25% (60 respondents) had volunteered at WQA, but 73% (174 respondents) had an opinion on WQA - showing that some had an opinion of WQA but hadn't used it before. I've made further comment below, but I think that we need to focus on social change - encourage hashing it out on a user talk page and provide self help tools so things like WQA isn't needed. StevenZhangHelp resolve disputes!01:58, 21 August 2012 (UTC)[reply]
Conditional Support. Per Masem (opposing) who makes some important observations: strictly on the understanding that AN/I does not take up the role and become a redirect target. There are already far too many help, advice, and other drama boards and many users, including experienced ones, can't see the wood for the trees. Many of the problems on the drama boards themselves are that they are staffed very often by inexperienced users who lack the necessary negotiating skills. This is a golden opportunity to start slimming down but the role of AN/I needs to be made more clear. Admin noticeboards are already swamped by people who can't/won't read the instructions, and new users who want to test their 'moderating' by unnecessarily 'clerking' at AN/I and other admin territory; all it does is prolong the agony. If the proposal to disband WQA reaches consensus, while relevant non-admin comments are welcome, there should first be an indication that AN/I was never intended to be a kangaroo court and that comments should be restricted to admins and involved parties. Maybe then we'll get more admins interested in keeping AN/I on their watchlists. Kudpung กุดผึ้ง (talk) 01:44, 21 August 2012 (UTC)[reply]
Support. Somehow Wikiquette assistance became a sort of cruel parody. It's the only place on Wikipedia where you're guaranteed to be made fun of (or worse) if you present a complaint. Kaldari (talk) 02:28, 21 August 2012 (UTC)[reply]
Oppose - I'm not a great fan of WQA, but it does serve a purpose, in that it deals with entry-level and one-off complaints; extended or egregious behvioral problems can then go to AN/I. My fear is that if WQA is closed, AN/I (which already has many threads that could have been dealt with elsewhere) will be inundated with complaints of the level of "He was mean to me." There needs to be a gatekeeper noticeboard for civility and low-level behvaioral complaints -- if WQA needs to be restructured, or given more teeth, or renamed or whatever doesn't really matter, as long as there is some first place for users to go to before things escalate to AN/I levels. AN/I cannot be that first place. Beyond My Ken (talk) 03:44, 21 August 2012 (UTC)[reply]
The first place should be a user talk page - if that's unsuccessful then outside input should be requested - I think something like the {{helpme}} template or a modified 3O would work. We should emphasise the importance of hashing things out at a talk page and decrease the reliance on boards like WQA or ANI. StevenZhangHelp resolve disputes!04:14, 21 August 2012 (UTC)[reply]
Yes, of course, talk page discussion should always be the first recourse, but I was talking about the "port of entry" for when talk page discussion does not settle the issue. Right now, that's WQA. If WQA is done away with, those disputes are going to have to go somewhere, and I don't believe that AN/I is the best place for them, there has to be somewhere to deal with post-talk page dispute before they reach the AN/I level. Beyond My Ken (talk) 05:17, 21 August 2012 (UTC)[reply]
(ec) I had a think about this and chatted with a few people - one problem with WQA is that the filer has the upper hand - "X user DID THIS!" - it immediately puts the respondent on the defensive and they can attack the other user in retalliation. Thinking about what works well at the moment, I thought of the {{helpme}} template - a user pops it on their talk page and gets assistance from someone. Something similar may work to supplant WQA - I'm working on Wikipedia:Sanity checks - the purpose of which would be that a user can see a situation and ask for someone to take a look at it - no pointing fingers. The details need to be hashed out but I think it'd work well - we need to give new ideas a go at least. StevenZhangHelp resolve disputes!05:52, 21 August 2012 (UTC)[reply]
We never had one before Mar 2005. You're right that the page was created because people were tired of complaints on ANI, but guess what? They didn't really decrease much. And WQA is not helping, in fact the opposite. KillerChihuahua?!?05:38, 21 August 2012 (UTC)[reply]
I have not, of course, done any kind of historical survey, but my impression is otherwise, that a lot of stuff still gets settled at WQA and never makes it to AN/I. Since these are, by their very nature, fairly run-of-the-mill incidents, they may not make much of an impression on people examining the two boards, and the more serious issues (that get noticed) do indeed tend to move on to AN/I. My feeling is that if WQA were more forcefully promulgated as the place to go post-talk page (by, for instance, referring routine matters there from AN/I more often) it would be a better filter. At the moment, I'm afraid that the claim that AN/I won't be adversely affected by closing down WQA sounds a bit like the politician telling his constituents that the new traffic pattern won't result in more traffic on their street. Unfortunately, the traffic has got to go somewhere, and if there's no WQA (or a replacement for it), it's going to end up at AN/I. Beyond My Ken (talk) 07:08, 21 August 2012 (UTC)[reply]
I think I pointed to the survey that I did, as well as the activity stats above - in short - 8% thought WQA was effective, in May 21.4% of disputes were resolved, and a dispute was filed once every 2 days. I'm working on something similar to third opinion that will shift threads from "USER X DID THIS!!!" to "I think there may be an issue at X location, can someone take a look" - using something like the {{helpme}} template. The details will be hashed out over the coming few days - but it's all about encouraging hashing out disputes on a talk page - remember third opinion was the most successful forum in May, so it may work. But WQA isn't working. We need to rethink how things are done - if there was an influx of threads I'd agree with you somewhat, but due to the small amount of threads filed I think closing WQA and setting up other measures (self-help through a rewritten WP:DR page) will work. ANI gets many disputes a day - an extra one or two that slips through won't overflow it. StevenZhangHelp resolve disputes!12:16, 21 August 2012 (UTC)[reply]
Support - WQA was a well-intentioned "sounds good on paper" idea that, per nom. & others in support of closure, hasn't worked in practice (generally speaking) and if anything has proven counterproductive.-JayJasper (talk) 05:52, 21 August 2012 (UTC)[reply]
Nobody Ent has this right. WQA is really only effective for low-level incivility between editors who don't know any better: it is hopeless for actual civility enforcement. However, given that, it actually works well enough for what it is and closing it would simply increase the workload of the general admin corps. Chris Cunningham (user:thumperward) (talk) 07:45, 21 August 2012 (UTC)[reply]
Oppose - ANI should not be treated as the first port of call for resolving disputes that cannot be solved on the relevant talk page. --W.D.Graham12:27, 21 August 2012 (UTC)[reply]
(edit conflict)To be fair, that's only one proposal for what to do after eliminating WQA, should we decide to do so. I agree with you 100% in that every minor dispute should not be brought to ANI; that would clog the system and leave many minor disputes unresolved, left to simmer until they actually do require admin attention. Instead, I think we should create an alternative to WQA, such as a 3O-esque template, to serve as a "first line of defense" in resolving civility disputes. The difference is, these discussions would still take place on the relevant talk page. Anyway, that's just one idea for how to replace WQA; other editors have proposed other options, and I'm sure people have suggestions they haven't made yet that would work equally as well, if not better. Cheers, Zaldax (talk) 13:05, 21 August 2012 (UTC)[reply]
Support and agree with Steven Zhang; We need to close WP:WQA and rewrite WP:DR to give users more help and encouragement to try to settle disputes that are currently brought up on WQA on the article or user talk page. --Guy Macon (talk) 13:03, 21 August 2012 (UTC)[reply]
Conditionally opposed; support if condition satisfied: A process prior to ANI and RFC/U is needed, but the way WQA works, which allows it to allow conduct disputes to escalate by providing a forum for the disputants to not only fight with one another but also fight with any neutral editors who choose to weigh in and who are drawn into the fight, is counterproductive. Still, it's better than nothing and I'm opposed to its closing unless a substitute process, such as the "3O for conduct matters" proposed below is adopted. If that or some other substitute process is created (and WQA is such a failure, I don't much care what it is, so long as it is different than WQA), then WQA should be shuttered. Regards, TransporterMan (TALK) 14:24, 21 August 2012 (UTC)[reply]
There's no need to be so emphatic about not sending people to ANI; most people wanting to close WQA agree an alternative mechanism is needed so those cases don't end up at ANI. Rd232talk14:35, 21 August 2012 (UTC)[reply]
Steven: I think you've misperceived my stance. I am (of course) opposed to redirecting WQA to AN/I, but my point is something different: if there is not a place for low-level incivility incidents to go to (either WQA or a replacement), then -- like the cars that have been diverted by the new traffic pattern -- those incidents will naturally gravitate to AN/I, with or without a redirect. As I said to begin with, I've never been a big fan of WQA, but if people want to close it down they need to have an alternative in place first, or else (pace your surveys) AN/I will be negatively affected. Beyond My Ken (talk) 17:44, 21 August 2012 (UTC)[reply]
Strong Support with equally strong encouragement to find some alternative means such as one of those suggested by Steven Zhang to handle civility matters shy of ANI. As a personal anecdote, the one time I attempted to utilize WQA I was attacked by the neutral editor for something entirely unrelated to civility and then accused of retaliating when I happened to tag one of their images for copyright problems a few days latter. There was no attempt to actually investigate let alone address the issue of civility on either side of the dispute. Perhaps this was only a case of the particular volunteer attempting to man the desk at the time I was there and would be equally prevalent in whatever replacement is found, but the whole situation left me more upset than before I sought outside resolution which is decidedly not the desired outcome of WQA. As Beyond My Ken notes, ANI should not be the first step for escalating civility disputes, but the current process is beyond broken--it allows and often encourages situations to actively worsen. Even if ANI is an interim solution, there would at least be multiple eyes to keep an eye on problems including admins to shut things down if they did get out of hand. VernoWhitney (talk) 15:18, 21 August 2012 (UTC)[reply]
(edit conflict)Oppose. That's going to surprise a number of people, but it's my opinion. Quite simply, yes, AN/I could do everything that WQA is doing, and possibly better. But WQA makes it so that the 10% of cases that just need to be vented about and the other 10% of cases that can actually be resolved there don't clutter up AN/I. It's a sinkhole for the more frivolous and/or easy-to-handle cases. - Jorgath (talk) (contribs)17:30, 21 August 2012 (UTC)[reply]
Close and mark historical. If it needs to be redirected to something, redirect it to WP:PAIN, which was basically the same thing (except with teeth) and was also closed and marked historical. - Balph Eubank✉17:36, 21 August 2012 (UTC)[reply]
Strong support — Wikipedia volunteers are not civility nannies. If someone is being rude to the point of it being a disruptive influence, then they can be blocked for it (notice that "gross incivility" is the second point listed under the subsection I linked to). There's no reason whatsoever that such instances can't be brought to ANI; if administrative action is deemed unwarranted, then the people participating there will say so, and the matter will be closed. WQA is needless bureaucracy, and the very notion of there being a separate noticeboard specializing in handling cases of rudeness is actually quite silly. To reiterate — if it's a problem, they can be blocked. If not, then just move on. Speaking from personal experience, you shouldn't let people like that get to you; be the better person. Kurtis (talk) 01:48, 22 August 2012 (UTC)[reply]
No, absolutely not. Note also my second sentence: "If someone is being rude to the point of it being a disruptive influence, then they can be blocked for it..." You won't find very many people who are stronger advocates of the notion that WP:CIVIL should have more teeth. At a bare minimum, we really should expect people to be nice. I think I probably should have phrased my first sentence better, on reflection. Kurtis (talk) 14:09, 22 August 2012 (UTC)[reply]
I agree with you that civility enforcement should be stronger, but because definitions and standards of civility are (obviously) quite different from place to place, there needs to be a fourm where conflicts between those standards can be discussed, and not just be settled in the mind of a single admin, whose standard may be different from either of the disputants, or even from the community's as a whole (if there is such a thing). Without that forum, civility enforcement becomes simply a random collection of one-off admin actions, which is more likely to lead to discontentment, since the disputants can see that a different admin in a similar case applied a different standard. And, yes, we do have that now as well, but I believe it will get much worse if there is a not an entry-level forum to deal with civility cases in which a de facto standard -- or at least a small range of standards -- can be arrived at through community discussion. As I've said, I have no objection to restructuring WQA, or giving it more teeth, or replacing it with something else, but just shutting the doors seems to me to be a bad idea. Beyond My Ken (talk) 16:31, 22 August 2012 (UTC)[reply]
Support I've been away, so let me know if I'm being stupid. It seems to me there are plenty of other ways of resolving disputes. This proposal probably won't cause an undo burden to fall on WP:an/i. It seems the process has broken down for a lack of disinterested 3rd parties to keep track of the board. Perhaps it would be better if these problems were resolved via user talk and failing that mediation. @kurtis-- I thought WQA was needless bureaucracy when it was first incepted. It was a product of the times and should be best celebrated by marking as historical and moving on. Dlohcierekim04:01, 22 August 2012 (UTC)[reply]
Provisional support. If WQA is demonstrably ineffective most of the time, plans should be made to replace it with something more effective. Once a replacement is up and running, WQA should be shut down, but not before. I do not think that ANI can be that replacement. Rivertorch (talk) 10:18, 22 August 2012 (UTC)[reply]
Comment seems to me that WQA is a place to continue a dispute in an unresricted fashion so that it can move to another venue. It needs an influx of volunteers if it is to work properly. 64.40.54.147 (talk) 14:14, 22 August 2012 (UTC)[reply]
Support, though I imagine that many/most WQA issues are not suitable for ANI. WQA is largely ineffective, though this is symptomatic of a broader lack of enforcement of civility, and we have too many venues for dispute resolution. Hut 8.515:48, 22 August 2012 (UTC)[reply]
Support - Close it. Its been pretty much pointless for a long time as are several of the other noticeboards. Much better reasons are given by users above but the bottomline is its ineffective, undermanned and at this point pretty much a waste of time. Kumioko (talk) 18:11, 22 August 2012 (UTC)[reply]
Support If WQA can't be fixed (OK, make that "won't be fixed"), then close it. My observation is that WQA is a waste of everybody's time. I don't think it matters why people think that - they do, and that's all that matters. Belchfire-TALK08:52, 22 August 2012 (UTC)[reply]
Support Twice I went to WQA after remarks on article talk and user talk. One case resulted in a stuck, and the reported user got blocked much later for sockpuppeting. The other "case" did not result at all, as no comment —let alone assistance— was given by anyone. On a third severe civility issue, when tempted to go to WQA (again, after many remarks on article talk and user talk), I decided to go to ANI directly. A few admin remarks solved the issue for a while. A revisit to ANI a bit later for the same issue resulted in a block of the reported user. It looks like experienced incivil editors are not impressed by the workings of WQA, unless of course a comment is made by someone holding a hammer. Therefore ANI is the place to go. I dont think that the proposed Sanity Check or the existing 3O in article talk space is a good alternative for WQA, as wikiquette matters are inherently off-topic in article talk space. - DVdm (talk) 21:48, 22 August 2012 (UTC)[reply]
Support removal OR moving to make explicitly voluntary, probably in userspace - Extra bureaucracy is a bad thing. This appears to acheive nothing, and wastes the time of many. On the other hand, I don't want to dictate to wikipedians what processes theny can use so if everyone agrees this could be helpful why delete it? I would say that in this case the movement of it to someone's userspace and it being made totally clear that it's a voluntary thing for everyone involved could potentially work. We need a volunteer for that though. EggCentric23:10, 22 August 2012 (UTC)[reply]
Oppose for the time being; if and when something else is instituted to buffer ANI and WQA becomes little used, it can be removed. Buy the tractor and have it delivered before shooting the horse. Dragging the horse away by hand ... you don't want to do that. htom (talk) 00:10, 23 August 2012 (UTC)[reply]
Oppose until some sort of alternative (e.g. WP:Sanity checks proposed above) is brought in and found to work better than the current system. Maybe this doesn't work all the time, but isn't it better to have something that works at least part of the time than to have nothing at all? Closing WQA without something to fill its place leaves a gap in the WP:DR process which it is intended to fill, regardless of how well it does so. If WQA were actually doing some sort of harm, then closing it without a replacement could be justifiable, but I don't actually see anything negative coming out of it. dalahäst(let's talk!)02:10, 23 August 2012 (UTC)[reply]
Support - My opinion has changed. For the good of Wikipedia, the process should be streamlined. The arguments to close it are too strong to ignore. ChrisGualtieri (talk) 04:46, 3 September 2012 (UTC) Oppose/Conditional - WQA may not have the tools it needs to address the situations in a proper fashion, therefore I would suggest having a test of any proposal prior to WQA shuting down so there is no void and a transition process can be tested. Though WQA works if the editors both want to resolve the problem, if either party doesn't have much faith in WQA, than it will not work. ChrisGualtieri (talk) 16:28, 23 August 2012 (UTC)[reply]
The WP:3O process already exists and supports behavior-related disputes. In the past, 3O has primarily been used for content disputes, not behavior, perhaps because WQA and ANI were more widely publicized for behavior issues. 3O is a mature and tested process. So, in that sense, the test you are suggesting has been underway for a couple of years. --Noleander (talk) 18:33, 23 August 2012 (UTC)[reply]
I have always been of the belief that WQA is far more informal and the board has this tagline, "For disputes that are exclusively about an editor's conduct and are not related to a content issue, other forums may be more appropriate such as administrator incident noticeboard or request for comment on user." I figured that via the chain, WQA would be the first step and if it was a conduct matter (solely WQA's function) that it would jump to RFC:U or AN/I depending on severity and immediacy felt by the filer. The current issues at WQA are largely conduct and they seem to be going well despite this proposal to shut it down. ChrisGualtieri (talk) 23:17, 24 August 2012 (UTC)[reply]
Support. A step before ANI might be helpful, but WQA doesn't seem to be doing the job effectively from what I've seen, and I don't think it's used that much either. I'd be in favour of closing it and trying something else. OohBunnies!(talk)18:47, 23 August 2012 (UTC)[reply]
Support close - This is like the United Nations of Wikipedia. It's basically a toothless talking shop that resolves nothing and is often use as a wikilawyering tool to deflect from content disputes. Stick a fork in it. -- Scjessey (talk) 19:32, 23 August 2012 (UTC)[reply]
Support Followed a couple threads there lately, and there appears to be a mob mentality to the page. ANI might have the same problem, but at least stuff gets done there. Hot Stop14:29, 25 August 2012 (UTC)[reply]
Support I've been asked to comment two or three times at WQA, and find it a toothless vacuum, just ready to be filled with a continuation of any dispute bought there. It provides "yet another" forum for ill-mannered and bullying editors to promote themselves. It doesn't add any value to Wikipedia. Ideologically it's lovely, but in practice it fails, in an epic way. The Rambling Man (talk) 16:47, 25 August 2012 (UTC)[reply]
Support It isn't effective, and seems more often than not to end up continuing the discussions that led to it, without any real resolution. Cloudbound (talk) 12:43, 26 August 2012 (UTC)[reply]
Oppose for now; echoing htom up thread a bit. I would prefer being drawn and quartered to being "invited" to WQA but I am skeptical that this step of closure would be a cure to the trauma / drama I'm reading there. If this is step one, the abuse certainly excalates upline, so we definately need a testable proven buffer before editors and conflicts are thrown into ANI. Fylbecatuloustalk13:04, 26 August 2012 (UTC)[reply]
Support WQA seems to be more of a gladitorial stadium than a place for dispute resolution. Dispute resolution needs teeth, and teeth are inherent in ANI and not in many other places. Also, ANI should be able to close down dispute resolutions that are brough here too quickly, such as with a "Work it out on the talk pages, and come back in three days if it is still a problem type solution.
Oppose It's another forum to get crap off the talk page. It's an alternative to RFC/U and it's low cost support for one of the pillars of the project. As an alternative has not been worked out, oppose. Alanscottwalker (talk) 18:50, 27 August 2012 (UTC)[reply]
Strong oppose, trout the OP, and prevent further useless nominations of WQA for closing The goal of WQA is to keep mildly uncivil behaviour off of ANI, and to improve communications between editors. ANI is there for incidents that need immediate action - WQA doesn't meet that definition. If I remember correctly, this is not the first time that this proposer has suggested its closing, and I may be wrong, but I think they were also involved in another assistance board that they mistakenly thought was possibly a replacement for WQA. This is a bad perennial suggestion. dangerouspanda20:06, 27 August 2012 (UTC)[reply]
It's also hardly fair to trout the nominator when the idea clearly has a fair bit of support (not saying whether it's reached consensus). Are we going to trout every supporter here? Heimstern Läufer(talk)07:07, 28 August 2012 (UTC)[reply]
Support. I concur with Steven Zhang's comments at the top of this section, particularly where he notes that it's up to us to encourage social change. This page had its use, but we have better options now and should move on. I also agree that EatsShootsAndLeaves's comment, above, is inappropriate. -- Earle [t/c] 08:25, 29 August 2012 (UTC)[reply]
Stong oppose Just because an idea isn't working as well as it should doesn't mean you should get rid of it. I've never used wikiquette, because I didn't know about it, but I think it's a fantastic idea. Any opportunity to infuse civility into a discussion is not only nice, it's essential. I don't want to get to too philosophical, but we need this sort of mediation not just in the wiki world but in society at large - don't close it down just because it isn't working. Find a way to make it work.Jasonnewyork (talk) 18:01, 30 August 2012 (UTC)[reply]
Support - Wikiquette assistance has unfortunately failed. It had noble intentions, but hasn't succeeded. I went there once with a serious complaint, and I didn't even get any help - I just got the editor I was complaining about responding and being incivil again. The thread above me was humongous, and consisted of essentially 3 or 4 editors involved in the request attacking one another, rather than anyone resolving it. It's not helpful, and throws off newbies. I'd support creating it again but with a different set of admin rules and a much closer eye on it from admins, but for now, I'd say close it. --Activism123405:09, 31 August 2012 (UTC)[reply]
Support. This venue is ineffective and promotes a divisive battleground mentality. It seems to have become part of our content dispute resolution process, yet is inherently harmful to the goal of resolving editorial disagreement. (Disclosure: I have never been reported to WQA, nor have I ever really worked the board, so I see it as an outsider.) My preference for implementing this proposal is the same as KillerChihuahua's, below. AGK[•]10:40, 31 August 2012 (UTC)[reply]
Support - WQA is ineffective and redundant. If the incivility issue is minor, then no board should be needed. If the incivility issue is major, then take said user to AN/I. The labour spent at WQA would be better spent elsewhere, like AN, DRN and SPI. ~ GabeMc(talk|contribs)00:18, 1 September 2012 (UTC)[reply]
Support closure, and support conduct 3O. I agree with the characterization of WQA as "ANI without admins". It's basically a gossip-and-gripe forum, with little to no outcome other than escalation of whatever drama led the users there. ANI may be a "drama board" in a sense, but at least ANI allows for solutions, especially when the appropriate solution is the banhammer. In situations that don't necessarily require administrative action, 3O works because users know what to expect, and can resolve their differences in a structured and constructive way. I would support separate 3O processes for content and conduct, to keep personal drama as far away from content disputes as possible. szyslak (t) 22:56, 1 September 2012 (UTC)[reply]
Support. Were the board to function in the manner it is supposed to, I think that my opinion would be different. As it currently stands, the fourth pillar has essentially been rewritten to read Editors should interact with each other in a respectful and civil manner, unless you just don't feel like it. Civility policy is toothless to the point of hilarity. As long as that fact remains, then this board will never serve any purpose other than to escalate conflicts. It's sad... but my biggest reason for wanting to see this board go away is that it is the most immediately obvious avenue to resolve conflicts of this nature, and I would prefer new users not to see the fact that the blatantly uncivil among us are permitted and enabled to operate unfettered without any accountability... ever. Trusilver07:49, 2 September 2012 (UTC)[reply]
Support. From what I have seen, WP:WQA is — for the most part — next to useless for the purpose that was originally intended for it. Most of the problems reported there are nothing that a little bit of extended, courteous user talk page negotiation cannot handle. SuperMarioMan00:22, 3 September 2012 (UTC)[reply]
Support merging of forums, because forum-proliferation is getting as bad as rule-proliferation. The more roles a board can fill, the more people will lurk and give feedback, and the more useful it will be. Narrow board-missions can hence be ineffective. -- Quiddity (talk) 00:41, 3 September 2012 (UTC)[reply]
Support from Signpost "Opinions of dispute resolution are overall negative – while respondents rate arbitration as the best dispute resolution forum (one in three respondents rate it as good or very good), Wikiquette assistance is regarded as the worst (only 1 in 12 rate it as satisfactory)." Seems this process is a failure and so abolish or reform it. Regards, Sun Creator(talk)12:38, 4 September 2012 (UTC)[reply]
Support Steven Zhang's Signpost article made it clear WQA lags behind the many other options in terms of effectiveness. This is a low-hanging fruit; let's pluck it. --JaGatalk16:13, 4 September 2012 (UTC)[reply]
Support closure and marking as historical. The data collected and presented by Steven Zhang are pretty damning. With such abysmally low approval and effectiveness, I really don't think "we should just improve it!" is a realistic perspective. In order to improve something, there needs to be something workable, and I just don't see it here. Put it out of its misery. ~~ Lothar von Richthofen (talk) 19:53, 4 September 2012 (UTC)[reply]
Support closure and marking as historical. As I have only been able to observe the events on noticeboards for about 18 months or so now I have discovered that WQA is just plain useless nowadays. All WQA is doing nowadays is allowing people to vent and try to work things out in basically a talk page made public. Barts1a / Talk to me / Help me improve02:53, 6 September 2012 (UTC)[reply]
Support. I do not have any experience with resolving uncivil behaviour on the Wikipedia. I had a note of this debate in the header of my watch list. I have read through almost all contributions to this debate, and I have also taken a look at Wikipedia:Wikiquette assistance, the page in question. In my view, only a few things stand out. The first is the claim that 21.4 % of the disputes are resolved by Wikiquette assistance in May. This is a poor percentage. It should be at least 50 %. The second is the series of stages that exist to solve civility problems. The proposer depicts five stages. However, the maximum should be three, for any kind of conflicts. The third is the statement that the page in question makes about its goal: "Wikiquette assistance is a forum where editors who feel they are being treated uncivilly can request assistance. The goal here is to help all parties in a situation come to a mutually agreeable solution.". This goal means that those who assist have the view that uncivil behaviour on the Wikipedia is basically acceptable; it does not need to be investigated and sanctioned. However, soft doctors make stinking wounds. P.S. There seems to be a problem with the 21.4 %. If 21.4 % of 17 disputes were resolved in May, then the number of resolved disputes is not an integer. --Maarten 1963 (talk) 22:10, 6 September 2012 (UTC)[reply]
Support closing. Resolved rate is too low, especially considering the relatively high chance of making unresolved situations worse by having a forum to "attack" each other's conduct. In one of the current cases there was a budding edit war on whether the reporter was to be included in the title (as the report was a boomerang). A third party editor resolved this, but took no further part in the discussion. Other editors added their opinion and the reporter decided to leave the forum, clearly not taking the hints about his own conduct. Hardly a stellar result. I don't know if I'm entitled to vote here, but I wanted to add a comment based on a recent experience with that forum. 88.88.164.41 (talk) 22:39, 6 September 2012 (UTC)[reply]
It looks like there are a few token objections to closing WQA. Assuming that the consensus *is* to close WQA, we should still take into account those token objections to make sure DR works optimally. The (limited) value of WQA has been described as:
Reducing the overload of low-grade civility complaints at AN/I or RFC.
A deterrent on low-grade incivility, to prevent things from escalating to a full-fledged AN/I or RFC.
A less bureaucratic mechanism for minor incivility that doesn't require an administrative action.
A less WP:BITEy way of helping new editors understand our civility policy, without too much page traffic.
Not saying that these are reasons to keep WQA around. But if the decision is to close WQA, we ought to decide whether to have another "line of defense" before we send these things to AN/I or RFC. If yes, we need to decide what that process should be. If not, we need to decide how to improve how RFCs and AN/Is deal with low grade incivility and newer editors who might only need a stern warning. Shooterwalker (talk) 20:04, 20 August 2012 (UTC)[reply]
Perhaps a template of some sort, in the same vein as Third opinion? (How's that project fairing, by the way?) Users could tag a discussion they feel is becoming uncivil, and a neutral party could drop by to observe the situation and give a few friendly reminders to the involved parties. It would certainly be a less bureaucratic, bite-y way of handling minor disputes. Cheers, Zaldax (talk) 20:11, 20 August 2012 (UTC)[reply]
It seems to me that DR/N could be the first line of defense, in-so-far as to establish whether the dispute is primarily content-related or behavior-related. As it already deals with content, and to the extent of identifying behavioral issues, this wouldn't be a change. From there, for behavioral problems (for that is what concerns us here) it could continue to "direct" users to the appropriate solution board, usually the user talk page to start, or another appropriate sub/pre-ANI noticeboard. If it's identified that the scope of the problem is larger than the scope of another noticeboard or user talk pages, then I doubt it's too small for ANI to handle.
This seems to me to get a bonus out of this direction, which is structuring the dispute to some extent, something I know is something WQA has an issue with.
Alternatively, we could set up a DR/BN (DR/Behavioral noticeboard), with the same restrictions on the participants as at DRN (word count, etc.). This also has the benefit of structure. --Izno (talk) 21:03, 20 August 2012 (UTC)[reply]
Third opinion is a process that works, but minor content disputes are much easier to resolve than behavioural ones. When two editors start going at each other's throats, it's difficult to stop the dispute from escalating. Small behavioural disputes have a tendency to snowball into larger ones.
Instead of creating a separate template or noticeboard and risking forum creep, one option which has been mentioned is to expand the scope of current content dispute resolution venues (3O and DRN) to include small behavioural disputes (that don't qualify for RFC or AN/I) alongside content disputes. Behavioural disputes are often intertwined with content disputes. This proposal may work, but it does have some major problems. It would drastically increase the workload of the process, and introduce the mess of personal drama into the process that volunteers might be uncomfortable with handling.--SGCM(talk)21:11, 20 August 2012 (UTC)[reply]
Third opinion is a process that works, but content disputes are much easier to resolve than behavioural ones. - Neither of these claims is true except for some pretty weird definitions of "works" and "resolve".VolunteerMarek22:56, 20 August 2012 (UTC)[reply]
Let me clarify, I meant relative to WQA. In the activity analysis, 3O had a success rate of 52% compared to WQA's 21.4%. A 52% percent success rate is nothing to brag about, and 3O certainly needs to be improved. I actually agree with you that the large content disputes (Arab-Israeli, Northern Ireland, Scientology, etc) are every bit as problematic as the dramafests that flare up on Wikipedia. But those disputes often fall outside the purview of 3O.--SGCM(talk)23:24, 20 August 2012 (UTC)[reply]
WQA fails in its inability to enforce decisions. To date the only instrument that can be used to enforce anything conduct-related is ban, so any new conduct dispute resolution process that doesn't not offer "ban" outcome is doomed. On the other hand, we already have a place where this outcome is available — AN/I, so why reinvent the wheel? — Dmitrij D. Czarkoff (talk) 23:28, 20 August 2012 (UTC)[reply]
Because not every WQA case needs admin action. If it doesn't need admin action or it's not apparent that it does because of no smoking gun; the section will be closed quickly at ANI. IRWolfie- (talk) 00:51, 21 August 2012 (UTC)[reply]
I do think we need a clear alternative to direct people to if WQA goes (an alternative which is not ANI!). My suggestion is WP:3O, via a help page about civility issues that tries to give advice about situations which WQA frequently encountered, including on when to escalate to RFC/U or ANI or Arbcom instead of using 3O. If this doesn't work for some reason, alternatives can then be considered. Rd232talk21:39, 20 August 2012 (UTC)[reply]
If we are to redirect to 3O, the latter is going to need to be reworked to an extent; specifically, to allow for situations in which more than two editors are involved in a civility dispute. Perhaps we could create a template such as the one I mentioned above, but fold it into the 3O project (perhaps as a civility subpage) to avoid some of the creep. That would allow for a more nuanced approach, I think, and would avoid overburdening the content dispute aspect of 3O with behavioral disputes. Cheers, Zaldax (talk) 22:29, 20 August 2012 (UTC)[reply]
I don't think 3O should be the primary destination that WQA gets routed to, but 3O is effective and I would be happy for it to take some of the caseload. If that means tweaking 3O's criteria, so be it. Our primary goal should be resolving disputes, rather than process pedantry. bobrayner (talk) 00:09, 21 August 2012 (UTC)[reply]
This is a discussion about process change; it's possible to change processes (although it's rarely easy around here). If there's another task which 3O would be better at dealing with, I'm happy for 3O to take that on too, rather than saying that 3O may only do what it currently does. bobrayner (talk) 07:16, 21 August 2012 (UTC)[reply]
IMO, the reason WQA does not work is that incivility is not a disease, it is only a symptom. Simply mark WQA as historical and focus on the root causes. If the incivility is tagging along with a content dispute, 3O is an option because resolving the content dispute should resolve the civility issue. If it does not, ANI becomes relevant. BLPN, COIN, etc. could also come into play depending on who is causing the concerns, and why. Resolute00:59, 21 August 2012 (UTC)[reply]
Something to consider here - in May, WQA saw a total of 17 disputes, a little over 1 every 2 days. If this trend were to continue, I don't think ANI would be flooded. Directing people from the closed WQA to a set of instructions on how to handle their own issues (read: self-help) should be encouraged in the first instance, something like Wikipedia:Sanity checks (hybrid of WP:GMN and {{helpme}} - currently being worked on) may catch any loose threads. But I don't think the concern of closing WQA causing an overflowing of petty disputes at ANI holds much water, simply because ANI isn't used a great deal. StevenZhangHelp resolve disputes!11:46, 21 August 2012 (UTC)[reply]
As one of the most frequent contributors at 3O I am opposed to opening 3O to conduct disputeshowever I think that a separate "3O for conduct disputes" is a brilliant idea and could easily replace WQA. Mixing conduct disputes and content disputes in the same process weakens the ability of the intervening editor to deal with the conduct dispute by drawing the resentment of one or both of the warring parties, but a separate process that works like 3O would cure quite a few of the ills which WQA suffers. Regards, TransporterMan (TALK) 14:16, 21 August 2012 (UTC)[reply]
A separate 3O process for conduct disputes is a bad idea (since apparently we're enthusiastically bolding now) because it requires a dispute to be defined as being about conduct. Conduct issues are rarely resolvable satisfactorily by talking alone, and usually mixed up with content issues, which more often can be resolved by talking. Leaving it open whether a dispute is 10% conduct and 90% content or vice versa allows much more flexibility for respondents to decide how to proceed. Quite often "focus on content, not the contributor, now let's see about this content issue" gets things moving a bit. And working together to get somewhere with a content issue often helps with conduct issues, because conduct issues often arise at least in part from a breakdown in AGF, and cooperation on content with a bit of assistance can help rebuild it. Rd232talk14:29, 21 August 2012 (UTC)[reply]
I agree entirely that curing content issues generally cures the conduct issues, but inviting them to be discussed in the same process is a recipe for disaster. I have certainly given 3O's in which I gave a conduct opinion and also included a strong admonishment about conduct and have seen those be successful, but I generally limited them to situations in which the conduct problems were mutual and did not pick out one or the other of the editors to individually admonish. Doing so would simply weaken the conduct part of the 3O for the very same reason that conduct issues generally weaken discussion. Regards, TransporterMan (TALK) 14:43, 21 August 2012 (UTC)[reply]
Agree totally. In first instance, this discussion seems a bit confused. If WQA is not useful (I have no opinion) get rid of it. If it useful, keep it. If it's useful but not working well, reform it. But this feels like a discussion that has reached two contradictory conclusions and wants to act on both of them.
Merging WQA with 3O would reduce 3O's clarity of purpose. Users (and, quite possibly, responders) would be less sure about what is does and doesn't do. Plus, I see there's a discussion consequent to this on the 3O talkpage about changing 3O to accept disputes involving more than two editors. That's something that should be discussed on its own merits, not because a failure of decision-making elsewhere necessitates it. And, it would basically make 3O an a cappella version of DRN, so we would presumably then end up discussing how to keep those two processes distinct. Before you know, the whole of WP's DR mechanisms will have been upended.
It seems to me there's two ways to look at closing WQA, and what to do afterwards.
One way to look at it is that we're closing WQA mainly because it's ineffective. In which case, it makes sense to create a 3O process for civility (a sort of "mediation lite"). Even though it would cover the same ground as WQA, hopefully it would have a greater likelihood of achieving some kind of result.
The other way to look at it is that we're closing WQA because we generally have too many DR processes. In which case, replacing it with another process is kind of self-defeating.
Steven Zhang noted that there were less than 20 WQA incidents in the last month. Couldn't we have 3O take on some of the content related stuff, have the DR noticeboard take on some of the behavioral stuff, and leave the truly angry stuff for AN/I? Shooterwalker (talk) 16:43, 21 August 2012 (UTC)[reply]
I'd encourage everyone to take a look at WP:SANITY; that proposal's coming along nicely so far, and I think it might make a good "replacement" of WQA as a sort of 3O for conduct. I think it would go a long way towards encouraging civility as well, by providing a neutral voice whose aim is to calm things down. Cheers, Zaldax (talk) 19:21, 21 August 2012 (UTC)[reply]
Correction: 3O already allows conduct disputes by community consensus. I totally forgot that there has already been a community discussion at 3O, about two years ago, when I tried to restore a content-only restriction which had once been there and had subsequently been removed. The discussion and consensus decision is here: Wikipedia_talk:Third opinion/Archive 5#Alleged restrictions on disputes. I apologize to the community for my bad memory. Abashedly, TransporterMan (TALK) 15:01, 23 August 2012 (UTC)[reply]
3O - Agree with those above that suggest 3O as a replacement for WQA (either as separate 3O-conduct & 3O-content; or as a single consolidated process). For a couple of reasons: (1) 3O is already in existence and functioning smoothly; (2) we need to streamline and consolidate DR processes, so 3O is a much better alternative than creating a new process. It may be that expanding 3O to handle WQA-type jobs will require some minor tweaks to 3O, but that is no problem. --Noleander (talk) 16:12, 23 August 2012 (UTC)[reply]
My reasoning for closing was mainly as it is redundant and we have too many locations. Make a big redirect to 3O and AN/I and folks keen to help out can watchlist those places. Casliber (talk·contribs) 13:30, 26 August 2012 (UTC)[reply]
The problem with 3O for conduct is how we respond when a matter involves more than two editors. My thought is that, similar to RSN and BLPN, we have a noticeboard specifically for discussing whether certain actions or statements constitute incivility. In other words, if someone feels he or she is being treated in an uncivil manner or if someone is curious about whether his or her own conduct is uncivil, that editor can see if outside observers agree that this is the case. Basically this would be used in cases where more than two editors are involved and could help guide admins on the matter of civility enforcement as well.--The Devil's Advocate (talk) 20:27, 4 September 2012 (UTC)[reply]
Another way around
Some of the comments above enlightened me to understand that the best way to remedy the loss of WQA would be to create another process that would serve the same goal as WQA – show that others don't accept this kind of behavior – but in a more conduct-specific way. I propose to create a lightweight process under the name WP:DICKS/N. This would be an RfA-like process (in terms of organization), which would essentially be a nomination of editor for listing at WP:DICKS – a listing of people, whose behavior was found to violate WP:DICK. Wikipedia Signpost would then inform the community of successful nominations. Corresponding barnstars and userboxes should be provided.
Though this proposal might seem sarcastic or otherwise not serious, in fact I genuinely suggest this process, as being called a dick officially Wikipedia-wide might happen to be more effective even then a short-term block. This might replace WP:RFC/U as well. — Dmitrij D. Czarkoff (talk•track) 13:21, 5 September 2012 (UTC)[reply]
But the qualification for your hypothetical WP:DICKS list would have to be something like: "A clear and persistent tendency to violate WP:CIVIL". But WP:CIVIL is a WP:FIVEPILLARS matter...and if someone is violating it to a sufficient degree to get onto your list - then surely we should simply have the admins block/ban the person instead? That implies to me that your proposed solution would simply mirror WP:RfC/U - which is where such blocks and bans are currently reviewed and dealt with. Since a large part of the problem here is the proliferation of mechanisms. IMHO your suggestion only makes matters worse. SteveBaker (talk) 14:43, 6 September 2012 (UTC)[reply]
The idea is based on the assumption that nominations are deferred to WP:AN/I when administrative sanctions are needed. Effectively the list is supposed to be populated with editors who don't deserve being blocked. — Dmitrij D. Czarkoff (talk•track) 21:46, 7 September 2012 (UTC)[reply]
WQA Failure and Success
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
It would be interesting to know how many editors who have stated "WQA doesn't work" feel that way because a.) they dislike being reported there when they push the envelope, as opposed b.) they editor they reported didn't get slammed.
WQA is not ANI or ArbCom. WQA rarely has winners and losers. WQA is the anti-Thunderdome: "two editors enter, two editors leave." Boring. No stocks or public hangings. WQA is either about editors being told yea, that editor was kinda of a jerk, but that's how it is around here, or you're being kind of a jerk and it would be good if you tone it down -- sometimes concurrently. What folks don't seem to get is just because someone doesn't get the block hammer, and confess Perry Mason style -- OMG, I'm sooo sorry I was rude, I'll never, ever do it again -- doesn't mean it has no effect. A newbie finding out that someone cares, a little, if ineffectually, matters. A veteran editor who tones it down about to avoid the annoyance of yet another WQA notification, matters.
Given the lack of consensus about civility -- what it is, how to enforce it, "WQA" is going to exist somewhere. When all is said and done with the "to what" section above, it's just gonna be WQA with a different name and watchlist.
See my comments at Conditional Support above. One of the problems is that where people with a grievance arrive at the wrong forum, instead of being redirected to a more appropriate venue, many editors attempt in good faith to resolve the problem there and then. More effort should be made to send users to the right places. Most of the incivility issues probably stem initially from content disputes, and WP:DRN is possibly the best venue to attempt to resolve them. Only, and strictly only, should complaints be taken to AN/I when admin action is clearly required. Kudpung กุดผึ้ง (talk) 02:30, 21 August 2012 (UTC)[reply]
My thoughts here: I think we don't necessarialy need to redirect WQA to somewhere - I think in the first instance, we need to encourage social change (I'm starting to sound like a broken record here). On WP:MEDCAB (now closed) we detailed ways that editors can get dispute resolution - offering DRN for small disputes and MedCom for larger ones. With WQA, we can do a short writeup on why WQA was closed, what steps they can use to address the issue and maybe a link to a modified 3O if that's unsuccessful. StevenZhangHelp resolve disputes!02:36, 21 August 2012 (UTC)[reply]
An education tool that rarely works. We're thinking about things the wrong way with WQA - something else can serve the same function but not create the chaos that WQA does. I'm working on something new at WP:Sanity checks. In a nutshell - hybrid of third opinion and the {{helpme}} template - lighthearted way to say "Hey, I think we may be a bit of an issue here, can someone come along and assess it" as opposed to "USER X DID THIS AND I DONT LIKE IT" which is common on WQA. Social change is key. We made changes to DRN for August - status templates and structure. It's resulted in disputes being resolved four times faster than compared to the unchanged DRN in May, and thread size has decreased by just over 40%. Change is good. Let's work together and come up with something better. StevenZhangHelp resolve disputes!08:30, 21 August 2012 (UTC)[reply]
I think WP:Sanity checks sounds like a great idea, I think that's exactly the sort of thing that I had in mind. I'd be willing to help develop any new policy we put forward to replace WQA, should we decide to do so (and it's increasingly looking like that is in fact the case.) That being said, any "replacement" we develop or designate for WQA should keep in mind it's "educational value", i.e. teaching editors to resolve disputes and remain civil. I think friendly reminders by an outside, neutral third party would be a good way to solve a lot of problems, and, should the dispute eventually escalate to another forum, it would provide a neutral witness to shed more light on the situation as it unfolded. Cheers, Zaldax (talk) 12:17, 21 August 2012 (UTC)[reply]
I oppose the new sanity check idea. 3O can and does handle simple cases that may tangentially involve a third (or more) editor. We had a discussion about that at 3O talk a few months ago, and the general consensus was that we should not turn down a 3O on "technicalities", if we think that a 3O can be valuable to the situation at hand. There was a little dissent from one editor, but the pretty strong consensus was that 3O could indeed handle many cases that fell outside of its explicit remit.
The subset of cases where a "sanity check" could address the matter, and a 3O could not, is non-existent. A large clusterfuck of multiple editors arguing for weeks is not going to be any more receptive to a "sanity check" than it would be to a 3O. I would say the main "action item" would be to send more people to 3O and to advertise it better. And if this sanity check idea sounds good to you, come help out by giving 3Os if you don't already. Gigs (talk) 13:47, 21 August 2012 (UTC)[reply]
For convenience's sake, we could always fold Sanity Check into the 3O project, but as a subpage, or link to it from the 3O page. My primary concern is ensuring that content disputes and civility disputes don't overlap; while the two are often linked, my idea for Sanity check is to bring a cool head into the conversation to calm everyone down and get things back on track, not necessarily to solve content disputes. We really ought to discuss if we want to handle both content and behavioral disputes at 3O, and/or if we want a way of distinguishing between the two. Cheers, Zaldax (talk) 14:14, 21 August 2012 (UTC)[reply]
Third opinion never did have the artificial distinction between behavior and content disputes that most other dispute resolution processes had. And I do think the distinction is artificial, since legitimate disputes almost always involve both. If it's a purely behavioral issue not associated with any content (like personal harassment), that's the sort of thing ANI is better at anyway. Since 3O already handled all kinds of disputes, I don't think it's necessary to split them now. Gigs (talk) 14:43, 21 August 2012 (UTC)[reply]
But there's a difference between quietly handling conduct issues (or better, curing the conduct issues so the conduct issues do not have a foundation) and inviting them in. Giving an opinion about conduct, especially if it favors one side or the other, just makes it look like the opinion-giver is taking sides and weakens anything they might have to say about the content issue. That's the reason a separate 3O process for conduct is a good idea. Best regards, TransporterMan (TALK) 15:08, 21 August 2012 (UTC)[reply]
Question What's the difference between WQA and DR/N? ... There's SO many drama boards, it's hard to keep it all straight. — Ched : ? 14:41, 21 August 2012 (UTC)[reply]
So maybe merge a bunch of stuff into 3 boards: "Content issues - DRN", "Behavior issues - BRN", and "Admin issues - ARN"? — Ched : ? 17:27, 21 August 2012 (UTC)[reply]
Re:"It would be interesting to know how many editors who have stated "WQA doesn't work" feel that way because a.) they dislike being reported there when they push the envelope, as opposed b.) they editor they reported didn't get slammed.", we have an article on that: False dilemma. "...a type of logical fallacy that involves a situation in which only two alternatives are considered, when in fact there is at least one additional option." --Guy Macon (talk) 17:40, 21 August 2012 (UTC)[reply]
oppose, keep, improve. WQA is broken - but we still have a pressing need for something in this space. It ought to be possible to operate WQA (or similar) by community (and a community of editors, not of admins), without involving ANI. We also have a problem of high-handed admins who are not as the other mere editors (and have taken to acting like it). Using ANI as WQA would further encourage this separation. Andy Dingley (talk) 12:14, 28 August 2012 (UTC)[reply]
Oppose, WQA is incredibly broken in its current state and needs reform to be effective, but a lightweight forum for resolving minor conduct disputes without the considerable overhead of 3O, AN/I or RFAR is, I think, still an essential ingredient in efficient dispute resolution. Lankiveil(speak to me)09:20, 29 August 2012 (UTC).[reply]
Comment: I agree with Lankiveil. We need something that does what WQA intends to do. Or maybe WP:CIVIL just needs to be taken much more seriously? Wikipedia doesn't have a reputation as a civil and helpful community, and there's good reason for that (for all that many editors here are civil, helpful and generally awesome). Making a civil and helpful community is a hard job, Wikipedia is struggling at it, and we need every tool available to help us do that. WQA probably isn't one of those tools though, at least in its current form. --Chriswaterguytalk02:42, 30 August 2012 (UTC)[reply]
@Lankiveil - Could you comment on the "considerable overhead" of 3O? Perhaps you are confusing it wither another process. 3O is, like WQA, very simple and lightweight. It is ideally suited to handle WQA-like issues. Merging WQA and 3O makes a lot of sense, since they utilize very similar processes. --Noleander (talk) 00:33, 2 September 2012 (UTC)[reply]
Oppose closure of WQA. We do need something like this. Far less work and more likelihood of success by fixing this than by starting from scratch. And IMO it's not completely bust anyway. Certainly better than nothing; There may be a gap in what it achieves but closing it will leave a still bigger gap. Andrewa (talk) 10:51, 30 August 2012 (UTC)[reply]
The third opinion project can fill any gap that's left by WQA's closure - we need to think about how we deal with conduct issues - address the underlying issues where they originate (3O style) or "report" the matter at a noticeboard where discussion loses focus and at times becomes finger pointing. Social change, people. StevenZhangHelp resolve disputes!12:26, 30 August 2012 (UTC)[reply]
Disagree. Or at least, WP:3O is currently focussed on content. Perhaps this can be changed with the consent of the regulars there, but I doubt it should or will be, and let's deal with that if and when it happens. There comes a time when, WP:NPA and WP:AGF notwithstanding, the issue must be admitted to be behaviour. WQA is then a valuable resource. And yes, by its very nature it has problems that 3O doesn't have, but that's because it deals with trickier situations. Andrewa (talk) 19:03, 30 August 2012 (UTC)[reply]
Strong oppose WQA should exist, and it should be reformed so that it's not broken. The fewer venues which exist for dealing with dispute resolution, the greater the editor burnout at the few venues left. 3O really is focussed on content disputes, in part due to the strength of its process rules, which force narrow language choices which, if exceeded, result in the nomination being deleted from the queue without a hearing.
WQA should be 3O's complement, and perhaps become more narrowly focussed, and pipelined the same way, with a similar nomination process, so that cool heads are required. Looking at WQA discussions, I get hives: too verbose, too much "I said, they said", without just damn diffs and links. Radical changes are required: I propose them in draft form User:Lexein/NewWQA. --Lexein (talk) 02:02, 1 September 2012 (UTC)[reply]
I disagree that closing a dispute resolution forum will burnout dispute resolution volunteers - its actually more likely that the regulars who volunteered at the previous forum would migrate to the new one. Changing how WQA works would be a process change, but we need social change - to encourage people to focus on the content issues. WQA flies in the face of this idea - it encourages one to focus on one's conduct. The scope of the third opinion project has been broadened to address any minor civility issues at the point of origin. This solves another problem that exists with WQA - a user is "reported" to WQA and will instantly jump on the defensive, often will retaliate. This cannot be changed by imposing word limits or requiring doffs, it's human nature. A majority of the conduct issues reported to WQA have some underlying content dispute, so let's focus on that and deal with any conduct hiccups informally thru 3O on the article talk page so things aren't escalated. StevenZhangHelp resolve disputes!20:38, 1 September 2012 (UTC)[reply]
It's true that A majority of the conduct issues reported to WQA have some underlying content dispute, in fact the vast majority of all conduct issues have an underlying content dispute, and at any stage it's good to try to focus on content not the contributor (which is still WP:NPA in a nutshell, despite the nutshell summary having been removed [6]). But a point comes at which the problem to be addressed is behaviour. Wikipedia has never been very good at handling these situations in my experience, and removing this facility will just make us worse IMO. Andrewa (talk) 07:37, 2 September 2012 (UTC)[reply]
Comment we need some more active volunteers in this WQA section. I was really displeased when I first filed my statement, there was rarely any intervention or advice being given for both parties by an un-involved user. Some new kind of project revolving around WQA would be great to help encourage more users to help out in this section. Bleubeatle (talk) 02:48, 1 September 2012 (UTC)[reply]
Strongly oppose closure of WQA. Although not perfect, it can work. It's resolved issues for me as a newbie and later as an experienced user I've mediated WQA disputes myself. WQA can appear to be an unpleasant place sometimes, but it's a necessary outlet for these issues. Plus, closing down WQA won't actually solve anything. 3O is simply a way for two deadlocked users to get another opinion on content matters—it quite literally does not make sense as an alternative/counterpart to WQA. Also, the community has always vehemently rejected the notion that civility policing is an administrative issue, thus ANI isn't a reasonable counterpart. We can't just shut this down without a specific alternative prepared. No way. SwarmX06:53, 7 September 2012 (UTC)[reply]
WQA indeed can work - but the data I've collected as well as the personal experiences of both respondents to the survey and those commenting above indicate that a majority of time, WQA is not helpful to resolving a dispute. A few months ago, 3O would not have been a viable alternative to WQA for the reasons you describe - but if you had seen the 3O page recently, it's undergone some change to accommodate the leftovers from a closed WQA - the removal of the two editor restriction in the documentation, and a relaxing from the strict "content only" requirement. This may lead you to think "so won't the conduct traffic at 3O be as bad as it is in WQA?", and I don't think it will be. At present, an editor files a request for a third opinion on a certain page, and said third opinion is provided at the point of origin for the dispute. With WQA, User:X reports User:Y to a noticeboard, and the discussion can veer off topic and become retrospective, and thats because we have shifted locations and fragmented discussion. 3O had the best success rate out of all the DR forums analysed in May, where WQA had the worst, and I think it is for the reasons I outlined above. While the community has in the past discussed the issue of policing civility ad nauseum, I don't think this proposal is about that. It's about addressing a forum that has had problems for years, and these problems are social ones. Closing WQA (while having some alternative) will in my mind encourage such change. We need to ask if we want to continue handling disputes in such a retrospective manner. I think the answer should be no. And if this doesn't go to plan, we can always rethink, but I don't think imposing diff requirements, word limits or huge edit notices saying "PLEASE BE CIVIL" will do the job. We need to bin the whole thing - send a clear message. StevenZhangHelp resolve disputes!14:08, 7 September 2012 (UTC)[reply]
Oppose closure of WQA. Redirecting to AN/I is a terrible idea. As for expanding 3O to take over the role of WQA, there seems to be some degree of resistance at the 3O talk page to this idea, and the removal of the two editor restriction from WP:3O was reverted pending further discussion. Better leave WQA where it is and work to imprive it in situ. Gandalf61 (talk) 11:31, 11 September 2012 (UTC)[reply]
The proposal makes it clear that WQA would not be redirectedto AN/I, so that is a bit of a red-herring. As for 3O: The discussions at 3O have, so far, decided that the main 3O page would not handle disputes exclusively about user conduct. But those very same discussions pointed out that the vast majority of "behavior disputes" (over 90%, I'd guess) are based on an underlying content issue, and those "mixed" disputes would be welcome at 3O. For the handful of disputes that are pure-behavior: the community needs to decide what to do with them. My personal opinion is that a sub-process should be established under 3O that handles pure-behavior disputes (so there is one-stop shopping), but there are other approaches as well. The top priority is to streamline the entire WP dispute resolution process: and that means trimming down the number of noticeboards, which is far too high now. --Noleander (talk) 15:29, 14 September 2012 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
To those who dislike WQA
Of those who want to shut Wikiquette assistance down, how many of you actually are volunteering there? As as the previous section asks, how do you determine success or failure? I've seen many instances where people are helped, where people learn more about policies and how to interact, and you're simply talking about shutting this forum down, yet I don't really think I've seen a lot of you drop in and volunteer your time there. I'd say as long as people are willing to help mediate at WQA, it should stay open. It isn't the job of a bunch of strong-armed opinion makers to shut down something where people regularly volunteer, and where some measure of success can be seen without at least coming up with a viable alternate FIRST. -- Avanu (talk) 22:50, 1 September 2012 (UTC)[reply]
Perception is everything. Perhaps the reason that people don't volunteer at WQA is because they feel it's a giant waste of time. Everyone's entitled to their opinion - telling people that they can't have a say because they haven't volunteered at WQA is not reasonable in my opinion. StevenZhangHelp resolve disputes!22:59, 1 September 2012 (UTC)[reply]
I think they absolutely can have a say, but unless they are volunteering or checking in regularly, their opinion is much less well informed, and as such, should only be given the weight it is due. -- Avanu (talk) 23:09, 1 September 2012 (UTC)[reply]
@Avanu: I respect all the work done at WQA by editors such as yourself (speaking for myself: I mostly do RfC work, not WQA). However, I did !vote above to close it. My reasoning is that WP is not very friendly when it comes to dispute resolution: the biggest problem is that there are too many forums. You raise a good point about volunteer burnout: would that problem get worse if the number of forums were reduced? My opinion is that reducing the number of forums would actually help volunteers, by giving them more guidance, by having more volunteers share the workload in a few areas, and by enabling volunteers to help each other. I don't think of it as closing WQA, but rather merging it WQA with 3O. --Noleander (talk) 00:30, 2 September 2012 (UTC)[reply]
2 things, that map the problem (and solution). 1) {{Noticeboard links}} footer (huge and overwhelming. We need to merge some, badly), and 2) {{Dispute-resolution}} sidebar shows the current recommended flowchart. As long as something comes before ANI and RFC/UC then the actual location is irrelevant - a broad & active set of people to give feedback, is all that is required. In an ideal situation, all the editors currently using WQA at its best, will move on to (WP:3O or wherever) and continue giving great advice there. -- Quiddity (talk) 00:49, 3 September 2012 (UTC)[reply]
Close it. I didn't have much of an opinion on this until a few minutes ago, but it's doing substantially worse than other venues in terms "customer" satisfaction; see Wikipedia:Dispute Resolution Improvement Project/Newsletter. It's a trap for the unwary, basically. [And feel free to move this post to whichever section of this rather unwieldy discussion it's supposed to go in.] Tijfo098 (talk) 19:56, 4 September 2012 (UTC)[reply]
I've already !voted, so I'll say this: those who already have the skill and knowledge to work on help desks and notice boards already are, so criticising us for not working on WQA as well is a strawman argument. WQA is redundant, and those working at DRN or 3O could easily absorb the work, and probably would. The proof is that our work at WP:EAR, for example, although we are still busy there, has dropped considerably (thankfully) since DRN was inaugurated. The other fact though, is that at EAR we still get people coming there with issues that are clearly for the other forums - again more indication that we have too many noticeboards. I once suggested a single central ticketing system for all noticeboards, but the idea was scoffed at (probably the true reason was that it would need WMF help and a couple of hundred dollars to develop) Kudpung กุดผึ้ง (talk) 11:07, 13 September 2012 (UTC)[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Orange fixit box on mainpage
Hi all, I originally floated this idea at Talk:Main_Page/Archive_165#An_idea_for_converting_readers_to_editors....3F and gathered some positive feedback there but nothing eventuated, so I will structure it a bit better here. The idea is to try and engage more readers into writers (but try and do it a bit better than it was done many moons ago.
So we have a small pale orange box which lists maybe 2-5 articles identified as good, broad candidates for fixing - thus maybe articles such as pink, North Island or Screwdriver rather than, say, quantum theory or some esoteric maths/physics/ sociology etc. We select them on a page similar to Wikipedia:Today's featured article/requests and load them up for 24 hours. The aim would be to see how many constructive edits we could get to articles.
Other question is, how would we fit it in...so folks can vote below....If cautious, we could run as a three month trial only, so if you oppose setting it in stone it'd be great to at least give it a time-limited trial.Casliber (talk·contribs) 01:46, 25 August 2012 (UTC)[reply]
Support
I think this would be a good idea - we could do it as a banner ad - "Here's five articles that could use improvement - please join us and help us build this encyclopedia" or something. Maybe put a banner on the left side by the toolbox links that would only show to IP users. Ego White Tray (talk) 04:19, 25 August 2012 (UTC)[reply]
I think this is the best suggestion for converting readers into editors that I've heard for a long time. If we could organize a "coaching" team - of Wikipedians with a reputation for helping newbies and not biting them then we could shepherd them through the process. So instead of getting a wild collection of crappy edits that would have to be reverted, we could encourage people through the process. Adjusting the number of articles presented (and picking the kind that newbies do best at) would allow us to control the flood of edits to those small numbers of articles. We could even have the links go to "sandbox" versions of those articles, which the shepherding Wikipedians could "promote" to the live articles when they feel that a good point has been reached. That would imply less panicky reversions and allow more time for constructive advice. At any rate, I think it's well worth some serious discussion followed by a trial period. SteveBaker (talk) 14:25, 25 August 2012 (UTC)[reply]
The above comes across as a radically different (and much better) proposal — one to develop a process in which newcomers are given advice and assistance instead of being sent to "shoddy" articles with the vague instruction to improve them. —David Levy15:42, 25 August 2012 (UTC)[reply]
I agree it has merit - does the Wikipedia:Teahouse have sufficient emphasis on article work? I have not looked at that aspect in detail.....I know it is a focussed place to help new editors and seems to be helping with retention rates, so building on this is a very good idea. Casliber (talk·contribs) 10:18, 26 August 2012 (UTC)[reply]
This is an interesting idea, and well worth giving it a trial. There would be nothing to lose (any vandalism likely would be watched and reverted quickly) and much to gain (new editors). We need to be more open to finding ways to attract new editors. First Light (talk) 15:15, 27 August 2012 (UTC)[reply]
Did you read my comments (in which I explained why I believe that we would lose potential editors, whom the proposed setup would frustrate, confuse and alienate)? If so, I'm interested in learning why you disagree. —David Levy15:48, 27 August 2012 (UTC)[reply]
Tentative support as a trial - As long as it's clear that the over-riding main goal here is to provide opportunities for editors to help edit the encyclopedia. I can think of several ways to implement this, but I'll save that for some other discussion : ) - jc3717:17, 27 August 2012 (UTC)[reply]
A small box, as described, would fit to the right of "Other areas of Wikipedia" (at the bottom) without making the page much busier than it is. All the best, Miniapolis (talk) 13:54, 29 August 2012 (UTC)[reply]
Tentative support as a trial. After reading all the good pro and con arguments, I'm supporting a trial period because there is merit in this idea. Having such a box may attract new editors, but also bring it to the attention of experienced editors who may be induced to improve the articles. I like to see a trial period only, because we don't know if it will work or just attract vandalism and/or unconstructive edits. If it doesn't work out, we can stop the trial before we lose to many frustrated editors (as referred to by David Levy. -- P 1 9 9✉23:43, 29 August 2012 (UTC)[reply]
How would experienced editors benefit from such a setup? They can easily find articles in need of improvement (including ones whose topics interest them) via other means. You note that "if it doesn't work out, we can stop the trial before we lose too many frustrated editors". But how will we know how many users are leaving in frustration stemming from edit conflicts? (They might not even manage to edit before this occurs.) —David Levy20:21, 4 September 2012 (UTC)[reply]
Tentative support as a trial I was thinking about how we could use banner ads to encourage more editors yesterday, in fact, and am glad to see this here. Word it so people will feel their contributions are important somehow... it doesn't need to be for all viewers, either, right? They have the ability to try it on 1% or so of people to figure out how well it can work without a major rush of potential vandalism. PhnomPencil (✉)04:21, 1 September 2012 (UTC)[reply]
Support as a trial. The six content boxes ensure that relatively polished content attracts a lot of attention, and I'm completely unconvinced by the suggestion that we should deliberately give the impression that most of our content is brilliant. I see that as counterproductive.
David Levy correctly points out that people prefer to contribute to prominent topics which they can easily add to, but the solution is to prioritise plugging those sorts of gaps. To my knowledge, there are no glossaries at Wikipedia:Featured Lists – in my experience some worthwhile glossaries haven't even been created yet, and they make great collaborations. List of national flags currently redirects to Gallery of sovereign-state flags: surely there is room for the redirect to become a vexillology list, and I can't think of a better way to kick it off than by asking for help on a high profile international page. There is also plenty of low-hanging fruit at Wikipedia:Vital articles/Expanded, such as East and square mile.
I do recognise many of David's concerns. In particular, we would need to carefully monitor what help is given to those who land on the page: would we need special edit notices for instance? Or a dedicated help banner at the top of that article? These things would need to be worked out before the trial started. But weighing the worries against the potential benefits in content improvement and editor recruitment/retention, I can't see a good reason not to at least try this. —WFC— 21:03, 1 September 2012 (UTC)[reply]
Support trial It would be nice for everyone to get a sense of what others see as lacking. May recruit good people. May develop as an episodic addition to the main page.
Support trial One of the biggest hurdles new contributors face is not knowing what is best to help work on. For many years now, we have removed any substantial mention of community work that needs doing from the Main Page and moved it to the Community Portal. With the number of active editors shrinking, I think it's time the Main Page got an invitation to help included again. I'd also like to offer my help with such a trial, as part of my work at the Foundation on the experiments team. Steven Walling • talk00:36, 3 September 2012 (UTC)[reply]
I support the idea of actively recruiting new editors via the main page. But why, in your view, does it make sense to send them directly to articles without any guidance beyond a vague instruction to improve them? —David Levy20:21, 4 September 2012 (UTC)[reply]
There are many types of people who could possibly register, but we know that there are two types that definitely make up some of new editors: A) people who've edited anonymously before, and have gained some experience even if it appears they are new, and B) people interested and knowledgeable about the subject at hand. People in the first category have some basic editing skill, but need to figure out the subject matter and how to deal with it. People in the latter category just need editing skills. How people learn these two things is by doing. If there are articles that need obvious help (i.e. not asking for GA/FA here), and there are people who are willing, we should be definitely directing new editors there. There is too much that needs cleanup for us to wait for every new person to become an expert editor before diving in to serious work. Steven Walling • talk21:45, 9 September 2012 (UTC)[reply]
If there are articles that need obvious help (i.e. not asking for GA/FA here), and there are people who are willing, we should be definitely directing new editors there. But why should we discourage them gaining a basic understanding of Wikipedia's editorial practices first? There is too much that needs cleanup for us to wait for every new person to become an expert editor before diving in to serious work. Who said anything about "expert editors"? I've repeatedly and unambiguously referred to "a basic understanding". We don't require users to read the introductory pages, but nor do we instruct them to skip directly to editing instead. That's what's been proposed here. Readers arriving at the main page would be told to ignore the help pages and jump straight to editing. Why is that desirable? And what about the edit conflicts? —David Levy05:23, 12 September 2012 (UTC)[reply]
Support trial, the Ambassador program had a lot of success with events where experienced got together to work on articles. One article that turned out really well is Tradition, though not a GA or FA by any means, it became a much more useful and well rounded article because of the editing team, Sadads (talk) 17:53, 3 September 2012 (UTC)[reply]
You meant to write "experienced editors", yes? (That seems consistent with the explanation provided at Wikipedia:Ambassadors/Editing Fridays.) How is that relevant to a proposal to send newcomers to articles, with no preparation apart from a vague instruction to improve them? —David Levy20:21, 4 September 2012 (UTC)[reply]
Generally, we have millions of people who have created accounts which means they are mildly aware of the opportunity to contribute. Inviting people to improve (and presumably having links to learn how to improve or find a tutorial in the box), would encourage them to reengage, and help make the public a little bit more aware that an editing community exists (which most people are ignorant of), whether or not they help contribute. Did you read how I said "trial"? If there is a serious problem that arises with this action, then we put a stop to it, but for now I am going to be influenced by the attempt to do good, instead of being a Debby downer. There is always the possibility of unintended positive consequences to every attempt at greater inclusion! Sadads (talk) 19:41, 13 September 2012 (UTC)[reply]
You've addressed a straw man instead of the actual arguments against the proposal (based upon concerns that the new editors will be adversely affected, not that they pose a threat). —David Levy20:21, 4 September 2012 (UTC)[reply]
Tentative support of trial with the condition that it is toward the bottom of the main page, not the top. We don't want the first thing people see to be "here's some crap that needs shoveled, have at it." --Nouniquenames (talk) 14:47, 10 September 2012 (UTC)[reply]
Oppose
We already encourage editing, less directly, by prominently referring to Wikipedia as "the free encyclopedia that anyone can edit" (linked to Wikipedia:Introduction) and linking to numerous editable articles. The concern, I take it, is that some potential editors are reluctant to dive in. But that isn't entirely bad, as this motivates them to familiarize themselves with our basic principles and practices beforehand. Sending newcomers directly to articles specifically for the purpose of editing them will generate primarily unhelpful (even if well-intentioned) results. And when we have to revert the good-faith (but inappropriate) changes, many of these users will become discouraged and never edit again. This already occurs to some extent (an unavoidable consequence of operating a wiki), and I see no reason to exacerbate the problem. —David Levy02:20, 25 August 2012 (UTC)[reply]
But what we're doing patently isn't working. We're losing editors at an unprecedented rate - while the encyclopedia continues to grow and need more maintainers. We do need a new approach of some kind. The "status quo" argument doesn't hold water. I have some ideas for improving this proposal that may get around some of your concerns...see my "Support" !vote above. SteveBaker (talk) 14:30, 25 August 2012 (UTC)[reply]
But what we're doing patently isn't working. We're losing editors at an unprecedented rate - while the encyclopedia continues to grow and need more maintainers. Much of that decline is attributable to the fact that fewer and fewer topics (particularly those widely familiar to persons fluent in English — an unavoidable systemic bias) have yet to be covered. It's unfortunate that editors are departing, but it's fallacious to assume that we're failing them in some way. For better of worse, many people simply aren't interested in sticking around to maintain articles. We do need a new approach of some kind. The "status quo" argument doesn't hold water. It's an argument that I haven't made. I don't oppose the idea of expanding efforts to recruit new editors, including on the main page. I oppose this proposal to send unprepared newcomers directly to "shoddy" articles with the vague instruction to improve them. I have some ideas for improving this proposal that may get around some of your concerns...see my "Support" !vote above. I don't believe that your ideas belong under the "Support" heading, as they appear to constitute a radically different (and much better) proposal. —David Levy15:42, 25 August 2012 (UTC)[reply]
Much of that decline is attributable to the fact that fewer and fewer topics (particularly those widely familiar to persons fluent in English — an unavoidable systemic bias) have yet to be covered. That has got be stopped being used as an argument across Wikipedia. It is simply not true. There are so many articles on "mainsteam" concepts that have very bad content, that nobody knows about or bothers to change. Habitat, Daughter, Son (actually, all the family articles are rubbish at the moment - things that you would've thought would be some of the first concepts to have articles created), human body, sadness (a lot of the emotion articles are rubbish too), analysis, letter (alphabet)... and the list goes on and on. The point is that these article were created once upon a time probably like 6 years ago, and then fiddled with with minor edits up until now, with the quality basically unchanged. There are sooo many articles like this lying around that noone know/care about. I think in general people are scared of the more general topics so focus on the more obscure, specific stuff. You only know what to include in art until you've made articles on all the different types of art, right? But we can let that fear go away, by making this sort of thing the norm. I had a similar proposal about half a year ago and that got shut down. Don't let this one get shot down too. It will help immensely in the process of converting readers to editors (or, in my vocabulary, allow people to realise that there is no dichotomy, and that they are in fact edi-readers). Why not bring important topics to peoples attention and get them going? --Coin945 (talk) 17:08, 25 August 2012 (UTC)[reply]
That has got be stopped being used as an argument across Wikipedia. It is simply not true. You dispute the assertion that fewer notable topics (particularly those of greatest interest to the site's editors) lack English Wikipedia articles than did before? There are so many articles on "mainsteam" concepts that have very bad content, that nobody knows about or bothers to change. I'm well aware that much of the encyclopedia is in a state of disrepair. As I noted, "many people simply aren't interested in sticking around to maintain articles". At some point, Wikipedia lacked the 697 articles currently tagged by WikiProject Buffyverse. Fans of the Buffyverse have striven to ensure that a Wikipedia article be written for every series, film, television episode, book, music album, video game, major character (and actor portraying him/her) and notable behind-the-scenes contributor. Are all of these articles in good shape? No, of course not. Here's one that I loaded at random. It's just sitting there, tagged for multiple issues (as is the Buffyverse article, I noticed). I'm sure that certain members of the aforementioned WikiProject are working on improving these articles. Other editors, conversely, set out to author unsourced plot summaries and never intended to contribute anything else. As far as they're concerned, now that the articles have been written, their work here is done. We did nothing to drive away these individuals. Why not bring important topics to peoples attention and get them going? We should, but not in the manner proposed above. —David Levy21:19, 25 August 2012 (UTC)[reply]
Right now the main page gives Wikipedia a certain polished respectability. Adding a box implicating that we're broken and need fixing may discourage those who actually want to use it as an encyclopedia. In business we call it, "airing our dirty laundry"; it's generally not something you want to do. Beyond that, I'm in accord with David above. Sending new editors to the introduction page has the helpful benefit of exposing newcomers to the Wikipedia philosophy. On the other hand, adding a big Try it! button that spoon fed a candidate editor through the process of picking a few pages to edit would probably be good. I don't why we don't have a simple device like that already. Regards, RJH (talk) 16:41, 25 August 2012 (UTC)[reply]
Wikipedia is a work-in-progress. It is not finished. Why are we presenting ourselves to the public as if we are? And when you start to bring the public into the picture, you get an even more important question: why are we excluding our readers (our potential editors) from the site? We set up this horrifically bureaucratic system, totally unwelcoming to newbies because we create this huge dichotomy of editors & readers (even thoguh in reality they're one in the same), and then moan and complain when everyone starts to leave. Hmmm... i wonder why. I say there's nothing wrong at all with showing off our "dirty laundry". We are not supposed to be perfect or complete. That is false advertising. If anyone wants my opinion, that's the sole reason why Wikipedia gets so many complaints about false/misleading information - we "claim" to be this brilliant complete source (through both what we do say... and what we choose not to), and then not deliver in many respects. There is something so intrinsically wrong with this sentiment, and noone has been able to change it. Actually i kid. Many have tried, but they are stopped by the worst philosophy of all in modern-day Wiki... which brings me back to the other point: why don't we (instead of chatting about all this theoretically, which is unfortunately what wiki has become: a place of all chat and no action), just charge head and see how it goes? It may fail miserably, yes indeed. But there's only 1 way to know for sure.--Coin945 (talk) 17:19, 25 August 2012 (UTC)[reply]
Wikipedia is a work-in-progress. It is not finished. Why are we presenting ourselves to the public as if we are? On several occasions, I've expressed the opinion that we should convey this more clearly on the main page. In particular, I've supported the idea of displaying the featured article and good article counts alongside the total article count (mock-up), thereby eliminating the implication that we care solely about quantity (as conveyed by the message's current text, in which featured articles, unsourced stubs and everything in between are lumped together as "6,855,895 articles in English"). And when you start to bring the public into the picture, you get an even more important question: why are we excluding our readers (our potential editors) from the site? I agree that we should do more to recruit new editors. Sending newcomers, en masse, directly to "shoddy" articles, with the vague instruction to improve them (despite their unfamiliarity with Wikipedia's editorial standards, which obviously can't be extrapolated from the articles themselves) is not a viable means of accomplishing this. It strikes me as a surefire way to lose potential editors (for the reasons that I've cited). why don't we (instead of chatting about all this theoretically, which is unfortunately what wiki has become: a place of all chat and no action), just charge head and see how it goes? That might have made sense a decade ago, but a community of this size is unsustainable under such a system. If we were to simply implement every big idea (even on a trial basis), the site would collapse under their weight. I agree that we sometimes get hung up on bureaucracy, but some discussion/filtration is essential. —David Levy21:19, 25 August 2012 (UTC)[reply]
Oppose. The front page is our opportunity to put our best work forward. Putting articles in trouble there isn't conductive to that. Nearly everyone knows they CAN edit Wikipedia, that isn't really the issue. Andrew Lenahan - Starblind14:48, 29 August 2012 (UTC)[reply]
Readers of the English Wikipedia who don't visit the main page
Readers of the English Wikipedia who visit the main page but fail to notice/understand the prominent "free encyclopedia that anyone can edit" description at the top
There's no reason to believe that the proposed change would assist any of these individuals in realizing that they can edit the site. (I realize that you were addressing a more general statement, so my reply isn't intended to rebut yours.) —David Levy13:25, 30 August 2012 (UTC)[reply]
Discuss
So David, you're opposed to even a trial of it? Even with some shoddy pages and a bunch of watchers just to see what happens? Actually we should get some figures on who goes from mainpage to introduction page and thence elsewhere.....Casliber (talk·contribs) 07:35, 25 August 2012 (UTC)[reply]
Yes, I oppose a trial. I disagree that sending newcomers directly to "shoddy" articles (from which a basic understanding of Wikipedia's editorial expectations can't even be extrapolated) is desirable. They won't know what's expected of them, so most of their contributions will be reverted, tagged or removed. Additionally, they'll become confused/annoyed upon encountering endless edit conflicts. That's why it's unhelpful for a large number of people — irrespective of knowledge/experience — to edit a particular article or handful of articles simultaneously. This situation, which is incredibly frustrating (even to longtime editors) arises naturally in articles about current/recent events. I see no reason to deliberately manufacture such a scenario in arbitrary articles, let alone bad articles edited by users who don't even know what an "edit conflict" is. —David Levy14:22, 25 August 2012 (UTC)[reply]
I think Caliber's choice of the word "shoddy" is a poor one. We would need to discuss what kinds of articles need this kind of support. Clearly we wouldn't want very obscure topics...and certainly not horribly controversial ones...but also not articles that are already very high quality. But there are plenty of articles out there that languish from lack of editors but aren't horrible.
I propose that we have the corresponding Talk pages be pre-loaded with welcoming, experienced Wikipedians (I'm going to call them "Shepherds") - who (let us suppose) have been discussing the article there for a day or two before the article is promoted. That way, the newbies will arrive to a welcoming, non-controversial editing environment, with gentle expert editors to guide them rather than a shark-tank.
The issue of having large numbers of people flood a single article can be controlled by removing each article from the front page once edits from...oh...20 new editors have been made? Cycling through a large number of articles in this way would help spread the load. We could also consider linking the "EDIT ME!" link on the front page to a sand-box - rather than to the actual, live article. The 'Shepherds' would be responsible for replacing the 'live' article with the sand-box changes whenever they feel it's better. So reversion won't have to be urgent and violent.
Shepherds would be instructed to explain policy issues rather than using curt and cryptic "WP:RS" or "WP:NOR" links as a shorthand.
I believe that a short trial would teach us a lot about how to make this work.
I don't oppose the idea of expanding efforts to recruit new editors, including on the main page. I oppose the idea of sending newcomers directly to articles with the vague instruction to improve them.
A hypothetical orange box should instead lead to an area in which potential editors are guided step by step (beginning with a basic explanation of Wikipedia's practices, with which they should be familiar before they're tasked with editing the carefully selected articles). And instead of listing articles to be edited, the box could contain a list of articles recently improved via the process. (This would provide helpful examples of what we hope to achieve and a reward/incentive.) —David Levy15:42, 25 August 2012 (UTC)[reply]
Casliber et al, are you aware of Wikipedia:Today's article for improvement? (I noticed this advertised on a talk page.) It has a similar goal. Rambling from here out: (hopeful:) I'm all for trying something different. (skeptical:) Even though I agree with David Levy on the particular problems, (hopeful:) would an experiment be the end of the world? Past sub-pages that ask people to improve content have suffered from randomness and too many choices. (See the link to someone's redesign in the other discussion section: too many choices!) (skeptical:) The larger problem with any initiative of this type is that Wikipedia editing has frankly become a specialty. If you ask previously uninvolved visitors to improve screwdriver, they may offer many good-faith contributions, and they'll promptly be reverted by gatekeepers for being unreferenced, etc. I see a number of 'unproven' assumptions in this discussion, and one of my unproven assumptions is that the number of people who are willing and able to contribute substantively to Wikipedia in a way that follows all of its 2012 policies and norms is just vanishingly small. (On norms, compare the degree to which citation is "enforced" by the community now versus 2007, even though the policy still says "likely to be challenged".) (hopeful:) I'd still like to see something like this go up on the main page for a few days to prove that change control and the status quo on this project have not ground experimentation to an absolute halt. It has merits and demerits: try it. Clearly with a tight focus knowledgeable editors can be there to "steward" new editors. An edit notice could be placed on the chosen article outlining a few broad principles for editing in plain English, and explaining how the particular article could be improved in terms that non-insiders can relate to. I mean, I look at screwdriver and I wouldn't know where to start (except for the generic "improve references" trope, or the "copyediting and formatting" tropes, which are all things that insiders understand, but they're not teasers for new editors; "tell us what you know about" is the teaser, and yet (skeptical:) the norm in 2012 is "we could care less what youknow!"). Riggr Mortis (talk) 07:09, 26 August 2012 (UTC)[reply]
@Riggr - wow, I hadn't seen that! I intend to take a closer look....@David, I do concede alot of what you're saying about the potential for blind reverts and edit conflicts. The optimist was hoping that maybe added scrutiny by some more constructive editors at the time the article was linked might mean a scramble to look for sources of material that people add rather than just reversion. This is why I was thinking of broad articles. Anyway, if other ideas which are radically different to my intiial proposal come out of this, I don't mind in the slightest. I don't own this idea and I am happy to try some alternatives. I'll take a look at the community portal revamp when I can. Casliber (talk·contribs) 13:43, 26 August 2012 (UTC)[reply]
I like the idea of providing more "Become an editor, here's how [easy it is]" links on the Main Page. But I think there may be better methods/designs to do so. Eg.
See the "About Wikipedia" box at the bottom of WP:2012 main page redesign proposal/Pretzels for a particularly good idea, with 3 sections of helpful pointers (readers/new-editors/regular-editors) - [The links that are chosen would all need to be re-examined, as his draft was primarily focused on layout and overall-ideas; but the "3 sections" is a good direction to think in, that the Help Project is also considering using for redesigning the main Help:Contents page, in the near future). (also see WP:2012 main page redesign proposal for more design ideas, and much discussion on the talkpage).
See User:Maryana (WMF)/opentask for a redesign that is (soon) to be placed in the top of the WP:Community portal, as part of the ongoing WP:Community portal/Redesign 2012. Using the Community Portal for specific article suggestions (as it has in the past) would be good, but getting new editors to glance at the WP:Introduction or WP:Cheatsheet (or similar) first is crucial. Less is more.
I haven't read the whole thing yet, but this would probably be the best way to interlap with PC. So if the wiki is worried about a bunch of bad edits, we could coach, but also, should a fixit box be displayed, then maybe pending changes could be a way to help out. I still have to read the rest though. Mysterytrey21:38, 27 August 2012 (UTC)[reply]
I like the concept as a good contrast to the overly perfectionist tendencies found with FAs. But there are likely to be practical problems such as edit conflicts because the process will encourage many editors to rush at the article at once and so there will be too many cooks. Warden (talk) 21:38, 27 August 2012 (UTC)[reply]
Interesting concept, but I'll say this: based on my experiences dealing with newbies while doing RC patrol, WP:AFC, monitoring those articles on my watchlist, and other places, I would prefer to direct them to the help pages, tutorials, and policy pages first. If I wanted an article improved (especially a broad article on my watchlist), I would instead seek out established editors on the relevant Wikiproject, peer review, WP:GA, or WP:FAC (if applicable) – not have a bunch of newbies, unfamiliar with the GA and FA criteria, rush in at once. Zzyzx11 (talk) 04:48, 29 August 2012 (UTC)[reply]
Not to be rude... but that's an awful idea. Those policy and help pages are long, confusing and generally overwhelming. If this was a group of people we wanted to discourage based on policy, like someone trying to add links to Facebook everywhere, then sending them to those pages is the perfect way to do it. But this a group of people who we theoretically want to just try out editing, and then get them to then take on more serious, complex tasks that require deep knowledge of policy. The kind of people who will look at a list of articles needing simple improvement, and then decide to help are the kind we want to encourage the most. Steven Walling • talk04:16, 3 September 2012 (UTC)[reply]
My vision is that we let editors loose on an article which has a basic structure but a lot of missing content (something like this, for instance?), and worry about Manual of Style issues etc one it is off the Main Page. Edit conflicts are a legitimate concern, but it's worth pointing out that we have no qualms about giving (often unprotected) news items prime placement. —WFC— 21:17, 1 September 2012 (UTC)[reply]
My vision is that we let editors loose on an article which has a basic structure but a lot of missing content (something like this, for instance?), and worry about Manual of Style issues etc one it is off the Main Page. What about unsourced statements and original research? Should we refrain from removing/tagging them? (To be clear, this is a sincere question; I'm not being sarcastic.) My main concern isn't that the articles will temporarily receive a few blemishes. It's that new editors, few of whom are familiar with Wikipedia's practices, will become discouraged (and never edit again) when their contributions are reverted or otherwise deemed problematic (even if this occurs after the article's main page appearance). This already is a very real problem, and I see no reason to exacerbate it by encouraging newcomers to edit articles without first gaining a basic understanding of our expectations. Edit conflicts are a legitimate concern, but it's worth pointing out that we have no qualms about giving (often unprotected) news items prime placement. And the resultant edit conflicts can be downright nightmarish, despite the fact that we aren't instructing readers to edit those articles. —David Levy17:58, 2 September 2012 (UTC)[reply]
The only way to prevent IP editors' feelings from getting hurt through policy-based reverts would be to restrict editing to registered accounts only (on a sitewide basis). We could do that very easily, but it would become harder to claim that we are still the encyclopaedia anyone can edit.
As for your comment on edit conflicts, I'm extremely confident that this section would receive significantly fewer edits than an ITN item. If it was proven at trial that this assumption is wrong then I would probably oppose the section becoming permanent. Besides, we're going for a different type of editor here. I hesitate to use the phrase "quality over quantity", because that would be unfair to the IPs who on balance contribute a lot to news related articles. But topical articles are edited by people who want to break news, and need little further encouragement to edit. This section would be aimed towards people who don't edit because they don't feel that there is much left to contribute, but who could be attracted to the site through the traditional charm of Wikipedia: seeing glaring omissions in content and deciding to help fill them. —WFC— 23:27, 2 September 2012 (UTC) (italic text added —WFC— 23:29, 2 September 2012 (UTC))[reply]
The only way to prevent IP editors' feelings from getting hurt through policy-based reverts would be to restrict editing to registered accounts only (on a sitewide basis). And even then, the problem would persist among newcomers with registered accounts. As I noted above, it's an unavoidable consequence of operating a wiki. No matter what we do, some users will jump directly to editing (without first gaining a basic understanding of Wikipedia's practices). And of them, some will become frustrated and discouraged when their contributions are reverted or tagged. But we needn't encourage this approach. That's my point. The proposed setup literally would instruct readers arriving at the main page to begin editing articles without first visiting the various help pages available. Supporters are focusing on the importance of recruiting new editors, and I agree. I also agree that this should be done via the main page. But no one is explaining why it would be beneficial to send newcomers directly to articles to be edited instead of a tutorial or training ground. And no one has commented on the alternative format that I suggested. As for your comment on edit conflicts, I'm extremely confident that this section would receive significantly fewer edits than an ITN item. Are you referring to the articles themselves? If so, that seems like a very low conversion rate (not that a high conversion rate would produce better results). Honestly, I want us to attract lots of new editors via the main page. I just don't understand why they should be encouraged to edit immediately (without preparation of any kind). —David Levy02:11, 3 September 2012 (UTC)[reply]
What generally happens with ITN stories is that a development to the story breaks, there is a 15-30 minute flurry, and then the editing slows to a realtively steady stream or trickle (depending on how prominent the story is) until the next major update. With this proposal we wouldn't have those spikes, which would account for the lower edit rate (and fewer edit conflicts). The other thing to bear in mind about ITN is that IP editors generally click on the page with the intention of checking that the latest development is in there, and then decide to add it themselves if it isn't. In other words, it generally attracts those who are already hooked on the "anyone can edit" concept, but for whatever reason don't want to sign up. It can reasonably be assumed that 95% of IP edits to a page under this sort of system would not have otherwise happened: fewer edits than ITN would therefore not automatically be a failure. —WFC— 06:35, 3 September 2012 (UTC)[reply]
With this proposal we wouldn't have those spikes, which would account for the lower edit rate (and fewer edit conflicts). But we don't instruct readers to edit the articles linked from ITN. In my experience, if a dozen people are trying to edit an article simultaneously, the resultant edit conflicts are incredibly frustrating (even for someone who understands why they're occurring, which newcomers probably won't). The main page averages roughly 5,000 views per minute, so if an orange box explicitly inviting readers to edit a handful of specific articles were to fail to accumulate a dozen simultaneous participants per article, that would constitute a failure in my book. (But again, success would be problematic too.) —David Levy07:39, 3 September 2012 (UTC)[reply]
In response to your question about why we don't send them to a tutorial, my view is that we want them to prominently see the help (via an editnotice and a banner/template at the top of the article). But ultimately I believe the balance should be "we are inviting you to edit this article. All the help, support and information you need can be found here." rather than "Help, support and editing advice can be found here. Once you have read that, we will disclose the location of an article where we can test what you know about Wikipedia." —WFC— 06:35, 3 September 2012 (UTC)[reply]
Comment: Hey. I just wanted to say that, with the amount of visits that our Main Page gets, you won't need three months to see if people will click on and actually do the tasks in a list. I'd suggest that you split up each month to test a different strategy to try and engage new contributors. Steven Walling • talk04:11, 3 September 2012 (UTC)[reply]
I think we should make the box dynamic and geotarget visitors IP, like WP:GEONOTICE does. So an editor from Ireland would see the article on Ireland as neededing improvement, but somebody from Hawaii would see Hawaii, and so on. Could use GAs from corresponding WikiProjects for a wider selection. --Piotr Konieczny aka Prokonsul Piotrus| reply here15:46, 11 September 2012 (UTC)[reply]
Proposal: enable HotCat for all editors by default
I think that Wikipedia:HotCat is a very useful gadget. It makes adding categories much easier. It is enabled by default on pl wikipedia. Why not on en wikipedia? It is a pure UI improvement. A lot of new or first time editors I talk with complain they cannot "tag" Wikipedia articles, and when I shown them the HotCat they ask me why such a useful tool it hidden in the depths of the preferences. Let's make it available to all by default (most inexperienced editors don't bother with preferences). --Piotr Konieczny aka Prokonsul Piotrus| reply here18:02, 26 August 2012 (UTC)[reply]
Oppose. It allows category removal with one click, no confirmation. Readers should not have a default setting that will cause them to edit accidentally, either due to stray clicks or 'what does that (-) mean' curiosity. They might not even notice after the fact that they edited the page until they get a warning for it. Kilopi (talk) 04:05, 27 August 2012 (UTC)[reply]
Strong Oppose - And further, there should be a way for admins to remove the ability from editors when it's abused, just like rollback can be. - jc3717:02, 27 August 2012 (UTC)[reply]
You know, you might get more conditional support for your proposals if you weren't so unconditionally negative about others' proposals. Why not say "Conditional support if a save step is added, and if admins had a way to remove the ability from editors when it's abused, just like rollback can be." --Timeshifter (talk) 15:29, 28 August 2012 (UTC)[reply]
First, I have commented on several proposals on this page alone, varying from support to oppose. But even if I hadn't, these aren't popularity contests, nor should they ever be quid pro quo or "I'll support yours if you support mine". Someone should support or oppose for honest reasons, not for some tactical reason. I'm honest in my dealings here, and I will try to continue to be so. If this means that you or other may oppose some proposal I have in the future, so be it. Wouldn't be the first time I've seen people oppose for such reasons, and unfortunately, probably won't be the last. - jc3718:16, 28 August 2012 (UTC)[reply]
It's not a tactical thing. It is a cooperative thing. And you did not address my main point about whether you would support this if a save step were added, and if admins had a way to remove the ability from editors when it's abused, just like rollback can be. --Timeshifter (talk) 01:19, 29 August 2012 (UTC)[reply]
"Cooperation" which suggests if I support others' proposals, they may be more likely to support mine? How is that not tactical : )
While I love HotCat, the lack of a save step makes it very easy to make mistakes by accident, especially when navigating a cluttered category box (and god help users of touchscreens). We need to make it easier to have these tools available to new users, but this is one where turning it on outright might cause more problems than it solves.
Conditional support/oppose. I support having HotCat as a default for placing in new categories, but oppose having it for category removal. The latter can be easily abused. Perhaps HotCat can be tweaked for this?--SGCM(talk)17:50, 29 August 2012 (UTC)[reply]
Oppose, as I recognize the idea in good faith. I have a good deal of concern that this would introduce a new wave of "category vandalism", from editors who would choose to remove reams of categories from articles by mass-clicking the minus feature. This would often be really hard to spot for patrollers et al. because category removal is at times a good faith activity, sometimes en masse. In other words, this could be an easy way to facilitate sneaky vandalism, which is the reason why I cannot currently support even if there was an 'are you sure' confirmation. I'm also not too big on having just the 'add' feature enabled by default - it is my general impression that we would get a lot of red-link categories on articles from newbies, who would not know what they are doing and fail to actually create the relevant cat page itself. Not to mention that many of these would be useless and redundant categories, though not all. Generally, I think the 'cutoff' works well - people who know HotCat exists in gadgets are generally smart enough to use cats appropriately, those who don't know it exists, well, are more likely to make mistakes, potentially outweighing the benefits of the people who wouldn't. I suppose too I'd rather not add HotCat abuse to the frontlist of things administrators should be monitoring for, whether or not there is a way for them to remove it on people. NTox · talk05:11, 30 August 2012 (UTC)[reply]
It is not easy to create red-link categories with HotCat. One has to ignore the suggestions that pop up. I think the benefit of making the addition of categories easier would outweigh the problems caused. HotCat makes it easy to see what categories exist. Maybe HotCat should be enabled by default only for logged-in users. Then the problem of category deletion vandalism is greatly lessened. Category deletion is necessary if one is changing from one category to a more apt category. --Timeshifter (talk) 06:47, 30 August 2012 (UTC)[reply]
The 'add' feature is something that I would be more comfortable with, and I agree that this change would increase constructive categorization activity. However, it would also increase non-constructive uses - the trouble is the speculation on these costs v. benefits. You are right that it is difficult to ignore HotCat's suggestions, however, people who are not familiar with the naming conventions would have trouble finding what they want anyway. All in all, I don't absolutely disagree with you - there is a lot of good that would come out of this, but I regret to say that I am concerned about the drawbacks, even if it only contained the 'add' feature, or if it was only activated on logged-in users. Lucky for us, unregistered people who love cats would still after all be able to work with them manually. NTox · talk16:36, 30 August 2012 (UTC)[reply]
Why deny logged-in users this tool by default? We trust them to add and remove categories now, but make it unnecessarily difficult to do so many things on Wikipedia. This is just one more reason, among many, that there is a decline in active editors. We can always turn this back to being an optional gadget if the cost-benefit analysis is unfavorable. --Timeshifter (talk) 02:47, 31 August 2012 (UTC)[reply]
Oppose as per User:Kilopi. I think anyone who purposely activates this gadget is more likely to familiarize him/herself with its features and is more careful in applying it than occasional editors or vandals. -- P 1 9 9✉14:06, 30 August 2012 (UTC)[reply]
Would you support it if it were only turned on by default for logged-in users? Kilopi was worried about category removal. If it causes more problems than it solves it can always be put back to being an optional gadget. Category removal is necessary when changing from one category to another. --Timeshifter (talk) 03:34, 31 August 2012 (UTC)[reply]
A trial period would be fine. I think the assumption that it would lead to a significant rise in vandalism is unwarranted without it. And it is worth pointing out that pl wiki has had it turned on for over a year, and I don't hear anybody there complaining about new wave of vandalism. --Piotr Konieczny aka Prokonsul Piotrus| reply here15:52, 11 September 2012 (UTC)[reply]
Convert Hotcat to a user-right
Remove hotcat as a gadget. Make it an integrated part of the mediawiki software. (So that it doesn't require JS, etc.)
Implement it as a user-right (like rollback). In which hotcat is the only right in that user-right package. This user-right is added to the administrator package. Admins can grant/remove this user-right at their discretion per whatever criteria is set (similar to other admin-given user-rights).
Add in preferences the ability to have a save/edit summary. Have this default to on. Only advanced users should be turning the edit summary part off. And of course, abuse can lead to removal.
You're preachin' to the choir here : ) - I'm merely responding to what I would support related to hotcat. Gadgets should be removable in their design, since they're apparently not, I proposed something which is. - jc3703:41, 30 August 2012 (UTC)[reply]
Oppose, for now. While there is a part of me that likes that user rights can be inducers of (good) behavior, I am not aware of very many cases in which HotCat has been significantly abused. Therefore, I would be concerned about restricting its use if there are not many that it needs to be restricted from. If there is sufficient evidence that the abuse of HotCat is a significant problem, I may reconsider. NTox · talk04:37, 30 August 2012 (UTC)[reply]
Oppose. This is a solution looking for a problem. It would restrict the use by plenty of editors who know perfectly well what they are doing. Secondly, we have too many user rights already and adding yet another one would be counter productive and increase our bureaucracy even more. Finally, it's just as easy to remove redlinked cats without a fuss. Kudpung กุดผึ้ง (talk) 08:01, 30 August 2012 (UTC)[reply]
Oppose. Wikipedia needs a lot of things: adding pointless bureaucracy isn't one of them. This is nothing but pointless bureaucracy. If people are incompetent with categories, there's a solution to that: tell them to stop, and if they don't, block them per WP:COMPETENCE. Putting more hats on sale in the WP:HATSHOP isn't the answer. —Tom Morris (talk) 15:01, 8 September 2012 (UTC)[reply]
Oppose per Tom Morris. I'm not sure why we make things like file moving into separate rights anyway, and this would make even less sense. Jafeluv (talk) 10:25, 14 September 2012 (UTC)[reply]
Convert Village Pump to Wikia Community Forum software
I am an admin-bureaucrat on a Wikia wiki, and I currently have over 36,000 edits there. Wikia sucks in so many ways. One good thing though about Wikia is that central, community discussions between editors across the wikis are very useful and productive. There are many expert coders participating. They fix innumerable problems caused by the Wikia staff and its software experimentation. Wiki admins add the custom fixes across many wikis.
Those central, community forums at Wikia are much better organized than the Village Pumps here, and have much better software. That is the model that should have been used for LiquidThreads. See here:
Each thread can be put on one's watchlist. The thread with the last post goes to the top. So it is easy to see current discussion. Old discussion naturally scrolls off the bottom of the screen. Everything can be searched. What's not to like? --Timeshifter (talk) 18:51, 22 August 2012 (UTC)[reply]
I'm in favor. Although I do think that the DPLForum (which is the extension in question) approach is somewhat simplistic, as long as we don't have Flow, it might be good medium term solution. It needs to be reviewed first though. I have reopened the bug ticket on this issue. —TheDJ (talk • contribs) 20:21, 23 August 2012 (UTC)[reply]
That the threads are forever moving over the page is one of the most offputting aspects of this layout. If I'm watching something or indeed the whole page, it keeping some sort of rigid structure to it is an advantage, not a disadvantage. NtheP (talk) 21:21, 23 August 2012 (UTC)[reply]
I don't think I have heard any complaints along those lines at the Wikia forums. People seem to really like the format. As I said you can put individual threads on your watchlist. There is a link at the bottom of them called "Follow" that puts a thread on one's watchlist. I also check off the box in My Preferences to email me when a page I'm following is changed on the community wiki where the central forums are located. Mainly just for those threads. On my main wiki I use the recent changes watchlist.
A new experimental Village Pump could be set up alongside the regular, old Village Pumps. People would soon see how much better it is to be able to watchlist individual threads.
This forum method might also be useful for putting central forums on a Wikimedia forum wiki. Forums that people might actually use. Versus the greatly disliked Liquid Threads. If it is just a forum wiki, then people would not fear checking off the box in My Preferences to get email when a watchlisted thread is edited. This would be better than continuing to try to get involvement on forums on Meta and Strategy wikis. People really dislike the scattered forums there, and Liquid Threads there. A wiki just for forums might be a solution for global discussions. Since it is just for forums, an integrated global watchlist would not be needed. That has not been created yet. Email notification of thread replies would be acceptable to people since they would only be getting email for replies to individual threads. --Timeshifter (talk) 16:14, 24 August 2012 (UTC)[reply]
Even if we wanted to this isn't the correct VP to make the actual decision, feasability yes agreeing to the change no. Not sure i would be for it anyway but thats better left for the right board.BletheringScot17:21, 24 August 2012 (UTC)[reply]
It is actually much easier. The Wikia search results list only has those threads that contain your search terms. The Village Pump archive search results lists whole archives. Several, or many, of them. So you have to open up a whole archive of multiple topic threads in order to see just one thread in that archive. That can be slow for people using dialup internet access. And it is easy to lose one's place in an archive.
It is also easier when using your browser to search within a current topic thread. Because at the Village Pump you have to wade through all the other threads on the current Village Pump page while using your browser to search for terms on the topic thread of interest. It is easy to lose one's place among all the topic threads. Happens to me often. It is much easier to search within a single topic thread as at Wikia central forums. --Timeshifter (talk) 16:17, 25 August 2012 (UTC)[reply]
I absolutely strongly oppose adding any sort of "forum" to Wikipedia. This very much sets the wrong "tone". Anything which indicates that Wikipedia is a forum-style place is contrary to the project goal. - jc3717:14, 27 August 2012 (UTC)[reply]
Um, we already have fora. You're on one now. The only difference is, these suck for the purpose of having actual discussions. Surely you don't suggest that making communication difficult is a good goal just because making communication easy could lead to the wrong "tone"? PowersT18:01, 27 August 2012 (UTC)[reply]
Apologies, but I don't see the major difference. There are plenty of "online forum"s where plenty of business gets done, and they are much more akin to what we do here than to chatrooms or blogs. PowersT00:08, 28 August 2012 (UTC)[reply]
Proposal for one Village Pump using DPLforum or other subpage discussion software
Note. Proposal has been amended. Other discussion methods that allow individual discussion watchlisting since they are based on subpages:
pt:Wikipédia:Esplanada/geral (Portuguese Village Pump) - fully developed Village Pump with subpages for individual threads. Each can be watchlisted easily. New topics are easy to create. Here is the Google translation of the Portuguese Village Pump.
fr:Wikipédia:Le Bistro (French Village Pump) - subpages by day could be adapted to subpages by individual discussion.
This is now a proposal to start one new Village Pump. Call it Village Pump (general) or something similar. It will use Extension:DPLforum as at the Wikia central community forums. Once people use this forum for awhile I believe most users will much prefer it to the current Village Pump method. To see DPLforum in use go here:
The advantage of Extension:DPLforum is that it allows people to watchlist individual threads. It also automatically puts the thread with the latest post on top of the forum index. The forums are easily searchable, both within the archives, and within individual threads.
Support as trial, for say 90 days: being able to watch only threads you are interested in is a long-requested option. Please {{talkback}} me if answer to this comment, as I can't afford watchlisting a page with such amount of traffic. — Dmitrij D. Czarkoff (talk) 20:52, 26 August 2012 (UTC)[reply]
So what is this, just a system to subpage discussions and list them on a single page, like the village pump system in use on it.wiki, fr.wiki etc. since 2006? --Nemo11:20, 27 August 2012 (UTC)[reply]
That sounds intriguing. That might address the concerns of Jorm (WMF) about having to adapt the Wikia community forum software to use on Wikimedia Village Pumps. --Timeshifter (talk) 00:56, 28 August 2012 (UTC)[reply]
For crying out loud, Flow is a lot more than "a couple of months" off, and your declaration that it will make Wikipedia look like Myspace is absurd on its face, given that no final design is anywhere close to being a reality at this point. PowersT18:03, 27 August 2012 (UTC)[reply]
Mogism. Could you change your oppose to support? Cause it sounds like you support it. Not everybody will take the time to read your comment in detail enough to get the sarcasm. Also, I have no problem with Flow continuing to be developed at the same time as DPLforum or other subpage discussion software is used for a Village Pump. In fact, what is learned from its use could be incorporated into Flow.--Timeshifter (talk) 01:03, 28 August 2012 (UTC)[reply]
I absolutely strongly oppose adding any sort of "forum" to Wikipedia. This very much sets the wrong "tone". Anything which indicates that Wikipedia is a forum-style place is contrary to the project goal. - jc3717:14, 27 August 2012 (UTC)[reply]
Comment - Sorry guys, but I'm afraid this proposal is dead in the water. We (the Foundation) have already investigated this idea and reluctantly discarded it. The Wikia extension is based heavily on some Wikia-specific architecture and MediaWiki modifications, which we would have to port into the WMF branches. The amount of work involved with doing so would be greater than building our own system for handling structured conversations (read: Flow).--Jorm (WMF) (talk) 20:23, 27 August 2012 (UTC)[reply]
I don't see why it could not be adapted quickly. It is basically subpage discussions whose titles are listed on the forum index. We already do similar things on Wikipedia. Also, see Nemo's comment higher up about such subpage discussion systems used for the village pump system in use on it.wiki, fr.wiki etc. since 2006.
I looked at mw:Flow and I can tell you as others already have that it looks like a disaster in the making to me. On the level of Liquid Threads. See: Talk:Flow
See also the relevant comments by Johnuniq about Flow here:
After years of work, and combining it with LiquidThreads, it might become useful for user talk pages. But its implementation says that it would not replace current user talk pages. People would be allowed to keep both forms of talk pages. I can tell you that from what I see of Flow so far I would keep using my current talk page. So would many others. Flow might be more useful for article talk pages. From what I see so far, it looks like Flow changes so many things in ways I do not like.
I think current subpage discussions with an index page look better to me. For many reasons. Note that in the French Village Pump example linked below, the individual discussions could be adapted to allow individual discussion watchlisting.
fr:Wikipédia:Le Bistro (French Village Pump) - subpages by day could be adapted to subpages by individual discussion.
But DPLforum in use at Wikia already allows individual discussion watchlisting. Also, the individual discussion with the latest post is put at the top of the index. It makes things very convenient for seeing what is of interest. One does not have to wade through many titles of discussion that no one has any interest in anymore. It also makes it easy to archive. Old, dead discussions roll off the bottom of the page, and naturally disappear into the archived threads. Which are all searchable, by the way. --Timeshifter (talk) 02:37, 28 August 2012 (UTC)[reply]
Well. My word about this is clearly not one you respect. I suggest you ask Brion Vibber himself about his technical evaluation of the software; perhaps he will be more convincing.--Jorm (WMF) (talk) 05:43, 28 August 2012 (UTC)[reply]
I don't know how difficult it would be to make DPLforum work on a Village Pump. But other subpage discussion formats are easy. Here is one I created in about an hour:
The problem there, IMO, is that the subpages must be watchlisted individually if you want to generally follow all discussions. And then you have to look at each of the pages individually if you want to see what changed. And, unless you're also proposing some sort of bot that moves discussions to these subpages, you've prevented IP users from initiating discussions (since they cannot create pages) and made it much more complex for anyone else to do so (since they have to create the subpage and figure out how to transclude it). Anomie⚔23:36, 28 August 2012 (UTC)[reply]
Look at the Portuguese Village Pump info below for an easy way to start new discussions. It is not necessary to watchlist every discussion. Why would you want to? If you are interested in all of them, then come to the Village Pump daily and scan down the page. --Timeshifter (talk) 01:45, 29 August 2012 (UTC)[reply]
That's amazing. We should immediately start one Village Pump using the method of the Portuguese Village Pump. Here is the Google translation of the Portuguese Village Pump. Each subpage can be easily watchlisted. --Timeshifter (talk) 01:41, 29 August 2012 (UTC)[reply]
I checked out mw:Talk:Flow and I don't see any actual constructive criticism of the proposal there. Am I missing something? Is there some implementation of it somewhere that people can look at and say "no, I don't like this"? Surely you're not giving a knee-jerk reaction to a feature that hasn't even been fully fleshed-out yet? PowersT12:42, 28 August 2012 (UTC)[reply]
There is a mockup at mw:Flow captioned "Flow as shown at Wikimania 2012". It looks like another version of Liquid Threads to me. Also, some of the concepts and goals of Flow are listed on that page. Some of which I disagree with. See also Wikipedia talk:Wikipedia Signpost/2012-08-20/Op-ed#wishlists and budget and Johnuniq's comment about Flow starting with "The problem at Wikipedia is that there is no good way for the WMF to seek ideas about a proposal, and no good way for the community to provide ideas regardless of whether the WMF sought them."
mw:Talk:Flow has some very useful info. For example; Tychay (Director of Features Engineering at Wikimedia Foundation), writes: "Unlike LQT, this [Flow] is only targeted at User:Talk, not Talk pages and discussions in general." Also: "It's not necessarily a complete replacement to User:Talk. The two might coexist indefinitely." So it looks like Flow is not for the Village Pump, and will coexist with current user talk pages. Its development may take a long time: "It was clearly obvious that user-user messaging is broken so a project was put in 2012-13 goals to address that. This has been named 'Flow' and according to planning will not be worked on directly until early 2013." --Timeshifter (talk) 14:16, 28 August 2012 (UTC)[reply]
Jorm, I don't entirely understand. mw:Flow says that Flow is intended for user-to-user communication (read: to replace User talk: pages), not for the kind of general discussion we have on the Village Pump, or on article talk pages. So how does that address this proposal at all? This isn't meant as disparaging Flow at all; unlike some of the other comments above, I think Flow has a lot of potential for its intended use as a User talk: replacement. But it's not a panacea for all discussion applications, is it? --R'n'B (call me Russ) 14:19, 28 August 2012 (UTC)[reply]
Comment - Liquid threads had definite issues (I and others commented about that there.) And I'm not sure I see that FLOW has fixed those issues. (I need to look closer, and haven't as yet.) But as others have noted, work is still in progress on FLOW, so there's no reason for me to jump to any conclusions yet : ) - jc3720:05, 29 August 2012 (UTC)[reply]
Noting that I would rather see a separate User-wiki (something that SUL could allow for), than to see a user-space specific communication system. - jc3720:07, 29 August 2012 (UTC)[reply]
Support or oppose a test Village Pump based on Portuguese VP
Note: See previous discussion just above too.
Other Village Pumps (community forums) using the Portuguese Wikipedia Village Pump software:
See pt:Wikipédia:Esplanada/geral (Portuguese Village Pump) - a fully developed Village Pump with subpages for individual threads. Each can be watchlisted easily. New topics are easy to create. Here is the Google translation of the Portuguese Village Pump.
Will it be possible to automatically watchlist all discussions? Loosing the ability have every discussion appear in my watchlist would be a deal breaker for me. Monty84503:23, 29 August 2012 (UTC)[reply]
Oppose Prevents IP users from starting discussions (or requires the configuration be changed to allow IP users to create pages, or requires that these subpages be stored in talkspace somewhere). Also requires watchlisting (and checking) of every individual discussion subpage, instead of just using one diff to keep abreast of new discussions. No thanks. Can't say I'm terribly impressed with having to use a script to create topics, either, especially since it didn't seem to actually work when I tried it there. Anomie⚔03:27, 29 August 2012 (UTC)[reply]
I tried to start a discussion and it got stuck, and I saw this message: "Por favor, aguarde a criação do tópico e sua inclusão na esplanada e no arquivo desde mês. O script se encarregará de atualizar a página quando terminar as edições." Google Translation: "Please wait for the creation of the topic and its inclusion on the terrace and in the file this month. The script takes care of updating the page when finished editions." Maybe there is some bug, or problem with posts from users outside Portugal. That does not mean they block IP users from starting discussion. Where did you get that info? Maybe they do. So what? That is a configuration setting, and not worth opposing a proposal for. As for blocking this because you can't watchlist the whole page, think of the massive benefit from being able to watchlist individual discussions. This is a thousand times more important to most people. --Timeshifter (talk) 04:13, 29 August 2012 (UTC)[reply]
I saw the same message, but I waited long enough to just give up on it. This is a thousand times more important to most people.[citation needed] I do hope Flow, LiquidThreads, or whatever else includes a mode to display a diff of all changes. This certainly couldn't, and would result in my not bothering to follow most discussions. On second thought, maybe that would be a good thing, give me more time for actual coding. Anomie⚔16:03, 29 August 2012 (UTC)[reply]
You want to block a test Village Pump solely because of some minor problems? Think of all the disputes you have to deal with due in many cases to the lack of adequate discussion forums that give the ability to watchlist individual discussions. Many people leave Wikipedia for this reason alone. They have to wade through WP:AN forums, and other forums, where they get lost in the shuffle of dozens of other irrelevant discussions. --Timeshifter (talk) 04:36, 29 August 2012 (UTC)[reply]
Comment. I was able to post elsewhere on the Portuguese wiki. So the posting problem at their Village Pump is particular to it. Obviously, many others are not having a problem posting there. I bet it has to do with spam intervention software and foreign posters because I also got some CAPTCHA filters. I asked Helder (via his script talk page) to have a look at the problem. --Timeshifter (talk) 04:52, 29 August 2012 (UTC)[reply]
Comment Is this really appropriate for a listing at Template:Centralized discussion which "is a list of ongoing discussions on policies, guidelines or other matters that have a wide impact and on which a broad consensus is needed"? This looks like a very local issue affecting only users of this board. I've removed it and ask Timeshifter not to replace it. Dougweller (talk) 05:02, 29 August 2012 (UTC)[reply]
People have been asking about the ability to watchlist individual sections of the Village Pump for ages. How is this a minor issue? What is more important than the Village Pump? It won't kill you to leave it up at Template:Centralized discussion for a day or two, and see what happens. The issue is certainly more important than some of the other issues listed there. --Timeshifter (talk) 05:17, 29 August 2012 (UTC)[reply]
Oppose - IPs cannot create pages on en.wiki (for understandable reasons). And we obviously want IPs to be able to start threads at VP. And because what one person finds to be helpful, "works better", or even "looks better", is in the eye of the holder, and MMV, per person. - jc3720:02, 29 August 2012 (UTC)[reply]
So you are helping to block this because you think IPs can't post at Portuguese Village Pump? Did you not read the sentence just above your comment that the problem is a CAPTCHA setting? Did you not also read Jorm's comment higher up: "ptwiki does not prevent anonymous users from creating pages. enwiki does." --Timeshifter (talk) 00:23, 30 August 2012 (UTC)[reply]
You continue to misunderstand this point. No one is saying that IPs cannot create pages on ptwiki. They are saying that IPs cannot create pages here on enwiki. So if we used a setup here on enwiki like the one on ptwiki, it would prevent IP users from starting discussions here on enwiki because they cannot create pages here on enwiki. Anomie⚔02:07, 30 August 2012 (UTC)[reply]
I did not elaborate enough in my last comment. I had previously pointed out that it sounded like configuration issues and choices on both English and Portuguese wikis. I just found this too: mw:Extension:EditSubpages ("Allows sysops to unlock pages for anonymous editing. ... This will also allow the anonymous users to create new pages that are sub-pages of the unlocked page."). --Timeshifter (talk) 04:10, 30 August 2012 (UTC)[reply]
Comment. There is English discussion about the CAPTCHA problem here: pt:MediaWiki Discussão:Gadget-Nova-esplanada.js. I started a discussion in English there. As for anonymous IP creation of discussion subpages on English Wikipedia there is this: mw:Extension:EditSubpages ("Allows sysops to unlock pages for anonymous editing. ... This will also allow the anonymous users to create new pages that are sub-pages of the unlocked page."). The extension may not be necessary if this configuration capability is already built in to Wikipedia. I don't understand why people would block a test Village Pump because they prefer whole page watchlisting over individual discussion watchlisting. Many people prefer individual discussion watchlisting. In any case no progress is likely to be made on the English Wikipedia on the discussion front unless the test is allowed to go on. It is only one Village Pump. Call it Village Pump (general), or Village Pump (test). We can watch to see how people like it or not. I think most editors will prefer individual discussion watchlisting. Some of the people who live on the Village Pumps may prefer whole page watchlisting. Eventually, someone may write a script to show a combined diff of all the individual discussion sections showing on the page. But that is less likely to happen unless some of the perennial naysayers who seem to live on the Village Pumps allow a test Village Pump to happen. Or you can continue to wait on the future nirvana of Flow or Liquid Threads.
Another benefit of subpages for individual discussions is that the links to individual discussions are permanent. One example of the many problems this causes is linking to discussions from Bugzilla. For example; read my comment (#2) in this Bugzilla thread started by Sue Gardner, the chief exec of Wikimedia:
I'm still waiting for information on watch listing all discussions, for those of us who like the current system. Will there be a way for that to automatically happen under this proposal? Monty84517:10, 7 September 2012 (UTC)[reply]
We are discussing that now at pt:Wikipédia:Esplanada/geral/English Wikipedia and Portuguese Wikipedia discussion forums (1set2012). It does not seem to be missed much. Plus, "related changes" provides some ability to watchlist all the current discussions at once. They started this discussion method years ago, and I believe this discussion method is now used on 2 of the Portuguese Village Pumps. The general Village Pump, and the VP for Proposals. Some of the Village Pumps use the old method.
Comment. See discussion below:#Talk page archivers: leaving a TOC trail. The current English Wikipedia Village Pump software requires a convoluted TOC trail to provide an overview of discussion topics with permanent links. Some ideas and solutions have been offered. Some compilation tools and methods are also proposed. --Timeshifter (talk) 17:00, 12 September 2012 (UTC)[reply]
General comment I'm late to this party, but I'd like to say I've always thought it silly that we use the article editing tool for making threaded discussions. Before Mediawiki even existed, I was using wiki software that had threaded discussion capability. It's about using the right tool for the job. Gigs (talk) 13:31, 13 September 2012 (UTC)[reply]
Support If implemented in the "Wikipedia talk" namespace rather than in the "Wikipedia" namespace, unregistered users could create threads without reconfiguration of the Wikipedia servers (albeit a different archiving bot would still be necessary). We already do this at Articles for creation. Categorizing threads can allow editors to use Special:RecentChangesLinked ("Related changes") to monitor discussions of importance to them. We already use a subpage per thread system (including the categorization part) at AfD. PleaseStand (talk) 22:19, 14 September 2012 (UTC)[reply]
When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.
About a month ago Jimbo created User:Jimbo Wales/Personal Image Filter as a followup to the perennial image filter issue. Discussion on that has petered out (no comments in last 4 weeks), and we don't seem any nearer to a solution that meets the criteria listed at User:Jimbo Wales/Personal Image Filter.
So, here's my suggestion, a (very) partial and (hopefully) uncontroversial answer to the perennial image filter question by giving users more control over what they see. It is simply a tool that will
put an images on/off switch at the top right of every article, defaulting to images on.
in images off mode, leave the image space blank, and show images after clicking them. Icons (images below a certain size, say 50 pixels) and images transcluded by templates would be excluded from this mode: neither should ever present images that someone would want to hide.
allow logged-in users to change their preferences, so images can be off by default (i.e. shown only after clicking), and to hide the images on/off switch.
the switch in point 1 gives users the option to apply the choice to the page or to the site; and for logged-in users, remember per-page on/off settings.
Now, I asked recently at Wikipedia:VPT#Gadget_for_control_of_image_display thinking that this tool could be done in Javascript only, as a gadget; based on comments there, it may need to be MediaWiki/PHP. But even if it's technically a bit harder than I thought, it's conceptually very simple, and is probably as uncontroversial as any solution to this problem can be. For a problem that has defied any kind of solution, even this very partial solution would be a whole lot better than nothing. In addition, implementing this allows us to get more of a handle on real world preferences, instead of much much much speculation, by collecting real (suitably anonymised!) data on what people actually do, for analysis. NB I also asked Jimbo recently at User_talk:Jimbo_Wales/Archive_113#KISS_image_filter, having raised it at m:Controversial_content/Brainstorming#KISS; Jimbo didn't reply.
'Tentative support of 1-4, on a trial basis. My main concern would be breaking the page through the hiding/showing of images. Also, how would page caching affect this? We could end up with unhappy, or at least confused, readers, something we should want to avoid. Also, the switch should be clearly located, but not so glaring as to be distractive. Maybe place it over in the toolbox? - jc3719:57, 29 August 2012 (UTC)[reply]
Comment - a trial run could be beneficial. I think it would need to be codified right from the start, and stated directly by the Foundation, that under no circumstances will the filter ever default to 'hide images', either on a site wide basis, or for any individual article. Resolute20:09, 29 August 2012 (UTC)[reply]
Well if that's what it takes, fine. But images off sitewide by default is completely and utterly implausible, whilst off by default on individual articles hardly less so, and in any case would require a system to choose which articles to apply it to - and there's no evidence there will ever be any agreement on that type of issue. Rd232talk23:47, 29 August 2012 (UTC)[reply]
Coming to an agreement on such a use is not my concern so much as the incessant arguing that certain editors would create on certain articles. Basically, what I would like to see in an image filter policy is a statement that "default to censorship will never happen. Don't even bring it up because the discussion will be ended immediately, with a block if necessary." But, as a personal concept, I can get behind a simple filter like this. Resolute23:54, 29 August 2012 (UTC)[reply]
Tentative Support Fine with everything but allowing an account setting to hide the on/off switch. It must always be easy for a reader to easily turn an image, or all images back on. Also, my support is conditional on this finally resolving the image filter debate, if discussion suggests that a substantial portion of contributors view this as a step towards a more involved image filter, then I will be switching to strong oppose. Monty84500:01, 30 August 2012 (UTC)[reply]
It must always be easy for a reader to easily turn an image, or all images back on. - yes, clicking a hidden image should always show it; and maybe hiding the switch would turn all images back on. Rd232talk13:44, 30 August 2012 (UTC)[reply]
Comment. If the feature is not strictly limited to hiding the images in the article currently being viewed then, from an intuitive design point-of-view, the on-off switch should not be located within the area of the screen given over to the article but instead at the very top of the screen or in the left-hand menu (i.e. locations where we expect to find features with a site-wide application). Formerip (talk) 00:14, 30 August 2012 (UTC)[reply]
Conditional support. I've long supported the general idea. Of the points noted above, I oppose only the part about excluding icons and images transcluded by templates. The statement that "neither should ever present images that someone would want to hide" is exactly the sort of subjective judgement that we need to avoid.
For an image filter to be acceptable at Wikipedia, it must be completely neutral. It's impossible to anticipate all of the images that people will want to block, but the many examples cited include spiders and religiousiconography, both of which which are transcluded by templates.
Additionally, most readers are unfamiliar with MediaWiki and its template system, so drawing such a distinction would cause confusion. —David Levy00:31, 30 August 2012 (UTC)[reply]
Well my concern is not to unnecessarily break interface images. I suppose the solution is to give users control over whether to hide icons/template images, so they can decide for themselves. Rd232talk13:44, 30 August 2012 (UTC)[reply]
That would be fine, provided that the distinction isn't drawn by default. (In other words, the image suppression should apply to icons and template transclusions unless the user specifies otherwise.) —David Levy14:09, 30 August 2012 (UTC)[reply]
Conditional support, like David Levy: I can imagine any number of reasons why someone would want to block icons or template images, ranging from arachnophobia to template vandalism, so the simple image filter should hide those images as well. In "images off" mode, the only images this should let through are user-interface elements like the disclosure triangles on the enhanced watchlist. --Carnildo (talk) 00:54, 30 August 2012 (UTC)[reply]
Right at the top of every article? There really isn't any extra space left there. The upper area of the page is already stuffed with tons of icons, buttons, links, and notices. In my opinion, that area already has much more than it should, and an images toggle button wouldn't be that high in the list of priorities. --Yair rand (talk) 11:46, 30 August 2012 (UTC)[reply]
Please educate me - I kinda want to support something like this - but I don't understand how this proposal works. If the switch is on the page itself - and it defaults to "ON" - then it's 99% certain that when I visit an article with NSFW (or whatever) images on it, I'll see the image before I have the opportunity to turn it off - and if my employer logs my Internet access and sees that I downloaded a porn image, I'll still get fired even if I turned images off on that page subsequent to it initially being loaded. Doesn't this seem a bit pointless? If I'm an arachnophobe and I can't bear to see images of spiders - then I need to state that globally so that if I visit (say) A Romance of Two Worlds - and innocently click on the unfamiliar word "gossamer" (which happens to redirect to Spider silk), I'm not confronted with two images of spiders before I can click the "Yuck no spiders please" button. What I need is a user-preference to say "No spider pictures" (or "No porn" or whatever) and have that operate globally. SteveBaker (talk) 13:02, 30 August 2012 (UTC)[reply]
The third point of RD232's proposal addresses that. There would be a 'master switch' available in your profile that would allow you to default all images off. Resolute13:17, 30 August 2012 (UTC)[reply]
And it's been stated at the Wikimedia Foundation level that the idea of an image filter based on content tagging is off the table. If someone wants such a setup (i.e. one that identifies and suppresses images depicting specific subjects), they're welcome to develop and deploy a third-party solution. —David Levy13:25, 30 August 2012 (UTC)[reply]
The idea of an image filter with categorizing of content etc was of the board (mostly because of the contentiousness of classifying content). This is however a much simpler approach of everything on vs. everything off. I think it is within the realm of what might reopen the discussion at WMF level, especially if there are volunteers implementing this. —TheDJ (talk • contribs) 21:36, 30 August 2012 (UTC)[reply]
Yes, that's my point. The idea of developing and deploying an image filter system based on content tagging has been abandoned by the WMF, but the type proposed here remains a possibility. —David Levy22:19, 30 August 2012 (UTC)[reply]
Is there any way of incorporating the user preferences in such a way that a supervisory program not under the individual users control cannot alter the default setting? DGG ( talk ) 13:37, 30 August 2012 (UTC)[reply]
Really? You imagine a supervisory program trying to fiddle with a user's Wikipedia preferences over image display, instead of just blocking images directly? Paranoia should be attenuated by Ockham's Razor, at least. Rd232talk13:49, 30 August 2012 (UTC)[reply]
If I'm an arachnophobe and I can't bear to see images of spiders - the concept here is that it's better to give an arachnophobe an easy way to quickly turn off all images on a given aagh spiders page, so they can still read the text, rather than be forced to deal with the images or give up and close the page. Giving the user some control is better than not. Rd232talk13:44, 30 August 2012 (UTC)[reply]
Oppose proposal, but support principle. I strongly oppose the switch anywhere outside Special:Preferences, and specifically for IP users: cookie pollution is no good thing, and if anybody wants to customize his UI experience, he may just register and log in. — Dmitrij D. Czarkoff (talk) 16:48, 31 August 2012 (UTC)[reply]
So you support the idea, but only for 1% of users? Why are you concerned about "cookie pollution"? What if I'd personally prefer a cookie instead of another username and password to remember? WhatamIdoing (talk) 20:33, 31 August 2012 (UTC)[reply]
Broadly support but agree with Dmitrij D. Czarkoff comment. The primary use of an image filter for me is that I frequently edit Wikipedia on my laptop while in public: on trains, in libraries, at conferences, at events etc. If I'm doing anti-vandalism work or, say, fixing issues with an article on a sexuality-related topic, I'd rather not subject my fellow travellers on the commuter train to some of the delightful images on, say, WP:BADIMAGES. As for IP users? Let's try it out for account users first and then if the world doesn't melt due to our mind-blowingly ghastly breach of WP:NOTCENSORED, then we can think more about enabling it for IP editors. Alternatively, we could just have it as a user script you could import into your vector.js or monobook.js. Does the script actually exist? I thought about building one a while back but the inner lazy programmer never got around to it. —Tom Morris (talk) 21:48, 31 August 2012 (UTC)[reply]
Oppose in principle. "Think of a the children" and religious considerations really don't sway me. If you don't want to deal with reality, don't go online. Even Tom Morris's argument above doesn't sway me. Yes, it's more convenient, but it's not worth what I fully predict to be a poorly constructed and poorly imitated shadow of the plan put out at the top of this section. If it's written, and it functions as intended and isn't intrusive, I might support, but I'm still opposed now. Sven ManguardWha?22:41, 31 August 2012 (UTC)[reply]
Oppose - without some way to select what kind of content one wishes to have filtered, it seems kinda useless. Unless someone is prepared to forgo all images (which seems unlikely), they'd have to first see an objectionable image, then turn it/them off...which is really useless. This is just a waste of effort and more GUI clutter on every page. I would seriously consider supporting a measure that allowed for some kind of classification - but even that is highly problematic. SteveBaker (talk) 23:07, 31 August 2012 (UTC)[reply]
Support I follow Steve's reasoning, but I don't agree that using a global no-images setting is so unlikely. If you're using WP from work, it sort of makes sense — turn off images, and click on them if you need them, in articles where it's clear they won't be a problem. Sort of similar to how I leave images off in my e-mail by default (even though the exact motive is different — I'm not so concerned about taboo pics showing up in my browser cache so much as about web bugs). --Trovatore (talk) 23:18, 31 August 2012 (UTC)[reply]
That's not really true though. If adding this had zero impact on people who don't want/need it, then you might be correct - but that's not the case. It adds an additional GUI element to every single page. Since it's not the fully effective thing that most people seem to wish for, it actually can be "worse than nothing" - which is why I oppose it. SteveBaker (talk) 18:53, 1 September 2012 (UTC)[reply]
Support. It's not strictly a filter, since a filter lets some things through and filters others, but it's a feature some will find useful, with minimal impact on the experience of others. It should prevent images from loading (not just hide them), so as to aid readers with slow connections or limited bandwidth. I'd like to see a commitment to take this back to the community three months after deployment for the community's final ratification. It's not a substitute for a real filter. If we ever adopt a filter, this can be included as a filter option. --Anthonyhcole (talk) 22:32, 1 September 2012 (UTC)[reply]
Support. There are enough people who object to seeing certain images that we should do our best to cater to them in a way that won't affect everyone else. From the technical angle, couldn't we implement this with something comparable to the fundraiser banner? Having a little box to click that will remove the hide-images button from all pages for a certain number of days would seem reasonable. The proposal of permitting the user to click on images to see them is also good, since this might blank images that users would want to see anyway, such as the calligraphic representation of Muhammad's name in his infobox. What's more, Anthonyhcole's comment makes a good point; there are still people with dialup who would benefit from the lack of images. Nyttend (talk) 22:41, 1 September 2012 (UTC)[reply]
Question. I have a question about point 3: "allow logged-in users to change their preferences, so images can be off by default (i.e. shown only after clicking), and to hide the images on/off switch." I'm not sure what "to hide the images on/off switch" means. SlimVirgin(talk)01:29, 2 September 2012 (UTC)[reply]
It means that if you get annoyed by the button being there (which now that I think of it, it probably would to me), you can hide it from appearing on your screen. Michaelzeng7 (talk) 23:39, 2 September 2012 (UTC)[reply]
Support - Put very nicely by User:GabeMc above me, there's not really any ways this couldn't be a useful addition to our MediaWiki installation. Personally, when I'm editing at the school library, I sometimes find myself frantically scrolling down, closing tabs and such when I mistakenly enter an article with a NSFW image. This would definitely benefit me; since I don't really work with images much at all, I could simply turn image display off whenever I'm editing in public. ❤ YutsiTalk/Contributions ( 偉特 ) 17:49, 4 September 2012 (UTC)[reply]
Conditional support. I like the concept, but also follow SteveBaker's reasoning that we can;t single out images transcluded by templates as completely inoffensive. I would support only if images transcluded by templates are hidden by default when the tool is activated (preferably through Special:Preferences for registered users). CtP (t • c) 01:30, 9 September 2012 (UTC)[reply]
I actually realise now that the templates thing is a bit of a red herring; I really mean icons, which are often provided via templates, but some templates (infoboxes!) provide relatively big images. So the additional option I'm asking for (whether it's on or off by default is less important to me than having it) should be whether the on/off switch affects small images (say <=50px). Rd232talk12:15, 11 September 2012 (UTC)[reply]
ABSOLUTE oppose: We exist to educate not to enable willful ignorance. This proposal is wholly incompatible with our stated values and objectives. Abyssal (talk) 16:17, 11 September 2012 (UTC)[reply]
So...it's critical to our mission to force people to look at unwanted images when they want to read text? It's critical to force people to download images on slow connections when they only have time to download the text? Nyttend (talk) 21:49, 11 September 2012 (UTC)[reply]
Support - This very simple edit filter would be ideal for work/public situations as a general precaution against unwanted Not Safe For Work (NSFW) pictures. Its often a hop and a skip to an article containing something that is awkward, hard to explain even if it is not religious or sexual in nature. Though many individuals would have difficulty in explaining Mastectomy's pictures if for some reason you hopped to it from another article. While it is more common the Human body to expect something like that, but as the spider analogy above shows, ignorance of the subject does not necessarily mean a desire to be ignorant of visuals. This simple edit filter will also prevent the weird looks from stumbling into any questionable pictorial content long before such an opportunity presents itself. And before anyone gets any ideas about the Muhammad article, yes it could be a watershed for those who wish to learn, yet not see any pictures. It wouldn't be censorship either, because the restriction is self-made and is no different then using other technological means to do so. A simple toggle would be of unquestioned benefit, with its uses far outweighing any potential negatives. ChrisGualtieri (talk) 04:20, 12 September 2012 (UTC)[reply]
Mostly support, but only at the level of "all images on"/"all images off", including templates. I think the setting should not be an icon, but an entry in the Toolbox which will work for all skins whereas an icon elsewhere could easily break things, that applies to the current page only. I do not support the option of hiding the toolbox option other than through special:preferences. Control for multiple articles should only be via special:preferences. I support the one-click unhide, and don't object to one-click hide as long as it doesn't interfere with the existing click to load the image description page. Ideally an images off setting should somehow interact with the maths display setting so that, where possible, text is displayed to the user (change "always show png" to "Math Jax"?). Although mathematical equations are unlikely to be NSFW that isn't the only reason people might be using this and exempting large maths images would not assist with bandwidth issues (although how much bandwidth MathJax uses I haven't the foggiest). Thryduulf (talk) 05:07, 12 September 2012 (UTC)[reply]
Oppose There is no reason for people to access pages on topics that likely have objectionable images if they would get in trouble for that. And existing policies should deal well with images that don't belong into an article. I also have issues with the "Think of the children" arguments as these seem to be speculation at best. Jo-Jo Eumerus (talk) 09:31, 12 September 2012 (UTC)[reply]
A gadget should be able to do this well enough, since gadget CSS is loaded at the top of the page. The gadget would set visibility:hidden on all images, and then some Javascript would unhide interface icons and set up the click handler on the rest. I've written such a gadget, and it seems to work on my local test wiki using Firefox 14, Chromium 21, Safari 5, and IE8.
It may not work quite right as a userscript, but you can try it out if you'd like. First, copy this to your common.js:
Note that this does not attempt to implement the in-page on/off switch; if enabled, will always hide images. To turn it off, remove the lines (at least the one in common.css). Anomie⚔03:20, 1 September 2012 (UTC)[reply]
Note also this doesn't prevent the images from being downloaded (at least not in Firefox 14), it only prevents them from being displayed on the screen. Anomie⚔03:20, 1 September 2012 (UTC)[reply]
It is better to limit it to the images within article content: '#mw-content-text img'. I do not think anything questionable can reside outside that area. Ruslik_Zero19:01, 1 September 2012 (UTC)[reply]
That's definitely a start, thanks. It works quite nicely in conjunction with NavPopups, so you can get some info about the image before clicking it to show. Can we develop this a little further, and work towards making it an optional gadget fairly quickly (default gadget is a discussion for later I suppose)? An easily accessible switch would be nice even if it's only globally on/off to start with, as would a means to display any alt text (maybe by tool tip when hovering, if it doesn't clash with NavPopups). Rd232talk11:41, 7 September 2012 (UTC)[reply]
Multiple watchlists
We should be able to have multiple watchlists (at least two!). If I'm busy one week, and don't have a lot of time to go over my watchlist, it's good to have an "important" watchlist as well as a "everything" or a "not so important" watchlist. People could divide them up in other ways depending on what things they felt like keeping track of for the time being "movies", "economics", "recent events", etc. Byelf2007 (talk) 30 August 2012
It is possible to do that already, though the contents are publicly viewable, and it shows all changes not just most recent. Create a page in your userspace, add wikilinks to the pages you want to watch, then hit the related changes link in the toolbox on the left side of the interface. It will show changes to all pages linked from the one you were on. Not perfect, but largely does what your looking for. Monty84516:15, 30 August 2012 (UTC)[reply]
That may help some people, but it is not satisfactory for most people. People are trying to create multiple streamlined watchlists showing only the most recent changes, and no more, in order to save time. --Timeshifter (talk) 03:07, 31 August 2012 (UTC)[reply]
Support, I totally agree, There are some times when I can look at the full catastrophe, and others when I only have time to look at the ones I consider most important. Two would be a functional minimum, three or four would be a bonus. • • • Peter (Southwood)(talk): 17:58, 30 August 2012 (UTC)[reply]
The frequency with which this idea comes up should tell us something about the desirability of doing it... bugzilla:5875 from 2006 (Group similar pages in watchlist) is not the first time it came up. It was raised eg two years ago on WP:VP here. More recently (early this year) Sue Gardner (chief exec of WMF) filed a general "let's improve watchlists" bug (bugzilla:33888 - Requesting a user-centred rethink of how watchlists work), which includes multiple watchlists as point iii (not using the term, but that's what it is). That was 7 months ago and nothing's happened. :(( Rd232talk18:54, 30 August 2012 (UTC)[reply]
It amazes me that the chief exec of WMF has piled on to this longtime request to improve watchlists, and even she can not get around the perennial naysayers on Wikipedia in order to make this a priority. The WMF needs to hire more technical staff, and stop hiring so many staff who are not fairly skilled in MediaWiki coding. --Timeshifter (talk) 03:13, 31 August 2012 (UTC)[reply]
Support. I think I already proposed this in the past myself because I agree that this would be immensely useful. For me the main argument in favor of this is that there are articles where I am interested in the topic and where I am a main contributor or the creator. But I also have a lot of articles on my watchlist, where I only do some maintenance. Since I have Watch this page checked by default, watchlist easily gets clogged. -- Toshio Yamaguchi (tlk−ctb) 21:23, 30 August 2012 (UTC)[reply]
Let's change how we explain this - Instead of saying "multiple watchlists", instead let's say: in addition to my watchlist, I would like a new special page called a "priority list". Pages would need to be added to my priority list manually by me (perhaps an exclamation point symbol or some such, next to the star for watchlist). While the priority list would need to have its own set of preferences, all hide/show preferences for my watchlist would also apply to my priority list (let's make things easier on the devs : ) - The presumption is that while (some of us at least) may have all edited pages added to our watchlists, the priority list is for things we really wish to watch closely. And yes, I would support this : ) - jc3723:44, 30 August 2012 (UTC)[reply]
Support. See how easy that is to say, O perennial naysayers. ;) A priority watchlist would be very helpful. The ability to watchlist only the talk page and not the article would also be useful. Right now that is not possible. If it were possible, then I could create a watchlist of priority talk page discussions. If we were able to have priority watchlists, and to watchlist individual sections of talk pages, wikipedia would stop losing so many active editors. Frustration with watchlists and many other problems cause many people (such as myself) to empty their watchlists of almost everything, and stop most editing of articles altogether. --Timeshifter (talk) 03:13, 31 August 2012 (UTC)[reply]
Thanks for plugging my project, YuviPanda. The project is still at an experimental phase, but I would like to continue developing it over at MediaWiki. Now that the GSoC project period has ended, I am seeking out developers who would be interested in working with me on the project. I will be attending classes starting next week, so having additional help during the Fall would definitely speed up development time. --Blackjack48♠t♣c15:19, 2 September 2012 (UTC)[reply]
Why don't we just add another watchlist? "Watchlist A" and "Watchlist B". I can't imagine this would require any additional programming, just a quick edit (but I don't know much about this stuff). Byelf2007 (talk) 5 September 2012
As a relatively new Wikipedia user I see watchlists from a different perspective so can hopefully provide an interesting insight. I see them as being of use to readers as well as editors (and hopefully turning readers into new editors :-)). I think it would be great if watchlists could be used as "reading lists". For example during my university degree I spent a lot of time bookmarking wikipedia articles. What I would have loved would have been a feature to 'watch' these articles, to add tags to them such as "read", "not-read". If we had such a tagging system you would get multiple watchlists (via filtering by those tags) - ie. you could invent your own tagging system such as "priority" "spam-target" etc... To reinforce this idea - when I first saw the star icon on Wikipedia article's I assumed the purpose of this feature was to favourite an article (Google Chrome my default browser uses the star for bookmarking). I then started getting e-mail notifications - and thus entered a world I hadn't expected to but was pleasantly surprised to be in - a world where I could do things like revert bad edits on articles I cared about and keep up to date on changes.Jdlrobson (talk)
sorry failed to sign.. I am a developer and on the mobile team where this can definitely happen if people are interested in helping define how it should work.... Jdlrobson (talk)
Strong support. This would have been of direct benefit to me (and still would be). Failing eyesight typically means a very high zoom level for me to be able to read anything (on a very big monitor). This means I only get to see the top few items in a single watchlist. A while back, when I decided to split up my interests into separate accounts, to be able to manage everything I wanted to watch, I got a indef block for "abusing multiple accounts". So it's something I'd be very pleased to see. Martinevans123 (talk) 08:38, 8 September 2012 (UTC)[reply]
Re-enable 'Show changes since my last visit' on Watchlist (and History)
Since the last debacle where a super-usefull software feature has been killed purely for aestethic reasons, I am intent on reinstating this feature again. This time I expect no complaints; Two updates ago, the watchlist has had an extensive CSS makeover, which allows us to control the styling much better (so no more bold is needed). Even the bullet can be changed; which is exactly what my proposal is: Each unwatched item will be displayed with a green bullet (), instead of the default blue one. This would also be the case for History pages on your watchlist, where the bullet will replace the "updated since my last visit" message. Now surely... no-on can object to that...
Code to test:
/* Watchlist and history of watched pages */.mw-special-Watchlist#mw-watchlist-resetbutton{display:block;}.mw-special-Watchlist.mw-changeslist-line-watched.mw-title{font-weight:normal;}.mw-special-Watchlistli.mw-changeslist-line-watched,#pagehistoryli.mw-history-line-updated{list-style-image:url(//upload.wikimedia.org/wikipedia/commons/c/c2/ChangedBulletVector.png);}#pagehistoryspan.updatedmarker{display:none;}
As you've inadvertently forgotten to link the discussion two months ago in which a majority of 101 to 43 voted to make this change opt-in only rather than foist your personal idea of "how a watchlist ought to work" on everyone else, this is the previous RFC. I take it you're going to keep on playing shoot-till-you-win until you find a board where people agree with you, at which point you'll declare that you've found "consensus" and unilaterally screw about with everyone else's user interface again? 188.29.114.59 (talk) 16:28, 31 August 2012 (UTC)[reply]
That's right, at least from your point of view. Everyone else will hopefully read my message more clearly and understand that cincumstances have changed an now allows for a non-intrusive way to have a default functionality enabled once again, in a way that will even please those that complained on purely aestetic reasons. — Edokter (talk) — 16:43, 31 August 2012 (UTC)[reply]
I've followed the directions to manually turn on the bold face text (just like all the other WMF projects!), so I'd kind of forgotten that this problem still existed. I support making this feature available to everyone, with the old power users opting out if they dislike it. Someone who knows how to complain at VPT has a better chance of being able to opt-out than a newbie has for opting in.
The blue and green are very distinguishable, plus the green dot is bigger. But anything is possible now with the new CSS; any suggestion is welcome. — Edokter (talk) — 23:38, 31 August 2012 (UTC)[reply]
Strong oppose; the opt-out I had used earlier is not 100% complete. I feel that this feature is still too obtrusive on an extremely large wiki; I'm fine with it on smaller wikis like Meta and MediaWiki.org.--Jasper Deng(talk)00:52, 1 September 2012 (UTC)[reply]
What difference does the size of the wiki make? Besides, Commons is much bigger, with 3.5 times as many mainspace files as en.wp, and they use it. WhatamIdoing (talk) 19:40, 1 September 2012 (UTC)[reply]
On this wiki I have 9500+ pages on my watchlist, while on other wikis I have far less. With much more activity on my watchlist than other wikis the change is a big intrusion on this wiki. I would imagine that Commons has far less changes per page than this wiki.--Jasper Deng(talk)19:45, 1 September 2012 (UTC)[reply]
So how do you keep those changes you have already visited on your watchlist apart from those that you haven't visited yet? Must be a pain to click on a page, only to discover you already saw that change. — Edokter (talk) — 22:07, 1 September 2012 (UTC)[reply]
Then how would a green bullet disrupt your way of working? (Note that most of us don't have 10,000 items on their watchlist.) — Edokter (talk) — 22:45, 1 September 2012 (UTC)[reply]
Must be a pain to click on a page, only to discover you already saw that change -- I fail to see how that comment even makes sense. Click "diff". Boom the link changes color and it's marked as visited in the browser. Refresh watchlist two hours late, diffs since that time are back to unvisited color. ♫ Melodia Chaconne ♫ (talk) 17:38, 3 September 2012 (UTC)[reply]
Ah, so the bit about the "extremely large wiki" is irrelevant, a complete red herring. The relevant factor is "the size of my own personal watchlist", which doesn't seem like a good reason to keep this feature away from 99% of users. I'm pretty sure that someone of your capability can figure out how to turn the thing off. I'm even more certain that 99% of users won't know that it exists, or be able to turn it on, if it's not on by default. This situation sounds like a good time for the very small number of technically adept people who don't want it to manually modify their own environment, rather than having them impose their personal preference on the vast majority of people who would probably benefit from it (based on the positive experiences at the other wikis). WhatamIdoing (talk) 17:11, 3 September 2012 (UTC)[reply]
This particular desing was not even possible during the RfC. This is not te same as the stars which were displayed inside the list. Did you even bother to look at the atached image that Anomie posted? — Edokter (talk) — 17:06, 2 September 2012 (UTC)[reply]
Why are we making this into such a big deal. Some people like it and some don't and thats ok. Why can't we just make it opt in or opt out at least and move on. Kumioko (talk) 17:09, 2 September 2012 (UTC)[reply]
Opt-in is a sure way to cause 99.9% of new editors never knowing about this feature. What is the big problem of having everyone benefit from a standard function in MediaWiki? — Edokter (talk) — 17:12, 2 September 2012 (UTC)[reply]
I would support opt out. I find the feature very useful, and guess that many relatively inexperienced users would too. Including those who wouldn't ever suspect the existance of the tool if they had to look for it and opt in. Providing the opt-out works, I see no reason why anyone should object, but expect some will anyway. One other thing I would find very useful would be a way to mark a notice as checked without having to open the page. This would make things a lot quicker as the mouse-over display is enough in many cases. Cases where someone you trust has edited also don't always need to be opened. • • • Peter (Southwood)(talk): 18:51, 2 September 2012 (UTC)[reply]
Support - I definitely think this would benefit me, with an ample watchlist (about 300 pages). Further, I'll support opt-out, which is a reasonable compromise as those who don't want the feature won't have it. Michaelzeng7 (talk) 23:48, 2 September 2012 (UTC)[reply]
OTOH, basing your argument on people not knowing CSS when a gadget can trivially be provided is similarly a very, very weak argument. Anomie⚔15:57, 3 September 2012 (UTC)[reply]
Actually, i'm also against a gadget. Things that will only be used by 20 or so folks should not be a gadget in my opinion. And that is the amount of users of the gadget that I predict when we choose the CSS that edokter is currently proposing. —TheDJ (talk • contribs) 18:26, 4 September 2012 (UTC)[reply]
Support for opt-in only because it's a purely aesthetic choice that a large number of people objected to last time around. Very strong oppose if it is opt-out or mandatory. Sven ManguardWha?15:42, 3 September 2012 (UTC)[reply]
It seems to me it's a functional issue, not purely aesthetic. And despite the wording of the RFC, people mainly opposed the bolding and the lack of a gadget (because the feature was overridden before a gadget could be written) last time around. This proposal involves something that is so inconspicuous that I for one worry that users who would find it useful won't actually notice it. Have you looked at the screenshot? Anomie⚔15:57, 3 September 2012 (UTC)[reply]
Oppose watchlist already have triangles, little m's little b's now bold green dots are next annoying must have feature. Also I find this Since the last debacle where a super-usefull software feature has been killed purely for aestethic reasons, I am intent on reinstating this feature again. This time I expect no complaints rather ugly surely if the feature is such an essential item to the functioning of the watchlist that you wouldnt need to ask the community it'd be added at the next upgrade. We all do this voluntarily a little consideration for the opinions of others would go along way to getting people to even voice an opinion. What that comment has ensured is that many editors wont bother to respond, so we'll get your little bold green dot irregardless of what we want, like all non-essential gadgets I'd prefer it be an opt-in. Gnangarra12:26, 10 September 2012 (UTC)[reply]
Note this feature is not any sort of gadget, it is a standard part of MediaWiki, although the default styling is much more obtrusive than is being proposed here. Unfortunately, when it was rolled out here, a bunch of people complained and MediaWiki:Common.css was edited (without sufficient thought or discussion) to hide all visible effect of the feature. This discussion is a proposal for something much less obtrusive, hopefully enough so that this vocal group will stop insisting we hide the feature from all new users just because they are too lazy to enable a gadget to hide it for their accounts only. Anomie⚔17:57, 10 September 2012 (UTC)[reply]
and again the language being used is creating the issue, why not just provide both options rather then deride those that dont want it. If it was that obtrusive that a sufficient number people odjected to it in the first place then is not reasonable to address those needs, then respond in a civil manner. Gnangarra23:32, 10 September 2012 (UTC)[reply]
Look at how much people also complained about the new diff colors, which were released at around the same time. But there the complaints were handled well: a gadget was created for the complainers to enable to change it back, rather than forcing the old colors on everyone who doesn't know enough to look for a gadget to get the MediaWiki default back. Anomie⚔23:53, 10 September 2012 (UTC)[reply]
Wikipedia spends a fair amount of effort verifying facts, verifying the reliability of sources, and verifying issues around licensing of images and text. Occasionally, when issues of socking and COI arise, it attempts to determine editor identity (at least enough to try and link accounts and IPs to the same person); but generally, it's axiomatic that it doesn't matter who an editor is, it matters what they say and do. To some extent, that's a laudable principle, but it does cause problems.
So I'm proposing that we establish a variety of mechanisms by which editors can, if they wish, verify their identity. The security of the mechanisms will vary, so which mechanism(s) have been used should be specified. Some of the mechanisms can be automated; others will require some human decision-making - those would need a process similar to OTRS. One mechanism I'm drawn to is a credit/debit card payment of $0.01 - it's easy to do (for editors who have such cards - alternatives certainly needed for those without) and can be automated. Another mechanism may be emailing to/from email addresses published on an appropriate website (eg an academic's institutional homepage). But the point of this proposal is less to debate pros and cons of different mechanisms, but to establish the principle of providing (multiple) mechanisms.
Once such mechanisms are established, they can be used in different ways - and we have to address that now in order to answer the inevitable, and fair, question "why?". The main reason is that in cases where we have authenticated experts contributing, we can give more weight to their opinions about NPOV, sourcing, etc (without permitting original research or mere argument from authority of course). Example: if authenticated Professor X says Y is a crappy source because of verifiable reason Z, that ought to carry more weight in a discussion than if PseudonymBla says it (especially if it's within Professor X's expertise). This is similar to how in practice, PseudonymBla's voice carries more weight in discussions, if they're a well-established editor with a track record, than a passing IP with no edit history. We already have ad hoc gradations of respect for different opinions about facts, sources, etc; but because of the lack of means to link WP accounts with offline identities, we have no way of allowing people to draw on those offline reputations, even when they may be highly relevant.
Three fundamental principles:
public identification/verification/authentication (whatever you want to call it) remains voluntary
editors whose identity is verified have equally to respect existing WP policy and guidelines, most especially WP:OR, WP:RS, WP:NPOV.
any additional respect given to verified-identity editors in a particular discussion is at the discretion of other editors; no rules can be made about it. It is ad hoc and discretionary in the same way that today a well-respected editor's opinion may carry weight in a certain topic area because other editors may know of and respect their track record of displaying relevant expertise; the difference is that this track record is no longer limited to being on-wiki.
Not sure I like the idea it presumes just because a user is a professor or professional than his/her word has more weight in discussion, all users should debate and discuss on an equal footing. We already have an email address authentication and the WMF has procedures if a user needs to be authenticated for legal reasons so I dont see what this would achieve. MilborneOne (talk) 15:23, 31 August 2012 (UTC)[reply]
The proposal presumes nothing about what additional weight, if any, a verified editor carries in a discussion even if they have known expertise in the area. It is entirely up to other editors whether they care or not. As to existing procedures: the current email address verification verifies only that the user has access to the email; in isolation that has no bearing on their identity. The current WMF verification procedure is AFAIK based on scans of identity documents, and besides being easily subverted is not practical for wider use. Rd232talk16:16, 31 August 2012 (UTC)[reply]
If the proposal gives editors no addition weighting then it doesnt appear to be worth the effort. Still not convinced that the profession or otherwise of editors is relevant to wikipedia to how they should be seen or behave. MilborneOne (talk) 16:46, 31 August 2012 (UTC)[reply]
I think it is a strength of Wikipedia that we focus on the quality of an argument, or a contribution, rather then on who is making it. The cult of credentials pervades the rest of society, lets not bring it to Wikipdia. Monty84515:52, 31 August 2012 (UTC)[reply]
Focussing on the quality of arguments and facts is the only thing that makes Wikipedia as viable as it is. However, it is naive to believe that everyone is equally able to assess the quality of argument and facts in every situation. Nothing about this proposal throws out the existing system where editors establish track records onwiki through behaviour and quality of discussion and edit contributions, particularly by showing expertise in certain topic areas. All it does is additionally allow editors to consider offwiki track records which may be relevant. We know that the current impossibility of this (because of lack of identity verification) puts off real experts from contributing because they begin their Wikipedia careers with the same level of respect as the infamous Randy from Boise who knows nothing about anything. It does not, and cannot, force anyone to respect those offwiki track records, nor to have it override considerations of verification of facts, reliability of sources, etc. Rd232talk16:16, 31 August 2012 (UTC)[reply]
To the extent that we consider off wiki track records at all, WP:AGF should be all that is needed. If we are ever in a situation where it matters whether an editor is lying about a credential, we have already given far too much weight to that credential. If I claim I'm a rocket-surgeon, and you can't tell I'm not from my editing, does it matter whether I really am? If I really am a rocket-surgeon, but don't act like one, does it matter that I really am? Monty84516:44, 31 August 2012 (UTC)[reply]
I don't know what your example is supposed to be. Here's a not uncommon scenario: A, an unknown editor, says X is a reliable source for fact Y. B, a professor in a relevant area, says it isn't, and says the fact is untrue, but there are no reliable sources which actually say it's not true, because it's trivial and not in dispute by mainstream sources. A third editor C wanders by and wants to help resolve the dispute. From a "settling disputes, let's keep the peace, none of this really matters, it's just a MMORPG" point of view, we don't care if C knows who A and B are. From a "quality is a good thing, this is supposed to be an encyclopedia" point of view, we want C to know who A and B are (how that influences C's decision is up to them of course). Capiche? Rd232talk19:20, 31 August 2012 (UTC)[reply]
I've been editing here since 2005, under the same name that I use for scientific publications (a subset of my full legal name). I have a link on my user page to my university home page, and a link on my university home page to my user page. I've established a certain amount of credibility on-WP, so that the pervasive lack of credibility given to activities off-WP isn't galling. But I would never suggest to any of my colleagues that they become Wikipedia editors. It's like being in grad school all over again, except that your committee changes randomly, everything you learned as an undergrad is devalued, and there's no light at the end of the tunnel. In short, for most academics editing in their own fields, WP is a waste of time. I don't know whether this proposal would improve anything (in the words of Shania Twain, "So you're a rocket scientist."). I know of a number of editors who are academics and specialists who intentionally keep their identities unknown (a fact that for me puts WP more in the realm of an online game than a scholarly pursuit). I have seen talented editors, well-respected outside WP, leave because their skills didn't include the harsh argumentation that has become the norm in many areas of Wikipedia. I've seen other editors leave because they got tired of being challenged over the basic facts of their disciplines. And I know there's an essay about all this. The responses above say a lot to me about why the essay, and the issue, exists.--Curtis Clark (talk) 17:36, 31 August 2012 (UTC)[reply]
While we occasionally have issues with pseudonymous editors claiming qualifications, credentials, or expertise that they don't really have (*cough* Essjay *cough*), such instances seem to be fairly rare, and I suspect are usually caught by their fellow editors.
What I haven't ever seen is an instance of an editor falsely claiming to be a particular and specific real-life, known expert, and I suspect that such cases are vanishingly rare. That is, I've seen User:RandyFromBoise falsely claim to be a college professor, but I've never seen User:RandyFromBoise falsely claim to be Professor Randy Knowitall from Boise University. The latter claim is far too easy for other editors to test, simply by sending an email to the good professor. The particularly conscientious or thorough professor might put up a link to his Wikipedia account from his website or blog. Verifying the identity and credentials of an editor who is willing to link their Wikipedia account to their real-life name is seldom required and generally straightforward to accomplish.
Has there been a rash of editors impersonating specific, named, real-life subject matter experts that I was unaware of? Are there really that many - or any - unresolved disputes involving editors doubting a genuine, self-identified expert's identity? In short, the ad hoc mechanisms we have for users to self-identify – often just a declaration on one's user page suffices – seem to work just fine; why would we want to build a formal and complex (and potentially vulnerable) identity verification system? TenOfAllTrades(talk) 18:37, 31 August 2012 (UTC)[reply]
Has there been a rash of editors impersonating specific, named, real-life subject matter experts - if you re-read my proposal, you will see that this is not a problem I have mentioned (I'm not aware of this being an issue either). The reason it's not a problem is precisely that Wikipedia has a culture that credentials are completely irrelevant; therefore asserting them is largely pointless, and making easily disprovable assertions about them is fairly foolish anyway. No, the motivation for the proposal is more in encouraging new editors with offwiki expertise to verify that expertise, so that this expertise can feed into discussions (in whatever way other editors participating are willing). Basically, there are two aims: (i) by allowing experts to participate qua experts, even at the discretion of everyone else in a discussion, we ought to reach better outcomes in discussions. (ii) by acknowledging expertise (ideally as an optional part of the signup process), we should in the longer term get more experts contributing, because there will be more sense that expertise is valued. And frankly, if we don't get more experts contributing, using resources at their disposal that others probably don't, then there is a definite limit to the quality that can be achieved by enthusiastic amateurs with access to free online resources (or decent public libraries if you're lucky), which is how most WP content is currently written. Rd232talk19:13, 31 August 2012 (UTC)[reply]
The problem is that you're addressing the wrong issue, then. The trouble is illustrated quite clearly by Jayron32's comment immediately below. The difficulty is not editors with the attitude "I don't believe you're the expert you claim you are"; it's editors with the attitude "I believe you are who you say you are, but I don't care". The – as you put it – 'anti-expert fantasy' won't be dispelled by providing additional mechanisms for editors to prove their identities; their identities aren't generally disputed. TenOfAllTrades(talk) 19:52, 31 August 2012 (UTC)[reply]
Hold on, that is also not what I said. I care a lot about what experts have to say. That's why I use the works of experts to cite when I write Wikipedia articles. Perhaps there is a fear of the use of credentials in lieu of having to cite one's sources, and I don't see that as a positive development either. I love when experts edit Wikipedia because they have access to, and understanding of, sources which non-experts don't necessarily do. But any identity verification system doesn't make Wikipedia any more or less friendly to experts, the only conceivable end I can see is that it would create classes of editors which are held to different standards of sourcing, writing, and verifiability. Experts should be here working, but they should not be exempt from Wikipedia policies and standards, and for that reason (among others), I don't see what is to be gained from verifying one's credentials. --Jayron3220:20, 31 August 2012 (UTC)[reply]
The place where I see experts often getting the most frustrated is not when they're trying to add stuff in without references. In general, the academics I encounter – on Wikipedia and in real life – are quite understanding about the need for proper sourcing and citations—probably more so than the average person off the street. For academics, citations and footnotes are their bread and butter; using them comes almost as naturally as breathing. While there are certainly exceptions, the experts I see on the project aren't looking for an exemption from Wikipedia's rules.
No, the place where I see (and experience) the most frustration is in dealing with the non-expert who clearly doesn't understand the meaning or significance of the sources he is trying to use, but wants to use that dubious source to push a POV in an article anyway. (This comes up a lot in the fringe medicine and science articles: cold fusion, AIDS denialism, anti-vaccinationists, suppressed 'all-natural' cancer cures, etc.) Because the non-expert is unfamiliar with the field and its literature (and often writes from a particular, peculiar point of view), he doesn't know how to evaluate the sources available to him, and he isn't willing to listen to an expert's explanations, preferring instead to fall back on attempting to rules-lawyer the guidelines in WP:RS and WP:MEDRS. TenOfAllTrades(talk) 21:40, 31 August 2012 (UTC)[reply]
I vehemently oppose any system, voluntary or not, which seeks to verify anyone's identity at Wikipedia. Even if voluntary, it would give extra credence and weight to users whose identities had been verified, and I don't think we want that. I can think of a LOT of good reasons why people wouldn't want their identity verified, not the least of which is having to explain to the cops why the stranger on my doorstep in the middle of the night has a dent the shape of my baseball bat in his head. Wikipedia users are only machines to rewrite and cite what is already written in reliable sources, and as such, it doesn't matter what our credentials are, it only matters how good we are at digesting source material and writing fresh articles from that source material. There's no way that knowing what my degree is or what my job is in any way makes my text more reliable. --Jayron3219:21, 31 August 2012 (UTC)[reply]
Wikipedia users are only machines to rewrite and cite what is already written in reliable sources - there's the crux of the Wikipedia anti-expert fantasy: the idea not just that anyone can write good content based on reliable sources (and that it matters not that some people have access to better sources than Google), but (i) that everyone is equally good at understanding and digesting and summarising reliable sources and (ii) that when disputes arise they can always be settled with reference to sources - because there's never any issue about interpretation of sources (often displaced onto interpreting the "reliability" of sources, since editors aren't supposed to interpret) or dealing with sources that contradict each other. No, it's really just rote copying! Rd232talk19:29, 31 August 2012 (UTC)[reply]
It seems like you're trying to change the culture by changing the rules, when it usually works better the other way around. But then I don't have any ideas about how to change the culture.--Curtis Clark (talk) 20:02, 31 August 2012 (UTC)[reply]
It isn't that everyone is equally good at it, it is that there is no correlation between the skill set necessary to be a good editor at Wikipedia, and a person's professional certifications. Of course there are many people who stand no chance of being good Wikipedia editors, but there's nothing in someone's credentials that makes any indication that someone will or will not be. I've known plenty of highly credentialed, smart people who couldn't write for shit, and plenty of people with nothing more than a HS diploma who are excellent Wikipedia editors. If there is a fantasy, it is that there is any correlation between credentials and the skills necessary to edit Wikipedia. Nothing in my statement or my position implies that everyone is equally good. I never said or implied that, so you've invented a strawman there, if you want to disagree with my point, at least disagree with the point I made, and not one you wish I had made so you could shoot it down. The point that I made was that credentials are not a good system for making that judgement. There's nothing you could know about me and my provable identity which would determine whether or not I would be a good editor at Wikipedia, at least, not reliably enough that it's worth getting those inevitable 2AM phone calls threatening my wife and children by name. No thank you. Someone trustworthiness at Wikipedia should be judged by the quality of the work they do at Wikipedia. --Jayron3220:12, 31 August 2012 (UTC)[reply]
Politely but firmly, Jayron, that's nonsense. The correlation is by no means perfect, but a person's qualifications tend to be associated with an ability to contribute effectively in technical or esoteric areas, and people with a real-life track record working in an area are more likely to be able to find, use, and evaluate references appropriately. What I'm not saying – and what no one here is saying – is that a person's credentials and qualifications are the only factor that determines one's ability to contribute, or that such credentials could or should be required to contribute.
As well, a real-life identity offers others a broader and deeper record of "User contributions" to consider, and can form one more element of the reliability/competence heuristic we might use in assessing one another as editors. Even if an editor's real-life identity isn't associated with a set of formal qualifications and credentials, it can still help to build a picture of a person's interests and skills. In some areas, it can dispel concerns about conflicts of interest and the like. As you point out, disclosure of real-life identity does carry some risks and costs (which is one of the reasons why I haven't done it) but it can also be one effective route to letting other Wikipedians know what tools you're bringing to our party. The fiction that Wikipedia editors aren't real people, and that we should not acknowledge or consider anything they do outside their edits to this project, isn't always healthy or useful. TenOfAllTrades(talk) 10:30, 1 September 2012 (UTC)[reply]
I have no pressing thought on this proposal in the current moment, but I wanted to point out that we do already have a kind of mechanism like this. Currently, when an editor wishes to utilize the real name of a famous person as a username, he or she is required to verify (usually to an administrator, OTRS, or the secure-info mailing list) that that name is their actual real name. Upon doing so, they are required to note whether or not they are that famous person or not on their user page (See WP:REALNAME). This serves as a verification of identity to avoid impersonation risks. Without evidence of verification, usernames like this are often blocked until it has clearly taken place. We get these every now and then at WP:ACC. NTox · talk20:22, 31 August 2012 (UTC)[reply]
Support. See how easy that is to say, O perennial naysayers?! :) Anything that helps provide more info about sources is useful to Wikipedia. And an editor's verifiable identity does help me in learning more about sources. That is because I am going to check out the sources an expert provides for article references before I check out the sources from some drive-by poster with a pseudonym. In either case the info in Wikipedia has to be reliably sourced. This idea is just another timesaver needed to make editing more efficient. We have more articles and less editors, and so we need to be more efficient. I suggest WikiProjects and others advertise WP:REALNAME since this exists now. Encourage experts who use their real name to send an email to info-en@wikimedia.org to verify their name per the rules of the Wikipedia:Volunteer Response Team. They can then link to the verification ticket from their user page. --Timeshifter (talk) 04:16, 1 September 2012 (UTC)[reply]
Fortunately, it does not matter what Jayron32 thinks about this since WP:REALNAME already exists. What people do on their user pages is mostly their business, and if they want to better verify their identity it is their choice. What? Is Jayron32 going to tell someone they do not have a right to better prove their identity. Ha! I know that Randy in Boise may be disappointed by this but I WP:DGAF. --Timeshifter (talk) 05:12, 1 September 2012 (UTC)[reply]
What this proposed system does, however, is establish a culture at Wikipedia whereby people who have established their identity are treated as a higher class of editors than those who, for whatever reason, have chosen not to. The WP:REALNAME situation exists for a different reason, and does not substantially change the nature of Wikipedia culture. A culture where some editors are given "supereditor" status because they've proven their identity is not a good idea. --Jayron3214:47, 1 September 2012 (UTC)[reply]
A system cannot establish culture (or certainly not in any straightforward way). The culture is already inimical to expertise, and I don't see that changing, whether or not this is done. (I actually see this as increasing the negativity towards editors who identify themselves.)--Curtis Clark (talk) 21:45, 1 September 2012 (UTC)[reply]
Two points 1) Wikipedia culture is not inimical to expertise. We use the work of experts all the time; ideally all of our articles should be sourced to the highest quality works written by the best respected experts in their respective fields. 2) If what you say is right, then that's still my reason for opposing. We shouldn't be creating classes of editors, either those who get super status, or those who get downgraded. --Jayron3205:12, 3 September 2012 (UTC)[reply]
Even non-experts who know what they are talking about will have problems if they expect logic and truth to be valued. The only thing valued on Wikipedia to the point of something actually staying on Wikipedia is rough consensus. Of course, many articles don't have enough editors to reach some kind of consensus. So drive-by editors rule in those cases, and tagteams, many of which are tagteams of morons. See User:Timeshifter/More articles and less editors. --Timeshifter (talk) 11:23, 5 September 2012 (UTC)[reply]
Nothing essentially changes.WP:REALNAME exists, and people can and do allocate whatever weight they desire to the points made by various editors. People oftentimes provide their real name and give some info about themselves on their user page. I can usually tell over time if they are lying about who they claim to be, without WP:REALNAME verification. I choose to allocate more time to researching the info and references provided by experts versus the info and references provided by morons like Randy in Boise. If you want to, you can choose to allocate more of your time to listening to morons. --Timeshifter (talk) 15:37, 1 September 2012 (UTC)[reply]
Oppose."Example: if authenticated Professor X says Y is a crappy source because of verifiable reason Z, that ought to carry more weight in a discussion than if PseudonymBla says it (especially if it's within Professor X's expertise)."
I strongly disagree that this "ought to carry more weight in a discussion than if PseudonymBla says it". Either a source is reliable or it is not. Why is it important for us who actually says source XYZ is crap or not? -- Toshio Yamaguchi (tlk−ctb) 10:06, 1 September 2012 (UTC)[reply]
Because an expert might actually know what they are talking about. In any case, it still has to be verified. But it is easier when some experts agree that a source is reliable. --Timeshifter (talk) 15:41, 1 September 2012 (UTC)[reply]
I still disagree. Content needs to be based on reliable sources and if we reproduce here at Wikipedia what a reliable source says, then there is simply no need for this. I agree that many sources require a solid background to be understood. In that case the editors who want to deal with the source have to acquire the necessary knowledge. I agree that this is not always easy and thus it would definitely be an advantage if we had editors knowledgeable about the subject. But this is not the way to achieve that. -- Toshio Yamaguchi (tlk−ctb) 15:00, 14 September 2012 (UTC)[reply]
I too oppose this idea. Such verifications, voluntarily or not, will only eventually create a WikiFacebook. An editor's real-life identity is not needed to verify and assess the sources they provide. Giving whatever weight to an editor's identity creates just the sort of bias and NPOV we don't want to have in our articles. There are of course Wikipedia:Wikipedians with articles, i.e. notable people editing WP, but their input should still be put under the same scrutiny than everybody else's contributions. Even commited experts are not infallible and some even tend to make their competitor's work look bad on purpose. So let's keep the current process of having the casual editor decide which sources look reliable or not. Apart from that I have a feeling that a Wikipedia with a sudden burst of openly verified experts on board who are given additional weight will only further discourage layman editors from registering. De728631 (talk) 11:46, 1 September 2012 (UTC)[reply]
"So let's keep the current process of having the casual editor decide which sources look reliable or not." The current process is not changed. You do not understand the proposal. --Timeshifter (talk) 11:17, 5 September 2012 (UTC)[reply]
Bad idea. Very few experts/academics edit Wikipedia relative to the number of experts/academics in any given field, and some of those who did turn up were unfortunately just as problematic as ultra-nationalist POV pushers, except for the somewhat obscure area of their drive, typically related to their own work; some were sanctioned by ArbCom. In light of this, proposing that the experts who bother to show up be effectively overruling the "plebs" because they ticked some bureaucratic boxes doesn't sound promising, especially since experience shows that they're more likely to pop up in areas where controversies exist in the their field. If consensus of reliable sources points in one direction, it's pretty easy to have most reasonable wikipedians agree on what that is, even if they're not mega-experts on the topic. Citizendum didn't fare so well... WP:RANDYs get recognized easily enough on Wikipedia, although I admit I feel there's sometimes a reluctance to take administrative action against them, even when they are moderately aggressive and persistent. Generally, posting at a WikiProject will get matters resolved, at least as far the contents is concerned, although there are some exceptions. Tijfo098 (talk) 07:30, 5 September 2012 (UTC)[reply]
"proposing that the experts who bother to show up be effectively overruling the 'plebs' because they ticked some bureaucratic boxes doesn't sound promising." Experts don't overrule anybody. Nothing has changed in how Wikipedia makes content decisions. Most of the people who oppose don't understand the proposal. --Timeshifter (talk) 11:17, 5 September 2012 (UTC)[reply]
Maybe you didn't read it carefully enough. Quote from the proposal: "Example: if authenticated Professor X says Y is a crappy source because of verifiable reason Z, that ought to carry more weight in a discussion than if PseudonymBla says it (especially if it's within Professor X's expertise)." Tijfo098 (talk) 16:17, 5 September 2012 (UTC)[reply]
"ought to carry more weight". It does not carry more weight now, and will not carry more weight if this proposal was passed. People will still make up their own minds, and articles will still be edited according to rough consensus as to how well the article follows the Wikipedia guidelines. The proposal discusses "ad hoc gradations of respect", and how this proposal aids those informal factors in decision making. --Timeshifter (talk) 11:15, 6 September 2012 (UTC)[reply]
Yes, it would be a first (and pretty big) step in an obviously wrong direction. Also quite costly and requiring Foundation technical/financial support. So why bother with it given that the ultimate goal on that road is the anti-thesis of Wikipedia's editing model? (See this for a pair of recent examples). Tijfo098 (talk) 17:00, 7 September 2012 (UTC)[reply]
People who are threatened by people who are more knowledgeable than them may not like editing at Wikipedia. I am not threatened by people who are more knowledgeable than me in some areas. I enjoy learning. It is not the antithesis of Wikipedia's editing model. Wikipedia acknowledges that some people, websites, sources, etc. are more reliable than others. See WP:RS. Wikipedia is based upon learning how to sift sources. Anything that helps that is a good thing. It is still up to the rough consensus of editors to determine things in the end. That does not change.
It does not cost much to do this. It may not cost anything. Volunteers do much of the development work and other work on Wikipedia and MediaWiki. --Timeshifter (talk) 18:22, 7 September 2012 (UTC)[reply]
Comment I don't have a problem with identifying who I am. I edit under my real name, and plenty of people have met me at Wikimedia meetups and at Wikimania etc. I don't honestly believe there's much doubt among Wikipedians that I am who I say I am. Why do I edit in my real name? It sure ain't for the money, sexual favours or the slightly higher risk of some nutter wanting to chop my head off and eat my balls for breakfast after I close an AfD the wrong way or whatever. It's primarily because I'm lazy and too unimaginative to come up with a decent nickname. There's also the built-in immunity to outing: as Rachel Maddow said of the other sense of outing, "nobody can insult you by telling you what you've just told them". There'll never be a dramatic ANI thread with someone trying to reveal my real name. Beyond these few scant benefits, what exactly does this give me? Ought I be exempt from, say, reliable sources because I'm open about my real life name? Well, no. I can't really think of any Wikipedia editing policy that I ought to not obey because I'm open about my RL identity. The expertise thing, then. What if we've got some professor who wants to edit Wikipedia and be open about who he is? Well, he'll get the same treatment as anybody else, but if he desperately wishes to do so, most universities have the ability to set up a homepage. Create an account on Wikipedia under your real name, link to your academic homepage, and on that academic homepage link back to your Wikipedia account. Done. Anyone who wishes to judge you on your degrees and expertise can now do so. Someone mentioned Citizendium. I was formerly very heavily involved in Citizendium. Real names didn't really work to solve the people-being-dicks problem. People were still uncivil even with their real names attached. The only real benefit it gave was it reduced the amount of vandalism and socking. But that might have been a side effect of reducing dramatically the number of editors. —Tom Morris (talk) 13:12, 8 September 2012 (UTC)[reply]
Thanks for letting me know. I returned it, and then it was deleted again. People can check that the website is really for the university or business or not. By the domain name. By the way, I am a figment of my own imagination. :)
Its forbidden in Muslim's faith to portray any kind of photo or illustration of Prophet Peace Be Upon Him. that is why, Wikipedia must respect the faith of Muslims about the issue. Wikipedia has to remove the illustration of Holy Prophet from the given article.
Please see Talk:Muhammad/FAQ. The first answer in particular explains the issue you raise:
There is a prohibition of depicting Muhammad in certain Muslim communities. This prohibition is not universal among Muslim communities. For a discussion, see Depictions of Muhammad and Aniconism in Islam.
Wikipedia is not bound by any religious prohibitions. Wikipedia is an encyclopedia that strives to represent all topics from a neutral point of view, and therefore Wikipedia is not censored for the benefit of any particular group. So long as they are relevant to the article and do not violate any of Wikipedia's existing policies, nor the law of the U.S. state of Florida, where most of Wikipedia's servers are hosted, no content or images will be removed from Wikipedia because people find them objectionable or offensive. (See also: Wikipedia:Content disclaimer.)
Wikipedia does not single out Islam in this. There is content that is equally offensive to other religionists, such as the 1868 photograph shown at Bahá'u'lláh (offensive to adherents of the Bahá'í Faith), or the account of Scientology's "secret doctrine" at Xenu (offensive to adherents of Scientology), or the account at Timeline of human evolution (offensive to adherents of Young Earth creationism). Submitting to all these various sensitivities would make writing a neutral encyclopedia impossible.
I have come up with this idea to releive the burden on the backlog. Out of 4 million pages on Wikipedia, a significant percentage of them is in a miserable condition, are abandoned or not visited for a long time. As of today, there are more than 170,000 orphaned pages, 55,000 are tagged as non notable, more than 230,000 are tagged as unreferenced and 250,000 poorly referenced, including BLPs. Some of these pages are tagged like that since 2006 (there are more than 2000 orphaned pages tagged since november 2006).
The idea is to have Wikipedia automatically tag pages that satisfy a set of conditions - e.g. number of significant edits in the last 6 months (excluding bots) < 5 AND page accessed in the last 6 months < 20 times (from different IPs) - as semi-deleted ; the page would then be not accessible except for admins and a special group or reviewers (or a WikiProject) which will then decide the destiny of the page (merge or delete) without further discussion needed; alternatively (or in addition) another set of more severe rules would have Wikipedia automatically delete the page. Check for example the history of L-EXOS; the article has not been edited for more than 17 months, is still orphaned and since its creation in 2005 there have been no significant edits. You guess how many times it has been visited since. This would bypass the deletion discussion and would be an automated process helping keep Wikipedia much cleaner and make the backlog much more useful. --Itemirus (talk) 14:39, 3 September 2012 (UTC)[reply]
I miss your point. Is there a flag for unpublished articles? And what is it used for? I was suggesting semi-deleting articles that are already published. --Itemirus (talk) 15:43, 3 September 2012 (UTC)[reply]
I'm suggesting that 'semi deletion' is the wrong terminology for the functionality that you were proposing to add. Deletion being a negative concept, as well as inaccurate (since a large user group can still view the articles). Instead demoting something to 'unpublished' would be the same concept, yet better. —TheDJ (talk • contribs) 16:02, 3 September 2012 (UTC)[reply]
Strong oppose Some articles are in a good shape, but aren't edited very often. Also, this would mean that an article in good shape about a "not so popular" topic could get deleted just for not being popular. -- Toshio Yamaguchi (tlk−ctb) 15:56, 3 September 2012 (UTC)[reply]
"not so popular" is one thing; being totally invisible and forgotten is another; some articles are there just to clog the backlog, that's it.
I see no particular problem with that. If the article about the book remains a stub and is never read for quite a while, it means that no existing or prospective editor ever cared or cares about that book , not even the original article creator. I'd merge it into the author's page.--Itemirus (talk) 18:29, 3 September 2012 (UTC)[reply]
Oppose While the idea of a semi-delete or unpublish option is intriguing as a lighter alternative to deletion, having it happen automatically, without regard to the page quality and only based on edit frequency is seriously misguided. Also, stubs aren't evil... Monty84520:22, 3 September 2012 (UTC)[reply]
I don't think this type of proposal would help much in the long run. This could cause many articles that could potentially be improved to be consigned to a deletion process. Even though an article might meet some of the semi-deletion criteria listed, it might still meet notability and other guidelines, and thus is qualified for inclusion on Wikipedia and could conceivably be the subject of a once-in-ten-years search. dci | TALK 22:38, 3 September 2012 (UTC)[reply]
Further comment to my vote In my opinion, it is part of Wikipedias mission to accumulate knowledge in a readable form. And in my opinion we should not hide something only because an article received few or no attention in a while. I believe determining the importance of an article based on how many edits an article gets will only make us more like facebook and less like an encyclopedia. I am NOT saying that there are not lots of articles which are in a poor shape, but this is not the way to deal with this problem. -- Toshio Yamaguchi (tlk−ctb) 12:12, 4 September 2012 (UTC)[reply]
Strong oppose - I see the point your trying to make but the problem is there are more bad things this would create than it would help. For one, what is notability? Whats notable to me who may not care even a little about and vice versa. Many of those tags are in error or basically amount to spam and should probably be removed from the pages anyway. What purpose does it really serve to add an Expand, copyedit, Wikify or a number of other tags to a stub. We know it needs expanding! Its a stub. Also, aside from the number of times its been edited, how many times has it been viewed? There are plenty of articles that don't get edited much but have a relatively high number of views. Kumioko (talk) 19:19, 5 September 2012 (UTC)[reply]
Strong oppose - Ridiculous. Some GAs get 1-5 hits a day and no edits for months. Why? Because they are on a non-mainstream topic. Such a policy/guideline would just make systemic bias worse. — Crisco 1492 (talk) 05:56, 6 September 2012 (UTC)[reply]
Strong oppose. This will result in articles on valid topics getting deleted simply because they aren't that popular. If you see an article that you're sure nobody will care about, why not just use PROD? CtP (t • c) 01:11, 9 September 2012 (UTC)[reply]
Oppose (as stated) for many of the reasons noted above, the criteria will pick up decent articles on very obscure topics, which should not be semi-deleted or unpublished.
However I could imagine supporting an alternative, which targets poor quality articles. Perhaps one that get a sufficiently negative feedback score. --SPhilbrick(Talk)12:06, 10 September 2012 (UTC)[reply]
I happen to have Help:Searching on my watchlist and because of this I stumbled upon the AFT feedback about that page. It seems that a lot of people ending up on Help:Searching are utterly confused. I think this is in part due to the wording of the message MediaWiki:Search-summary on the search results page. "For search options, see Help:Searching." If I read that unbiased, especially when imagining not being too good at English, I can imagine that clicking this link will give you more options. It doesn't, it gives an unreadable amount of information that 99.5% of the users isn't really waiting for. I propose we reword this message to better explain that the target is a functional description of our Search system, for instance "Learn how our Search functionality works !". Additionally it would be good to rework Help:Searching to be more useful and especially more readable. And possibly, the Search-summary message on the search results page should be right aligned or something, because it might be confusing to have it be the first linktarget on the search results page. What do others think ? —TheDJ (talk • contribs) 15:57, 3 September 2012 (UTC)[reply]
If I knew nothing about Wikipedia, then I would think "Help:Searching" was where I could configure my search options. I would click the link, and then be very confused by a long page of stuff, none of which is search options. So I think the idea to change the MediaWiki search summary page is a good idea. David1217What I've done16:25, 3 September 2012 (UTC)[reply]
Note that Help:Searching was removed from this feedback system a few hours before the original post.[7] The edit summary was "Category:Article Feedback Blacklist, too much noise". The readers giving feedback saw the box to the right saying "Did you find what you were looking for?" If they clicked "No" then they got a box with heading "Sorry about that. Any suggestion for improvement?", and a feedback box prefilled with "What were you looking for?" In the case of Special:ArticleFeedbackv5/Help:Searching everybody naturally answered what they were originally searching for in the search box, and didn't comment on the actual content of Help:Searching. The box was designed for articles and has an unfortunate formulation for Help:Searching.
I think "Learn how the search function works." would be better than "Learn how our Search functionality works !". But I suggest an unpiped link saying "See Help:Searching for information about the search function." PrimeHunter (talk) 11:54, 4 September 2012 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I know this is listed, in a way or another, as a perennial proposal, but I'd like to submit a variation to it.
The fact that Wikipedia can be edited by anyone is a founding principle of the encyclopedia, and I agree. Anyway there is nowadays a Wikipedia article for at least 99.9% of every bit of human knowledge: almost every city, including micro-villages, in the world has an article; all celebrities have an article; every constituent of physical matter in every form, known and theoretical, has an article; even the most obscure philosophical concepts have an article. The point is, at least 50% of all new articles created is deleted within a week if not immediately by CSD; another 30% is non-notable, orphaned and unreferenced and stays like that thereafter. I assume the remaining 20% is suitable content for an encyclopedia. The problem is that most of editor and admin resources are wasted fixing the problems caused by that 80% bad articles that are created everyday.
More and more people get access to the internet in the emerging regions of the planet such as India, North Africa, the Middle East and China. This is great news for freedom and democracy, but it also entails the problem that some of these guys (and even a small percentage means thousands of people each day) want to edit the 6th most popular website in the world, and most of the time they do it just to get in the spotlight, because they have a conflict of interest, for religious propaganda (especially fanaticism-prone Islam), because they are paid to advertise, or just for (disruptive) fun.
Jimbo Wales has complained that Wikipedia is slowly dying; maybe because it is becoming too messy and/or large to manage for dedicated editors?
The best solution to all of this would be preventing non-confirmed users to create new articles. IPs would still be able to submit drafts for new articles, but these would not be immediately published; instead they would remain suspended to be reviewed by new page patrollers, before getting a red or green light for publication.
This would be a fantastic deterrent against the creation of unwanted material because the anonymous editor now knows that his article will not go immediately online but would be subject to review - hoaxes, unreferenced biographies, advertisements, non-notable and unsourced content would have zero chance of being published on Wikipedia.
One could argue that new user creation is a matter of a few seconds. That is right, but is still a further step one has to take before being able to create articles; in the meantime they could change their mind; requiring email confirmation to register new accounts would be the final nail in the coffin against unwanted content.
A lot of resources would then be freed to counter vandalism and to relieve the backlog.
The anyone can edit (and create) concept made a lot of sense while Wikipedia was in its infancy and needed to grow. To prevent Wikipedia from becoming an utter mess, stripping that concept of the create part would make a lot of sense in 2013.--Itemirus (talk) 14:01, 4 September 2012 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Gah. Subpage proliferation madness. This kind of thing is very hard to maintain/understand/watchlist properly, hence a supercomplicated overhaul will usually lead to inactivity soon afterwards.
I recommend: Merge as fiercely as possible, if you've got the patience to do it properly. If you don't, then it might be best to just mark as historical, and remove/redirect any incoming links from navboxes/helppages etc.
I was wondering what folks would think of including a section in the WP: , to encourage editors both new and old to remember the ronin part of this community project. This is part of WP:Bold in some ways, but I think it might be welcome encouragement for (forgive the term) "outside the box thinkers." Interested in what you folks think.
It could be, for instance, WP:Pilot, as a reference to pilots, who, from ancient Greek times, had to be relied upon to make independent decisions.
I think Wikipedia should create a new skin for users who prefer a dark theme. It should not be that difficult to implement. Change just a few color sets, such as black or dark gray as the background, fonts can be white, internal links can be yellow, etc. Otherwise the design can be equivalent to the original.
It would be extremely appreciated by many, it would also be functional for someone who works in a dark room and hence not having to squint because of bright white light from the screen. The option would be available to registered users, and perhaps even for ordinary readers, if possible.
Please consider this proposal! Can be very useful for some people, and is not difficult to implement.
There's an option in Preferences > Gadgets for "Use a black background with green text on the Monobook skin"; if you tick this, you'll probably also need to set the skin back to monobook from the default vector. Hopefully this should be more or less what you're looking for... Andrew Gray (talk) 22:44, 8 September 2012 (UTC)[reply]
Thank you very much! Fixed it, it's a good skin for night reading but the option is hard to find for common people. And the design is somewhat outdated, had not implemented Wikipedia's renewal of the design. Hope someone has the desire to improve it and make it more "mainstream", would help many others. ThTK35 (talk) 13:55, 9 September 2012 (UTC)[reply]
There have been quite some requests for "black background, green text" for vector:
Is Athena expected to have multiple skin options? I had assumed from the description that it was still one basic design, rather than a collection. Andrew Gray (talk) 22:05, 9 September 2012 (UTC)[reply]
(with my work account now) Athena is basically a set of design goals, and while I think it will end up with one new skin, the design team is looking at variety of ideas for look-and-feel right now. If a light and dark option for any skin is something folks want (it's quite a reasonable request), then you should drop by the Athena talk page and suggest it. Steven Walling (WMF) • talk18:35, 10 September 2012 (UTC)[reply]
For a black Vector, we could perhaps use a more readable version of this one I made as a joke on uncyclopedia in January. While that is just a page gag in monobook, I was going to make it work with the current mediawiki anyway one of these days, and wikipedia is so much more stylable than uncyclopedia... could be fun. Be pretty trivial to then add the vector css to the monobook gadget to make it support both, though that would also make it a bit bigger... should I do that, then? -— Isarra༆05:06, 14 September 2012 (UTC)[reply]
Talk page archivers: leaving a TOC trail
This is to propose a new (optional) Talk page archiver behavior, making access to previous topics easier, while keeping Talk pages reasonably small.
Archive (move dated topics to archive, creating new archive pages as specified) using the same basic behaviors as User:MiszaBot and User:ClueBot III
In Talk, keep (or create) a top-of-page level 2 topic: ==Previous discussions==
Under ==Previous discussions== add a level 3 title which links to the archived level 2 dated topic
I believe this will have a beneficial effect, by keeping the fact that prior (perhaps very important) discussions occurred, visible right there in the TOC. Thoughts?
--Lexein (talk) 21:56, 8 September 2012 (UTC)[reply]
I'm imagining that ==Previous discussions== would be permanent, but maybe that section can be collapsible-boxed. I mean, the TOC itself is collapsible...--Lexein (talk) 22:45, 8 September 2012 (UTC)[reply]
Seems reasonable for low activity talk pages, though would be totally unworkable for very high activity ones, so the bot would need to handle the conversion from the new method to a conventional high volume archive when necessary. Monty84523:54, 9 September 2012 (UTC)[reply]
Right. There is no conversion. To stop leaving a TOC-trail, just delete the whole ==Previous discussions== section and set the archiver option |TOC-trail = no. No other change is necessary. All the /Archive1...n will still be there, because of requirement (1) above. --Lexein (talk) 00:47, 10 September 2012 (UTC)[reply]
That's a separate index page. This is about keeping the Talk page integral, requiring no off-page navigation to see prior topics, in a very compact way. --Lexein (talk) 06:04, 10 September 2012 (UTC)[reply]
My proposal is not intended for high-bandwidth Talk pages. Do you have a specific objection to a compact, non-transcluded, TOC-based archive index as suggested?--Lexein (talk) 10:55, 10 September 2012 (UTC)[reply]
Comment. You could keep the last year, 3 months, or 6 months TOC trail on the talk page. After that period of time, move the old TOC trail index to a consolidation page. Keep moving the TOC trail to that one page. Then you end up with one TOC index on one page. That would be very useful.
Currently, busy talk pages such as Village Pumps have huge archives spread out over many pages. The only way to find anything is with an archive search tool. It would be nice to be able to scan the topics, too. If I am looking to see what the topics of discussion have been for the last year or 6 months this would be very convenient.
Look at meta:Wikimedia Foundation Report, July 2012 and the archive index by month and year to the right. That collapsible index format could be adapted to a TOC trail consolidated to one page.
Ok, now I see that a separate cumulative (compact) TOC trail page makes sense. I theorize that keeping a TOC trail of links to old discussions will help stickiness, and help avoid needless rediscussion, but I have no proof that it will help. People will often write before reading, and that's human nature. Navigation of old content is always going to be a bit of a thorn, and I well know there can't be a single solution. I should test the idea by manually creating a TOC trail on one Talk page for a few key already-archived topics, to see how people respond to it. A question remains - how do we keep people from commenting in the Archives? Full page protection? --Lexein (talk) 16:38, 10 September 2012 (UTC)[reply]
Well, the only reason I see not to allow people from editing "archived" discussions is because their comments may not be seen, since people only watch the main talk page. This is not a problem on Portuguese Wikipedia, which uses subpages for each topic, because "archiving a topic" just means "removing a link to it from the main talk page". In this case, anyone who was watching the topic before it was archived will still be watching it afterwards (and then will note a new comment made after the archiving). If more then one people add comments on an "archived" topic, it can be resurrected by re-adding the link on the main page. Helder18:37, 10 September 2012 (UTC)[reply]
I think DPLforum is a better way to index Village Pumps based on subpages. See mw:Extension:DPLforum and the discussion higher up:
With DPLforum discussion titles do not have to be manually added back to the main page.
Wikia's Village Pumps use DPLforum where subpage discussion titles are listed and linked on the discussion entry page. The discussion with the latest reply is at the top. So old discussions can be replied to, and their title automatically moved back to the main page. At Wikia, old discussions are automatically "archived" after around a couple months (I believe) without replies. The edit link on those discussions is gone, and a trick has to be used to edit it. So it is difficult to reply to archived discussions older than two months.
English Wikipedia talk archives are marked as archives at the top and bottom of the page. So people know not to reply to them.
On pages with that banner there are no edit buttons except at the top of the page. They are not fully protected pages, because sometimes people want to update links, especially links to discussions after they are archived.
With any Mediawiki discussion method it would be nice to have a TOC trail by date of creation of topics. But what to do after that. With its archives English Wikipedia can show on one page all the old topics from a certain period in the past.
Portuguese Village Pump does not currently have a way to compile old topics and open them up on one page. For example; by month. It would be nice to be able to pick a month, any month, and see all the topics started in that month opened up on one page. --Timeshifter (talk) 15:56, 11 September 2012 (UTC)[reply]
Interesting. I found this too: Template:Deletion debates. It is funny and telling that deletion discussions are cataloged and organized in multitudinous ways, but English Village Pump discussions use out-of-date software, have a poor TOC trail, and can not be linked to permanently. I wish I could program JavaScript, but I haven't studied it. I can edit some HTML and some basic CSS. Maybe some other JavaScript coders reading this can help out. --Timeshifter (talk) 16:48, 12 September 2012 (UTC)[reply]
(created article) date
Each article has a last modified date in the main page of the article {Read tab},
I have a small suggestion to include the (created article) date _which is already existing in {View history tab}_ in the {Read tab} of the article.
For example:
This page was first created on XX XXXX XXXX at XX:XX
This page was last modified on XX XXXX XXXX at XX:XX
Why is it necessary? Just click the link for "earliest" in the history and scroll to the bottom. That will show the first edit to the page—i.e., when the article was created. —C.Fred (talk) 00:42, 11 September 2012 (UTC)[reply]
As far as I see it, this would be rarely necessary. The last modified section is sufficient: a user can easily check to ensure the page might not be outdated. Hazard-SJ ✈ 03:17, 11 September 2012 (UTC)[reply]
Add functionality to include links to sister projects in infoboxes
This is done on Polish Wikipedia, see for example pl:Maria Dąbrowska and look at the bottom of the infobox. It is pretty self-explanatory. I think it would raise the awareness of our sister projects among the readers, and thus improve the functionality of our articles. I upload a lot of photos to Commons, and occasionally I'll have people from museums and such get back to me and tell me they cannot find the gallery I promised them, even through it is linked through {{commonscat}}. I am not surprised - to find this tiny template they have to scroll to the bottom, and the template does not even include the word "gallery". Sigh. Adding "Gallery in Wikimiedia Commons", "Text in Wikisource", "Quotes in Wikiquote" and such to the infoboxes seems like a win-win. Thoughts? --Piotr Konieczny aka Prokonsul Piotrus| reply here17:01, 11 September 2012 (UTC)[reply]
We already do this to some extent, but do it at the bottom of articles, usually in the "see also" section rather than the infobox. Just a random example, see Federalist No. 51, which contains a little box near the bottom that tells you about the Wikisource document. --Jayron3217:09, 11 September 2012 (UTC)[reply]
I know, that's why I mentioned the commonscat template. My point is that at the bottom is not as good as at the top, through I see no reason not to have both. I am not suggesting removal / replacement of the current templates, I am just suggesting adding their functionality to the infoboxes, to increase their visibility. --Piotr Konieczny aka Prokonsul Piotrus| reply here17:52, 11 September 2012 (UTC)[reply]
Navigational templates are for links to pages within each Wikipedia itself (internal links only). Not that we are trying to trap our readers here within each encyclopedia, but our info should be linked well before any external links that lead readers to info beyond what is offered here. External links should not be incorporated info the article text or nav boxes - they should be in the External links section to indicate to our readers there leaving English Wiki - as per Wikipedia:Wikimedia sister projects#Where to place links.Moxy (talk) 18:42, 11 September 2012 (UTC)[reply]
Wikipedia:Wikimedia sister projects is not a policy, so we should treat it just as an optional suggestion. The links I propose would be clearly labelled ("See gallery at Wikimedia Commons"), so people should not be overly confused. Any confusion from leaving our site should be well compensated for by the fact that it will be easier for people to access highly relevant content (galleries, source texts, quotes). Polish Wikipedia also includes clearly labelled external links to organizational home pages, which I think is also a good idea, although please note that I am not advocating adding this functionality in this proposal (I don't want to get too off topic here). --Piotr Konieczny aka Prokonsul Piotrus| reply here19:02, 11 September 2012 (UTC)[reply]
I think this is a good idea. Sister project links generally go in the "External links" section these days, which doesn't really make sense to me, since they're not "external" from Wikimedia. Wikimedia content should not be considered the same as external content. --Yair rand (talk) 18:57, 11 September 2012 (UTC)[reply]
"Sister projects" are external links in my opinion (as seen at Wikipedia:External links#Links to be considered) and due to the fact they require separate registration for the end user. I personal believe any external links should be after the "See also" section - Refs - Bibliography - Notes - Further reading - External links .. all lead readers away from English Wiki, thus should be seen last. I do however believe "Sister projects" links should all be listed on the left side of pages like with our other "language wikis" or even there own section under "See also". I believe having 9 external links in an info-box/navbox is simply overwhelming.Moxy (talk) 19:41, 11 September 2012 (UTC)[reply]
You wouldn't have 9, just 1-3. And it wouldn't be overwhelming, just helpful (have you bothered to look at the linked example before you invented the 9-link strawman? Anyway, I find it discouraging that so many will fall back on policy, rather than consider the arguments abut readability and usefulness. Here's a heresy to consider: policy should be changed to accommodate user experience, not the other way around. But if anyone want's to wikilawyer the policy here, note that Wikipedia:External_links#Templates_for_external_links encourages the use of links to sister projects in templates, and infoboxes are templates. QED :) --Piotr Konieczny aka Prokonsul Piotrus| reply here20:12, 11 September 2012 (UTC)[reply]
"invented the 9-link strawman" Pls see how many sister projects there are at Wikipedia:Wikimedia sister projects - I think your misreading that guide - its about templates "for" external links - not "about" external links. Its talking about making templates for external links - like Template:Official website that you may see in a musicians info box (that I believe should only be seen in external links anyways). I have not relied solely on policy for my position - but have explained that having links that lead our readers away for English Wiki so fast is not helpful. English wiki is not here to produce traffic to the other wikis, but to inform our editors here - for more info they should see below the "See also" section that will lead them to pages that do not comply with our policies of neutrality and verifiability etc. That said I believe our internal portals should be linked in the fashion you mentioned above. (Moxy (talk) 20:28, 11 September 2012 (UTC)[reply]
Portals? They are usually off topic and pretty useless. As our polices suggest moving certain type of content to our sister projects (quotes, source text, galleries), I think it is only fair that we should inform our visitors of that through easy to access links. As I said above, I have had people complain to me they cannot find associated galleries because we don't make the links to commons galleries visible enough. To fulfill our mission to inform the readers, we must make those links more prominent. --Piotr Konieczny aka Prokonsul Piotrus| reply here23:01, 11 September 2012 (UTC)[reply]
Unless you can cite results of a survey, I am not convinced; I would counter hypothesize that many people don't look at the bottom, past references and such, they stop where the main text ends and thus never see this template. Therefore, why not have both? We are not paper, we have space for helpful redundancy. --Piotr Konieczny aka Prokonsul Piotrus| reply here15:49, 12 September 2012 (UTC)[reply]
Eliminate stub templates completely
Reiterating my comment from Wikipedia_talk:Manual_of_Style/Layout which was mentioned by another user at Wikipedia_talk:Stub, I propose that all stub templates are eliminated. Some similar proposals have been raised before without generating much discussion:
PROPOSAL: Stub templates should be completely eliminated. RATIONALE: There are a variety of reasons. It is often unclear to editors when to remove them. For instance, it is very common to see articles that are way past stub status yet still have stub a template (or templates!) attached. Sort of opposite to the previous case, there are very many articles that are unlikely to ever get past stub status and so the templates just linger providing clutter. Spoiler tags were removed in part because it was "generally expected that the subjects of Wikipedia articles will be covered in detail" and were clutter. A template reminding us that we can expand an article is equally useless. It is always true that we can help expand an article so a template reminding us of that is clutter. A case could be made that the templates encourage new editors to start editing but stub templates have always been sold as helping organize articles, not as an "editor engagement" method. Even if the "editor engagement" benefit of footers is worthwhile, it could easily be done sans all the categorical (in the sense of requiring Wikipedia categories) baggage that stub templates entail. For example, simply putting "You can help Wikipedia by expanding this article" at the bottom of every article does the same trick. The other benefits of stub templates (which seem to be limited to just allowing editors interested in a topic to find short articles to edit) could be subsumed into the article class rating of Wikiprojects. Any editors that like to expand short articles could locate them through Wikiprojects. We currently have this duplication of article "rating" which can cause a Wikiproject article class rating to be incongruent with the presence of a stub template. This proposal eliminates that duplication.
I anticipate from the other similar proposals that somebody will claim that stubs templates help expand articles. There is, to my knowledge, no study to support (or deny) that claim. My anecdotal experience lends me to believe there's no significant expansion of articles due to stub templates so I skeptical of such claims. If you are going to claim this, either cite a study or recognize your own view is also anecdotal. Jason Quinn (talk) 15:06, 12 September 2012 (UTC)[reply]
Personally I think that the stub templates could be cut way way back but not eliminated. I think we have way too many stub templates, a lot of which aren't used or IMO needed and it just causes too much maintenance to continually add them and remove them as necessary. Its a full time job for a dozen or more people just doing stub sorting. I think its better to use less stub templates and spend more time working on the article. More to the point, here is why I don't think they can be completely eliminated.
Some projects gauge the stub "assessment" differently than the stub tag.
Most people don't mess with talk page templates so far less are likely to add them
Adding stub tags, to me, is an important part of sorting the articles
tagging as stub is a good checks and balances between the aritcle and the talk page. Many assessment bots look for the stub tag to assess the article automatically. Kumioko (talk) 17:06, 12 September 2012 (UTC)[reply]
A stub template really serves two functions. First, it is an invitation to edit. Subjectively, I don't believe it helps much, if at all, in this regard. The second reason is stub sorting. So my question, which I believe Kumioko may be able to answer, is what is the value in stub sorting? Resolute17:19, 12 September 2012 (UTC)[reply]
First, I personally agree that its unlikely to me that an editor is going to edit the article because they see a stub tag buried at the bottom of the page. That's always been a stretch for me. As I mentioned above I also think that in many cases we over complicate the stubbing/categorization process by adding too many layers. For example, all of the following stub tags add the articles to the same category (Category:American painters, 20th century birth stubs):
Which relate to similar categories and IMO this level of granularity is completely uneeded and just overcomplicates and overburdeons the process unnecessarily.
This is just one example, for one niche group of articles but the end result IMO is self evident. It takes a lot of time to sort these things and properly categorize them.
With all that said, I do think we need to keep some process of tagging articles as stubs. I think its important for several reasons to identify these articles outside the assessment on the talk pages as stubs because as I said above most folks wouldn't look at the talk page and if they did the project could characterize a "stub" as something different than the "stubbing" system with templates on the Main article page. Also, categorizing articles as stubs helps us as editors to identify which ones are 1) In need of the most work, 2) which ones aren't and 3) and probably the most important, allows us a lower level of granularity than the assessments onthe talk pages. By grouping them into like categories (American painters for instance as shown above) it allows editors who are interested in that topic to edit them without having to dive through the categories, which may or may not cover that topic. I hope this helps. I would also add that to me the Stub template name should match as closely as possible to the associated category. Using the Example above if the Category is called American painters, then the stub template should be Template:American-painters-stub and not Template:US-painter-stub but thats just my opinion. Kumioko (talk) 20:51, 12 September 2012 (UTC)[reply]
The one thing I would be wary of claiming (in addition to how some WikiProjects use the stub assessment differently) that one could use the talk page, is that there will be articles without a talk page, ergo, they will not be tagged for a WikiProject. My $0.02. --Izno (talk) 22:18, 12 September 2012 (UTC)[reply]
This is an excellent point worth more than 2¢ that would have to be taken into consideration. Also important would be articles that do not naturally fall under the auspices of any particular existing Wikiproject. Both these situations warrant a solution, perhaps requiring a slight weakening of the proposal. Overall I think it is a minor issue compared to the one being solved though. Jason Quinn (talk) 01:18, 13 September 2012 (UTC)[reply]
Support - it's blindingly obvious that an article is a stub...it's really short, right? So why do we need yet another annoying template to say so. Wikiprojects can look at the length of the article using any number of tools which are guaranteed to deliver a realistic appraisal - rather than some subjective judgement that might just be entirely wrong (either false-positive or false-negative). SteveBaker (talk) 22:41, 12 September 2012 (UTC)[reply]
I agree it is unlikely that a stub tag would prompt editing from someone who wouldn't otherwise, but to be honest I feel the same about virtually every cleanup/wikify tag, and most of those are a lot more visible. To me, the point of stub sorting is the categories: An editor who fixes/expands/references/etc a particular 19th century American painter article because that is their area of interest/expertise can find 120 more articles on the same topic for expansion using the stub category, whereas a category like Category:Articles lacking sources from April 2008 has 2000+ effectively unrelated articles on hundreds (if not thousands) of topics. I can't of course offer any studies to say this happens besides relating that I have used it that way before (looking for newer articles likely to be missing certain infoboxes, navboxes, etc, without having to search the entire much larger category). So I think the stub category structure is of far more value than the visible stub tags. --Qetuth (talk) 03:05, 13 September 2012 (UTC)[reply]
Just to clarify why I think the stub cats are valuable: The Wikiproject categories should be good for this, but in practice, in the vast majority of cases, they are not. Maybe one day this will have changed. Is sorting American 19th century painter stubs by decade too much? Probably, yes, which is why that category recently got merged. But most of those articles (from random sampling) have a Wikiproject category of Category:Stub-Class biography articles (620,000 articles), except a few who have been sorted into Category:Stub-Class biography (arts and entertainment) articles (a mere 50,000 articles). Some few have interest from a second WikiProject, but these are completely inconsistent (some have a US state, some another country, some wp: Visual Arts, etc, or something completely different). For 'allowing editors interested in a topic to find short articles to edit', this is completely useless --Qetuth (talk) 03:22, 13 September 2012 (UTC)[reply]
Comment I'm pretty sure that we don't have a wikiproject to cover the scope of every article, and if we don't have a project to cover an article, what then? Or if the wikiproject that covers the article doesn't support assessment? or if they have been classified as inactive, and therefore the banner doesn't support assessment anymore? -- 76.65.131.248 (talk) 05:57, 13 September 2012 (UTC)[reply]
A new "Wikiproject Misc." could be created to cover articles that fit into no Wikiproject. If a Wikiproject doesn't support assessment, that's their prerogative. I was unaware that inactive projects no longer support assessment. I don't know. Would have to think about it. Jason Quinn (talk) 15:24, 13 September 2012 (UTC)[reply]
I think it unlikely that many pages will fall under at least one WikiProject. I will, however be even more iconoclastic and suggest that the whole values of many WikiProjects, much of the work around WP 1.0 and the several million banners are pretty much up for dispute. Also creating talk pages with just banners has the deletoray effect of making it impossible to tell if there is discussion on a page without actually opening the tab. RichFarmbrough, 21:12, 13 September 2012 (UTC).[reply]
I think this was a stronger argument back in 2006 or so; as it is, in many cases the discussion that would turn the tab blue is a few passing comments from several years ago. The semantic value of a blue talkpage link (even without templates) is reduced the longer the page has been there. Andrew Gray (talk) 09:11, 14 September 2012 (UTC)[reply]
If you create a WPP-Misc, that could solve the two other problems, by adding a Misc-banner (so WPPs without banners, or whose banners don't do |class=, or whose banners has been inactivated by the inactivity setting, will be covered) ; If every page uses WPP-Misc for general quality assessment (stub/start/FA/etc), and page-type assessment (type=article/list/dab/etc), then regular WPPs could be reduced to just assessing importance (or not assessing if its their wont) -- 76.65.131.248 (talk) 23:06, 13 September 2012 (UTC)[reply]
I think there is a good case to be made for amalgamating all the quality assessment system into a single template, and hanging project/importance tags off that, rather than the other way around. But that's another discussion, I think ;-). In an idea world, we'd be able to move all this metadata to be separate from the discussion, helping alleviate things like Rich's concern above.
Regarding inactive, my understanding is not that the banners don't support assessment because they're inactive, but rather that because the projects are inactive they were never "upgraded" when article ratings became standard practice some years ago. Originally, these banners were very little more than "ownership tags"; rating appeared later. Andrew Gray (talk) 09:11, 14 September 2012 (UTC)[reply]
{{WPBannerMeta/inactive}} doesn't do assessment. When someone from WP:COUNCIL I suppose, determines that a WPP's activity level shows no activity, it is tagged as inactive, and the banner is converted into a non-assessment form. The existing assessments are still on switches at the talk pages, but they don't get categorized or do anything anymore. (like any other template parameter that is used but not coded for) It doesn't have to do with upgrading, it concerns the amount of activity seen at the WPP. If the WPP doesn't use WPBANNERMETA, it can't have an inactive banner. There are still WPPs that don't do assessment, and WPBANNERMETA also supports not assessing (it's optional) so even then, lacking assessment is not a sign of not using current banner technology. -- 76.65.131.248 (talk) 19:41, 14 September 2012 (UTC)[reply]
The French Wikipedia uses a single project banner template that does quality assessment, and subbanners for assessing each project's importance assessment. -- 76.65.131.248 (talk) 19:45, 14 September 2012 (UTC)[reply]
There are two separate issues here: (a) is it useful for articles to be labelled as "stub"; (b) is it useful for them to be "stub-sorted", ie labelled as "this-subject-stub" and put into category "This subject stubs" (or sometimes a parent category, where the template is an "upmerged" one like the US artists above). I have spent many, many, hours stub-sorting over several years. As far as I know, this whole structure was created in the belief that there are editors out there who look for articles in category "This subject stubs", in order to work on them and improve them. I do not know whether this is (still?) the case, and would welcome any evidence one way or the other. Activity at Wikipedia:WikiProject Stub sorting seems pretty low right now, and sadly one of its leading lights has left Wikipedia "owing to the over-officiousness of several users who have made this site no longer the enjoyable place it used to be". But I urge that any decision to abandon this whole structure (stop stub tags, or stop sorting them) should only be done after wide discussion. PamD07:09, 13 September 2012 (UTC)[reply]
There are at least two issues occurring, maybe even three if you include my "new editor recruitment" idea. Weaker proposals that target only individual issues might be a better approach. For instance, if it is true that stubs are unwanted clutter for the article but stub categories are beneficial, then stub templates could just be converted to hidden stub category inclusions. Jason Quinn (talk) 15:36, 13 September 2012 (UTC)[reply]
Oppose Quite often one finds either an error or ommision in a particular stub. The assumption that a similar error/ommmision is in similar stubsize articles is usually not wrong. So after finding an improvement the stub-category is the first place to go to in order to duplicate that specific improvement. Project assessment categories are far too wide to accomplish this and serve a more shotgun approach purpose. Even at the reduced stubsorting activity due to the people that make life on the wiki unbearable the work that has already been done and is still happening make it worthwhile to keep the templates. If stubsorting is totally abandoned for more than a year we can look at this again as the incomplete categories will start to loose their purpose. Removing them now would be premature. 09:15, 13 September 2012 (UTC)
Comment: 'Oppose' because it would put Pam out of a job she has been doing meticulously and with great devotion for years. On a more serious note, before deciding this on a simple straw poll, some metrics are required, such as for example, how many different stubs are there? (I would guess a couple of 1,000); How many are there of each kind in use? How much time does it take for a user to find and apply the right one? (I only have a few dozen in my head, and for the others I just leave a generic 'stub' tag (sorry for all the work I cause you Pam); How many stubs get expanded to when the stub tag is removed? How many articles get developed due to having a stub tag? (probably impossible to say). How many projects actually go through their stub articles and try to improve them? (probably impossible to say). Kudpung กุดผึ้ง (talk) 10:50, 13 September 2012 (UTC)[reply]
Comment The idea of similar errors replicated across a category because of the same editor populating those categories is noted as a good point. It does however rely on people actually fixing stub cats for it to be important which is questionable. Yet it remains a valid issue. Jason Quinn (talk) 15:41, 13 September 2012 (UTC)[reply]
Comment - I have I think propose din the past, and I do so again, the idea that stub templates could, without loosing much functionality, be invisible, leaving just the category as the useful semantic structure. RichFarmbrough, 21:14, 13 September 2012 (UTC).[reply]
Oppose I think the stub system works fine; I often use it to find articles worth editing, expanding, or cleaning up. Yes, sometimes the template doesn't get removed when it should be, but other than that I don't find merit in the other rationales for such a sweeping change. --Jayron3205:23, 14 September 2012 (UTC)[reply]
Get rid of the "Show redirects only" external tool in WhatLinksHere in favor of the native interface
If you go to what links here for a page (example) a link is provided to an external tool to "show redirects only", in the form "External tools: Show redirects only" Because I do tons of page moves and need to easily locate redirects for cleanup, I can tell you that the fastest way to do so is not by clicking on that external tool but simply by clicking on hide links, and hide transclusions available on the very same page. Doing so provides the redirects alone immediately and using our native interface.
The external tool lags sometimes, is nonfunctional when the toolserver is down, takes us away from Wikipedia for no purpose I can fathom given the native capacity available from the same page, and does nothing to help people understand our interface. I propose replacing that line with:
To show only redirects, hide transclusions and links above.
Or we could even keep the link in the same form, but make "Show redirects only" pipe to the url for the very page the person is on with &hidetrans=1&hidelinks=1 added to the URL, e.g., Show redirects only. Any change would be made at MediaWiki:Linkshere; I have advertised this discussion at its talk page.--Fuhghettaboutit (talk) 11:30, 13 September 2012 (UTC)[reply]
Yes, no decent reason has been given as to why we should remove the link to this tool, other than that it is redundant (which, as PrimeHunter explained, it is not). It is useful and should stay. — This, that, and the other (talk)02:29, 15 September 2012 (UTC)[reply]
Previewing an edit using Javascript instead of the servers
I do a lot of editing around Wikipedia, and it's important for me to confirm that my edits are proper. By default, when I hit the Preview button, the servers handle the rendering and send it back to me. I have recently discovered the preferences setting that lets Javascript handle it instead of the servers. I know we're not supposed to worry too much about performance, but seriously, if this was enabled by default (obviously one could disable it after) I'm sure it could cut down on server load. Javascript works just as well and it's faster, so why put extra strain on donation-run servers? Thus I propose that the setting be enabled by default. • Jesse V.(talk)15:37, 15 September 2012 (UTC)[reply]
What about user:js/ajaxPreview (~185 uses) ? (see also WP:Gadget/proposals archive for when that was added as a gadget, 2.5 yrs ago. I'm not sure when it was removed?)
I've used that one (and previously Anomie's) for years, and love it. I'd support making it a default-On gadget for logged-in users, or even a site-wide-default.
Tangent: Are all the best features of the other 'quickpreview' scripts, merged into either of those? Because there's also
Toshio Yamaguchi My talk My preferences My watchlist My contributions My sandbox Log out
David1217 What I've done 02:31, 9 September 2012 (UTC)
Regards, RJH (talk) 16:41, 25 August 2012 (UTC)
Question: How exactly are we going to implement this? Michaelzeng7 (talk) 23:32, 2 September 2012 (UTC)
), instead of the default blue one. This would also be the case for History pages on your watchlist, where the bullet will replace the "updated since my last visit" message. Now surely... no-on can object to that...
