Jump to content

Wikipedia:Village pump (proposals)/Archive 69

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

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

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

Automate stock information through RSS feeds

I asked at Village pump (technical) if this was technically feasible, and it looks like it is. I am not an expert on matters of stock markets, but wouldn't it be possible to use a reliable RSS feed to guide a bot to update Template:Infobox company? We could place a flag like NASDAQ = ????, and we could start on only a few companies to begin with. The bot could update with closing price and stock volume, and the template could automatically generate a company value (assuming that those numbers would equal that, I'm not certain myself). User:Gary King expressed at the above link concern over the amount of edits this would make every day (one for each listed company). I think that one edit per week would be sufficient. Obviously this is not a news site or a stock portfolio site. However, I don't think that there can be any doubt that knowing the approximate value of a company has encyclopedic value. It doesn't need to be up-to-the-minute, but most articles I have seen have out-of-date financial info, some by several years. Many more have financial info with no references, or even no context (Sega is up, but for which year, and compared to what, and who says?). It is painful for editors to try and keep this kind of info up to date, and if there is a reliable second-party RSS feed that gives exact info that bots can use, why not have them use it? ▫ JohnnyMrNinja 07:45, 3 February 2011 (UTC)

I definitely support this, the job of updating stats doesn't seem too popular, so getting a bot to do it is great. However, I do not think daily updates is required, weekly or monthly would be sufficient. Another use could also be to update currencies perhaps. Passionless -Talk 08:15, 3 February 2011 (UTC)
Ok, to make this smoother, I'd like to specify I am proposing that (at the current time) this only happen once a week. If we make it once per month now we will not be able to see how well it is doing, and once a day is probably unnecessary. We can change this aspect later, but this seems like the best increment to start with. ▫ JohnnyMrNinja 08:26, 3 February 2011 (UTC)
Where do you suggest the information be pulled from? For myself, I use Google Finance for my stock symbol formatter, which just converts stock symbols that appear in articles to links to Google Finance. One hurdle would probably be that some companies have more than one stock ticker listed in their infobox—especially the large companies, so I suppose someone would have to mark which stock ticker to use as the "primary" one for the bot? Gary King (talk · scripts) 16:15, 3 February 2011 (UTC)
I see little encyclopedic value in keeping data that is constantly updated. That's what stock market websites are for, and they provide summary over time which is much more valuable. We already have yearly summaries in the infobox. We can add quarterly valuation and have that updated by a bot. But having weekly or even monthly data seems excessive to me. --Muhandes (talk) 16:24, 3 February 2011 (UTC)
Agreed, not sure stocks value is really something of use to us. But I like the idea of automatically doing revenue and other financials that we DO track. Do you have anyone to write the bot? --Errant (chat!) 16:28, 3 February 2011 (UTC)
It's not the stock prices themselves I am interested in per se, but the total value of the company (stock price x number of stocks). Surely you would have to agree that the total value of a company is just as encyclopedic as its revenue stream? If once a quarter is all that is desired then that is just as easy as once a month or week. The bot has not been built yet; a bot request will be made once we have decided what it should be doing. As far as RSS feeds, I am not an expert, but every major market has RSS feeds available. I was going to leave that to the bot operator, to see which ones will be best suited for the purpose. At the very least, could we agree that a bot updating the information currently within out scope has value? Because most editors don't like updating that info on the medium to small companies, so it never gets done, and we're left thinking that some company in chapter 11 had a record high quarter. ▫ JohnnyMrNinja 21:23, 3 February 2011 (UTC)
I don't agree value beyond a yearly evaluation (and marginally quarterly) has much encyclopedic value. Consider that the stock value changes momentarily. No matter when you are going to activate the bot, it will take a snapshot of an isolated valuation, detached from the past or the future of that moment. That's sometimes worse than not giving a valuation at all. I'd be all for a bot updating the values already present in the infobox, if such a thing is possible. --Muhandes (talk) 14:35, 4 February 2011 (UTC)
(You probably mean "from moment to moment".) I agree that up-to-the-minutes stock prices are not terribly encyclopedic. However I do agree with Mr N that if we give stock prices, or total values at all, the headline figure should be appropriately up to date, i.e. this month's, this quarter's or this year's. Moreover there is, for me at least, a much bigger issue, in that while "now" is important, it soon becomes "then" and we should not be making the old information inaccessible, nor do we wish to clutter out relatively small article allowance with every stock movement. What I would like to see is, perhaps, annual capitalisation figures. For small companies, or new companies they could sit in the article, for older companies they could go on their own page. This applies to many fields where the numbers, or members, are constantly changing, for example armed strength. I think the gmail page is regularly updated with he amount of space avaiable. Rich Farmbrough, 15:27, 4 February 2011 (UTC).
To address Johnny's interest, valuation of a company (which I agree, is probably interesting) does not change from moment to moment in any meaningful way. Any kind of live updating is probably excessive for this purpose. We usually determine the market valuation of a company when there is a major event such as an IPO, a bankruptcy, a buyout, or a similarly large investment made in one fell swoop by a single party. While this is still a snapshot, it at least represents a statistically significant and long-term reference point. These events are almost always covered in reliable sources and can be accurately documented in the body of the article. They should suffice as a static ballpark figure for the sake of a WP article and only need to be updated when another major event occurs. The daily, weekly, monthly, even annual stock movements are either too small to be worth updating, or too volatile to be reliable information for whatever period is measured. It's a catch-22, and that's just the nature of the market. I don't object to the idea of having a continually updated stock price, but it doesn't seem worth the amount of automated edits that it is going to generate. If this could be done via some external method, like having a client script pull the live price from some other source, rather than writing the updates directly into the article, I would consider that to be more viable from a maintenance standpoint. Ham Pastrami (talk) 22:38, 5 February 2011 (UTC)

Expiry of watchlist items

I would like an additional feature whereby watchlist items have an expiry time. I.e. when adding an item to the watchlist, I would like to be able to specify that it expires (be removed from my watchlist) in x days. Of course the default for expiry would be infinite, and therefore not function differently to the current system. I edit many articles, and feel responsible to address concerns on a talk page soon after my edits, however after a decent interval, other edits will make my having to respond less important. I'm finding it impossible to keep track of pages when too many get placed on my watchlist, so I have to delete articles manually from time-to-time anyway. This proposal would help to automate that manual process. I suspect people running bots and scripts will also benefit from an expiry feature.  GFHandel.   07:05, 15 January 2011 (UTC)

If it would be feasible to install such a feature then I would be sure to use it often as I also will make a minor edit, and then watchlist the page to see if I get any comments about it, but never return to the page again, and after awhile have to manually remove it anyways, but can't keep track of what pages I edited when. --AerobicFox (talk) 07:15, 15 January 2011 (UTC)
Handel's proposal sounds good. But in the meantime, it would be such an advantage in tending to one's watchlist to have a little button adjacent to each item to unwatch it, without having to go through the contortions of visiting the editable list, ticking boxes, scrolling and saving, or alternatively of going to the target, unclicking the blue star and returning. Tony (talk) 08:03, 15 January 2011 (UTC)
OK. See user:js/watchlist. ---— Gadget850 (Ed) talk 17:53, 15 January 2011 (UTC)
Yes, would be good. In the mean time, WP:POPUP has an Unwatch item that saves clicks. Rd232 talk 10:20, 15 January 2011 (UTC)
Another way of doing something similar would be to have a device to incude the pages of your last 50/100/whatever contributions included in your watchlist. Peter jackson (talk) 12:05, 15 January 2011 (UTC)
A slight tweak on this proposal that I would find useful, would be a facility to easily de-watchlist any items that have not been updated in x days. That is, you display the watchlist, you specify the number of days and click - articles where my edits were definitely uncontroversial i.e. no-one has changed or commented on the article for x days since my edits - are gone from the list. Colonies Chris (talk) 14:26, 15 January 2011 (UTC)
I would find it a big DISadvantage to have instant unwatching on the watchlist, myself. An optional timeout sounds like a very good idea, though. ♫ Melodia Chaconne ♫ (talk) 14:52, 15 January 2011 (UTC)
Strong support. I just recently took a weed whacker to my Watchlist, removing all the stuff I only reverted vandalism on or PRODded or whatever. This feature would be a godsend. -- RoninBK T C 16:04, 15 January 2011 (UTC)
Ed, thanks heaps for that little x button function for the ongoing weeding of one's wl garden. At some stage, we should push for it to be a permanent feature (or at least optional via prefs; but I can't see what the objection would be to permanence—the little x adds almost no bulk to each item). Tony (talk) 00:57, 16 January 2011 (UTC)
Not a bad idea. Now I have to figure out why it doesn't work on my watchlist any more. Probably one of the multitude of scripts I have loading. ---— Gadget850 (Ed) talk 01:48, 16 January 2011 (UTC)

It seems that there is good support for the idea. What happens now?  GFHandel.   19:16, 21 January 2011 (UTC)

  • I could write up a script on the toolserver that could be used to help prune my watchlist, right how I have a personal tool that I use, it has a list of about 100 pages that I want permanently on my watchlist, and then grabs a list of the last 500 pages Ive edited and combines the two into a list I just dump onto Special:Watchlist/raw after I clear it. ΔT The only constant 19:26, 21 January 2011 (UTC)
I like this idea a lot, and would strongly support implementation. I too will often make a minor effort where I'm only interested in "watching" it for nn days. Having said that, another way to do this might be to have an advanced feature for editors that classify the edit being made into one of several categories which would then have user-definable behavior for each category. E.g., for N2eCat4, I could customize it to remove all edits from my watchlist at nn days, or I might just use the Cat to look at all of my recent Cat4 edits on one rainy Wednesday afternoon and then bulk delete them after my review. In short, great idea for a feature. Implementation details could vary depending on how powerful someone wanted to make the tool. Cheers. N2e (talk) 19:52, 28 January 2011 (UTC)
  • Support. Great idea! It should be in the preferences and also a clickable "remove" box on the watchlist itself beside each item. Right now I "have 5,281 pages on your watchlist (excluding talk pages)." It's a pain to weed it out, and I usually have about 4,000, but this idea would help a lot. -- Brangifer (talk) 01:14, 29 January 2011 (UTC)
  • Support. I already have the clickable remove button on my watchlist via this handy lil script, but i'd love to also have the option of having my watched pages expire on their own. So how can we push for this to be implemented? A feature request at bugzilla? -- œ™ 12:48, 29 January 2011 (UTC)

I was reading a nearby thread where someone stated that there are about 31 million rows in the watchlist table. A few design suggestions for this proposal:

  1. Add a new column to the watchlist table (of type Byte, called ExpiryPeriod) with a default of 0, and populated with 0s for all existing records. (A default of zero means that there would be no change to the current watchlist mechanism, and the proposal would be opt-in.)
  2. At a designated time each day, delete all records that have a 1 in the ExpiryPeriod field, and subtract 1 from all rows that have an ExpiryPeriod > 1. Zero would mean that items never expire, and the longest expiry time would be 255 days. Using two-byte storage would of course allow much longer ExpiryPeriod values (but I can't see that being significantly more useful).
  3. (Technical DB issue...) Not sure if a transaction should be used for the above two operations? Probably would be best to index the ExpiryPeriod field though.
  4. Change the Watchlist Preferences tab to provide a UI that either indicates no expiry (the default) or a number of days to use as a default. (This could be done with a drop-down list described below.)
  5. When an editor makes a change to a page, if the page is on the watchlist with an ExpiryPeriod of >0, then reset the ExpiryPeriod field for the page to be the value indicated by the Watchlist preference.
  6. Change the Special:Watchlist/edit page to allow the display of the current ExpiryPeriod value, and the entry of a value for each entry on the watchlist. If the maximum number were to be 255, the UI mechanism could be a drop-down list with the number 1 to 255, and the first entry (with key value 0) being "0 (no expiry)". The drop-down list could either be next to each item on the page, or there could be only one drop-down list at the bottom of the page that works with an "Update expiry days" button on any watchlist items that the user has checked (similar to the current "Remove titles" mechanism).
  7. (To slow the growth of the watchlist table...) Automatically set the ExpiryPeriod value to be 255 for all watchlist items (where ExpiryPeriod is equal to 0) for any editor who hasn't logged-in to WP in (say) more than a year. This would mean that defunct editors' watchlist items would eventually be removed from the table (currently after 365 + 255 = 620 days). A note could be displayed to an editor who has had this event triggered and who subsequently logs in (to indicate that they should check the expiry settings of their watchlist items).
  8. The above could be simplified by changing the implication of Days to be either Weeks or Months (and artifically lowering the maximum of 255 accordingly). Weeks or Months would also mean less database processing.

(If it were in C# asp.net and SQL Server, I could do the above in a few hours, but...?)  GFHandel.   23:27, 29 January 2011 (UTC)

  • A watch-list table with 31 million items tells me that there are abandoned, orphaned, obsolete items no human is paying any attention to. What GFHandel is proposing is to address something that has obviously gotten out of hand. Greg L (talk) 23:56, 29 January 2011 (UTC)
  • Doing something about the abandoned watchlist items would be a possible side-effect of the proposal. The main point of the proposal would be to help the active editors (by auto-removing watchlist items after a predetermined interval).  GFHandel.   00:05, 30 January 2011 (UTC)
  • I don't think I formally supported this idea above. I do support it. Tony (talk) 02:48, 30 January 2011 (UTC)
Yeah, that would be great. --A. di M. (talk) 00:34, 7 February 2011 (UTC)

"Mark all edits as minor by default" should be disabled

Resolved
 – Yes it should, as previously agreed. Vote for bugzilla:24313 to possibly hasten the day it happens. Rd232 talk 04:31, 9 February 2011 (UTC)

The option in "My preferences" to "Mark all edits as minor by default" should be removed. I think this is being used more for abuse than what possible benefits there are. For instance, a vandalism-only account can set the option and then go on a vandalism-spree of minor edits; those who choose to ignore minor edits on watchlists won't notice it. IIRC, this is a good explanation as to why IP addresses cannot make minor edits. –MuZemike 20:45, 30 January 2011 (UTC)

Consensus to remove this option has existed for some time. The bugzilla seems to be stuck. –xenotalk 20:48, 30 January 2011 (UTC)
Perhaps it would be a good idea to do something like what we do for rollback or auto-patrolled, where we only allow this option to trusted users who have demonstrated a pressing need for it (such as editors who almost exclusively focus on spell-checking, Wikilinking, punctuation, etc.). -- Mesoderm (talk) 20:54, 30 January 2011 (UTC)
There is a script trusted users can use if they still need to use this function. –xenotalk 21:04, 30 January 2011 (UTC)
Then in that case, I see no reason for the feature to exist at all. Mesoderm (talk) 21:44, 30 January 2011 (UTC)
To expand on xeno's comment, see also Help talk:Minor edit#Should we remove the Preference setting to "Mark all edits minor by default" ? and bugzilla:24313. The process was initially bogged down when a developer removed the feature across the board and was reverted, and since then we have a complete lack of useful response by the people in charge (e.g. claiming they want all users using the preference notified, but then ignoring the request to provide the list of such users so we can do so). Anomie⚔ 21:52, 30 January 2011 (UTC)
  • Support removal. I run into misuse quite often. One doesn't have to ever mark an edit as a "minor" edit, even when it is, and the opposite only causes problems and misunderstandings, such as the abuse mentioned above. -- Brangifer (talk) 05:18, 31 January 2011 (UTC)
We already have consensus to do this. There's no need to vote again. Mr.Z-man 02:41, 1 February 2011 (UTC)

Another Proposal

Sorry, I know I've already posted a proposal very recently. This proposal also relates to Book Creator.

Proposal:

Change Book Creator so that it can convert Wikipedia articles into .doc and/or .docx (Microsoft Office documents).

I guess I am posting this and now realize this may not be possible. I'll keep the proposal up just in case it is possible and will gain momentum...but while I'm at it, does anybody know Wikipedia policy on converting to a "non-free" file format such as a Word document? Oh, I'll throw one more in just for good measure in case it hasn't been mentioned:

How about e-books too? 24.10.181.254 (talk) 03:05, 2 February 2011 (UTC)

.doc and .docx are closed formats so they won't ever be supported. You can however, download things as .odt, although the PDF are much nicer. e-books are being investigated. Headbomb {talk / contribs / physics / books} 06:21, 2 February 2011 (UTC)
You can also download OpenOffice.org from http://www.openoffice.org/, and use it to convert the output file into .doc format. עוד מישהו Od Mishehu 09:03, 3 February 2011 (UTC)
Thanks for the info, Headbomb. I agree that PDF's look better. Od Mishehu--thanks as well. I appreciate the willingness you guys had to respond. 24.10.181.254 (talk) 03:38, 4 February 2011 (UTC)
E books is one of the BEST ideas I have EVER seen here. Being investigated? By who? Staff or volunteers? Is there a forum or page about it?Shabidoo | Talk 22:51, 8 February 2011 (UTC)

Anybody tired of dead links in citation templates? Several of us have been looking in to the problem of WP:LINKROT and have come to the conclusion there are no easy/free solutions. We think it's time for the Wikimedia Foundation to step in and help in some capacity. We would like to get input from the greater Wikipedian community on this issue. Those that are interested are encouraged to voice their opinions here. Thanks. - Hydroxonium (H3O+) 20:42, 5 February 2011 (UTC)

Someone I think was liaising wit the Web Cite people. If you can find out who it might help. Rich Farmbrough, 22:39, 8 February 2011 (UTC).

OTRS flag

Just like Commons, I think we should have an OTRS flag. That way, we could easily identify and contact members of the OTRS team, via lists like Special:ListUsers. Comments? Rehman 05:29, 7 February 2011 (UTC)

And why on Earth would we need to identify OTRS members? They are people who respond to emails - if you need help from them, you email, not leave a message on their talk page. On commons there is actually a use for it, since OTRS-ticketed files are often dealt with publicly. Here, however, the only reason I can think of for having this is for vanity purposes (Look at me, I'm in another user group!) Ajraddatz (Talk) 23:57, 8 February 2011 (UTC)
Maybe you're right. I'm confusing Wikipedia with Commons as another file repository site. Also, Wikipedia deals with much less files than Commons, it doesn't seem that useful here. Thanks for the response. Rehman 01:50, 9 February 2011 (UTC)

More detailed "You have new messages..." banner for IPs/newbies?

The meaning of the basic "You have new messages (last change)" banner might not be clear to casual IP editors who might think it's about their own email or something non-WP related or something unimportant. IP editors should especially be encouraged to read the messages as these could be warnings which if ignored could lead to a blocking, or perhaps a welcome message which might encourage them to register or read up on policies. Could a more detailed banner text be displayed to IP (and perhaps new/non-confirmed) users? Maybe something like "You have new messages from Wikipedia - please take a few moments to read these as soon as possible. (last change)" Once registered, editors would see the current concise orange banner wording instead. Dl2000 (talk) 02:17, 24 January 2011 (UTC)

I'm not convinced that it's unclear; surely most people know what their own email looks like. My reaction to my first message was more "ooh, a message" rather than "I'll just ignore that". Although I guess it might be more confusing for people who haven't registered. Is there any reason to think its a problem at the moment?--Physics is all gnomes (talk) 12:48, 26 January 2011 (UTC)
The key point here is that unregistereds may not always be expecting that WP has a talk page system. There are often problem edit/revert cases where warning messages have gone unheeded, perhaps because these are unread. Or perhaps some IPs miss out on the welcome messages which might encourage registrations. Some admin tools would need to be run to determine how frequently messages are read by unreg/IP editors. If the stats show a low pickup rate, that suggests using a more obvious and explanatory banner for them. It's not the biggest problem in WP - at least in vandalism cases a block gets the message across the hard way. Dl2000 (talk) 04:19, 31 January 2011 (UTC)
Actually, now you've explained it more it seems like a good point, if the stats show there is a problem. Some users end up banned quite shortly after their warning, so helping make sure they read the warning is a good plan! --Physics is all gnomes (talk) 16:10, 5 February 2011 (UTC)
So it seems reasonable that before we alter the messaging behaviour, the first thing is to get some message pickup stats collected. Not sure where to move this forward, though, as it likely would involve some Wikimedia tech folks to indicate how feasible that is. Dl2000 (talk) 04:17, 11 February 2011 (UTC)

So, there are a decent number of articles with gallery sections in them such as Basilica of Our Lady of Licheń and St. Laurence and All Saints Church, Eastwood. Some galleries can be quite extensive, ~20 photos, but to really appreciate them one really must click on them, but than to get to the next one must go back a page than go forward again. This can get annoying so I was wondering if if was possible to create a template that when mulitple photos are put into the template that there would be a 'next/previous image' buttons so that a viewer could go through the images much more efficiently. These buttons exist pretty much everywhere online but not on wikipedia, why not if they are all in the same gallery? Passionless -Talk 00:20, 2 February 2011 (UTC) Addition- I also propose that the description is included when a person clicks on a photo to enlarge it. This, while valuable by itself, would be very much needed if the next/previous image button is created. Passionless -Talk 22:53, 3 February 2011 (UTC)

That idea has good potential. My curiosity leads me to wonder if the reason that it hasn't been implemented is because...maybe it's too hard for new editors to format? But if that is the reason, I think it's a poor 'justification'; I'm sure there are plenty of editors that would be able to figure it out. Seems to me like the beginners edit what they can and the advanced users take care of more difficult, but manageable tasks. I like your proposal a lot. I too get a little tired of the process of going back and then clicking the next image. For one or two images it isn't 'killer', but for a huge gallery, efficiency would be very nice. 24.10.181.254 (talk) 03:10, 2 February 2011 (UTC)
I understand the idea but if an article has enough images in a gallery to cause issues they should really be deleted and moved to commons. If an image is that important to understanding the subject it should really be placed near the related text and not in a gallery. MilborneOne (talk) 21:28, 3 February 2011 (UTC)
Please see WP:Galleries-specifically "gallery section may be appropriate in some Wikipedia articles if a collection of images can illustrate aspects of a subject that cannot be easily or adequately described by text or individual images."
I have only found the wikimedia commons for the first time today, after years of reading wikipedia. I see that the problem is much greater there. I suppose there is a seperate bureacracy for the commons than here that I would have to wade through to get change brought there. The problem is not only limited to galleries, the images in articles such as Fallingwater or Lion are all so closely related a next/previous button would help readers immensely. Passionless -Talk 22:53, 3 February 2011 (UTC)
I agree with Passionless. Even after using Wikipedia for years, it took a while before I even noticed Wikimedia Commons. I personally think that the Wikipedia Guideline on Galleries needs to be discussed. "Indiscriminate" collections of images, yes, certainly is a problem. But I think that the guideline has been formulated too far to the other extreme. I'm just as much opposed to indiscriminate collections of images as the next Wikipedia editor; however, why must all (or most) galleries be discouraged?--Why not omit the 'indiscriminate' pictures in a gallery? I am more likely to look at images that I actually see thumbnails of; much less so to click on a "Commons" image or media link. I highly doubt that Passionless and I are the only frustrated users when it comes to clicking through the images. But yeah, like Passionless has mentioned, maybe it's through the Commons discussion that we try and get our voices heard. 24.10.181.254 (talk) 03:57, 4 February 2011 (UTC)
This also raises the question why click-through rates from WP articles to Commons are so low. If you check stats.grok.se, it looks like typically only 1 or 2% of those whose read a WP article also visit the related Commons category or page. Therefore, if a gallery is removed from an article, more than 95% of readers will no longer see its content, even if it's still available from Commons. I can only think of two explanations here: Either they don't notice the link at the bottom at all because it's typically in the right margin and therefore easily overlooked. Or they disregard it because they are under the not unreasonable impression that all important and high-quality images for that subject are part of the Wikipedia article already, so Commons wouldn't have to offer anything significant beyond that. Whatever the reason may be, galleries in WP articles remain an important feature as long as this situation persists, so making them more convenient to use is an excellent idea IMO. --Morn (talk) 11:50, 9 February 2011 (UTC)
I agree this would be a good feature. There may be a way of implementing it using the "show/hide" functionality (or the same technique) of navboxes, otherwise I think it would need an extension, either a custom one or page variables, or javascript as they have at Wikia. Rich Farmbrough, 00:32, 9 February 2011 (UTC).
The feature sounds a good one especially for Commons and could also be implemented automatically for categories. However I would oppose the galleries in Wikipedia being just galleries with loads of pictures stuck in, I think the current guidelines are good. A way I think of getting more people to Commons would be to put the box linking there in the gallery section if there is one instead of in the see also section. Dmcq (talk) 12:08, 9 February 2011 (UTC)
Right now the link box is under external links, not "see also". But perhaps that's the problem--Commons is not actually an external web site but part of the same project. That might be confusing for readers. I have also already experimented a bit with putting an extra link to Commons below galleries, like here, but I don't know if that makes a difference. --Morn (talk) 14:09, 9 February 2011 (UTC)
You are absolutely right Dmcq that offering tools can result in people getting carried away. But that is what good governance is about, or ought to be. Preventing the problematic uses of facilities rather than denying facilities themselves. This is how WP came about, after all, allowing anyone to edit, then stopping the malicious, misguided or incompetent. Rich Farmbrough, 14:14, 10 February 2011 (UTC).
There is a slide-show gadget on Commons. That does show promise - firstly for registered users, but secondly that a suitable default interface could be provided. Rich Farmbrough, 14:14, 10 February 2011 (UTC).
Ya, I saw the slideshow yesterday, though only editors and not readers can use it, and although it does make the photos larger, it still does limit the size of many photos to be smaller than if they were to be clicked on once, and I don't think you can re-click a photo to make it its true full size in the slideshow. Though in general, it is going in the right direction. Passionless -Talk 21:50, 10 February 2011 (UTC)

HTTPS

Proposals

  1. I suggest that all logins are made through a secure page by default like Gmail and Yahoo
  2. I suggest that login page does NOT use mixed contents
  3. I suggest that secure pages are easier to reach. Simply adding s to http should make the page secure. Currently the secure page is REALLY long https://secure.wikimedia.org/. Let's simplify it to https://www.wikimedia.org and https://en.wikipedia.org

--Tyw7  (☎ Contact me! • Contributions)   Changing the world one edit at a time! 05:53, 9 February 2011 (UTC)

Why? Dmcq (talk) 11:57, 9 February 2011 (UTC)
For more security and prevent session jacking. --Tyw7  (☎ Contact me! • Contributions)   Changing the world one edit at a time! 20:31, 9 February 2011 (UTC)
See Bug 225. This feature request is older than tumbleweeds. Titoxd(?!? - cool stuff) 22:48, 9 February 2011 (UTC)

WP:TALK Title change

For discussion, please see Wikipedia talk:Talk page guidelines#Title change. Jujutacular talk 08:06, 10 February 2011 (UTC)

MOS:FLAG description of appropriate use needs expansion

I recently re-added a flag icon to a country topics template. The revision history is here: [1]. My edit was then reverted, citing the WP:ICONDECORATION guideline and the WP:Other stuff exists essay. Then, in reading MOS:FLAG, the guideline gives descriptions of "inappropriate" uses, but is not clear in mentioning what would be an "appropriate" use. Shouldn't both "sides" be presented and described in the policy, in order to avoid mis-interpretations? I would think that using a flag icon in a country's topic template would be an appropriate use, and am eager to hear if other editors would agree. I would also like to know how that MOS section could be updated, per consensus. Thanks, --Funandtrvl (talk) 06:15, 11 February 2011 (UTC)

It is tricky, there does seem to be a lot of "colourful bunting" around. Sometimes the flags are useful, often they are not - in which case they are an accessibility issue, as well as cruft, albeit pretty cruft. I raised the question about balance (and also the negative tone) on the talk page of Icondec some considerable time back, and thought I had made the page more positive. Which is what should be aiming at with all our guidance. Lists of prohibitions are beloved by bureaucrats however, and are much easier than saying what is good in many cases. Rich Farmbrough, 06:33, 11 February 2011 (UTC).
Yes, that is a good point. In looking at the edit history of that MOS page, it does seem to be recently edited by just a few people, which is not using a consensus-based model to set up a guideline-- to say the least. Could you explain how the flag icon causes an accessibilty problem? Is there an accessibilty problem with all templates, or just the flag/country icons? Thanks, --Funandtrvl (talk) 06:54, 11 February 2011 (UTC)
Tastes differ. There are some people that'd rather have no picture at all on wikipedia. There is also the potential political problems introduced by flags, such as the flag of northern ireland (template:Northern Ireland topics). Pictures in such template title bars should be highly relevant, indicative, and non-intrusive. I find this is the case for template:countryX topics, like for example template:Denmark topics, template:Japan topics, template:Peru topics. Cheers. walk victor falk talk 07:16, 11 February 2011 (UTC)
What is the relevance for the flags in the templates you listed, should we add a flag every time a country in mentioned Gnevin (talk) 12:33, 11 February 2011 (UTC)

I think flag icons are overused, and would favor a clearer and more restrictive policy on their use. I work on a number of articles with a historical context, and see a fair amount of the wrong flag icons being used in an article. Of course, the historically correct flags are not recognizable to most readers. In fact, many contemporary flags, especially at icon size, are not recognizable to most readers. That's why the guidelines also call for the name of the country or sub-national entity to be displayed with the flag icon. The flag icons are not really adding anything to the information being delivered by an article (with the exception of articles about the flags, where larger images should be used), and in many cases may convey misleading or incorrect information, or exacerbate controversies. -- Donald Albury 12:58, 11 February 2011 (UTC)

I too think flag icons are overused. My particular problem is that the use of such flag icons on Wikipedia articles can often introduce a subtle but important non-nuetral point-of-view. A bunch of flag icons in an article tends to imply a nationalistic point of view and gives the state a prominence that may be unwarranted by the particulars of the article. Examples may be found in many business-related articles that have businesses from around the globe involved; the businesses are presumably private associations of private individuals doing business. Yes, they are each domiciled in some nation or the other in terms of their business addresses, but bringing in national flags seems to me to introduce a WP:POV, and one that is generally not supported by the specifics of the article. Cheers. N2e (talk) 15:20, 11 February 2011 (UTC)
Well, it boils down to a matter of taste, really. Like mentioned above, some people like flags, and some don't. Somehow, I don't think we're going to arrive at a consensus here. I do agree, however, with N2e that flags on a business-related article is probably not a good idea, but I also agree with victorfalk that flag icons on the "countryX topics" templates are an appropriate use. I really find the flag icons helpful, based on the fact that I've learned about a number of country flags and can now identify more of them than before, due to the icons being present on the templates. I still would like to see the MOS:FLAG article updated to list not only the "inappropriate" uses of the flag icons, but also the "appropriate uses" too. It's only fair to describe both sides of the issue and let the editor make his/her decision, and not to just present the "negatives" of the issue in a biased manner. --Funandtrvl (talk) 18:32, 11 February 2011 (UTC)
MOSICON lists the appropriate uses Wikipedia:Manual_of_Style_(icons)#Appropriate_use. How do you find the flag helpful other than you've learnt by osmosis so extra flags which if you could of learnt a lot easier and better by visiting List_of_national_flags and where the icons aren't tiny Gnevin (talk) 18:57, 11 February 2011 (UTC)
(edit conflict) No, it doesn't. As stated in my comments above, I was referring to the lack of an "appropriate uses" section under the "Flags" section (where MOS:FLAG points to), not just the "General" section (where WP:ICONDECORATION points to.) In regards to your question, I do find the List of national flags article helpful, of course. However, that is just one article out of 3 million, and most of the country articles and templates do not even link to that page. Having the flag icon on the different country templates adds exposure, obviously, to what the national flag is, of those respective countries. --Funandtrvl (talk) 19:13, 11 February 2011 (UTC)
I've always thought that the most useful application of flag icons is to aid navigation of (relatively) long lists or tables, where each item has a strong (or "strong enough") national association, and ideally has more than one entry per nation. With this possibly narrow definition, I present some "good" examples:
  • List of Olympic medalists in alpine skiing – clearly Olympic sports have a strong national association, and these icons make it easier to browse the list to find all skiiers from a certain nation
  • 2010 FIFA World Cup – the flag icons, especially since they are aligned vertically, help the reader scan the list for match results of a single team, as it progressed through the tournament
  • Napoleonic Wars – the infobox has long lists of combatants and commanders. Even though most every flag is historical and unknown to the average reader, they serve a purpose here by associating commanders with nations, without making the infobox unwieldy by imposing a different layout
  • Moscow#International relations – the long list of twin cities is slightly improved by the flag icons, as it makes it easier to scan the list looking for cities in specific countries
and some "bad" examples:
  • PepsiCo – there is absolutely no value in having a singular flag icon in the infobox. It draws undue weight to the "Headquarters" field, and adds nothing to the linked text of "United States"
  • Template:U.S. presidential elections – almost every article on which this navbox is found has a title that starts with "United States" in large bold text. What added value is a little, singular icon at the bottom of those articles?
  • USL Premier Development League#2011 Teams – subnational flags are even more obscure, and these teams don't "represent" their state or province
I do agree that WP:MOSFLAG is poorly written and due for a makeover, and I'd like to see it somehow capture these thoughts, without suffering from bureaucratic bloat. There must be an elegant way of stating where flag icons are useful, and where they are not. — Andrwsc (talk · contribs) 19:07, 11 February 2011 (UTC)

RfC to use archived citations at Wikiwix

Dead links in citations (i.e. WP:LINKROT) are a significant problem on Wikipedia. A task force found that the French Wikipedia dealt with this situation by using cached webpages at Wikiwix.com. Based on the conversation here, I have started an RfC to do the same thing. This requires modifying MediaWiki:Common.js, which is the javascript common to everybody that visits the English Wikipedia using a web broswer with javascript enabled. This modification will change how everybody sees Wikipedia, so I am encouraging everybody to comment on the RfC. Thanks. - Hydroxonium (H3O+) 15:43, 11 February 2011 (UTC)

Virginia Elisabeth Farmer

Forgive me, please, for suggesting this but I did not grow up with computers and I can't figure out how to do this. I was hoping that someone could create an article about Virginia Elisabeth Farmer, an author. She wrote "Lizzie's Blue Ridge Memories," for children and is also known as an extra in at least two movies. (I read about this on her facebook fan page.) Her fanpage says she is working on more projects and she has about 90 fans. Her book for children is sweet, but at the same time, thought provoking, dealing with death and other social situations.

Facts: Resident of Grandhaven, Michigan Of mixed blood Cherokee heritage Brigham Young University alumnus

Articles and reviews can be found on Amazon and other pages. More articles and reviews can be found on her facebook fanpage. I wanted to find out more and did a search on here. That's when I found out there were no articles about this author or her book. Please, don't suggest that I do this because as I said, I didn't grow up with computers and if anyone out there is a computer snob, that really won't help. Second, I am sick and weak and can't do it as I tire easily. I hope I will get better. Thank you for your time.— Preceding unsigned comment added by JunkMailFyle (talk • contribs) 17:00, 11 February 2011

She doesn't seem to have significant coverage about her in reliable sources such as books, magazines, or newspapers. We don't use Facebook as a source. We need significant coverage about someone to write a biography. Fences&Windows 04:17, 12 February 2011 (UTC)

Accessibility for unregistered users

Having the references in smaller type is an accessibility issue for unregistered users. We should remove the css element that does this. Rich Farmbrough, 22:25, 8 February 2011 (UTC).

Could you elaborate a bit more? I know that references are smaller, but why does this only affect anonymous users? Yoenit (talk) 22:34, 8 February 2011 (UTC)
It doesn't. Simply every time I bring this up as a genreal issue people kindly tell me how to hack my css, or that a gadget is available. I don't have much of a problem, personally, but enough to know that it is a problem. Rich Farmbrough, 00:11, 9 February 2011 (UTC).
Are you proposing that we should 'forbid' anything under our default font size because some people don't know where the "Larger" option is in their webbrowser ? —TheDJ (talk • contribs) 22:45, 8 February 2011 (UTC)
No, I'm saying we should not have small fonts for references for several reasons. We already have guidance elsewhere on the general deprecation of non-standard font sizes. Using the embiggen control results in the normal text of the article being too large, those who can control, or have others control for them, the size of text will already have optimized the size. There are no compelling reasons to have small text. We do not need to look like paper. We are not paper. Rich Farmbrough, 00:11, 9 February 2011 (UTC).
Just to comment, a lot of people with visual impairments are already using OS settings, browser settings, and other software to enlarge text on their screen. Browsers let you set a minimum font size, or override all font and color styles on web pages, and this does not require editing CSS files. You can also disable CSS altogether for a particular site (in Firefox under the View menu), and the result is often quite nice. – Acdx (talk) 06:53, 9 February 2011 (UTC)

It's only 10% smaller, so this is hardly an accessibility issue (if X*0.9 is too small, then X probably is too, so it's the reader's responsibility to zoom as needed). It's just a design issue: and most people prefer it because it makes it easier to skim the page, because the refs look slightly different. Rd232 talk 00:29, 9 February 2011 (UTC)

I have seen a number of complaints about the legibility. "Just a design issue".... Rich Farmbrough, 00:38, 9 February 2011 (UTC).
If the reference list size needs to go, the so does every other instance of small fonts— infoboxes, navboxes, etc. ---— Gadget850 (Ed) talk 04:27, 9 February 2011 (UTC)
While I have no issue with other instances going too, it doesn't necessarily follow. Navboxes and inofboxes are a different style, less dense than normal text, while references may be more dense. And while they have internal footnotes as small as 6pt (I would judge) that could also be resolved in a number of ways (there does seem little point using a smaller font for collapsed navboxes since they take no space until they are uncollapsed). We should really consult usability/accessibility experts on this stuff. Rich Farmbrough, 11:43, 9 February 2011 (UTC).

Wellll... some websites have CSS font size change buttons baked in, don't they? Could we do that? Rd232 talk 04:28, 9 February 2011 (UTC)

I don't know, its certainly an idea. Whether it's worth increasing the complexity of the interface to maintain an existing piece of complexity or not might be determined by some study. Rich Farmbrough, 11:43, 9 February 2011 (UTC).
Well the buttons would apply to the entire page; I just don't see the 10% difference as an issue. My suggestion is merely aimed at making it easier for a reader to adjust Wikipedia's font size generally, even though many readers will already be well aware of how to do it via the browser. Rd232 talk 13:59, 9 February 2011 (UTC)

Personally, I like to have the footnotes smaller, but I can see how this may be an issue for some users. Same thing with size for images.

Couldn't there be a way for unregistered users to set some preferences and save them via cookies? I mean, I have some preferences set for Google (which national site for the main Google page, which country for Google News, and so on), and these are in force via cookies whether I am logged in or not. Couldn't Wikipedia do the same? (Anyone refusing to accept cookies is probably tech-savvy enough to fix this in some other way.) --Hegvald (talk) 18:27, 9 February 2011 (UTC)

Would someone please explain the problem with font size? Wikipedia:Manual of Style (accessibility) is mute on font size as an issue and even mentions the use of <small>. I have skimmed through the Section 508 and Web Content Accessibility Guidelines and don't see this. I have used some online accessibility tools and don't see a font problem.
Now, if we do have accessibility issues, wouldn't a better solution be to create variant skins with accessibility to address any and all issues? (It does appear that our use of stylesheets is a 508 issue.) ---— Gadget850 (Ed) talk 18:05, 12 February 2011 (UTC)
The issue is simply that the end user can be assumed to have set their browser to a default font size that's comfortable and legible for them. Increasing the font size over the default by too much is annoying to read, but unless it's set to be enormous (less than one word per page, say) there's no real usability issue. Decreasing the font size below the default by even a little bit can make it difficult to read, and the only stylistic defense of this that's ever been offered is "on my browser on my computer it looks fine for me". — Gavia immer (talk) 18:32, 12 February 2011 (UTC)
And that is why every page fails the 508 standard in our use of stylesheets, regardless of font size. ---— Gadget850 (Ed) talk 18:39, 12 February 2011 (UTC)

Keep deleted templates to support viewing old revisions

Suggestion: deleting templates ({{expand}} springs to mind) breaks old revisions. It should be possible for deleted templates to be wrapped in a {{deletedtemplate}} wrapper which detects whether the page URL contains "&oldid", which makes it likely that it's an old revision. What the wrapper would do is simply display the template as it was before deletion (if &oldid is found), and suppress the template output (or give an error message) if not (i.e. if the current revision contains the deleted template). Does this make sense? Is it worth doing? Rd232 talk 00:25, 9 February 2011 (UTC)

I don't believe templates can detect that they are on old versions of pages. A significant template like Expand could simply display as a null template - unbreaking the old revisions. The better solution is for the historical verisons of the pages to use historical versions of templates (proper history like ZUG), something I have advocated for some time. Rich Farmbrough, 00:37, 9 February 2011 (UTC).
historical versions of templates would be lovely, but infinitely more complicated and vaguely never-gonna-happen territory. What's wrong with my detection of &oldid in URL proposal? (The only kink is permalinks to the current version, but they shouldn't contain deleted templates anyway.) Rd232 talk 03:35, 9 February 2011 (UTC)
I seem to remember coming across this. If you go to the history of a page and click on a past version, you won't get the version of a template that was actually on the page at that time, you'll get the present version, or an error message if it's been deleted. Peter jackson (talk) 10:20, 9 February 2011 (UTC)
(True history is not that hard.) Well the current (permalink) version we can use in theory "revision = -" ({{REVISIONID}}) - but I'm not sure any of the magic words give is the actual URL being accessed in the first place which is the pre-requisite for your idea. If you can (something like {{fullurl:{{PAGENAME}}}} =//en.wikipedia.org/wiki/Village_pump_(proposals)/Archive_69, of course, doesn't work) then the implementation should be easy enough, given that our damaged string functions can cope, which they quite often can't. Rich Farmbrough, 11:25, 9 February 2011 (UTC).
Hm, looking around at the string functions available, I'm sure it's doable, but I'm not sure how the various limitations will interact in terms of working for all page titles. Perhaps someone else would like to play around and see how it goes... Is there a bugzilla entry for a proper history thing? Rd232 talk 14:11, 9 February 2011 (UTC)
Of course, a simpler, temporary alternative would be for the {{deletedtemplate}} wrapper to always display a small "deleted template, should only be visible on old revisions" warning over the final version of the template before deletion. Rd232 talk 17:26, 9 February 2011 (UTC)
Or, more crudely, simply "This template has been deleted". Rich Farmbrough, 14:43, 10 February 2011 (UTC).
I don't know, I am not terribly enamoured with the rate that Bugzillas get zapped, so I haven't looked (that I remember), I should.
But your basic idea might well be solvable, since you can compare the revision ID of a history page with the current one. Let me experiment with Expand and we can find out. Rich Farmbrough, 14:43, 10 February 2011 (UTC).
'Tis done. [2] displays an "Expand" template, but if I use it here I get:

The template {{Expand}} has been soft deleted.

Et voila! Soft deletion! Rich Farmbrough, 14:58, 10 February 2011 (UTC).
Now someone has to continually monitor Special:What Links Here on all the 'soft deleted' templates to see whether some n00b has created error messages on current revisions by placing a softly deleted template on it (bearing in mind that one of the keep arguments for {expand} was, it's so simple even idiots can remember it/use it - the exact kind of idiot who isn't likely to know what 'soft deletion' even is, or how to fix the resultant error message), just so we can view old revisions in perfect condition. MickMacNee (talk) 16:04, 10 February 2011 (UTC)
Infact, even non-n00bs are likely to not have a clue what it means if they see it mentioned. The analogy to soft-redirection is if anything, a complete red-herring. Given the fact that Wikipedia:Soft deletion is a failed proposal about something completely different, I suggest you avoid the whole phrase all together, and come up with a simple message which explains why someone might be seeing this message, and what to do about it. MickMacNee (talk) 16:14, 10 February 2011 (UTC)
I've done it myself infact [3] (I've hardcoded the message above too, to retain this discussion thread's logic.) MickMacNee (talk) 16:23, 10 February 2011 (UTC)

Well that seems pretty neat, if it really works consistently. The logic should be moved into {{deletedtemplate}} for general use, and some instructions written. Unless anybody thinks it a bad idea to implement this. PS One kink: the same "remove me" message is shown on old revisions which postdate the template's deprecation, even though you obviously can't remove the template from an old revision... I've tweaked the message accordingly to add an "if this page is a current revision". Rd232 talk 17:29, 10 February 2011 (UTC)

{{Deleted template}} created. Needs documentation. Also created tracking category. Rich Farmbrough, 06:28, 11 February 2011 (UTC).
Done. I wonder if it's possible to allow subst:ing in order to fix talk pages and archives using deleted templates in past discussions? Rd232 talk 14:49, 12 February 2011 (UTC)

A request for bot approval has been filed for a task that will, among other things, "delinks full dates (but not lone day-month strings or years), days, months, decades, centuries", "removes direct links to full dates, whether ISO8601, dd mmm yyyy or mmm dd, yyyy, including piped links of same to chronological articles in almost any imaginable form" (per WP:UNLINKDATES) and ensure articles uses a consistent date format throughout.

A member of the Bot Approvals Group has requested community input to determine if community consensus exists for an automated process of this nature.

Editors are invited to comment on the feasibility and desirability of the automated task here. –xenotalk 16:22, 15 February 2011 (UTC)

Featured sounds main page proposal

Voting has begun at Talk:Main_Page#Featured_sounds_vote. Adam Cuerden (talk) 19:58, 15 February 2011 (UTC)

  • Hey, is nowiki broken?? I had to delete the final semicolons
    I think it doesn't work inside headings? -- Ϫ 06:18, 12 February 2011 (UTC)
  • Dunno how doable this is, but when wikilinks break across right margin of body text or (even worse) across the columns of a cite (imagine one breaking from the bottom of a long left column to the top of the right) it's odd to say the least. I suggest it would be beneficial to comprehensibility to replace all empty space in wikilinks with &nbsp; ...can this proposal be done?Locke'sGhost 05:41, 12 February 2011 (UTC)
You can replace the ampersand with the HTML entity &amp; ---— Gadget850 (Ed) talk 06:22, 12 February 2011 (UTC)
I think it would be better to use CSS. For example <span style="displaywhite-space: nowrap;">[[Wikipedia]], the [[Free content|free]] encyclopedia that anyone can [[Help:Editing|edit]].</span> should not wrap. – Allen4names 06:59, 12 February 2011 (UTC)
I'm fairly sure that that implementation is wrong; you probably want <span style="white-space:nowrap;">Blah blah blah</span>. I don't think nowrapping links is a good idea, though; there are too many places where long links (eg section links) should wrap. Happy‑melon 19:55, 12 February 2011 (UTC)
Correction made per Happy-melon. Thank you for the correction. – Allen4names 23:16, 12 February 2011 (UTC)
Behold the magic of {{nobr}} Titoxd(?!? - cool stuff) 06:53, 17 February 2011 (UTC)

Forced Response tool for Admins

I often see that warnings and questions on talk page regarding disruptive users are often left unanswered or even acknowledged...especially by new or unregistered users. I sometimes wonder if they even know that a talk page exists, or that they should bother to look at it. Anyway, would it be possible to add an admin tool that blocks a user from editing until a response is made on their talk page? I would see it working, for example, in this way: A disruptive user gets a couple of warning on his/her talk page, but does not respond or change behavior ----> Admin uses the "response required" tool and requests communication with a message (or template) on the user's talk page ----> Next time the user tries to edit, he/she gets a notice that a response is required to an issue on their talk page before editing can resume ----> When a response is received, the admin can verify this and remove the editing restriction. I just think this might be a good way to "force" someone to put down the stick and communicate...even if the response is "go to hell", an admin can at least determine where the user is coming from. Thanks, David Able 18:58, 16 February 2011 (UTC)

Special:Block ? –xenotalk 19:01, 16 February 2011 (UTC)
Just trying to think of ways to retain some users since the numbers have been in decline lately, and the subject of discussion. I guess it would be a last-resort attempt before block. Maybe some of these people just need a little guidance and don't know its available to them. David Able 19:03, 16 February 2011 (UTC)
I agree with xeno. If the user refuses to respond and is editing disruptively, a block is warranted. Once the user responds, the block can be lifted.
In the case of a user repeatedly recreating a page, I've also SALTed the page for a short time. That at least forces the user to choose a new page name, which reaffirms intent to disrupt (or ignorance of his talk page), or brings them into discussion on a talk page.
As for giving guidance and getting the user's attention, the latest revision to the underlying software isn't a help. The new message notice box is now a pale blue instead of the attention-grabbing orange. —C.Fred (talk) 19:06, 16 February 2011 (UTC)
@ Xeno, I am not an admin so I can't see the link you provided...but perhaps a tool like this already exists in some form. David Able 19:07, 16 February 2011 (UTC)
(It's a link to the blocking form) I think a bigger problem affecting retention is administrators blocking before the users have had a chance to respond/resumed editing. If they receive a talk page message and keep up their disruptive behaviour or otherwise do not attend to the message after the orange bar (pale blue?) should have drawn their attention to the message, an attention-getting block strikes me as an appropriate response, and serves the function you've suggested. –xenotalk 19:08, 16 February 2011 (UTC)
I see a lot of the same problem with warnings, xeno. A user makes series of edits and gets warned. A subsequent warning comes in for an edit that preceded the one he got warned for. Suddenly, a user goes from an empty talk page to a level three warning, and they haven't made any intervening edits. I look at time stamps a lot, especially if a user is nearing a block. I won't block them over an edit that they made right after the level 4 warning, because they were probably in the process of hitting save page before or as the warning came in. —C.Fred (talk) 19:14, 16 February 2011 (UTC)

Blocks go in the block log, and require an admin to lift them. I can see the merit in this: the person would effectively be able to unblock themselves by responding on their user talk, and it wouldn't be logged. As a result, it would be a very minor measure which could be used much more liberally than blocking. Rd232 talk 19:09, 16 February 2011 (UTC)

Ok, fair enough. –xenotalk 19:19, 16 February 2011 (UTC)
  • Since we're talking about tools to get a user's attention, it'd be nice to be able to do a user-specific edit notice. So that, if there are warnings they haven't responded to, they get a "Warning! You have not responded to messages on your talk page about your conduct. If you do not respond, and if you continue to make the same inappropriate edits, you may be blocked. Please respond to the comments on your talk page" message inside a bright orange box at the top of the edit screen. —C.Fred (talk) 19:16, 16 February 2011 (UTC)
It should just be an attention getter...gentle prod...a temporary removal of editing privileges with a personable message of concern, and an easy link that directs them to a new section of their talk page to respond. And don't call it a block. Sometimes the language in the escalating warning templates can be downright intimidating. Something like "Hang on a second. I've noticed some problems with your editing that may be breaking the rules of Wikipedia. Why don't you click here, and tell me what you're wanting to do? Once you respond, I'll restore your editing privileges, no harm done." Again, I'm not trying to take the teeth out of a block. This would be a pre-block step to be used when circumstances warrant maybe less of a "bite." Definitely not to be used in all cases. David Able 19:46, 16 February 2011 (UTC)
That's in the same direction, but I think forcing a response is more commonly going to be helpful. They've probably already ignored requests to discuss things. Rd232 talk 01:41, 17 February 2011 (UTC)

Alternative. Change the message bar to red and have it double in size for each talk page message not responded to until it fills his full screen.. Seriously though, I can see how it might be easier for some people to edit articles then talk pages. Some newbies might not even realize that the warnings on their talk pages are something they can respond to. I use to participate in usenet and web forums before Wikipedia and it took me a while to get the hang of talk pages and noticeboards. I wonder if liquid threads might help in this regard. It certainly would make it more obvious that the messages on their talk pages are messages that they can respond to. As far as editors who do know what talk pages are and how to use them, if they still let the warnings pile up (or delete them), show them the door. --Ron Ritzman (talk) 05:24, 17 February 2011 (UTC)

Well that consideration just makes the concept more attractive, because the notification template could include crystal clear "click here" type instructions. Rd232 talk 06:38, 17 February 2011 (UTC)
Perhaps we could add a monobook.css/vector.css to the user to make an input-box appear on any page they use on Wikipedia that would also pose the critical message we want them to read and respond to. They would get this even if not editting. The hard part will be to make it save the answer they may give. As alternative we could even just simply change that light blue background to a blinking orange with the personalised style sheet upgrade!. Graeme Bartlett (talk) 07:53, 17 February 2011 (UTC)
How would you apply it for the target user alone? The saving bit could probably be done the way MediaWiki:Protectedpagetext does the "submit an edit request" thing. How would JS/CSS know to clear the response request though? Rd232 talk 09:07, 17 February 2011 (UTC)
Make it at User:offender/monobook.css or user:22.33.44.55/monobook.css which should only strike the affected user, perhaps there can be some if exists test that will suppress the alert once the response is saved in a talk sub page. Graeme Bartlett (talk) 10:00, 17 February 2011 (UTC)
An excellent idea - I could have used it today. Sometimes you need to block to stop a chain of disruption and discuss the issue with the user, but a traditional block can just make things worse. In this case I discussed the problem with the user, who settled down and was cooperative, and unblocked. It would have been less stinging if we could have a friendlier tool to say "time out while we talk this over," as opposed to a regular block that gets interpreted as "you're banned." In this case the user was in fact communicating, but not particularly constructively until they had to come to a full stop, but a required response might have done a gentler job of breaking the chain of escalation. Acroterion (talk) 20:06, 17 February 2011 (UTC)
I can't see it working for IPs, with all the concerns if another person uses the IP.
Otherwise...the principle, to force a user to respond, might have merit. It's time-centric though; what exactly will happen if they don't respond for hours/days/weeks; and, who will respond to their answer - if the same admin requesting it was around, yes, great; but they might not be. Will their 'quick need for response' potentially languish for days?
I do think it worth discussion though. It could reduce the stigma currently attached to blocks for minor offences by new users.  Chzz  ►  20:26, 17 February 2011 (UTC)
From what I know of the MediaWiki software, it would be possible to design an interface similar to Special:Block that, similar to blocking a user, would prevent them from editing until they edited their talk page, and provide a notice to that effect when they try to edit pages. And yes, it might be worth it, especially in regards to new users as Chzz said. Ajraddatz (Talk) 22:08, 17 February 2011 (UTC)
Ultimately, this whole deal will mean that people will only have to pay attention to warnings issued by admins (or a special group of users), and other warnings can be safely ignored. Not a very convincing idea. Choyoołʼįįhí:Seb az86556 > haneʼ 23:19, 17 February 2011 (UTC)
  • No, lets not do this. It will be abused or misused - at the very least admins will be accused of misuse and abuse. Far better to simply block users if they fail to respond and continue to engage in the unacceptable behaviour that is a concern. After all, if the concerning behaviour isn't worth a block its certainly not worth forcing someone to respond over. Spartaz Humbug! 04:55, 18 February 2011 (UTC)

Allow trusted users to create edit notices

Can we make it so that certain users can create and modify edit notices? They've recently been enabled on every page and namespace. I think there would be a lot of use for them on WikiProjects, where they can direct users to the correct venue, or on the talk pages of controversial articles to state that "Controversial edits to this topic can ignite heated debates, consider discussing your proposed change on the talk page before making an edit".

Either this or we need a new class of trusted users that have more permissions to do basic housekeeping tasks (page moves, editing protected templates, and other things that can be easily remedied if performed incorrectly). I don't want to be, nor do I believe I have the patience or temperament to be an administrator, but I'm requesting their assistance for simple edits several times per day. - ʄɭoʏɗiaɲ τ ¢ 17:20, 17 February 2011 (UTC)

Account creators and administrators can, and I think that it would be good to keep it that way. You are free to request a modification through any user with access to it. Ajraddatz (Talk) 19:39, 17 February 2011 (UTC)
A proliferation of excessive messages can really get annoying. A type of WP:CREEP. Also, edit notices are quick hack-ish.
Regarding the wider matter, there have been various calls for 'unbundling' of various user rights. I'm not necessarily saying it is a bad idea, but just that you should do a bit of a search through WT:RFA e.g. this, and search around a bit for prior discussions - clearly none of which succeeded, thus far.  Chzz  ►  20:33, 17 February 2011 (UTC)
P.S. Your comment of I don't want to be, nor do I believe I have the patience or temperament to be an administrator is understandable, and a good illustration of just what is wrong with the current adminship process. It should be no big deal, and if you, or anyone, has a valid need for those buttons, they should get 'em. If you don't like blocking or whatever else would try your patience, then don't do that stuff. Just 'coz you have buttons does not mean you have to press them.  Chzz  ►  20:37, 17 February 2011 (UTC)
Editnotices don't normally need to be changed often enough than an occasional {{editprotected}} is that big a deal, IMO. Looking through your contribs, Floydian, I don't see where you're asking for admin assistance several times per day. Anomie⚔ 21:50, 17 February 2011 (UTC)
I usually ping them through the IRC channel I frequent because its faster that way, and they're the admins that understand the kind of articles that I'm working on. Add to that various template modifications and the numerous moves I've requested. - ʄɭoʏɗiaɲ τ ¢ 22:05, 17 February 2011 (UTC)

Proposal of General Sanctions on Abortion articles

See WP:ANI#Alternative to Topic block of User:WikiManOne.... General Sanctions on Abortion articles. - Neutralhomer • Talk • 05:35, 18 February 2011 (UTC)

Olive Branch

I wonder if there is currently, or has been in the past, an organized effort to reach out to inactive users, inviting them to return to editing? Among these, retired users...or even users with a history of good editing that were at one time temp blocked for something minor (like edit warring), never to return. I'm thinking of something like a Wiki-pardon. Perhaps an incentive could be the blanking of a block log after a one month return to productive & unproblematic editing. I've seen a lot of good editors who leave WP basically due to a bruised ego, and maybe they just need an olive branch to return. David Able 18:41, 17 February 2011 (UTC)

Maybe we should instead fix the problems that caused them to leave, like the constant biting of newcomers? Ajraddatz (Talk) 05:34, 18 February 2011 (UTC)
I agree. Fixing the problem of biting newbies is much better. - Hydroxonium (H3O+) 03:52, 19 February 2011 (UTC)

2010 census boilerplate

This should be the time to talk about the boilerplate info that will used to plug into geographical articles from the 2010 U.S. Census. Unfortunately, I find that the material from the 2000 census was really very weak in construction and was, I fear, not too helpful to the reader. I don't say this to denigrate anybody's hard work, but to ask for very good preparation for a similar project this year. If you look at Inglewood, California#Population, you will see three ways of treating the census figures: The top example are population figures that have been run through a human brain. The second example is a chart that compares nearby areas, with some explanation (all sourced). The third example is a modified use of the 2000 boilerplate. (It was modified because the boilerplate could simply not be used the way it was.) An unmodified version is, I believe, at Lennox, California#Demographics. I propose that, instead of a one-size-fits-all narrative (as was used for the 2000 figures), we use a chart of some sort that could be easily modified to fit each community. At any rate, we really don't want to end with a one-size-fits-all wording that really does not give the information the reader would be seeking. Sincerely, GeorgeLouis (talk) 00:16, 19 February 2011 (UTC)

See Wikipedia talk:Manual of Style (linking)#Parent–child links.

- dating so this will be archived. Fences&Windows 22:47, 20 February 2011 (UTC)

Article Blame -- a simpler WikiBlame tool

There is a simpler version of the WikiBlame tool, linked as "Revision history search" from a history page; this is called Article Blame, from toolserver.org: http://toolserver.org/~soxred93/blame/ It should be considered whether the simpler tool should also be included in the External Tools section of a history page.

- dating so this will be archived. Fences&Windows 22:48, 20 February 2011 (UTC)

MS Word 2010 compatibility

I'll have to admit, I'm not overly familiar with this side of things, i.e. whether the initiative in such collaborations is taken by Wikimedia or by the other party, but if it is by Wikimedia (in the case of e.g. Wikipedia (en) searches straight from your Google toolbar, or whatever), then it might be an idea to integrate WP into what seems to be the new MS Word's replacement for the 'Synonyms' feature (roughly explained here). It Is Me Here t / c 23:51, 19 February 2011 (UTC)

Broadcast content transcription and verification program

A situation has come up in regards to a TV broadcast and WP:V. The discussion can be found here, but the crux of the problem is how WP:V applies to broadcast content once it is no longer available. In this particular instance, while the BBC archive all their broadcasts, the vast amount of the archives are only available to people involved in the production of the programme (outside of those programmes that are commercially available). The interpretation of the WP:V which we have is that just existing in an archive isn't completely consistent with WP:V, and such archives need some form of public access so that editors can verify content. This is causing a problem for a particular editor who wants to include quotes from a current affairs show that can no longer be accessed by the public.

Since TV/radio broadcasts seem to be the main medium especially for current affairs interviews, it would be a shame if we couldn't use this material, and a policy which is supposed to enhance Wikipedia starts to become a hindrance. I was wondering if initiating a "transcription verification" service might be a way to incorporate the material without compromising WP:V to an unacceptable level. Maybe some form of this already exists? The basic idea would be in a typical interview/debate, a quote (along with the context i.e. such as a question) is fully transcribed for use on a particular article, and two independent editors who haven't edited the article could verify that the transcript is an accurate rendition of the quoted material. In the example of the BBC and this particular problem, the shows are available on iplayer for a week after broadcast, which would allow enough time for the transcription and the verification.

If this idea is a complete no-go I understand, but we have an editor at the discussion who is willing to trial the system if we can try it. Betty Logan (talk) 03:52, 21 February 2011 (UTC)

I took a look at that link, but it's just the one comment. What I'm wondering is who is interpreting WP:V to mean that we can't use TV shows as sources, even when those shows aren't archived? WP:V says, "The principle of verifiability implies nothing about ease of access to sources." Now, I would be comfortable excluding such sources for information about living people under the more stringent sourcing requirements laid out by WP:V. Similarly, if someone is trying to include an incredulous claim based upon "I saw it on BBC News yesterday", WP:REDFLAG ("Exceptional claims require exceptional sources") could also be invoked. And, of course, it would be better to have a print source if one were available. But, all of that being said, I don't believe WP:V can be read to generally state that un-archived television programs cannot be used as sources. Is this being discussed somewhere else? Qwyrxian (talk) 00:40, 23 February 2011 (UTC)

Proposal to Acquire a Professional Musopen Account for Wikipedia

Discussion at Portal talk:Featured sounds/Musopen. Sven Manguard Wha? 08:02, 22 February 2011 (UTC)

Archive Protection

I got an idea of having an new type of protection on archived pages that is not supposed to be edited like RfA. The protection makes no one can edit it. Maybe that when bureaucrats approve or rejects the request, it automatically protects the page.

~~Awsome EBE123~~(talk | Contribs) 12:58, 22 February 2011 (UTC)

Is there currently a problem with vandalism on the RfA archive pages? If not, then what is the point of protecting them. Yoenit (talk) 13:21, 22 February 2011 (UTC)
Although probably unnecessary, and technically not worth the trouble of implementing, It's still not a bad idea: There's no reason anyone should be editing those pages anyway, and in the off-chance that they do get vandalized, and I can see that happening as someone wanting 'revenge' on an admin for some past block, it's possible that the vandalism can go uncaught for a long time, especially if the admin is inactive, as presumably noone other than the admin would have that page on their watchlist. -- Ϫ 18:42, 22 February 2011 (UTC)
As there is always the possibility of unforeseen future reasons to edit closed RfAs, I don't think it's necessary to preemptively protect them. –xenotalk 18:49, 22 February 2011 (UTC)

Basically wrapping everything (articles, watchlists, special pages, etc... in <div class="plainlinks">. This icons can be annoying to those of us who are fine with the difference in tone as the only way to tell internal apart external links. Headbomb {talk / contribs / physics / books} 00:18, 23 February 2011 (UTC)

Try adding this to your skin.css:
a.external {
    background:none !important;
    padding:0 !important;
}
That could probably be turned into a gadget, if there were sufficient demand. Anomie⚔ 01:59, 23 February 2011 (UTC)

I'm not sure what the proposer means. Are there external links icons? Where? GeorgeLouis (talk) 03:44, 23 February 2011 (UTC)

the arrow in the box to the right of this text is what he's talking about. Sven Manguard Wha? 04:22, 23 February 2011 (UTC)

A-class

How about a top icon for A-class articles? I made a template already. It's at Template:Class A article.

~~Awsome EBE123~~(talk | Contribs) 12:51, 22 February 2011 (UTC)

GA and FA are wikipedia-wide standards while A-class is wikiproject specific. Not all wikiprojects use A-class and if one wikiproject makes an article A-class that does not mean it is an A-class for another wikiproject. For example Thinis is assesed as A-class for Wikipedia:WikiProject Ancient Egypt, while Wikipedia:WikiProject Former countries considers it only B-class. Yoenit (talk) 13:17, 22 February 2011 (UTC)
I'm not a big fan of the idea. Actually, I'm not a big fan of the GA top icon either. For the casual Wikipedia reader, I think the multiple icons are confusing because their meaning is not that obvious. In particular, the fact that a good article is "not as good" as an A-class article but "better" than a B-class article is somewhat counter-intuitive. Furthermore, the process that identifies A-class articles is not transparent. For the avid Wikipedia reader/editor, there's always the possibility to set the preferences to include the user interface gadget that automatically displays the assessment. I highly recommend it if you're not already using it. Pichpich (talk) 13:21, 22 February 2011 (UTC)
This whole classification reeks of subjectivity. I suggest the "EmmanuelM index" for article greatness, which is the ratio of total visits / number of edits, both over the last 30 days. In other words, a great article is an article that many people read but few find something that needs to be corrected. Emmanuelm (talk) 20:02, 22 February 2011 (UTC)
Speaking from WP:PRIMATES, some of the articles in our top 25 for hits get very few edits, but are in really crappy condition. Monkey and Slow loris quickly come to mind (although we have a collaboration slowly working on the latter at the moment). – VisionHolder « talk » 21:25, 22 February 2011 (UTC)

I was going to propose this and I think it's personally an awesome idea, but we need to standardize this site-wide first before we can really make progress with this proposal. Kevin Rutherford (talk) 06:19, 24 February 2011 (UTC)

Main page redesign

A proposal to add Featured sounds to the mainpage was put forward on February 15. An additional proposal to add Featured lists was added on February 23. Together, these two proposals involve a redesign of the main page, under discussion. SandyGeorgia (Talk) 03:57, 24 February 2011 (UTC)

Wikipedia's Most Wanted (Pages)

I think Wikipedia has progressed far enough that it's faults are becoming more apparent. It seems that recently (the last two years or so), community work has been focused on the nuances of existing policy, rather than the less functional aspects of the wiki model. Basically, given enough time, wikipedia will eventually have generated articles on all subjects. However, this model suffers from the fact that people find some stuff more interesting than other stuff, and the extremely popular subjects are basically exhausted in terms of new articles. This leads me to think that for the wiki to become more well rounded, the areas of missing content should be addressed.

It seems that about a year ago, the process that generated pages on Special:WantedPages was sabotoged by a new mode of editing, where redlinks get added to templates. Because of this, links to missing pages got disproportionately measured, since any article added to a popular template would make it seem highly requested, while articles only redlinked in mainspace text would be easily missed. There is also Wikipedia:Most wanted articles, which was created using a database dump in 2007. This page only includes links from mainspace articles, not templates. This circumvents the problem generated by Special:WantedPages, but there is no automated updates or removals to this process.

There are two other processes worth mentioning: Wikipedia:WikiProject Missing encyclopedic articles, which is a project geared to create articles that have been identified as missing through a variety of other sources. There is also Wikipedia:Requested articles where users can add red links to the subject-based lists.

Basically I am looking for ideas. I guess there's two issues, methods of discovering missing articles and methods of creating missing articles. I think this is the sort of problem that would be served well by applying the original goals and ideals the wiki, since when it started out there was a great deal of interest and momentum in article creation. As things are right now, there are huge gaps in certain areas, and this is a community issue. What are your thoughts? --NickPenguin(contribs) 00:54, 22 February 2011 (UTC)

Not really an answer to your questions but: aren't red links still strongly discouraged in templates? That's what Wikipedia:Red link says. Pichpich (talk) 01:16, 22 February 2011 (UTC)
Not always - "The exception is redlinks in navboxes where the articles are part of a series or a whole set ..." - which fits most of the large templates which have been the issue here. Shimgray | talk | 03:07, 25 February 2011 (UTC)

Number of hits per article

It's too late to start over, but I always wonder when I read an article how many others have read before me. It would be interesting to me to see how many hits each article has had. Wouldn't Wikipedia administrators as well as users like to have some idea of this?

Just a suggestion.

Thanks for reading.

An external counter for page view statistics is linked under the page history tab - it's on a daily basis rather than "for all time", but it should be more or less what you're looking for. Shimgray | talk | 20:02, 23 February 2011 (UTC)
You click on "History" and then you click on "Page View Statistics." Sincerely, GeorgeLouis (talk) 20:03, 23 February 2011 (UTC)
A fresh install of MediaWiki still has counters for total page hits at the bottom of every page (mw:Manual:$wgDisableCounters). However, this feature was disabled on Wikipedia many years ago, so it looks like admins didn't like it. --Morn (talk) 00:47, 24 February 2011 (UTC)
I believe it's disabled because it doesn't count pageviews that are served by the caches, just the ones that make it through to the apache servers. And since we want as many hits as possible to be served by the caches, it's basically useless here. Anomie⚔ 01:52, 24 February 2011 (UTC)
There's also the fact that, as I understand it, MediaWiki itself doing the hit counts is quite inefficient. Whilst it's theoretically capable of it, enabling the function on a system with this much traffic could have rather messy effects, since it has to update a record every time a page is hit. Even without the caches, it would still be more efficient to use the "secondary" counting via logs. Shimgray | talk | 02:07, 24 February 2011 (UTC)
True, cache hits aren't counted, so enabling the stock MedaWiki feature wouln't help. Then again, a nightly job could be set up to analyze the logs like stats.grok.se does and add total daily hits per article to the database. I don't think it's a technical or performance issue. It's more due to lack of interest on the admin side that this feature never came back to Wikipedia. --Morn (talk) 11:49, 24 February 2011 (UTC)


Click on the "History" bar at the top of each article, and then find the icon that says "Page view statistics". Click on that - I think that that will give you the information which you have been seeking. ACEOREVIVED (talk) 19:56, 24 February 2011 (UTC)

He's looking for total hits, not hits per day. --Morn (talk) 22:53, 25 February 2011 (UTC)
You can get a good idea by adding all the years' data together. http://stats.grok.se/en/2011/User:Killiondude/stats + http://stats.grok.se/en/2010/User:Killiondude/stats etc. etc. stats.groke.se appears to list things from 2008 and onward, but see User:Killiondude/stats about locating its source data and for links to the internet archive's copy of even older data. Killiondude (talk) 23:06, 25 February 2011 (UTC)

[technical] Wikipedia after 10 years: sharing informations - step two

Hi all, my name is Paolo.

First of all: sorry for my bad english language :)

Next, right to the subject: I really appreciate what Wikipedia gives to me everyday and I would like to return to it a little bit.

I think this idea could lead to:

a) significantly lower the storage costs of the immense wikipedia mass of data while exponentially increasing available space;

b) boost the wikipedia speed;

c) involve all us, as users, in a new higher grade of collaboration;


My idea simply consists into developing and issuing a software through which we all can share a little percentage of Hard disk space on our internet-connected home computers, just like p2p philosophy, and following the example of SETI @ HOME project, in order to host some encrypted datas of wikipedia which will be managed only by the original website

I will not annoy you with all the technical details I have thought of, because I would like before to know your opinion about this proposal...and for sure there are many other people who are better than me for this :)


Wishing to help you improving wikipedia...

Regards,

--94.163.7.8 (talk) 08:28, 24 February 2011 (UTC) Paolo Bianchi e-mail: bianpaol @ gmail . com

Well, SETI@HOME doens;t share disk space: It only uses your computer's processor to process data. SETI's data is run through many different algorithms, and this requires a lot of RAM. It wouldn't be a good idea to implement this on Wikipedia, as we don't need that much processing. It would require as much RAM to send the data requiring processing and the algorithm to a computer as it would to do the job itself. Wikipedia requires fast results, which would be slowed down if the data was sent to another computer for processing every time you used the search suggestions or something similar. All of Wikipedia's processing is related to messing around with the database, so a user's computer can't help anyways. ManishEarthTalk • Stalk 12:45, 24 February 2011 (UTC)
I'm sorry, but this does not seem like a good idea for a number of reasons. First of all, Wikipedia has a massive and very complicated network architecture, and this type of change would require it to be completely redone. Second it poses major security risks, as anyone with direct access to the servers and enough technical knowledge can get into places they shouldn't by simply circumventing any web interface based security features. Third, it would only be possible if the volunteer computers were always on and always connected to the internet, something Wikipedia can't ensure. Fourth, if something does go wrong, having the servers all in a limited number of places allows for more efficient repairs and less downtime. Finally, for legal reasons, Wikipedia keeps servers in some places and explicitly out of others. If a single person from New York donated part of her computer as a server, it would open Wikipedia up to New York's very restrictive laws on musical recordings, and Commons would have delete about a third of its repository of sound files. Likewise if a single person from another country opted in, it would have legal and tax ramifications.
Simply put, if you want to help Wikipedia with it's storage needs, ask them for a wishlist and buy them hardware off the wishlist (or send them money earmarked for said hardware so that you save on shipping.) Sure a server is expensive, but there are likely other things they could use too, and everyone likes donating tangible items. Sven Manguard Wha? 16:47, 24 February 2011 (UTC)
Storage is cheap, it's constantly getting cheaper, and text does not take much space to store. The cost to develop and implement a system like this would probably offset any savings in storage costs for years. Mr.Z-man 21:48, 25 February 2011 (UTC)

Extension:ArticleEmblems and Top Icons

Extension:ArticleEmblems was designed and developed to handle top icons properly (Bug 23796) without some of the css hacks we need, I propose we actually use it. Peachey88 (T · C) 06:58, 25 February 2011 (UTC)

Has it been reviewed yet ? Unreviewed code cannot be deployed (I know it's on Roan's list for the coming weeks, just like the new Narayam and a few other extensions, but as far as I know, it has not yet been done at this exact time) —TheDJ (talk • contribs) 08:39, 25 February 2011 (UTC)
Extentions don't really get reviewed unless somewhere (a community) requests that it be activated to avoid pointless requests, which is why I'm trying to gain consensus first. 09:08, 25 February 2011 (UTC) — Preceding unsigned comment added by Peachey88 (talk • contribs)
(More specifically, extensions don't get reviewed unless a sufficiently large community requests it, otherwise it just sits around for years while all the code reviewing gets done for the big projects. Grumble grumble...) Does this extension actually solve any real problem, or is it just a more elegant solution to something already been dealt with by CSS? --Yair rand (talk) 11:24, 25 February 2011 (UTC)

Permanent Preservation

This will sound like a bit of a silly/stupid idea, but as an archaeologist, I know that pretty much the only histories we have ancient cultures other than oral histories and papyri are those written on (accidently baked) clay tablets and stone (and a few other anecdotal instances of other materials.) Paper degrades and so do disks and all manner of digital storage. So I was thinking wouldn't it be fun if at some point the articles (after review of course) in Wikipedia were copied down onto either hard durable plastic or some manner of stainless steel tablet? Something that would never degrade and even if somehow civilisation was wiped out completely, the archaeologists of the future would have an abundance of information from this era and our knowledge and cultures would be preserved. After all, the cultures for whom we have no histories are pretty much lost to history.

I can just imagine the caches being found in the distant future and whoever finds them saying "Ah Ha!" and finding out all the old stories and whacky theories about this time and earlier are true! Full records of our global civilisation with its many peoples, languages, musics, foods, dances, etc.

Silly I know, not to mention expensive and time-consuming. However it would be nice if this could be done. I would love to see projects like this in maybe a decade when the other languages have caught up to the English wiki. It would be a marvelous thing if people in many different nations raised money for this sort of thing and everyone contributed to the preservation of their collected knowledge in their own tongues (no sense just preserve the English Wikipedia.

Just a thought.... =) TheArchaeologist 06:36, 24 February 2011 (UTC)

The idea had been kicked about a bit. Metal has too high a scrap value and plastic degrades on exposure to sunlight. Best suggestion I've run across is probably to stamp extracts of wikipedia articles into bricks (and then use them for normal construction.©Geni 01:45, 25 February 2011 (UTC)
We could put it on a solid gold CD and shoot it into space. (Please someone get the reference.) Sven Manguard Wha? 03:56, 25 February 2011 (UTC)
Yes, yes, haha, very funny. =p You two laugh, but a lot of people, when they really really think about it, are at the very least a little uneasy with the idea that if our civilisation just ceased to be tomorrow, then there would be nearly nothing left of us (our modern civilisation) in a thousand years (if you believe the History Channel, which is typically not good practice I will admit) except from some plastic cases, of course garbage dumps (archaeological gold mines) and apparently the Hoover Dam. (yes I do overuse commas)
Looking at what you said as jokes seriously though (time to kill the jokes >:3), the scrap value thing assumes that stainless steel would still be valued at that time and they wouldn't have something better that they use for their main metal (like some manner of cheaply produced titanium or some other metal) and the idea of a cache is that usually it is in a vault of some sort or buried (in a vault in this case), and I don't think many plastics degrade on immediate contact with sunlight, it also depends on the type of plastic you use (in this case, not one of the eco-friendly ones that degrades quickly). Even then, it's not like if the vault is exposed for study that its contents would degrade anytime soon. They might be stolen and sold, yes, but not degraded for a long time.
Yep, Voyager 1 and Voyager 2. I think Futurama helped a few more of the younger generation get that reference (though I read many Astro books when I was a kid (21 atm)). There was a recent little Finnish film (which I cannot find or remember the name of) actually where one of the Voyagers (I think it was 2) crashes and this odd man and his alien dog (don't ask, I didn't get that bit) play it and then build a rocket to go to Earth. They find nothing there but an old man and a bar with a computer that has a short video history, nothing else.
It would be nice if someone financed a project similar to this at some point. If not with wiki then maybe Britanica or Encarta (though they are very limited) TheArchaeologist Say Herro 04:29, 25 February 2011 (UTC)
Well the closest I'm aware of is the Long Now Foundation's Rosetta Project.©Geni 18:55, 25 February 2011 (UTC)
If it's good enough for Scientology, it's good enough for us: "The archiving project, which the church has acknowledged, includes engraving Hubbard's writings on stainless steel tablets and encasing them in titanium capsules."[4] Fences&Windows 19:21, 26 February 2011 (UTC)
Well the disk is a start, but I don't like the fact that it will eventually degrade. =/ Ugh, I for one hope THOSE tablets stay buried or are destroyed. Godforbid whoever the later archaeologists are find those and think that it was a major religion or part of our culture. See they have the right idea though, even if they are basically preserving what is in my opinion (don't want the CoS to sue) garbage. TheArchaeologist Say Herro 03:35, 27 February 2011 (UTC)

My Brilliant Idea

I have no clue if this has been discussed before, or if there's a reason why it hasn't been done but I think that in order to edit Wikipedia, you must create in account or login. No more anonymous IP edits. Wouldn't this greatly cut down on vandalism? If you have something constructive to add, you can easily sign up. Others will be discouraged from adding nonconstructive things. It seems like it would work to me. ~ Richmond96 t • c 23:50, 27 February 2011 (UTC)

See Wikipedia:Perennial proposals#Prohibit anonymous users from editing MBelgrano (talk) 00:00, 28 February 2011 (UTC)
Ok, thanks. I see the reasons for the current method, now. ~ Richmond96 t • c 03:26, 28 February 2011 (UTC)

Template

One thing I think would help improve the ol' Wikipedia is to have a little template appearing at the top of the page saying you have new messages on your talk page whenever you do have new messages. Of course, it would have to be done so that it doesn't appear on every single page to everyone, just to those who have new messages on their talk pages. Maybe have it say something like this:

You have new messages

Just have it be as simple as possible, and have "new messages" link to whichever user's talk page. Besides, just about every other Wiki I've been to has this feature, why not Wikipedia? --Codyrox (talk) 01:24, 25 February 2011 (UTC)

Well, I would edit as "Thebigfan" but I seem to have forgotten what my password was to get on it. --Codyrox (talk) 18:35, 25 February 2011 (UTC)

Can't you just request the password be sent to your email address? Otherwise, redirect User:Thebigfan to User:Thebigfan2, and get on with editing, problem solved. You already use the totally unrelated "Codyrox" in your sig so there's no reason to be wedded to the Thebigfan account. Fences&Windows 23:58, 28 February 2011 (UTC)

WP:Notability (video games)

Posting here as there it seems we have a final draft before this gets promoted. This is based on the GNG, WP:VG/GL and common practices, If anyone has any comments please feel free to discuss them there.陣内Jinnai 22:40, 28 February 2011 (UTC)

Purge dropdown change to purge tab

I would like the purge dropdown to change to a tab, as it's easier. --Highspeedrailguy (talk) 16:22, 28 February 2011 (UTC)

Alternatively, we could change the personal toolbar purge clock in preference → gadgets tab → User interface gadgets, into a default and have its removal available through preferences.--Fuhghettaboutit (talk) 16:30, 28 February 2011 (UTC)
Please don't. Anomie⚔ 22:42, 28 February 2011 (UTC)
Purging is a fairly rare need. I'm sure someone could write a gadget to add a tab for it though. --Cybercobra (talk) 02:28, 1 March 2011 (UTC)
See User:Svick/DropDownToTabs.js. — Edokter (talk) — 18:03, 1 March 2011 (UTC)

Template:Worldcat

I wish to add more functionality to the current Template:Worldcat. I have created a proposed version as well as described the new usage on the talk page. Basically the proposed idea is to add a new parameter OCLC for entries that do not have an Identity ID; as well as adding an accessdate parameter to be shown when it was retrieved. The new code will check if you are using either the ID or OCLC parameters and provide a warning otherwise. The current usage would be unaffected for any article already using the ID param, new usage below: 

{{Worldcat|name=Test|oclc=222395773|accessdate=March 2011}} would produce:
Test in libraries (WorldCat catalog). Retrieved on March 2011.

similarly: 

* {{Worldcat|name=Test|id=lccn-n50-34079|accessdate=March 2011}} would produce:
Test in libraries (WorldCat catalog). Retrieved on March 2011.

Please feel free to view and edit my proposed version to better refine it, or offer any suggestions. Thank you. Who (talk) 23:08, 1 March 2011 (UTC)

Allowing more users to use huggle

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.
No consensus. Mono (talk) 01:34, 7 March 2011 (UTC)

Huggle is an antivandalism utility which is used also on english wp, as I couldn't find any policy which says that rollback is the requirement for usage of the tool I think it would be great to allow less strict requirements, it's easy to disallow a person from being able to use it and I see no particular reason for requiring a rollback, so I think it would be good to change the requirements to autoconfirmed + other requirement, edit count and so, what do you think? :) I think easiest way would be some sort of poll whether allow people or not, so if you want you can support or oppose this idea with comment why or how would you change it. Petrb (talk) 19:48, 1 March 2011 (UTC)

Agree (support)

  1. yes 250 edits and account age 10 days, Petrb (talk) 19:48, 1 March 2011 (UTC)

Disagree

  1. no, most users need more than 10 days to figure out the difference between vandalism and content disputes. --SarekOfVulcan (talk) 20:40, 1 March 2011 (UTC)
  2. Strongly oppose If somebody is not yet capable enough to handle rollback they should definitely not be allowed to handle Huggle. I would in fact support a proposition to raise Twinkle to the same bar. Yoenit (talk) 20:43, 1 March 2011 (UTC)
  3. No Huggle induce false positives and induce "stress" as user start to compete with one another to revert the vandalism. This induce more errors. --Tyw7  (☎ Contact me! • Contributions)   Changing the world one edit at a time! 21:31, 1 March 2011 (UTC)
  4. Oppose, to me there is a significant difference between rollback and autoconfirmed. Rollback is granted by a human being, and that ensures that at least some check is done on the potential rollbacker/huggler. In the case of autoconfirmed, no one can be sure the candidate for huggle has been noticed before and that he is trustworthy. [[CharlieEchoTango]] 21:33, 1 March 2011 (UTC)
  5. Oppose. Users granted rollback most likely know what they're doing when it comes to anti-vandalism. New users might not. Guoguo12--Talk--  21:44, 1 March 2011 (UTC)
  6. Oppose. Just because Huggle doesn't require rollback rights doesn't mean that there isn't a reason behind that restriction for using it. Not all autoconfirmed users can be trusted with this tool, and having rollback shows that the user is capable of using Huggle properly. Logan Talk Contributions 23:09, 1 March 2011 (UTC)
  7. Oppose. Far to easy to revert in Huggle, for someone who might not understand exactly what we call vandalism. A reasonable bit of anti-vandalism with Twinkle will show that the user is competent to have the right, it not that there's a huge waiting list of rollback applicants.  Ronhjones  (Talk) 23:22, 1 March 2011 (UTC)
  8. Oppose - I have seen editors who were rollbackers and still had problems using Huggle responsibly. The minimum requirements for Huggle should be rollbacker. ~~ GB fan ~~ 23:50, 1 March 2011 (UTC)
  9. Oppose in agreement with Yoenit and GB fan. I have both rollback and reviewer and I don't think I should be using Huggle. – Allen4names 03:36, 2 March 2011 (UTC)
  10. Strong oppose There are indeed many rollbackers who use huggle incorrectly, let alone those who aren't proven vandal fighters. Huggle essentially performs the same task as rollbacking, so opening it up would render the entire rollbacker user group obsolete, in favor of a much more dangerous tool. No way. Swarm X 03:40, 2 March 2011 (UTC)
  11. Strong oppose - I'd support the complete removal of huggle. In my opinion, countervandalism should be done in the traditional environment - examining diffs. As it is, countervandalism has turned into some sort of a game, and allowing more users to play is not a good thing. Ajraddatz (Talk) 04:47, 2 March 2011 (UTC)
  12. Oppose Huggle can be quite dangerous if used inappropriately. Rollbackers have been checked (a tiny bit, but still) by a human. We already have problems with users reverting wrongly. Countervandalism has become a game (This is not completely bad), and it'll be dangerous if newbies decide to join. ManishEarthTalk • Stalk 12:00, 2 March 2011 (UTC)
  13. Oppose there's a lot of abuse of rollbacker-only tools; NO WAY! --Posted on 17:34 on 2 March in 2011 (UTC) by Highspeedrailguy 17:34, 2 March 2011 (UTC)
  14. Oppose per my statements in the comments section.--Cube lurker (talk) 17:44, 2 March 2011 (UTC)
  15. Oppose There is way too much roboticization on Wikipedia. The usertalk templates are worst, but these scripts are a bad problem too. I'll stop short of wanting to eliminate them completely, but they should have fewer users, not more. 71.141.88.54 (talk) 01:22, 3 March 2011 (UTC)
  16. Oppose Huggle should be at the same level of trust as AWB, a high level that is proportional to the high level of damage that is possible to inflict if the tool is improperly used. Sven Manguard Wha? 07:06, 3 March 2011 (UTC)
  17. We have too many incompetent people reverting good edits already. /ƒETCHCOMMS/ 15:49, 4 March 2011 (UTC)

Discussion

  • Though I'm not entirely sure on this, I think having rollback is also a technical requirement, as huggle uses the rollback facility when reverting. –xenotalk 20:04, 1 March 2011 (UTC)
No it isn't. Petrb (talk) 20:06, 1 March 2011 (UTC)
Yes, I edit conflicted with you trying to remove my comment. –xenotalk 20:23, 1 March 2011 (UTC)
So what is the technical requirement? If there aren't any, then what are we even discussing?--Kotniski (talk) 07:15, 2 March 2011 (UTC)
Huggle uses the API's rollback feature. It could just as well use "undo", but there's no undo feature in the API. To undo, Huggle would have to fetch the previous revision's revid, then the wikitext of that revision, and finally reupload the whole wikitext to the page. This makes it a bit slower, and less efficient. ManishEarthTalk • Stalk 11:48, 2 March 2011 (UTC)
So in fact you do have to have rollback enabled in order to use Huggle?--Kotniski (talk) 17:57, 2 March 2011 (UTC)
Yup. Though theoretically, Huggle can go without it, but it'd require a small change by the devs. ManishEarthTalk • Stalk 08:46, 3 March 2011 (UTC)
So (moot as the question is, since it seems to have been soundly rejected), the proposal would actually simply mean giving the rollback privilege to a greater number of users?--Kotniski (talk) 16:58, 4 March 2011 (UTC)
  • Why should we feel confident that a new user with that little experience will be able to tell the difference between vandalism and good faith unproductive edits?--Cube lurker (talk) 20:27, 1 March 2011 (UTC)
Indeed somehow I agree with you, perhaps inceasing the requirements a bit? There are many users who use twinkle and are not rollbackers and many others who can constructively help with vandalism anyway huggle is a tool only people familiar with that know. Petrb (talk) 20:40, 1 March 2011 (UTC)
Have you read the signpost from today? Wikipedia:Wikipedia_Signpost/2011-02-28/News_and_notes. Yoenit (talk) 20:44, 1 March 2011 (UTC)
The only way to 'learn' Huggle is to use it, and it's the responsibility of any editor who sees someone using it incorrectly to correct them. I've done it several times and the users have been apologetic and eager to fix and learn from their mistakes. It's all part of learning. Swarm X 03:47, 2 March 2011 (UTC)
Actually I strongly disagree with this. There is a serious foundation of policy knowledge that's required (or damn well should be) before you even touch huggle. It comes from manually reverting vandalism. Manually choosing and applying proper templates. Learning to take a look at the edit and ask yourself, is it vandalism? a new user who doesn't understand policy? a good faith edit that accidentaly broke formatting? or any of the other types of edits that all need to be handled differently.--Cube lurker (talk) 17:43, 2 March 2011 (UTC)
Considering I'm in complete agreement with that statement, I have a hard time seeing where the "strongly disagree with this" comes in. Swarm X 23:39, 2 March 2011 (UTC)
I'm most likely misreading your comment. I was reading The only way to 'learn' Huggle is to use it as dive in with huggle and learn policy as you go, where I was focusing on getting a foundation in policy then move to huggle. Appologies for misunderstanding.--Cube lurker (talk) 15:59, 4 March 2011 (UTC)

Oh, no problem. Let me try to clarify. I was replying to Petrb, who suggested increasing the requirements to use huggle because getting the rollback right doesn't automatically make you competent to use Huggle. My point was that if you've been granted rollback, you've presumably shown that you can responsibly identify and revert vandalism, and you should be trusted to use Huggle. At that point, the only way you can learn it is to use it; further increasing the requirements won't help anything. So yeah, I was only talking in the context of rollbackers; I didn't mean to imply that anyone should be able to use Huggle to learn by experience. Hope that cleared up my comment. Swarm X 16:55, 4 March 2011 (UTC)

Got it. That sounds reasonable. Think we're both ont he same page.--Cube lurker (talk) 16:59, 4 March 2011 (UTC)
  • Comment I stopped by this page because I just noticed I no longer have "undo" buttons, and am wondering what happened. Maybe I'll find some discussion someplace, but it doesn't seem like a useful removal. 71.141.88.54 (talk) 01:23, 3 March 2011 (UTC)
    • Wikipedia is changing over it's code base from whatever it was before to the mw:API, which is HTML5 compatible. I read above that there is no undo feature in the API, which explains why the undo button is gone. Personally I didn't notice that, but if you say it's gone, it might be. Someone with actual technical knowledge could/should probably give you a better answer. Sven Manguard Wha? 01:53, 3 March 2011 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

A place for more proposals

Hey, everyone. This isn't a proposal itself per se, but I wanted to drop a note here to point out a new place where fully-formed proposals that have some community support can be taken if they need help from the Wikimedia Foundation. Some of you know that the WMF started a fellowship program for Wikipedians, academics, and others to come join the organization for a limited time to work on a specific project or projects (that's my job). Well, now there's an open proposals process for new fellowships on Meta, so please consider it when you're thinking about the future of Wikimedia and moving your proposals for improving English Wikipedia forward. Thanks! Steven Walling at work 23:51, 7 March 2011 (UTC)

Use bots to maintain census figures

Bots can be used to maintain census figures.

Editors may construct initial text templates which would be locked. These would be incorporated into the text of the place article. Editors would present the template for incorporation into the list of templates a bot would maintain. A separate "acceptance" bot would be needed to accept and file the template.

When the bot was run, and found material that needed to be updated, it would unlock the template, make changes in some pre-specified manner, and relock the template.

No one else would make any census changes in the US. There would be a separate country-bot (and acceptance bot!) for each country since they each present material differently. But they would probably resemble the US one in construction and updating. — Preceding unsigned comment added by Student7 (talk • contribs) 17:54, 28 February 2011 (UTC)

I'm not sure what this means. I do know, however, that the boilerplate used for census figures in the U.S. articles is simply appalling. Sincerely, your friend, GeorgeLouis (talk) 20:25, 28 February 2011 (UTC)
While the editors of the article would still construct the text (template presentation; layout) for the article, I would guess that the templates would become more standardized. But yes, the words "spread out" for age groups, particularly appalled me. But these would be decided in advance (as the 2000 census were, only by a much smaller group, and for everyplace in the US) and would usually not be as clunky, having had the input of several people for each article. Student7 (talk) 13:04, 1 March 2011 (UTC)
I'm with GeorgeLouis. The text in thousands of US-related articles from the last (2000) census are pretty appalling. Moreover, the information being claimed to be so in those thousands of articles was nearly always without any sort of an inline citation that would have made the claim be easily verifiable to the casual reader of Wikipedia. In my view, Wikipedia can do better, and we should. N2e (talk) 13:40, 1 March 2011 (UTC)
I'm in full agreement about the need for a change in the boilerplate. Even after reading and editing scores of articles on US communities, that phrase "the population was spread out" always makes me think of population density. The organization of the age-distribution paragraph could also be improved: I think that it ought to begin with the single summarizing statistic, viz., the median age; after that, we can elaborate on the distribution. --Ammodramus (talk) 23:23, 1 March 2011 (UTC)
The boilerplate could be addressed with this change. The bot (and bot handlers) would have the responsibility of ensuring the material was properly footnoted. This would most likely be in the boilerplate template - the same place for everybody. I am assuming a centralized census bureau, as in the US, and, in fact, aiming this at the US which would most likely be first to be implemented.
So, step one, could be the construction of a recommended text template. There is no reason we could not start work on one now. On the other hand, there is no reason why anyone must use this exact boilerplate, but we might build into the "acceptance bot" criteria for a basic template. That is, the US template must contain age distribution, economic data, the valid footnote, etc. No point in using the bot without census-relevant data. Student7 (talk) 13:53, 2 March 2011 (UTC)
I concur; the work on the boilerplate could start anytime. And if we could build consensus about that boilerplate text, including the specific {{full}} citation(s) (linkable to the particular place in the Census Bureau online data repository that supports the specific claim for any particular Wikipedia page, along with the date of the data and the date that the bot accessed the database) that would support the quantitative assertions, then the bot gurus could later use it and turn a bot loose on adding the text to applicable pages based on the data in the Census report. If anyone starts this, feel free to drop me a line and I'll try to join the effort. Cheers. N2e (talk) 19:20, 2 March 2011 (UTC)
For the record, a current (or near-future) boilerplate, might have "...White = 44.6%..." as a part of its text. The distant future template, might have, for the same information, "((uscensus|white=}}" and be absolutely riddled with this type of template invocation.
My idea of boilerplate is dry facts, no embellishment. Just looked up Demographics of New York City. Quite embellished. Editors would still be free to have any template they wanted, including embellishments. But the one we come up with would be dry as toast, right? Student7 (talk) 18:35, 3 March 2011 (UTC)
I support the idea of using a bot to update the numbers but...good luck. I don't have much faith in the bot group these days and from what I have seen if you submit the bot task today it will be summertime before it gets approved and by then we could have fixed the majority of them manually. I would recommend working with the US WikiProjects in a Census drive to fix the problems. You will probably have better results. --Kumioko (talk) 19:06, 3 March 2011 (UTC)
I was rather hoping for census data to be maintained centrally. Right now we get annual updates (if we are lucky) or monthly or more frequent ones with someone "finding" another guesstimate on their local population increase. Always increase, of course. The idea here is to control format, then release figure updates to the bot. The bot unlocks the template for updating once a year with the official census guesstimates, then locks them again. No changes unless approved.
Our problem in the past has been to figure out when someone is legitimately updating and when some newbie IP is simply vandalizing by altering a few numbers at random. Usually they get reverted (with no edit summary)! But it is a nuisance to have to even worry about it. And unnecessary IMO. Student7 (talk) 13:29, 4 March 2011 (UTC)
I support the idea of a managed bot, opened only occasionally (annually?) to put in basic non-embellished "dry facts" from the census data, with simple boilerplate of the type suggested by Student7. I would just like to ensure that whatever comes out of this effort does not do it (as was done after the 2000 census) with unsourced bot entries. There ought to be a (hopefully, bot-generated) citation to a specific online-available part of the census database that would reliably source the claims made. In the case you mentioned, it might be "...White = 44.6%...<ref name=uscb20yymmdd> {{cite web |title=Census 2010 Database |url=http://www.LinkGoesHereForCensusDB.gov |work=United States 2010 decenial census |publisher=US Census Bureau |accessdate=20yy-mm-dd<!-- date the bot consulted the database to obtain the data -->}}</ref>" as a part of its text, but with a citation. We should not turn a bot loose that adds a lot of text to articles that is difficult to verify, as was done after the 2000 census. Cheers. N2e (talk) 14:22, 4 March 2011 (UTC)
Agree.
Having said that, I've put a possible boilerplate for census data on Wikipedia_talk:WikiProject_United_States/proposed census boilerplate. Not sure there were citations there when I copied it!
Note that we will change and discuss changes on the same page.
Feel free to notify other interested editors/Projects. I've put a notice on the US Project discussion page. Student7 (talk) 19:25, 5 March 2011 (UTC)
Small problem. How do I request a bot? Student7 (talk) 13:08, 8 March 2011 (UTC)

Proposed layout change for "Deletion sorting" notes in XfDs

The current layout renders {{Deletion sorting}} notes on XfD pages similarly to the !votes cast. This makes XfD pages harder to understand. I propose changing the layout so that notes are more clearly separated from !votes, using a colon to generate an indented list item without a bullet, and eliminating the bold formatting of the word "Note". A mock-up is shown below. - Pointillist (talk) 12:56, 7 March 2011 (UTC)

Note: This debate has not been included in any list. Can you believe that?
  • Support – looks like an improvement to me. Also makes the delsort messages actually easier to spot, for the same reason – now they look too similar to the !votes.  --Lambiam 18:19, 7 March 2011 (UTC)

For the record: the proposal has been boldly implemented.  --Lambiam 13:26, 8 March 2011 (UTC)

Up to a point... Mono made the change for Template:Deletion sorting, but there are about fifteen other templates in Category:Deletion notification templates that use the old look, AFAICS. - Pointillist (talk) 19:00, 8 March 2011 (UTC)
Thanks for following up. I was going to leave it until there was a consensus for the change! - Pointillist (talk) 00:24, 9 March 2011 (UTC)

Like Button

I propose a Like button/link on every page. This information would be persisted for every user. This information could be used to provide personalized page suggestions on the home page, based on that particular user's interests.

I don't think that's what the OP meant. The "personalised page suggestions" would suggest an entirely on-wiki thing, but we don't really have a way to achieve this. - Jarry1250 [Who? Discuss.] 20:44, 25 February 2011 (UTC)
This is actually in the works via the article feedback pilot; see Category:Article Feedback Pilot. ---— Gadget850 (Ed) talk 20:54, 25 February 2011 (UTC)
I looked at the feedback form, it asks for too much, there should be a short form, ie the Like button, and a long form which people can optionally fill in.Hackbinary (talk) 12:19, 4 March 2011 (UTC)

Strong Support A simple like and dislike buttons, keep it simple. Hackbinary (talk) 12:19, 4 March 2011 (UTC)

This has been proposed and rejected a month ago, see Wikipedia:Village pump (proposals)/Archive 68#"Like" or "dislike"" button MBelgrano (talk) 17:23, 26 February 2011 (UTC)

Anyone wanting personal suggestions might be interested in User:SuggestBot, "a program that attempts to help Wikipedia users find pages to edit based on their past contributions". Fences&Windows 19:14, 26 February 2011 (UTC)

Debundling of sysop tools (commonshelper right)

I'd like to propose a debundling of a new right, commonshelper, to allow non-admin users experienced in image work (transferring appropriately licensed enwiki images to commons, reviewing transferred images) to be able to delete in the File: and File talk: namespaces. They'd use this right to help clear backlogs, (Category:Copy to Wikimedia Commons Category:Wikipedia files with the same name on Wikimedia Commons Category:Wikipedia files with a different name on Wikimedia Commons), as not many current administrators are very willing to do it. I've listed more details here. --Addihockey10 e-mail 03:18, 26 February 2011 (UTC)

Would/should/could this be bundled with the filemover tool proposal? Thoughts? --Addihockey10 e-mail 03:22, 26 February 2011 (UTC)
Note that consensus may soon allow all autoconfirmed users to move files. Guoguo12--Talk--  20:51, 26 February 2011 (UTC)
Note that the above statement is patently false and that the consensus supports unbundling of filemover but rather strongly opposes giving it to every autoconfirmed user at this time. FWIW the proposal also opposes bundling it with accountcreator, so I'd avoid that idea here. Sven Manguard Wha? 23:49, 27 February 2011 (UTC)
Note that the statement directly above may not be true. How can you say consensus strongly opposes it at this time? You strongly oppose it, but the opposition is not unanimous, nor is consensus very clear. However, for obvious reasons, let's not discuss this here. Guoguo12--Talk--  01:12, 28 February 2011 (UTC)
  • Support FWIW.
    — V = IR (Talk • Contribs) 23:39, 27 February 2011 (UTC)
  • Oppose allowing non-admins to delete anything, for any reason, at this time. I would however be in favor of creating a bot to assist in the work. Consider the following:
  • Wikipedia already has the capability of noticing that someone is trying to upload an image that is pixel for pixel identical to an existing file.
  • Most of copying to commons involves copying images pixel to pixel.
  • A bot, theoretically, could scan two addresses, the enwiki one and the commons one, to determine if the two images are pixel for pixel matches.
  • One idea would be to allow users access to a wikipedia to commons move script without the ability to delete the wikipedia image, which would automatically feed information to a bot that would scan to ensure that the image was pixel for pixel identical, the file names were identical, and that license information was transferred over successfully. If that were the case, the bot would delete the enwiki version. Any edits that need doing to the image itself, such as cropping or renaming, could be done on commons.
  • This proposal ensures that only files that were copied to commons are deleted, as opposed to allowing anything in the file namespace at all to be deleted. Sven Manguard Wha? 00:06, 28 February 2011 (UTC)
    That would hit a couple snags though. If people uploaded blatant copyrighted images, such as a cover of an album etc., the bot wouldn't be able to tell it is copyrighted. So the inexperienced editor adds {{CC-BY-SA 3.0}} to the image description - the bot finds the image and copies it to commons. I also find that when knowledgeable humans review it - it's far less likely to be a copyrighted image. --Addihockey10 e-mail 12:57, 28 February 2011 (UTC)
Support - I generally support the idea but I also recommend that users with the above right also has the ability, via a script or whatever, to be able to rename images on Wikipedia. This currently requires administrator access and would be very beneficial. --Kumioko (talk) 01:41, 28 February 2011 (UTC)
  • Unfortunate Oppose - after thinking about this, I've come to the conclusion that there are very few users that would be suitable for deleting images moved to commons but not suitable for other admin tasks. Now to toot my own horn a bit and show my credentials in the area: I have spent literally hundreds of man-hours moving images to commons and I'm largely responsible for the clearing of 2/3 of the backlog at Category:Wikipedia files with a different name on Wikimedia Commons. I can testify right now that many non-admins are better at recognizing which images should be moved over and which shouldn't. But the users I'd trust to recognize which images should be moved over, I'd mostly also trust to be admins. Thus I see three problems:
    1. If any admin could bestow this ability upon a non-admin, then there would be countless bad moves, if only because most admins don't really know what they're doing in the area. This isn't like rollback or autopatrol; hitting the delete button can't be undone easily. And if an admin sees exemplary behavior from a user in all areas and much good work with images, this admin is liable to say "I would trust this user with images" without going through the vetting process of making sure that user is familiar with the subtleties of image moves (e.g., COM:DW, COM:FOP, COM:DM, COM:COA, Wikipedia:Non-U.S. copyrights (a woefully out of date document), WP:PERMISSION, {{PD-US-not renewed}} - and how to search for it [5], work-for-hire laws, {{Not-PD-US-URAA}}, the interaction of {{PD-URAA}} with {{PD-Russia}} and {{PD-Russia-2008}}, etc.).
    2. If, on the other hand, we require a vetting process to gain the bit, it would become sort of a pseudo-RfA. All of which would be fine with me (no really), except that the community has repeatedly rejected the idea of giving admin bits in increments.
    3. The third objection isn't really mine, and it might prove to be immaterial: this is a fairly difficult thing for the devs to write into the software. They would have to give the ability to certain users to delete only certain files, and only allow the users to choose one option from the pull-down list. The devs might reject this as not worth their time. Magog the Ogre (talk) 18:29, 28 February 2011 (UTC)
    I'm not one to ask, but I don't think it'll be THAT hard to make a new usergroup that can delete pages in the File: and File talk: namespaces. Also it's not just for users just focused on enwiki>commons work. It's for users who are fully capable of reviewing enwiki->commons images but would not pass a regular RfA for various reasons (not any experience in certain areas such as WP:AIV WP:RFPP WP:UAA etc. etc. --Addihockey10 e-mail 22:35, 28 February 2011 (UTC)
Support - this should help with the backlogs.   — Jeff G.  ツ 01:50, 3 March 2011 (UTC)
  • Oppose This is an example for creating too many user groups for too few users. I suspect that only a few users would end up helping with the backlogs; we have over a thousand admins and look where we are. /ƒETCHCOMMS/ 04:40, 4 March 2011 (UTC)
I'm not sure how to take the "we have a thousand admins and look where we are" comment. We have a 2-3 year admin backlog that few people want to deal with? A handful of those few people being non-admins? I kinda picture this to be similar to the abusefilter right. Not TOO many people have it, but it's enough to significantly clear the current (2-3 year) backlog that we have. --Addihockey10 e-mail 15:08, 5 March 2011 (UTC)

Support Deletions in the File/File Talk namespaces are often uncontroversial. And virtually all deletions that have to do with images moved to Commons are uncontroversial. There's a need for competent people working in this area and it's a good idea to try and make it happen. I see a couple of problems with Addihockey10's objections above. First it's quite likely that some very competent candidates for this userright would fail RfA because of unfamiliarity with other areas that are considered more important at RfA. Second, it's true that most admins would be incompetent at this task but this is precisely why it makes sense to selectively target competent people for this task. Unbundling will increase the number of competent people in this area without creating any sort of drama. Pichpich (talk) 19:46, 5 March 2011 (UTC)

  • Oppose only because I have a concern that the moved images are not reviewed properly and then removing the source moves the problem to commons. I also have to agree with the points made by User:Magog the Ogre. All the images moved to commons really need to be be checked as we have a more than you think number of images that should not have been moved, many obvious copyright violations are just moved to commons and these have to be sorted out. Removing the local copy without checking just makes the problem dissapear without a trace into commons. MilborneOne (talk) 00:26, 9 March 2011 (UTC)
    Well of course the users with the commonshelper right would have to check that the image was moved properly, that the license is correct and that there are no issues with it, source, attribution etc. etc. --Addihockey10 e-mail 22:25, 9 March 2011 (UTC)

Collab with Citizendium

As I am sure everyone here knows, Wikipedia is the largest source of free online information available. Thanks to the ever vigilant team of admins and editors(yes I’m talking to you) this website continues to become increasingly accurate and neutral. The talk:Reliablilty of Wikipedia does an excellent job of allowing us editors to help the way by which this online resource covers itself, showing that neutrality is ultimately the websites main goal. However this produces a paradox of sorts, Wikipedia cannot self-define with absolutely neutrality. This brings me to my main point; a collaboration with Citizendium. When Wikipedia’s founder left the team shortly after its creation, he started a second project which attempted to remove the lack of credibility that is inherent within Wikipedia(sorry guys). I propose, and I assume I am not the first, that these two projects are combined. The pure size of Wikipedia is something that Citizendium could never match, and the accuracy and neutrality that Citizendium has is exactly what is holding Wikipedia back. Citizendium only has 155 pages with have been edited and confirmed by multiple experts of that topic, but these pages are said to be entirely error free. Adding this level of accuracy to Wikipedia articles, even if just 155 out of the 3-million plus articles would be an incredibly beneficial step forward for the site that would only increase with time.” --Droberts4080 (talk) 09:24, 28 February 2011 (UTC)

I've never been overly impressed with the scope or writing on Citizendium; of the pages they have that are workable the content is about on a par with what Wikipedia has on the same topic, usually using the same sources. The caveat to that is that certain contentious pages are much better on Citizendium through virtue of being restricted editorship - but practically speaking those pages are crappy (example compare Islam to Islam) because they are contentious. The lead to our Islam article is horrible; but how is Citizendium collaboration going to fix that problem :) --Errant (chat!) 09:52, 28 February 2011 (UTC)
WikiProject Citizendium Porting exists already as a way for Wikipedia to benefit from Citizendium's work. You might want to look at what they're doing. Including, by the way, assessments of which pages aren't up to Wikipedia standards. — Gavia immer (talk) 09:55, 28 February 2011 (UTC)
Citizendium is hardly error-free, nor are they particularly neutral. Their alternative medicine articles have largely been taken over by proponents, and many of their approved articles are terribly written and/or inaccurate, for example, Biology is a confused mess, and Scientific method has a section advocating for Intelligent design, which is pretty horrifying to anyone who knows biology.
Frankly, there's serious quality and accuracy gaps in a lot of Citizendium articles, and we'd be well advised to be very careful in use of them, while, of course, benefiting from the occasional very good articles to come out of the process. Adam Cuerden (talk) 10:07, 28 February 2011 (UTC)
There isn't a "section" on ID, just part of a paragraph, which clearly states that very few biologists accept it. Peter jackson (talk) 11:38, 28 February 2011 (UTC)
It looks to me as if there are three whole paragraphs (and some other verbiage elsewhere) dedicated to introducing the proposition that the theory of evolution by natural selection is possibly not scientific. Since the article is not about evolution (and says it is not), the amount of verbiage attached to this proposition is pretty troubling. — Gavia immer (talk) 12:05, 28 February 2011 (UTC)
Having taken the time to flick through a few more articles there, Citizendium suffers a lot for requiring "expert" editors on topics & most of the articles suffer from a lack of focus, poor writing, neutrality issues and often too narrow a scope. It's a shame, the idea IIRC was to fix those very problems, I guess that is an approach that doesn't work. --Errant (chat!) 12:18, 28 February 2011 (UTC)
I've seen no evidence that Citizendium is overall more neutral or accurate. Many of their articles are in fact old forks of Wikipedia articles that have since been cleaned up on Wikipedia, but not on Citizendium. 28bytes (talk) 16:26, 28 February 2011 (UTC)
Quite. "Citizendium only has 155 pages with have been edited and confirmed by multiple experts of that topic, but these pages are said to be entirely error free." Said by whom, the experts? Citizendium has terrible problems with fringe science, even more than we do, and that's caused by their "experts" (just look at their Homeopathy article). Moreover, the restrictions on editing and the general culture there led to stagnation (example: the discussion email list got busy just as it was launching, so Larry Sanger responded by essentially shutting it down[6]; another example of Sanger's "golden touch":[7]). An alternative approach is to overlay 'expert review' on top of Wikipedia, see meta:Expert review. Fences&Windows 23:43, 28 February 2011 (UTC)

An alternative to this may be to create a system similar to the GA nominations, where the articles would be reviewed by an expert in such topic. Of course, "an expert" would not be some random user with delusions of grandeur, but someone previously approved for such a task, perhaps detailing his real name and degrees by OTRS. And of course, the topics that this expert can manage as an expert. This system would not replace FAC or GAN, but be a new one. It may not replace FAC, accuracy is an important thing for FA status but not the only one, and an expert-approved article may still need to adress other issues. We shouldn't expect real-world experts to be aware of internal Wikipedia nuisances, such as how to use templates, not linking to disambiguations, no overcategorization, image licences, what to keep at an article and what to move to a fork article, etc; and the expert may overlook them. And, although it would have a higher prestige than GAN, it will certainly be a very, very, very slow process, with backlogs that may last for many months, as very few people would be managing them, and without help from other users. MBelgrano (talk) 17:41, 1 March 2011 (UTC)

[Edit conflict] The major problem is that credentials can be somewhat dangerous when you're dependant on one person: For example (and using only really obvious cases to avoid BLP issues) Michael Behe is a professor of biochemistry, but one would not want him as the judge for our biology articles, given his promotion of the unscientific intelligent design form of creationism, and denial of evolution. Andrew Wakefield was a medical researcher at a respected hospital, but would've been a disaster if he were our judge for immunology, given, you know, that he was found guilty of committing fraudulent and unethical research in order to promote a crank immunological theory.
Instead, may I point to the vastly respected WP:MILHIST and their multi-person expert A-level review. On a WikiProject level, with multiple experts fully integrated into Wikipedia, expert review can work wonderfully. Adam Cuerden (talk) 18:07, 1 March 2011 (UTC)
Isn't Citizendium basically dead? Only 155 articles in how many years? I just looked at the recent edits there which are 500 article edits since 26 februari, not terribly active. Garion96 (talk) 17:56, 1 March 2011 (UTC)
There are more than 155, the 155 are the approved articles. Still not that much though. Garion96 (talk) 18:00, 1 March 2011 (UTC)


I have very rarely looked at Citizendium, but on the rare occasions I have looked at it, I can only say that it appears to be an online encyclopaedia that is lower-quality product than Wikipedia. It lacks Wikipedia's range of articles and comprehensiveness, for a start. ACEOREVIVED (talk) 19:41, 2 March 2011 (UTC)

Let me be a little more specific. When I looked at Citizendium, I noticed that it did not even have an article on Paul Tillich - a leading theologian of the twentieth century without an article! Citizendium may be against anonymous editing, but that has not made it a better encyclopaedia than Wikipedia. ACEOREVIVED (talk) 00:22, 3 March 2011 (UTC)

I looked at Citizendium from the computer I use at work on the morning of March 3 2011,and again, I was anything but impressed with it. I noticed that it did not even have a separate article on ascetism - an article which has long existed in the paper version of Encyclopaedia Brittanica. So please let us keep us what is definitely the better online encyclopaedia (Wikipedia} separate. ACEOREVIVED (talk) 22:28, 3 March 2011 (UTC)

May I also add that Citizendium rarely has the high Google search that Wikipedia has. ACEOREVIVED (talk) 00:07, 4 March 2011 (UTC)

Feel free to write such articles yourself. Citizendium can't be expected to have lots of articles until it has lots of people. Peter jackson (talk) 09:39, 4 March 2011 (UTC)
MB, Veropedia already runs such a system for WP articles. Also, the new site known (last I looked) as Knowino has such a system internally. Peter jackson (talk) 09:42, 4 March 2011 (UTC)
Gavia, the article is on scientific method. It's proper for it to cover philosophy of science, in which Karl Popper is a major figure. In relation to his ideas it's quite appropriate to discuss whether evolution is a scientific theory. Peter jackson (talk) 09:44, 4 March 2011 (UTC)
It is not, however, reasonable to then go on to claim that Intelligent design - an idea, not a theory, the premises of which are either untestable or disproven, is on equal footing. That's directly contrary to Popper.
Indeed, anti-science is core citizendium policy:
In short, Larry Sanger is an idiot, and Citizendium is awful by design. We're not going to salvage this by bringing a horribly broken system over into Wikipedia, which violates our basic WP:NPOV policy (ironically, written by Sanger orginally, before he decided he knew better than those damn scientists). Adam Cuerden (talk) 07:17, 6 March 2011 (UTC)

Adam Cuerden (talk) 07:13, 6 March 2011 (UTC)

  • Oppose Let Citizendium rot. Last time I saw a thread here regarding Citizendium, it was because they didn't have enough money to keep the doors open and someone suggested a WMF loan. I have issues with both the quality of Citizendium's content and its philosophy. My opinion on Larry Sanger isn't so hot either, but that's a different matter entirely. The point is that it's really not something worth our time. For the sake of discussion, Wikipedia:WikiProject Citizendium Porting does exist. My understanding is that it's not very successful. Sven Manguard Wha? 06:21, 6 March 2011 (UTC)
    • We're 40% done with the porting, and several articles we lacked have been imported wholesale. I call that success. But yes, there have been a surprising number of articles copied from WP w/o significant improvements, and there are a few unusably tainted articles. --Cybercobra (talk) 08:02, 6 March 2011 (UTC)
      • There's certainly things to gain from using the compatible licenses, and the Porting WikiProject should not be disparaged: it has improved a few dozen articles. But adopting Citizendium's methods, or giving Citizendium power here, as the proposal suggests, is an AWFUL idea. I'm of the impression that the successful articles are despite the setup they have, not because of it. Adam Cuerden (talk) 02:27, 7 March 2011 (UTC)

My impression of Citizendium is that it's basically failed - I don't know why, perhaps just because it never achieved that critical mass of publicity to match that of Wikipedia, or perhaps because it turns out that their editing model isn't tenable for a voluntary project, whereas Wikipedia's (in spite of all we dislike about it) is. That isn't to say we can't learn things from Citizendium - if there are some articles that they have better than ours, then I'm all in favour of porting them in, licencing permitting (and glad to hear that that's happening). Otherwise, the best way to "cooperate" with Citizendium is to persuade the kind of specialist editors who write there to come and write for us instead/as well - ours (fortunately or otherwise) is the encyclopedia that the world reads. And we could certainly benefit from hearing first hand about any features of the setup over there (including the software) that might be usefully introduced over here.--Kotniski (talk) 08:46, 6 March 2011 (UTC)

Adam, the article doesn't put ID on an equal footing. And Citizendium's neutrality policy is much the same as Wikipedia's. Peter jackson (talk) 11:07, 7 March 2011 (UTC)
Repeatedly saying that doesn't change the truth. If the neutrality rules are the same, why did Sanger apparently personally invite homeopathic advocate Dana Ullman to take over writing the Homeopathy article? Adam Cuerden (talk) 07:47, 8 March 2011 (UTC)
Wikipedia doesn't always observe its own neutrality policy. Nor does Citizendium. Peter jackson (talk) 10:45, 8 March 2011 (UTC)
Kotniski, many of the specialist editors on Citizendium do edit here as well. For the rest, it's hardly going to be the case that they're unaware of Wikipedia, is it? So those who don't edit here must have some reason for not doing so. That must be that they got fed up with having to fight endless wars with propagandists and/or idiots and/or trolls. Until Wikipedia develops an effective means of resolving disputes those sorts aren't going to come back. Peter jackson (talk) 11:12, 7 March 2011 (UTC)
Yes, that's kind of what I meant. Make the atmosphere and culture here more amenable to serious and knowledgeable editors.--Kotniski (talk) 12:44, 7 March 2011 (UTC)
But I don't think it's likely to happen in the near future. The community is too complacent. Not much is likely to change until competition forces it. Whether that competition will come from Citizendium, Wikinfo, Knowino, something I haven't heard of or something that doesn't exist yet I don't know. Given the orders of magnitude separating WP from others it'll take a long time, though a "long time" on the internet may be only a few years (corollary of Moore's Law?). But it's bound to happen eventually if WP carries on getting "suckier" as Ludwigs puts it. Peter jackson (talk) 10:49, 8 March 2011 (UTC)
How would a competitor taking wikipedias position be a problem? Think of wikipedia as the Roman Republic, it will eventually be replaced by something better like the Roman Empire. The senators might not like this transfer, but they are powerless to stop it. The plebs care little either way, they are more interested in bread and games. Right now we are still in 149 BC though, beating the shit out of Carthage and whoever else might challenge us. The only realistic end to the greatness of Rome is we lose the war against the Vandals. Yoenit (talk) 12:17, 8 March 2011 (UTC)
It would only be a problem in the sense that it's a waste of the enormous resources currently available in WP space. If WP could make proper use of them itself, that would be more eficient and a lot quicker than someone else having to do so. Peter jackson (talk) 11:22, 9 March 2011 (UTC)

Reducing boilerplate below edit box

Between the edit box and the box below it (the one that allows you to enter wiki markup and such stuff as Greek and Hebrew letters by clicking) there are several lines of boilerplate text:

Content that violates any copyrights will be deleted. Encyclopedic content must be verifiable. You irrevocably agree to release your contributions under the CC-BY-SA 3.0 License and the GFDL. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license. See the Terms of Use for details.

and:

If you do not want your writing to be edited, used, and redistributed at will, then do not submit it here. All text that you did not write yourself, except brief excerpts, must be available under terms consistent with Wikipedia's Terms of Use before you submit it.

(These texts can also be found at the interface pages MediaWiki:Wikimedia-copyrightwarning and MediaWiki:Wikimedia-editpage-tos-summary.)

By now, after some 30,000 edits, I just ignore them. So why do they bother me? Because this boilerplate stuff takes up real estate at an inconvenient place: I regularly find that I need to scroll the window down and up, again and again, to switch between the place in the editing window where I'm entering text and the Non-Latin-letters-etcetera box below it, since I want to have immediate feedback, but they don't fit together in the browser window. It is annoying to do this scroll down, click, scroll up for every single letter you enter. (I could opt to have fewer "rows" in the editing window, but then it becomes a peephole through which it is harder to keep an eye on the context.)

The proposal is:

Add an option (disabled by default) to the list of options at Special:Preferences/Editing to "Show Wikimedia copyright warning and terms-of-use summary before preview and edit box".

 --Lambiam 15:04, 6 March 2011 (UTC)

I doubt any developer would get around to adding such an option, and disabling it by default would never fly; we want IP users and newbies to see that text. To disable it hide that text for yourself, add this to your skin.css:
span.editHelp { display:none; }
#editpage-copywarn { display:none; }
div.mw-tos-summary { display:none; }
#editpage-copywarn2 { display:none; }
span#minoredit_helplink { display:none; }
This could probably be turned into a Gadget if there were sufficient demand. Anomie⚔ 15:20, 6 March 2011 (UTC)
I think you have misunderstood. The default (disabled) would let the page be exactly as before: with the boilerplate between the edit box and the goodies box. Enabling the option will move the boilerplate up to before the edit box, where it will still be quite visible, just as the anon edit warning "You are not currently logged in. ..." before the edit box is quite visible. But the CSS stuff does the trick for me; thanks.  --Lambiam 15:58, 6 March 2011 (UTC)
Yeah, I misunderstood. Sorry. Anomie⚔ 00:01, 7 March 2011 (UTC)
Well, it stopped working; an admin deleted my skin.css page, stating: creates copyright headaches. :(  --Lambiam 00:22, 8 March 2011 (UTC)
Someone who has been here for 5 years with over 30000 edits should be well aware of the copyright issues by now, without needing interface clutter to remind them. Try asking the admin in question what they're playing at, and if they won't undelete take it to WP:DRV. Anomie⚔ 05:01, 8 March 2011 (UTC)
Another admin already restored it, stating: don't be silly – always good advice to everyone except clowns and comedians. I hope I did not unwittingly instigate a wheel war.  --Lambiam 13:22, 8 March 2011 (UTC)
Unfortunately being aware of the copyright issues means aproximately very little from a legal perspective. We need a release and by removing the we lose that release. Effectively your position is equiverlent to arguing that experence users don't need to add license templates to their images.©Geni 18:34, 8 March 2011 (UTC)
It is a totally different position that does not bear even the remotest resemblance to the strawman you're putting up.  --Lambiam 00:13, 9 March 2011 (UTC)
Interesting argument. Do you really think one can prevent their contributions being so licensed simply by hiding the relevant text? If so, what is to stop them from hiding it with browser css (or a post-it note, for that matter)? –xenotalk 18:56, 8 March 2011 (UTC)
Because that's browserside. They got a bunch of stuff sent to them that has the intention of showing that notice. With the CSS changes no attempt is made to show the notice. The whole area is very messy and best avoided for precisiely that reason.©Geni 19:11, 8 March 2011 (UTC)
So you are hypothesizing some future situation where someone would sue the Wikimedia Foundation for copyright infringement, after hiding the release via css? And you think that, after it is demonstrated that they had intentionally and willfully hidden the release, they are going to have legitimate grounds for such a suit? –xenotalk 19:19, 8 March 2011 (UTC)
they argue that their action was the equiverlent of opting out. The court might accept that. The court might not but argue that any future use of material derived from that work would then constitute a copyvio. As I said messy. The copyright situation on wikipedia is complex enough as it is and making it messier is at best missguided.©Geni 19:24, 8 March 2011 (UTC)
I think that's a bit of a stretch - but would you be satisfied if a user who, having hid the release via CSS, made a blanket general release somewhere on their userpage? –xenotalk 19:26, 8 March 2011 (UTC)
(e/c)CSS is browser-side whether its delivered by the server or not. The text of the copyright notice is still there in the HTML source, its just hidden by the browser. The terms of use don't stop applying just because you don't read them. Mr.Z-man 19:30, 8 March 2011 (UTC)
Also, the terms of use is still linked on every page, and clearly states how everything is licensed. I too find this scenario quite a stretch. henrik•talk 19:33, 8 March 2011 (UTC)
if you remove editpage-copywarn and editpage-copywarn2 (which appears to be what is being attempted in this case) then there is no link to the terms of use on the edit page.©Geni 19:41, 8 March 2011 (UTC)
No but in this case we need an active agreement which is a bit of a problem if the editor has turned off the mechanism by which we get that.©Geni 19:37, 8 March 2011 (UTC)
This is rediculous. Any editor may choose what to hide for him/herself, even if it is a copyright warning. One's personal CSS file only affects visibility to the eidtor itself, unlike licence templates, which are visible to anyone. Please don't remove those lines from personal CSS files. — Edokter (talk) — 19:13, 8 March 2011 (UTC)
The license templates are the release in the case of images. The release in the case of text is clicking save page on a page with the text of editpage-copywarn next to it. Other people being able to view it or not is of no actual significance.©Geni 19:20, 8 March 2011 (UTC)
By hiding a message, the editor is asumed to have read and agreed to any message previously displayed. Hiding it does not in any way deminish our policies. If it were really this important, the message would be unhidable. — Edokter (talk) — 19:27, 8 March 2011 (UTC)
!)I don't think it occured to anyone that someone would try and do this and 2) how would you even go about making it unhidable.
You could remove the class ID, I suppose. In any case, as Z-man notes about, even when hidden with user or browser CSS, it is still present in the HTML source. –xenotalk 19:34, 8 March 2011 (UTC)
Unless you are going try and argue that the courts would look kindly on a release in the HTML that was commented out I don't think "it's still there in the HTML" is an argument that gets us very far.©Geni 19:39, 8 March 2011 (UTC)
I feel silly arguing about this in the first place, but I suppose frivolous lawsuits are a lot more common south of the border. –xenotalk 19:44, 8 March 2011 (UTC)
There are 352 users who are hiding copywarn2, including me for close to two years now. IANAL and find the idea that hiding the notice can be argued as an opt-out absurd, but I try not to underestimate the absurdness of copyright law, so I wouldn't want to rule it out either. Cat's out of the bag however. If anyone is seriously worried about this having the potential to create problems, ask WMF legal council, and have them worry about it. Amalthea 21:29, 8 March 2011 (UTC)
The long term ones create another headache because of course the copyright warning has changed from pure GFDL to GFDL+CC-BY-SA.©Geni 23:58, 8 March 2011 (UTC)
And even 726 users are hiding copywarn. The way I see it, we all agreed at some point to uphold policy; we really don't need to do that with every edit. — Edokter (talk) — 00:35, 9 March 2011 (UTC)
I'm in a weird position here in that I agree that it's probably not necessary, if we require affirmation of understanding of policy before the notice is disabled, but still kind of thinking that displaying it universally is a good idea. :) The only potential for legal problems I can see out of allowing opt-out would be if somebody argued that they had usurped an active account and so did not themselves agree to the opt out or know about the copyright policy, or if terms significantly changed (as with our great license shift). For all I know, it's plausible to unilaterally override everybody's opt out in the latter case, and the former could be taken care of by adding to that opt out requiring an affirmation of understanding that accounts are not transferable. But, again, I think it's a good idea to have it at the bottom of every edit screen because it may potentially provide an additional layer of protection for WMF, demonstrating a strong good faith effort to prevent misuse of the project. --Moonriddengirl (talk) 13:53, 9 March 2011 (UTC)
Going back to the original proposal, if you add the release to the login page and repeat it as part of the setting on the preferences page, surely that is sufficient if the user has opted out of the warning next to the edit box? - Pointillist (talk) 18:48, 8 March 2011 (UTC)
I'm not sure adding text to the login page for everyone is a great idea.©Geni 19:20, 8 March 2011 (UTC)
Why not? - Pointillist (talk) 21:33, 8 March 2011 (UTC)
Because we try and keep it as sort as possible in the vauge hope that new users will read it.©Geni 00:00, 9 March 2011 (UTC)
Is that an established view? I would have thought that the project would benefit from new users being told that "Encyclopedic content must be verifiable. Content that violates any copyrights will be deleted. You irrevocably agree to release your contributions under the CC-BY-SA 3.0 License and the GFDL." BTW, why do you prefix your username with ©? - Pointillist (talk) 00:21, 9 March 2011 (UTC)
Well the whole registration system is meant to be undergoing a complete overhal so I suppose historical might be a better description. The © is playing with a bug in CC-BY-SA 3.0©Geni 00:28, 9 March 2011 (UTC)

Side question—appropriate use of admin powers?

Is it really an appropriate use of admin powers for an admin to go around editing other users' personal css files after it has become clear that there is not consensus for his/her position? Anomie⚔ 23:05, 8 March 2011 (UTC)

A strict reading of policy would call for warning followed by indefinet block however I would regard that as somewhat excessive.©Geni 23:59, 8 March 2011 (UTC)
Revert, desysop, block, then ban. What fun. Mono (talk) 00:04, 9 March 2011 (UTC)
I would say not. An editor's personal CSS is not subject to any content or copyright policy. An admin making such edits should revert his/her edits and apologize to the editor. — Edokter (talk) — 00:32, 9 March 2011 (UTC)
Everything (with the possible exception of the logo) on this wiki is subject to the copyright policy. Quite a few of the CSD criteria could also apply. In fact since it is possible to drop comments into your monobook.css page there are quite a selection of content policies that apply.©Geni 00:37, 9 March 2011 (UTC)
Right, there are cases where a users js or css file could be deleted. This isn't one - hiding a page element doesn't make it not there, any more than covering a contract with a piece of paper voids it. But I think we've come to that conclusion already anyway. Prodego talk 02:28, 9 March 2011 (UTC)

Redesign

How about combining the two into a simple notice, like





Mono (talk) 00:04, 9 March 2011 (UTC)

Isn't that considerably larger than what we currently have?©Geni 00:19, 9 March 2011 (UTC)
It is somewhat consolidated. But in my view, it should be shrunk to one clear line with a link to the Terms of Use page. — Edokter (talk) — 00:28, 9 March 2011 (UTC)
Tried that. Actualy back in the GFDL days we got pretty close (although we used footnotes rather than link out). Current text is foundation mandated and objections about length got kinda brushed asside. Feel free to file a fresh protest though.©Geni 00:31, 9 March 2011 (UTC)
Perhaps the second? Mono (talk) 01:19, 9 March 2011 (UTC)
The second notice is not consistent with Terms of Use, in that hyperlinks and URLs are not the same thing. For instance, we use hyperlinks when copying within Wikipedia, not URLs. (Also, it's not necessarily to the page you're contributing to, as it could be a stable version stored elsewhere.) Both of them exclude reference to "except brief excerpts". I think we need to retain that. :) We don't want to eliminate quoting here. I'm not sure that either of these are an improvement over what we have, though. (Though it, like these, omits the other possibility of attribution--a list of authors.) --Moonriddengirl (talk) 13:30, 9 March 2011 (UTC)

Adblock Plus

File:Screenshot-Adblock Plus Preferences.png

Personally, I found Adblock Plus an efficient tool to ged rid of those annoying messages. —Ruud 01:06, 9 March 2011 (UTC)

Why have the boilerplate disclaimers?

Sometimes, I wonder why we have them there in the first place. I highly doubt most people, including newcomers, "casual editors", and veteran users alike, don't care to heed them. If they're going to add unverifiable or copyright-violating stuff, they are going to anyways. I feel that they are more in the way aesthetically than whatever benefits they have in informing users. –MuZemike 20:35, 10 March 2011 (UTC)

It is, as we lawyers say, to cover your ass... in case of a lawsuit. Without notice of disclaimers etc it is hard to rely on them in court. With them you at least have an argument. Isn't this an issue that the Foundation's General Counsel should be opining upon, rather than the user base? – ukexpat (talk) 20:45, 10 March 2011 (UTC)

All this started because there is people who do not like a mass of well known links in the space between the edit box and the summary and save sections; but now it may seem that it may be legally needed to include the copyright release in the save box. Both things are not mutually exclusive: if it turns out that the copyright links must be included, wy not include them somewhere else? The "important" area in edit mode, where editors use things and need to see them or scroll to them,, is between the tools and the save button. Above and below it's unused space (for editing purposes) and any boring mandatory messages may be included in there. MBelgrano (talk) 21:59, 10 March 2011 (UTC)

Which was the very proposal with which this started, or, at least, to make that a user-preference option.  --Lambiam 00:51, 11 March 2011 (UTC)

Allow Wikimedia-wide searches from within Wikipedia search screen

There used to be a box at the right of the search results page that showed the most relevant results from sister projects (see Help:Searching#Search results page which btw desperately needs updating) This is no longer the case and hopefully someone can tell me why because I thought that was very a very useful feature. And I DO have "Enable enhanced search suggestions (Vector skin only)" checked in My Preferences, and this tool doesn't really do what I'm wanting to do. What I propose is to be able to search ALL Wikimedia projects, including ALL languages, all at the same time, and to be able to do this from the regular Wikipedia search results screen (perhaps by selecting it from the drop-down box that lets you select external search engines?) Is this feasible? -- Ϫ 09:53, 11 March 2011 (UTC)

Yes, wiki-wide searches is a problem. If I search for 'Mikołaj Dowgielewicz' I get nothing - except on the wikipedia.pl because he is polish. In this case I took the picture, so I know he is polish, but next time maybe all I have is a name, and no nationality. Really I could use a system-wide search, for any language, and also for picture/media as well. It would be useful if the search result told me how many bytes (so I can look at the longest result first). As it is now, it is entirely a one-language closed box. If anyone knows how to do system-wide searches, then tell me, as I apparently do not know how to do that. --Janwikifoto (talk) 15:36, 12 March 2011 (UTC)

Mix Wikipedia and Twitter

Wikipedia offers the "immutable" knowledge of the world. Twitter offers the "mutable" experience of the world changing in front of our eyes. Wouldn't it be interesting to being able to take a look to both at the same time? --Maalvarez (talk) 09:56, 27 February 2011 (UTC)

So go design that. I'm not sure exactly what you're envisioning, but if you have something in mind, web hosting is cheap (and often free) while you're just in development. Why does everyone want to throw something out there, and then have someone else go code it? Seraphimblade Talk to me 10:11, 27 February 2011 (UTC)
For what purpose? There's no reason to read a Twitter feed and an encyclopedia article side-by-side (and I say this as an avid Twitter user with close to 13k tweets). Plus, your use of "immutable" and "mutable" here is incorrect: Wikipedia is an excellent example of "liable to change". EVula // talk // ☯ // 15:51, 27 February 2011 (UTC)
Here's an easy way to do this. Go to Wikipedia. Resize your browser screen to half of your monitor. Open another browser window. Go to Twitter in the other browser window. Also resize this to half of your monitor. Place them side by side. Presto! Done. Cheers! bd2412 T 16:27, 27 February 2011 (UTC)
But that's hard to do if you don't have Windows 7… :( --Izno (talk) 16:46, 27 February 2011 (UTC)

Hell No! The separation of WMF project and social network site must be absolute at the development level, or Wikipedia loses essentially overnight the credibility and academic standing it has spent ten years trying to gain. I don't see how this is so freaking hard for people to understand that Wikipedia is not a social networking site. Most Wikipedians are quite happy with the fact that there is no share or like or friend or whatever other buttons on Wikipedia, and that there are no corporate relationships between the WMF and these sites. Wikipedia is an encyclopedia, it shares the knowledge of the world. It can be social in so much as that people work together to improve the project. Twitter is not academic, most of the time it is not even substantive, and it's primary functions are in no way comparable with Wikipedia. If you want a social experiance related to Wikipedia, hop onto the IRC, which at least attempts to be Wikipedia focused some of the time. Sven Manguard Wha? 20:25, 27 February 2011 (UTC):

I agree, hell I don't really consider Wikipedia to have much credibility, though I do think its articles are reliable 99.95% of the time. I would never use it in an academic setting, but I think it has been improving and maybe a few people are starting to respect it a bit more. Plus I am editting it in a serious manner rather than just vandalising, so I guess that says something. If you integrate the ability for Twitts to do this and that so that it becomes a social networking site where people talk about and share the most boring details of their lives, I think Wiki will lose any and all respect that, as Sven has said, it has spent all these years trying to get. So in closing, **** No! TheArchaeologist Say Herro 20:44, 27 February 2011 (UTC)

Sharebox is a script that reorders your toolbox. It adds new buttons that make it easier to mail, print or share an article on Facebook or another linksharing service. See User:TheDJ/Sharebox. ---— Gadget850 (Ed) talk 20:56, 27 February 2011 (UTC)

That's a useful script. I didn't know that AddThis could be used in wiki scripts. Goodvac (talk) 08:37, 3 March 2011 (UTC)

Please read Wikipedia: What Wikipedia is not. I think it is the section under sub-heading 2.5 that clarifies that Wikipedia is NOT a social networking site, so it must be kept separate from websites such as Facebook, Bebo, My Space or Twitter. ACEOREVIVED (talk) 22:27, 1 March 2011 (UTC)

Add of access

Ok, so I think that SPI Clerks should have access to all relating to sockpuppets. It's strange that they do not have all sockpuppet things access. ~~Awsome EBE123~~(talk | Contribs) 19:07, 13 March 2011 (UTC)

What are you even talking about? Kevin Rutherford (talk) 02:06, 14 March 2011 (UTC)
I'm talking about that SPI Clerks gets to go block confirmed sockpuppet accounts and all of SPI. ~~Awsome EBE123~~(talk | Contribs) 19:02, 14 March 2011 (UTC)
Clerks are not necessarily Admins. That's why they don't get to block. — The Hand That Feeds You:Bite 19:16, 14 March 2011 (UTC)

Transferring over "filemover" tool

SUMMARY:

There's essentially a unanimous agreement to extend the ability to move files to more people than just administrators. The bigger question is whether we should grant it to all autoconfirmed users or create a separate usergroup. There seems to be no solid consensus on the former, so I think it is appropriate to choose the more conservative of the two—creating a new usergroup for this. Perhaps in some months, we can reconsider Ruslik0's proposal. But for now, someone who knows how should file the appropriate bugzilla request to create a new usergroup with the ability to move files, similar to how Commons does it. NW (Talk) 04:12, 8 March 2011 (UTC)

 Done here. Ruslik_Zero 09:17, 8 March 2011 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

There is a discussion above about unbundling vandal fighting tools and creating new admin-lite packages. Whatever I think of the idea, I don't think that the community will go for unbundling some of the core items of admin rights. In the above conversation, I suggested unbundling or transferring over "filemover" onto Wikipedia, which is not a core part of admin rights, however the conversation was dominated by vandal fighting, so I'm moving this down here.

The "filemover" tool exists on Commons, and allows trusted users to move pages that exist in the file namespace (images, sounds, videos, MIDI compositions, PDFs, others). Period. It does not have any other function. There is a small but competent and talented group of editors that work heavily in files, myself included, that could benefit from this tool, and the risks of importing this over are low. It would allow people that work in files and backlogs to keep such things as Category:File renaming clear, and the only risk would be that users would make inappropriate moves. In reality, since any autoconfirmed user can move non-file pages, and there is already an effective way of tracking that and dealing with it, combined with the fact that this tool would be given to people that already work with images and have to demonstrate trustworthiness, I don't see the risks as being at all large. Meanwhile, Category:File renaming has 150 items, some of which are pending since December. Had I the ability to, I could clear that in less than two days.

Thoughts? Sven Manguard Wha? 19:38, 20 February 2011 (UTC)

That would get my support, yes - it sounds like it would boost productivity, and sounds low risk. -- Boing! said Zebedee (talk) 19:42, 20 February 2011 (UTC)
It has worked fine on Commons, and I would support it here too. I think this is a conversation for the Village Pump though, not here. NW (Talk) 19:52, 20 February 2011 (UTC)
Agree with Nuke—propose it on VP and then link it from here. Der Wohltemperierte Fuchs(talk) 20:13, 20 February 2011 (UTC)
Moved to Village Pump (from Talk:RfA). Sven Manguard Wha? 21:14, 20 February 2011 (UTC)
For those of us not familiar with what exactly the tool does, could you elaborate a little bit? Specifically, my question is exactly what are the possible risks? That is, I have a fairly good idea of what could potentially happen if someone with the "block" button went bad, and so feel like it's important to make sure admins are well vetted. But, in this case, while your description of the tool seems mundane, I'm wondering if there is anything really serious that could go wrong. Or is this really just the File equivalent of the page-move ability that all autoconfirmed users have? If the latter, I would certainly support unbundling this from the admin tools. Qwyrxian (talk) 21:25, 20 February 2011 (UTC)
Okay, so essentially it is exactly "just the File equivalent of the page-move ability that all autoconfirmed users have" as you put it. It also logs as a move, which can be tracked through the move log (it's rare, being only a fraction of the move log, but here's Magog the Ogre's log which is full of them. The issue is that he seems to be the only one that does it consistently that I could find.) The risk is exceedingly minimal, it's easy to revert if there's a problem, and we would be giving it to people who already display competency in files and trustworthiness, and enough knowledge of the processes involved to know to ask. I can't see how this would result in any problems, honestly. Sven Manguard Wha? 22:19, 20 February 2011 (UTC)
In that case, it sounds very much like something that shouldn't be reserved for admins. Would you recommend having a request page like is currently done for reviewer and rollbacker? Qwyrxian (talk) 02:19, 21 February 2011 (UTC)
I suppose that would work. The upside of having that type of request system is that it makes it easy for the people that would have use of it to find it. The downside is that dozens of people that don't have any use for it and have no intention of moving files will clamor for it, under the mistaken impression that it's a status symbol. I suppose that as long as those users don't abuse the tool, it won't be a problem though. Sven Manguard Wha? 05:25, 21 February 2011 (UTC)
  • Sounds reasonable to me. Having trusted non-admins do this work might free some admin time for clearing out the F8 backlog. 28bytes (talk) 22:48, 20 February 2011 (UTC)
  • Support This works on Commons and it should work here. TBH, tho, most of the files in that category should be moved to Commons. Mono (talk) 01:03, 21 February 2011 (UTC)
  • I'm not experienced in working files, so my opinion here should be given proportionally small weight, but, having reviewed the docs at Commons and seeing that this would still be controlled by a separate right, this seems constructive, prudent and sensible. --j⚛e deckertalk to me 01:41, 21 February 2011 (UTC)
  • I'm in the same boat as Joe. The risk that exists is a risk that we already face for article moves. But by having a lightweight requests process similar to reviewer/rollbacker, I'm pretty certain that this would be a net positive. —WFC— 04:57, 21 February 2011 (UTC)
  • Support. I deal with a lot of files, both here and on Commons, this tool will definitely come in handy. And as W says, it will be a net positive. Although, I do think more focus should be made on moving "eligible" files to Commons. Rehman 10:06, 21 February 2011 (UTC)
  • This sounds reasonable, but it could be granted as on commons, on the opinion of an admin, rather than people clamouring for it. Those that have put in good requested move requests could be the ones to have it granted. Also I would want the persone to know all about fair use and FURs. Graeme Bartlett (talk) 10:56, 21 February 2011 (UTC)
    I believe that there is a request page for filemover on commons as well, not instead of "at admin discretion" but in addition to. Here on en.wiki those request pages (for auto-patrolled, rollback, reviewer, etc.) seem to coexist with admins also doing some amount of granting things separately, I got rollbacker here originally without ever having asked for it (although I was asked if I'd want it, the admin who discovered me figured I'd get constructive use of it), and there's in fact an organized effort to grant autopatrolled to people to reduce the NPP load. I guess I was imagining that that'd end up be the case here. --j⚛e deckertalk to me 19:36, 21 February 2011 (UTC)
  • Support. davidwr/(talk)/(contribs)/(e-mail) 16:37, 21 February 2011 (UTC)
  • Support. Der Wohltemperierte Fuchs(talk) 19:34, 21 February 2011 (UTC)
  • Support This can't hurt. But I suspect it will be low-risk/low-reward as very few users will have any use for it. Along the same lines, though it's probably not doable technically, it would be safe to give reasonably experienced editors the ability to do {{db-move}} on their own. Pichpich (talk) 21:19, 21 February 2011 (UTC)
  • Support. Looks like a sensible idea to me. bobrayner (talk) 02:38, 22 February 2011 (UTC)
  • Support Sounds fine. It's worked well on Commons, and it should work well here.

    I just did a small test on Commons, and it appears that files that are fully move-protected aren't movable by filemovers. That's a good idea, I think, and we should keep it that way. NW (Talk) 05:06, 22 February 2011 (UTC)

    • Oops. I forgot to mention that earlier. Yes, Filemover can move semi-protected files, but no it cannot move either fully protected files or move protected files. Again, this is exactly the same set of rules that governs moving non-file namespace pages. As this would ideally be a simple code borrowing, I don't foresee that changing, nor would there be any reason for it to do so. Sven Manguard Wha? 06:27, 22 February 2011 (UTC)
  • Support Yes please, that would we be useful. I had planned to propose this myself, but never got round to it :) Acather96 (talk) 19:26, 22 February 2011 (UTC)
  • Support No big deal. -FASTILY (TALK) 22:22, 22 February 2011 (UTC)
  • Comment - I was asked about the technical feasibility of this. From what I interpret as the proposal, that'd be a trivial change. It's a very simple configuration change that the admins know how to do. (X! · talk)  · @227  ·  04:27, 23 February 2011 (UTC)
  • Support, kind of I've never really liked Commons' filemover system. No, it's not really dangerous  ... but enwiki has many more rights-hungry users who won't even understand what the point of it is. I would definitely prefer bundling this with some new right that includes a few useful features (e.g., merge accountcreator, add filemover, and move-without-redirect, etc.) for trusted and established users—not at all how we hand out rollback; it's like free candy. Is there a pressing need for more filemovers here? It seems like only a very small number of users would benefit from it, which is why I think bundled rights is better than creating more single-right usergroups. /ƒETCHCOMMS/ 03:44, 24 February 2011 (UTC)
  • Note: added to Template:Cent. /ƒETCHCOMMS/ 03:48, 24 February 2011 (UTC)
    • Well I know of about half a dozen users that would have use for the filemover tool, and I'm sure that there are half a dozen other people that each know a half dozen people that could use it. I'm not sure how many people work in predominantly in files, and of them how many of those are already admins, so yeah, by best guess is that it would be around 36 or so people that would have legitimate use for the right. To some degree it's very easy to tell who does work in the file namespace and who does not. It would ultimately be up to the admins to make sure that the people that get the right are the people that need it. On the plus side, however, X! literally showed me what would have to be done to import the right. It takes two changes to one configeration page, so around 27 seconds to implement. That's one key argument against bundling, this is just such an easy change to make and it will be highly beneficial for the file gnomes. Sven Manguard Wha? 04:42, 24 February 2011 (UTC)
      • Hmm ... 36 isn't really a lot. Yes, it's an easy configuration change, but I don't think bundling takes that long, either (at least, it's a two-minute deal on my personal wiki). I'm not opposed to it, but we need to draft up fairly strict guidelines for handing it out—to users who would actually use it, such as you. /ƒETCHCOMMS/ 04:56, 24 February 2011 (UTC)
        • What would be the benefit to bundling? You mention the account creator right, but I know there are some people who consider the existing account creator/edit notice editor bundling to be a bug rather than a feature. 28bytes (talk) 05:07, 24 February 2011 (UTC)
          • (edit conflict) Well I got my Commons filemover right because an admin there thought I'd be able to put it to good use and knew how to use it. While I don't want this to turn into a cabal type activity, I would say that the easiest way to avoid this becoming candy is to just quietly inform admins like Magog who do filemoves themselves to be on the lookout for non-admins that make lots of good requests, are trustworthy, and display clue, and just hand them out that way. It's not a pretty option, but it would reduce the likelihood of people gaming the system for a shiny new right. It's either that, or people will game the system.
          • We could bundle the right with a few other more potentially dangerous ones, like move without redirect, but while that would force the standards to be higher, it would not reduce the whole "gimme gimme" factor.
          • At the very least, I think we can all agree that even if it does get out of hand, there are systems in place to remedy the issue, and moving files, especially if they automatically leave behind redirects, has a much lower potential for causing mayhem when abused than, say, rollback does. I really don't have an answer for you on this. Sven Manguard Wha? 05:18, 24 February 2011 (UTC)
(edit conflict) If we bundle, we should make sure that all the users which are given the right are checked thoroughly. Not through a process like RfA, but basically the admin should spend some time on the contribs, etc. That way, the right can be considered as a "trusted user" flag. Also, bundling will encourage account creators to help at file moves and vice versa. ManishEarthTalk • Stalk 05:29, 24 February 2011 (UTC)
(edit conflict) I'm against bundling those two groups. Strongly so, in fact, because of how fundamentally different they are. Through my work at AfC I've had a chance to talk to several accountcreators, and have come to realize that they neither understand nor have any great desire to work in the areas I work in (files and the smaller namespaces) and I neither understand nor have any great desire to work in account creation. Wikipedia has a number or esoteric areas of work, and several of those areas have various types of userrights (account creator, OTRS access, toolserver access, abusefilter, etc.) Yes, there is overlap, but that's because a particular user in question works in several of those areas. Bundling any of these rights together would just give people additional tools that they don't need or know how to use, and will increase the chances of things going wrong. Right now, with the exception of rollback and reviewer, these userrights serve as tools of the trade for users that are a part of that trade (craftsmanship metaphor.) Combining them into a "trusted user" userright turns them from that into a sort of upper level caste below admins and above everyone else. This isn't their intention at all, and would, for a lack of a better term, be very bad. Sven Manguard Wha? 06:02, 24 February 2011 (UTC)
    • Can I ask why everyone is so opposed to a tangentially related proposal I just noted here? I'm not even trying to push bundling that much, just pointing it out as an alternative to consider later. At any rate, I'd like to see a clear policy on how this would work before supporting this proposal; it seems that very few users would need this so we must have requirements set. /ƒETCHCOMMS/ 16:13, 24 February 2011 (UTC)
  • Who cares - Is being able to move files any more dangerous than being able to move any other pages? IIRC, the right was initially given only to admins because it was a new feature and only lightly tested, so use was controlled. Given the absence of major bugs, I don't see why it shouldn't just be given to all autoconfirmed users. Mr.Z-man 06:00, 24 February 2011 (UTC)
  • Support Oh yes! This will make the moving of images that much easier. No longer will I have to make up some sappy rationale to get an image moved uncontroversially. Kevin Rutherford (talk) 06:09, 24 February 2011 (UTC)
  • Support Very good idea. Armbrust Talk Contribs 06:44, 24 February 2011 (UTC)
  • Oppose bundling of Account Creator As an ACC User and Developer, There are several reasons that account creators have their own permission group. Some of these reasons include that the group allows members to override most blacklists, some abuse filters, anti spoofing checks and rate limits (these are all seperate permissions). These permissions are given to account creators to allow them to create lots of accounts that sometimes blacklists would normally block. If it were to be bundled a person who has nothing to do with ACC wil able able to bypass (ALL) blacklists that are there for good reason for purposes other than to help create accounts for others. Secondly the group is there to help identify those people who are creating lots of accounts specifically for ACC so other people know they are not creating accounts for sockpuppeting, spamming, vandalism or other malicious purposes, rathor as part of thier work with ACC. ACC users are held to strict guidelines regarding how they over-ride anti-spoof, the same guidlines would not be enforced if it were given to non-ACC users. I have to agree with one of the comments above, why would you bundle permissions that have nothing to do with one another? Why create a "lesser admin" group? The current groups are there to serve specific roles and they serve them well.   «l| Promethean ™|l»  (talk) 13:13, 24 February 2011 (UTC)
    • Hmmm, that's a valid point. Another thing is that accountcreators have the 'noratelimit' right, which could be abused through the API (Basically, the user could mass-blank/mass-vandalise stuff and cause a headache for the rollbackers). So I redact my support above for the bundling... ManishEarthTalk • Stalk 13:33, 24 February 2011 (UTC)
      • Yes, Manishearth, because fifty good users turn bad every day. We should not give admins access to Special:Nuke because I might decide to delete all the pages created by Alansohn or someone, right? Your rationale makes no sense. /ƒETCHCOMMS/ 16:07, 24 February 2011 (UTC)
        • Well, the filemover tool bundling would widen the range of users, and, by the looks of it (As my personal opinion is that filemover isn't too dangerous), filemover shouldn't be too hard to get (maybe a bit harder than rollback, but then again, rollback is "free candy"). ManishEarthTalk • Stalk 06:42, 26 February 2011 (UTC)
    • Prom, the problem I'm seeing now is people who still want to acquire as many rights as possible—ACC is an example of this. Obviously, bundling doesn't solve that problem, but in reality, we don't need these separate userrights: ACC can be handled fine by enwiki admins only, as can file moving. It's just more convenient otherwise. /ƒETCHCOMMS/ 16:13, 24 February 2011 (UTC)
      • ₣etch this is a slightly different tune you are singing now that you got admin on ENWP. Have you noticed how few ENWP admins come around to ACC regularly? Right now there are none logged in to the system and i am not on irc to see if any are there. Content writing could be done by admins. It would eliminate the need for most everything else if the wiki was read-only for non-admins. Those wanting all rights will still come around. I still haven't got importer, abuse filter editor, founder, bot, IP block exemption, oversight, checkuser, bureaucrat, steward, or administrator but i hope to get some of them as birthday presents :P
        I thought it was 73 good users who turn bad every day for each user who promises to not vandalise any more if unblocked ;) delirious & lost ☯ ~hugs~ 07:18, 25 February 2011 (UTC)
        • I have to agree with deliriousandlost on this one, it's funny how quickly one forgets the workings of smaller groups like ACC and why certain things are the way they are when one becomes an admin. In any case Fetch you have failed to address any part of my lengthy reasons as to why it is seperate. And to counter your claims regarding the accountcreator user right being flagwhored, you seem to quickly forget that anyone requesting it has to be an active member of ACC who frequently hits the 6 accounts per day rate limit or needs to create an account that antispoof is blocking which makes it hard to flagwhore, you either need it or you don't. Information about ACC users is publicly viewable on the ACC tool [8] and if Administrators (such as yourself) aren't checking that before giving the right to users then that is a failure of Administrators to follow set precedure and your fix of bundling the right will also fail because admins won't follow set procedure and hand out the bundled right to everyone. To me, the notion of giving out a right that allows users to bypass blacklists, rate limiting and anti spoofing to users who dont explicitly need it is the stupidest thing ive heard from an admin or otherwise. Please re-read my reasons above this comment and address them if you wish to discuss this with me further so I dont have to repeat myself. You talk about reality and yet you seem to be very out of touch with it.   «l| Promethean ™|l»  (talk) 01:39, 26 February 2011 (UTC)
          • I know alot of non-sysop users who are getting more experience by using the ACC tool. I'm getting more experience using the ACC tool, deliriousandlost, a tool admin at ACC, a non-admin here has alot of experience on ACC. Mlpearc, a non-admin, is a tool admin and many others such as Alpha Quadrant JoeGazz84 etc. Are you trying to say that just because we are not sysops on enwiki we are not capable of managing the ACC tool? Are you trying to say that we should remove a large handful of fully-capable and responsible users from the tool? --Addihockey10 e-mail 03:29, 26 February 2011 (UTC)
            • Addihockey, I think fetch is trying to say that he is to good for us since he is an admin now. Only admins are capable of anything because we are all just worthless people since we do all the hard stuff and all he does is pull out a damn block page and block some users. We write the content, we handle the stuff you don't want to do. No admin is active on ACC except for stwalkerster. It is ultimately his tool, you can't change who he gives access to, so you can't say that admins only handle requests, he won't stand for that, I know him. Many more users, like Addihockey, Alpha_Quadrant, and Mlpearc and the rest of the team, are WAY more capable at many more things than the admins. Personally, I think most of the admins are lazy, you get the sysop bit, so some easy stuff, most you do is automated. We do the hard work. We are more capable. Fetch, you are not the decision maker. You don't say now just because you are an admin that this doesn't matter. If you were in our spot, as an editor, you would be saying the SAME thing we are trying to tell you. Think about it. I am turning into a Delirious here... ( in a good way )  JoeGazz  ▲  15:01, 26 February 2011 (UTC)
  • Oppose bundling of Account Creator pretty much for what PromCat said; somewhat surprised that Fetch would raise this proposal since i would have thought him to be one to come out against such an action. delirious & lost ☯ ~hugs~ 14:06, 24 February 2011 (UTC)
  • Support filemover, but oppose the addition of the account creator rider. Filemover won't likely be used too much, but it can't hurt to give this right to trusted users — after all, Pagemover has been activated for all active users for several years, and moving around an article is generally more likely to be disruptive than moving around a file. Experience at Commons shows that this isn't likely to be misused. Nyttend (talk) 14:30, 24 February 2011 (UTC)
  • Support filemover per above, and oppose the addition of the account creator rider per Nyttend. --Highspeedrailguy (talk) 17:59, 24 February 2011 (UTC)
  • Support giving this permissi,ion to all autoconfirmed users — why does this need to be a separate permission group at all? Moving a file shouldn't be any different than moving any other page. If someone abuses the ability for vandalism, do the same thing we would do with standard pagemove vandalism: revert the damage and block them. *** Crotalus *** 19:27, 24 February 2011 (UTC)
  • Support any option that gets ability to users beyond just sysops, either through a separate flag, or bundling it on some other (reviewer would work). But not account creator, please, that one gets "hacked" enough with the ability to bypass the title blacklist and create/edit edit notices. Courcelles 20:52, 24 February 2011 (UTC)
  • Support - it'd lessen the workload for admins, which is a good think since admins have more important things to do than to move a file because of a simple misspelling. —Ancient Apparition • Champagne? • 9:20am • 22:20, 24 February 2011 (UTC)
  • Support filemover, but oppose the addition of the account creator rider per Nyttend. I have filemover on Commons and create accounts here, and agree that they are too different to be bundled.   — Jeff G.  ツ 03:42, 25 February 2011 (UTC)
  • Support filemover, per above. Basket of Puppies 04:48, 25 February 2011 (UTC)
  • Support filemover but only if it doesn't go to everyone, for reasons I've explained below. Magog the Ogre (talk) 03:24, 26 February 2011 (UTC)

(edit conflict)

Implementation Proposal: Three month trial as userright

While it hasn't been a week yet, there is an overwhelming consensus to do this, and there are three suggested methods of doing so, as a straight up user right, as part of the autoconfirmed package, and as part of some other rights package. The third option does not necessarily have to be the already panned accountcreator right, it could be another one, however no one has suggested one that received support. Therefore, I'm going to make a proposal that encompasses both of the more accepted ideas.

Since this would be such an easy changeover to make, I suggest that we start off on March 1 by making filemover a requestable userright. The threshold would be that the requesting user can demonstrate a history of either a high level of substantive and useful work in the file namespace, a number of substantive and useful file page move requests, or a history of substantive and useful page moves, as well as the general trustworthiness component that goes with all userrights. This would be on a request only system for three months (all of March, April, and May.) on June 1 another RfC will be opened to assess the successes and failures of the trial, analyze any abuse if it occurred, and decide on whether or not to expand the right to all autoconfirmed users. That seems like a sensible compromise to me. Thoughts? Sven Manguard Wha? 22:41, 24 February 2011 (UTC)

  • Support I see no reason why this shouldn't be implemented. I think we should address the oppose votes above in that they give incredibly valid concerns about why this shouldn't be bundled with another right. I don't think there is any harm letting this be its own right but if we put it in with the account creator right, we are asking for trouble. I know that the support votes above didn't really address bundling the right, but I feel as though Delirious and Promethian's worries are quite valid so we should take them into consideration when deciding whether or not to bundle this. Kevin Rutherford (talk) 01:27, 25 February 2011 (UTC)
  • Support with a suggestion that confirmed filemove activity on another wiki like Commons be considered as a part of the process.   — Jeff G.  ツ 03:45, 25 February 2011 (UTC)
  • Let's not bundle this for now. Let's also not bother with a follow-up RfC; this isn't going to be controversial, and I don't think we need to worry about expanding it to anyone (it's not a big backlog or anything, and Commons' system works fine). I say, go for it but have a drafted policy page up first. Who wants to start that at Wikipedia:Filemover? /ƒETCHCOMMS/ 03:52, 25 February 2011 (UTC)
I agree strongly with FC's request to have a solid (and agreed upon) page put together before we go live. I ripped the heart out of a copy of the autopatrolled page, stuck in a couple different numbers I made up out of my own head, just to have something to start from. Heck, I've used file stuff so rarely that my usage of terms around it is probably not idiomatic. Sven, FC, folks, could someone take a better shot at mine at what the guideline for granting this userright should be? --j⚛e deckertalk to me 04:27, 25 February 2011 (UTC)
I had the same idea but didn't act upon it. As far as it how it reads, it's pretty good right now, as it was written by file people on Commons, I'm sure. I've been tweaking it, but yeah, it'll work. Sven Manguard Wha? 05:52, 25 February 2011 (UTC)
  • Oppose as process creep. I don't think anyone has actually said why this is or might be more dangerous than regular pagemoves. Why go through this elaborate process, or even a minor process like keeping it as a requestable right when there's no actual justification for it? Mr.Z-man 05:09, 25 February 2011 (UTC)
    • There might not be justification for it not being a default, we'll find out during the trial. I would note, however, that almost no one agreed with you when you brought this up the first time, so I'd say that at the moment, there are at least some reservations about just opening the floodgates. Sven Manguard Wha? 05:52, 25 February 2011 (UTC)
      • Did anyone disagree? And if they did, did they provide any reasons? This looks like a convoluted attempt at a pre-compromise to satisfy one side of a possible dispute that may not actually exist. We should start with the simplest possible proposal, then add extra processes iff we don't get consensus. Mr.Z-man 16:06, 25 February 2011 (UTC)
  • For whatever it's worth, I'm mostly with Mr.Z-man on both posts he's made to this thread. If people abuse moving abilities (vandalising or whatever) we have ways to deal with it currently (warning, blocking, etc.). I don't see how moving local files should be too much of an issue. Commons is a different matter because it serves content to all of Wikimedia's wikis (in their various languages, etc.) as well as any wiki running MediaWiki with the proper configuration to use Commons' files. Moving files on enwiki shouldn't be something you have to jump through hoops to be able to, especially since the ability is readily available. Killiondude (talk) 07:44, 25 February 2011 (UTC)
  • Weak oppose for now per Mr.Z-man's argument. There really is no need for a whole new userright. However, this could will lead to more vandalism (i.e., file move vandalism) as a result of bundling with autoconfirmed. Guoguo12--Talk--  21:17, 25 February 2011 (UTC)
  • Support I'd like to answer the concerns of a few of the opposers and explain my (possibly incorrect) concern about attaching this to autoconfirmed. As I understand it, and you are all encouraged to mock me if I've got this wrong, files such as image files essentially share the same space of names between Commons and Enwiki. It is my assumption that in the case of a conflict (that is, the filename existing on both Enwiki and Commons), that articles asking for a file that exists in different forms on both will pull the Enwiki version. The concerning scenario for me is a filemover renaming a file that did not previously exist on Enwiki but to a filename of a different image that already exists on Commons. This is not so much a matter of vandalism (although that could happen) but simply of namespace collisions. Some article, Cats We Love uses Commons/MyCat.jpg. An Enwiki user moves JoeTheCat.jpg to MyCat.jpg on Enwiki. The Enwiki article is now broken (showing the wrong image), and the user who broke it doesn't know he or she has broken the article, and the user who broke it doesn't have the ability to fix the problem they created without an administrator to fix it. Do I have that right? If I have it wrong, and there aren't other unforeseen circumstances, I would support bundling it to autoconfirmed, I'm just not convinced it's precisely as safe as article-move for the above reasons. --j⚛e deckertalk to me 21:38, 25 February 2011 (UTC)
    • Only administrators have 'reupload-shared' userright, which allows them to upload a file with the same name as on commons. Users with without this right will be unable to move a file to a target that exists on commons. Ruslik_Zero 18:13, 26 February 2011 (UTC)
      • Ruslik0, to make sure I understand you correctly, the filemove code as it is now, when run on Enwiki, would know to require reupload-shared for files that preexisted on either Enwiki or commons? If that is the case, and the code already works, then that would address my primary concern with the broader proposal. If we can safely give this right to all autoconfirmed users, I'm entirely in favor of it, but I do want to exercise all due care. --j⚛e deckertalk to me 18:31, 26 February 2011 (UTC)
        • It should require the reupload-shared right in order to move a file over an existing commons file. (I do not know what you mean by "preexisted on 'Enwiki'".) I have not read the code but it is a reasonable assumption that it should work in this way, otherwise we just discovered a serious vulnerability. (See also below) Ruslik_Zero 18:51, 26 February 2011 (UTC)
          • Okay, let me explain again, and thanks for your patience. Filemover code, when run on Commons, only really needs to check if there's a preexisting file of the same name on Commons to do the appropriate tests. That's one check, at most. When we run Filemover code on Enwiki, we need that code to do two checks: there may already be a file of the same name on Commons, and/or there may already be a file of the same name on Enwiki. Note that the code needs to (possibly) do subtly different things depending on which of the two systems it is run on. You're right to say that if that code doesn't work, that's a serious vulnerability, but not necessarily a vulnerability if the code is only run on Commons. Now, maybe that "just works", and it's quite possible that's the case. It's quite possible that I'm worrying unnecessarily. But I'm not willing to assume that without better assurances. I would love to cheerfully support releasing this to all autoconfirmed users, that is my preferred outcome. But for me to really support the wider deployment, I'll want to hear from a developer or someone else close to the source that that extra code is in place and tested, *or* that filemover is already in place and deployed to all users on another language wiki. (Heck, if Dewiki or the like has been giving filemover to autoconfirmed users already, that would handily answer my concerns.) --j⚛e deckertalk to me 19:46, 26 February 2011 (UTC)

My only concern is in regards to a point Joe raised on my talk page, that Commons and Wikipedia file pages layer. If commons has a file with a specific name, it will appear on all other projects with the same name. Take File:Brown treecreeper jan09.jpg from today's main page. It's a commons image, but it appears on English Wikipedia as well. If you created a page with the same name on English Wikipedia, it would overlay the content on the Wikipedia (that's how the FP tags appear on the local page but not the commons page.)

Now the issue becomes what happens if someone moves a different image into something with the same name as a Commons image. I honestly don't remember at the moment what it does, but I'd have to assume it would be a mess.

Finally, if we do allow file moves for all autoconfirmed users, we must remember to protect file pages locally as well as on commons when they appear on the main page, which isn't always done right now, even though it should be. Sven Manguard Wha? 21:51, 25 February 2011 (UTC)

  • Support: I however would like to see it be its own group, not all bundled with Account Creators, that is the worst idea I have seen yet. I speak for me and probably most of the team when I say, we are here to create accounts, that group identifies us. We don't need a non-related right bundled with us. It also allows others to get Account Creator and not use the account part of it, which allows us to override lots of restrictions, which is dangerous for users who do not need it.  JoeGazz  ▲  03:21, 26 February 2011 (UTC)
  • Support. I understand and respect Mr.Z-man's position, but I don't see much of a downside to trying it out on a smaller scale (i.e. editors who specifically request the flag) first, rather than just granting it to everyone regardless of whether they need or want the ability to move files, or have any idea when and when not to do so. I've had to clean up after good faith but poorly-thought-out page moves, and cleaning up after good faith but poorly-thought-out file moves doesn't sound like a good use of anyone's time. That's not even considering image-move vandalism, which is a very real concern. 28bytes (talk) 23:11, 26 February 2011 (UTC)
  • Support. Agree that it should be in its own group, apart from Account Creators. Swarm X 03:48, 1 March 2011 (UTC)

Implementation Proposal: Enable for all autoconfirmed users

Since some people seem to think it's not a big deal, I figured I'd formalize this option. Do see my concern above regarding commons though. Edit: see my vote below. Sven Manguard Wha? 21:51, 25 February 2011 (UTC)

  • Strong oppose - no no no bad idea. Users could then overwrite an image that's on commons, which would be a mess to clean up (moving the image back wouldn't work because it would require an administrator to delete the redirect left afterwards). IIRC, they can't do that (anymore) just by uploading a file on enwiki. Not to mention the disruption caused by multiple moves would be more significant. Take File:Evolution-tasks.png (now deleted) for example
    • In November, it had 5000 redirects (I'm sure there are images with more, but this is the only one I know of). Now say an autoconfirmed user comes along and moves the page, and then vandalizes the redirect to a giant penis.
    • The Mediawiki software must now render all 5000 of those pages again. This probably creates an ugly burden on the software.
    • 5000 pages now all have a giant penis image on them. This is far worse than 5000 redirects, because users don't immediately click the redirect, but they do immediately see the image.
    • A non-admin cannot undo this vandalism. The user will have to place a {{db-g3}} tag on it (whereby the 5000 pages will again be rerendered and this time break the image altogeter) until an admin comes along and can undo the vandalism.
  • Additionally, there are problems with overwriting images that exist on commons. For anybody who's been here for a while, they will know that there are enough clueless editors that don't pay attention to message boxes like "pretty please make sure you know what you're doing before you overwrite the commons image." This could create all sorts of mess for an administrator to clean up, as the admin would have to move the file to a correct location, delete the underlying redirect, then sort through the existing transclusions to figure out which ones are correctly pointing to the commons image, and which were pointing to the incorrectly moved image, and change the latter by hand.
  • This is a bit that should only be given to users that really really know what they're doing (like it is on commons), and which can be revoked due to poor management or mischief. Magog the Ogre (talk) 23:44, 25 February 2011 (UTC)
    • If users can move over an image that they can't upload over, that's a bug that should be fixed. The rest of the issues are not specific to files. For the case of an image used in 5000 pages, the same thing could happen for a template used in 5000 pages. The solution there is to protect the template, why would it be different for an image? Mr.Z-man 00:45, 26 February 2011 (UTC)
    • Which is why we protect those templates. It sure would be an unnecessary burden to have to protect a bunch of images. Frankly, this is a bad idea guys - moving files should only be done with the utmost care. And n00bs are far too careless with this sort of thing. Magog the Ogre (talk) 03:23, 26 February 2011 (UTC)
      • Why does it need to be done with more care than moving any other type of page? If this vandalism risk is actually real, any non-commons image used in hundreds of pages should already be protected because any autoconfirmed user can already vandalize them in a much less convoluted way, by simply uploading a vandal image over them. Do you have any evidence to back up your assertion than new users are too careless with moving pages? There are currently around 100 local images used in more than 500 pages that are not currently protected. The "burden" of protecting these would be minimal. Not that it's necessary though, since there's already over 5000 templates that are used in more than 500 pages that are not protected that we don't seem to have any significant vandalism problems with. Mr.Z-man 17:38, 26 February 2011 (UTC)
  • Support, in consistency with my oppose !vote above. Mr.Z-man is right again; image moving should be be consistent with page moving. Guoguo12--Talk--  01:29, 26 February 2011 (UTC)
  • Support. Filemoving was assigned to administrators only for testing purposes. It has always been an assumption that once all bugs are fixed the ability to move files will be given to all autoconfirmed users. Ruslik_Zero 18:26, 26 February 2011 (UTC)
  • Support - There are no serious risks associate with this that can't already be exploited by regular uploading or moving non-file pages. Pagemove vandalism is an uncommon event and there is no reason to think that there will be a major uptick with the ability to move files. Mr.Z-man 19:41, 26 February 2011 (UTC)
    • Actually, there are. I'm not concerned with vandalism, I'm concerned with people moving images to areas where commons already is using the name, thus blocking out the commons name. Please read the comment above by Magog. This has the potential to cause massive messes, and it's worrisome. If it were a choice between only admins having the right and everyone having the right, I'd choose only admins. The middle ground of a userright is acceptable because in order to get those rights the users have to display clue. Again, I'm not worried about malice, I'm worried about well intended people that don't know how the commons/enwiki interaction works moving things in spite of the warning and messing things up. Sven Manguard Wha? 21:10, 26 February 2011 (UTC)
      • See the comment by Ruslik0 in the section above. This shouldn't be possible, and if it is, it's a major bug that should be fixed before it's given to anyone. Mr.Z-man 21:59, 26 February 2011 (UTC)
        • What would convince me, and might settle this for one or two other people, is a developer or someone familiar with the code saying "yeah, we tested and/or deployed this on a system that isn't Commons", or other evidence it's been deployed outside of Commons, (any system where the code would have to check both for overlapping names locally and separately on Commons). Or a developer saying "yeah, that needs to be fixed, but it's a one-liner and I've got it covered." Any idea of how to approach getting that reassurance? Because we're that close to my supporting the wider release. Sorry to be a pain, but a full-scale zero-to-few hundred thousand users deployment better be precisely right before flip the switch. (Which sounds like a sentiment we're in complete agreement on, we're just quibbling about a few details.) --j⚛e deckertalk to me 22:22, 26 February 2011 (UTC)
  • Strong Oppose Serious concerns over inexperienced users causing damage due to the overlap issue discussed above and at my talk page. Sven Manguard Wha? 21:04, 26 February 2011 (UTC)
  • Second Choice Support While I'd like the comfort of being able to test it for three months as an unbundled feature, (as it right now has never been separated from the 'reupload-shared' right anywhere except for on commons where 'reupload-shared' is moot,) I agree that without the 'reupload-shared' tag, this can't do too much harm. Now mind you we had better make sure that everything works right or there's going to be some chaos. Ultimately, my primary concern is with things that need to be done getting done, so this, I guess, is acceptable. Sven Manguard Wha? 05:52, 28 February 2011 (UTC)
    It may be that the code protects against that issue, we just need to actually get a real answer as to whether it does or not. --j⚛e deckertalk to me 22:24, 26 February 2011 (UTC)
    The answer came from Magog, and is on my talk page. From there "If you try to move a file over one that exists on commons, as an administrator you will get a warning about moving on top of a file that exists on a shared repository. If you click continue anyway, it will move it on top, and the underlying file is no longer visible to enwiki. An administrator can undo this by deleting the existing file, or moving the file and suppressing/deleting the redirect. If non-administrators were allowed to move files, they would not have the ability to undo this, because they would have to tag the subsequent file as {{db-g6}} with an explanation."
    So as you can see, it is a problem. Sven Manguard Wha? 22:52, 26 February 2011 (UTC)
    Administrators have a right (reupload-shared) that allows them to upload over a commons file locally. Other users do not, so they shouldn't be able to move over a commons file. Mr.Z-man 23:01, 26 February 2011 (UTC)
    I just checked on my local test wiki; users without the reupload-shared permission cannot move over a file on a shared repository (Commons). Users with the right (admins) get a warning but can override it. Mr.Z-man 23:23, 26 February 2011 (UTC)
    Rockin'. You have my support, then. --joe deckertalk to me 06:47, 1 March 2011 (UTC)
  • Oppose, partly per Magog the Ogre's concerns. I support Sven's proposal of granting this right on request, rather than to everyone regardless of whether they want it, need it, or know how to use it. Maybe there wouldn't be any problems granting it to all autoconfirmed users, but why not try it out in "pilot mode" first with a smaller group of editors, to uncover and fix any potential issues? I'm concerned that there are things we're not fully considering here, especially regarding potential image-move vandalism. Is someone going to move-protect all the images on the bad image list, for example? I think that's the kind of thing that ought to be considered and decided before expanding the right to all autoconfirmed users. 28bytes (talk) 23:21, 26 February 2011 (UTC)
    All significant technical bugs should be worked out by now; the feature has existed in MediaWiki since January 2009. I'm not sure when it was enabled for admins. There are only 25 images on the bad image list that exist locally (the rest are on commons), so it would not be difficult to protect them. But as I said above, evidence shows it isn't necessary. There are over 5000 templates that are used on more than 500 pages (2 are used on more than 100,000) that aren't protected above semi-protection. Yet, amazingly, they're not targets for vandalism.
    Additionally, if we only give it to people who demonstrate competency when dealing with images, what useful information does that give as to whether it could be turned on for all autoconfirmed users? It's like having a new software interface tested by computer programmers. Their experiences are not going to be very relevant to determine how the general public will react, unless it's so bad that the experts can't use it. But we already know it's not from the rather extensive testing by admins and filemovers on Commons. Mr.Z-man 23:42, 26 February 2011 (UTC)
    All reasonable points. Personally, I'd prefer the right be given to anyone who asks for it rather than people who've demonstrated proficiency; that wouldn't stop vandals, but it would hopefully slow people down who just don't know what they're doing. I've just spent the last couple of days clearing out "== Headline text ==" and "== Heading text ==" from articles, so there is a legitimate concern, I think, about the cleanup that would be required if we enable it by default. 28bytes (talk) 23:51, 26 February 2011 (UTC)
    That's not really a good comparison. Adding "== Heading text ==" in an article is a single button on the toolbar that even an anon can do. Test edits like that are rather common. Users would still have to be autoconfirmed to move an image, so presumably the desire to just randomly press buttons would be much less once they've already created an account, made 10 edits, and been here for 4 days. The easiest way to determine how much cleanup might be required would be to look at how often regular pages are moved incorrectly by people who don't know what they're doing. Mr.Z-man 00:05, 27 February 2011 (UTC)
    I wonder if there are stats available someplace to show reverted page moves. That wouldn't show bad moves of pages that didn't get noticed, of course, but it might be a useful data point. 28bytes (talk) 00:26, 27 February 2011 (UTC)
  • Oppose for now, at least. The issue with moving files is that, to prevent an overwhelming number of useless file-space redirects, we'd need to have all images re-linked (I think this is protocol on Commons?); there is no need to get "exact" titles for files, unlike article titles. Simply put, for most files there is no reason to rename them, other than to create more trouble in the future. Yet, I find it difficult to believe that users will abide by a policy that says, "Do not rename File:RandomBuildingUSA.jpg to File:Random building in the United States.jpg" because it defies common sense at first sight. There's no need, really. /ƒETCHCOMMS/ 21:33, 27 February 2011 (UTC)
    • What? Who cares if there's redirects in file-space? That said, we trust that users will abide by every other policy that exists. Why are non-highly-experienced users so inherently untrustworthy when it comes to file moving that we're practically throwing AGF out by saying "We don't trust you to not screw it up"? I asked a similar question before and never got an answer. Mr.Z-man 22:12, 27 February 2011 (UTC)
      • I'm going off commons:Commons:File renaming, which says "In general, Commons aims to provide stable file names as there might be external file clients and file moving involves significant human and computing resources. Thus renaming should be used with caution." I see no reason why enwiki should not aim to provide stable file names as well (although we don't support several hundred other projects). Also, I think too many useless redirects are bad because commons:Template:Rename directs users to have a bot delink the files in addition to the rename—and if redirects weren't an issue, I don't know why this would be a real problem. Non-highly-experienced users are so inherently untrustworthy because I have seen so many of them not bother to even read policy before doing a score of bad actions, and because my own experience shows that there is so little need for moving files (compare the rename category with RM) that we simply don't need to give it to almost everyone. I don't trust many users with this, just like I don't trust them to rollback or adminship, either. My experience with some users must differ from yours. /ƒETCHCOMMS/ 17:52, 28 February 2011 (UTC)
        • You basically say why we don't have as much of a need to provide stable file names - we don't support hundreds of projects. If people on other sites want to hotlink our images, they already do so at the risk that they may be deleted with little warning. Your argument mainly seems to be "we should do it this way because Commons does it this way." Having a bot go around and bypass the redirects is just stupid. I have no idea why Commons is doing that. If that bot is running on enwiki, it should be blocked immediately for a blatant violation of the bot policy. The "human resources" to move a file are exactly the same as to move any other page, so that doesn't even make sense. If server resources are an issue, the sysadmins will tell us. There's little need for lots of things, but outside of an actual risk, that isn't a good argument for restricting them. This is a wiki, it should be as open as possible. Mr.Z-man.sock (talk) 17:21, 1 March 2011 (UTC)
          • How are double redirects handled in filespace? I can foresee a user moving A.jpg to B.jpg and someone else moving it to C.jpg. Will the image stop appearing on articles that use "A.jpg" when they do that? 28bytes (talk) 18:20, 1 March 2011 (UTC)
    • Yes, I believe the image will stop appearing. I'd just like to see a trial of this with a separate user group, first, before letting all autoconfirmed users do it, however; it seems like a reasonable compromise. /ƒETCHCOMMS/ 04:02, 2 March 2011 (UTC)
  • Weak Support per the test of Mr.Z-man - giving this right here is safer to English Wikipedia than giving this right on Commons, and we need to AGF. People do upload files with really bad names, here and on Commons, and we don't have enough admins (or enough attention and inclination from current admins) to deal with such files (dealing with the uploaders is a separate issue). That having been written, the ability to track what the filemovers have done (via the log requested in bugzilla:27709) would be really helpful before implementation.   — Jeff G.  ツ 03:35, 28 February 2011 (UTC) "Weak" in favor of enabling for rollbackers below.   — Jeff G.  ツ 03:58, 28 February 2011 (UTC)
  • Strong Support I'm against elitism here, and Mr Z-man has shown that the major concerns are non-issues. Choyoołʼįįhí:Seb az86556 > haneʼ 04:08, 28 February 2011 (UTC)
  • Oppose This can make a bigger mess than moving pages, with having to consider Commons conflicts. I'd honestly prefer a separate flag, so we don't end up hacking another flag like account creator already is to let folks mess with edit notices. Courcelles 06:39, 28 February 2011 (UTC)
  • I think it was already intended to be this way eventually. Support. PeterSymonds (talk) 08:19, 28 February 2011 (UTC)
  • Listen to Mr.Z-man. There's no reason to have a new user group and there's no reason that moving files should be any different than moving pages. --MZMcBride (talk) 08:23, 28 February 2011 (UTC)
  • Per Mr.Z-man's posts (and what I said above). Killiondude (talk) 08:31, 28 February 2011 (UTC)
  • Oppose Would prefer a separate flag with a trial run, see my support in the above section. Swarm X 03:51, 1 March 2011 (UTC)
    • Your original post commented on the potential misuse (vandalism). Well currently any autoconfirmed can misuse pagemove abilities in any namespace besides File and Category (and MediaWiki, unless you're an admin, of course). It doesn't make much sense to oppose on those grounds if they can move articles, etc. Meh. Killiondude (talk) 06:19, 1 March 2011 (UTC)
      • The potential for misuse is the same as page moves now, which is precisely why I refactored it ("rewd" meant "reword", though I can understand if it came off as "rude"). I still base my opposition on the fact that I would rather see a trial run in a more limited scope, if you'd like to reply to that position you're more than welcome to. Swarm X 19:52, 1 March 2011 (UTC)
        • That's not really a position that can be argued against. Now that you've removed the bit about potential damage, you're arguing for a limited trial, but you're not saying why we should do that instead of this. Mr.Z-man 02:08, 3 March 2011 (UTC)
  • Support, as my concern is apparently unfounded. For those who missed it, Z-man tested the case that concerned me, and (barring being an admin or a reupload right), filemovers on wikis like are not permitted to move files to destinations whose name matches an existing file on Commons. --joe deckertalk to me 06:58, 1 March 2011 (UTC)

Implementation Proposal: Enable for all rollbackers

It's dead. Drop the stick and step away from the horse.
The following discussion has been closed. Please do not modify it.

This would be a middle ground. We already trust rollbackers more than autoconfirmed users, and autoconfirmed is such a low hurdle. If this goes well, we can always extend to autoconfirmed users.   — Jeff G.  ツ 03:58, 28 February 2011 (UTC)

Implementation Proposal: One week testing period as userright then automatically enable for all autoconfirmed users

Withdrawn Idea
The following discussion has been closed. Please do not modify it.

I might be getting needlessly complicated, but I'd like to propose yet another compromise that will hopefully make everyone happy. If nothing changes right now, my guess is that filemover is going to become enabled for all autoconfirmed users. Since Wikipedia from a technical standpoint is unique from other wikis, even those sharing most of the code, things are a bit less fragile than they appear (see the recent signpost artilce on the HTML5 conversion if you have any doubts.)

What we're proposing has never been done before, and could therefore break in unexpected ways. I think, therefore, that giving a dozen or so users a week to do testing (with a mandate to intentionally push the boundaries and try to break stuff) will give the people worried about the technical or logistic aspects the satisfaction that they need, and will give the plurality calling for the filemover right to be released to all autoconfirmed users the outcome they desire. This option would also give the coders any grace period they need.

To make things clear. At the end of the week, barring the testers coming back and reporting a list of things that are broken (which mind you would be discovered anyways if we don't do this, but in a less controlled setting) the changeover to all autoconfirmed users would happen automatically. The testing phase would be available to anyone that wanted in, however they would be asked to log (somewhere centralized) anything that might be a problem. I know a few admins have mopless alts for public computers, those would be welcome as well.

Really this is the equivalent of sending a test vehicle across a newly built bridge. Every responsible business or institution does this, precisely because the earlier problems are found the less costly they are to fix. The last thing I want to see happen after all this is for the floodgates to open only for the right to get taken back after something big breaks.

Thoughts?

  • Strong Support Sensible, ensures stability while delaying consensus only a week. It's waited years, we can afford a week to make sure things get done right. Sven Manguard Wha? 07:30, 3 March 2011 (UTC)
  • Oppose - There's no way it'll actually go this smoothly, config changes often take weeks or even months before they're implemented. It's also unnecessary. File moving is not a new feature. It has been in the software for more than 2 years and has been tested rather extensively since then by developers, admins, and filemovers on commons. It was considered relatively stable enough to include in the 1.16 release of MediaWiki 7 months ago. I highly doubt we would learn anything new in one more week of testing. Mr.Z-man.sock (talk) 19:25, 3 March 2011 (UTC)
    • I was worried that it was never used on a WMF project apart from it's related suite of tools, except for on commons which operates differently. Also I'm pretty sure that the implmentation for this would take, oh, 37 seconds to do. X! showed me what had to be done, it was just changing four lines of text. Either way, withdrawn. Sven Manguard Wha? 20:28, 3 March 2011 (UTC)

Compromise

It is actually possible to create a separate usergroup for filemover, which is automatically assigned (and implicit) as the autoconfirmed usergroup. However criteria may be more stringent—for instance, 30 days and 100 edits. These can be tweaked later. In the future we can get rid of this usergroup if everything goes smoothly. Ruslik_Zero 20:10, 4 March 2011 (UTC)

That's even more complicated than what I had proposed and then withdrawn. The discussion on implementation is set to close today anyways. Besides, my initial proposal was a compromise, and it didn't go over as well as opening it up to all autoconfirmed users did. Sven Manguard Wha? 20:24, 4 March 2011 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page, such as the current discussion page. No further edits should be made to this discussion.

Add redirectsuppress to the File mover right

I propose that we add redirectsuppress to the file mover right so we could instead of leaving the File:ThisGuyIsAJackass.jpg redirect for an admin to come by and delete the thing. I figure if we're trusted to move images, we should be able to suppress useless redirects. Thoughts? Also, consider bundling this with ALL namespaces? It'll be useful for us non-admins to undo pagemove vandalism, clean up after ourselves and will reduce the burden on current admins. --Addihockey10 e-mail 14:29, 13 March 2011 (UTC)

On the one hand that would be an excellent tool for me to have, these DSC##### image names just need to disappear forever. On the other hand, it's very much a matter of trust, and right now, without naming names, I don't particularly trust some of the 100 or so people that have the right. This is not because they're bad people or because they've done anything specific wrong, but because some of the people with the user right now have almost no experience in working with the file namespace at all. The potential for vandalism, as well as for chaos caused by good faith mistakes, increases if we do this, but the utility of the tool increases as well. I'd be interested in hearing what the community thinks of this tradeoff. Sven Manguard Wha? 05:31, 14 March 2011 (UTC)
Might make more sense to create a new userright "page mover" or something that includes movefile, suppressredirect, and move-subpages, (and maybe tboverride, for good measure) and then develop stricter criteria for granting it. –xenotalk 20:18, 15 March 2011 (UTC)

Share button

Not sure if this has been already proposed, but can't we have a "Share" button to directly share a page on Social networks like Facebook/Orkut? Knowledge is power but the power increases exponentially when it's shared !! — Preceding unsigned comment added by Arnabcse28 (talk • contribs) 12:00, 26 February 2011 (UTC)

It's been proposed quite a few times, declined thru WP:NOTMYSPACE. But, you may use this userscript if you want to enable it for yourself. ManishEarthTalk • Stalk 12:51, 26 February 2011 (UTC)
I think we prefer to limit the sharing of knowledge to those competant enough to copy and paste a URL.©Geni 14:04, 26 February 2011 (UTC)
Wikipedia is a social network wether you like it or not. Its a network and it promotes social interaction between its users. The focus is on the encyclopedia, but that doesn't change anything. Flixster's focus is on movies, Fickr's is on photos, Digg's on news, YouTube's on videos and Wikipedia's on encyclopedia articles. No one refutes YouTube's status as social network just because its primary goal and function is to collect and provide video content. Wikipedis IS a social network and the encyclopedia isn't damaged because of it. Wikipedia has taken steps towards the future like Barnstars, Userboxes, guest books, humor pages and and other things that have nothing to do with the encyclopedia. Does it hurt it? No, it just let's people have some fun and interact in ways the encyclopedia doesn't let them. These people contribute, but they also love interacting and chatting. Just like YouTube's users subscribing to each other's pages and chatting up the comment boards doesn't change the fact that a lot of them upload videos regularly. The day Wikipedia embraces the social network revolution is the day it truly reaches its full potential. Feedback ☎ 05:21, 27 February 2011 (UTC)
Personally I think we should enable a share button, but it would be in the preferences if a user would want to disable it. --Addihockey10 e-mail 05:27, 27 February 2011 (UTC)

Hell No! The separation of WMF project and social network site must be absolute at the development level, or Wikipedia loses essentially overnight the credibility and academic standing it has spent ten years trying to gain. I don't see how this is so freaking hard for people to understand that Wikipedia is not a social networking site. Most Wikipedians are quite happy with the fact that there is no share or like or friend or whatever other buttons on Wikipedia, and that there are no corporate relationships between the WMF and these sites. Wikipedia is an encyclopedia, it shares the knowledge of the world. It can be social in so much as that people work together to improve the project. Facebook is not academic, most of the time it is not even substantive, and it's primary functions are in no way comparable with Wikipedia. If you want a social experiance related to Wikipedia, hop onto the IRC, which at least attempts to be Wikipedia focused some of the time. Sven Manguard Wha? 20:27, 27 February 2011 (UTC) Amazingly, one post works in both sections.

One post in two sections, but I really don't think it's terribly relevant to this section. A Share button would be less about building a social environment around Wikipedia and more about sharing our content with people in increasingly easy ways. What use is compiling the sum of all human knowledge if nobody reads it? (of course, I'm not suggesting that nobody reads Wikipedia, but still) EVula // talk // ☯ // 16:40, 28 February 2011 (UTC)
You'll not meet many people with lower opinions of social networking sites than I have. I would hope that if this passes, it would be very, very low key, and give logged in users the ability to hide it entirely through their preferences. Sven Manguard Wha? 06:15, 6 March 2011 (UTC)

Sharebox is a script that reorders your toolbox. It adds new buttons that make it easier to mail, print or share an article on Facebook or another linksharing service. See User:TheDJ/Sharebox. ---— Gadget850 (Ed) talk 20:55, 27 February 2011 (UTC)

  • This purism about not including share buttons is weird. Scholarly journals do include them, see the right-hand bars on OUP's Bioinformatics and BMC Bioinformatics for just two examples. Being 'scholarly' is not the same as being snobbish stick-in-the-muds like Wikipedians are over this. It'd not harm our credibility one jot to have share buttons for Twitter or Facebook. Fences&Windows 23:53, 28 February 2011 (UTC)
  • Support. The share button is just a button to share our content to other sites, and that's it, just a link. It doesn't make Wikipedia any more or less like a social network. I'd strongly support this feature, it would make spreading the name of Wikipedia much easier... Rehman 11:27, 1 March 2011 (UTC)
  • Oppose Facebook already includes the chance to "share" a link with a friend (to any web site). This generates a link with the page name over it, a small preview of the content, and one of the images included at the site (which the user may select before sharing the link). The result is more or less like this. This requires no work or Facebook-association from the source site, in this case, us. So why bother? MBelgrano (talk) 11:43, 1 March 2011 (UTC)
Mmm, yes, you have that option too... But I still think a link from the source site is a bit easier. And because of that "bit easier", I am changing my vote to neutral... Changed back to Support, per my comment below. Rehman 12:46, 1 March 2011 (UTC)
Have a look at the toolbox of the Hebrew Wikipedia, they have "Share on Facebook", "Share on Twitter", and "Email This". This hints that there is no real problem in having them here too... Rehman 05:37, 6 March 2011 (UTC)
  • Oppose. URLs and Facebook's link-posting function works fine, if you ask me. Guoguo12--Talk--  21:39, 1 March 2011 (UTC)
  • Support - Facebook is already on many other sites, and it's a great way to spread the message. So what if it's a commercial site and it's social networking? Great way to share. That said, I have opted out of this feature myself on Facebook due to privacy concerns (enforced via NoScript on my browser!) Magog the Ogre (talk) 06:53, 4 March 2011 (UTC)
  • Oppose There are tons of sharing utilities, bars, social sites, etc.. To add functionality for one or for all would be to extensive, and the "flavor of the month" always changes. If you like something, just use whichever tool you have to share with friends. Who (talk) 13:19, 4 March 2011 (UTC)
  • Support - I tend to agree with Fences & Windows. Being scholarly is not the same as being old-fashioned. There are even services now like CiteULike specifically for sharing scholarly publications. Nature and journals published by Springer also include some variant of "share" links. The links don't have to be extremely visible, just present. I don't think it's in our best long-term interest to continue to isolate ourselves from the rest of the internet. Mr.Z-man 17:28, 4 March 2011 (UTC)
  • Support While it wouldn't turn Wikipedia into a social networking site, it would only serve to increase visibility of articles, encouraging contribution. I don't think WP:NOTMYSPACE applies here, the ability to share articles on social networking sites doesn't make Wikipedia a social networking site itself. Swarm X 17:39, 4 March 2011 (UTC)
  • Support Wikipedia is not myspace, but to deny the existence of the social web is to miss out on a whole venue of site promotion. Being able to share articles only attracts more readers, and probably over time, more editors too. I don't see a negative. --NickPenguin(contribs) 05:59, 6 March 2011 (UTC)
  • Oppose A special plea to those obsessed with Facebook: Keep it as a separate part of your lives. I use Facebook a little, but there is no way I want to see any connection between it and Wikipedia. Wikipedia is already very well known. A link via a url makes a perfect connect if one is required. HiLo48 (talk) 06:16, 6 March 2011 (UTC)
  • Oppose We really need a button to do this? All you are doing is ctrl+l, ctrl+c, go to facebook (as in type it in to the address bar, not search for it), ctrl+v. The only advantage of doing this via button is to collect statistics on our users as to who is sharing what where. Buttons are in my opinion more work than just copying and pasting, because as of yet there is no standardized way of doing this and you end up having to log in anyways. As such it usually takes me longer to post about something on facebook with a share button than it does to do it manually. --nn123645 (talk) 18:59, 9 March 2011 (UTC)
  • Oppose It's just like the like/dislike buttons above. ~~Awsome EBE123~~(talk | Contribs) 20:36, 13 March 2011 (UTC)
    • No it isn't. The only thing that they have in common is that they're both buttons. The "like button" proposal above is for something that would be completely based on Wikipedia. Mr.Z-man 22:23, 13 March 2011 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_69&oldid=1145855246"