This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
spun off from "Unblockself permission" thread above as it's not really an alternative solution to that issue. Rd232talk13:07, 17 July 2011 (UTC)
A common non-admin experienced user knows what's worth revoking talk page access over, and maybe perhaps even what's supposed to be worth an unblock. Therefore, as an alternate proposal, I propose a Block Reviewers user group that can modify blocks and unblock, but not have any other admin-related things. Thoughts?Jasper Deng(talk)04:10, 16 July 2011 (UTC)
Completely agree! I do not like the current method of admins playing judge and jury and appellate court all in one. There is, unfortunately, one admin who seems quite aggressive on reviewing unblocks and upholding the block in probably 90% of all cases (way too high regardless of what admins may think, they are far from being that accurate in their blocks). I came across one egregious block review denied by him, brought it to AN/I and within a few hours had it lifted, and during that time I decided to check the user contributions to find more and found out of the last 10 block reviews all ten had been denied by that admin and at least three IMO should have merited lifting or at least further Community discussion. Given how active this admin is in seeking out block reviews in order to be the reviewer (and sorry, no AGF here) simply to purposefully deny and uphold the block; for this one reason I would like to see non-admins decide whether admin actions such as blocks should be upheld or not, they want to feel high and mighty like they are the "police" then we'll be the civilian police board to monitor their actions and hold them accountable. No cabal's self-monitoring their own actions.Camelbinky (talk) 04:49, 16 July 2011 (UTC)
"One of the more serious things an admin can do"? Really? Well, that might be true in a social media site... oh wait we're an encyclopedia. I thought the most serious thing any editor could do is to actually edit and add information to articles. I would say denying blocking requests is the least helpful thing someone can do when our goal is to "finish" this encyclopedia. Perhaps if more time was spent on research and creating articles and expanding stubs and adding references to articles with refneeded tags etc then the goal of the most comprehensive encyclopedia of knowledge in the world might be attainable. But nooooo, there are admins who would rather not do any editing at all and instead worry about enforcing civility and policies they see as "rules and laws". We'd be farther along without them.Camelbinky (talk) 04:31, 17 July 2011 (UTC)
Camelbiky, I'm just going to copypasta a comment in here that I made elsewhere, coz I'm a lazy get .... "Like every large community, Wikipedia needs a whole range of people with a whole range of interests and skills in order to function. Consider the medical profession - yes, we have family doctors / GP's, and very, very valuable they are, too. And, in the old, old days, we had 'wise men' and 'wise women' and such, who did most of the medical care for their community, and did it well. But today, for many reasons, we need people whose speciality is in orthopaedics, or cardiac, or ENT, or neurosurgery, or cancer, or - you name it! The community cannot - no community can - function well, let alone brilliantly, without specialists, and who are we to start judging when one specialist is 'more important' than another? It's a team effort. Everyone who contributes, in any way whatsoever, is a valuable member of that community. Let's make sure that we value everyone's contribution to the community, even if we don't personally have that particular area of interest and expertise ourselves. We need all sorts, really we do. Possible a better example: yes, we need people to build wonderful new roads - but if we're building wonderful new roads, we also need people who are happy to make sure the signposts are easy to read, people to create new maps, people to make sure that potholes are filled in, people who pick up the litter so road-users don't break their necks in it, people who make sure that bandits aren't lurking in ambush along the sides of our wonderful new roads, people who clear the road quickly when there's a crash ... we're all important." Pesky (talk …stalk!) 04:58, 17 July 2011 (UTC)
There are ways and means to address such issues with individual users. I'm sure you're aware of them. Rd232talk23:18, 16 July 2011 (UTC)
Oppose per Eraserhead. If someone disagrees with the result of a block review they can request another one or, if they're not the blocked editor, they can discuss the issue with the admin and, if unsatisfied with the answer, raise the issue on AN or ANI. There really is no need for this new userright. SalvioLet's talk about it!15:39, 17 July 2011 (UTC)
Oppose per Timotheus Canens. When there is a backlog of blocked users so long that no one can deal with all the unblock requests, perhaps it would be time. Then again, if we ever get to that point, we may be past the Wikipocalypse... --Jayron3201:02, 18 July 2011 (UTC)
Oppose - Being able to revoke talkpage and email access removes all avenues of on-wiki appeal and thus should be restricted only to admins. Anyway, vandalism-only accounts who abuse talkpage access normally lose that within a couple minutes, so there isn't even a need for this. Reaper Eternal (talk) 16:44, 19 July 2011 (UTC)
Oppose the above proposals aren't going anywhere and there's no need for this either. While I agree with the principle of unbundling admin privileges, blocking (or modifying blocks) is not one of the things that should be delegated to just anyone. Swarm17:59, 24 July 2011 (UTC)
What do others feel about the ratings poll that is being put on articles? I must admit I must have missed the discussion where this was decided upon by the Community, I assume it would have been here at the proposals page. I would have disagreed with it then, and I disagree with it now. We have Wikiprojects that classify pages already for us to know if things need improvement. I find the poll to be distracting, unprofessional looking, and actually end up making articles look worse aesthetically and look less reliable. I first came across these polls on an article I made and it showed up within 24 hours, it bothered me so much I just havent been able to continue working on the article because it just makes the article look terrible, so the article is stuck at a stub for now. I'd like to see the reasoning and perhaps I can understand and support it more if there are hard facts that it is somehow being useful to readers. I personally don't see how it is useful for the readers, and I don't see how it is being helpful in our goal to create a comprehensive complete encyclopedia without the negative effects of being a distraction and just plain ugly, especially on shorter articles.Camelbinky (talk) 16:38, 20 July 2011 (UTC)
I don't remember seeing this before it started appearing, although recent rollouts have shown, disgustingly enough, that the WMF is more than willing to roll out features without giving the community the opportunity to give meaningful input, they just tell us when they've made a decision and tell us to live with it. I made a comment in one of the other threads, the Signpost I think, that this is so easily gamed. I like the idea but I worry about the implementation. Sven ManguardWha?16:47, 20 July 2011 (UTC)
In my opinion it is more than unfortunate that the main discussion about this feature seems to be on Media Wiki (link http://www.mediawiki.org/wiki/Talk:Article_feedback), while no discussion seems to have taken place here on EN Wikipedia. If someone can show me the discussion where consensus was reached to enable this feature on the english Wikipedia, please let me know, since I must have missed that too. Toshio Yamaguchi (talk) 17:03, 20 July 2011 (UTC)
I left them a nice message regarding where they can shove their decision to roll this out on us without our consent. For the first time ever I guess I can now understand what those in Boston felt like.Camelbinky (talk) 17:19, 20 July 2011 (UTC)
I happen to like it. I think it reflects well on Wikipedia. I think it invites even those who are not editors to provide feedback. There are measures in place that make the feedback relevant. For instance feedback that is eclipsed by a sufficient number of edits to the article is disposed discarded. And if more than one package of feedback is provided by a given reader, I think it is only the last that is kept for consideration. I think there are a lot of intelligent measures in place. You've got to read about it. And I would say it would have been a nightmare to hammer out a process with the usual amount of input and dissenting opinions. This makes interesting reading. Bus stop (talk) 17:27, 20 July 2011 (UTC)
There is no need for it to be that large. Takes up way too much room. You could even just have a rate this article link at the bottom for people to click who want to rate it. DreamFocus17:46, 20 July 2011 (UTC)
Except that my guess is that it's aimed at non-editors, i.e. our casual audience. I agree it's rather large, but... well... it's supposed to be noticed. Sven ManguardWha?18:01, 20 July 2011 (UTC)
Voted for changing the layout. I was thrilled the voting system there was a simple check box. Discussion is great, but man, it can sure do a number on your wrists after a while. Others should consider voting as well. I, Jethrobotdrop me a line (note: not a bot!) 05:23, 21 July 2011 (UTC)
Oh my god, give it a rest already folks. This isn't a community driven item. The Foundation is doing this, on their servers, for their own purposes. If you have a problem with that then vote with something that really matters: your feet and your pocketbook (through donations). Otherwise shut the hell up and let them do their job. If you really think that "the community" can decide how the Foundation can or cannot do their job... well, after I laugh in your face I'll simply ignore everything you say as being inconsequential, because you obviously have little to no grasp of reality. — V = IR(Talk • Contribs)18:46, 20 July 2011 (UTC)
Maybe we need to start collecting the links to the many discussions, so that when the next person comes 'round to complain that "the community didn't get to talk about it", that we can point them at the long list of discussions and ask them where they've been for the last eight or ten months. Also, there's a phenomenon in which power users fuss about any change that was made to "their" website without their personal approval. The notion is that such "unauthorized" changes remind them that, although they feel like they're at the top of the heap under normal circumstances, they are less powerful than the website owner. This dose of reality does narcissistic damage. Perhaps we need to find the name and some sources for this, and write an essay. WhatamIdoing (talk) 19:30, 20 July 2011 (UTC)
Or maybe the WMF should do a better job of at least advertising these things to the community their website depends on; whether they're using input from them or not, there's no excuse for poor communication so that things like this seem "out of the blue" to the average editor. Rd232talk19:37, 20 July 2011 (UTC)
Maybe, but yelling at them and trying to criticize them (through a multitude of venues) for doing their job strikes me as just silly. They can do whatever they want with their servers, after all (granted that they're a public not-for-profit, but still). — V = IR(Talk • Contribs)20:05, 20 July 2011 (UTC)
Maybe... but only if you can pretend that there aren't a dozen prior discussions just in the Village Pumps, and that every change and expansion hasn't been in advance, via the Signpost, the Village Pumps, and even once at ANI. I don't think we can really fault the devs for "poor communication" here: the only things they didn't do were spam every user individually and abuse CENT to advertise a routine announcement. Maybe what we need is a software feature that whacks a few editors upside the head and yells, "Remember this! This announcement was in front of your eyeballs! Don't be so daft as to pretend later that this announcement didn't happen just because you didn't think it worth paying attention to today!" WhatamIdoing (talk) 20:58, 20 July 2011 (UTC)
It should probably have been a sitenotice or watchlist notice. Also, one of the problems with these type of development issues is discussion being scattered around in different places on en.wp, and some on bugzilla, and some on meta etc. If there were some way of centralising this discussion in a way that allowed it to be seen on en.wp watchlists it would help. Perhaps a bot could mirror comments from meta to an en.wp page? Rd232talk21:58, 20 July 2011 (UTC)
Comment: one of the remarks on the MediaWiki feedback page [1] made me think of this idea currently at VPI: Wikipedia:VPI#Sticky_Notes:_contributing_-_for_beginners. Instead of just getting ratings, make it easy for readers to leave substantive comments without having to use wikitext (i.e. probably with the aid of some JavaScript, though possibly even a template like {{Leave feedback}} would be something in that direction, since a blank section for a comment is less scary than clicking Edit on a talkpage with lots of wikiproject templates and the like). How to do that is a question, particularly integrating with the talk page somehow, but basically, this would be a step in the right direction for accessibility for the non-geeky multitude. Mere ratings, on the other hand, are of rather less value than comments. Rd232talk19:37, 20 July 2011 (UTC)
I think that's a decent idea worth exploring, but... the current political climate pretty much makes any suggestion a non-starter (which is why I'm slightly aggravated about all of this). — V = IR(Talk • Contribs)20:05, 20 July 2011 (UTC)
A loosely related tool was mentioned on this thread of the talk page of the tool: As said here there is a script on Polish Wikipedia (pl:MediaWiki:Wikibugs.js) which is also in use on Spanish and Portuguese Wikipedias, and was already proposed on English Wikipedia. See:
WMF doesn't invest enough money into developing features - WMF develops features without consulting community
WMF doesn't consult community enough - WMF is being annoying with adding a banner every two weeks
WMF decided to do this thing without my consent - WMF isn't being proactive enough
We discuss at too many places, we should centralize everything - Discussion is too complex and has too many topics, I can't keep up/not all of this stuff interests me.
Not everybody can be part of everything that happens, yet not be bothered with all the stuff that goes on, AT THE SAME TIME. It's not possible, too much stuff happens. Involve yourself in the things that happen, if you choose to ignore something for a while, then involve yourself when you learn of it, or just ignore what happens, but stop whining already. —TheDJ (talk • contribs) 22:22, 20 July 2011 (UTC)
Not sure if this is on-topic, but have no opinion as far as the feedback tool itself is concerned, but its placement seems too random. Last night, I was a little surprised to see it at the bottom of NMU (disambiguation), which is not serving any purpose whatsoever (I mean, what makes a dab page "trustworthy", "objective", "complete", and "well-written"?) –MuZemike22:31, 20 July 2011 (UTC)
Yes, it was mentioned many times, but the reason the discussions did not get the prominence they deserved is that most of us naïvely felt that would be a full scale community-wide discussion before implementation . The WMF has the power to put anything they like on the servers, but they normally do not use it without the express or at least implied consent of the community involved, and I do not think they have it for this one. The various projects implement different things (deWP uses patrolled articles; enWP after a trial finally decided not to.) For all I know, the members of the BOD or the staff may wish very much that we use it, but they know it would drastically change the community to exercise that power. The foundation could technically force us to use it, but they do not do so. We accept fair use content in limited circumstances, many other projects do not . The foundation has the technical power to remove all of it, but they do not do so. In practice, we have always decided what features we do or not want to have on our pages.
As for my opinion about whether we should have it, I am uncertain &would like to hear the arguments at a full discussion. At present it is disabled on my preferences, though I did use it for all the public policy articles during the trial there in order to help the experiment. DGG ( talk ) 22:34, 20 July 2011 (UTC)
While dab pages contain potentially inaccurate or harmful information, vandalism or spam that could be surfaced through AFT, it may indeed be sensible to exclude them. You can put dab templates in Category:Article Feedback Blacklist to do so.
Further to some of the comments above, rater comments or extended reviews are indeed a highly requested feature. We have a few free-text comment fields in the survey call-to-action that comes up at, I believe, 1/3 likelihood right now, and evaluating those comments it's pretty clear that the signal/noise ratio of just posting to the talk page would be too low. So we'll likely need a highly efficient meta-review tool for that, making it possible to promote useful reviews/notes to the talk page. You can see some ideas in that direction on mw:Article feedback/Extended review, and this will likely be a future priority direction for development. We've just posted an RFP, since we're not going to do that development work in-house. You can see it at foundation:RFP/Article Feedback Feature. --Eloquence*22:38, 20 July 2011 (UTC)
What bothers me about the tool is the screen realestate that it occupies. I still don't understand why it cannot be made 'collapsible-default uncollapsed' like the interlanguage links on articles. Where is the hurt in that ? And wouldn't that satisfy the majority of the registered users ? Registerd users would then see a 'small bar' at the bottom, a bit like: —TheDJ (talk • contribs) 23:01, 20 July 2011 (UTC)
The more collapsed it is, whether that's as a smaller graphic or as a subtle link, the less it will get used. It's the iron law of the web: Every single click in the path costs participants. WhatamIdoing (talk) 01:01, 21 July 2011 (UTC)
Yeah. I agree it's a bit bulky, but think of it as a deliberately large canvas for experimentation -- we're trying to understand what forms of interaction make sense, what kinds of post-rating engagement are effective, etc. It's already fairly out-of-the-way on long articles, but it definitely does stick out on short ones. The feature will evolve as we learn more about the data. If I went with my gut, I'd get rid of two or three of the rating categories and the checkbox, and focus on getting a really solid comment/meta-moderation process in place. But it's too early to make that call. With all that said -- without collapsing by default, it wouldn't hurt to have a convenient, sticky show/hide (collapse) code in the UI similar to what we have in so many other places. If you (or anyone) would like to take a crack at that, please do.--Eloquence*01:17, 21 July 2011 (UTC)
By not having it collapsible you are turning 'very active' editors into 'eternal enemies' of the AFT project, who click "Exclude me from feature experiments" in their preferences instead. Sticky collapsible, with a default uncollapsed state seems like a much safer plan. —TheDJ (talk • contribs) 06:49, 21 July 2011 (UTC)
We considered making the tool collapsible/hideable by having something like a "Hide this" link from within the tool. That control, however, would require us to save the preference as a cookie -- there isn't a way to change a user preference from an external object such as the ratings widget. If the preference is saved as a cookie, it won't persist if another browser/computer is used, or if cookies are deleted. This seemed like it would be a pretty annoying experience, though I do agree that asking a user to go into preferences isn't ideal either. Howief (talk) 18:32, 21 July 2011 (UTC)
The aesthetics of the panel were a bit flawed and I'm not sure what the questions will find out, but one thing I do know is that the best way to find answers is to ask questions. And any old question is fine provided you eventually learn from it what you should have asked. I'm for them experiment to find out more from the users and perhaps get some of them involved. And thee scale was as an experiment and is nothing for people to get their knickers in a twist about. Dmcq (talk) 07:21, 21 July 2011 (UTC)
If this is just an experiment, then I am yet to hear of a deadline for when the tool will be removed from the articles. --Bensin (talk) 10:41, 21 July 2011 (UTC)
I'll repost part of one of my comments from Wikipedia:Village_pump_(policy)#Disable_Article_Feedback_Tool_and_Discuss:
"As I understand the Article Feedback Tool is supposed to serve two purposes: (1) To assess the quality of the articles and (2) to encourage readers to become editors. Both of these purposes are, in my opinion, better served by other solutions: (1) Better internal evaluations of articles and (2) to better welcome, encourage and help new users." --Bensin (talk) 10:41, 21 July 2011 (UTC)
Yep I don't have to waste time asking users as I know my ideas are wonderful ;-) Seriously we really have tried on the self assessment and the welcoming business and they aren't going to suddenly get a lot better. Dmcq (talk) 12:04, 21 July 2011 (UTC)
Comment - I'd like to echo the sentiment above that the biggest problem with the ratings tables are the huge chunk of real estate that they occupy. They take two full inches of vertical space on my laptop, presumably more on a 72 ppi desktop monitor... That needs to be tightened to less than half the height. the "I am an expert" button adds no useful information and should go away. As for the utility of those ratings themselves, the jury is still out on that... Carrite (talk) 15:37, 31 July 2011 (UTC) Last edit:Carrite (talk) 16:01, 31 July 2011 (UTC)
I'm surprised there's no "collapse by default" option for people's user preferences. Your choices are only to disable it or to put up with the big thing designed to get the attention of casual readers/editors. Rd232talk17:29, 31 July 2011 (UTC)
Are you suggesting something similar in purpose to a draft subpage? I think a problem is that the overwhelming majority of articles are so lightly edited that stuff would just sit there forever. Another problem is it's one more thing that has to be monitored for libel, etc. --B (talk) 00:44, 28 July 2011 (UTC)
Excuse me? I will have you know that B and I are completely separate accounts. I have nominated only about four or five articles for deletion - hardly "rampant". And thus far you haven't elaborated at all on what you propose. All I ask is a slightly better structured explanation. Interchangeable|talk to me|what I've changed02:53, 28 July 2011 (UTC)
After reading your comment about drafts I remembered of mw:Extension:Drafts which was in this survey during the usability initiative some time ago. I think it would work better than sandboxes for users experimenting things. Helder02:44, 28 July 2011 (UTC)
It might be better to develop some examples of what this namespace might do using article talk subpages like (which would be an interim solution at least). At this point, it's all a bit vague. "Show, don't tell", as the saying goes. Rd232talk08:22, 28 July 2011 (UTC)
I agree that an example would be helpful. Most of what's suggested above (e.g., creating a directory connected to Crowned Eagle of which zoos contain a Crowned Eagle) seems to run afoul of WP:NOT. WhatamIdoing (talk) 15:29, 28 July 2011 (UTC)
Why can't the notice about the QR code pointing at the article be done on the talk page? That's where we've always put everything similar, like lists of media articles that cite or link to the page. WhatamIdoing (talk) 23:30, 30 July 2011 (UTC)
The Magnum_Photos photographic collection includes over a half-million professional photo images, browseable on line. I have no idea what our history of access has been (beyond the fact we are apparently getting away with claiming fair use of "Afghan Girl"). Per a NYT blog and their own site they are soliciting volunteers to tag their collection. Would it benefit the goals of the WMF if WP had an agreement with Magnum for some form of enhanced access in return for useful contributions by registered editors to the tagging they need? Could someone knowledgeable about fair use, permissions, and Magnum's past practices brainstorm on what sort of arrangement might be mutually beneficial? One thot that occurs to me is that as little as a streamlined process for claiming "by permission" rather than "fair use" in consideration of improvements over what they have previously published as tagging/caption-text/etc. might be worthwhile. --Jerzy•t06:11, 28 July 2011 (UTC)
While this may be a valid proposal, I think the mentality on Wikipedia isn't that we "get away" with claiming fair use--fair use on Wikipedia usually errs on the side of caution and necessity, and in the case of Afghan Girl the image was well within the limits. As for the proposal itself, I'm doubtful it would work. As I understand it (and please correct me if I'm wrong), Wikipedia's position is that only free content should go in the encyclopedia, except in cases where non-free content is essential and irreplaceable. Tapping into a large library of non-free photographs under a special agreement is hardly in line with that philosophy. wctaiwan (talk) 06:50, 28 July 2011 (UTC)
If one could convince them to release their collection under a cc 3.0 license than we could have further discussion regarding helping them tag. Otherwise they are on their on. Doc James (talk · contribs · email) 05:13, 1 August 2011 (UTC)
Bot for mirroring discussions from MediaWiki here at the english Wikipedia
Per the comment of Rd232 above I propose to create a bot that mirrors discussions that seriously affect the English Wikipedia somewhere here on the English Wikipedia. I already filed a request at WP:BOTREQ#Bot for mirroring discussions from meta somewhere on en-wikipedia but put that request on hold until we have reached consensus here for such a bot. Thus I would like to get some input to see, whether there is consensus for this. Please leave votes and comments below. Thanks. Toshio Yamaguchi (talk) 14:47, 21 July 2011 (UTC)
Support - (I am not very active here, but I prefer to check enwiki and plwiki than enwiki, plwiki, meta). And wikilove/rating extensions will later or sooner appear on my home wiki so it would be nice to have illusion of influence Bulwersator (talk) 16:03, 21 July 2011 (UTC)
There has been some conversation about creating a noticeboard for Wikimedia Foundation activities on the local Wikis precisely for this reason--to allow people to watchlist on their local projects to see what developments are pending. Currently, this is on hold pending input from the newly hired Movement Communications Manager, whose job will include helping to "introduce more painless, relevant, and effective ways to increase the exchange of information within the community". (You can see an early mock-up at my userpage.) That said, the system was not envisioned to include replicating discussions, and I don't know if the new MCM will choose to go in that direction anyway. :) Can I ask what pages on MediaWiki you would mirror? Would somebody have to choose which conversations are worth reproducing and tag the page or provide a link to it? How often would the bot copy over the content? It might be helpful to consider some of the specifics in gathering consensus, since people might have different ideas about how such a thing would work. :) --Maggie Dennis (WMF) (talk) 16:30, 21 July 2011 (UTC)
The question what specific pages to mirror might be a bit tricky. In general, I think people here on the english Wikipedia should be able to inform themselves about drastic changes (such as the introduction of the Article Feedback Tool) prior to the introduction of such changes here on EN Wikipedia. Therefore the discussions leading to the consensus regarding the introduction of these tools should be made visible here on Wikipedia, since I think many people will not watch what is going on at Meta, but will voice their opinion here on EN Wikipedia when these changes are introduced. To summarize:
People should be able to inform themselves prior to the introduction of 'drastic' changes to the English Wikipedia on the English Wikipedia and not having to monitor discussions somewhere on MediaWiki. I am not going to say this is an easy to solve problem, but I think it is needed. Toshio Yamaguchi (talk) 16:49, 21 July 2011 (UTC)
"The question what specific pages to mirror might be a bit tricky." - I was kind of thinking there'd be two templates to tag pages with: {{crosswiki master}} and {{crosswiki slave}}, with the latter page protected. (The master template would tell the bot where to mirror to, and the slave template give an explanation that edits only occur on the master page.) Updates would be at least daily (maybe configurable per page in the template). (By the by, this system could possibly also be adapted to mirror templates - smaller language wikis complain about problems keeping templates borrowed from other wikis updated.) Of course, an alternative to all this would be cross-wiki watchlists and/or transclusion... Rd232talk17:36, 21 July 2011 (UTC)
Hi Toshio Yamaguchi, you said: "People should be able to inform themselves prior to the introduction of 'drastic' changes to the English Wikipedia on the English Wikipedia and not having to monitor discussions somewhere on MediaWiki." Well, one question is where such discussions take place, and how the decision is made. But (as Whatamidoing indicated above) there have been frequent opportunities right here on the English Wikipedia to inform oneself about the introducton of the AFT, including the Signpost (already mentioned by Maggie) which was founded precisely for such purposes in 2005. See this incomplete list, ranging from brief mentions to full stories:
September 13, 2010 ("Experiments with article assessment", a lengthy article, likely the first public announcement of the feature outside Mediawiki.org, written by a Foundation staff member specifically for the Signpost, i.e. the English Wikipedia)
October 4 ("Preliminary data on article feedback")
May 9 ("version 3.0 of the Article Feedback tool will go live to 100,000 articles on the English Wikipedia")
May 16 ("the new Article Feedback tool, which was recently expanded to cover 100,000 articles on the English Wikipedia")
May 30 ("The Article Feedback extension for rating articles was listed ... to be expanded to all articles on the English Wikipedia on 31 May. The lack of publicity given to the deployment raised criticism ... Erik Möller explained that the page was in error, and instead announced that the tool would be rolled out incrementally over the next few weeks")
June 6 ("the continued 'development, deployment and roll-out' of the Article feedback tool")
July 18 ("WMF Annual Plan, rollout of Article Feedback" - full story)
Now (speaking as former Signpost editor) I am not saying that the Signpost couldn't have given the topic even more prominence, and (speaking as future WMF Movement Communications Manager) I am not saying either that Foundation staff can rely entirely on volunteers to make sure important information about their (WMF's) work gets out to the project communities. But it seems that your analysis of the situation was overlooking some venues. Still, Maggie and I am very interested to hear about thoughts and specific proposals to improve movement communications.
The point is well made that the Signpost covered this, but not everyone reads it, and anyway that's just announcement. The "mirroring" proposal would be more flexible and try and draw people into a more two-way discussion (as a substitute for crosswiki watchlists). Rd232talk13:58, 27 July 2011 (UTC)
Indeed not everyone reads it, but this will be true for any new on-wiki page that users are invited to watchlist, or actually, to some degreee, for virtually any new communications channel that one can think of. (We want to avoid falling into the trap described in this recent Xkcd - replace "standards" with "communication channels".)
"that's just announcement" - true as well; as said above, "where such discussions take place" is another question (while the comment section for Signpost articles has often seen meaningful debate - including comments by WMF staff members - about such topics including the AFT itself, it isn't intended as the primary venue for them). I didn't want to discourage your proposal - such a bot may (or may not) help to alleviate some communication problems -, but I don't see how it would make sure that all Wikipedians are made aware of upcoming changes. Regards, HaeB (talk) 00:38, 4 August 2011 (UTC)
Slightly different topic from what y'all have been discussing so far, but we really need to get the mailing lists shut down, and those conversations moved to more accessible places (the MediaWiki server, Meta, here, etc...). There's no way that I'm using my regular email address, I shouldn't be required to maintain a separate email address simply to participate in discussions using a lame ancient hack of technology, and there's certainly no way that I'm downloading literally thousands of emails (I realize that the archives eliminate part of this criticism, but still). We have all of these sites, and all of these people using them, so I don't understand why some people want to hide serious discussions away on some backroom platform (the mailing lists). It's exasperating. — V = IR(Talk • Contribs)15:10, 27 July 2011 (UTC)
@HaeB: Yes, we have the signpost. However, I personally don't want to have my talk page "spammed" with bot delivered messages, a great part of which I am not interested in reading anyway. And if I want to take a look at the signpost, I will just take a look at the talkpage of a user which has enabled the feature (since after all, I believe, all users subscribed to the signpost have the same messages delivered to their talk page). I would prefer some kind of announcement board that I can add to my watchlist. But well, maybe that's just me. Toshio Yamaguchi (talk) 08:45, 28 July 2011 (UTC)
Sure... but the Village pumps are some of the English Wikipedia's "annoucement boards", and it was repeatedly announced here, and yet you somehow didn't seem to know about it. I believe that at some level, we're all going to have to admit that it is actually impossible for any individual human to keep up with everything that happens here. Your blindness to the announcements doesn't mean that the announcements and discussions didn't happen, just like my blindness to changes made on the 49 (out of 54) official policies that I don't choose to watch doesn't mean that there were no changes and no discussions about the changes at these policies. WhatamIdoing (talk) 15:19, 28 July 2011 (UTC)
The white light hurts the eye and it becomes extremely annoying when one is reading very large articles. Since that what’s people do in Wikipedia I believe it would be advisable to have the background be a different color or to have an option that allows people to change the color of the background in the articles they are reading to whatever color the want. — Preceding unsigned comment added by 190.0.67.25 (talk • contribs) 00:21, 2 August 2011 (UTC)
Actually black on white is the least straining on our eyesight. Light on dark will be a lot more difficult to read after extended periods of time. - ʄɭoʏɗiaɲτ¢00:42, 2 August 2011 (UTC)
Have you tried turning down the brightness of your monitor? If this site is hurting your eyes, a word processing document should be giving you similar problems. Also, when was the last time you got your vision checked? You could be in need of glasses, or a different prescription strength of glasses for reading on a computer. Ian.thomson (talk) 00:49, 2 August 2011 (UTC)
Firefox, Wikipedia with a grey background - see here
Presumably, the IP would have to create an account to take advantage of it, but how hard would it be to create a skin that's light text on a dark background? There are multiple skins available at the My Preferences page, but they all seem to be dark on light. —C.Fred (talk) 00:51, 2 August 2011 (UTC)
There isn't any reason why the wiki shouldn't be available in other colours if a user wants it that way. I'm sure that it would be easily programmable and since it is an option on a list of options most users don't even know about, it won't disrupt the wiki in any way and it will make a few users who like to personalise the wiki...just a little happier. Shabidoo | Talk01:25, 2 August 2011 (UTC)
You mean this for logged out users as well? This would be a nuisance to public computer users who must change the settings back. MarcusQwertyus02:37, 2 August 2011 (UTC)
There is a "Use a black background with green text on the Monobook skin" option on the gadgets section of logged in users preference page. It is a pain because now it loads white on black before loading green green on black. MarcusQwertyus02:35, 2 August 2011 (UTC)
To 190.0.67.25: please give us an example of a website that you find visually pleasing so we can determine if there is a solution. ---— Gadget850 (Ed)talk16:12, 3 August 2011 (UTC)
If you have Windows Vista or Windows 7 (which I know all of us "free software" folks have</sarcasm>), you can change the theme so that "everything" including Wikipedia pages take on a different look, such as the "black background" look. I do that from time to time when I know I'm in a darker setting, and having a completely white screen would be disruptive to others. –MuZemike19:06, 4 August 2011 (UTC)
I just tweaked my vector.css to give things a more Zenburn appearance. It's nowhere near done, but if you like the results, I'll go through and try to finish it.
body{background-color:#3f3f3f;/* @embed */background-image:url(images/page-base.png);}a:link{color:#f0dfaf}a:visited{color:#e0cf9f}h1,h2,h3,h4,h5,h6{color:#dcdccc;}/* Head */#mw-page-base{height:5em;background-color:#3f3f3f;/* @embed */background-image:url(images/page-fade.png);background-position:bottomleft;background-repeat:repeat-x;}div#content{margin-left:10em;padding:1em;/* @embed */background-image:url(images/border.png);background-position:topleft;background-repeat:repeat-y;background-color:#3f3f3f;color:#dcdccc;direction:ltr;}
You can change your browser settings to change colour. I mostly use standard but occasionally I find the white bland and feel like a change. My usual is either a light grey background or black with white text. I find though that the black does my eyes in more than white. I agree there ought to be more custom aesthetic options in your preferences. I for instance can't stand the standard size and font of wikipedia and use something rather clearer and more elegant looking. I'm using Gabriola font at the moment. ♦ Dr. Blofeld20:00, 4 August 2011 (UTC)
I am a novice who cant seem to make wiki happy. Could someone submit my article on writer Abbie Graham. I will give you the draft I have? It needs editing that I am incapable of doing I guess.
Author Abbie Graham was an active author in the Young Woman's Christian Association (Y.W.C.A.) in the United States during 1920-1940. This was a significant time, with many changes occurring in the rights of Women in the United States. (1)She wrote books about the Woman's right movement and eleven of her works were published from 1923 through 1942 through the Y.W.C.A. press, Womans Press, New York . (7)These books provided guidance and comfort to the young women of that time. (2)Her works covered many subjects, including spirituality, race relations, Girl's Camp activities, womens sufferage and she wrote the biography of Grace Hoadley Dodge, (5)founder of the Y.W.C.A. Several reprints, subsequent editions and copyright renewals were also done. Many of her books are currently available online and are held by various libraries. (4)The Y.W.C.A. records held at Smith College and the University of Washington document her activities.
(4)Abbie Graham books:
Ceremonials of common days 1923
Grace H. Dodge 1926
Vain pomp and glory 1927
High occasions 1930
(6)Outposts of the imagination 1930
The mother and daughter observence 1932
The girl's camp 1933
Ladies in revolt 1934
Time off and on 1939
Working at play in summer camps 1941
On being mortal 1942
A Vespers Service, The American Dream" 1938
(credit: Sophia Smith collection, Smith College)
Sources:
(1)librarything.com
(2) Ladies in revolt, 1934 Author Graham, Abbie Womans Press New York
(3)Grace H. Dodge, 1926 Author Graham, Abbie Womans Press New York
(4)YWCA of the U.S.A. Records, Sophia Smith Collection, Smith College, Northampton, Mass.
(5) Wikipedia, Grace Hoadley Dodge
(6) A collection of essays . ...April 27, 1930 New York Times article
(7) Review; Miss Abbie Graham, writer, ...January 7, 1934 New York Times article
This has been discussed before with a fairly even split in opinions thus would like to bring it up again. I am currently in discussion with ECGPedia regarding our use of their images. They may be willing licensing their content under a creative commons 3.0 license but have some concerns about proper attribution. Currently there is no attribution within the article for images. This is in contrast to ideas to which we reference where the idea is from in the reference section. We give the New England Journal of Medicine and The Lancet a great deal of attribution. The issue with images is that the source is not always readily apparent and when it comes to medicine whether a picture was taken by a physician or a lay person affects the images reliability. Per WP:V either adding credits or a little blue link would improve things.
Also in my position with Wikimedia Canada I am working on collaborations with a number of other organizations. I am hoping to collect data regarding what effect their involvement with us has. If we show that ECGPedia's release of images under a more open license increases visits to their site than this will give us something with which to approach other organizations with whom we wish to partner. This is another reason I feel that we should fairly attribute those who donate images.--Doc James (talk · contribs · email) 03:40, 13 July 2011 (UTC)
Image attribution Proposal 1 (little blue link)
Typical ECG abnormalities in Brugada syndrome: ST elevation in V1-V3, without ischemia.[1]
(The attribution text would display in the usual section below with reliable sources, e.g.:
Support as optional I think this would be an acceptable way to do it when there is a good reason to want extra attribution on an image. Monty84517:03, 13 July 2011 (UTC)
Please see my comment in the other suggestions section - "optional" is not an option because of the language of the Creative Commons licenses. It's an all or nothing thing. --B (talk) 19:54, 13 July 2011 (UTC)
As we are not a collection as defined by "Collection" means a collection of literary or artistic works, such as encyclopedias and anthologies, or performances, phonograms or broadcasts, or other works or subject matter other than works listed in Section 1(f) below, which, by reason of the selection and arrangement of their contents, constitute intellectual creations, in which the Work is included in its entirety in unmodified form along with one or more other contributions, each constituting separate and independent works in themselves, which together are assembled into a collective whole. A work that constitutes a Collection will not be considered an Adaptation (as defined below) for the purposes of this License." This equal application to all would not apply, Doc James (talk · contribs · email) 21:41, 13 July 2011 (UTC)
Support; fits with our typical page layout and is unobtrusive. At the end of the day; this is a reasonable and small change that might make more institutions of this sort open to donating content. It does not undermine our ideals, it does not clutter up pages (well, apart from an extra small blue box...) and ultimately could bring is great benefit. (as a side point; I have gottne permissions for release under the promise I will try to add an in-article credit the author [with the caveat that it might not stick] and make zero apologies to you all for doing so. I got us a few awesome images in return for a reflist credit. :)) --Errant(chat!)21:00, 15 July 2011 (UTC)
There is no need to do this for attribution, as all attribution information is already one click away by simply clicking on the image. However, if the identification of the image itself or the caption text are supported by reliable sources (as may well be the case with File:BrugadaECGPedia.png used as the example here), I see no reason why a real reference couldn't be used. Anomie⚔19:30, 13 July 2011 (UTC)
This is sort of the manner in which I was planning on using it. Some of the images that I have been requesting come from published journal articles. --Doc James (talk · contribs · email) 20:12, 13 July 2011 (UTC)
I think this is just going to be obnoxious more than anything else. And from a readability standpoint, it's confusing, since it's the same reference we use for factual citations. If the image caption has some controversial claim in it, that claim may be cited to a news article. Adding a second footnote to credit the image author is starting to hurt readability. Also, if you have to click on the footnote to see the attribution, you were already one click away from the image description page, so it doesn't really change anything other than clutter up articles (although, I guess it gives you built-in image attribution for printed versions of the article.) --B (talk) 19:45, 13 July 2011 (UTC)
Unjustified distinction between creators of text and creators of media (article writers don't get credit on the article page), unjustified distinction between institutional creators and other creators (institutional media donors get credit on the article page, but User:JoeBlow425 doesn't get credit), hard to implement reliably because we have to keep track of which donors impose extra requirements on attribution. Calliopejen1 (talk) 18:00, 17 July 2011 (UTC)
I agree with the above. Attribution is provided on the image description page. If we act on this proposal, we give institutional image donors (or image creators generally, if this approach is generalized) undue prominence compared to text contributors. But a footnote can be used where it is needed as a reference for the caption. If this ECGpedia is a reliable source according to our definition, which may not be the case, it can be used as the reference. Sandstein 11:33, 6 August 2011 (UTC)
An internal wikilink is what I presume this proposal is suggesting, that would mean that the donar would only get in article attribution if the donar is notable. internal link to our WP article isn't going to really benefit the source. I can see disputes arising from this format specifically where images are available thru multiple locations do we credit Flickr for images sourced from Flickr users. Gnangarra10:21, 13 July 2011 (UTC)
It is like a reference. When you click on it it brings you to the reference section where the credit info ( real name of author is mention ). This would be an optional idea if approved. Not requesting that we use it universally. Doc James (talk · contribs · email) 17:00, 13 July 2011 (UTC)
If you want to go this route, it's worth considering using the "group" feature for references. To do that you'd use: <ref group=Image>Joe Photographer - Joe's Photography business</ref> followed by {{Reflist|group=Image}} somewhere in one of the Footers sections (note that if the group name shows up in the brackets of those references, so you should keep it short. Also, if the group name contains any spaces you'll need to use quotations around it [for example: group="example name"]) — V = IR(Talk • Contribs)20:18, 13 July 2011 (UTC)
Redundant to both the image itself and the little "Enlarge" icon being linked to the same place. Anomie⚔19:26, 13 July 2011 (UTC)
We could replace the little enlarge icon with maybe credit? I had no idea what the little icon did for years. It is not intuitive. The EB gives you the caption and the credits when you put your mouse over the image. Doc James (talk · contribs · email) 19:41, 13 July 2011 (UTC)
This doesn't really accomplish anything if all it does is take you to the same page that clicking on the image takes you to. --B (talk) 19:48, 13 July 2011 (UTC)
Redundant to the image's description page, and gives unfair credit to image contributors vs. text contributors. Text contributors are currently noted only in the article history, not on the page itself. --Cybercobra(talk)20:37, 13 July 2011 (UTC)
Redundant to the image description page. Yes, this makes the credits more accessible to those who don't consider mouse-overing the image, but it does not outweigh the disadvantage of added clutter. Sandstein 11:57, 6 August 2011 (UTC)
While a better approach as notability of the source isn't a presquesite for attribution. I'd be concerned over disruption to articles with image choice as EL do affect the source sites. Gnangarra10:27, 13 July 2011 (UTC)
A hand affected by rheumatoid arthritis James Heilman, M.D./Wikimedia Commons
Support
I much prefer this option with the restrictions that I outlined below - no user names, no company names, no links. We can't have this turn into an opportunity for free advertising. If the photo was uploaded by a pseudonymous Wikipedian, we can just say "See description page for attribution" or some such thing. --B (talk) 19:37, 13 July 2011 (UTC)
Oppose
No need to spam photographers' (or other copyright holders') names across our articles. This information is appropriately kept with other metadata on the image description page. Anomie⚔19:44, 13 July 2011 (UTC)
Redundant to the image's description page, and gives unfair credit to image contributors vs. text contributors. Text contributors are currently noted only in the article history, not on the page itself. --Cybercobra(talk)20:39, 13 July 2011 (UTC)
Strong Oppose I've seen this in actual implementation at the Assassin's Creed Wikia, it looks godawful. Images are already credited if you click on them. Sven ManguardWha?21:45, 13 July 2011 (UTC)
Comment - If there HAVE TO BE photo credits for some legal reason, this is the preferred form, from my perspective. However, if there is no pressing legal reason for these, forward and onward with the status quo. Carrite (talk) 15:41, 31 July 2011 (UTC) Last edit: Carrite (talk) 15:54, 31 July 2011 (UTC)
Support - If it ain't broke, don't fix it. The big problem with the images at WP is twofold: 1. A terrible upload page which does not list all valid American rights templates, like Public Domain-1923 and Public Domain-Pre1978 in the pulldown. A robust set of copyright options for England would also be beneficial. 2. A small cell of ultra deletionists who get their jollies blowing up images, the process being far too unilateral and hinging upon ill-explained regulations. Carrite (talk) 15:49, 31 July 2011 (UTC) Last edit:Carrite (talk) 15:55, 31 July 2011 (UTC)
Nothing else at Wikipedia gets credit. If I take a photograph, why does that get my name prominently displayed on it, but if I write a paragraph of text I don't get to sign my name? Why? Because contribution to Wikipedia is not about generating glory for the writer. It is about spreading knowledge pure and simple. There are outlets to gain personal glory, and it's called "The rest of the world that isn't Wikipedia". If your purpose in taking a photograph is to become a better known photographer, or your purpose in writing text is to become a better known writer, Wikipedia is not for you. Wikipedia's image file pages, like Wikipedia's text history pages, are an adequate means of giving attribution for image sources and be fully compliant with our licence. There is no need to give more prominent credit in the text to the originator of content. Yes, other parts of the world give more credit. We are not other parts of the world. We are Wikipedia. There is no reason to change how we do things just to increase the number of photographs we have access to. If you want more photographs, get a camera. --Jayron3219:49, 13 July 2011 (UTC)
You have referenced the ideas in the text you have written to a reliable source so that the ideas do get attributed in the ref. Images like ideas should get referenced / attributed. The difficulty is how many of us have images of porphyria cutanea tarda lying around. I carry a camera every day and have still not got the opportunity to take a picture of it. I am suggesting this as a way to improve Wikipedia. As a way to convince others to release images they might not otherwise release. Doc James (talk · contribs · email) 19:54, 13 July 2011 (UTC)
It is a completely distinct and different issue. An image is not an idea. I am wholly the creator of the text I am writing, but I am referencing it to sources where the ideas come from. You are conflating two completely independent and distinct parts of Wikipedia articles, and there's no inherent need to make an analogy for what works in one case (inline cites for source texts) and apply it to another (images). They are different things, and require different standards. --Jayron3220:24, 13 July 2011 (UTC)
I tend to agree, however... I can see the point that Doc James is making. I don't think we should dismiss his concerns out of hand (if for no other reason then the fact that many others seem to share his view). — V = IR(Talk • Contribs)20:39, 13 July 2011 (UTC)
I'm okay with a citation when an image comes from a reliable source and we are relying upon or stressing the accuracy/authority thereof. I'm not okay with blanket attribution in all image captions. As Jayron argues, it would create an unfair divide among contributors based on the kind of content contributed. --Cybercobra(talk)20:47, 13 July 2011 (UTC)
And that is what I am proposing. Per my above comment it appears to be allowed. I am not proposing we ref all images just those from reliable sources in which the reliability may be in doubt. Doc James (talk · contribs · email) 21:30, 13 July 2011 (UTC)
It does not seem to me that you are proposing to "ref" any images at all to proper reliable sources. It seems to me that you want to advertise the name of the person who took/owns the photo. "Dr H took this picture" is not a reliable WP:Published source for information about the contents of the photo. "Dr H took this picture" does not tell me whether the photo actually contains what some editor said it contains. It only tells me that he took the picture. WhatamIdoing (talk) 20:58, 15 July 2011 (UTC)
The first example is a reference to the source of the caption that verifies this interpretation of the ECG. The interpretation was made by a cardiologist in the Netherlands for this example. Even though the ref page does not make it that clear. But for images say from the WHO we should have a ref to the WHO supporting the interpretation per WP:V. If the image was from the WHO rather than Wikimedia Commons would that change matters? I agree Wikimedia Commons is not a reliable publisher. Doc James (talk · contribs · email) 16:25, 16 July 2011 (UTC)
Yes, but verifying the interpretation of the ECG doesn't have anything to do with image attribution. It happens that in this instance, you're using the same website to verify the accuracy of caption and to say where the photo came from, but you could use another source to verify the caption.
Question Is the intent to make a policy (enforced), a guideline (best practice), or just approve it as an optional practice? Monty84505:59, 13 July 2011 (UTC)
That's possibly going to be problematic. The various Creative Commons licenses all have this language (or some form of it): "The credit required by this Section 4 (b) may be implemented in any reasonable manner; provided, however, that in the case of a Adaptation or Collection, at a minimum such credit will appear, if a credit for all contributing authors of the Adaptation or Collection appears, then as part of these credits and in a manner at least as prominent as the credits for the other contributing authors." The "so what" of that is that attribution of one photo needs to be "at least as prominent" as the attribution for other photos. So if we start allowing some Creative Commons photos to be attributed, we have to attribute all of them. Of course, this flies in the face of my strong desire to keep user names out of image articles, but I think we can resolve that by saying "Image credit: see File:whatever.jpg" for users who have not provided an English name to attribute. But the bottom line is, if we start doing this, we have to do it everywhere. --B (talk) 17:25, 13 July 2011 (UTC)
I have emailed Wikipedia's legal counsel too see if this is an issue ( if we need to do it for all images if we do it for any images ). Will let you know what he says. I am not suggesting we put user names in the article text itself. I am suggesting on that we have "Image credit" or "[1]" as an option especially for images in which the source effects the reliability. Doc James (talk · contribs · email) 18:33, 13 July 2011 (UTC)
FYI, I have no idea what our current counsel will do/say, but when this question was asked of Mike Godwin, he basically said to leave him out of it. I guess/assume (based purely on my non-legal mind) that the Foundation doesn't want to get involved in these decisions, because if it gets involved, it becomes legally responsible. Right now, they get to claim that they are just a content hosting service no different from Youtube or Blogspot and that if a user violates a license, that's the user's problem, not the Foundation. So they have a vested interest in not giving an opinion here. --B (talk) 20:44, 13 July 2011 (UTC)
That's exactly what is going on, and I would be very surprised if the current legal counsel said anything different than Mr. Goodwin did, for the reasons that you've already outlined. — V = IR(Talk • Contribs)20:47, 13 July 2011 (UTC)
Question threshold before an source is attributed, do we also attribute users in the article for images. Gnangarra10:29, 13 July 2011 (UTC)
I don't mind attribution for images with two IMPORTANT restrictions: (1) No internal or external links, website names, company names, in the attribution - otherwise, we're going to have massive numbers of commercial websites fighting over images just so they can have a free link to their website and (2) Real names only - no "photo by User:PointlesslyColorfulAndSillyUs3rname666". The attribution should be very simple - "Photo by Bob Johnson". --B (talk) 16:32, 13 July 2011 (UTC)
This sites give use attribution [2] and [3]. I am not suggesting we do it this prominently. Just a halfway point. One would still need to click on credits to bring it up. Also we would need a clause stating that we use images uploaded by our users directly preferably if equal quality images exist for the subject matter at hand. Images of rare medical disease are exceeding difficult to come by. We need to bend a bit ( not much but a bit ) if this can help us acquire them for the creative commons.Doc James (talk · contribs · email) 18:40, 13 July 2011 (UTC)
If "we need to bend a bit" means that we need to accept less than completely free images, then that's fine (to me, at least) but it means that commons is not an option. The entire purpose of commons is to be a completely free resource, so if potential contributors have any objection to completely giving up their rights to the image then they shouldn't be posting the files to commons. That doesn't mean that Wikipedia can't use the image(s), though (despite the hysterics of the anti-NFCC crowd). If there are license issues, then the contributors should upload the images directly to Wikipedia itself, not commons. — V = IR(Talk • Contribs)18:57, 13 July 2011 (UTC)
No people are still donating completely free images. It is just that we (Wikipedia in English) the major users of these images are going to give proper attribution (slightly more than the minimum required by law). The people I am in discussion with are completely aware that other may not do the same as us and are free to reuse their images. Doc James (talk · contribs · email) 19:28, 13 July 2011 (UTC)
Please see the Wikimedia Foundation's licensing policy. Projects are not permitted to accept "free content" licenses that are "less free" than the ones acceptable at Commons. Nor can we use under a claim of fair use content that would violate the "replaceable" rule. These are Wikimedia Foundation policies, not ones that the English Wikipedia has the power to change. --B (talk) 19:27, 13 July 2011 (UTC)
Right. I know that yourself and others have this interpretation, but... well, NFCC and all (more correctly: "Exemption Doctrine Policy (EDP)"). — V = IR(Talk • Contribs)19:52, 13 July 2011 (UTC)
James, I very much like the attribution method used on those sites you linked - I would support something exactly like that here. --B (talk) 19:27, 13 July 2011 (UTC)
I don't really have a suggestion, but more of a basic question. Images (and other files) have their own dedicated pages, and it's always been my impression that we preferred all attribution to take place on that page (it's actually required for the most part, due to the NFCC bureaucratic stuff). Why do we want to, or need to, have attribution of images within the articles where the images are used? — V = IR(Talk • Contribs)18:51, 13 July 2011 (UTC)
That's what this discussion is about - asking the question whether or not we want to change what we're currently doing. The main advantage I see in changing it is that it's the norm outside of Wikipedia and it's the expectation that serious photographers have. If you go to CNN.com and click on a random article, you will see any photos in that article captioned with something like "John Smith / Getty Images". Some professional photographers (or even a few of the more serious amateur ones) I have interacted with over the years have been rather ticked off that we don't provide inline citations. For example, see File talk:Cynomys ludovicianus -Paignton Zoo, Devon, England-8a.jpg for one such discussion. Now, I've also seen ones that want an inline citation linking to their website (for obvious self-promotional purposes - a link from Wikipedia is hundreds or thousands of dollars in free advertising) and we need to guard against that at all costs. --B (talk) 19:34, 13 July 2011 (UTC)
I think that I'm generally inclined to remain with the status quo, which essentially means "no inline attribution... but you can add it if you think it's important and others don't actively remove it". The reason being, essentially, due to the concerns over promotion that you brought up. Additionally though, the fact that you can click on our images and get to a dedicated page seems to supplant the need for inline citation (and indeed, allows for much more information to be given than normal). Most websites don't provide that click through capability. I hear you that because it's different, some contributors can be and are put off, but... I think that our position as a top 10 website allows us some leeway to say "this is how we do it, please learn our way". I'm willing to listen though, of course. — V = IR(Talk • Contribs)20:00, 13 July 2011 (UTC)
(edit conflict) I for one don't think we need to. As far as I understand the people who do think so, the motivation is generally along the lines of "Some person/organization might/will freely license a bunch of pictures, if we display their name alongside every use of their pictures in articles." This comes from the fact that few other major sites use our system of linking every image to an attribution page, instead printing the photographer credit in small print next to the image or at the end of the article in imitation of print media. Anomie⚔19:39, 13 July 2011 (UTC)
Per Anomie WRT the collaboration with ECGPedia will be referencing the interpretation of the cardiologist there who uploaded the image. Thus for this specific circumstance the text in the caption will need referencing.Doc James (talk · contribs · email) 20:19, 13 July 2011 (UTC)
If the interpretation is described in the text, it would be referenced like any other text in the body of the article. What we want to avoid is the small art photographers (who produce a useful product, it's true) spamming samples of their images into articles and insisting on highly visible attribution. It is free advertising for them and a headache for us. Rmhermen (talk) 22:09, 15 July 2011 (UTC)
Yes and what we want to promote is organizations like the World Health Organization, Health Canada and the Mayo clinic releasing their thousands of images of rare conditions for use to us. Images that it is unlike we will be able to ever take ourselves. We must not paint all images / sources the same. But with respect to images in medicine the entire interpretation of the patient is required before one can say what the image is. Therefore for the content I am interested in references are need to support the fact that say this image of dengue fever is indeed dengue fever with the ref being the Center for Disease Control who have back up the claim with serology rather than just someone who thinks they have dengue from flicker.(BTW I will not be referencing flicker) Doc James (talk · contribs · email) 16:19, 16 July 2011 (UTC)
With the recent incident with WikiAlpha, I think it's best, if possible, that this feature require CAPTCHA for non-autoconfirmed users.Jasper Deng(talk)04:00, 18 July 2011 (UTC)
Support - I'm surprised we've never had one. Also, WikiAlpha is currently being discussed at AN/I. I've linked to here as a "See Also" at the top of the thread. I wonder if going a step further and requiring capthca for registration might also be a good idea now, if not already present. CycloneGU (talk) 04:56, 18 July 2011 (UTC)
Support although I wouldn't terribly mind if it were required of all users in order to send emails. If you want/have to send email en-masse, and you don't already have enough of an on-wiki relationship with the recipients to already have their emails, then you probably shouldn't be sending those emails in the first place. This will make it harder, or at least more tedious, for both pollsters and vandals (which is what I consider the WikiAlpha people to be) to use the email function on a widespread basis, and I think that's a good thing. Also, since autoconfirmed is a deliberately low standard, it doesn't take much for a spammer to build up an account to get around the Captcha requirement. Sven ManguardWha?07:06, 18 July 2011 (UTC)
No. Last I heard the WMF is opposed to anything which uses servers outside their control for privacy, reliability and possibly other reasons. Personally I think a more important goal as per Graham's comments below is we need some sort of audio captcha for blind users. Of course this could be handled via ReCAPTCHA but any method is fine provided we actually have something. Edit: See the replies here [4], the biggest concern is it's not open source. I should mention on a personal note I've never been that impressed with ReCAPTCHA. It's sort of like some of the distributed computing efforts, at least in the earlier years. Sounds like your contributing something noble but sometimes it seemed like your doing work for semi-commercial efforts for free (or at least it wasn't always clear what would happen to the results and whether anything may be patented partially arising from volunteer efforts). Nil Einne (talk) 10:54, 18 July 2011 (UTC)
Cautious support, but I'm not sure how much good it would do, as WikiAlpha's email bots could just make ten edits and wait four days until they started their email spree. However I oppose requiring a CAPTCHA for all emails, as it would make things more difficult for blind Wikipedia users like myself. I wouldn't be personally affected, as I am an admin, but I've never gotten the audio CAPTCHA to work for instance. Graham8708:03, 18 July 2011 (UTC)
Limited support per Graham not sure how well it will work. Opposed to all e-mails until and unless audio CAPTCHAs or some other solution is found for blind users and anyone else who can't use our current CAPTCHAs Nil Einne (talk) 10:54, 18 July 2011 (UTC)
Would you support a throttle (e.g. 1 in 24 hours) after which you can't send any more without a captcha? That would reduce the risk of bot spam, while allow blind users to send some emails. עוד מישהוOd Mishehu13:01, 18 July 2011 (UTC)
A throttle should be okay although 1 in 24 hours sounds a bit low. Perhaps 6 (semi random example) in 24 hours. I don't think it's unresonable someone may want to send a few in a space of 24 hours (whether on the same thing or different things) and asking them to wait or to email a third party to get them to email the other parties seems bad. And 24 hours or similar is appropriate, I don't think 1 in 4 hours is as good. Someone could still spam but it would seem to be of limited use before they got blocked. Nil Einne (talk) 18:10, 18 July 2011 (UTC)
Comment - the possibility of socking so that captcha is not required is an interesting one. There are parallels with the #Proposed expansion on current protection. In both cases the answer may be some higher bar (more edits and time than is required to get autoconfirmed) and some software that detects attempts to do a mass of "under the radar" edits, such as minor punctuation changes. Yaris678 (talk) 11:21, 18 July 2011 (UTC)
Support under the condition that we allow infrequent emails (maybe 1 per 24 hours?) to be sent without a captcha - this should help with the accessibility issues, while remove the reason for using a bot to send the emails (a bot would make it easy to send hundreds of emails in a single sitting; sending 1 a day is hardly a job for a bot). עוד מישהוOd Mishehu12:03, 18 July 2011 (UTC)
Cautious support. While the WikiAlpha usage of the email system is a problem, it's an isolated incident, as I haven't heard of any other recent users spamming the email system. Still, it feels like a good idea, but only for users who are not auto-confirmed. Pushing a captcha upon established users would be onerous and unnecessary. elektrikSHOOS (talk) 15:20, 18 July 2011 (UTC)
Comment - isn't this overkill, if the problem is really just WikiAlpha? They've engaged with Wikipedia in the past (re licensing), and they may just get the message that they'll be banned if they continue spamming. (And considering that it seems a good-faith attempt to set up a Wikipedia-clone with different standards, it would be bizarre if they're willing to piss off the WP community this much.) At any rate, even with a no-captcha sending quota (say 5 a day), I'm skeptical about doing this without an audiocaptcha which users needing it are happy with. Rd232talk17:47, 19 July 2011 (UTC)
Support - I understand the need to prevent bots from sending out emails (and I've received spam before WikiAlpha bots came along) and if I need to put in a CAPTCHA on the rare occasions when I email someone, no big deal. -- Atama頭23:38, 19 July 2011 (UTC)
Support there is a problem, and some sort of solution is required. Perhaps putting CAPTCHA on emails after email #3 in a 24h period? WormTT· (talk) 11:45, 20 July 2011 (UTC)
Support - I haven't personally experienced any spam from WikiAlpha or other sources, but I approve of adding reasonable captchas to stymie any spam coming my way in the future. I, Jethrobotdrop me a line (note: not a bot!) 05:00, 21 July 2011 (UTC)
Oppose a minor incident does not justify so much disruption to legitimate users. Captcha systems, even the better ones, are slow, annoying and unreliable even for sighted people. For sight-impaired people they can be a nightmare. DuncanHill (talk) 07:40, 21 July 2011 (UTC)
Support.' I'm surprised this is not already the case; right now the feature provides a ready-made automation interface for spammers. Sandstein 12:04, 6 August 2011 (UTC)
As a gnome and new page patroller I get tired of coming across articles on music that are merely "upcoming". Technically a music track or album that is upcoming is one that aint yet even published. Why do we allow upcoming tracks/albums to exist? This whole area is foggy at best. How can a track/album claim notability when it aint yet published? We already decided that BLPs must include at least one ref as of March 2010 - why not now, at the very least, elect to exclude all tracks/albums until they have been published? MarkDask13:55, 5 August 2011 (UTC)
Note, it is not the fact that is, or is not, released that matters; it's whether or not there is significant coverage of it in reliable sources - it comes down to the general notability guideline. It is quite possible for a 'future album' to be notable - if it's some mega-group, then newspapers could provide lots of coverage prior to the actual release.
If we have a specific guide for future-music, then we'd probably have one for future movies, future books, future football matches, future software, and so on. It's not necessary. If we have detailed policies/guidelines for every single case, it becomes unwieldy and unnecessarily complex - see WP:CREEP.
In NPP, if an article like that is totally without merit - no indication of notability - then you can CSD it as A7. If it's just a track-list, or has little content, just redirect it to the artist. Failing that, if it is not notable, you can PROD it or AFD. -So we already have the tools to deal with it. Chzz ► 17:36, 5 August 2011 (UTC)
There are many projects which are notable even when not published; we have several articles dealing with the concept (vaporware, development hell, etc.) There are many types of media which are notable without being released, such as Lifehouse (rock opera), Smile (The Beach Boys album), etc. The word "upcoming" is not, in and of itself, problematic. The only thing you should be looking for when deciding whether or not to delete an article in the context of notability is the existance of reliable sources discussing the topic in depth; other considerations are always unimporatant when related to notability. Something can be upcoming and notable for an article, I would pay the word "upcoming" as perhaps a red-flag that more research is needed before deciding to keep the article or not, but it shouldn't mean anything in the final analysis. --Jayron3217:49, 5 August 2011 (UTC)
Allow the inclusion of references and redlinks in disambiguation pages
Currently WP:DABNOT#References says dab pages should not contain references. However, it might be possible, that a topic is a valid search term connected to a notable topic that simply does not have an article yet. Per WP:RED#When to create red links one of the purposes of redlinks is to link to "topics which should obviously have articles". So I think references and redlinks should be allowed in disambiguation pages to encourage content creation. The reference would serve as a proof that the term is not just a joke. Toshio Yamaguchi (talk) 13:59, 3 August 2011 (UTC)
My reading is that redlinks are allowed, but you should have an alternative bluelink i.e redlink guitarist of the band bluelink where the second wikilink should be unlinked once the redlink turns blue. References - great idea. Agathoclea (talk) 15:05, 3 August 2011 (UTC)
Each red-linked entry must have a supporting blue link in the description because the referencing should be done in the supporting article, not on the disambiguation page. Dab pages are navigation pages for topics covered by Wikipedia. If a topic does not have an article and is not discussed or mentioned within another article, then it should not be included on the dab page. Insisting that dab page content reflect article content--that is, requiring that an article be created, or an existing article improved, to include that content before the topic can appear on a dab page--is not unreasonable. This subject has been discussed repeatedly at Wikipedia talk:Manual of Style (disambiguation pages), and the consensus has always been that references do not belong on disambiguation pages.----ShelfSkewedTalk16:18, 3 August 2011 (UTC)
No, we probably shouldn't change the guideline against including references in dab pages. If the redlink is valid topic for a future article, then the reference which would "prove" it so would also be a valid reference to build a simple stub article around. In other words, the threshold for having a redlink in a dab page is the same as the threshold for having an article in the first place. Adding the reference to the DAB page isn't a more difficult act than adding the reference to a short stub article about the subject. --Jayron3216:30, 3 August 2011 (UTC)
Agree w/ Jayron32. The existing policy is fair and sufficient. It allows for redlinks provided there is a supporting bluelink which, ideally at least, links to a referenced article. If there is sufficient sourcing to justify a mention in a dab page - as Jayron points out - then certainly there is adequate sourcing for a stub article, or at the very least, a redirect.--JayJasper (talk) 16:58, 3 August 2011 (UTC)
Example I found an interesting example of a case where I think a reference would be needed. The dab page BLA claims that BLA is an acronym for Logan International Airport. However, looking at the article, I cannot find a mention of that acronym anywhere. Thus if this is a valid acronym, there should be a reference for that on the disambiguation page. It might be an acronym that is verifiably used somewhere, but would count as trivia in the article about the airport. Thus a reference for this acronym should be allowed on the page BLA. Toshio Yamaguchi (talk) 17:14, 3 August 2011 (UTC)
No, if this is a valid acronym, then that information, and the reference for it, should be added to the article Logan International Airport. If no verifiable source can be found to support adding the acronym to the article, then the entry should be removed from the dab page. If the use is too trivial to be noted in the airport article, then the same standard applies to the dab page.--ShelfSkewedTalk19:37, 3 August 2011 (UTC)
I believe the the Manual of Style on DAB pages is correct as written. References should not appear on disambiguation pages. This does not preclude that some DAB pages may have references, but there would have to be a good reason to ignore the rule. I can not think of any off the top of my head but I will not say there is no DAB page that would be an exception to the MOS. As far as the example above, if there are reliable sources that confirm that BLA is an acronym for Logan International Airport then the information should probably be included in that article. I have looked and so far have not been able to find any reliable source that confirms that BLA is such an acronym. GBfanplease review my editing19:21, 3 August 2011 (UTC)
I looked into who put Logan International Airport into BLA, it was originally inserted 22:41, 15 December 2009 by 66.31.9.250 that geolocates to Saugus, MA just outside of Boston. The same day they added Logan to LIA also. GBfanplease review my editing19:42, 3 August 2011 (UTC)
Dab pages are not regular pages. Their purpose is to help readers find articles when the term they are looking for could refer to more than one thing. Any references necessary should be in the articles pointed to, not on the dab page. If there's enough description to need a reference, just write a stub page for the topic and put it there. As for red links, having those beyond what is already allowed could get out of hand and is not what dab pages are for. --Auntof6 (talk) 19:43, 3 August 2011 (UTC)
Another exampleBlack Hill - This dab page contains 6 redlinks. In my opinion it would far more convenient and useful to add 6 citations to Black Hill instead of requiring someone who wants to improve the dab page to create 6 new articles. Toshio Yamaguchi (talk) 20:07, 3 August 2011 (UTC)
I can see how adding citations to the DAB page is more convenient to someone who is just working on the dab page, but I agree with JHunterJ, I don't see how it is more useful. GBfanplease review my editing20:43, 3 August 2011 (UTC)
Wikipedia disambiguation pages disambiguate Wikipedia encyclopedic content topics that share a possible title (the ambiguity). If the topic isn't covered by Wikipedia encyclopedic content, then it doesn't need to be disambiguated. This is what the current guidelines reflect, and they don't need to be watered down to give homes to content that doesn't meet the criteria for inclusion in the encyclopedia. -- JHunterJ (talk) 20:26, 3 August 2011 (UTC)
I agree with the others here in opposing including references on disambiguation pages. These pages are not meant to index the Internet. The bar for inclusion on a disambiguation is very low -- it only needs to have a non-trivial mention in an existing article. older ≠ wiser21:58, 3 August 2011 (UTC)
Agree with others: redlinks are fine if they refer to something already linked in an existing article, the bluelink. If there's no existing article, and you think the term really ought to be in the dab page, then either add it, with source, as a redlink in an appropriate existing article, or create a sourced stub. If neither of these is appropriate, the item has no place on the dab page (unless there's a very exceptional WP:IAR situation, but nothing comes to mind!) The existing rules seem fine and don't need changing. PamD (talk) 15:54, 5 August 2011 (UTC)
Regarding references, I think the current guideline restricting refs is the way to go, otherwise, I've found pages where redlinks are listed with a ref, and the only purpose was advertising/spam. I agree with above that the ref should be on an article page that is related to the redlink, not the disambig pg, otherwise, someone should really create the article instead of just listing the redlink on the disambig pg. Also, redlinks are okay, sometimes, but I remove them if there are no backlinks that actually use the redlink, otherwise the disambig page gets too unwieldy. --Funandtrvl (talk) 18:32, 7 August 2011 (UTC)
Sticky notes: contributing, for beginners
Concept art: A user clicked the new "sticky note" button - which could be next to "edit". They were then prompted to highlight some text, and leave a comment in a colourful sticky note. Done. Now, other users can click to expand the sticky note and highlight the related text again.
I propose that we adopt Wikipedia Sticky notes (click here for details) - an idea that received enough positive feedback (in the idea lab) that I thought it was worth bringing here. I will only summarize the specific sub-proposals here.
Proposal 1: Sticky notes
This is the fundamental idea: allowing users to leave a small sticky-indicator on the margin, which can expand to show a comment. This is something we could test-run on a large sample of pages.
Proposal 2: and they link to discussion page
This an enhancing idea: having each comment itself be clickable, taking readers to a section of the discussion page that the sticky note generates.
Proposal 3: and they highlight relevant text
This is the enhancing idea that, when you create a sticky note, the system should allow you to highlight relevant text. That text will then appear highlighted if others open your comment sticky note.
I'm very skeptical of this. What would these comments be for? The example you are giving in your illustration seems to imply it's for editorial comments on how to edit the article, but in reality, I'm pretty certain people would immediately begin using this for their personal POV commentary, opinions, OR and so forth. It's often difficult enough to keep such comments out of talk pages (per WP:NOTAFORUM). Providing a technical means of how to plaster such comments all over the article itself seems like not a good idea at all. Fut.Perf.☼17:22, 4 August 2011 (UTC)
Such things could be useful on a WYSIWYG editor, but as asides to the main article, they'd attract a lot of vandalism, and wouldn't really add any potential to give information that wouldn't be better suited to being directly integrated into the body. i kan reed (talk) 17:45, 4 August 2011 (UTC)
We already have a notes function. While I see how this would be better, I don't think it's so much better that it's worth tasking the coders with implementing. Sven ManguardWha?18:45, 4 August 2011 (UTC)
this looks terribly similar to the books I check out from libraries and some morons had to leave their comments on the margins. mainspace is for reading, no discussion belongs there. Choyoołʼįįhí:Seb az86556> haneʼ08:03, 5 August 2011 (UTC)
The mechanism might be useful for posting feedback (e.g. to the talkpage), but the comments themselves should not be visible by default; I share Future Perfect's concerns. If there was an edit view which showed the rendered current article simultaneously, this would then be very useful and worth showing in said edit view. --Cybercobra(talk)09:02, 5 August 2011 (UTC)
Some general comments
Interesting ideas, but we already have an article creation wizard that is:
A brilliant idea
Not enough used
Under exploited
Presents a wall of text at each stage
Needs a great deal of further development, perhaps at WMF level, rather than relying on the lone support of a single editor.
I trust everyone has read Wikipedia: Sticky notes? We may indeed have a article creation wizard that is those things; but I think this new sticky notes feature has many applications, not in article creation, but editing.
To IKanRead, I think you are correct. I do not deny that many sticky notes would be ideas that should be put into the body. Or links that belong in the body. Or rephrasing suggestions that would really just be better performed on the main text. That is the hope, no? People who do not know how to edit would use sticky notes, instead of giving up and losing interest as editors, but also as readers ("I don't edit it" becomes "stuff doesn't get edited" becomes "Wikipedia is not as democratic as we thought"). We KNOW this is happening, and it happens after seeing a walls of HTML text (which I can edit largely with the help of a text editor - and that only came with my account).
Sticky notes, even when there are many of them, stay out of the way unless you click on them.
To Choyoo, you make a sadly true, important point. Those comments are super annoying and distracting. That sounds different than Wikipedia:Sticky notes to start, because in instances where they are used for vandalism, the comments themselves are not immediately visible (only the indicator, which one must click in order to expand and open the comment). Sticky notes are thus way less distracting; you chose to check each one out. When those little indicators are minimized, I maintain that they are actually an enhancement of sorts; they remind you that Wikipedia is what it is: a community project. This does bring me to what I see as the most valid concern for Wikipedia: Sticky notes so far: vandalism...
Even if the feature were out of the way, and leading to way more involvement, vandals exploit every great tool we give users, and so the same would be true of Wikipedia: Sticky notes. There is always great logic to concerns of misuse. But I think the way to deal with this is to find better ways to stop vandals, not to avoid adding features that make editing easier. This is the Wikipedia project, after all.
If ever we refused to attempt something as helpful as sticky notes because we fear vandalism, we would have to be honest about our reasoning. We would have to be clear that we are officially keeping Wikipedia hard to edit as an anti-vandalism measure. The working hypothesis, I think, would be that difficult editing is a sort of filter. Perhaps keeping editing difficult keeps out more and worse comments, at a price worth paying: the loss of many more and better comments, as well as decrease in public engagement. Put this way, I think we have a hypothesis that is not only against the philosophy of Wikipedia, but is a hypothesis that would be falsified if put to the test.
I believe this is long overdue: we need a technical means to deal with those users who are otherwise good-faith contributors but are utterly unable or unwilling to wrap their heads around image copyright, license tagging and the like. We need an measure, below that of blocking, that prevents a user from uploading files but doesn't prevent them from contributing elsewhere.
Technical
Technically, this would be very easy: "file uploader" is already a separate permission bit in the MediaWiki software. We would just need to unbundle it from the automatic "user" group and make it a separately assignable user group, just like "rollbacker", "patroller" and the like.
Motivation
Unfortunately, bad image uploaders are very, very numerous. Mind you, I'm not talking about people who occasionally upload a non-free image that might be argued to fail NFCC#8 or the like (just to put to rest the minds of those who know that I also sometimes take a strong stance about such things; these cases are not what I'm talking about now.) I'm talking about people who persistently upload plain copyvios, or images with completely blank description pages, or who tag random images taken from the web as "self|cc-by-sa", or who use the upload form for non-free images, with the "rationale" and "description" templates automatically pre-loaded, but then fail to fill in any of their fields. Many, perhaps the majority of newbie uploaders do these kinds of things, and a frighteningly large proportion of them will stubbornly ignore all friendly notifications and instructions posted to their talk pages. A huge proportion, perhaps as many as half, of all images uploaded locally on en-wiki these days are bad. (Check out Special:Newfiles a couple of times each day if you don't believe me.)
Suggested policy
Once we have the manageable user right, my suggestion for its use is this: let the user right be granted automatically by default in the beginning, perhaps together with "autoconfirmed" status. But then, let the threshold for taking it away be very low, much lower than that for blocking. Let's say, "two strikes and you're out". (i.e.: you make a crap upload once, you get a warning, you ignore the warning and do it again, you get the right revoked. Very transparent and easy to understand.) Let the procedural threshold for giving the right back be fairly low as well: just ask an admin and demonstrate to them that you have read and understood image policy and have understood why the uploads you did were wrong.
Oppose I share Future Perfect's frustration, having had to deal recently with the uploads of a particularly troublesome user now at CCI, however this isn't the answer. For the rare cases where a user is just so out of line that sanctions are needed, community sanctions tailored to the individual case at hand, which may include partial or full upload bans, are a far better option. Secondly, I think that if this change is implemented as written, it'll be abused terribly. Since so few admins are on familiar terms with the file namespace, let alone work in it, I'm loathe to trust the expertise of a single admin on whether a user should be able to upload or not. If it becomes possible to block people from uploading on Wikipedia, doing so needs to be the result of a discussion, rather than a unilateral action. If the uploads are being done so rapidly that it's disruptive, a regular block would do fine while the details are sorted out. In short, I believe that there is a good husk of an idea here, but it needs fleshing out to make it palatable. Sven ManguardWha?09:08, 4 August 2011 (UTC)
These are not "rare cases", and requiring a process of community discussion for them would be overkill and unworkable. I currently hand out about four or five {{uw-ics3}} or {{uw-ics4}} every day, do at least one or two blocks for related reasons, and this leaves at least half a dozen other problem users below that level who under the current rules I have no way of stopping. Fut.Perf.☼10:13, 4 August 2011 (UTC)
Oppose and Unworkable - #1 non-free images generally belong on Commons (let's please not get into the arguments here; that's the way it is, right now), #2 users who "stubbornly ignore all friendly notifications" need to start reading them - that's part of the ordinary process of warning/admin actions, #3 Unnecessary extra process (WP:CREEP), creating work, #4 I wonder if users who do not understand copyright are really otherwise productive in most cases? Our system is too technically complex in requirements - that's the problem we need to work on fixing, but if a user genuinely struggles with the current system, it'd be more advisable to suggest they get assistance, such as using Wikipedia:Files for upload. Chzz ► 09:20, 4 August 2011 (UTC)
I've taken the freedom of correcting "non-free" to "free" above. (1) Well, you may prefer free images to be uploaded on Commons, but fact is, many (allegedly) free ones still get uploaded here, for whatever reason, and a huge proportion of both them and the non-free ones are bad. (2) Yes, editors ought to be reading warnings. But fact is, they don't. The only way to force them to understand that they must change their upload habits is to stop them from uploading. If you don't want the "block file uploads" option, the only alternative is to block them outright. I wouldn't be opposed to doing that, with a lower threshold than now, but I figure that would lead to even more opposition. (3) I don't agree our system is too technically challenging. Anybody who actually has objectively legitimate images to contribute, and possesses normal adult intelligence and a working knowledge of English, can let themselves be led through the upload process in less than ten minutes. The problems are mostly with users whose images are objectively unsalvagable to begin with. They go to the upload pages, see the warnings (it's impossible to miss them), but then deliberately decide to go ahead anyway and dodge the rules. These are not "innocent" newbie mistakes; we are dealing with people who have consciously chosen to be an irresponsible lazy bum. (4) Offering users more individual assistance and advice is not an option. There are simply too many of them. We don't have the manpower to advise them all individually; plus, such advice presupposes that editors are prepared to ask for it. Most of the problem editors who keep ignoring warnings will simply refuse to communicate. Fut.Perf.☼10:04, 4 August 2011 (UTC)
Thanks for the correction; quite right.
I understand and sympathize that so many users don't actually read messages and/or choose to ignore them. But that's a general problem, not specific to file uploads; it's exactly the same with e.g. creation of new pages - the majority of which are not appropriately referenced; many have stepped through the wizard, with all its clear statements. And with new pages, we also lack the man-power; we're currently intending to stop new users creating live articles (trial here), and whilst I support the notion (per this), I worry about the reality; take a look at WP:FEED queries, where a large proportion never get any response - we don't appear to have the manpower to handle that, either.
We're stopping new users creating articles; we're bashing new users with template-warnings about all kinds of bits and pieces (all stick and no carrot); we don't let people become an admin unless they meet extraordinarily high standards; and this proposal is a further restriction. That's what concerns me. That, because we seemingly cannot provide help and guidance, we use a bludgeon to prevent these "incompetent fools / new users that don't understand our project" (delete depending on your POV).
What next - do we stop newer users from moving pages around, because they're too dim to understand what should go live (and because we can't cope with correcting them all)?
Sorry to digress there, but I do think this is a bigger issue than just image uploading; the question is one of balance between closing the wiki to prevent harm, and open editing/accepting of general-lack-of-clue in many users.
The fact that so many free images are uploaded locally instead of Commons, despite our seeming consensus that they mostly belong on Commons - and that we move them there freely and delete them - seems to indicate that we're doing something wrong, somewhere, by advising people to upload local. I see that happen all the time, on e.g. our helpdesk, when people ask why they can't upload yet (auto-conf) - instead of pointing to Commons, they're told to wait or use FFU.
And, if they belong on Commons/should be uploaded there, then any proposal that only effects enwiki uploads is, really, unworkable. Chzz ► 13:10, 4 August 2011 (UTC)
Comment, neither support, nor oppose. Though it would solve a part of the problem, it by far does not solve it all, I'm even afraid that this is going to be marginal. There are also many cases where files get uploaded with a proper rationale and used appropriately, but then get re-used by others (not the uploader), where the re-user fails to update the file page, etc. etc. Yes, it would stop those editors who upload images without info at all (for which I would support it), it would not stop the all other problems (actually, the editor who lost his uploader bit can still re-use images in violation of copyright - hence, oppose). If editors continuously work in violation of copyrights, block them, whether they are the uploader or not. It will yield yelling in the beginning, but I am afraid that that is the only way to get the message through. --Dirk BeetstraTC10:20, 4 August 2011 (UTC)
Weak support. I first knocked this around in the idea lab last year. The least it would do is to prompt new users to "do some homework" before uploading their non free image and it might give us some indication that the user can "communicate" with us when they request the right. (many users who were eventually indefed for uploading copyvios never said shit on any talk pages) I'm saying weak because I can see some drawbacks to this. The first is that it might create some additional headaches for commons as there might be an increase in uploads with bogus license tags over there. The second is that it will create another hoop for newbies to jump through for "full participation". I can answer the second by saying that I can't think of any case where an image has to be added to an article "right now". --Ron Ritzman (talk) 13:03, 4 August 2011 (UTC)
Just to clarify, in the version I suggested, it wouldn't actually create any new "hoops" for newbies to jump through, as the userright would be granted automatically in the beginning, just like autoconfirmed. They'd only have to jump through the hoops of having to ask and demonstrate they know the rules when they want it back after having it taken away. Fut.Perf.☼13:12, 4 August 2011 (UTC)
Sorry, I think I was commenting on my original idea instead of yours which resembles my original "alternative proposal". --Ron Ritzman (talk) 13:34, 4 August 2011 (UTC)
Strong support with the presumption that it is a right enabled by default, tied in with the rights to create a page) and removable only as a preventative measure after significant disruption; latter would include, say, users that should after repeated discussions of understanding NFC as determined by consensus. Cases of, say, uploading a free image to en.wiki commons, having images they added in good faith sent to FFD for NFCC#8 discussion, etc, are not significant disruption. --MASEM (t) 13:40, 4 August 2011 (UTC)
Strong support long overdue. This also can help to make Wikipedia appearing more welcoming to newcomers, as this would prevent them from getting spammed with messages by other users and bots regarding uploading media non-compliant with WP:NFC. Toshio Yamaguchi (talk) 13:57, 4 August 2011 (UTC)
Oppose Primarily because of the suggestion that the mechanism for removing the right should be extremely low. I might be persuaded to support if the mechanism involved community consensus similar to, say, that necessary for a topic ban, but there's no way I can support it if simple unilateral admin action would be allowed to remove the right. Beyond My Ken (talk) 15:24, 4 August 2011 (UTC)
Are you comfortable with single admins unilaterally blocking bad image uploaders? Because that's what we're doing now. Except that blocks are often handed out only after a person has uploaded about two dozen bad images, passing about a dozen warnings. This proposal is meant to be both a gentler alternative to a block, without the stigma and frustration attached to that, and to save everybody the trouble of uploads and warnings beyond two or three. By the way, taking away rollback rights is also something that is typically done unilaterally by a single admin. Fut.Perf.☼15:30, 4 August 2011 (UTC)
Taking away the right to upload image is not the equivalent to blocking, it is equivalent to a topic ban in the file area. Generally, topic bans are not imposed unilaterally, but take a consensus discussion, and I believe that should be the case for this as well.
Not all rights are equivalent in their scope. Removing rollback, for instance, simply means that the editor is forced to use a different mechanism, undo, but if the file upload right is removed, the editor cannot upload files, period. That, to me, is very much like a topic ban, and it should be handled similarly. Beyond My Ken (talk) 20:29, 4 August 2011 (UTC)
And what is the reason that a milder form of sanction (a partial block/ban, whether technically implemented or not) should be more difficult to impose than a harsher sanction (a full block)? That's something about this whole "topic ban" concept that I've never understood. It just makes no sense at all. Fut.Perf.☼20:41, 4 August 2011 (UTC)
@Beyond My Ken: This analogy makes no sense. I disagree with the assumption that "taking away the right to upload images" is "equivalent to a topic ban". In my opinion, the privilege of being able to upload images is similar to the privilege of being an admin. A user who is given this privilege should be aware of the policies and guidelines governing the behavior under this privilege and should have demonstrated the experience to properly use this privilege prior to being given it. After all, dealing with images and media (especially non-free media) is something that requires some amount of experience and should only be dealt with by users, who have shown to posses this experience. Toshio Yamaguchi (talk) 20:47, 4 August 2011 (UTC)
We disagree. The privilege of uploading images is exactly equivalent to the privilege of adding text. Large amounts of text uloaded here is badly written, badly constructed and badly spelled, and we rely on the actions of other editors to whip it into shape. That's part of the downside of an open source project, part and parcel of the whole package. The same thing goes with images, people who have problems uploading need assiatance and if they cannot learn, then it can be shown to the community that they should be topic banned from uploading images, and that can be put into effect, with the removal of a unbundled user right. There is no necessity for allowing unilateral admin action to, in effect, topic ban an editor from uploading files. Beyond My Ken (talk) 02:53, 5 August 2011 (UTC)
The main problem is users uploading copyrighted text or copyrighted images in a way that violates the owners copyright. If using copyrighted text or copyrighted images here at Wikipedia is permitted under fair use, Wikipedias guidelines require the inclusion of a valid Non-free media use rationale per WP:NFURG and WP:NPS#Fair use of copyrighted primary sources. However the amount of work required to fix the problem is different. In the case of text, it is in most cases possible for the violating editor to rewrite the text and readd it without much effort. However, readding an image requires the editor to make it compliant with WP:NFC#Policy, which means the addition of a valid rationale and ensure the image in fact satisfies this rationale. Most editors adding images or text in violation of NFC (in my opinion) don't know how to write a proper rationale and make the image or text compliant with NFC. In case of text, they can simply "circumvent" this by rewriting the text, which does not require external software and no knowledge of how to write a proper rationale. In case of the image, this is not possible, because the image, even if altered, has a much higher potential of violating copyright as a derivative work. They would have to create an entirely new work (which requires much more effort than rewriting text). Toshio Yamaguchi (talk) 07:15, 5 August 2011 (UTC)
I, for one, am not comfortable with lots of admin actions and interactions, but I don't see why yet-another-complication will help resolve that one. We do have ways of dealing with admins who don't follow agreed guidelines - of course, they're utterly inadequate. But again...that means that the real problem lies elsewhere, not with the fact we allow new users to upload pics, but, in how we deal with them. Chzz ► 15:33, 4 August 2011 (UTC)
If we consider the difference between an admin blocking a user that is uploading obviously-bad image at a fast pace (purposely disrupting WP) without discussion, and a consensus-based discussion about a user that over a long time has uploaded images that have nearly all been deleted and not showing any comprehension of why they have been deleted, but may otherwise be making good text mainspace edits. We don't need new language to handle the former case, but its the latter case where this would be helpful. --MASEM (t) 15:38, 4 August 2011 (UTC)
Oppose I don't see the people who do this as any more specifically problematic, in terms of "rate of problems", as the people who create any other specific problems at Wikipedia that is. We have otherwise "good meaning" editors who do lots of stuff and this specific problem is not special. For example, we have a rampant problem of straight copy-pasting from source texts and "close paraphrase", which is basically to copyright violations what "ethnic cleansing" is to mass murder. This isn't to say that copyvios of text is more or less of a problem than the picture issue, but the way to solve this is not to introduce an insanely complex system of userrights where people have to "prove" themselves before they can effectively edit. --Jayron3220:43, 4 August 2011 (UTC)
Why is nobody reading my proposal properly? For the umpteenth time, I did NOT propose a system where people have to prove themselves before they can edit, and there's certainly nothing particularly complicated about it. The right should be given from the start, automatically, but it should be possible to take it away. That said, I do believe the image matter is special, simply in terms of the percentage of bad uploads to good uploads. I don't think the percentage of bad new pages to good new pages is anywhere near comparable. How many of you have spent some time doing Special:NewFiles patrol recently? In any case, why is the fact that there are other problematic areas too a reason why we shouldn't introduce a solution for this one? 20:47, 4 August 2011 (UTC)
Support - this would lessen the burden on administrators and make them even more disposable. Of course my support is conditional on me getting this right.Volunteer Marek (talk) 05:50, 5 August 2011 (UTC)
Conditional support upon the technical feasibility of this happening. The idea itself sounds quite good to me, largely because (1) I don't think it good to make such a basic right only available to those who ask for it, so I like the idea of users getting it automatically after a few days/edits, and (2) because it's better to remove some technical abilities from a problematic user than to remove all technical abilities, if so doing will solve the problem. Why should someone be blocked and get the negative attention that entails when a simple rights modification would solve the problem without affecting their other abilities? Nyttend (talk) 06:15, 5 August 2011 (UTC)
Oppose. Users who persistently upload copyvios and ignore warnings should be blocked because they are likely to create problems in other areas as well. So, this proposal is actually useless, basically a solution in search for a problem. Ruslik_Zero07:48, 5 August 2011 (UTC)
Tentative support, and I suggest not granting this permission by default, but on application, like the previous "reviewer" group. Most free images should be uploaded to Commons anyway, and the NFCC rules are so arcane that I do not fault many casual editors for just ignoring them. I do not share the concerns that this would be unduly restrictive: anybody who is prepared to read the rules should easily get the permission, and people who are not (or who violate the rules) should have it taken away. That would also be less restrictive than just blocking them, which is what we do now with repeat copyvio uploaders. Sandstein 15:33, 5 August 2011 (UTC)
Oppose Image uploading is simply too common a task to restrict it to a userright that is handed out later. And for the opposite scenario, where it is given out by default, that's useless—users who persistently upload copyvios are completely blocked, no userright revoking needed. The problem is that copyright is confusing and our upload form does not do a good job of explaining it well. We need a better, more explanatory approach, not a new userright. /ƒETCHCOMMS/03:43, 6 August 2011 (UTC)
Support, with a few changes. I don't believe this right should be granted automatically to all users like the 'autoconfirmed' bit. Instead, anyone interested in uploading files should specifically request that right at WP:RFR, similar to requesting rollback, autopatrol, etc. Because Wikipedia has a much larger community than Commons, and that we are an encyclopedia, not a free media repository, file uploading should not be automatically given to all users. There can be productive content editors who may not want to work with files, or may have a hard time understanding basic copyright policy. Some people may even have disagreeing opinions regarding issues such as fair use. —TerrenceandPhillip07:29, 6 August 2011 (UTC)
My definition of "content" on Wikipedia includes images. If I am writing an article, I want to include relevant images so it's not 10kb of boring text. If we only allow certain people to upload images, should we then only restrict article creation to users who understand the full text and conditions of the CC-BY-SA 3.0? What makes editing different than uploading images? They are both adding "content" to me. The problem lies with copyright education and explanation on the upload screen; we can't eliminate copyvios from ever happening again, but we can certainly make uploading images easy, accessible, and understandable. /ƒETCHCOMMS/18:01, 6 August 2011 (UTC)
Well, as I think I said earlier, I don't actually agree that our current system is not "easy, accessible and understandable". To my mind, the number of uploaders who behave completely irresponsibly, by simply ignoring everything they get told along the way, cannot be explained through bad instruction. It really is the uploaders' own laziness. (The fact that laziness appears to be so ubiquitous is no moral excuse for the individual case.) But be that as it may, I do agree there's some room for improvement in the forms. As for the new Wizard at Commons, I don't particularly like it, mainly for the reason that it forces you to first physically upload the file and only then write the description; that's really quite a nuisance. In our system, the one thing that I believe is really technically confusing is the fact that we have "forms within forms" (i.e. a html form, and then within one input box a pre-loaded wiki template with several parameters to be filled out, when newbies will likely not yet be familiar with the syntax of parametered templates, and the function of each parameter is not always self-explanatory. That's one thing we should streamline into a single system of customized html forms.) I've taken the freedom of sketching out the kind of steps I think would be useful to guide uploaders through for our purposes here. Rough draft at: User:Future Perfect at Sunrise/Upload forms draft. Fut.Perf.☼19:45, 6 August 2011 (UTC)
In Wikipedia, I define "content" as working to create new (and notable) articles, expanding stubs, or improving existing articles to FA or GA quality. I agree that it's better to include images into articles, so they can be more interesting or easier to understand for readers. IMO however, most images on WMF projects should come from Commons, as long as they are freely usable and comply with Commons' licensing policy (i.e. public domain, GNU licenses, Creative Commons). Images that are not free for commercial use, derivative works, or is restricted by copyright such as "All Rights Reserved", can be uploaded here in Wikipedia, but not on Commons. But copyright policy can be confusing to some people, and many users have been blocked due to copyvios. We can't enlighten everyone about copyright policies and mistakes can still occur regardless of the situation. But I agree with Perfect Sunrise that some copyvios can be the result of people who may choose to be ignorant, even when being provided with an explanation about copyrights. —TerrenceandPhillip23:10, 6 August 2011 (UTC)
Most users' lack of copyright knowledge is largely due to society's complete ignorance of such laws and the encouragement of illegal P2P filesharing and whatnot by many in the online world. While 95% of new users will have no idea what a "freely licensed image" is, we can't blame them—copyright isn't taught in schools, and even universities aren't able to educate all their students about usable material. What we need, and what will be difficult to do, is make our uploading process very clear (and Fut. Perf, I agree that the Commons UploadWizard is not at all perfect, but I do think their first step with the cartoon is more effective than our enwiki upload directions' wall of text) and more streamlined. As I and others said above, we just block repeat copyvio uploaders, rather than revoking a right. If they cannot understand image copyright why should we assume they understand text copyright, too? /ƒETCHCOMMS/20:46, 7 August 2011 (UTC)
Support - I found possibly the only free image for a certain article, but I couldn't wrap my head around the webs of licensing. I will not be uploading it any time soon unless this proposal is implemented. Interchangeable|talk to me|what I've changed01:32, 10 August 2011 (UTC)
"Layman's Terms" idea / suggestion
Possible problem: Since many Wikipedia articles are technical, it may be impossible for novices to learn about a given article's topic.
Idea: Include the following on technical pages: a small section with a "layman's summary".
Could there be (or is there already?) a standard section or option for giving a short summary in layman's terms? I know (as I understand it) that any editor could add such a "layman's summary" to any page...maybe it could catch on as a common practice, rather than a system-wide revision, which might be difficult to apply. Any thoughts and info are welcome!
We already have a template called "This page in a nutshell", but it's not used for articles. Article summarization ideally, in any case, should be provided by its lead.Jasper Deng(talk)18:09, 4 August 2011 (UTC)
Basically, this is supposed to happen in the lead of an article anyway. That it doesn't always is part of the ongoing need for improvement, but we don't need a new policy. :) LadyofShalott22:36, 4 August 2011 (UTC)
I agree with the above; a good lede, and indeed a good article, should be written in terms a layman can understand. It is possible, even for very complicated subjects; it's not easy, but it's possible, and something we should strive towards.
I agree that the lead should summarize the article in a generally accessible fashion. I think we also have separate explanatory articles for the rare scientific topics that are both very difficult and of great public interest (e.g., Introduction to special relativity). Sandstein 12:11, 6 August 2011 (UTC)
No, the Simple English Wikipedia is subtly different. It's written in a dialect of English known as Simple English, which uses a restricted vocabulary and grammar to make it more accessible to non-native speakers and children. The topics and explanations aren't necessarily what's "simple" about it. Zetawoof (ζ) 07:33, 7 August 2011 (UTC)
A discussion here led to me discovering that a full third of our Burecrats are mostly or completely inactive. This led to a quote by Risker which said in part:
"This raises the question of removing unused or insufficiently used tools: after all, stewards must make XX number of actions with their steward tools each year in order to be eligible for re-appointment. We already, as a project, have serious concerns about administrators using their tools after long periods of absence or inactivity; the opportunity for making a poor decision is much higher with more powerful tools."
Therefore I propose we remove Bureaucrat rights from any user that has not made any Bureaucrat related edits in over six months.
This would follow the same notification procedure as was outlined in the recent proposal to remove Admin rights from inactive admins. It would also have 'if you come back and want the right, you can get it back' clause as the recently passed Admin procedure. This was inspired by the 'pull your weight' clause that Stewards have.
Oh, right. Well I removed #1, so #2 is now the only one up. I support it, although I'm not married to it, considering the first option was already policy. Sven ManguardWha?21:21, 8 August 2011 (UTC)
Ok, but my bracketed statement still applies: this proposal would completely replace the existing policy (which was just minted). Would suggest that you take a look at the previous discussions on removing the bureaucrat permissions from active-editors-who-aren't-using-their-crat-tools before submitting a refined proposal for consideration that takes into account the objections raised in the past. –xenotalk21:28, 8 August 2011 (UTC)
We have bots that maintain the interwikis to the other Wikipedias, however as far as I can tell the links to Commons via {{commons category}} and like are unmaintained. The categories are moved about on Commons - to disambiguate, or to implement a standard naming scheme, for instance, but the inward links from WP are not typicaly updated by the Commons users. Therefore its probably in WPs best interests to create a bot with similar functionality to the interwiki bots for this task.--Nilfanion (talk) 12:51, 9 August 2011 (UTC)
Sounds kinda sensible, to me - but there may well be side-effects and so on that I haven't considered. Or just don't have a clue about. Pesky (talk …stalk!) 12:13, 10 August 2011 (UTC)
Discussion concerning a bureaucrat bot to handle the procedural removal of inactive administrators
I don't see this in the perennial proposals, but pardon me if this has been proposed before. Having "admins" as a user group has some advantages clerically, but in the end, being an admin is (or it's at least supposed to be) just a bunch of tools that are potentially damaging in the wrong hands. Would it be possible to grant those tools to users on a tool by tool basis, much the way rollback is handled? There are backlogs for people with the tools, and the community is probably a lot more comfortable giving a user just the one tool they need to deal with one particular area of interest instead of the whole bag. Things like blocking users and speedy deletion are obviously going to be doled out very carefully, but some things, like taking action on PRODs that have run their course, really don't require a super-trusted user and could be handed out to the WP:WikiGnomes who enjoy doing such work. It would help deal with the backlogs, which is one perk. Presumably anyone authorized to the full set of tools would retain access to the full set of tools. It also complies with the Principle of least privilege, which means we aren't giving users access to tools that they don't know how to use or can't be trusted with, just the tools we want them to use and they're interested in using.
As a side benefit, it could also remove the concept of "being an administrator" which I think has caused more harm than good: these are just users with access to additional tools, and there's less chance of people thinking they're something more than they are and less frustration against a cadre of authority figures. This sub-part isn't necessary, an "authorized to use all tools" user could still have the title of "administrator" if it was felt that distinguishing these people was somehow important.
It might be helpful to have "packages" of tools for the purposes of whatever process replaced RfA, such as an "anti-vandalism" toolset that covered tools like short-term blocks and semi-protection which could be given to new page patrollers. There would probably be one authority that's really not a software issue, which is a "resolution" authority to deal with situations where consensus has to be assessed (e.g. on AfD's), one of the few non-software abilities that admins currently have, though if the resolution is delete that does require a software tool.
Giving the tools out one by one would also make it easier to take them away one by one, since taking away the full set of tools is a big deal and just trimming one or two needn't require ten years of drama at ArbCom.
The real downside to this would be the administrative overhead of doling out the individual tools, which might turn a single RfA into ten separate events, albeit ten hamsterpits instead of a bearpit. SDY (talk) 04:13, 8 August 2011 (UTC)
Wow, that's badly named as a heading, because the entire point I'm trying to bring up is removing the hierarchy by ditching the concept of "administrator" entirely. It causes more problems than it solves, and having a large corps of people-with-tools would bring some resolution to WP:NBD, because it really would be not such a big deal. Anyway, I figured something like this had come up before, though it looks like it's had very little discussion for a perennial proposal, and I think the "can't be done" argument is extremely weak. We don't need "admins" we just need people to do administrative tasks. SDY (talk) 11:55, 8 August 2011 (UTC)
It has indeed been brought up per Jayron, but if it's done right assigning tools individually might just work. I think most people making such proposals had in mind separate bundled access levels between "user" and "administrator", such as users who can rollback and protect but can't delete or block. That idea has drawn similar objections to what you mention at the end of your comments: if the question "should this person become an admin?" is contentious, imagine how contentious the question "should this person be a full admin or should they only get such-and-such tool(s)?" would be. Or perhaps this won't come up so much if we just do away with assigning the single bundled "admin" access level. Since I'm not a fan of the RFA process and what it's led to, I like the idea of, say, someone who does a lot of work in the area of deletion merely having to ask a bureaucrat for a delete button, having amply shown themselves to be trustworthy in that area. Here, the user can pitch in to clear backlogs and help the encyclopedia without all the hang-ups over how many FA stars they've racked up or their level of participation in featured category removal candidates. szyslak (t) 05:18, 8 August 2011 (UTC)
There are additional problems presented with such things (not insurmountable but must be addressed):
How do you verify the person can be trusted to use destructive tools like delete or block - currently we have RFA as a vetting process. That's not easy to expand to a more granular permissions system & the current informal method (of handing out, say, rollback) is unlikely to meet with approval as an alternative :)
Admins currently fulfil a community role in closing discussions & implementing the actions. Theoretically that process could be changed to "any editor in good standing", but in practice that will only lead to arguments :) Admins have a perceived modicum of authority (through being trusted) to implement decisions - and if that situations gets changed we need something effective to replace it.
This situation would probably raise the bar for each individual tool - to the point where the question is asked "but why will you use this tool"; with it leading to a higher standard/need required before the tool is granted. ANd that leading to less people with tool access (when ideally we want MORE!)
These are all issues that would need to be considered and addressed by any such proposal. I suspect this is something that will in time be resolved in favour of splitting up the toolset. But at the moment community opinion is against it. --Errant(chat!)12:12, 8 August 2011 (UTC)
Dealing with each point in turn:
(1, "How do you verify...")- Giving access to only one tool at a time means that we don't have to trust people with a whole group of things, just a few. It doesn't matter if someone has a thoughtful opinion on "cooldown blocks" if all they want to do is deal with requested moves. It substantially reduces the barrier to entry for a tool, since we don't have to trust them with everything, just one thing at a time. This isn't a simple question, but it's much easier under a segmented system than under the current "keys to the launch codes" binary system.
(2, "Admins currently...")-Creating a specific authority for evaluating consensus is something I explicitly addressed in the proposal. You don't have to be able to block people or change usernames to close an AfD (though you might need the ability to delete it).
(3, "This situation would...")-I completely disagree, for the reasons given under #1. Since these aren't "admins" with a broad range of powers but only one additional tool, oversight isn't complicated: if they aren't using the tool acceptably, we take it away.
The intent of this proposal is not to create "lesser admins" but rather to make it easier to grant and take away individual powers. A lower barrier to entry would help the backlogs, and since all they have are the individual powers, a "rouge" user with additional powers could only cause minimal damage. SDY (talk) 00:22, 9 August 2011 (UTC)
...and the add semi-protect button, and the ability to RevDel, and with his level of knowledge as a vandalism fighter, maybe the right to see the hidden edit filters. The "just one button" thing is a fallacy, sorry. Sven ManguardWha?06:34, 9 August 2011 (UTC)
No, Strong Oppose - There are three reasons I oppose this.
First, it would create a nasty time gap issue. Anyone that got the tools before this was implemented would have all of the rights, while anyone who got it afterwards would not be guaranteed to have/get the full suite. This would make what is already a hierarchical system (and I say "is", because I firmly believe that there's sadly a caste culture here) even more hierarchical.
Second, it would make finding assistance harder. If we get raided, I'd have to track down someone who has the right to protect articles, someone who has the right to block, and maybe even someone who has the right to RevDel, and when raids hit, that kind of needless expenditure of time causes real, measurable, and ultimately preventable damage. Even outside of emergencies, this would make it that much harder for users without advanced rights to find people with the ability to assist them with their specific situations.
Third, this won't solve anything. If I trust someone to delete pages, or trust them to know how to edit protected templates without breaking stuff, then I trust them with the whole package. If someone needs one item in the whole suite, and I can trust them with that one item, I can trust them with the rest of the package. Breaking things up won't solve the trust issue, I doubt it'll prove to be a better system of getting the right tools to the right people. It'll just make getting those tools more painful (more processes). Also, having just one of the tools really isn't that helpful. Look directly above (at my response to Σ) to illustrate this. Sven ManguardWha?06:34, 9 August 2011 (UTC)
That's also been proposed, but mostly gets shot down because of the following line of logic:
A vandalism fighter would need to protect, and he'd need the ability to edit protected pages, so he could clean up the mess after protecting, and he'd need the ability to block, and unblock in case he makes a mistake, and he'd need to be able to RevDel, since the 4channers can get pretty explicit when they raid, and he'd need the ability to delete pages, in case they start making attack pages, and he might need to see the edit filter and the deleted contributions if he's raid response specialist, so that he would be able to detect patterns and set up preventative filters...
And there goes pretty much the entire suite of admin tools. There would be only tiny differences between the two rights. In fact, if a "vandal fighter" individually already had the Account Creator, File Mover, and autoconfirmed rights (reviewer and rollback are really a given for a vandalism fighter already) then there would be no difference between the two groups at all. Sven ManguardWha?06:45, 9 August 2011 (UTC)
Sure, a "vandal fighter" could have all of the tools, but there's no need for vandal fighters to be able to do the "core" admin function, which is evaluating consensus and resolving disputes between editors. A "vandal fighter" might have the tools to close an AfD, but they wouldn't have the authority to do so except in highly unusual circumstances. That authority to resolve disputes is probably the authority that requires the most trust from the community. Screwballs that abuse the tools are easy to throw to the wolves. Biased arbiters are where there is a potential for a serious breach of trust. SDY (talk) 01:52, 10 August 2011 (UTC)
Actually, that is NOT a core admin function, and I have absolutely no idea where you got that notion from. Admins have absolutely NO special authority in resolving disputes; many WP:DR processes happen away from the admin boards, and are mediated by non-administrator editors all the time. Any discussion at any noticeboard which needs summarizing and closing can be done by any editor, excepting when the actual admin functions (block-protect-delete) need to be done (see Wikipedia:Non-admin closure). If admins are looked to disproportionally make rulings on discussions, it is only a social development within Wikipedia, and only exists because Admins are also experienced editors, and it is their experience as editors that gives them authority, not their admin tools. Let me reiterate that: Admins do not have any additional authority at Wikipedia. What they do have is additional tools, and a certain level of reputation that comes more from being here a long time than any official role. If you believe that admins have all this extra power with regards to deciding consensus or making rulings, you have a complete misunderstanding of what it means to be an admin. The ONLY benefit to being an admin is the access to the main tools (block-protect-delete), otherwise non-admin editors have the same rights as admins do. --Jayron3202:06, 10 August 2011 (UTC)
That's not entirely accurate when it comes to deletion discussions, per the guidelines at WP:NACD. One potentially productive avenue for discussion would be whether some of the specific limitations on non-admin XFD closes (especially "Non-administrators should not close discussions in which they lack the technical ability to act upon the outcome") are appropriate or not. --RL0919 (talk) 02:25, 10 August 2011 (UTC)
You'll notice that the ONLY two statement in there which do not also apply to admins equally are "Non-administrators should not close discussions in which they lack the technical ability to act upon the outcome." and "Close calls and controversial decisions are better left to an administrator." The reason for #1 is that if it needs admin tools, an admin should close it. The reason for #2 is that the outcome might need admin tools, so see reason #1. In principle, any discussion (not just XFD, but literally ANY discusison, ANYWHERE at Wikipedia) is open to be closed and acted upon by any editor in good standing, so long as nothing needs to be blocked, protected, or deleted. If people ask admins, it isn't because they are required to. It is documented nowhere in Wikipedia that admins are needed to do anything except use their tools, indeed language in most places goes out of the way to make this clear. For just one example, consider Wikipedia:Requests_for_comment#Ending_RfCs which says, (bold mine): All requests for comment on a user need to be closed manually. This should be done by an uninvolved editor (not necessarily an admin) when the dispute has been resolved, moved to any other forum, or seems unlikely to be resolved." Seriously, if it doesn't need the tools to do, it doesn't need an admin. People like SDY really need to stop giving admins more power than we have. --Jayron3202:34, 10 August 2011 (UTC)
Actually, every so often a non-admin will close a discussion in such a way as to clearly require admin action, and just found an admin to carry it out. Though I can certainly understand how that becoming common could be very problematic. I can point to one policy that does privilege admins, WP:NACD has a special rule "Decisions are subject to review and may be reopened by any administrator." whereas on an admin close the matter must be taken to DRV. I'm not sure if it has ever been an issue, or if it has only occurred in the case of really bad closes. Monty84502:42, 10 August 2011 (UTC)
It isn't clear to me that there is anything problematic about it (which by extension means the limitation on non-admin closes may be unnecessary). There are lots of non-WP decision-making systems in which the person who decides the result is not the person who carries it out. There are already two XFD venues (templates and categories) with post-discussion work queues where the final disposition may be performed by someone other than the closer. So there is no inherent reason the closer needs to be an admin, even for a "delete" result. --RL0919 (talk) 02:52, 10 August 2011 (UTC)
If a policy change allowed it, and a non-admin, with say 500 edits, came along and closed a AfD, 5+nom to 4 in favor of deletion, with a delete outcome, would you feel comfortable being the admin to delete the article without reviewing the full discussion and making your own determination as to the appropriate outcome? If you do review the close, then is the NAC really useful? You would be doing the work over again. I'm sure there are some non-admins you would trust without a review, but as a policy applied generally, would it make sense? Monty84503:19, 10 August 2011 (UTC)
I doubt there would be an overflow of inexperienced editors even trying, but just to guide people in the right direction, the guideline should not encourage any random editor to do closes, but rather say something like "any editor with substantial experience participating in deletion discussions" (this should apply to admins also, since there are some who got the bit for vandal-fighting or whatnot, and should think twice before closing something like a CFD or RFD). Also, if the close is dubious, we do have other ways of addressing that, such as taking it to DRV or just reverting the close (in the most egregious cases, such as an editor involved in the discussion trying to close it). A close that looks really out of sorts would trigger scrutiny, but those are also likely to produce protests from someone else before the admin gets to it. So for the most part I expect admins would be "working the queue" of deletions and not doing a lot of rework on closes. Would there be zero problems? Of course not. But the current system is hardly problem-free either. --RL0919 (talk) 04:04, 10 August 2011 (UTC)
I'm afraid that I have not accreted any powers to myself beyond the three tools my RFA supported giving me. If you are going to assert that I have usurped or accreted extra powers for myself, that's the sort of accusation that needs backing up. Where have I personally used or demonstrated any extra power, Malleus? Hm? Please show me where, because I have not, to my knowledge, ever claimed that I had any such power. Put up with diffs or shut up. --Jayron3204:51, 10 August 2011 (UTC)
This is a sterile discussion that is no more likely to lead to a sensible conclusion than any such previous sterile discussions. There is no logic in play here, merely lazy pragmatism. When the abuse filter was introduced, for instance, all administrators were allowed to grant themselves that new right, despite none but a handful having any idea about regular expressions, and certainly none voted into power on the basis of their ability to use that new right. MalleusFatuorum02:39, 10 August 2011 (UTC)
I completely disagree with Jayron32's interpretation of WP:NAC (it generally implies that NAC is only for snowball/speedy keeps, not that any user can close an AfD), and there is massive resistance to any change in the bureaucracy. Part of "the point" of this discussion was to remove the title of "administrator" entirely so that no one would be confused as to whether there was some difference between regular users and admins or not, but it appears that people are only hearing what was said by previous users that attempted to raise the idea. Regardless, it appears this is going nowhere and can be closed. SDY (talk) 02:51, 10 August 2011 (UTC)
The NAC information seems written to discourage NAC closes generally, which is probably a good thing, in that it discourages new users from closing discussions, but I think users who are experienced with the processes, and are thus in a good position to make a NAC, understand that in actual practice, NACs are used more broadly then the NAC information seems to advise. Monty84503:07, 10 August 2011 (UTC)
Sorry, to clarify, I meant that NACs are used much more broadly then the policy seems to advise, but common practice is still limited to situations that do not require an admin tool to carry out the close. Monty84503:41, 10 August 2011 (UTC)
SDY, you are correct. This proposal of yours is the way to resolve the major administrative dysfunctions on Wikipedia, and remedy a huge amount of unnecessary damage that now happens on Wikipedia. But it is too late. We now have a huge corps of privileged administrator mandarins, and their entrenched interests will ensure this proposal will be hurriedly and thoroughly buried again (and again... when eventually someone else dares raise it). The admins have incontestable control here now, and will no more reform themselves than the military in Burma will reform themselves. This proposal will never be properly aired now. Don't pursue it. As I discovered, you pursue at your peril. Just drop it, and back quietly away... --Epipelagic (talk) 09:20, 10 August 2011 (UTC)
I think that this proposal has the potential to eliminate one of the "delay-sionist" time-wasting tactics which is used at RfA, specifically the argument that "this candidate cannot be an administrator because he does not have experience in every single area in which an administrator could possibly work" and in particular, the argument that "this candidate will never work in such and such an area in which he happens to have no experience, and he therefore cannot be an administrator, because it is especially important that candidates for adminship have experience in any areas in which they are never going to work, because it is especially important that we should be able to waste time like this" and similar nonsense, whereupon they tell the candidate to come back in six months so that they can engage in further time-wasting. James500 (talk) 22:17, 11 August 2011 (UTC)
Addition to lonely "[Edit]" button on pages, etc
My suggestions would be as follows:
Add a new entry "[Top]" or "[Return to Top]" "button" next to the current "[Edit]" entry which is located at various points though a page so that the user can return to the top of the page, or at
least to the index for that page.
Also, would it be possible to add a facility whereby if a user branches to another part of the page (or to another page, for that matter) the system can return the user back to the location from which they made the "call" to the associated link? I don't know whether this could be done via dropdown boxes which would allow the user to move backwards to any previous link that lead them to the page that they are currently on without having to traverse all the links that got them to where they are without having to navigate back through each one in turn. As I currently use the system, I have to use the browser's "Back" key to do this when there should be a batter and faster way to do it.
Forwarded for your information and comments.
Regards,
Paul Myers
("prmyers@acslink.net.au")
PS. I'm not a "web" programmer so can't provide any supporting suggestions as to how to implement the above, but I have worked as a COBOL analyst/programmer for many years so have an understanding of programming in general.
—Preceding unsigned comment added by 203.29.97.30 (talk) 1:41, 9 August 2011 (UTC)
I support the idea about the "[top]" links. That might be a good idea for long articles. Maybe it should be added only when the article is larger than a specific number of bytes, so that stubs short enough to not even require any scroll bars and also possibly short articles would not have unneeded "[top]" links. ;-)
As for the second idea, it sounds like that would be an idea for a feature for a Web browser's "History" section: not only show what pages you visited at a website on a particular day, but also the order in which you visited them. That might be more practical than implementing it as a part of the MediaWiki software that Wikipedia uses, but who knows. So I am going to be neutral on this one, for again, it might be a better idea as a feature of the Web browser than as a MediaWiki/Wikipedia feature, but again, who knows. It is a good idea nevertheless.
Oh, and please sign you posts by typing four tidles ("~~~~"). Also, you might not want to put your email address in your posts, for the sake of preventing spam from coming to your email. ;-)
Sorry, but I oppose both suggestions. The functionality of a "return to top" link is already provided by the Home key on most keyboards (or Fn + another key on laptops). The suggestion may work as an optional gadget, but to add such a link to all section headings would be unnecessary clutter. As for the second suggestion, the dropdown list for the Back button in most browsers already provide the feature, so it would be needlessly complicated to re-implement it in MediaWiki (or so I assume, since we need to provide a way to go back to any point in a page, etc.) wctaiwan (talk) 02:40, 9 August 2011 (UTC)
oppose to "Back to Top" style buttons next to edit. Not worth the clutter.
Very much in support of the idea of making linking built in to Wikipedia
It would be interesting to get some data to for the anecdote of "opening a thousand tabs". I often find that I can get to a point where I am opening links all over the place until I have too many things to read. This seems to be touching on an ideal I always support: accounts should have all kinds of features that make just READING easier, even if you do not want to edit. It would be cool if you could turn on something like "breadcrumbs" mode - where opening new links throws the last page onto an easy-to-access "To-read" list or something.-Tesseract2(talk)16:59, 9 August 2011 (UTC)
The idea above isn't bad, but it's not what should be done in the end IMO. I think it would be best if the various Tables of Content produced an anchor (say #WIKI-TOC). If there's a TOC, the [ toc ] links would be present. If there isn't a TOC, then the TOC links would remain absent. It would look something a bit like
Ah well if it's already provided, then this probably would be even simpler. However some modification would probably be required to the software to only display the [[[#toc|toc]]] links if there's a TOC. Headbomb {talk / contribs / physics / books}15:09, 11 August 2011 (UTC)
Multilingual translated articles - automatic translation in Wikipedia
I would like to suggest you that the common articles expressed in
different languages could be viewed in one single page using (for
example - Google translator). Doing this way one can have a more wide
ranging (abrangent/altavista) view or even an overview of the global point of
view about one subject. With the event of Google translator or
similar, a true globalization of concepts is closer to all mankind.
Alternatively, Wikipedia could suggest to the reader the language in which a subject is better or more completely presented.
For this suggestion implementation I do not think that voting is the best way to choose, but some automated technical criteria would be useful.— Preceding unsigned comment added by Jgrpoco (talk • contribs)
I've seen what automated translation does to Japanese... it's not pretty. I'd probably tag a machine translation from Japanese to English G1, since it's usually completely incomprehensible- we even have a rather hilarious article which expounds upon the difficulties of this sort of translation. The Blade of the Northern Lights (話して下さい) 13:18, 11 August 2011 (UTC)
there seems to be some interest among native english speaking people:
"how do i pronounce this correctly??????"
as an american, i am fully aware, that as an american, i am totally
unaware of anything even remotely "International". i still buy gas
by the gallon and not by the liter (pardon me litre).
on the other hand, i am a retired mathematician and programmer.
so please let me make some comparisons:
say i were amongst any of the following:
The IPA is used by foreign language students and teachers,
linguists, speech pathologists and therapists, singers,
actors, lexicographers, artificial language enthusiasts
(conlangers), and translators.
i would hazard a guess and say this set comprises less than 1% of
native english speaking people who visit en.wikipedia.org.
therefore the rational seems to be:
The pronunciation of English words in Wikipedia
is given in the International Phonetic Alphabet (IPA)
using the following transcription, which is not specific
to any one dialect.
the problem with this is: it is not specific to ANY dialect!
except:
foreign language students and teachers,
linguists, speech pathologists and therapists, singers,
actors, lexicographers, artificial language enthusiasts
(conlangers???), and translators.
so here is my comparison...
suppose i WERE one of those folks who actually uses the:
International Phonetic Alphabet (IPA)
and i wanted to know what the square-root of two was...
should i first have to learn about the natural numbers, then the
set of integers and then the rationals and set notation to prove
that the square-root of two is not a rational number and then learn
that it is also neither a transcendental or complex number or quaternion?
so here's where the looking for guidance part comes in...
since i am retired... all that information provided to make sense
of this international alphabet which has been around since 1888,
(but simple american folks like mathematician's have never heard of!)
actually looks interesting to me, but that is probably because i LIKE
looking at unintelligible symbols! but on the serious side, i have
found this to be quite irritating.
so here is my proposed solution:
when a new topic is started, i see: "needs citation" all over the place.
now those comments may all be made by other wiki readers who can't keep
their fingers off the "needs citation" button. but my solution would
require a bit of programming... so here goes...
how about i create a simple database, and every so often the topics
which contain the: International Phonetic Alphabet (IPA) symbols are
matched against this database and we stick a tiny, tiny, little icon
near it (so as not to offend) so that when you pass your mouse cursor
over it, you actually DO get some help on how to pronounce the word.
of course this would only be for the native english speaking wiki's.
if you think this solution might work, let me know, i will be happy
to code it, for the sake of all us simple folk who would like to know
how to pronounce: Mohandas Karamchand Gandhi correctly...
I haven't a cue with IPA and agree that we could use a more intuitive pronunciation guidance in articles, but I think we already have it, or at least a form of it. Check out {{respell}}, and for it in use, see the lead sentence of Azerbaijan. The thing is that it hasn't gotten much use, being only transcluded in about 3,200 articles. Maybe the discussion should turn to how to include this more prominently in guideline pages. It is mentioned already in Wikipedia:Manual of Style (pronunciation), which you say you looked at, though I'm not very surprised you did not notice it since that page does not even contain a clear link to this template that provides the mechanism to place it.--Fuhghettaboutit (talk) 01:20, 12 August 2011 (UTC)
Actually, the lack of ties with a dialect is a strength for IPA, not a weakness. It's also why respell isn't widely used - in the example given of Azerbaijan, the respell text referred to is 'AZ-ər-by-JAHN', which is great until you consider that 'az' is pronounced differently in different dialects. In New Zealand and South Africa, it sounds a little more like 'ehz', while others might sound more like 'oz' or 'ahz'. So how do you know which one of all of those is the way the 'az' in 'Azerbaijan' is supposed to be pronounced? This is where the IPA comes in. It is dialect-independent, which means it provides critical pronunciation information that doesn't rely on comparisons with other sounds that might differ from dialect to dialect. Yes, it's technical, but the sounds producable by the human mouth are complex and varied, and a system that can properly capture the specific nuances is essential. If anything, the respell template should be eradicated for not providing useful information. TechnoSymbiosis (talk) 01:38, 12 August 2011 (UTC)
I agree with you that it's a strength of IPA, but I also agree with the OP that IPA is complete Greek to a large number (maybe the majority) of people. So the question becomes, for people who don't understand IPA (and let's be pragmatic, few will decide to master it just because it's all we provide), is including respell alongside it a boon for them? You donl't say it directly but your post could be interpreted to imply that respell is worse than nothing. I think of it as providing at least some guidance where IPA provides nothing because the person seeing it does not understand it. Note that the MOS section provides that respell should only be used where IPA is also used so we would be providing the IPA for those who understand it as the best pronunciation guide, and respell as the second class alternative for the masses who don't understand IPA.--Fuhghettaboutit (talk) 01:59, 12 August 2011 (UTC)
I believe preserving accuracy of information is critical. I can't 'read' IPA either but if there's a word I'm curious of the pronunciation of, I look up the specifics of how to pronounce the individual IPA letters in that word. If that's too tedious (and I agree it can be, for some), a better option while retaining precision would be to make use of a recording and template like {{IPAc-en}}, as is used on the Azerbaijan article. That way users can still get a precise answer to their question 'how is it pronounced' in an audible format, so they don't have to worry about decyphering the IPA symbols.
As an aside, {{respell}} isn't exactly used in simple ways either, case in point the very same Azerbaijan article. How would a typical English reader decide how to pronounce the symbol ə? TechnoSymbiosis (talk) 03:27, 12 August 2011 (UTC)
Fortunately, schwa is the only special symbol used in the respelling key; the only other anomaly would be "uu" (until recently, "oo" (yes, including the bold)), to express the vowel in the word "food". IMO, {{IPAc-en}} should be mandatory for English IPA. --Cybercobra(talk)06:22, 13 August 2011 (UTC)
Add HTML IDs to article maintenance tags
User scripts and gadgets like Twinkle make heavy use of metadata provided in Wikipedia's HTML output in order to do what they do. However, one of the many commons items on Wikipedia that lacks metadata is the article maintenance tag. There is no way to detect which (if any) tags are present to a given article without requesting the wikitext from the server, which can be quite slow.
Thus, I am hereby proposing to add an HTML IDclass to each article maintenance tag listed at WP:TC.
This will allow Twinkle to provide added functionality (removal of existing tags from an article) without weighing down the server with extra requests. IDsclasses could be of the form class="... ambox-tag-wikify" (for {{wikify}}), or some other form. (HTML IDsclasses are completely invisible, and do not affect the wikitext used to apply tags to articles.)
The proposal would also require modification of {{ambox}}, {{ambox/core}}, and possibly {{mbox}} to accommodate HTML IDsclasses.
This is something that I could set up fairly easily myself (with several editprotected requests), but I wish to gather some support before I do so. (By the way, apologies for alienating any non-technical users with my description... feel free to ask about any points I have not clarified.) — This, that, and the other (talk)04:14, 13 August 2011 (UTC)
I can't think of a case where we would want to repeat particular templates on a page, but I still think it would be better to set a class for each template rather than an id. On that note, ambox already emits a class to the table element saying, zomg, I'm an ambox, so it would be cleaner simply to add the template name as a class.
That said, I was fairly certain that Twinkle goes through the API, not the html output, which is not to say that other scripts don't use the html or that I'm right about Twinkle. --Izno (talk) 05:57, 13 August 2011 (UTC)
You're probably right about classes. I have refactored the proposal accordingly. Re Twinkle, I am a Twinkle coder, and am going to implement this as a new feature. — This, that, and the other (talk)06:04, 13 August 2011 (UTC)
Section problem tag templates can and are repeated. But then again, TW doesn't use them. Is this proposal only for those tags which are used by TW, or for all tags? — HELLKNOWZ ▎TALK12:36, 13 August 2011 (UTC)
I can see no reason why this should not be applied to all tags now, in case Twinkle or other scripts want to be able to recognise them in the future. However, if it is going to cause caching nightmares, then it could be applied only to the 68 tags that Twinkle knows about at present. — This, that, and the other (talk)01:03, 14 August 2011 (UTC)
We've had this discussion before, I'm afraid I don't have the time to find it. Perhaps you could look for it yourself, since it'll prompt any issues people are likely to come up with. Grandiose(me, talk, contribs) 18:14, 31 July 2011 (UTC)
In fairness, after some superficial searching, the recent-ish prior discussions were about tweaking the tagline, to have it include hyperlinks and/or be more verbose, both of which got voted down. There does not seem to have been a recent retain/remove discussion. --Cybercobra(talk)05:07, 1 August 2011 (UTC)
There's not an issue I can't see there being an issue here. When an article is printed out, the tagline tells you where it originated from. It acts as a 'byline', almost as a validation, or even an excuse if things are not entirely accurate ("This article is from Wikipedia, so just keep that in mind"). To remove it would reduce the identity of the project, ultimately. doktorbwordsdeeds18:27, 31 July 2011 (UTC)
Here's the thing. On each any every Wikipedia page, we have File:Wikipedia svg logo-en.svg at the top left of each and every page, which says "WIKIPEDIA – The Free Encyclopedia"; moreover, the HTML title on each and every page also includes "Wikipedia, The Free Encyclopedia" at the end. As long as we have one mention of the tagline somewhere in the HTML (not just in the logo, because then people won't know if you happen to use text-based web browsers). Personally, I think we could do without the tagline on the top of every article; it should already be clear, regardless of what browser you're using, that you're at a Wikipedia page. –MuZemike21:27, 31 July 2011 (UTC)
One significant advantage of retaining the tag line is that it makes it easier to spot screen scraping mirror sites. The graphical logo is easy for a screen scraper to remove, but it requires a tiny bit of forethought and effort to also get the tag line. On more than one occasion I have encountered sites that mirror Wikipedia content and then slap a copyright notice at the bottom of the page. The tag line is surprisingly effective at making the true source of the text known in such cases. --Allen3talk00:18, 1 August 2011 (UTC)
Since they hyperlink "Wikipedia" and we don't, I'd guess the latter. I agree that the tagline is useful in helping ensure some level of attribution in the event of copypasta. --Cybercobra(talk)05:00, 1 August 2011 (UTC)
The concern isn't sinking in. So much so, that I wonder if we are discussing the same thing. Are you talking about the standard wording at the bottom of the page identifying the license and other information? If so, it doesn't waste space. --SPhilbrickT17:32, 1 August 2011 (UTC)
This discussion is about the text "From Wikipedia, the free encyclopedia", which sits at the top of the page just below the page title. -- John of Reading (talk) 17:37, 1 August 2011 (UTC)
Heh, this reminds me of my userpage, "Wikipedia, the free encyclopedia that anyone can edit, including idiots." There's a script that adds "a B-class (for example) article" in front of it. Maybe it should be done for all users? --Σtalkcontribs01:44, 2 August 2011 (UTC)
It's not a script (any longer). It's a standard preferences setting, under Gadgets, in the middle of the =Appearance= section. Any registered user can turn it on if s/he wants to. WhatamIdoing (talk) 00:00, 3 August 2011 (UTC)
I personally like the tagline. It's never bothered me, it feels professional, it it makes spotting a good 60% of the Wikipedia mirrors really easy. Sven ManguardWha?09:10, 4 August 2011 (UTC)
Wouldn't making the aforementioned gadget turned on for all readers help encourage someone to edit a stub article? --Σtalkcontribs05:14, 9 August 2011 (UTC)
Support Removal I have hated that stupid tag since I first began to use Wikipedia. It's unnecessary, users already know where they are, and just in case they have forgotten the logo at the top corner solves everything. A second reminder is ridiculous. Interchangeable|talk to me|what I've changed19:42, 9 August 2011 (UTC)
Support Removal "Everything should be as simple as possible, but not simpler." I think this is clearly a case where things can be made simpler. It looks cleaner, and everyone knows it's coming from Wikipedia. One small thing to check is that sites like Facebook (which copy Wikipedia) still retain something like the tagline. Sanpitch (talk) 04:38, 11 August 2011 (UTC)
Oppose removal, but support having a user preference to disable it. If the tagline can give away content-stealing mirror sites, then that is enough reason to me to keep it. However, I see no problem with allowing the individual registered user to disable it if they want to. It should be turned on by default, in my opinion. [|Retro00064|☎talk|✍contribs|] 05:12, 11 August 2011 (UTC)
Oppose removal, so long as the gadget that prepends "a (something) class article" is turned on for all users, anonymous or logged in, as it would help support anonymous users to try writing their own featured articles. Registered users could delete or move the tagline somewhere else with a setting in the preferences, or delete the tagline's existence entirely in the preferences. --Σtalkcontribs04:13, 16 August 2011 (UTC)
"Please read FAQ before posing a question" on talk page edits
Is it possible to have something along the lines of "Please read the FAQ before posing a question" on talk pages when one goes to edit? It seems perennial questions come up, we get sick of answering the same thing or having long drawn out "polls" and discussions that end the same way over and over, and decide- "we'll put this in a FAQ box at the top of the talk page, that'll solve the problem!" In the end either people arent reading the FAQ's or worse because of the numerous wikiproject etc boxes the FAQ box gets minimized as well and no one looks at it. If we could have a "warning" when people edit the talk pages maybe it will encourage people to read the FAQ's and stop asking the same question that was just closed out 3 months ago (and 4 months before then, and 3 months before then, and 5 months before that!). Any other ideas or suggestions?Camelbinky (talk) 01:15, 14 August 2011 (UTC)
In my opinion FAQ would not work due to length: there are so many long pages to look through that it is way quicker to ask. This is analogous to fiddling with something and then reading the manual if that does work. --Squidonius (talk) 02:01, 14 August 2011 (UTC)
Probably not worth the effort. In my experience, people who don't read instructions won't read them not matter what you do to draw their attention to their existance. In other words, if they haven't read the FAQ which is already noted at the top of the talk page, they aren't going to read the notice which tells them of the FAQ's existance. People either RTFM or they don't, and adding more FMs doesn't necessarily help. --Jayron3204:52, 14 August 2011 (UTC)
There are several methods for doing this. See Template:FAQ for one; it can be displayed uncollapsed by default, which means that every person who clicks on the page will see it. Another option is to create an WP:Edit notice, which displays a message above the edit box. There's been one on this page for two and a half years, which you can view at Template:Editnotices/Page/Wikipedia:Village pump (proposals) (or by clicking the edit button and looking at the part with the orange warning symbol). WhatamIdoing (talk) 23:58, 15 August 2011 (UTC)
A good, but thoroughly pointless idea. If you watch this page for any length of time you come to the tragic realization that a large number of people completely ignore the header (well all headers) and won't follow instructions as simple as "if you're talking about XXX, go to YYY instead". I mean, sure, let's go ahead and put the link up. It can't hurt, and it might help a few people, but it most certainly won't be used by everyone. Sven ManguardWha?01:21, 16 August 2011 (UTC)
It seem to me that this page isn't used enough to warrant potentially relegating good ideas to it (9 edits this year). We have the idea lab now, and this well-used proposals page. Is marking historical and removing the link to it from high visibility areas (eg. WP:VP) a good idea? Grandiose(me, talk, contribs) 20:17, 14 August 2011 (UTC)
About all three of your posts, I feel that {{historical}} tags should reflect the status quo - if a community forum has dried up, then there is Buckley's chance that anyone is going to add new posts there. A {{historical}} tag should make that obvious, so that casual visitors do not have to examine the page contents before they realise that the place is in fact lifeless. I think it would be reasonable to take BOLD action and tag these pages as historical now. (On another note, poor old VPR is not exactly in tip-top lively shape, either...) — This, that, and the other (talk)07:20, 15 August 2011 (UTC)
I'm happy to be bold if there are no objections here in say, a week. This would be to allow for any factors I've missed. Grandiose(me, talk, contribs) 13:02, 15 August 2011 (UTC)
Warm greetings to all(!), I'm thinking that Wikipedia adopt a system where a page is set up for every WikiProject to allow increased one-on-one collaborations and teamwork, as well as easier venerability.
Essentially, an editor would come along, write down a scholarly book that he or she has access to, so that other editors can set up a joint effort in writing (or re-writing) an article. For example, let's say WikiProject Aircraft creates Wikipedia:WikiProject Aircraft/Books. User A writes down a list of books that he/she has, so User B, who owns those books, can communicate with User A and hopefully start a week-long collaboration effort. This system hopefully would abolish the need for an editor to fish around the Project to see if there are editors who have the same sources as him/her. This is one of my ideas which I think addresses the quality issue; a user would normally might be deterred from daunting task of re-writing a page because they think such task this too taxing and laborious. With this system, there is much more potential for an article to be revamped and, hopefully, get promoted to FA status. Furthermore, with the publication written down User C might called User A to verify sources on a particular page, which would otherwise be impossible because User C does not have any knowledge that User A has such sources.
This is only an infant idea – further clarifications to this idea will be carried out should it be adopted. I'd like to hear everyone's comments on this. :D Sp33dyphil"Adastra"07:44, 15 August 2011 (UTC)
Automatically archive all reference links when an article gets FA nominated
Linkrot of online sources is a problem for all articles on Wikipedia. I think, it is especially serious, if it affects featured articles, as this damages the hard work that has gone into an article that actually becomes featured. Therefore I propose when an article gets promoted to FA status, all online sources should be archived as part of the FA process, using a system such as WebCite or the Wayback Machine. This could perhaps be handled using a bot or giving people such as the FA director User:Raul654 or his delegates access to a tool they can use on FACs, when the promotion takes places. This would help to preserve the quality of featured articles and the work that has gone into them. Toshio Yamaguchi (talk) 14:29, 5 August 2011 (UTC)
Understand that these archive sites will honor web site settings that don't allow archiving; the New York Times is one such site. ---— Gadget850 (Ed)talk16:37, 5 August 2011 (UTC)
Anything would be better than the current system. Ideally Wikipedia itself would archive all sources irrespective of any no-spider tagging, but that's not practical here. Providing archive.org links at the very least would help with a good 50% or more of sources. Keep in mind that paywalls aside, major institutions like the New York Times are not likely to be inaccessible or disappear forever. Other websites are far more likely to poof. HominidMachinae (talk) 02:57, 6 August 2011 (UTC)
If this goes through, we should respect individual websites' noindex / noarchive settings (especially when archiving is already something you have to opt out of). Building an encyclopaedia does not trump copyright or respect for content owners' wishes. wctaiwan (talk) 14:22, 6 August 2011 (UTC)
Support - Our featured content is our most valuable content, but it is only as good as the references that support it. When the references go dead, the content is in question so it makes sense to archive as much as we possibly can. I believe WP:Checklinks is helpful with this, but a fully automated process would be much better. Automating the archiving of references would not only be helpful for our featured content, but all of our other content as well. - Hydroxonium (T•C•V) 03:05, 6 August 2011 (UTC)
I agree and I guess this is kind of a problem. If we reach a consensus here to do this, I know a person I could ask to bring this to the foundations attention. And if the foundation chooses to ignore this and instead continues to rule stuff out that is (in my opinion) much less useful than this would be (just mentioning these rectangular boxes at the bottom of articles) then I think something goes awfully wrong here. Just my other 2¢. Toshio Yamaguchi (talk) 15:50, 6 August 2011 (UTC)
Why just FAs? Why not every article? Why not just encourage (not require) all links to be archived using WebCite when added as refs? /ƒETCHCOMMS/17:50, 6 August 2011 (UTC)
The reason for this is, because tons of previous discussion regarding this issue led virtually nowhere. I think this more specific proposal might have better chances to actually gain consensus and reach the stage of an implementable solution. If this is successful, I see no problem with expanding this to other articles as well. Again, even after tons of previous discussions, only very little has been achieved. Therefore I am happy if we can achieve anything in that area. This does in no way imply that I am not open to expanding this to every article in the future, but we have to start small in my opinion. Toshio Yamaguchi (talk) 18:06, 6 August 2011 (UTC)
Support, but for any and all cited references (if they already aren't using the |archiveurl= and |archivedate= parameters). This could be accomplished by a bot or two (it would take some catching up, for sure, but it could be done). ···日本穣? · 投稿 · Talk to Nihonjoe · Join WikiProject Japan!17:58, 6 August 2011 (UTC)
Strong Support. I've long considered link-rot of sources to be Wikipedia's most pressing problem that's not getting the urgent attention it deserves. User:WebCiteBOT was my last hope as everything was going so good but the project keeps stalling. I'm really hoping the Archive-It.org/Wikimedia partnership proposal thing below goes through.. -- Ϫ10:33, 7 August 2011 (UTC)
I think that it would be appropriate for MediaWiki to join the Internet Archive as an Archive-It partner. This would cover all of the MediaWiki projects including all of the language-specific Wikipedias and Wiktionary, among others. --User:Ceyockey (talk to me) 14:59, 6 August 2011 (UTC)
Due to the introduction of the WP:TAGGED article, would it not be useful to display a link to this article in all speedy deletion tags, and in the notifications added to the author's user talk. An example: "See what to do if your article gets CSD tagged.", though this could and should (as is the nature of Wikipedia) be improved upon. Osarius : T : C : Been CSD'd?19:57, 16 August 2011 (UTC)
I started a copyedit but realized just how much work the page needs. For that reason I would oppose, at least for now, adding this to any policy or guideline pages and certainly not to db-meta or any warning notices.--Fuhghettaboutit (talk) 20:12, 16 August 2011 (UTC)
That article is nowhere near ready to be included, and includes some fairly offensive text. "Writing an article saying "Becky is hot" is one thing. Writing an article comparing her ass to a bowl of week-old clam chowder is another." Philippe Beaudette, Wikimedia Foundation (talk) 06:44, 17 August 2011 (UTC)
Dispute resolution noticeboard - Stage 2
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.
Around this time last month, following this previous Village pump discussion, the dispute resolution noticeboard started a one month trial, with WQA and the content noticeboard staying active. Part of that proposal was after one month, depending on the success of the board so far, for these noticeboards, WQA and CNB, to be closed for one month and redirected to DRN, to see if the structured format of DRN can do anything to resolve these content and conduct issues any better, and see if it can reduce the mudslinging that occurs at WQA. I think that so far, progress at the new board has gone well. Not every dispute has been resolved, not all can, but so far things have gone reasonably well. I propose that WQA and CNB be closed and redirected to DRN for a month to see how things go. Steven ZhangThe clock is ticking....21:59, 19 July 2011 (UTC)
OK, so perhaps WQA has it's place. Perhaps it doesn't. DRN is still in it's infancy, and perhaps at a later date will change into something that makes WQA redundant or unnecessary, but it'd still be a reasonable replacement for the content noticeboard, so striking the idea to close WQA, and altering proposal to only close CNB. Stats to follow. Steven ZhangThe clock is ticking....19:50, 20 July 2011 (UTC)
I support doing so for WQA and am neutral on CNB. Also, for the sake of discussion, if the entirety of the WQA archive and history happens to be... lost... during the transfer, I think that would be not at all a bad thing. That page and everything in it should be forgotten forever. Sven ManguardWha?22:08, 19 July 2011 (UTC)
On the hope that DRN is more effective at discouraging uncivil and disrespectful than is "we don't penalize" WQA, which is pretty useless in my experience, I support. I'm neutral on CNB with which I have no experience.
While I have your attention, I believe WP needs a place where uncivil and disrespectful behavior can be quickly and efficiently addressed, the first time with a warning, and subsequent times with progressively longer duration blocks. We need a near-zero tolerance policy for such behavior. --Born2cycle (talk) 22:54, 19 July 2011 (UTC)
Not a fan of DRN so far. Having spent a lot of time in WQA, it actually served its purpose: allowing people to vent a little, encouraging communication, often without a threat to block. In my days in WQA I would actually open ANI reports when a report needed a block. DRN is too structured, which reduces people's desire to post/resolve which almost guarantees some form of escalation. (talk→BWilkins←track) 23:57, 19 July 2011 (UTC)
Sometimes structure is important. It's served it's purpose so far, a trial to see how it works handling conduct issues (as sometimes on WQA they degrade into shouting matches) would be handy, to see how an alternative method would work. It's a trial to see of it works. If it doesn't, at least we will know. Steven ZhangThe clock is ticking....01:24, 20 July 2011 (UTC)
I've been working DRN since it opened and think it's served a role as a great, coordinated place to get focused third opinions and navigate other dispute resolution options. We so far have not been dealing with many user conduct issues, so perhaps WQA should stay open a little longer (3-6 months). I can't see the purpose of CNB staying around now that DRN is up and active. WQA was a nice idea, but it should probably be reconceived as the Civility Noticeboard, along with a comprehensive rethinking of what we want our civility policy to actually be in practice. Ocaasit | c01:07, 20 July 2011 (UTC)
No, I don't support doing this for WQA, and I agree with Bwilkins. So far, DRN seems to be a better run version of CNB, but it hasn't really done much more from what I've been observing over the past few weeks. Still, as it is better at handling the issues which would turn up at CNB, I support closing CNB and redirecting those issues to DRN. I think we should keep WQA open for longer rather than just forwarding all of those to ANI (because unless ANI is managed better, it won't matter what name or format another board takes...we will encounter the same problems as earlier, and this will turn out as a colossal waste of time). Cheap short-term solutions aren't good enough. The admin noticeboards need to be fixed first (if not at the same time). Ncmvocalist (talk) 08:41, 20 July 2011 (UTC)
Show me the data! In that previous discussion, my advice at the time was not to simply run DRN for a while and then close down the other boards so long as the sky didn't fall. I said that there should be an analysis of how well the new board worked in comparison with the status quo. I don't see that here. A few editors' impressions of it did or didn't work pretty well are not even close to being enough (however well intended). How many complaints were lodged at the new board? What are the statistics of how they were concluded? How many were resolved, there, to the satisfaction of the participants? How many were forwarded to other venues, and of those, how many were dealt with successfully at those other venues? How many were unable to be resolved? And how do those results compare with the results at WQA and CNB during the same time period? I would have to oppose closing anything down until such an analysis has been performed and evaluated by the community. --Tryptofish (talk) 16:13, 20 July 2011 (UTC)
Yes, what Wikipedia totally needs is more fuel for the sensitivity brigade. Nothing encourages people to edit more than the prospect of morecool-down blocks impulsively demanded and occasionally granted for completely benign incidents. WQA is perfectly fine the way it is, for reasons laid out above by Bwilkins. If people were actually concerned with etiquette, they'd realize that nothing discourages amicable collaboration and actual resolution of disputes more than the axe of punishment hanging over participants' necks. Continually biting one's tongue in order to avoid punishment is a very efficient way to foster resentment and grudges. Sorry, but this proposal is completely out to lunch. Badger Drink (talk) 18:35, 20 July 2011 (UTC)
I think that DRN is fine, especially now that it's been in existence for a little bit of time and has worked out some of its initial "growing pains". I don't see it as a replacement for WQA though, which takes a lot of criticism (basically for doing nothing?) but seems to serve a purpose. WP:CNB (which, along with quite a few other people, I wasn't aware of) may or may not be useful still, but it's probably too early to tell. If, in a couple of months, CNB is full of tumbleweeds then go ahead and redirect it. If no one squawks, problem solved. Otherwise... well, discussing a merger on the CNB talk page would probably be a good idea, but again I'd wait a little while to see how things shake out. — V = IR(Talk • Contribs)18:38, 20 July 2011 (UTC)
Following striking of WQA, I still think that it's too early to consider the question of CNB's future. Something to keep in mind and keep an eye on, certainly, but... I suggest kicking this can down the road for a bit. — V = IR(Talk • Contribs)20:36, 20 July 2011 (UTC)
Looks like it may be moot point already, but I would add nonetheless that I strongly oppose closing WQA. As B mentioned, it serves a useful purpose as a place to hash out disputes without blocking (generally) being on the table. Beeblebrox (talk) 01:28, 21 July 2011 (UTC)
It should be noted that DRN does not have any inherent enforcement mechanisms. We're all acting as regular editors there trying to negotiate a resolution to the problem. If action is directly taken in regards to a DRN filing, it's when the filing is used at some other enforcement board (3R, AN*, etc.) Hasteur (talk) 13:39, 25 July 2011 (UTC)
Support generally, all efforts to consolidate these dispute noticeboards, including WQA. The fragmentation of noticeboards is a significant contribution to the bureaucratization of Wikipedia. Centralizing and streamlining dispute resolution into a formal, controlled process will result in more productive outcomes and fewer alienating discretionary sanctions. causa sui (talk) 00:19, 23 July 2011 (UTC)
You know, I thought about this rational myself, and I generally agree with it. My only concern is that the board seems to receive some activity still, and I'd hate to see us stomping on toes in something like this. A couple of days ago it looked active, at least. I guess that my suggestion would be to move towards an "orderly" shutdown, rather than suddenly going in an redirecting the page. Stick an edit notice on the page, and a message box, pointing to WP:DRN, and wait. After the board hasn't had any activity for a couple of weeks or something, then redirect it. — V = IR(Talk • Contribs)03:37, 23 July 2011 (UTC)
Oppose in that both DRN and CNB ought to be closed (but not WQA, though it could use some work) unless their guidelines can be better clarified to differentiate them from WP:3O on the one hand (which, notwithstanding some suggestions to the contrary, is not limited to content disputes, per this discussion at the 3O talk page) and WP:RFC on the other hand. If one or the other is to be retained, I prefer DRN to CNB (which I made an unsuccessful effort to tag as inactive in late April) but only because DRN, unlike CNB, is mentioned in {{Dispute-resolution}} and WP:DR. — TransporterMan (TALK) 16:53, 25 July 2011 (UTC)
Update: Support retention of DRN and closing of CNB. After working around DRN and considering the following arguments by others, I do think that DRN has a place. I also feel, however, that the hierarchy of DR (as most clearly set out in the {{dispute-resolution}} template) ought to be changed to put WP:EA in the Tips section (as it's a venue for getting individual help, not solving disputes) and to make the sequence under the Negotiation section be, top to bottom, WP:TPG, WP:3O, WP:WQA, WP:DRN, WP:RFC, and WP:MEDCAB, with text in WP:DR and the guidelines at WP:WQA and WP:DRN stating that WQA and DRN should be regarded as alternatives, not sequential steps, and that use of one precludes the use of the other on a first-come, first-served basis. Regards, TransporterMan (TALK) 17:19, 1 August 2011 (UTC)
The way I see it, 3O attempts to solicit a single 3rd party to give a reading on the individual article and just on the article's content, DRN is to get more than a single viewpoint and to try to resolve the issue that can also consider behavior of the editors or multiple articles. Yes DRN probably covers some of the same ground as 3O, but does it in a way that allows editors to bring a collection of articles that share the same issue while keeping the discussion more organized and centralized. Hasteur (talk) 19:55, 25 July 2011 (UTC)
The overlap with 3O is, indeed, somewhat slight, I don't disagree with that, but how about the overlap with RFC? What does a listing here do that a listing at RFC does not do? Regards, TransporterMan (TALK) 14:17, 26 July 2011 (UTC)
RFC I find is somewhat longwinded and can take an extended period of time. RFC's are designed for those big disputes that need lots of discussion over an extended period of time, DRN is designed to be somewhat quicker, easier, and less formal. Steven ZhangThe clock is ticking....03:25, 27 July 2011 (UTC)
Note: Anyone counting tumbleweeds at CNB should not count my reply to an inquiry there today. I wouldn't have seen the inquiry had I not gone there to count tumbleweeds myself (and the inquiry should have actually been an SPI report, not a listing there). Sheesh, TransporterMan (TALK) 21:51, 29 July 2011 (UTC)
Support merging the content noticeboard – While I have not necessarily approved of the dispute resolution noticeboard, I also see no purpose in keeping both the content and dispute resolution noticeboards around, as they're both redundant. I mean, dispute resolution usually revolves around content, anyways. –MuZemike18:52, 31 July 2011 (UTC)
Partial support: I support merging content board which is overly vague and I didn't know existed. I oppose merging Wikiquette Assistance (formerly alerts) because this helps not with disputes but with people under attack with insults from individuals and/or groups of individuals for whatever reason. We've discussed at the GenderGap list that Wikiquette Alerts (now Assistance) is one place women who feel they are unfairly singled out for attack, or women who have problem with sexist language which seems to be used to make them uncomfortable, can go. CarolMooreDC (talk) 13:24, 2 August 2011 (UTC)
Support The dispute resolution noticeboard actually seems to work (that is to say, discussions provide a working consensus). This is because the board is structured as to encourage a resolution from the get-go, as opposed to the siren-and-flashing-lights style of WQA (and to a lesser extent ANI) which serve more as a means of tattling on editors than coming to an agreement. ThemFromSpace14:55, 2 August 2011 (UTC)
People above were asking for statistics. here's my attempt to summarize archive 1. Maybe I or someone else will get round to more.
rejected 4
not yet sufficiently discussed on talk page 3
consensus already reached on talk page [this seems to me a violation of policy, which, as I understand it, says people on the wrong end of a local consensus have the right of appeal to the community; in my understanding it's part of the role of this NB to tell people how & where to post such appeals; this has happened again more reently] 1
suggestions made & reference back for further discussion 3
referred elsewhere 3
RfC 1
3O 1
mediation 1
discussion fizzled out without apparent resolution 4
resolved 4
by 1 party giving up 2
by agreement 1
by block 1
withdrawn: someone pointed out to the applicant that they'd misread the situation & they agreed 1
Thanks Peter for working on that. I have to admit that I had stopped watching this discussion, and only happened to look back here now. I'm guessing that other editors may likewise not have noticed this information. Please let me suggest that you and others who are working on this analysis get the information to where you feel it is sufficiently complete, and then post a new RfC, to get better input from the community. Good luck! --Tryptofish (talk) 16:04, 10 August 2011 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Proposal for tag for failed "Redirects for discussion"
I realise this proposal may be hard to implement, but here goes! If an article was at one time suggested for deletion and the outcome of the discussion is "keep", one only has to go the "talk page" of the article and see a tag that says "Nominated for deletion - outcome of the discussion was keep". Well, some time ago I suggested that ginger cake should not redirect to gingerbread (sorry, I live in the United Kingdom, where we tend to think of ginger cake as being different to gingerbread). It seems that my suggestion was defeated. How about a tag saying "It was suggested (Word X) should not redirect to this article, and the outcome of the discussion was to leave things as they are" for the case of articles that have been the subject of failed redirect discussions? ACEOREVIVED (talk) 16:10, 17 August 2011 (UTC)
I've noticed in the past that the main page has been deleted by either account hijacking or by accident, to prvent this, cant we somehow make the main page undeletable?--Spoctole (talk) 19:52, 10 August 2011 (UTC)
Reminds me when I discovered what I thought was some rather iffy stuff on a mainframe and I asked an operator to run a little job to test it out for me next time the machine was about to go down. "No there's nothing you can do at user level that'll cause any problems" he said and straightaway ran it. Everything froze instantly and the machine needed to be power cycled. :) Dmcq (talk) 12:23, 11 August 2011 (UTC)
I personally would support the proposal to make the main page undeletable - in fact, I did not even know it could be deleted. It seems an innocuous enough proposal to me. ACEOREVIVED (talk) 20:26, 16 August 2011 (UTC)
It does have an edit this page button for admins. What you are probably seeing is "view source" instead of the edit this page button, which is what you will always see when any page is protected and you don't have permission to edit a protected page.--Fuhghettaboutit (talk) 16:39, 17 August 2011 (UTC)
The software has already been modified to make the Main Page undeletable. However, this is intended to deal with casual curiosity, not a determined attacker. There are well-known ways around it. Dcoetzee15:00, 19 August 2011 (UTC)
Reform of Wikipedia IRC
I've been discussing a huge problem with Wikipedia IRC for a while now with a lot of editors, whose opinions have varied (although I'm not going to identify them, because I'm too tired to go and get their permission). The problem is that Wikipedia IRC users have no control over one of the primary methods of providing help to new users, they can't select the people who run these essential channels, they don't even have a say on minor administration issues. The community has no power to stop cloaks from being made or even to express their concerns. They can't replace the people who "represent" them. They can't voice their opinions on the most minor of issues. If some people, for example, were to believe that it may be ideal to have bots in certain channels, to add to discussion and the assistance provided to new users, they would be shunned. We need a new system if we are to ensure that the encyclopedia continues to be a welcoming atmosphere to all editors, new and old, and the lack of the community's right to run its own assets and channels will surely harm developments to the encyclopedia.
I propose change. I propose that we ask WMF (or if we have the right to, do it ourselves) for a new, welcoming, consensus-based sphere of discussion on the freenode IRC network (or others, should the community choose), where the community has the right to elect its representatives, Group Contacts, to freenode, via on-wiki discussion and consensus, where all channel policy is proposed, changed, and passed by the community, and where the community has the ultimate power to improve this new sphere. I believe that this will help newbies and oldbies alike, for the benefit of the encyclopedia and its great community.
Let us decide. Thank you. --123Ħeðŋeħøŋ45622:30, 16 August 2011 (UTC)
Support IRC is now a fundamental part of collaboration; the old "IRC<>WP" lie doesn't hold true. Our {{helpme}} template links users there, as do our welcome, and many other areas. We need to move towards improved support. The existing system is anachronistic, and in need of reform. The consensus should be able to dictate the operations of IRC - specifically, the help channel, but others as well. Control of these channels should belong to the community; management and operating procedures should be agreed through our norms of discussion and consensus. GCs should be elected through discussion. The community needs to make this happen, in the interests of progress. For historical reasons, the IRC system is administered separately from normal Wikipedian process; this must change, to make progesss. For the future of collaboration. Chzz ► 22:39, 16 August 2011 (UTC)
Just a side question though it may have some bearing. I've never been on IRC. I was wondering: how many users ask help there per day?--Fuhghettaboutit (talk) 23:04, 16 August 2011 (UTC)
We don't have stats, but I think it's about 30-50 people per day on average (I checked a random typical week from my logs a while back and got such a result). --KFP (contact | edits) 23:16, 16 August 2011 (UTC) [Clarification: I only counted people who actually asked a Wikipedia-related question, not others.] --KFP (contact | edits) 23:28, 16 August 2011 (UTC)
Nobody keeps any stats that I know of - and it varies a lot day to day - but on average, I'll probably see 8-10 come into #wikipedia-en-help in the few (4-6) hours I'm on IRC. The vast majority are there for help with WP:AFC submissions; there's also the occasional helpee needing assistance elsewhere, and about every other day we get someone asking for medical advice that we have to tell to go see a doctor. I'd guess there are about 20 or so drive-bys on average during that period as well - people who come in the channel, get welcomed by Helpmebot, and then leave without saying anything. (edit conflict: KFP's count sounds right) Hersfold(t/a/c)23:18, 16 August 2011 (UTC)
Oppose I'm both a newbie on IRC and have been a regular in both places for about a month and I lend a hand in the help channel on questions I'm capable of addressing like "is it notable?" I see absolutely zero reasons to create more bureacracy on-wiki and the above paragraphs of support did exactly nothing to lay out a case of why this is necessary aside from vague boilerplate language about "control" and "democracy" -- which in itself gives me the creeps. If somebody can make a case where the harm is in the current arrangement citing concrete example I'll be more than happy to consider it. From my standpoint, the people I see on IRC regularly and as channel ops are solid, well-respected Wikipedia regulars. NO NEW BUREAUCRACY Snardbafulator (talk) 23:22, 16 August 2011 (UTC)
To address your concerns, I will give some examples. Let's say a user proposes that a bot sending periodic messages about, say, vandal emergencies be installed in a multitude of IRC channels (let's say the GCs' zone of control) to help the reliability of the encyclopedia. The current GCs are inactive, and so they won't approve the bots. Consensus is rising, what can you do? Get active, involved GCs who will listen to the community? Can't do that. Get a new system of approving bots? Can't do that. There is simply nothing that can be done. --123Ħeðŋeħøŋ45612:52, 17 August 2011 (UTC)
I have a few concerns about your proposal (or more perhaps some of the points you raise). I'm not sure what you mean by "Wikipedia IRC users have no control over one of the primary methods of providing help to new users" - the #wikipedia-en-help channel is constantly staffed by active editors; sometimes a helpee will go a few minutes without getting a response, but that's usually during times of low activity (after 5 AM UTC, for example - most English-speaking countries are asleep around then). As for stopping cloaks from being made, I'm not sure why you'd want to. A cloak serves as a means of identification, much as an account on Wikipedia does. It hides your IP address and allows you to get autovoice or other flags. Aside from that, a cloak means nothing. As for raising concerns or proposing new bots etc., have you tried to do this recently and were rebuffed? If there is a problem that needs to be addressed, #wikimedia-ops is always open; as for bots, just bring it up with active users in the channel and discuss it there. I think this is a solution in search of a problem. Hersfold(t/a/c)23:25, 16 August 2011 (UTC)
Concerns have been raised about GCs being inactive and some aspects of channel administration not being in the hands of the community when it should. Why choose a good system when you can choose a better one? Why choose an old, outdated system where the community is mostly, but not completely, involved in channel matters when you can have a system of cooperation, collaboration and consensus, where total power is in the hands of the community, where bad policies can be struck down, where GCs who refuse to allow this can be struck down? --123Ħeðŋeħøŋ45612:52, 17 August 2011 (UTC)
I vaguely support the idea that IRC should be subject to some amount of on-wiki control e.g. we should be able to establish policies by consensus on-wiki that apply with force to IRC channels, and Arbcom should be able to make rulings that apply to them. But the OP's proposal reads more like they had a bad experience on IRC that they're not relating to us and are trying to generalise it into a poorly-conceived proposal. Dcoetzee00:54, 17 August 2011 (UTC)
I have no bad experience with IRC except for the lack of total community control. I tried to generalise it so that the bulk of the proposal was in the hands of the community, and this was just a proposal of certain action.--123Ħeðŋeħøŋ45612:52, 17 August 2011 (UTC)
Oppose; this is utterly unenforceable. We don't get to pick group contacts, we don't get to alter behavioural standards, and we don't get to pick ops, because Freenode is not in any way controlled by the Foundation or WP. If you think you coming to them with a petition will work, you're wrong. By all means try to petition the Foundation to create their own dedicated IRC server network or something, but this proposal fails before it even gets off the start line. Ironholds (talk) 03:35, 17 August 2011 (UTC)
What utter nonsense. While we cannot change Freenode, and while we cannot their policies, we can change who runs our channels and we CAN choose what policies we choose. The Wikipedia community has a right to select its representatives to freenode, and many wish to destroy that right and destroy any hope of a consensus-based, collaborative system on IRC. We must take action if we want change, and change IS necessary. --123Ħeðŋeħøŋ45612:52, 17 August 2011 (UTC)
On principle, I agree that IRC channels with some degree of officialdom (mention in in WP:IRC, official IRC contacts, etc.) should be run with some community oversight. In practice (from my years in various IRC channels), attempts to impose the control of a larger community on IRC channels have rarely if ever succeeded. I just raised the issue in #wikipedia-en, and I think the opposers are right in that greater oversight / more rules would just drive people elsewhere or just completely kill the form of collaboration. It is also debatable whether people who are not already long time users of IRC (and used to its more relaxed atmosphere) would find it a convenient way to collaborate.
Note that as it is, IRC conversations do not have any official power aside from the participants on-wiki actions in their capacity as individual editors or admins, so its effects, harmful or good, are already highly limited. wctaiwan (talk) 04:34, 17 August 2011 (UTC)
Additional comment: What I've said above only applies to #wikipedia-en. #wikipedia-en-help is running very well in its current form. There is usually someone around to help, and most conversations are constructive and relevant to the help request at hand. Additional control on that channel would not have much effect either way, I think. wctaiwan (talk) 04:45, 17 August 2011 (UTC)
But we need a better system, while this is good, we need change if we want a better discussion and help atmosphere on Wikimedia IRC. --123Ħeðŋeħøŋ45612:52, 17 August 2011 (UTC)
Oppose — The IRC channels are separate from on-wiki discussion/rulings/monitoring for one main reason: they're, well, separate from on-wiki discussion/rulings/monitoring. Things tend to be more uncivil, more crude, possibly even involve personal attacks, and as a general whole, even get unruly at times—in contrast to that which you'd find on-wiki. The reason for this is, once again, self-evident: it keeps it from littering on-wiki discussions or activities, because it provides an outlet for people to go, vent frustration, or relax and socialize without their every single word being recorded and coming back to haunt them days/months/years down the road, among other things. One can get in an argument and say something they'd regret saying without it tanking their chances at RfA, for example, or causing them to get banned on-wiki for just some drunken socializing or controversial personal opinion.
If we try stomping over it with official regulation, committees, elections, and all of the various nonsense involved in bureaucratic red tape, it will simply move elsewhere—the very way it arose in the first place. It can easily move to different channels, an entirely separate network, or even entirely different protocols, because the chatters, helpers, and chanops will go where it's most comfortable...and I'll clue you in right here and now, that will always be as far away as possible from attempts at on-wiki regulation. The proof is in its very existence and popularity.
If I recall correctly, I've never said they were "entirely unaffiliated." They're seperate—one doesn't control the other. Just like m:Countervandalism Network isn't "entirely unaffiliated;" it's just separate—one doesn't control the other. Additionally, no, -en-help wasn't in {{helpme}} until only recently—someone only added it last year. You're free to revert, because that would constitute an on-wiki disagreement about content. However, please don't start assuming that enwiki can magically bestow authority upon itself to invade otherwise-personal channels when someone changes a template or alters a page. Keep in mind that although Wikipedia habitually reports on reality, it has no power to dictate it unilaterally. --slakr\ talk /06:36, 17 August 2011 (UTC)
But why have them separate when having them together would ensure more control over channel policies and procedures by the Wikimedia community? The current system may be good, but a consensus-based system is, IMO, even better. And I recall Chzz was reverted and warned when he changed the channel on the helpme template, not your "free to revert" claim. --123Ħeðŋeħøŋ45612:52, 17 August 2011 (UTC)
Oppose per Slakr. The Wikimedia Foundation is quite capable of running a public IRC server. Should they ever chose to allocate resources there, then this becomes a relevant discussion. If freenode staffers maintain "Freenode isn't Wikipedia" in the attitude of their decision making, which they do, we must maintain that Wikipedia is not freenode. That's just how it is. Keegan (talk) 05:29, 17 August 2011 (UTC)
Erm, while Freenode isn't Wikipedia, it may be better to link them as much as we can. We direct newbies to IRC, so when the community cannot choose who represents it to freenode (and vice versa), and change channel procedures and policies, we have a problem. --123Ħeðŋeħøŋ45612:52, 17 August 2011 (UTC)
Support per Chzz. How it will be implemented is the trickier question, but there should be at least a semblance of Wikipedia's rules being applied there. On-wiki discussions for example, should have effect on IRC, contesting a ban, requesting things, getting a say in decisions, etc. From my time there (dunno the situation now, haven't been on IRC for months) for example, the most active helpers often do not have op powers or even just any authority at all to say... kick trolls or be involved in active decisions. It can be frustrating, especially as some ops can be a bit impulsive in their decisions when they're not in the right mood or something. At the very least, ops should have roughly the same responsibilities as admins in that they serve rather than rule. The problem is IRC by necessity must give special powers to the few, and who they are can't really be changed that easily, especially as Wikipedia's channels are in a public non-WMF server - Freenode.-- Obsidi♠nSoul05:43, 17 August 2011 (UTC)
Delink from any and all Wikipedia pages. The channels are admittedly run without regard to Wikipedia behavior policies, which give new users the wrong idea about acceptable communication. I'd support this but the main actors will never agree to it. Cutting all ties should have been done years ago. People are making a great point about how IRC and Wikipedia are completely separate. If that's so, why are we linking to it and promoting it? RxS (talk) 13:27, 17 August 2011 (UTC)
Deprecate IRC with regard to Wikipedia The problems are known. WMF has no real control over the IRC chats. It is no more related to the proper running of Wikipedia than is the infamous "WR." This opinion applies to all such "instant communication" which is not fully transparent to the community. Any such "chats" which have full transcripts posted on Wikipedia would be far superior to the current system, for sure. Cheers. Collect (talk) 13:32, 17 August 2011 (UTC)
Oppose. The current system works fine to me, and I see no need for action. Increasing complexity involves pointless work that detracts from more important tasks, and ultimately more bureaucracy and red tape is detrimental to the goals of Wikipedia. --Slon02 (talk) 14:06, 17 August 2011 (UTC)
Fish or cut bait The proposal has serious merit if just to say whether the IRC channels are part of the project or not. If they are part of the project, then they should be covered by equivalent processes to any other forum used for discussions. They should be logged and be as much a part of "the record" as talk pages and user pages. If they are not a part of the project, then they are unofficial and off-wiki. Links should be removed and they should not be recommended as a support channel for anyone. Jim MillerSee me | Touch me14:25, 17 August 2011 (UTC)
We are researcher at Carnegie Mellon University who are working on a project to involve experts in different scientific fields to contribute to Wikipedia. Our project has started as a collaboration with Association for Psychological Science to improve the quality of psychology articles. More information about the initiative can be found at: http://www.psychologicalscience.org/index.php/members/aps-wikipedia-initiative, and http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Psychology/APS-Wikipedia_Initiative. As part of this project, the team is developing tools to support instructors who are interested to use Wikipedia in classroom. An important purpose of our tools is to allow instructor to share comments they are providing to their students with the Wikipedia community to broaden the audience who can contribute in addressing the problems with the article. To support that feature in our tools, we are creating a manual bot to post comments on article talk pages on behalf of instructors who are very familiar with the topic but might not be familiar with the Wikipedia markup language and to decrease the difficulty of providing feedback for them. You can find more information about the bot which is in approval process here. We appreciate your comments, questions, and concerns. Notice that given the feedback we received from the community we are changing the name of the bot from ExpertCommentBot to InstructorCommentBot. Rostaf (talk) 13:43, 18 August 2011 (UTC)
Kollanthoppu
Kollanthoppu this my village. My village is non pollution and naturely.it has been wonderful area. This area is one great person living. Our name is karthikeyan. He is king of the village. My village famous temple is muniyasawami temple.— Preceding unsigned comment added by Kd3890 (talk • contribs)
Well, already suggested at and in preparation for WP:ACTRIAL, we need an faster way to get to autoconfirmed. It has already been proposed that admins patrol WP:AfC and liberally give out confirmed status to users proposing good quality articles. Take Monsey Church, for example. It was created via the article wizard, drafted in userspace, then moved to mainspace. They posted a review request, with one glance I couldn't believe it was a brand-new article. Newbies have great article ideas, so admins should take more advantage of that by patrolling AfC and the move log and granting confirmed status. Now for the main idea. The Speedy Confirmed Wizard consists of a quiz where the questions are pulled at random from a large depository, preventing posting of all answers. The quiz would require study of Wikipedia's policies and the WP:MoS. If the user passed the quiz, confirmed status would instantly be granted. Now, new users will learn of the wizard via a welcome message posted to their talk page automatically. A frequently declined feature that is on Commons and Meta is auto-welcoming. Considering the fact that I was never welcomed (except by myself once I had general knowledge of Wikipedia), I think leaving a general notice talking about autoconfirmed and linking to basic policies would be good. Then another user could give a regular welcome later. I'm going to continue working on this idea and related templates. Thanks, Nathan2055talk - review03:32, 20 August 2011 (UTC)
Redirects containing topics when possible
We should allow redirects that can concisely identify the nature of an article whose name does not.
Argument: The title used for the referent of piped links ([[referent title|display text]]) can be seen in browsers as alt text. It's logical to hover over a link like "there is no clear boundary between the languages" before clicking it. I've observed Wikipedia users doing the same for links whose display text is their title without parenthesized disambiguation, disambiguating without navigating.
While parenthesized text is sufficient to distinguish, it is not always sufficient to identify the topic. Articles are blessed with identifying redirects only as a sideeffect. Nonetheless, articles that have the choice will use the title that describes the referent, as Hoy uses Norse rather than Norse, which would only frustrate someone looking for the title to disambiguate.
Mathematical objects are often named after non-mathematical ones, which can be sufficiently distinguished using (mathematics), and rarely have identifying redirects. Yet there is a great need for them in math articles — Defining one article depends on several external concepts. Reviewing a concept must be done sparingly, or the article will become unmanageable and regressive. That doesn't change the fact that to understand the internal definition one has to be able to hold the meaning of all the externals and interpret them in the new context. This requires the reader to navigate the regression that the article spared in review. Many concepts can be reduced to simple themes or categories, which could be used to identify them. For example, Image (mathematics) can be meaningfully recalled if Image (output) is used as the title, which would relieve the sentence (Metric space#Continuous maps), "The image of every compact set under a continuous function is compact, and the image of every connected set under a continuous function is connected." If there were titles for math articles that carried enough semantic content to identify the terms as they are read, readers could glean information about a subject and gradually obtain a firmer understanding, rather than requiring comprehensive knowledge of the foundations before approaching the subject.
Policy: Titles of this form are extensions of WP:TITLE's recognizability and precision criteria. Precision stipulates that the title be only as precise as needed to distinguish it from other articles, but WP:REDIR allows redirects for alternative names and (though it may falsely apply here) more specific forms of names. ᛭ LokiClock (talk) 02:31, 21 August 2011 (UTC)
This is trying to optimise for two things at once. That's the sort of thing politicians always seems to be talking about and failing to do, and they fail for the simple reason it is normally impossible. One major requirement is quite enough for article titles. If something like this was to be done the obvious way would be to have a bit of javascript get a small chunk from the beginning of the article when the mouse hovers over the link, support could be put on the server later for just returning what's needed if the feature proved popular and if it isn't popular the extra load wouldn't matter. In fact overall it might lighten the load if it was popular. Dmcq (talk) 08:08, 21 August 2011 (UTC)
Wikipedia has trouble attracting casual or new editors. One problem is that you'll go to fix some issue with an article and find that some editor, often an experienced one, has "improved" the article by smushing all the text and wiki directive together and created a huge hairball. I have, a number of time, given up on fixing an article upon seeing this mess.
My Proposal - all wiki-directives, like refs, images, etc should begin and end on their own line if at all possible. This still leaves the text available for people to compulsively smush together (or to obsessively straighten all the pictures in their own home if they choose).
Conversely, I have often tried to edit some article, only to find that refs or some other template stretch over lines and lines (probably due to automated tools used by some editors) and the whole thing is just too unreadable (The sentence begins BAM multi-line ref and it continues here) for me to actually get to doing it. I wouldn't be too bothered if the template stuff is on its own, single line, but to me that isn't better than having everything together. (Ideally, for source readability, we should separate refs from content, but some editors who do more content work than I have strongly opined that inline refs are much easier to maintain.) Also, It's a personal preference thing. Please don't assume your behaviour is the logical one and ridicule that of others. wctaiwan (talk) 06:22, 18 August 2011 (UTC)
I personally concur with wctaiwan and seem to recall (though I am having trouble locating) that the current guideline is that neither multi-line nor single-line referencing is preferred. I wish the WMF would put funds towards a better citation system instead of their proposed image censorship crap. --Cybercobra(talk)07:22, 18 August 2011 (UTC)
Don't get me started on this whole CITE abomination, which makes things 10 times more uneditable than simple refs and has no added value for 99.9% of Wikipedia users or editors. I considered proposing getting rid of CITE entirely but wasn't up to starting a flame war. :-) Ploversegg (talk) 21:19, 18 August 2011 (UTC)
Ok, I suppose I don't know what the advantages of Cite over
ref are then. The result looks the same to me on the finished
article but the Cite source text is noticeably more complicated,
especially if you are trying to edit it cold. Anyway, ref
does seem to do everything you need while being simple to
edit. Clearly there must be a reason Cite was created to make
up for the complication. I'm sure there was a huge discussion
about this at one time that I missed.Ploversegg (talk) 23:57, 18 August 2011 (UTC)
As the comment above you said: standardisation and error checking. With the template, we get errors if something is malformed, and the format is consistent across every citation made using the template. Editors don't need to worry about memorising the APA style—they just need to fill the information into marked fields (author, publisher, date, etc.). And if we suddenly decide to say, replace periods with commas, we only need to update the template and every single citation would be updated to use the new format. It's more lengthly, but also far more accessible. (And individual editors are free not to use it, too, if they find it cumbersome.) wctaiwan (talk) 02:04, 19 August 2011 (UTC)
Thanks for the clarification. Now, as long as people don't come along and convert all my nice refs to cites using some fancy "bot", I'm happy.Ploversegg (talk) 02:33, 19 August 2011 (UTC)
--Fuhghettaboutit (talk) 20:50, 16 August 2011 (UTC)