This page contains discussions that have been archived from Village pump (idea lab). 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.
I dunno, but however hard it would be, it's important enough that it should be developed anyway. So, how to attack this problem? Looking at bug 3525, Happy-Melon said that it's a CentralAuth feature request. I will set up a wiki farm and start playing around with it, and see what solutions present themselves. I'm thinking maybe we'll be using SpecialWatchlistQuery. Tisane (talk) 02:04, 7 April 2010 (UTC)
Anti-vandal bot for problematic IP ranges
Vandalism from school IPs has been an issue for a long time. A recent proposal suggested that we should soft-block all school IPs. On that discussion I made a suggestion that got a positive response but was lost on the middle of the main discussion, so I will reiterate it here: an IP specific, aggressive anti-vandal bot for problematic IP ranges. What do you think? Sole Soul (talk) 18:14, 10 April 2010 (UTC)
Makes sense to me, especially given fair testing and logging for review/configuration tweaking. Couldn't Cluebot just do this though? Rd232talk22:33, 10 April 2010 (UTC)
Cluebot is so cautious, you have to raise many red flags to be caught. So adding common vandalism words like "poop" will not get you reverted, unless it is combined with other vandalism signs. Plus, Cluebot is a 1RR compliant. What I propose is that for certain problematic IP ranges we have significantly less cautious bot. This can also lessen the long blocks for some IP ranges. Sole Soul (talk) 09:40, 11 April 2010 (UTC)
Cluebot is somehow customizable, for example it has an 'angry list' of articles here. I suppose it could take into account a list of IPs to revert more aggressively; though another bot could do too. Cenarium (talk) 19:49, 11 April 2010 (UTC)
Publicly-accessible oversight log that provides only rev_id
I recently proposed a publicy-accessible oversight log for auditing purposes, but it was rejected. However, I wonder whether it would be useful to create a public log that merely provides the revision ids of oversighting actions, and nothing else. That way, Wikipedia mirrors can set up bots to monitor the log and delete their copies of those revisions. The downside might be that a rogue mirror might scrutinize the revisions specified in those rev_ids and publicize oversighted content, whereas before it might have just slipped through the cracks unnoticed. There are some sites like Wikitruth that have been critical of oversighting in general, and probably there are those out there who wouldn't feel too many qualms about playing the role of Wikileaks in this regard.
On the other hand, even without such a log, it is probably possible to detect which revisions are being oversighted, if a person really wanted to. If someone had the entire revision history of Wikipedia pages at one point in time, and then checked the entire revision history at another point in time, any revisions present in the earlier version and missing in the later version would presumably have been oversighted. Software could be developed to locate such discrepancies and provide the revision ids.
It seems to me that suppressing information is a losing battle. Information wants to be free, regardless of what our policy may be. Editors should just be careful from the get-go about disclosing their identities and other private information on Wikipedia, because once posted, it might not be possible to redact it from the entire Internet. Tisane (talk) 00:49, 13 April 2010 (UTC)
Circular sources
Is there any policy or discussion about "reliable sources", such as a big newspaper, using Wikipedia itself as a source, and thus creating a circular "verification" for the fact in question? We of course couldn't know for certain that they were using Wikipedia as a source, but it is certainly possible that some lazy journalists would do so.
To give a fairly unimportant example, the Eckhart Tolle page states that he changed his name to "Eckhart" in admiration for Meister Eckhart. This was originally sourced from quitemonk.com, not a particularly reliable source, and it seems like it was probably just speculation, rather than coming from an interview with or statement by Tolle himself. However, USA today have recently also made the same claim, again not claiming that he actually said it in an interview, and I have a strong suspicion that they may have gotten the info from Wikipedia itself! Of course, USA today can now be cited (and I have done so) directly as a "reliable source", creating a now perhaps circular verification of this dubious speculation.
Now, this example is not particularly important, and it may be that USA today actually has a better source than WIkipedia for its claim. However, I would be interested to know if there is any policy already in place with regards to this potential issue, or any discussions elsewhere that you could point me to. Thanks! Gregcaletta (talk) 09:32, 15 April 2010 (UTC)
Always use WebCite when referencing an undated source or any whose content is known to change as the plot thickens (and all other sources too if you have the patience). Then you can link to the dated snapshot and prove that the information existed prior to your edit. ―AoV²13:36, 15 April 2010 (UTC)
It's a concern. "Reliable Sources" shouldn't be relying on Wikipedia, but they sometimes do, introducing potential (or actual) circularity. Unless the RS says the info came from WP, there's not a lot you can do. Rd232talk19:16, 15 April 2010 (UTC)
It would be nice if Wikipedia had its own automatic WebCite bot, and wasn't dependent on anybody else to archive references. It would solve a lot of problems. WebCite doesn't work consistently from what I read. --Timeshifter (talk) 23:49, 15 April 2010 (UTC)
Of particular interest for IMAGE patrollers. I'm aiming for something to place on uploader talk page to alert them to the need to review an Own Copyright status.
Such files should really go directly to WP:PUF. The 14 days that that process allows is more than enough time for the uploader to fix it. By just warning the uploader without tagging the image, we run the risk of losing track of these images. Mr.Z-man23:25, 16 April 2010 (UTC)
I'm happy to apply if that is the consensus. The only reason for the suggested tag was that I noticed that a lot of users have a history of logging in irregularly - every month or so (no examples to back that up, I'm afraid). Appreciate that they can then go through the un-deletion process, but that represents an increase in load on the IMAGE admins (who seem to be a group particularly under pressure). The images in question are already effectively "lost track of" - by applying a tag requesting the correct information, the next editor to stumble on the image is alerted, and where there has been no response, would apply PUF. If so many such images weren't integral to articles I don't think I would have given it much thought. --Haruth (talk) 04:17, 17 April 2010 (UTC)
I thought the whole point of making PUF twice as long as every other deletion process was so that we wouldn't have to go through pointless waiting like that. If these potentially copyvio images are integral to articles, they should be put through the process sooner rather than later. Mr.Z-man04:40, 17 April 2010 (UTC)
Bot to delete very old userspace pages
Suggestion: why not have a bot which deletes very old userspace pages of inactive users. We have precedents now for bot deletion, and the criteria could be really conservative, eg page has existed for 5 years, user has been inactive for 5 years, and nothing links to it. Thoughts? Rd232talk21:51, 9 April 2010 (UTC)
5 or 25 years from now, storage space will be even cheaper than it is now. (Not that deletion frees up any space anyway.) The only point that I can think of would be to prevent extraneous stuff from showing up in searches, but that can be resolved by tightening up one's date/time criteria on searches or simply deprioritizing old stuff in search results. I sometimes find intriguing abandoned stuff in userspace from several years ago that provides food for thought, or simply useful historical information. All in all, I agree with Equazcion's sentiments. Tisane (talk) 22:42, 9 April 2010 (UTC)
The point is that userspace is poorly policed in terms of keeping out spam, BLP violations, old drafts, discarded tests, and miscellaneous junk. Since deletion doesn't actually delete anything (hence you can undelete...), the point is to remove it from searches, both internally and externally. Having a bot of this type would at least draw some kind of a line under these things after a period of time. NB The bot could also handle undeletion requests for any false positives (i.e. pages someone does actually still want around), via a template (which can be mentioned in the deletion log entry) which users can add to the page to put it in a "please undelete" category, which the bot would respect for pages it deleted. Rd232talk23:40, 9 April 2010 (UTC)
Do you run into such junk a lot in your searches? Have we gotten complaints from people who have? I just don't seem to run into it that much, but perhaps our patterns of site use differ in that regard. Tisane (talk) 00:00, 10 April 2010 (UTC)
Well there is WP:MFD which turns up all manner of spam and crap. Also there is anecdotal evidence that a large majority of userfied pages are abandoned; and a lot of Help:userspace drafts which are either abandoned or unnecessary copies from before the page was copied to mainspace. Userspace pages do occasionally show up in external and internal searches; and because we pay relatively little attention to policing it (rightly so), I feel it makes sense to have some automated cleanup of unwanted pages. It certainly does no good to have this old junk around, and it may do some harm. Of course we could start with just having a bot list the pages which would be covered, so we get some info. Rd232talk01:38, 10 April 2010 (UTC)
I'm still not seeing the necessity, and I think the criteria is much too "blanket". Userspace pages are especially prone to orphaning, since they're often only used by the author; and saying they must not be of any use to anyone anymore, or even that they likely violate some policy, just because they're also old, isn't great logic in my mind. Even if they aren't actually used anymore, they may still have historical value, as Tisane points out. I come across something old and abandoned once in a while that's interesting just because it's a window into how Wikipedia users were thinking in a different era of its development. This is frankly a solution in search of a problem, as much as I hate the abuse of that phrase here. Equazcion(talk) 02:07, 10 Apr 2010 (UTC)
Fundamental to this idea is that anything deleted in error (i.e. someone actually does want the page) it can be undeleted on request by the same bot. And this is less a solution in search of a problem than a solution to an extremely ill-defined problem, due to lack of info. Step one would be a bot to collect info on the problem. Rd232talk10:12, 10 April 2010 (UTC)
I'm kinda skeptical as to whether the community would allow a bot to undelete anything without a sysop reviewing and okaying each request. From what I know of the community, it seems plausible that people would (irrationally) end up arguing, "What if the bot deletes old libelous or copyrighted userpages and someone requests undeletion? The bot would restore it!" Tisane (talk) 14:17, 10 April 2010 (UTC)
I don't know what the likelihood of people requesting that would be... but if undeleted pages were listed somewhere for review, we'd be no worse off. If any undeletion had to be manual, that would be more work (albeit I would think it would be very little work, with reasonably conservative parameters). Rd232talk15:25, 10 April 2010 (UTC)
I don't see the need, and text uses very little hard drive space. 10 years from now people will look at it all as historical. Think of it as Wikipedia's Wayback Machine. Some of the stuff in userspace is fascinating. It's a time capsule. Of the list of things you mentioned - "spam, BLP violations, old drafts, discarded tests, and miscellaneous junk" - in my opinion only BLP violations are possibly problematic. BLP violations are buried for the most part if they are in userspace. Since it is in userspace it isn't usually noticed anyway. It is inconsequential compared to all the badmouthing of notable people that occurs on hundreds of millions of other pages on the web. --Timeshifter (talk) 03:42, 10 April 2010 (UTC)
I never mentioned hard drive space (not least because Wikipedia page deletion doesn't save any). Userspace is far too haphazard to be any kind of Wayback Machine analogue - it's more like a rubbish heap; archaeologists may find things of interest in these too - but that's hardly an argument against recycling. Anyway, as I already said we don't really know what's out there - so what about a bot to collect some info and make a list, initially of really old stuff, so volume should be manageable? Rd232talk10:10, 10 April 2010 (UTC)
Getting info is always good. Relevant factors beyond age should be: traffic, vandalism, ranking on various search engines (ours and others), statistics on actual problems with the target pages.
Currently, the only addressable concern I see is search results, which is a question of setting appropriate search defaults. If you're worried about external search engines, adding a noindex seems preferable to deletion. Paradoctor (talk) 11:47, 10 April 2010 (UTC)
Noindex is better than nothing (and could be a first step, perhaps as part of a "this page will be deleted in 12 months" sort of approach), but because some Wikipedia data dumps include userspace, and are used by some Wikipedia clones, it's not a complete solution. Rd232talk15:25, 10 April 2010 (UTC)
Not to appear heartless, but the clone will have to take care of themselves. <soapbox>Especially the spamming scum sites.</soapbox> Paradoctor (talk) 17:20, 10 April 2010 (UTC)
I think you missed the point. Clones appear in search listings, and I don't think noindex carries over to them (possibly it could if they wanted, but then if they take the trouble to use the dump that includes userspace, why would they) - so the userspace junk is still public that way. This is mainly an issue for us, I guess, in terms of BLP. Rd232talk18:21, 10 April 2010 (UTC)
To keep stuff from being indexed via clones, five years is way too much. Five days might work.
"issue for us, I guess, in terms of BLP": Not to disrespect your guesses, but I'd really like to see clear evidence that this is actually an issue. Paradoctor (talk) 18:35, 10 April 2010 (UTC)
So would I. Hence the first step of the bot being to collect info. On the basis of that we might conclude we don't need to do anything; but I don't know what other info source we have to decide that. Rd232talk22:25, 10 April 2010 (UTC)
(unindent) I thought of other reasons why not to delete userspace pages of users inactive for 5 years. We want to encourage people to continue editing, even if 5 years later. It is good sometimes to look at the user pages of contributors to articles. It helps tell where people are coming from in their editing. Some articles don't get a lot of edits over 5 years. It is especially helpful in that case to check the user pages of those who edited the page. I have checked the user pages of many editors in order to get an idea whether or not they are seeking WP:NPOV in their editing. I don't have always have time to follow up on all the references used in an article. It helps to look at the user pages of editors of an article to pick out a few suspicious edits and editors. If I notice a pushy point of view on their user pages, I can focus on their edits and references first. User pages are good for following sockpuppets over time, too. Patterns are noticed in what they write on their user pages, user talk pages, etc.. The more info and evidence the better. --Timeshifter (talk) 01:18, 12 April 2010 (UTC)
All userspace pages including subpages. All of it is useful concerning what I wrote. I thought of other reasons too to keep user pages. Some user pages contain how-to info that people link to. --Timeshifter (talk) 00:01, 16 April 2010 (UTC)
Well such howto pages shouldn't be deleted - but the userspace of a very long-term inactive user is hardly the place for it either. So perhaps very old pages with inward links could be listed so that they can be handled manually. They might well be better migrated to a relevant wikiproject; or maybe the inward links are old or irrelevant and they can be MFD'd. In general, I don't see keeping userspace subpages for the sockpuppet etc reasons you suggest - user pages, user talk pages, and contribs are what matters for that. Rd232talk09:37, 16 April 2010 (UTC)
I think that we should encourage people to come back no matter how long it has been since they last edited. We lost good admins on the Commons because of the new rules requiring a certain number of admin-related edits in the last few months. Many of these decommissioned admins did excellent work even if they didn't have all the time some other admins had. Worst of all some of these decommissioned admins were still editing on Wikipedia. We encourage people to edit in multiple wikis (strategy, commons, meta, etc.) but then punish them when they actually do so, but not frequently enough to satisfy the same people (oftentimes) who encourage people to edit on multiple wikis. --Timeshifter (talk) 01:18, 17 April 2010 (UTC)
Well, I agree, that's silly. But I don't see the relevance; the search criteria should be chosen such that this isn't an issue (and, again, easy undeletion is envisaged). Rd232talk22:21, 19 April 2010 (UTC)
I don't see how search criteria can tell whether someone will come back. Precognitive psychic search? ;) And newbs figuring out undeletion, or knowing that something can be undeleted? I am an admin at Wikia, and editors avoid extra steps. New editors, especially. Every roadblock just discourages more editors. We are trying to implement easier editing, WYSIWYG, etc.. --Timeshifter (talk) 02:22, 20 April 2010 (UTC)
Extremely strong opposeUsers should not be forced to have there userpages deleted against there will, even if they have not edited for 10 years. In fact, I would consider leaving wikipedia if this proposal succeeded. Immunize (talk) (talk) 22:24, 15 April 2010 (UTC)
There is nothing to oppose here. This is a place for discussions only, nothing will be enacted even if all participants agreed it is a good idea. Sole Soul (talk) 22:44, 15 April 2010 (UTC)
Best to comment on the talk page about that. There are existing discussions on that. Equazcion(talk) 23:18, 15 Apr 2010 (UTC)
The point is precisely to avoid "I oppose!!!" comments like yours, and instead have discussion. Why do you oppose deleting very old useless userspace junk? That is the core idea here. Anything deleted would in any case recoverable on request if someone actually cares about it. Rd232talk09:37, 16 April 2010 (UTC)
New page creation throttling for non-autoconfirmed users
Currently users can create new pages in unlimited quantities the moment they create an account. What about throttling the rate at which they can do so, at least til they're auto-confirmed? Limit to 2 pages per hour, say. This would reduce the workload dealing with junk articles created and recreated by people fooling about, but should rarely effect genuine users. And for the genuine users, they don't need to wait long for the restriction to be removed, and they can do help:userspace drafts in the mean time. Thoughts? Rd232talk10:06, 10 April 2010 (UTC)
Are we talking about articles or any page in general? How about limiting them to one article only, for the whole duration of the 4 days? Why would a new user need to create more than one page anyway? I haven't created any article and I've been here for a few months. In any case, it wouldn't do them any harm if they waited for 4 days. --JokerXtreme (talk) 10:57, 10 April 2010 (UTC)
I meant articles. One article for the whole of the non-autoconfirmed period is much too strict I think (putting off genuine users). At any rate most of the benefit from throttling will be attained at a much lower level, eg per hour. Rd232talk15:36, 10 April 2010 (UTC)
I'm pretty sure that if they had to wait 4 days and make ten edits to create a second article, they would be discouraged and just wouldn't create it. And sometimes the creation is timely. I see from time to time new users who create a few good articles in less than an hour, for example this user who created Australopithecus sediba and ~20 minutes later Malapa Fossil Site, Cradle of Humankind. I have seen new users who created several acceptable or even good articles in half an hour. So I think a throttling higher than one page creation per minute would be harmful to our coverage and user retention. Cenarium (talk) 14:01, 10 April 2010 (UTC)
OK, fair enough. There's an easy fix to make the "2 per hour" limit less strict for good contributors in particular: take into account deletions of pages created. In the simplest form, only apply the throttle at all if the non-autoconfirmed user has one of their creations deleted. Getting false positives to zero is always hard and rarely worth it, but that should make it come close. The error rate could be reduced further by focussing on the first hours an account exists, where the most junk is created; maybe other ways too. I do think a throttle is a good idea and it's just a question of figuring out how to configure it to keep the error rate low enough to be acceptable. I also think the ability to create userspace drafts and the relatively short period of non-autoconfirmed status means false positives here imply relatively little harm compared to many other contexts. Rd232talk15:36, 10 April 2010 (UTC)
Along those lines, I think that alerting users when they recreate an article they had created recently and tag those recreations would be helpful. Having done that, if the collected data justifies it, I could support disallowing a second recreation of the article. Though all this would require that the edit filter (another type of implementation would be unlikely in the foreseeable future) can get the recently created articles by a user, with multiplicity, and integrate it as variable. The software can get this type of data, since the extension Special:Nuke does, but I'm not sure that the edit filter could (without major modification), we can always make a request. Now for users who create several articles as opposed (or in addition) to recreating a specific one, it would be more complicated for the edit filter to handle because the checks needed would no longer be only 'local' (it would have to check if pages recently created by the user have been deleted). Cenarium (talk) 00:40, 12 April 2010 (UTC)
Actually, one issue that occurs is that one possible response from junk-creators hitting a creation limit is to hit existing articles instead, which is more likely to be harmful to readers of the encyclopedia. If junk creation is a valve, closing it (partially) could raise the pressure elsewhere. Firmly pointing people hitting the limit to userspace drafts may help, but it would remain a concern to watch out for behaviourally. Rd232talk15:44, 10 April 2010 (UTC)
Do you mean you want to stop vandalism, or just low-quality pages? If it's the former, we have plenty of admins patrolling new pages and CSD. –Juliancolton | Talk13:54, 13 April 2010 (UTC)
I mean obviously speedy-deletable junk; vandalism or mucking about. Yes, we have plenty of patrollers, but any low-cost way of saving work would allow more attention elsewhere, for example helping good faith new contributors develop pages, welcome them etc. That's not an admin job per se, but the sort of experienced users who become admins have a broad array of tasks available if they actually run out of admin stuff (like CSD) to do - including (shock, horror) actually writing content. But the main thing I'm imagining is less time at new page patrol and recent changes being taken up by bad faith users, allowing more attention on helping good faith ones. Rd232talk19:13, 15 April 2010 (UTC)
I suggest a log-only edit filter request, and I suggest 2 exceptions: redirects and pages with in-line citations. Sole Soul (talk) 15:20, 17 April 2010 (UTC)
I seem to remember reading somewhere that nonautoconfirmed users may not create more than 8 pages per day. I'll look for a link... Intelligentsium01:44, 18 April 2010 (UTC)
Edit filter 261, "Page creation throttle for new users", I believe. But upon closer inspection it is actually per minute, and will only stop blatant vandalism. Perhaps a per day functionality could be added to this filter, or adapted from this filter. Intelligentsium01:52, 18 April 2010 (UTC)
I'd be happy to have an edit filter as a start, even if it's log-only or tag-only (at least to begin with). What I had in mind probably goes beyond edit filter capacity, but it would be better than nothing, and maybe pretty useful. It could maybe tag rapid recreations by autoconfirmed users (eg. recreation by non-autoconfirmed user of a page deleted within last hour or even 24 hrs). Could someone more familiar with edit filters propose or implement this? Rd232talk22:39, 19 April 2010 (UTC)
hovering
I was just at <a
href="http://en.wikipedia.org/wiki/Obverse_and_reverse">this</a> page hovered over
a link I thought perhaps I could see the image of the coin without leaving the
page(it didn't happen) so I thought that would be something you could do on the
links to images so users don't actually have to leave the page and backspace to it
to keep reading —Preceding unsigned comment added by 66.176.94.223 (talk) 15:36, 19 April 2010 (UTC)
On a slightly related note, I think it would be helpful to expand redirect links into full page titles on mouseover. Mousing over a redirect and just getting the redirect title, as is the current behavior, isn't really of much use. Equazcion(talk) 16:13, 19 Apr 2010 (UTC)
Yup, I definitely think the default behavior should change. Tooltips that just give the redirect title aren't of any use to anyone, in most cases. Being able to see what the destination page title is without clicking would be infinitely more useful, to everyone. Equazcion(talk) 22:44, 19 Apr 2010 (UTC)
Adding larger images to pages could significantly increase load times, especially for dialup users. One can right-click a thumbnail image to open a larger version in another browser tab. This avoids the problem of clicking an image, leaving the article page, and having to backspace to the page. --Timeshifter (talk) 02:31, 20 April 2010 (UTC)
How to improve Sanskrit Wikipedia?
The state of Sanskrit Wikipedia is far from acceptable. The content is very limited, full of grammatical errors and more often than not contains text in Marathi language.
I propose that we take the help of university professors to provide a better translation and to expand the its scope. I am willing to provide offline as well as online support for it.
I know that this could be done and but I know not about the wikipedia procedures. Somebody kindly tell me what am I supposed to do to get Wikipedia's approval and guidelines for such an activity.
I don't think there's any particular procedure for getting more people involved in editing Wikipedia! There are different approaches; eg Wikipedia:School and university projects may be relevant if you want to involve a class. Google's Kiswahili challenge [2] might inspire similar efforts, but you'd need some organisational clout (a university perhaps) to organise something like that - and that might need some kind of approval from the Wikimedia Foundation. Any other ideas? Rd232talk10:10, 21 April 2010 (UTC)
I think "Wikipedia Academies" have been rather successful in the past. But unless you actually want funding from Wikimedia (which I'm not sure Wikimedia will do), there is no formal process. Mr.Z-man23:22, 21 April 2010 (UTC)
Creating an IRC (or other) feed containing all revision data (including revision text, or diffs thereof) pertaining to items appearing on RecentChanges, in XML format
Earlier I created thesetwo threads and bug 23001 on the subject of making available, free of charge and in a format that can be easily parsed, more real-time Wikipedia revision information to the masses of the wikisphere. This will allow wiki owners to more easily and comprehensively integrate with Wikipedia. I am thinking now that we should create an IRC feed that would contain more data than what #en.wikipedia provides. Our current feed provides the prefixed page title, rev_minor_edit, rev_id and parent_id (in the diff url), user_name, rev_comment, and the change in rev_len. The new feed should basically provide all fields from the pertinent rows in the page table, revision table, and text table, including all of the above as well as page_id, rev_timestamp, rev_user, and of course, the all- important old_text. The bandwidth required could probably be reduced by an order of magnitude by including only the diffs, rather than the full text of each revision.
The goal is to make it possible for a wiki owner to, after importing a Wikipedia data dump, launch an app that will import all the data from the IRC log from changes made after the dump time/date. Then a daemon can be launched to continue updating the wiki based on that IRC feed, and thereby create a database whose contents are basically identical to Wikipedia's. I.e., all primary key values and such would be identical. In this way, anyone who wanted could set up and maintain a completely up-to-date Wikipedia mirror that would respond identically to all queries.
It might also be possible for one such mirror to make dumps of its own database available for download on, perhaps, a nightly basis. These need not be full dumps; they could just be incremental dumps to allow a downloader who has already installed Wikipedia's periodic dumps to catch up with where Wikipedia currently is. These end users need not keep all the primary keys and such identical to Wikipedia's, and in some cases it might be undesirable/impossible to do so. This might be the case, for instance, if someone were creating a mirror/supplement to Wikipedia that contained all of Wikipedia's 6,908,478 articles, plus some articles of their own; since Wikipedia would be autoincrementing and thereby adding new page_ids and rev_ids without regard to what the local wiki is doing, the local wiki would encounter collisions if it tried to keep those keys in sync.
So, I wonder how to implement this? I could set up a bot to keep hitting an API page like this one, changing rcstart each time to get the newer data, and then hitting the API for individual revisions like this. Then I could create diffs and send them out onto the IRC. If I get a dedicated IP address, I can probably get away with running a daemon 24/7, although if the server ever goes down, so will my daemon. So maybe the toolserver should run it.
Does it reduce server load to have wikis pulling data from IRC rather than from RecentChanges? And I wonder if all those diffs would be too much traffic for IRC to handle? If allowable traffic were unlimited, it would be just as well to put the entire old_text for each revision rather than just diffs of it. Thanks, Tisane (talk) 00:54, 23 April 2010 (UTC)
The toolserver will never run this, they have copies of the complete databases (not all of it is available to ts users). Please stop trying to leach off Wikipedia's work. Either just use regular dumps. Any other method would cause too much stress on the WMF servers for no gain. βcommand01:07, 23 April 2010 (UTC)
Freely copying others' work is the whole point of things like copyleft and open-source software, which we have based our project upon. If outdated information were all that were needed, we could just wait around for Encyclopedia Britannica's copyrights to expire, and voila! We would have a free encyclopedia. But that's not adequate to our purposes. Likewise, it doesn't really suffice, for all purposes, to have data from Wikipedia that is several weeks old. Also, the regular dumps put a certain amount of stress on the servers too; what is the difference between downloading, say, 5 GB in one fell swoop and and downloading it a little bit at a time through incremental updates? Lastly, it is only "leaching" if nothing is offered in return to Wikipedia; but many sites like Answers.com that mirrored Wikipedia gave money in return. Also, the more people who use MediaWiki, the better it is for Wikimedia, because a lot of users (such as myself) also contribute software enhancements and wiki-markuped content that in some cases eventually becomes reusable on Wikipedia. Tisane (talk) 01:28, 23 April 2010 (UTC)
Simple explanations, the server that hosts the dumps is not also coping the database, its sole role is to act as a host for the dumps. The only stress on the servers in that case is bandwidth. As for creating the dumps they just take a single database out of rotation and then use it for the dump. That prevents the rest of the hive from being stressed. What you want to do, because you are to impatience to wait a few weeks for a dump is to apply stress to all the servers in order to create a live mirror for your website. What extraordinary need is there that you cant wait for a dump? Your idea of little over longer is not accurate. Those servers that you want to pull from are doing other work, unlike the current method, so your proposing to add additional un-needed stress to the cluster for your own gain? I see plenty of cons and no pros in this case for the WMF. βcommand01:43, 23 April 2010 (UTC)
I was trying to take load off of the servers by putting revisions on IRC for the masses, so that they wouldn't all need to pull data from enwiki. It's hard to tell how much load that might save, without knowing how many users are presently pulling data from RecentChanges in an automated fashion. Also, this has nothing to do with creating a "live mirror" in the sense described at m:live mirror. The live mirrors WMF doesn't like are the ones that hit WP every time a viewer loads a page on the mirror, and thus if the mirror gets hit 50 times a second, it will hit WP 50 times a second. There appear to be about 120 edits per second, so the generation of this feed would require hitting WP perhaps 2-3 times a second, an order of magnitude less than the example above. Being a few weeks out of date doesn't matter unless you're trying to seamlessly integrate with Wikipedia and create a site where editors can view full article histories and whatnot, and the only time they need to jump over to Wikipedia is to make an edit. It is conceivable that such a system could ultimately take load off the servers. (The question of why isane|Tisane]] (talk) 02:09, 23 April 2010 (UTC)
The English Wikipedia gets several edits per second. That 510 bytes also includes some other information as well. Assuming you manage to find some way of condensing the diff that only uses say, twice the size as the total difference in bytes - i.e. it doesn't include an entire line if only one word changes - you would probably need (on average) 3 messages per edit just to include the diff and the information currently included in the RC feed. So about 10-20 messages per second, using what's probably an optimistic estimate. If you want to use XML, maybe double that for overhead (tags, quotes, escaping). Mr.Z-man02:04, 23 April 2010 (UTC)
No offense, but this idea is so full of stupid I don't even know where to begin to describe what a horrible idea it is. QTC02:07, 23 April 2010 (UTC)
Well, the point of posting the thread was to gain input as to the idea's usefulness and feasibility, and the level of interest in it, before putting a lot of work into it, so I guess I have my answer. There's no offense to be taken from the unvarnished truth, and in fact it's more useful than when people hold back. Tisane (talk) 02:13, 23 April 2010 (UTC)
Next time you might want to try posting things like this at WP:Village pump (development). They try to be more optimistic there about new concepts. Equazcion(talk) 02:16, 23 Apr 2010 (UTC)
Going back to the drawing board, I wonder if there is another type of feed that could be implemented? We know that something like this was once useful, and that companies were even willing to pay money for it; see m:Wikimedia update feed service, which is now closed to new customers. Tisane (talk) 02:22, 23 April 2010 (UTC)
My concern is the reliance on diffs to make feasible bandwidth consumption. Mediawiki's diff generation is just accurate enough to offer people a reasonable visual representation of how page content has changed, but I have doubts that it would be viable to tell a server how to change a page to bring it up to date. For that I think you'd need to post the complete latest version of article text on every edit. Equazcion(talk) 02:35, 23 Apr 2010 (UTC)
For that reason, the diffs probably shouldn't be generated through MediaWiki, but should instead be generated by downloading the complete current revision from WP and comparing it to the complete previous revision already stored on the local system from the last time WP was hit. A better diff generator, like the one Apache Subversion uses, could be employed for this. By the way, what do people usually use the present #en.wikipedia for? Tisane (talk) 03:15, 23 April 2010 (UTC)
The main users are those using the Huggle anti-vandalism tool, as well as the anti-vandalism bots such as ClueBot. These tools and bots get the real-time feed of changes from the IRC feed and retrieve the diffs that they need through the MediaWiki API, which runs over HTTP. In particular, Huggle has a whitelist of users whose edits do not need to be scrutinized. PleaseStand(talk)03:50, 24 April 2010 (UTC)
It's actually meant to be free as in "no cost", rather than "free speech", as far as I know. Wikipedia isn't a free-speech area. Equazcion(talk) 21:45, 23 Apr 2010 (UTC)
You're describing free as in cost. Free speech is when you're allowed to say whatever you want, which is something we actually don't allow. Equazcion(talk) 22:01, 23 Apr 2010 (UTC)
It refers in fact to the license status which allows you to do whatever you want with the material* without needing special permission, see free content. The most concise way to make it clear would be linking the adjective to that article, though other options exist. Capital letters would accomplish nothing. ―AoV²10:51, 25 April 2010 (UTC)*offer not valid in Illinois for “fair-use” images.
The issue is less the meaning than the fact that capitalising "free" in this way doesn't distinguish between the two meanings; it will just look odd. Rd232talk22:26, 23 April 2010 (UTC)
I don't think that capitalising "free" reduces the confusion; it just draws attention to it. I don't see the double meaning as particularly troublesome, but it's certainly not something which can be explained by changing one character. Happy‑melon10:39, 25 April 2010 (UTC)
Make contrib and history section links link to the particular revision
I'm referring now the the arrow links "→" that occur just before the header name in edit summaries. In your watchlist, clicking one of these arrows brings you directly to the particular section referenced in the edit summary, rather than the top of the page.
In history and contribs listings, this behavior is pretty much unchanged. The arrow link attempts to bring you to the section referenced in the edit summary -- only it still attempts to do this in the current revision of the page. When dealing with older contribs and history revisions, those sections are often non-existent. To see them, you need to click the date link instead, which brings you to the old revision where the section exists, but it brings you to the top of the page.
I propose changing the arrow links for contribs and history listings to link to the previous page revision, rather than to the current revision. I'm not sure if I explained this clearly, so please let me know if there are any questions as to what I'm talking about and I'll be glad to clarify. Equazcion(talk) 01:54, 29 Apr 2010 (UTC)
Well it's clear to me... even though I had no idea those arrows did anything! I've literally never clicked one before today! And yes, it seems clear they should go to the relevant historical revision, not the current one. Rd232talk06:21, 29 April 2010 (UTC)
I solve this problem (if I understood you correctly) by clicking the diff link, instead of the date link, and then at the top right section of the diff page click the arrow to go to the section. Sole Soul (talk) 11:23, 29 April 2010 (UTC)
Yes, the arrow from the diff page includes the appropriate "&oldid=" in the URL. The arrows from the History page don't. This seems like a straightforward bug, since the date on the same line on the History obviously does include the oldid (i.e. clicking the date takes you to the old version). There may even be a Bugzilla entry for it; if not, does someone want to do it? Rd232talk11:44, 29 April 2010 (UTC)
(To Sole Soul:) That's not quite a solution, though. The point of the arrow links is to get you to the appropriate page and section with a single click. You could also "solve" the problem by clicking the date link and then the section link in the page's TOC (which would actually be faster than your way since it only involves one page load). The suggestion here is to make those arrows actually serve their purpose in contribs and history lists.
RD232, I found out about the arrow links myself because I complained when they removed the links from the section names in edit summaries (there was a time, years ago I think, when those were actually the section links), and was told the links were still present in the arrows. I wonder if I would've realized they were there otherwise, and how many other people are unaware of this convenience. On the bugzilla report, I could probably do this later today, if it's really deemed that uncontroversial.
A potential problem I could see, for example, would be that for recent contribs and history listings, people might actually want to see the current revision in many cases. If you're checking someone's recent talk page contributions, you'll probably want to see all comments made since their contribution; or if checking the contribs of a current vandal, you may want to see the current revision to make sure "everything is okay" in the section they edited.
Once again I'm not sure if I'm making any sense, it's early in the morning and I'm rushing through this to get out the door, but the point is that I can see some dissent on this, and a discussion forming on whether perhaps only "older" contribs/history listings should have the link change to an oldid, while newer ones stay linked to the current revision; and then, what the cutoff point is for "old" and "new". A possible solution would be two section links for each item, one linking to current and one to the old revision. Equazcion(talk) 11:57, 29 Apr 2010 (UTC)
I just want to say that when you click the arrow in a diff, you do not load the page again, you go directly to the section. I agree with you that this is not really a solution. Sole Soul (talk) 12:24, 29 April 2010 (UTC)
To Sole, in my diff view the whole page content isn't loaded, just the diff itself. Maybe there's a preferences setting that has thing working differently for some people. I would need to load up the complete page as a separate step after opening a diff. To RD232, I don't remember why they delinked the section names, if I ever knew to begin with. This was a long time ago so my memory of it is hazy. Equazcion(talk) 16:18, 29 Apr 2010 (UTC)
Well I asked because that's one option: relink that to the historical section, and make the arrow go to the current. (Or vice versa.) Perhaps bake a proposal for VPR, and see if someone remembers why it was done. Rd232talk16:48, 29 April 2010 (UTC)
connect wikipedia with facebook
My name is Gjermund, and I come from Norway!
I have a good idea for you. What if you connect wikipedia with facebook?
Then the facebook users may just add an article from wikipedia on their
profile\wall whenever they find something that is relevant, interesting etc.
What do you think?
Hope this will help you improve and develop wikipedia!
—Preceding unsigned comment added by Euroneme (talk • contribs)
Horrible idea. We have a bot that eliminates facebook in the references, yet the same crowd is being encouraged to add stuff? I don't think so -- the two sites have completely different missions, and thus differences audiences. Conflating wikipedia with the people who do social networking will make things worse for us, not better. Choyoołʼįįhí:Seb az86556> haneʼ15:54, 29 April 2010 (UTC)
We have to look more for quality at this stage of Wikipedia English. However, I can see a merit for your suggestion for other languages with low participation numbers. Sole Soul (talk) 16:12, 29 April 2010 (UTC)
I think it's a good idea. In response to Seb and Sole, we'd be encouraging people to use and link to Wikipedia's information, not necessarily to contribute. That's an online encyclopedia's primary function after all. However I don't think this would be something to suggest on our end. It's more of a Facebook feature idea than a Wikipedia feature idea. Any site is already free to mirror our content; they just have to choose to do it. Equazcion(talk) 16:14, 29 Apr 2010 (UTC)
My impression of "connect" was that Gjermund possibly had in mind Facebook users being able to log in to Wikipedia using their Facebook ID, or something. (Not gonna happen.) Other than that it is, as you say, entirely an issue at Facebook's end to reuse WP content. Rd232talk16:50, 29 April 2010 (UTC)
We have an official iPhone app and plenty of other perks for that closed system. So I wouldn't be too surprised if the foundation was involved with Facebook. Wikinews already has some Facebook integration via the social bookmarking systems and they seem to get the new (untested) stuff first. However, I'm sure that there those here that are worried about repeating Eternal September. — Dispenser03:08, 30 April 2010 (UTC)
Absolutely not: facebook gets hacked more often (and as far as I can tell) is easier to hack than wikipedia. With that installation in place, hackers will be able proceed to vandalizing wikipedia after they're done spamming facebook. It's not for no reason that you need to be autoconfirmed before you can create pages. Choyoołʼįįhí:Seb az86556> haneʼ03:34, 30 April 2010 (UTC)
This page is not for comments which begin with "absolutely not"; no position is absolute as the idea should evolve to accomodate any objections you raise. If after making such accomodations it turns out that the proposal cannot be made consistent with all the objections, fair enough, but the purpose of this page is to allow that opportunity for development.
In the sense that it's easier to steal control of a facebook account, yes, it is easier to "hack" than a Wikipedia account, although only marginally. That doesn't particularly affect our anti-vandalism measures, as the Connect functionality would only affect account creation: rather than having to go through the arduous task of entering a username and password at Special:CreateAccount, you can import those data from your facebook account. Once created, accounts would need to achieve autoconfirmed status in exactly the usual fashion. On the flip side, any accounts connected to Facebook will be (more) publicly identified and identifiable. Fake facebook profiles are pretty easy to spot. I expect we'd see an increasing fraction of petty vandalism coming from Facebook-linked accounts, which is actually no bad thing, as we can report to appropriate authorities in many cases an actual name rather than just an IP. Happy‑melon11:21, 30 April 2010 (UTC)
I don't think sharing logins with a social networking site would be a good idea in terms of sending the right message about what kind of site this is. I'm fine with Facebook integrating with us in terms of using our content; but if someone trying to log in to Wikipedia with no account yet is told "you can login with your facebook account", that already hints something inaccurate about what's expected at Wikipedia, IMO. Equazcion(talk) 11:59, 30 Apr 2010 (UTC)
Yes, I agree - the message sent from integration matters. In terms of pursuing the idea further, we could consider OpenID and Google ID and things like that; but I'm not sure that's worth the effort or a good idea either. At the end of the day, creating a WP account is really easy, and not necessary for basic editing in most cases. There is also the issue of appearing to endorse commercial entities (so Open ID would be more plausible). Perhaps if the original poster clarified their intention with the idea, it would be easier to see how those intentions could be pursued in other ways. Rd232talk12:17, 30 April 2010 (UTC)
This definitely a bad idea. You will inevitably see an influx in vandalism ,because most teenagers use Facebook, and they are the ones who usually add nonsense to articles without regard for consequences. Deagle_AP (talk) 02:34, 1 May 2010 (UTC)
We have moved all userboxes to userspace, so why not move all essays as well? Their presence in the Wikipedia namespace seems to confuse or encourage people to regard or cite them as if they were policy or guidelines. If they were moved to, say, subpages of a nonexistent user like User:Essay (much as we use User:UBX), the collaborative process of editing those essays could continue without any user seeming to "own" or otherwise have editorial control over the essays. Granted, people cite essays a lot more than they cite userboxes, and it might be more cumbersome to type, say, User:Essay/Coatrack rather than WP:COATRACK. The proposed U: namespace alias for User: would help in that regard, and perhaps other types of shortcuts are possible; we might use a (usurped) User:E rather than User:Essay, so all that would be needed would be U:E/COATRACK. Or, we might just have an essay namespace aliased to E:. Or perhaps it would be easier to just move policies and guidelines to their own namespace (e.g. PG:Notability), and leave the essays where they are. Tisane (talk) 19:04, 15 April 2010 (UTC)
Possibly. Clearly flagging in the shortcut to all and sundry (particularly newbies) whether it's a policy or an essay does have some merit, both in principle and perhaps in practice. It probably would have been a good idea to do this originally... But the problem at this point is a behavioural issue (behaviour embedded now) and I'm not sure this tech fix would make much difference. Well, perhaps in the long long term it might (years). I suppose a bot could update all the old shortcuts to E:whatever, which would reduce the transition pain... But breaking all the old shortcuts (which you'd have to) is going to be very painful for those who've been around a long time. Perhaps the transition could be eased further by allowing the old shortcuts across namespace (to the new E: location) for a while, with a bot updating them to the new shortcut. Rd232talk19:25, 15 April 2010 (UTC)
There are occasional discussions on the talk page of the essay template about whether the template should be stronger in noting that essays are not policies or guidelines. The general consensus there is that people do not cite essays in discussions because they are confused of the status but because they agree with the content of the essay and find it applicable to the situation. Like that change, this proposed change would seem to reinforce the incorrect idea that if an argument isn't directly based on a policy or guideline then it has no merit. Mr.Z-man23:34, 15 April 2010 (UTC)
I don't think it's reasonable to suggest that people are generally citing essays mistakenly thinking they're policy or guideline. It must happen occasionally, but surely only by people picking up shortcuts without actually reading the page. And I don't think the proposal is based on the idea that using essays is wrong; rather that it is valuable to be clear about the lesser status of essays. Essays represent a collection of useful thoughts, and can often valuably encapsulate a point. But for those who don't know every shortcut by heart, it may be misleading. Shifting essays to E: space and bot-updating shortcuts (even if the old ones were still working) would reduce that. Rd232talk06:26, 16 April 2010 (UTC)
If citing essays isn't wrong, then why do we need to go out of our way to make the distinction clear? The more I look at this, the more I see a solution without a real problem. Mr.Z-man23:20, 16 April 2010 (UTC)
If going to the toilet isn't wrong, why do we need to close the door when doing so? Seriously, isn't it clear from the above that the issue is being (unintentionally) misleading in citing essays, particularly with shortcuts to policies, guidelines and essays equally being WP:whatever? Rd232talk21:41, 19 April 2010 (UTC)
No, it isn't clear. If people aren't going to take the time to actually look at linked pages, I don't think we should go out of our way to encourage their laziness (especially at the expense of making things difficult for other people). For the most part, whether something is a policy, guideline, or essay, is irrelevant; what matters is the strength of the argument, not the tag on the pages it cites. As for your analogy, defecating in public is wrong. But we already have a door, this proposal is just to make the door bigger and harder to open, or something like that. Mr.Z-man00:59, 20 April 2010 (UTC)
Well, let me give a perfect example: I've just seen someone add a header "Related information", referring to "WP:NAVHEAD" in the edit summary. Sounded like a new part of the ever-expanding MoS guideline, or a separate guideline page, or whatever. But I take the time to click on it, to find it's a (short) essay. Now, {{essay}} tag or no, what conclusion do you think the average user comes to here, if they even get this far? It's hard enough for me to judge (looking at history and talk page) how much support this has. How is the average newbie expected to interpret this? Also, to return to the metaphor, {{essay}} is not a door. It's a sign inside the toilet that says "This toilet includes one or more Wikipedia contributors going about their business. In many cases contributors will close the door, but door-closing may represent widespread norms or minority viewpoints. Consider these views with discretion." huh? do I close the door or not? Do I ignore them, or join them (if we imagine a communal Roman toilet - look it up), or encourage them, or hand them a newspaper? Clear as mud. Rd232talk07:52, 20 April 2010 (UTC)
Z-man. This is untrue in my opinion: "For the most part, whether something is a policy, guideline, or essay, is irrelevant." If it were irrelevant than we wouldn't need policies or guidelines. Everybody could make up the rules (via essays-I-wrote-today). --Timeshifter (talk) 11:21, 20 April 2010 (UTC)
The "rules" are just arguments that have wide acceptance. Once people stop supporting a rule, it is no longer a rule. Mr.Z-man12:12, 20 April 2010 (UTC)
This is true. Which is precisely why it's important to be clear about the status of pages. As noted above, it's not clear at all from shortcuts, and the meaning of "it's only an essay" is not at all clear on the page itself. QED: essays should have their own namespace, and maybe their status clarified in other ways (suggestions? start with editing the tag, maybe). Rd232talk14:14, 20 April 2010 (UTC)
If anything, I think we need to make the distinction less clear, there are many people who act like essays have no use whatsoever in an argument regardless of relevance or if the essay is based in policy simply because the essay itself is not policy; if you cite an essay, your argument is invalid. Similarly, there are people who act like policy is holy scripture that represents universal truth on Wikipedia (I've seriously seen people oppose a policy change because it would require changing a policy). Making the distinction more clear would only serve to exacerbate these issues. Mr.Z-man14:53, 20 April 2010 (UTC)
Well I see your point, but obfuscation is not the answer - especially as I think a large part of the reason people so often say "that's just an essay" is because it's not self-evident from the shortcut! If the shortcut was E:whatever instead of WP:whatever, people would be more likely to understand the reference as a shorthand expression of opinion (once they get E=Essay, which is a whole lot easier than learning X million shortcuts), and less as an attempted declaration of a rule. Perhaps we should think about how to make the status of all pages clearer, both absolutely (in what way or to what extent does it represent consensus) and relatively (how interacting with policy). All essays are not equal, for instance; isn't there some way to clearly account for this? A start, perhaps, would be making WP:ESSAY a clear guideline, with the content of Wikipedia:The value of essays a good starting point for that (the current WP:ESSAY is more of a how-to - not very helpful for the issue at hand). Rd232talk15:51, 20 April 2010 (UTC)
If you make it clear from the shortcut alone that something is an essay or a policy, you're just making it easier for people to dismiss arguments (or accept them as fact) without actually looking at the linked page to see if it really applies to the situation. We want (or we should want) people to actually understand the arguments people make, not to just weight them based on how many essays and/or policies they can link to. Mr.Z-man18:45, 20 April 2010 (UTC)
I don't disagree that we need to try and get people to use references to policy, guidelines, essay and fact more constructively - not trying to bludgeon people with alphabet soup. But I cannot see how obfuscating the nature of those references helps in that cause - quite the opposite, when it comes to experienced POV-pushers talking to newbies. As noted above, I think part of the reason people dismiss essays is because they initially assume it's a guideline or policy (WP:MUSTBEIMPORTANT), only to discover that it's "just an essay" (meaning what, incidentally? 1 bloke this morning, or long-established line of argument? newbie confused...). The feeling of being somewhat mislead (by the shortcut) harms engagement with the point the essay makes. Bottom line: no matter what other problems exist and will remain, I cannot believe that the obfuscation involved here is a net good thing. Rd232talk19:56, 20 April 2010 (UTC)
Again, how will making the distinction clearer help there? Why do you think people assume that everything that begins with "WP" is a policy or guideline (only a fraction really is)? I think people feeling that "essays" have no weight because they are not policy makes more sense than people just being annoyed that they were "deceived" by the link. Your argument does not address the fact that there are people who know full well that something is an essay (experienced contributors) and still dismiss it simply because it isn't policy. Experienced POV pushers are always going to be able to push newbies around and intimidate them; they don't need to misrepresent essays as policy when they can just misrepresent policy. Mr.Z-man01:20, 21 April 2010 (UTC)
I think I've made my point quite clearly enough on how making the distinction clearer will help. Essays should be properly understood as encapsulated opinion; by referring to Essay X, I'm saying X. But by having it in WP space, it seems (in practice) to be declaring it a certain authority (like policy/guideline), and people complain and reject that (and end up ignoring the actual point X). I do think being clearer about this will make essays more useful, because references to them will be more clearly understood as shorthand opinion. Anyway, it seems I cannot persuade you of this, and you have not offered anything constructive on this subject, where we seem to agree there are issues - how about it? This is supposed to be a creative forum. To answer your "why" question, I think people make this assumption based on my experience of having been around WP a long time. Rd232talk10:04, 21 April 2010 (UTC)
I've not offered anything constructive? What? What have all my replies been then? Vandalism? I'm sorry, I didn't realize that "creative forum" meant "everybody has to agree." I guess I just haven't been around WP long enough. Mr.Z-man14:08, 21 April 2010 (UTC)
Don't get touchy, I mean you haven't offered any new ideas. That's what "creative forum" means - not merely saying "no... because" but "oh, but how about..." Rd232talk17:14, 21 April 2010 (UTC)
Why? Why does everything have to be a new idea? Sometimes we don't actually need change. Perhaps I'm misunderstanding the purpose of this page, I thought it was for extended discussion of proposals before it goes to the community for a wider discussion/vote for actual implementation. You seem to be suggesting that this is only for people for people who agree with the proposal to build it. I really cannot think of a way to make this proposal acceptable to me that wouldn't have the effect of changing the entire spirit of it. Why does that mean that my input should be considered not only unwelcome, but actually "unconstructive" (since my comments are clearly not neutral, that would imply that they are destructive)? If this page only exists for supporting all the proposals, then I will no longer continue commenting here (since I'm apparently not welcome), if you do actually welcome criticism, then perhaps you may wish to amend your earlier comment (and it did come off rather rude/condescending). Mr.Z-man23:07, 21 April 2010 (UTC)
Calm down guys. Mr.Z-man you always give me hard time to prove my case when I suggest a new idea, and that is why I appreciate your input very much. This is similar to the inclusionists/deletionists debate. I always think, if DGG (one of the most respected editors) thought an article should be deleted, then it almost always should, and if Mr.Z-man thought a new idea is a good idea, then it almost is. As you said sometimes we don't actually need change. Sole Soul (talk) 00:29, 22 April 2010 (UTC)
Well I'm sorry if I upset you, that was not my intention. To try and be even clearer than I thought I was already being (textual communication, eh): obviously all kinds of comments are welcome; but as long as there is agreement on there being a problem (essays are cited and used in misleading ways), then critiquing a specific idea or solution ought at some point to segue into trying to come up with alternatives (either variations, or something completely different). (Alternatives needn't even be particularly realistic, in this VPD environment - as long as it's attempting to be relevant and helpful some good may come of it, eg in terms of inspiring something which is realistic.) Example: "no matter how much you think a chocolate teapot is a fine idea, I don't (for reasons X,Y,Z). However I get that you're trying to produce chocolatey tea, so why not just make tea in an ordinary teapot, and then stir some chocolate in? Personally I think the result will be disgusting but if you're willing to test it on a limited scale, go nuts." Rd232talk16:07, 22 April 2010 (UTC)
So then it is the second option? People can only comment in support of an idea, even if they disagree with not only the idea itself, but the underlying reasoning? Mr.Z-man17:12, 22 April 2010 (UTC)
Yes, that's correct. Also, you must email the proposer a chocolate teapot, by way of compensation for not improving their idea such that it instantly solves all of Wikipedia's problems. .... sigh. I cannot make up my mind whether it's really possible that you don't understand the very simple point made. Let's try one final time: the premise until now has been that the discussants at least vaguely agree on an objective (here, better use of essays), but disagree about the merits of the proposed strategy for achieving it - with the key point that the discussants should then try to contribute to improving the strategy or coming up with alternative strategies. (This does not mean any particular person doing all the work - this is a collaborative environment.) However if that objective is not shared, say so, and explain why. Possibly substitute a better or more important or more urgent objective. Rd232talk00:18, 23 April 2010 (UTC)
What? So if I disagree with the basis for the proposal, I have to propose something completely different in the middle of the discussion? Are these rules written down somewhere, or are you just making them up as you go? Mr.Z-man02:23, 23 April 2010 (UTC)
Since making the same point in ten different ways doesn't seem to be getting me anywhere, I might as well just quote myself: "However if that objective is not shared, say so, and explain why. Possibly substitute a better or more important or more urgent objective." Rd232talk13:38, 23 April 2010 (UTC)
If bots could go around and update all the links to essay pages then I would support moving essays to another namespace (but not userspace). Otherwise, all the broken links would be too disruptive. Some people outside wikipedia link to some essays such as Wikipedia:Advertisements. So, I believe there needs to be at least a disambiguation page, or a soft redirect left on the essay pages. The essay pages are in Wikipedia space (WP:). So, cross-namespace redirects are less problematic. At least soft ones. --Timeshifter (talk) 00:33, 16 April 2010 (UTC)
I think the essay template is doing the job. Being consistent about namespaces is important, so either we designate a namespace for the various types of process pages, like a policy namespace, guideline namespace, essay namespace etc. (which I think is less optimal) or we should keep the status quo. Sole Soul (talk) 05:50, 17 April 2010 (UTC)
See above. The issue is being (unintentionally) misleading in citing essays, particularly with shortcuts to policies, guidelines and essays equally being WP:whatever. And even then, a template is a weaker signal than namespace of the difference between long-established consensus policy and essay-I-wrote today. Rd232talk21:41, 19 April 2010 (UTC)
It's disingenuous to work on the basis of there only being two or even three 'levels' of regulations on Wikipedia. We work on the basis of consensus: the 'rules' are what people agree on. The more agreed-on a point or procedure is, the more prestigious its title, but there is no lower boundary between things that a couple of people think are sensible (random essay) and things that a lot of people think are sensible, but which aren't quite important enough (or run up against the CREEPists) to become guidelines. Essays like WP:DEADLINE, WP:CRUFT and WP:ATA, are as widely-cited as guidelines in their own right, and rightly so, as they have had as much input and consensus-building as a guideline. WP:COATRACK, WP:SPA and WP:LAWYER are valuable extensions to well-established policies and guidelines (WP:NPOV, WP:SOAP and WP:POINT, resepectively). Conversely, while A warning to concert organizers, | and Wikipedia:Beef up that first revision arguably contain useful advice which editors would do well to think about, there's no question that these areas are too niche or informal to deserve widespread citation. Then there are, of course, the areas which are genuinely disputed or disputable: Assume clue & Assume no clue, WP:SPADE & WP:NOSPADE, You do need to cite that the sky is blue & You don't need to cite that the sky is blue; and various essays in direct contradiction to policies and guidelines such as Embrace weasel words, WP:VINE and Bots are annoying.
It's not constructive to sweep out all essays, because asserting that citing essays in discussions is uniformly bad is misconstruing what such a citation actually means. By citing a policy, guideline or essay, an editor is not saying "X says we must do Y" but "there is an argument that we should do Y, which is explained better than I can in X". The strength of an argument is not a binary quantity, it has degrees, and so do essays.
I think we need to be more aggressive in our management of essays, at both ends of the scale. Essays are a valuable resource, but like so many other things they range hugely in quality. The creation of new projectspace essays should be frowned upon unless one can demonstrate that the topic really is a collaborative effort, not a single point of view. Userfying essays at the 'bottom' of the range improves the reputability of those essays which are genuinely credible. And no userspace essay should have WP: shortcuts. But blanket-banishing all essays to userspace is not at all constructive, unless you genuinely do intend to banish WP:RBI, WP:BEANS and WP:BASH along with them. Happy‑melon20:28, 21 April 2010 (UTC)
Well, I appreciate some new input, even if you haven't read all the WP:TLDR above... :) - nobody is "asserting that citing essays in discussions is uniformly bad", or anything remotely like it. The issue is being clear about status, particularly in shortcuts. And, yes, it would be helpful to at least limit WP: essays and shortcuts to widely recognised essays, with essays living in userspace by default. If we had a centralised way to approve an essay as good enough for WP:space (i.e. demonstrate enough consensus that it's useful enough), that would help limit the proliferation of essays. But it doesn't address the problem that WP: shortcuts are misleading, wherever they point (and perhaps they shouldn't really be pointing across namespaces at userspace essays...). Hence I think E: space is a good idea (and we can still limit that to "essays with some kind of consensus", for the proliferation issue). Otherwise, maybe we can at least introduce U: as a shortcut to userspace, so that at least essays in userspace don't wear the "WP:" badge in shortcuts. Rd232talk21:04, 21 April 2010 (UTC)
I did read it all, actually, although I agree it was almost as verbose as my own comment :D. The proposal, and its reactions, are to move/rename/repatriate "all essays", to tar them all with the same brush. I admit it is only a general sentiment that that brush is a negative one. I agree that we need to be much clearer about what is a consensus-based topic and what is just a solitary opinion. I don't think that treating all essays as 'below the salt' is the right way to go about that, it's just throwing the baby out with the bathwater. I don't see a problem with WP:BLOCK, WP:LINK and WP:RBI all having shortcuts in the same space. I do see a problem with shortcuts like WP:COAL, WP:CONLIM, etc, sharing that space. Any shortcut link should be interpreted as an invitation to read whatever is on the end of the link, not as an object in its own right. Any writing which has a reasonable consensus, even if it's not enough for guideline status, is worthy of being read in that fashion. Anything that's just something someone wrote down one day can be just as easily written down in the discussion itself; the point is that the linked-to page describes the concept better than an individual editor could, which for monologues is manifestly not the case. Happy‑melon22:19, 21 April 2010 (UTC)
"Any shortcut link should be interpreted as an invitation to read whatever is on the end of the link, not as an object in its own right." - sure - but I think it would be helpful for the nature of that invitation to be clear. Also, the way discussion often works, people don't always follow every unfamiliar shortcut (especially when it's a seemingly self-explanatory one, or seems clear from the discussion context). I don't think moving all essays to E: space is "tarring them with the same brush" - it's a reality that essay has a lower status than guideline! And some should be moved to userspace, and get a U: shortcut instead. Some - particularly "supplemental essays" - could maybe be kept in WP space. but perhaps the nub of this - and easier and quicker and less controversial to implement - is some central place to discuss essay status etc (unless this exists already?). Could be a WikiProject I suppose. Rd232talk23:06, 21 April 2010 (UTC)
What's the difference in the "nature of the invitation" between a good essay and a guideline? People making a judgement about the applicability of the principle without actually reading the page is something we want to discourage, not facilitate. It's also a reality that guidelines have lower status than policies; but are we going to clearly differentiate between them as well? It's not necessary, because both are appropriate to cite in discussions; and it's the same with some good essays.
"It's also a reality that guidelines have lower status than policies; but are we going to clearly differentiate between them as well?"
Yes. More clarity is good. People have limited time. Policies must be followed. Guidelines should be followed. WP:IAR can trump them at times, since no rule can possibly cover everything.
Essays are essays and vary in how much agreement there is concerning them. Some tag teams seem to have pet essays they sprinkle around to intimidate people. Happens frequently. Alphabet/acronym intimidation should not trump common sense spoken in English any newbie can understand on article talk pages. --Timeshifter (talk) 10:37, 22 April 2010 (UTC)
Yes, that's the key underlying concern, here: newbies getting put off by a sea of jargon (including talk page passers-by who might consider participating in editing/discussion, but find it impenetrable). Some of it is irreducible, but some improvement may be possible. And we must take into account that (a) in real life people frequently don't follow every shortcut (or they may follow it once and not remember); (b) they may not be clear on the status even if they do follow it. Even the people using shortcuts may have forgotten what exactly they're linking to (or even link to them without ever reading - just picking up from others' use). Devil's Advocate: ban shortcuts to essays! At least if the full title had to be given as the wikilink, it would be clearer from the text what was going on. Less dramatically, make the shortcuts clarify the status of the destination. WP: for policy and guideline and maybe consensus "supplemental essays"; E: for more polemical/opinion essays agreed to be useful; U: for userspace essays-I-wrote-today. What harm from this? Rd232talk16:07, 22 April 2010 (UTC)
A policies and guidelines namespace
There are so many WP: shortcuts of all kinds that I think it would be simpler and clearer to create a policies and guidelines namespace.
There are WikiProjects, labs, and everything else imaginable with WP:SHORTCUTS. Resource pages, you-name-it.
But it's taken, and used for far more than essays. It would cause less disruption to create a new namespace just for policies and guidelines. People will adjust to it more easily since there is less they have to remember to change. There are far fewer policies and guidelines versus essays, etc.. Wikipedia space (WP:) has shortcuts for so many different types of pages. That whole acronym soup confuses newbies greatly. A namespace just for guidelines and policies would help flag the attention of all editors to what is more important. --Timeshifter (talk) 04:36, 24 April 2010 (UTC)
And I'm less concerned about wikiprojects and things like that having WP: shortcuts as well as policy because I think it's generally clear from the context that it's a very different sort of destination than a policy or essay. Also changing the shortcuts for policy and leaving them the same for essays is unfortunately perverse in terms of people needing to relearn shortcuts: the more important ones should stay the same. Also, policies and guidelines for me fit more essentially into "Wikipedia:" space than essays, so I'd rather move the latter out from that point of view as well. Finally, all of Z-man's issues with E: space would seem to apply to this approach as well. Rd232talk09:08, 24 April 2010 (UTC)
It might be best to move everything. Essays to Essay:, policies to Policy:, and guidelines to Guideline:. It might be a pain in the neck if something gets promoted/demoted, though. But I don't think that will happen very often. Hmm, another downside is that some people might not remember which are the policies and which are the guidelines. But maybe this will help them remember! Are there any wikis that have tried something along these lines? Tisane (talk) 03:27, 25 April 2010 (UTC)
I don't think people will accept this, not least because pages do change status between policy and guideline occasionally: it's far from permanently fixed. Anyway I don't see the advantage in splitting Policies and Guidelines - PG: space is a better idea than that, being simpler. Rd232talk08:08, 25 April 2010 (UTC)
A policies and guidelines shortcut format
Maybe we could have MediaWiki automatically make the new namespace shortcuts bold red (maybe underlined, too). PG:NPOV. PG: for Policies-guidelines. Or just P: for Policies. P:NPOV. It could be made clear that the policies namespace also includes guidelines. --Timeshifter (talk) 04:36, 24 April 2010 (UTC)
I don't think any form of autoformatting is going to happen; let's not get sidetracked with that (start a different section if you want to pursue the thought). Rd232talk09:08, 24 April 2010 (UTC)
OK, I started a different section. I now think that this may be the easiest solution. Rather than create new namespaces for policies, guidelines, essays, etc., it would be a lot easier if people could keep using the same WP namespace for everything, and use the color of the shortcut to indicate policies and guidelines. WP:NPOV.
The software would detect policies and guidelines shortcuts and add the color and bold format. Similar to how ISBN and PMID numbers automatically generate a link. See WP:ISBN and WP:PMID. These "magic words" cause the software to automatically format the number into a wikilink. See also Help:Magic words for other similar automagic formatting.
This would serve another purpose. People oftentimes just write NPOV or WP:NPOV without adding the brackets to make them into wikilinks. Autoformatting would solve that problem. This would greatly help newbies wade through a sea of jargon and acronyms thrown around at times. The linking helps greatly. --Timeshifter (talk) 05:45, 25 April 2010 (UTC)
Hmm, autolinking might be enough of a selling point for this to have a chance. (On the other hand, it may result in sprinkling many more bluelinks than the writers want.) But in terms of clarity, I'm not sure that autoformatting is the answer - how easy will it be for newbies to understand the formatting code? And you have to balance that against a very substantial annoyance factor of stand-out formatting the writer didn't intend and doesn't control. I wonder if autoexpanding and autolinking abbreviations could be the answer, but only under certain conditions: like WP:NPOV which suggests a possible linking intention, but not NPOV (mere reference). There could be an "autoexpand shortcut" instruction, like if I type WPx:NPOV, the bot will autolink and expand to Wikipedia:Neutral Point of View. OK, that doesn't really satisfy the objective of the formatting proposal (show what type of thing the destination is), but it's something possibly helpful in this area :) And in combination with namespace sorting, it would help clarify things. Rd232talk08:17, 25 April 2010 (UTC)
WP:NPOV. This link is clickable. I guess the underlining is overkill, so I removed it. Also, green might be less intrusive than red. :)
Newbies would not need to learn any formatting for this to work. To see an example of how it would work type ISBN followed by 10 or 13 digits, and a link is automatically created and formatted. See WP:ISBN for more info. Paste the following into an edit window, and preview/save it:
ISBN 1234567890
It produces ISBN 1234567890 - It is not a valid ISBN number since I just picked the numbers randomly. But it illustrates the auto-formatting. Note that the formatting is not visible in the wikitext after saving, and going back to edit mode. There are no brackets around ISBN or the number. --Timeshifter (talk) 09:01, 25 April 2010 (UTC)
Yes, but that's done in software (Wikipedia:ISBN), and that massively increases the implementation time for anything. That's why I was thinking of a bot. Also I don't think any kind of formatting for this will be accepted at WP:VPR - but I know colours won't be. I also think that it makes too big a deal of the difference between policies, guidelines, and essays: we want to be clear about what the target is without jumping up and down and distracting and annoying people. It's a delicate balance, but I think formatting is probably not going to fly as signalling. (Of course autolinking introduces its own formatting, but it doesn't distinguish target type.) I think namespaces are the way to go to signal target type. Rd232talk09:32, 25 April 2010 (UTC)
magic links (things which are automatically and unavoidably linked from plain text) are out of favour with the developers and no new examples will be added. A namespace or pseudospace is probably the best bet. "PG" is not an ISO language code, so would be potentially available for this. Happy‑melon10:32, 25 April 2010 (UTC)
It's a fairly simple and common request [3]; the namespace would function just like the Portal: space. It would have to have a 'long' name, and the PG: alias. The biggest challenge will be deciding on a sensible long name for the namespace. Happy‑melon12:14, 28 April 2010 (UTC)
Yes, I think so. I guess this would be proposing "Policies and guidelines" pseudospace and PG: pseudospace for shortcuts, and moving policies and guidelines there; and/or "Essay" pseudospace and E: pseudospace, and moving essays there. Do you want to draft it here? Rd232talk15:41, 28 April 2010 (UTC)
Someone can feel free to draft a proposal. I don't have the time to do more than comment now and then. I suggest aiming low at first. A "Policies and guidelines" namespace, but indicated just by Policies:
Asking for an Essay: namespace at the same time might be aiming too high, and asking too much of the people at VP-proposals. Also of average editors. It will be hard enough getting editors to start using PG: for policies and guidelines. --Timeshifter (talk) 19:45, 28 April 2010 (UTC)
"hard enough" depends on the timescale. On a scale of 1-2 years it doesn't seem so hard. Stop advertising the old shortcuts and have a bot automatically replace existing and new uses of old shortcuts (or references to the full page name, which would still work as a redirect), and gradually and relatively painlessly people will absorb the change. And for new editors, they won't ever have known the old way. Rd232talk12:23, 30 April 2010 (UTC)
I think it would be great to separate out the file save functions from the publication function. Why? Because people need time to construct worthy articles. Sometimes, editors look at a piece before it is really ready for the "reality check," causing worthy articles to be deleted, and, increasing editor workload.
Greater accuracy of editorial decisions would be made if authors could develop pieces over a period of time. Wiki could set a time limit on save without publish.
To say again, separate out saving the file from publishing it. Wiki is a publishing environment. So, sometimes content needs to be developed by the authors before it is ready for "prime time." This would let a team of authors work in tandem without having Wiki editors removing the material before it is ready to be "judged."
See mw:Extension:Drafts, no idea if its ever going to be enabled. There was also a Village Pump discussion (which I cannot find) where people were bashing the idea of a secret place to store information. — Dispenser00:18, 20 April 2010 (UTC)
In a somewhat related note, the usability team found that some new users assumed that when they hit the "Save page" button, that the page is saved somewhere, and did not know that their edits went "live". I myself interacted with a new user who had that assumption. I think we should rename the "Save page" button to "Publish"to make it more clear. Sole Soul (talk) 00:42, 20 April 2010 (UTC)
kjm 24.22.74.213. I think you have some good ideas. New editors barely understand Wikipedia, wikitext, etc.. They may not know of user subpages, sandboxes, etc. as places to develop articles. Maybe add buttons to "save to my userspace" and "publish." --Timeshifter (talk) 02:43, 20 April 2010 (UTC)
I like this line of discussion. It's exactly the sort of thing crusty old Wikipedians would never think of, and it may be helpful to new users. Rd232talk07:54, 20 April 2010 (UTC)
When I think of "publishing" something, I think of actually printing something, like a magazine or a book. While it may technically be the correct word, it sounds (to me) even more jargon-y than "Save", which is at least connected more to computers. Mr.Z-man01:25, 21 April 2010 (UTC)
Because it is related to computers (i.e. save file), it is more confusing. In the contrary, it is less likely that new users would think "publish" means puplish like in printing in this context. Anyway, "submit" may be another option?! Sole Soul (talk) 04:33, 21 April 2010 (UTC)
They may not think of actual printing (do you have any evidence to suggest that they won't think that way?), but that doesn't necessarily mean that they won't still be confused. "Submit" is just vague. Submit what to where? Mr.Z-man05:08, 21 April 2010 (UTC)
I don't have evidence (like a usability team survey) that says new users are not likely to think that "publish" would mean actual printing, if that is what you are asking. The question is what most new users are used to at other popular websites. Most of these sites use "submit" for adding comments. When "save" is used in the web, it is usually to save files at web storage sites, or to save settings.Sole Soul (talk) 05:44, 21 April 2010 (UTC)
Nobody thinks a Publish button on a webpage means "print to my local printer"; it's well established as meaning "put live on the web". OED has a sense of "Publish" as "To make generally accessible or available for acceptance or use (a work of art, information, etc.); to present to or before the public; spec. to make public (news, research findings, etc.) through the medium of print or the Internet." WordPress and Blogger and most CMS's use the word "Publish" for their "put live on web now" buttons. Furthermore, it seems to me the original MediaWiki choice of "Save" was probably motivated by a techie perspective of "saving changes to the underlying database". From the user's point of view, publish is the relevant call to action. "Save" is vaguer than "publish", at best - for many it carries a suggestion of something local (save to my hard disk), or perhaps save an online draft of some kind (compare webmail systems). "Save" doesn't clearly say "let the world see this" in the way that "publish" does. Regardless of whether we want to add some kind of a "save draft" button (eg via the Drafts Extension), I think a simple rename of "Save page" to "Save and publish" would be an improvement. Using both words is helpful here for continuity. PS why not think more fundamentally about making these buttons clearer: get some colour in there at least, if not a different icon for each action. Cf [4]. Rd232talk09:43, 21 April 2010 (UTC)
Users familiar with other CMS's are probably not the ones who are confused by the "Save" button. Though if we are going to clarify it, I agree that more words is better than fewer here, its not like we're constrained for space. One thing to consider though is the effect that FlaggedRevs will have (assuming we ever get it), where under certain situations, it won't actually save it to the version shown to the public until the edit is reviewed. Mr.Z-man23:18, 21 April 2010 (UTC)
Good point. FR would probably need the button changing anyway, so that people are clear about the exact effect of clicking the button. So we may as well as get used to the idea of changing the button. What would the post-FR button be, for people whose edits need reviewing? "Submit changes for review"? Rd232talk16:09, 23 April 2010 (UTC)
Back to the suggestion made above: shall we
1. Change "Save page" to "Save and publish"
2a. Add a new button "Save draft/test", which saves the page to Special/MyPage:Pagename, i.e. a userspace copy of the user's text. Ideally adds a suitable template to the userspace page as well, to help with the "what now".
2b. Add a new button "Save draft", which is only available when the page doesn't exist, and creates a userspace draft as in 2. I mention this in case 2a is considered too confusing or clutter-creating to be available all the time.
I know it's been suggested Flagged Revisions may change things with regard to 1., but we can cross that bridge when we come to it. And you could argue that if anything changing the button from "save and publish" to something relevant to FR will make the transition clearer than from "save page". Rd232talk10:48, 27 April 2010 (UTC)
I note that the idea of publish is already being worked on in the usability project (it has been in the designs since october). see this sandbox edit page. The idea of reworking the drafts extension to be more usable and understandable for users is also being considered. —TheDJ (talk • contribs) 23:54, 27 April 2010 (UTC)
That sandbox is confusing. It's basically the same as here, except, there's an extra Publish button top right which seems to have the same effect as Save Page. Rd232talk09:59, 28 April 2010 (UTC)
new page patrol
Thinking about last month's on hasty new-page patrollers, perhaps an actual delay before publication of new pages wouldn't be such a bad thing. Websites like Craigslist say that they take up to 15 minutes to publish, so it probably wouldn't seem too strange to new editors.
(I'd still rather that these couple of NPPers followed the directions about not patrolling pages within seconds of their creation.) WhatamIdoing (talk) 22:49, 23 April 2010 (UTC)
One possibility would be to delay the new page feed for some users - for all users wouldn't be a good idea. It would seem an undesirable complication (managing who has a delay and who doesn't), but it's perfectly possible - and given the constant backlog, maybe not as silly an idea as it might seem at first. Just - do we really want another user-right? Is there some other way to do it? Is it worth it? What about splitting New Pages, perhaps by category of user (autoconfirmed/not)? Access to the latter would be more sensitive. Rd232talk23:03, 23 April 2010 (UTC)
You mean tag for deletion? Some new pages should be detected ASAP, like attack pages. Most patrollers give clearly non-vandalism pages time before tagging it for deletion. Sole Soul (talk) 23:55, 23 April 2010 (UTC)
Tag for deletion or cleanup. Mostly this is done reasonably (and obviously it's a necessary task and for some pages it does need to be ASAP), but it's done in a WP:BITEy way often enough by enough patrollers that finding ways to avoid this is a perennial issue. A previous response to this was adding the injunction at the top of New Pages to consider patrolling from the back of the new page log. Rd232talk01:05, 24 April 2010 (UTC)
Two alternative ideas. One, just revise the MediaWiki message at the top of New Pages to emphasise not WP:BITEing people. This I'll probably have a crack at some time today, drafting something (probably to mention welcoming people and providing {{userspace draft}} to people if appropriate. Two, suggest that for very very new articles patrollers use a variation of {{new unreviewed article}} instead of applying lots of tags (uncategorised, etc) saying what's wrong with it, which can be offputting and bitey if the article's only a few minutes old. The tag might borrow something from the PROD template to show how recently the article was created, and change accordingly (if it's old enough, suggest cleanup tagging). Twinkle could have the template added to make it easy. Rd232talk09:25, 24 April 2010 (UTC)
I object to the "Consider using Friendly" part since I consider that tool to encourage drive-by tagging. The {{userspace draft}} template is for putting on userspace drafts, not for using as a talk page warning. I like that the options to show a "delayed" new pages are inside a box for better visibility by newer patrollers though. PleaseStand(talk)11:24, 26 April 2010 (UTC)
1. I think you're confusing WP:Friendly (easy welcoming users, albeit with templates) with WP:Twinkle (easy article tagging, CSD, etc). In any case, in an NPP context I don't think driveby tagging is a big issue; the main problem with driveby tagging is users adding NPOV tags and the like without (sufficient) explanation, which happens less in an NPP context where it's more fairly clear/selfexplanatory issues like uncategorised, cleanup, etc. 2. I fixed the template reference to {{uw-draftfirst}}. Rd232talk10:26, 27 April 2010 (UTC)
Twinkle can be used to add deletion tags. Friendly can be used to add welcome templates and maintenance tags. The part of Friendly I object to is it allows adding tags to old articles just as easily as to new articles. And how hard is it to type {{subst:welcome}} ~~~~? I do not think we should endorse such a tool on Special:NewPages. PleaseStand(talk)11:06, 27 April 2010 (UTC)
My bad - I thought the "tag" tab was from Twinkle, but it is from Friendly (I've had both so long I've forgotten). Since the reference in the proposed draft is to using the welcome functionality of Friendly, and NPPers will be using this or similar tools anyway to tag pages, there doesn't seem any point in suppressing the suggestion (endorsement? no) to welcome people with it. As to "how hard is it" - I don't know how to quantify that, but it's certainly harder and slower than using Friendly, which also provides a range of options which may sometimes be more appropriate (notably anon welcome templates, specific problem user welcome templates). In sum, if we want to seriously encourage welcoming people, we need to mention Friendly. Rd232talk08:37, 28 April 2010 (UTC)
It should work like Gmail. Drafts should be autosaved at least once a minute, and you publish when you're ready. And it should inform you immediately when someone makes an edit that conflicts with the one you're working on. Tisane (talk) 08:36, 25 April 2010 (UTC)
About the hasty NPPers: Part of the problem is that we have a couple of very active NPPers who (1) know that the community has — directly, explicitly, and personally — requested that they not patrol pages created in the last 15 minutes and (2) insist on going against this advice.
Given this situation, I doubt that the proposed changes will have the least bit of effect on the worst offenders.
IMO there is no valid reason for ignoring attack pages for weeks (and that are now indexed on all the search engines) simply on the grounds that you didn't happen to be logged in when they were created. Pages that were created a few minutes ago are essentially invisible to the outside world: we can afford to let them sit long enough for the editor to get the second edit in. WhatamIdoing (talk) 00:38, 27 April 2010 (UTC)
If the problem is as specific as you suggest, maybe we can impose a community sanction requiring them not to do this? Perhaps do an WP:RFC/U first? I'm not quite sure about your "IMO there is no valid reason...." sentence - what's your thinking here about "happen to be logged in"? I'm not clear about your point. On the last sentence though: pages often appear on Google within minutes. This is a longstanding peeve of mine, and I've suggested before that the software NOINDEX all pages for the first 24 hours after creation, except where explicitly overridden on a page where it matters (eg new current events articles). Could try proposing that again... Rd232talk10:34, 27 April 2010 (UTC)
These couple of editors seem to think that patrolling pages within seconds of their creation is a virtuous act (even though the backlog of weeks-old unpatrolled pages is significant, and pages in the backlog are equally worth their attention). Consequently, whether a page gets patrolled is essentially determined by timestamp: If the page happened to get created during the minutes (or hours) that an NPPer chose to patrol a bunch of pages, then it gets patrolled. If it was created while most of the active NPPers are in bed/at work/at school, then it gets ignored. WhatamIdoing (talk) 01:12, 28 April 2010 (UTC)
I see. Do you mind saying who you're thinking of? And do you think NOINDEXing new pages would be a good idea? Rd232talk08:29, 28 April 2010 (UTC)
I provided a link in my first comment above; I suggest reading it so that you can have not merely (two) names, but the associated context.
I imagine it being done by default in software (eg for pages younger than 24 hours), with a magicword override (i.e. INDEX) which can be kept in a template for ease of use. Alternatively it could even be done without a software change, if we change the MediaWiki configuration to allow NOINDEX in mainspace, and then use templates, bots etc to NOINDEX everything new, and remove NOINDEXing after 24 hours. The former would be cleaner. I think we could propose this at VPR actually, it would have a number of benefits, and making NPP a slightly less urgent/high-pressure task would be one of them. Rd232talk22:52, 3 May 2010 (UTC)
Users who don't know what Wikipedia is are being misled
I still remember when I first found Wikipedia. I googled for a term and arrived at the entry for that term at Wikipedia.
What I found was grossly misleading and inaccurate content in the ENCYCLOPEDIA. I though what the hell? An encyclopedia should contain verified and correct information.
It was much later when I browsed to the main page of Wikipedia to look into what this encyclopedia really is. There I saw the explanation: It is the encyclopedia THAT ANYONE CAN EDIT(!). Aha!
That sentence immediately worked as an eye opener and a disclaimer that I should treat the content as unreliable.
Now, my question is: Is it intentional that the phrase "that anyone can edit" is only on the main page?
New users discovering an article on Wikipedia will not go to the main page, but directly from Google to the article. They will be misled into believing that this is a real encyclopedia that can be edited only by experts who know what they are talking about.
The phrase "that anyone can edit" needs to be visible on EVERY article page on the Wikipedia website. Either within the logo or within the text.
94.113.158.92 (talk) —Preceding undated comment added 09:28, 23 April 2010 (UTC).
No, I couldn't because I didn't know THAT ANYONE CAN EDIT this wikipedia! Read my post again. Also, it doesn't matter which article it was. It is a general principle that is and always will be true.94.113.158.92 (talk) 09:33, 23 April 2010 (UTC)
I expected exactly this kind of answer. But reliable research has shown that NOBODY reads the fine print. However, people DO read the first line within the text. And I ask once again: Is it deliberate that the main page starts with the crucially important phrase "that anyone can edit" and the actual article pages do not? Is it honest to not tell new people about this crucial fact? And once again, new users WON'T come to the main page, let alone read any fine print!94.113.158.92 (talk) 09:42, 23 April 2010 (UTC)
Look, if you get medication, don't read the labels and die, that's tough luck. Now go get a copy of Britannica or whatever other work you admire and read their disclaimers. I'll mark this as resolved. No administrator-attention is warranted here (to find out why, read WP:ADMIN which tells you what admins do and don't do. Thanks.) Choyoołʼįįhí:Seb az86556> haneʼ09:47, 23 April 2010 (UTC)
Maybe this could be appropriate at the WP:SIGNPOST, although probably not if you just want to complain without some fix in mind. This is a place for issues that require administrator intervention. I don't see any of that in your complaints. Shadowjams (talk) 09:48, 23 April 2010 (UTC)
94.*, you didn't notice the edit button at the top of the page? That's a pretty big giveaway, and seems fairly prominent to me. I recall seeing that rather quickly when I first came here, and thought "Hmm, I wonder...." (Oh gods, why did I do that?!?)— Huntster (t@c)09:50, 23 April 2010 (UTC)
(edit conflict)Stop with the corporate ass-covering "it's not our fault if you didn't read the fine print" talk, please. Mr. Anon has a point, despite his poor choice of venue. Maybe we should put the phrase someplace where every article page will show it. I'm refactoring this to VP, will notify the author. Equazcion(talk) 09:50, 23 Apr 2010 (UTC)
Indeed, that's a rather strong phrase. I, personally, consider it extremely foolish for *any* person to automatically trust anything they read online. Their own damn fault if they do. No "corporate ass-covering" going on, just plain common sense and an expectation of personal responsibility. It isn't our job to hold everyone's hand. And I would suggest that the five million page view average the main page gets daily indicates that lots and lots of readers, quite a number of them new users, actually do get to see the phrase "that anyone can edit". — Huntster (t@c)10:06, 23 April 2010 (UTC)
I think "hand holding" is a bit of a stretch for this situation. It would be more apt if the proposed change would constitute some sort of sacrifice on our part. In this case it's suggested that we can help clarify the truth about Wikipedia by adding four words to the sidebar or logo. As for the stats argument (propaganda, ahem), compare the main page views with the total views of article pages from search engines, whose viewers never get to the main page; If it were possible to generate that stat, I think that you'd see it exponentially larger than the main page views. Equazcion(talk) 10:14, 23 Apr 2010 (UTC)
Back to the point, I myself wasn't aware anyone could edit Wikipedia for a while after first encountering it. My family and friends still don't get it even after I told them. The concept that I actually edit the encyclopedia, and that they could too, seems new to them no matter how many times I mention it. Having this phrase on ever page might serve to get the point across, and wouldn't cost very much in the way of space. Equazcion(talk) 10:00, 23 Apr 2010 (UTC)
It might. but that was not the point of the complaint; obviously, the anon's asking for a disclaimer that says "this shit isn't worth anything, don't believe it" -- that's at least how it came across. Choyoołʼįįhí:Seb az86556> haneʼ10:03, 23 April 2010 (UTC)
I think this is a good point and there is no reason that I can see that the phrase shouldn't be visible on all articles. People don't read disclaimers as a rule, and unfortunately misinformation does spread through Wikipedia - we all know this. If that can be counteracted by adding a simple statement to pages, that's surely a Good Thing(TM). Add "that anyone can edit" to "From Wikipedia, the free encyclopedia", which is what it says at the top of each article now - that will serve the double purpose of making more people aware that they could fix misinformation, and making them view the articles with a more critical eye. --bonadeacontributionstalk10:05, 23 April 2010 (UTC)
(e/c)The page logo, top left, says "Wikipedia, the free encyclopedia", but the main page says "Welcome to Wikipedia, the free encyclopedia that anyone can edit." I have some sympathy with the OP's original point, and it wouldn't seem too difficult, the next time the logo is revised, to clarify the strapline. Ghmyrtle (talk) 10:08, 23 April 2010 (UTC)
(edit conflict) Yes, this is a reasonable change, though I have no faith that it'll keep folks like the OP from complaining that they weren't given adequate warning as to the potential unreliability of the site. Remember, people like to complain for the sake of complaining (this reply is a testament to that). — Huntster (t@c)10:10, 23 April 2010 (UTC)
Seems to have last been seriously discussed in 2006, and then it was just a list of support signatures. Could be time to revive it. And I'd suggest keeping the discussion here, where there are more eyes, rather than at Mediawiki space. Equazcion(talk) 10:17, 23 Apr 2010 (UTC)
Correction: Keep the discussion at Village pump, where there are more eyes; not on this page specifically. This page is new and has less than 30 watchers so far. Once we've hammered out details (whatever details there are) this should be proposed at WP:Village pump (proposals). Equazcion(talk) 10:26, 23 Apr 2010 (UTC)
(edit conflict) Funnily enough, I've always had the exact opposite problem with my friends. They're all "I added 'your mom' to the end of every line in the article about whatever, so it's not reliable- I don't even use Wikipedia, let alone edit [well, obviously apart from vandalism :P]". And my dad-- he made a false article, and it stuck for like 32 hours, so he's stoked. (And he's an open-source, copyleft junkie- it's where I get it from.) But I think he probably doesn't trust it simply because I can edit it.
But I agree with the IP. It needs to be more clear to people that they can edit-- not only that, the process of contributing should be easier. At Articles for Creation, we've been having a little discussion about IPs and creating pages, seen here. In essence, why does the search tell them they can create a page, then make it so hard to find the right place? It's non-conducive to new users, methinks. </rant> And yes, this should probably be at the main Village pump. but oh well...SS✞(Kay)10:30, 23 April 2010 (UTC)
Comment. I don't have a strong opinion either way on the issue but, if Huggle-main-stats are reliable, there are in excess of 3 edits per second during high peaks. I've never seen the rate fall below one edit per second. I think the word is out, personally. Tiderolls11:54, 23 April 2010 (UTC) excessive white space due to my comment interferring with User:Equazcion's image on my browser...feel free to edit my post to reformat
This is just like the main page view statistic as a reason to say people know anyone can edit. A number like this doesn't mean anything unless you can compare it to another number. 3 edits per second sounds like alot, but that still doesn't mean we know how it compares to the number of article views we're getting by people who might have edited had they known they could. Equazcion(talk) 12:11, 23 Apr 2010 (UTC)
Just my interpretation. "The Free Encyclopedia" was always capitalized, so I figured the rest would be too if we added stuff to it. "that" and "can" are lowercase due to being articles or "unimportant" words, which traditionally aren't capitalized in titles and slogans. I'm not married t this format, it was just a choice based on what was already there. Equazcion(talk) 12:37, 23 Apr 2010 (UTC)
I capitalized "can", on further thought. Equazcion(talk) 12:41, 23 Apr 2010 (UTC)
(edit conflict) Again, for what it's worth, the large edit button on the top of the page seems to be enough for people to get the general idea. References are there for a reason, they let people verify what they're reading. And if someone happens to read an article that has I love Joe! in the middle of it, I think users have enough common sense to know it's vandalism. The 'new' logo looks like, but I think it might be bulky on the side bar. PanydThe muffin is not subtle15:13, 23 April 2010 (UTC)
Just because there's an edit button doesn't mean that I can edit - it would be easy, as a clueless visitor, to assume the button is for registered experts only (and that "I love Joe" means the site's been hacked). The "anyone can edit" approach could be made clearer. On the other hand, I'm not totally convinced that putting the objective of Wikipedia (a free encyclopedia) on a par with the method (anyone can edit) in the logo is a good idea. Also, I'm not totally convinced that "anyone can edit" encapsulates the method ideally. Maybe there's no better phrasing, but it would be nice if there were. Finally, I'm not sold on the "disclaimer" being worth much except in court; nobody reads those things. So the question is whether we can be clearer to visitors, who generally don't enter via the main page, without taking up too much space or uglifying things. On balance, the proposed change does that; I just wonder if we can do better? Rd232talk16:26, 23 April 2010 (UTC)
Or we could make it more accurate: "...The free encyclopedia that almost anyone can edit most of the time". ;P -- Ϫ16:39, 23 April 2010 (UTC)
I'm not sure that there are any other wording choices. This has the best chance for wide support since it's already a slogan in use. There are a few formatting variations I'm brainstorming though. If anyone has any ideas let me know. Equazcion(talk) 17:06, 23 Apr 2010 (UTC)
I think we should go with the longer slogan. It's beneficial to stress that anyone can edit the encyclopedia; we might get more edits that way. We can put an asterisk next to "anyone" if need be. Tisane (talk) 18:41, 23 April 2010 (UTC)
I think it's ridiculous IMO. Too long, looks silly and unprofessional (and I'm not referring to the sarcastic one I wrote above). It's perfectly fine the way it is, nice and short and simple, like a slogan should be. -- Ϫ19:48, 23 April 2010 (UTC)
I'm not entirely sure of the mockup myself, but the OP's concerns still have merit. If you're not in agreement on that premise, feel free to discontinue commenting on this thread, but this page is intended to brainstorm with an eye towards the optimistic, rather than to flat-out oppose or support a suggested implementation. If you agree with the premise but not on the suggested solution, please do offer thoughts on possible alternatives. Remember a logo change is just one way to handle this. Text located elsewhere could be another solution. Equazcion(talk) 20:37, 23 Apr 2010 (UTC)
The logo could be contracted out to a graphic designer. But I think we could start by changing the tagline. Of course, we should implement a parserfunction to detect if the user is blocked, and if so make it say "the free encyclopedia that anyone except you can edit, because you're such a frickin' dork for not taking the hint when we told you to quit vandalizing." Try making a mockup of that! Tisane (talk) 20:43, 23 April 2010 (UTC)
Sticking parserfunctions in the tagline is a surefire way to get yourself chased out of town by Domas beating you with a melted server (I'm not even sure if the tagline takes parser functions...). But I think the tagline is a better target for this than the logo or pagetitle. Happy‑melon20:52, 23 April 2010 (UTC)
If you mean the tagline under the logo, that's what is meant by "the logo", since it's part of the image. If not then I'm not sure which tagline you're referring to. Equazcion(talk) 20:53, 23 Apr 2010 (UTC)
The tagline is the bit immediately under the page header, which says "From Wikipedia, the free encyclopedia". Rd232talk21:01, 23 April 2010 (UTC)
(I will commment as I see fit) Changing the tag line is a) much easier b) can be reverted easier, and c) isn't as intrusive as changing the logo. There's already a tagline. We should talk about that. Choyoołʼįįhí:Seb az86556> haneʼ21:22, 23 April 2010 (UTC)
Ah. Yeah that's an option. It's not as visible as the logo (I didn't even notice it til pointed out to me just now), but it's better than nothing, if the logo change is deemed unfeasible. Equazcion(talk) 21:43, 23 Apr 2010 (UTC)
So... do we want to draft a proposal, perhaps in two parts with the issue below (linking the word "free" to something explanatory)? Then take it to VPR? Rd232talk22:39, 25 April 2010 (UTC)
Yes, it appears that most of the people participating in this discussion want to draft a proposal. I suggest changing both the logo and the tag line (ie. "From Wikipedia, the free encyclopedia that anyone can edit"). Both as some newcomers will look at the logo while some will look at the tag line. Xnquist (talk) 14:06, 30 April 2010 (UTC)
Can't really put ads for that anywhere they will be seen by the people who don't know that. I mean, if the ads are not on the article or article talk page, it's not going to make much difference, because anywhere else pretty much attracts only people who already get that. However somewhat in this vein of thought is my Main Page "how to contribute" box idea - see Talk:Main Page. Rd232talk14:11, 13 May 2010 (UTC)
School IPs
Thought: school IPs are often tagged with {{schoolip}}. I reckon it ought to slightly put school users off vandalising if they know their IP is identifying their school. But they won't find this out unless they happen to get a warning message and then visit the talk page. So why not somehow (would need a software change I guess) permanently show a warning to school IPs: "we know where you are" - or words to that effect :) ... ? It shouldn't be too obtrusive of course; maybe it could replace the IP number at the top with the name given by the schoolip template? (Or keep the IP and add the name in brackets.) Rd232talk20:49, 27 April 2010 (UTC)
Any idea for the warning? I suggest the follow, but we should get it run by lawyers first.
Attention
Your IP address 163.150.225.201 will be logged by the Wikimedia Foundation, Inc and disseminated publicly. Violators of our Terms of Use can and will be prosecuted to the fullest extent of the law. This includes but is not limited to defacement, knowingly providing false information, and/or uploading copyrighted material without permission from rights holders. You irrevocably agree to release your contributions under the CC-BY-SA 3.0 License and the GFDL.
It is already possible to do the check, {{#ifeq:{{str find|{{User talk:{{REVISIONUSER}}|template-sharedipedu}}|-1|<!--untagged-->| {{SharedIPEDU warning}} }} you just need to add template-sharedipedu in the first 80 character of the template. — Dispenser01:14, 1 May 2010 (UTC)
To original point: No, it doesn't put people off. As a kid whose school IP is blocked until 2013' (and who's talked to kids and sysadmins about it), the reaction is usually "Great! Get the school in trouble, lol." It's almost an incentive that they, by doing something so small, could get a result so big. Of course, the novelty wears off, but along comes another kid. {{Sonia|talk|simple}}02:22, 1 May 2010 (UTC)
The president seal seems inappropriate for such a template, because most schools aren't in the USA (hence it would be humorous to some vandals). I agree with Sonia on the principle that it'd fuel vandalism by school IPs instead of stopping it, so I'd recommend finding another way to combat this i.e. tightening warnings so that educational institutions are treated like everyone else. There's just no use in being lenient on those who already possess a history of vandalism, even if it dates back to 3 months ago. A lack of severity will be reflected in a continuing lack of discipline. Deagle_AP (talk) 02:30, 1 May 2010 (UTC)
This has gone off in a rather different direction than I meant. What I had in mind was a relatively discrete notification in the top right, identifying the school alongside or instead of the IP (for non-logged-in users from that IP). It could be clickable for further information. The point is to show "we know where you are", and the "further information" could clarify that the person could be reported to their school administrators, something like that. And make it clear that getting that IP blocked isn't "getting the school in trouble", it's merely for the benefit of Wikipedia to combat morons. Properly worded, it should be more along the lines of "do you want to be the 10 millionth moron to vandalise a random page?" than "we're gonna sue you". So to Sonia in particular - does something in this direction sound perhaps worth doing? Some variation? Rd232talk22:34, 1 May 2010 (UTC)
I would also point out that Conservapedia bans people at the drop of a hat and prominently warns that vandalism is punishable under federal law,[5] but I don't know of any wiki that gets vandalized more than that one. Vandalism is not all that big a deal, by the way — every open wiki will have vandals, and it is an easy matter to revert. Easier, in fact, than it is for them to vandalize to begin with. The bigger deal we make out of vandalism, the more we'll attract people seeking lulz from our reactions. Tisane (talk) 23:13, 1 May 2010 (UTC)
Actually Tisane I have to disagree with you there. Every time someone vandalises a page, you can be sure that it's not a 100% chance it'll get reverted. The small percentages of edits that we miss will accumulate over time, and hence the number of vandalised pages will steadily increase, particularly in cases where the vandalism cannot be easily identified (ie sneaky types). However, we must be direct and not exaggerate our concerns. Saying something along the lines of "10 millionth vandal" is not the way to do it, because persistent vandals seek pleasure from being able to continually disrupt Wikipedia, and using civility against vandals is the option (or we can just ignore their attention-seeking antics all together). Deagle_AP (talk) 03:07, 2 May 2010 (UTC)
Yeah, I dunno about that. Sneaky vandalism that's important will tend to attract notice from some knowledgeable person and get hit with the {{fact}} tag and eventually be removed, if it's not immediately removed. And the vandal's other contributions will usually come under scrutiny once one act of vandalism is detected. The bottom line is, people should know by now that anything they read on Wikipedia is suspect unless it's sourced; and if sourced information still seems suspect, it's a good idea to check that source. The same applies to anything else one reads, online or offline, of course.
I favor showing civility to vandals so as not to provoke them to have a vendetta, and basically killing them with kindness. I think most of them will become ashamed and stop if treated that way. Of course, at some point a block becomes necessary, but blocks generally shouldn't be for long periods, because that just encourages sockpuppetry. When I see vandalism show up on my watchlist, I just revert it, hit the guy with a {{test}} template, and go on my merry way, not only because I don't want to reward attention-getting antics, but because I have other stuff to do. Tisane (talk) 03:27, 2 May 2010 (UTC)
This has got off-course again, in a way I don't see getting very helpful. Back to the specific issue: is signalling to every non-logged-in-user from a known school IP, on every page, that we know their location, a possible way to deter vandalism (a little)? This would be done in the top right "preferences" line, next to the IP address (which I guess could/should still be displayed). In addition, how about linking that school name either to a generic intro/info page, or even to one customisable for the school (semi-protected, I guess), perhaps by the school administrators if they choose to? Rd232talk00:50, 7 May 2010 (UTC)
cool idea! A general one would work well and then it could have subpages for individual schools to use if they so chose? I don't know how much it would deter, though. As someone said earlier, some students want to get the school in trouble. VerballyInsane14:55, 7 May 2010 (UTC)
Yes, the wanting to get the school "in trouble" is an issue. I think one advantage of having an explanatory general page is that it can make clear that vandalism will not get the school in trouble. It will simply get the IP blocked, and Wikipedia won't care. Few schools have legitimate tasks involving editing Wikipedia, and that's all that's blocked - so it's not even inconveniencing any school users (except for limiting their ability to sod about in class when they should be working). And if it's bad enough and/or the school administrators care, there's risk the vandal may get in trouble because schools may monitor traffic and user logins and may trace vandalism to the person if they can be bothered. It's that (small) risk, properly explained, which may have a deterrent effect, clarifying that "not logged in" is not the same as "anonymous". Rd232talk14:27, 8 May 2010 (UTC)
I disaree stongly with the "can and will be prosecuted" statement, because I do not feel we should be maing off-wiki threats, particulary to school IP's. Immunize (talk) 16:31, 8 May 2010 (UTC)
I agree that the Presidential seal is not intimidating enough; we'll want to customize it by IP address, as follows:
Extended content
For users with U.S. IP addresses, we would want to use the following warning:
Attention
Your IP address 163.150.225.201 will be logged by the Wikimedia Foundation, Inc and disseminated publicly. Violators of our Terms of Use can and will be prosecuted to the fullest extent of the law by the FEDERAL BUREAU OF INVESTIGATION, which takes such offenses very seriously. Criminal violations include but are not limited to defacement, knowingly providing false information, and/or uploading copyrighted material without permission from rights holders, any of which can be punished by fines, imprisonment, and a term of supervised release during which you may be restricted by the court from accessing a computer or the Internet. You may also be subject to civil suit by the Wikimedia Foundation, resulting in disgorging of your assets and/or garnishment of wages to satisfy the judgment. You irrevocably agree to release your contributions under the CC-BY-SA 3.0 License and the GFDL.
For those with IP addresses outside the U.S., we would want to display this one:
Your IP address 163.150.225.201 will be logged by the Wikimedia Foundation, Inc and disseminated publicly. Violators of our Terms of Use can and will be prosecuted to the fullest extent of the law by the INTERNATIONAL CRIMINAL POLICE ORGANIZATION, which takes such offenses very seriously. Criminal violations include but are not limited to defacement, knowingly providing false information, and/or uploading copyrighted material without permission from rights holders, any of which can result in extradition and prosecution in the International Criminal Court, once its statute is broadened to include jurisdiction over these crimes. You irrevocably agree to release your contributions under the CC-BY-SA 3.0 License and the GFDL.
And for those whose IP addresses indicate that they're editing from a Christian church or parochial school, we would want to display this warning:
Attention
Your IP address 163.150.225.201 will be logged by the Wikimedia Foundation, Inc and disseminated publicly. Violators of our Terms of Use can and will offend THE LORD, who takes defacement, knowingly providing false information, and/or uploading copyrighted material without permission from rights holders very seriously. Ephesians 4:29 commands that you refrain from such corrupt communication. Failure to repent of these sinful actions can result in everlasting destruction (2 Thessalonians 1:9), with the smoke of your torment ascending up for ever and ever (Revelation 14:11), after you are cast into Hell, where your worm dieth not, and the fire is not quenched (Matthew 9:44, 46 and 48). Submit to the powers that be (Romans 13:1) and pray that you not be led into such temptation, but be delivered from evil. As irrevocably as your soul may be condemned to eternal punishment for violating the sanctity of this encyclopedia, you agree to release your contributions under the CC-BY-SA 3.0 License and the GFDL.
Most of the other major religions also have concepts of Hell, so I'm sure we can come up with warnings for them too.
Well that's very entertaining I'm sure. FWIW, Dispenser's original notice, which inspired that, was nothing like what I had in mind with my original idea. The core idea is merely to tell school IP visitors that they are not anonymous. Rd232talk18:17, 8 May 2010 (UTC)
The templates above really don't seem appropriate for Wikipedia. They seem to border on scare tactics, especially with the big font for "THE LORD" etc. I'm still of the view that vandals will only laugh at such attempts to discourage them. For school students trying to be normal editors, it might be annoying for them to see that they're being tracked from page to page. Therefore, Rd232 I really don't think this is the right way to approach vandals. Deagle_AP (talk) 03:06, 9 May 2010 (UTC)
Can you expand on that? You mean an edit notice specific to articles particularly vulnerable to school IP vandalism? This was recently mentioned elsewhere, it seems like a reasonable idea - could be complementary to the original suggestion, rather than necessarily a substitute. Should be a standard template to drop in editnotices of vulnerable articles (cf Category:Editnotice templates), maybe with a specific version for school articles. Rd232talk17:15, 8 May 2010 (UTC)
I mean an edit notice that appears only to school IP users. May be this is not technically conceivable now, but so is your suggestion. Sole Soul (talk) 18:45, 8 May 2010 (UTC)
Ah, I see. That would make sense, targetting school IPs when they click "edit". It raises similar tech issues to the original idea. I'm not sure how difficult this would be to do; perhaps we could ask at WP:VPT for an opinion. I'm not anticipating any rapid implementation for an idea like this, but Wikipedia isn't going anywhere (hopefully). And in the short term an edit notice could be applied specifically to articles often targetted by school IPs - the sort of articles often semi-protected I suppose. Which leads perhaps to the related thought that just as MediaWiki:Protectedpagetext identifies the Main Page and provides custom text, maybe these vulnerable, semi-protected pages could also be identified. Custom instructions could point more enthusiatically to the sandbox, for instance, or otherwise be more targetted at a younger audience in terms of presentation or language. Rd232talk21:57, 8 May 2010 (UTC)
Personally, I would support an edit notice that clearly stated that blocking will occur in the event of vandalism. I would object to any notice that made any off-wiki legal threats (e.g., fines, imprisonment) as I feel that not only should we not be making legal threats, but that a notice that intimidating would discourage useful contributors as well as vandals. Immunize (talk) 19:24, 10 May 2010 (UTC)
Offwiki threats are off the table (not sure they were ever really on it) - let's forget about that. The trouble with saying "blocking will occur" is that it's not necessarily true, because of the sliding warning scale. Rd232talk07:18, 11 May 2010 (UTC)
While it is true that we can never be certain that any IP will be blocked, it is generally safe to say most IP vandals eventually get a block. Therefore a warning stating "you will likely be blocked from editing if you vandalize the encyclopedia" would be appropriate. Immunize (talk) 13/19, 13 May 2010 (UTC)
I like that edit notice, but given that that particular notice is made only for featured articles, we would have to find one applicable to all articles. Immunize (talk) 20:01, 14 May 2010 (UTC)
Stop distributing database dumps from Wikimedia servers; seed through torrents instead
I was browsing through Wikimedia's database dumps and noted their large sizes: up to 200GB for a full history dump of EN. Even the current-version-only dump, the version commonly used by mirror sites, is about 6GB. A test download showed, from I can gather, that these downloads are unthrottled. With all the sites mirroring Wikipedia, this could add up to a lot of bandwidth that could otherwise be improving response times for people actually using Wikipedia. While it's our responsibility to make our free content available to everyone, I don't think it should be our responsibility to pay for them to get it as fast as possible, to the detriment of our own community.
I wonder if instead of distributing dumps from Wikimedia servers on a permanent basis, we could instead seed dumps for limited time via BitTorrent. If a torrent dies, a request could be made to the foundation for a temporary re-seed; or, a permanent "trickle" seed could be maintained from Wikimedia servers following the initial unthrottled seed, so that in case no other seeds exist at all, the torrent still won't die completely.
Taking this further, we would even implement our own torrent tracker that requires peers to maintain a certain share ratio, meaning that they'd have to seed dumps themselves a certain amount, relative to how much they've downloaded, or be cut off until they upload more. This could ensure the torrents stay alive with enough outgoing bandwidth for others to keep downloading, with minimal further demand from Wikimedia servers. There would be some technical logistics to work out for this, like keeping track of share ratios via IP or some kind of account system.
First of all (just for information for anyone trying to download), the most recent dump you can get right now is the March 12 dump since the newer dumps are screwed up. Second, mirror sites (and AWB users) generally download the smaller pages-articles dump (~5 GB) and then link back to Wikipedia to comply with the Creative Commons license. The mirror sites which include images generally hotlink them from Wikimedia servers since there is no image dump. One thing that is lacking, however, is incremental dumping, including only what has changed since the last dump. Note that peer-to-peer downloading tends to be slower than direct downloading, and if given a choice, many would do the direct download. PleaseStand(talk)00:50, 8 May 2010 (UTC)
I've noted above that the mirror sites tend to use the smaller (5/6GB dump). And, yes, of course everyone would rather use the direct download, since it's faster -- but again, as I said, it's faster at our expense. It's not our job to pay for everyone to direct-download so that they can get our content as fast as possible; only that it's available to them. Equazcion(talk)00:54, 8 May 2010 (UTC)
Are there any figures on how much bandwidth is actually being eaten up by this? It might be insignificant. But even if it is expensive, the data dumps are rather important to our mission and values, and therefore we shouldn't diminish the performance too much. If anything, we should enhance the availability of the data by making incremental dumps and a feed available, perhaps for a fee. Tisane (talk) 04:54, 8 May 2010 (UTC)
IIRC, there used to be some unofficial torrents available, but too few people were using them. In any case, I'm not aware of dumps actually slowing down connections for other users. Wikimedia's outbound traffic peaks at over 8 Gb/s, a few dozen people downloading dumps once a month or so is really just a drop in the bucket and we probably have plenty of bandwidth to spare. Mr.Z-man14:13, 8 May 2010 (UTC)
My assumption that there is a server performance and bandwidth deficit is partly based on my experience with browsing and editing. I often get lagging responses, and we all have experienced those database lags, especially during peak usage hours. I'm not convinced that we actually have much to spare, but granted I don't have the stats to back that up. Equazcion(talk)14:19, 8 May 2010 (UTC)
You can see the performance stats of all Wikimedia's servers at http://ganglia.wikimedia.org. All the database dumps are served from one apache server: you can see it's stats here. Its average traffic is about 4Mb/s; that's probably literally one or two people downloading a large dump at any one time. The equivalent load for just one of Wikimedia's three hundred main-cluster apache servers is around 0.5Mb/s. Overall traffic from the Wikimedia cluster is around 8Gb/s. So the dump download system represents around 0.05% of the overall cluster load. Database lags are routinely caused by dump creation, but once generated, the cost of putting them up for download is utterly trivial. I don't think there's any evidence of causality here. Happy‑melon20:08, 13 May 2010 (UTC)
Thank you for those stats. Also, it may very well be that making the dumps available causes a net decrease in load, as people wanting large amounts of Wikipedia content use the dumps when up-to-date content is not needed, rather than hitting the site. Tisane (talk) 01:13, 15 May 2010 (UTC)
Does the full-history dump include deleted pages? If not, how can you obtain a database dump that includes everything, including deleted contributions? *** Crotalus ***16:29, 13 May 2010 (UTC)
Make it easier for people to put discussion items on Wikiproject talk pages, rather than on article talk pages
First: I want to say that this Village Pump is long overdue. If it is ever threatened with the axe, please summon me and I will issue a more thorough encomium.
Before I make my proposal, here's the observation that inspired it: After a year of serious WP editing, I've started to feel that it's generally better when article discussions go on WikiProject talk pages, rather than on the article talk page. Threads on Wikiprojects are less likely to languish unnoticed, and more likely to reach the attention of an "expert" in the subject. (Yes, there are downsides: when comments skip the article's talk page, evolving editor consensus won't get associated with the article, and might get overlooked by people who have only watchlisted the article. But the latter shortcoming will be partially addressed when more people start watchlisting wikiprojects; and both shortcomings can be fully addressed if the wikiproject discussion gets mentioned at the article talk page, perhaps via the automation that I describe below.)
Therefore, I'm interested in discussing proposals whose function is to make it more likely that people will raise article issues at Wikiproject talk pages, rather than at the article talk pages. For example,
In each of the Wikiproject templates that we put in article talk pages, there could be a prominent button, "Start a thread at this wikiproject". It is like hitting "New section" at the wikiproject talk page, except its header is pre-populated with the text, RE: [[ArticleName]]:, and when the section is saved, a "talkback" thread automatically appear at the article talk page.
Write a javascript (or edit Wikimedia), so that when you're on an article's Talk page, the "New Section" button has a dropdown that lets you add a new section to any of the associated wikiprojects, employing the automation in the previous bullet (pre-populated header, talkback thread at article).
When you hit "edit" on an article talk page, the edit box could be preceded by a caption, which invites the editor to add a new section to any of the associated wikiprojects ... the "New section" button employing the above-mentioned automation.
I think this is interesting, but there's a core assumption which needs unravelling, which is that it's generally better to discuss things on a wikiproject talk page. It's widely felt that in general the best place for discussion is the article talk page, since that's where new users are most likely to see it. So we may think more in terms of advertising discussion elsewhere than moving it. For instance, quite a few projects have separate Noticeboards, which would be convenient for the purpose (keeping the wikiproject talk page for more "meta" discussion about the project). However most noticeboards are actually or virtually defunct. It's a chicken-and-egg thing... I do see your point, but maybe my thoughts lead us more in the direction of putting a link to Special:RecentChangesLinked in the project banner, providing easy access to all recent talk page discussions covered by the project (see WP:INACTIVEWP point 8.) Also, are project noticeboards generally linked from their banners? If not, maybe they should be. I do see that maybe on low activity pages a template could be added "consider notifying the noticeboard by clicking here..." the trouble is this will cover the vast majority of pages! And somewhat perversely, a page where someone bothers to add such a template will be by definition unusually high activity (even if it's still pretty low). So it would need to be in the banner, but you can't identify low activity pages there. So maybe a general noticeboard link is enough. Main problem: not sure there's room inside the project banner for much clarification on usage. Rd232talk07:14, 9 May 2010 (UTC)
Thanks for the reply Rd232, sorry I can't reply in detail at the moment. However, I wonder if folks will please take a look at this url --
There should be slightly larger text (like there was before the Wikipedia renovations) because some people can't read this text without squinting and/or getting a headache from being within a few inches of the screen. I am not opposed to the new set-up I just want to be able to read and edit without needing to pop some Tylenol. Xx IzzyReal xX (talk) —Preceding undated comment added 20:32, 13 May 2010 (UTC).
Thanks for the tips. In Firefox I always used Tools menu, Options, Content, Fonts & Colors. I hadn't used View menu, Zoom. The Ctrl shortcuts are listed there, but I hadn't tried them. Now that I see how easy they are to use I will use them. To reset the text size I noticed though that I had to set Num Lock in order for Ctrl - 0 to work. That's the zero key on the number keypad. Zero on the main part of the keyboard works either way. --Timeshifter (talk) 03:02, 17 May 2010 (UTC)
Question regarding bibliography articles
I think we may be coming to the point where at least for some articles and topics, the immediately obvious sources have been, basically, mined already. Also, in some cases, the various sources which do exist might not be always immediately obvious to many. Having a list of sources created for some primary subjects, like countries, disciplines, etc., might be one way to both let people know what sources exist and are considered basically reliable, as well as to, potentially, make it easier for school groups. And, in some cases, it might help make it more obvious that the available English language sources have already been, basically, mined. Wallis and Futuna comes to mind here, considering I find only one English source, about songs there, and four French sources dedicated to the general topic. Would it make sense to perhaps somewhat prioritize development of such separate bibliographical articles? John Carter (talk) 15:34, 28 April 2010 (UTC)
This is a good idea, at least for reasonably narrowly-defined topics where it can stay manageable. I'm not sure they should be separate mainspace articles though. Some WikiProjects have lists of resources, but they're often not very well organised. If placed on a separate page, the list can be linked more prominently, maybe from project banners (like portals often are) and from portals. That would be a start, at least. Rd232talk20:10, 28 April 2010 (UTC)
No, because the list should be permanent and easily found. A talkpage thread isn't necessarily either, and will eventually get archived. Rd232talk07:26, 2 May 2010 (UTC)
You can make a subpage of the Talk page and then link it above the TOC in a notice (that won't get archived). This seems like it would be a fantastic idea, IMO. VerballyInsane00:37, 4 May 2010 (UTC)
Yes, that would work, and bring the resources more upfront. But some effort should be made to tie the subpages together via a relevant wikiproject, to avoid needless duplication. If necessary, have different bibliography subpages of the wikiproject for different topic areas, so the talkpage subpage can transclude the relevant one(s). As so often, a template can help make things easier and show how it can be done. Rd232talk08:35, 4 May 2010 (UTC)
And, of course, if there are explicit articles or books which are themselves, effectively, bibliographies (and there are regarding virtually every country and religion I've seen, and probably several other topics as well) they would probably be notable enough to clearly qualify for a separate article. John Carter (talk) 19:47, 4 May 2010 (UTC)
So you tag the talk-page section as something that shouldn't be archived. (It's not hard.) Personally, I'd probably place the list at the top of the talk page (either in a {{todo}}-style box or simply as a regular section). I think the primary advantage to using the talk page is that all serious editors automatically look there for any/all information about what was done previously -- which means that the list is far more likely to be noticed by editors, and you don't have to reinvent the wheel. WhatamIdoing (talk) 06:18, 9 May 2010 (UTC)
Interesting idea. Obvious question: why could this list of sources not be put in the references section on the article itself? I'm not sure whether {{WPBM}} is the best place to propose this because I can't see the direct link with WikiProjects - this idea seems to transcend the WikiProject structure. If an article has no related WikiProjects (okay that's unlikely) then the link would not appear; if it's within the scope of 10 projects then the link would be duplicated 10 times which is redundancy. I could see a case for a link being included on the banner shell {{WPBS}}, if this idea takes off. And that could be done automatically using page detection rather than using a parameter. — Martin (MSGJ · talk) 10:54, 7 May 2010 (UTC)
I think you've got the wires crossed of the two proposals. Template:Bibliotalk is a bibliography specific to an article; this adds value to an in-article Reference List by virtue of being annotatable, eg being able to list good references editors don't have access to but which should be checked out; or even bad sources ruled out. The Banner box is for a link to a specific wikiproject's general bibliography page, covering all articles within the wikiproject's purview. So 10 banners = 10 different biblio pages. Rd232talk12:44, 7 May 2010 (UTC)
Yes, I think I was confused. Do any WikiProjects currently maintain a bibliography page? If so, we could look at adding a box to those banners. — Martin (MSGJ · talk) 13:11, 7 May 2010 (UTC)
Well it's a chicken and egg thing, isn't it? I'm not aware of WikiProjects with bibliography pages - but there are some with resources pages, and many more with resources sections which could become separate pages. Adding the parameter to bannermeta, plus a bit of publicising, makes it something that can develop relatively easily, if anyone is willing to pick up the thread for an individual project. Rd232talk14:20, 8 May 2010 (UTC)
I don't think it is quite chicken and egg. The page needs to exist before you put a link to it! I don't think it would be appropriate to implement this in the meta-template until there is a proven demand for it from a significant number of projects. (Generally we try to keep the meta as simple and easy to use as possible by not adding code which is only used by a few projects.) So the way this could work is:
Suggest the idea to a few active WikiProjects who you think might be interested.
Work on adding support for it in their project banner. (I could probably help with this.)
Perhaps it proves useful and some more projects create similar pages and add links to their banners.
Then we can start to think about whether there is an advantage to adding a new parameter to the meta-template.
It is a chicken-and-egg thing. If the template makes linking really easy, it's tempting to use it, especially with one or two examples (projects using it) which I'd have boldly done. I was going to advertise it via the WP:Signpost as a new WikiProject tool, but you can't really advertise a mere idea, especially one fiddly to implement/explain. ("Do what with the banner exactly?") I mean, sure, it's not impossible your way, but I don't have the time to evangelise it in that approach. Rd232talk14:16, 13 May 2010 (UTC)
Speaking strictly for myself, I personally think the best way to proceed might be something like this. If there is a given WikiProject related to the topic, include in its "resources" section a list of all the periodicals which are relevant to the topic. If the bibliography of any given article gets to be a bit excessive, or just to have a single bibliography for the topic in general, create a separate article page, and there already are some such, which could be subdivided as required, if for instance a bibliography on Augustinian theology got too long for the relevant pages, or, like in the case of individual books of the Bible, if the bibliography section is disproportionately long compared to the article itself. But it might be best if the bibliography article/section were limited to certain books, like, for instance, works included in a book which is virtually nothing but a bibliography for a topic or if they are included in numerous college/university libraries. John Carter (talk) 17:59, 14 May 2010 (UTC)
Well, whatever we come up with, we really need to create some guidance (maybe in the WikiProject Guide? or an essay?) and perhaps an example of two to point to, and publicise them appropriately. Rd232talk08:42, 15 May 2010 (UTC)
We probably need to decide on a Wikiproject to associate these with (WikiProject Books? a new WikiProject Bibliography?) for banner tagging and to give us a central discussion location, and we need to consolidate the categories. I dislike dealing with categories, but would be happy to assist in anything else. Hope that helps. -- Quiddity (talk) 20:01, 14 May 2010 (UTC)
I'm not sure that there would necessarily be enough interest for a group, although I think that there is more than sufficient cause for one. The Books project would probably be as good a "home" for such efforts as any other, though, possibly as a task force. I actually have a number of such bibliographies right now on paper, but have some current computer access problems which make transferring them a bit of a problem. I would think, for just lists of relevant journals, for instance, if there is a WikiProject dealing with the general topic such a list of journals or other periodicals which regularly deal with the subject could be included in the space of that project, but that for books and other non-periodical sources a separate list might be better.
One of my ultimate goals (which will probably never actually happen) would be to with luck use these bibliography lists as a basis for writing articles on relevant source materials. For a lot of topics, like controversial groups, including religious groups which don't discuss their own internal workings very often or otherwise try to keep a low profile, finding which sources are most reputable might only be possible by, basically, creating articles on the individual books which indicate how well received by the community they are. For these reasons, I think the idea a reasonable one. A subproject is generally supposed to have five members, and, if you are considering being involved, I would think I would be willing to count as a second interested party. John Carter (talk) 21:05, 18 May 2010 (UTC)
I've been looking recently at inactive WikiProjects (in Category:Inactive WikiProjects; see also Wikipedia:WikiProject Council/Inactive projects). What I'm thinking, first, is whether we shouldn't reconsider what exactly it means for a project to be {{inactive}} or {{semi-active}}. Particularly for well-established projects with a lot of automation set up (project banner assessments, article alerts, new article bot, etc), a project can be very useful for editors without there being any visible activity, and perhaps without new editors bothering to add their names. Ironically, they're less likely to bother if the project is marked inactive! And a particular problem, possibly, is that new editors coming along may be reluctant to remove semi-active or inactive tags, in terms of taking responsibility or not being sure if it's "allowed". One possibility would be to provide a link in those tags to an active central page where they can discuss this (by definition, the relevant project talk page probably isn't a good place for advice). There might be other ideas too, including changing the guidelines for the inactive tag. Or perhaps reconceive the tags altogether: instead of "inactive" or "semi-active", say "low activity" or something less off-putting like that; or even perhaps provide some automated measure of actual activity (eg X edits to project articles in the last 30 days, of which Y by project participants).
Secondly, I wonder if we can find more ways to help all projects be more active. On the latter point, I've created WP:INACTIVEWP, a section in the WikiProject Guide, and created some subdivisions in Category:Inactive WikiProjects to help get an overview. I also wonder if it wouldn't be helpful to have a bot go around and annotate participant lists, splitting off inactive users in a subheading, according to some reasonable definition (eg indefinitely blocked > 1 month, no edits to any page > 1 year). In theory this could also be used to automatically mark projects inactive (if no active participants exist), but that probably wouldn't happen too often anyway. Beyond that, can we find more ways to help merge the small projects that spring up? Or to more generally encourage and support project activity? I think more links between projects, even unrelated projects where pages overlap (eg a norwegian film-maker: WikiProject Norway, WikiProject Films), might help. Other ideas? Thoughts? Rd232talk21:59, 19 April 2010 (UTC)
Three thoughts:
If editors are paralyzed by doubt about whether it's okay to remove a tag that directly says, "Feel free to remove this tag", then their problems are likely much larger than we can solve.
If the members aren't talking to each other, then the project effectively doesn't exist, even if all of the individual editors happen to keep editing articles in the project's area.
Participant lists are kept in so many different formats that I seriously doubt that a bot could process them all... although if you find a way around this, I'd be happy to hear about it; I was thinking just the other day that it's probably time to weed WP:MED's participant list. WhatamIdoing (talk) 22:42, 23 April 2010 (UTC)
I doubt there are that many different formats for participant lists. They're basically all bulleted lists under a heading, either on the main page or a subpage. Some variation between "members", "participants", etc; nothing unsolvable. The remaining ones can be standardised gradually. Rd232talk23:50, 23 April 2010 (UTC)
On the inactive tag - well on the one hand I see why you say that, but on the other hand, what the tag actually says is "Feel free to remove this tag if activity resumes or if this tag was placed in error." This involves a decision with unclear criteria: how is "activity resuming" defined? How much is enough to justify removing it? Who gets to decide that? What does "in error" really mean? Especially for relative newbies who've perhaps not been in an active project before, these issues can all be very mysterious - and there's no obvious place to ask for help. Rd232talk23:50, 23 April 2010 (UTC)
I think Rd232 raises some important issues and has some very good points here. Particularly true is the idea that editors are less likely to bother signing up and/or reviving a project if it's already marked inactive, and this discourages collaboration. I'm in favor of doing two of the things Rd232 mentions, either reword the inactive template to something more off-putting such as "low activity" (this way we could deprecate the semi-active template), and/or change the guidelines to lengthen the time of inactivity to a much longer timespan before placing the inactive template. -- Ϫ14:42, 26 April 2010 (UTC)
Rd232, Please click here, here (be sure to scroll to the end of the page), and here, and then come back and tell me whether you still believe that "they're all basically bulleted lists".
NB that I don't oppose an automated method of identifying active participants. I'd be happy to see an organized annual audit of both participants and projects, and I ask that you start with any project that I've ever interacted with. I just don't think that it's going to be feasible.
OK, so some of them are in tables - big whoop, a bot can handle that, if designed to (or else the projects can change to accommodate the bot, if they want its services; or they can do without). And yes, the bot should also be able to handle the userbox categories, and do something sensible with them (eg comment out the userbox for inactive users). A self-maintaining WikiProject directory is a great idea and could actually be relatively easy if it's set up so the templates which make up the project entries are kept instead on the relevant project page (and maybe merged with the {{inactive}} template). Then all you need is a bot that checks the templates and copies to the directory page. The tricky part would be maintaining the categorisation of WikiProjects, eg "History and society", but I think the template/bot can handle that too. We can turn this into a proposal now, and then WP:BOTREQ and hopefully someone will step up and do it. These two things together would help a lot. A third thing, I think, would be making it stupidly easy for WikiProjects to remind their participants of their existence. What I imagine here is a newsletter bot which on perhaps a quarterly or even monthly basis simply reminds active editors listed as participants "you are listed as a member of Projects X,Y,Z", along with some current tasks (if the project has them) or else the standard {{Help Out}} (with a don't-remind-me optout possible, of course). Apart from reminding the editor, it would also advertise the projects to talk page visitors, who might well have similar interests. Rd232talk11:10, 27 April 2010 (UTC)
unarchived premature archiving
So, how about merging {{project}}, {{inactive}}, {{semi-active}} and perhaps even {{defunct}}, using a new language of "low activity" , and effectively dropping the inactive/semi-active distinction which I think is either not very helpful or even counter-productive in practice (see discussion above)? Rd232talk14:57, 8 May 2010 (UTC)
I'd accept a merge of {{Defunct}} into {{Inactive}}, but not the others. I don't think that there's anything wrong with telling potential participants that a project like WP:AFOD is highly unlikely to respond quickly to their questions. WhatamIdoing (talk) 06:25, 9 May 2010 (UTC)
Well focussing on that "likely response" as an objective makes the merger I suggested make more sense. Projects defined as "semi-active" are unlikely to give a rapid response to passersby either! I do think this "response time" is a sensible way of looking at it, and it makes sense to me to label all projects which still exist and serve some purpose but are unlikely to give a rapid response to a question as "low activity" (could distinguish "very low activity" if we want). Merging the templates is in a way a separate issue, since it's really about adding a |activity= parameter to {{project}}, and we can define the activity levels any way we want, including the existing scheme - but keeps things a bit tidier and more organised. Incidentally, you didn't reply to the incomplete bot discussion above. Rd232talk07:02, 9 May 2010 (UTC)
I don't think that one complex template is preferable to three simple templates, especially where new editors are concerned. WhatamIdoing (talk) 03:39, 10 May 2010 (UTC)
As another editor has pointed out at a very low edit project - he spent 9 months re-jigging a project, I have been party to a number of project creations - some are potentially 'inert' but they serve a very important process - they organise information within a very larger project to keep things coherent - I would even object to 'low activity'. I can think also of larger more aggressive projects that at a point in time try to justify moving in on projects to swallow them up (its true) - I believe that project status should be as loosely defined as possible to (a) respect the integrity of a projects scope (b) allow revitalising by anyone enthusiastic enough to revive flagging projects (c) keep scope challenged editors in larger projects from subsuming adjacent projects simply because they are related (d) allow review of false start or permanently damaged projects to move into more appropriate areas with some level of respect. It is possible for as few as 1 or 2 editors to actually revive projects - if they have the time and patience to go through the process - I believe a page of instructions/essay/guide should be produced for editors shocked to find their favourite subject project is at deaths door so to speak - many editors come and go - there very few long timers around to pass on anecdotes on issues an 'history' of some areas - a revival process guideline would be an important issue of succession management that occurs in many organisations and management structures. SatuSuro02:12, 10 May 2010 (UTC)
To clarify - some merges between projects can be seen to be made in a negative sense - in relation to my comments made above - merges have a few levels to them - they are a case by case issue and not easily generalised about. As for the templates regarding a projects state I would suggest a different wording to project templates this project needs help - rather than this project is currently inactiveSatuSuro02:18, 10 May 2010 (UTC)
I agree with that change in emphasis - that's what I'm suggesting. I've created WP:INACTIVEWP and CAT:INACTIVEWP, and linked the former from the relevant project templates, to try and pull some guidance together. However I do think we need some kind of template indication of the level of activity of a project, because it ensures that currently listed members have some degree of agreement with that. Otherwise, it's purely down to individual editors guessing, by looking at the last dates of talk messages or edit history - which is more likely to be misleading in a low-activity project which still serves a purpose than a "low activity" notice. So I think we need that, but really emphasise the What You Can Do. One thing worth doing would be adding {{Help Out}} to every low-activity project which has little guidance on how new members can contribute. Rd232talk09:13, 10 May 2010 (UTC)
I would agree with the helpout item - you never know who might decide to join in if they saw that rather than last one out turn the light off messagesSatuSuro10:50, 11 May 2010 (UTC)
WikiProjects are useful for a variety of purposes: as topic forum/noticeboards; for motivation; for organising collaborative editing; for collating best practice and devising topic guidelines; and assisting with providing helpful uniformity. Some of these things do require active membership - motivation and collaborative editing for example - while others, such as responding to questions, only require one person to be watchlisting the talkpage; and others still, such as providing guidelines, no longer require any active membership - the guideline is there, and can, of course, be ammended in line with current practice by any editor. SilkTork *YES!20:46, 13 May 2010 (UTC)
Yes. I started that last night, then was called away. I was exploring the notion of what WikiProjects do, and how the notion of "inactive" can apply to them. An essay or guideline that is consulted but hasn't been edited for a year is not neccessarily "inactive". As indicated above, the structure and guidelines that a Wikiproject put in place may well be used or consulted by many people without any visible activity. Wikipedia:WikiProject Essays is looking into essays, and starting to organise and present them in a manner that enables readers to make a quick assessment of how much they are used and valued. The old general essay label of "This essay contains the advice or opinions of one or more Wikipedia contributors. Essays may represent widespread norms or minority viewpoints. Consider these views with discretion." is gradually being replaced by more topic specific labels, with some advice to the reader on how to judge the status of the article, such as "This guidance essay contains comments and advice of one or more Wikipedia contributors. It is not a Wikipedia policy or guideline, though it may be consulted for assistance on the Wikipedia is not an indiscriminate collection of information policy and the Do not include copies of primary sources guideline. A potential measure of how the community views this essay may be gained by consulting the history and talk pages, and checking What links here." Ok, this is much longer, but it is also much clearer and more helpful.
The current inactive and semi-active tags are not helpful, as they do not indicate what it means to be inactive or semi-active. An assessment could be made into a project to see what it has done - some projects start up and collapse quickly having done almost nothing, except try to get support. Should such projects be taken to MfD rather than tagged as inactive? What are we telling people when we tag an article as inactive? Is it mainly about the forum/message-board aspect? That messages left on this project's talkpage may not be answered? If that is the case, then where should the person be going? If someone has a question about a topic covered by an inactive project, where else might they go to get an answer? One of the listed participants? A parent project? The talkpage of the main article for that topic?
Maybe what we need is a new project aimed at cleaning up inactive projects. Or is that the role of the Council - and what is needed is a Council TaskForce? - WikiProject Clean Up! SilkTork *YES!11:13, 14 May 2010 (UTC)
It could/should be a Council role, but the Council is (ironically) semi-active at best. I did recently go through Category:Inactive WikiProjects and create subcategories, mark some pretty unambigously defunct project/pages as defunct, and add a link in the inactive/semi-active tags to the parent project. I think the main "activity" issue is indeed the "likelihood of reasonably rapid response". Maybe a solution to this would be to limit the talk pages of WikiProjects to meta discussion about the project, and have noticeboards for discussion about content. These noticeboards could be merged more easily and more frequently as necessary; plus if there's few enough of them, you could have a navbox for them (which you couldn't have for 1500+ wikiprojects). I would also merge semi-active/inactive tags and make them both use the phrasing "low activity", perhaps with further encouragement to passers by to do something about it. How does that sound? Rd232talk11:43, 14 May 2010 (UTC)
I would support rewriting the tags so they contain helpful information. Merging may or not be appropriate depending on the rewrite. An inactive project is going to be different to an semi-active one. At least with a semi-active project (such as WP:Beer) there is a liklihood people will get a response to their questions; with an inactive project there will be no response at all. In general, as it would useful to do something about inactive projects, and there are few enough people interested in this area, I would support and encourage you to do what you feel is appropriate. I have an intention to help out, though as my Wiki activity is quite low at the moment and I already have a handful of commitments still to be completed, how much that intention is turned into activity I couldn't say! SilkTork *YES!07:47, 17 May 2010 (UTC)
I think that some of the comments indicate a fundamental misunderstanding of WikiProjects. WikiProjects are not super-categories, or methods of organizing information, or collections of advice pages: WikiProjects are first and foremost social groups. When members of any social group stop interacting with each other, then the group ceases to exist in any meaningful fashion.
Put another way: WikiProjects are the equivalent of a bunch of students who usually sit at the same table in the school cafeteria. They talk, they work, they make decisions, and they leave evidence of their existence (e.g., by vandalizing the tables). If, at the end of the school year, the students all leave or otherwise lose contact with each other, then the group no longer exists. What the group once carved into the table is not the group; it is only evidence that the group once existed. Similarly, WikiProject pages are not the group; they are only evidence that a group once existed. WhatamIdoing (talk) 04:27, 23 May 2010 (UTC)
Rollbacks and sinebot
Can we make rollbacks roll right over sinebot's edits so the actual vandalism can be reverted? Is there some way around this presently that I'm unaware of? Equazcion(talk)00:10, 12 May 2010 (UTC)
Which I just realized was started by you in the first place! duh :) - -Ϫ
Ha, I forgot all about that. The general response there seems to have been that there is no actual problem, but I'll insist that there is. When some IP or newly registered vandal makes a nonsensical comment at a heavily-trafficked discussion page (ie. ANI), sinebot renders rollbacks useless; and the heavy traffic and large page makes it hard to make a quick revert, especially when the vandal created a new section and you need to open the whole page for editing. I think sinebot's edits should count as an edit by the user being signed for, as far as rollback is concerned. There's pretty much never a need to rollback sinebot's edit alone. Equazcion(talk)22:34, 13 May 2010 (UTC)
I'm not that familiar with it; though I have tried it briefly in the past. Regardless, while I assume scripting fixes are possible, that still leaves the standard rollback feature "broken". Why not fix it? Equazcion(talk)20:27, 14 May 2010 (UTC)
It would be acutely annoying if it became impossible to rollback bot edits; bots screw up on a regular basis, and being able to go to contribs and Ctrl+click all the rollback links is the only viable way to clean up such messes. How is the software to know the difference between a rollback action aimed at the bot edit itself, and a rollback action aimed at the edit underneath? Happy‑melon20:36, 14 May 2010 (UTC)
Good question. I'm not suggesting this for all bot edits, just sinebot. When's the last time that one screwed up in a way that required use of rollback? Anyway, lucky for us, we're in the brainstormy, optimistic section of the village pump, created to break free of the usual doubt-defaulting discussions of Proposals. Unless you're saying that this is a non-issue, or that dealing with it is fundamentally a bad idea, then as we say in the edit notice, "If possible, suggest a better variation of the idea, or a better solution to the problem identified." I'm open to suggestions. Equazcion(talk)21:09, 14 May 2010 (UTC)
Oh absolutely, that wasn't a rhetorical question. I do think that making all bot edits transparent to rollback is a very bad idea; and I can't think of a pleasant way to single out Sinebot in particular. Maybe making the transparency optional would work... Happy‑melon22:00, 14 May 2010 (UTC)
Hm.... It may be possible to have sinebot include an (undo) link in their editsummary, which would undo the bot edit, and the edit made just before that (course it would take longer than normal rollback, but it might help address Happy-melon's concerns). Also, I'm not sure that I fully support this, just an idea... :P SpitfireTally-ho!15:19, 19 May 2010 (UTC)
I propose that all articles about towns with population less than X, and with nothing on their talk page, be deleted due to lack of notoriety.
I don't know what number to put in in place of X. Rebele | Talk The only way to win the game is to not play the game. 07:30, 16 May 2010 (UTC)
There is nothing wrong with having data about tiny little burgs on WP... It's not using space or depriving anyone of a satisfying user experience — if someone took the time to create a page on a micro-sized locale, what's the problem with keeping it? What possible rationale is there for deleting someone's work over something as petty as "current population"? I have personally — and I'm not making this up, I'm serious — in the past couple of months been able to link to pages of a couple teeny tiny towns from history pages that I've written — obscure little places that were perhaps important a hundred years ago and now are more or less ghost towns. The articles were unquestionably improved by giving the user the opportunity to see exactly where the little micro-places were with blue links at the appropriate juncture. Seriously, more information is better! Carrite (talk) 01:29, 17 May 2010 (UTC)
I completely agree, but these were not created by people. They were created by a bot from a census data download. Rebele | Talk The only way to win the game is to not play the game. 01:46, 17 May 2010 (UTC)
There should be no such implementation. The opposite is true too, however, in that something shouldn't be kept because it happens to have a few people living there and people call it a name. Notability should be the keeper or destroyer every time. But some people disagree. ♫ Melodia Chaconne ♫ (talk) 02:10, 17 May 2010 (UTC)
Every town and community is notable. Some are just more significant than others. But if that stuff is in the system, if it is accurate, there is no point in losing it. Carrite (talk) 02:28, 17 May 2010 (UTC)
There is a difference between notability and existence. I'm bringing this up now because we are entering a new census cycle. I think we should set a policy now rather than turning the policy making over to a bot. Rebele | Talk The only way to win the game is to not play the game. 02:50, 18 May 2010 (UTC)
Set which policy? If it is notable, it is notable; if it isn't, it isn't. And if it doesn't exist it can't be notable. Is there anything else we need to care about? --Duplode (talk) 02:55, 18 May 2010 (UTC)
Lets start over. I'm trying to define "notable" for a small town. I want to say that any town with a population of X and nothing on its talk page, is inherently not notable. This is a page to toss around ideas beefore they are formally proposed. There are some who have said that my supposition is wrong. They did this by saying that X should be zero. Are there any other opinions out there? Rebele | Talk The only way to win the game is to not play the game. 07:17, 21 May 2010 (UTC)
Honestly, even a town with a zero population in 2010 is notable, since it had a population of greater than zero in the past, otherwise it wouldn't be a town. Carrite (talk) 02:58, 22 May 2010 (UTC)
I think that the best (and perhaps only) evidence of notability is that some source noticed it. If people are writing books about a particular town because it is remarkably tiny, or a ghost town, then we should have an article about it. If, on the other hand, a place is larger but less noticed, then we shouldn't. Arbitrary numbers are not good substitutes for editorial judgment. WhatamIdoing (talk) 04:32, 23 May 2010 (UTC)
the is no subject wherever where a book about the subject is needed to prove notability. Ever inhabited place has been noticed by a RS, or we wouldn't include it because we wouldn't know about it, but this is a matter of WP:V, not WP:N. Places we can not verify are deleted. The virtue of the rule of including all verifiable places that have ever been inhabited, is that is saves us several hundred thousand deletion discussions. DGG ( talk ) 23:23, 17 June 2014 (UTC)
The manual of style does not explain how to account for inflation when adding currency denominations to articles. As such, I would suggest that each currency template also include an inflation calculator such as {{US$}}. Anyone have any thoughts?Smallman12q (talk) 20:51, 17 May 2010 (UTC)
That editors should follow the sources instead of doing their own calculations, especially if long time periods, obsolete currencies, or subject-specific issues are involved. A pound of silver is still a pound of silver, but that lump of silver buys both more food and less cooking than it did five hundred years ago. Most editors won't know which price index is appropriate. You are best off following your sources rather than applying a blanket inflation rate to everything. WhatamIdoing (talk) 05:20, 23 May 2010 (UTC)
Can I cite information in an article from a person that article directly pertains to?
Title says it all. As it happens, the lead singer of Blessid Union of Souls has told me some information about the history of the band. Is there a way to cite our discussion itself as a legitimate source? As a side note, something like this has happened with the articles for xkcd (the creator stated that an image is warranted) and Homer Simpson (someone related to the creation of the character, I don't remember, stated that the article is accurate and approved it). Tezero (talk) 02:05, 23 May 2010 (UTC)
No. Wikipedia requires that it be possible to verify all material in a published source, and personal communications are not published. See the canonical list of invalid proofs, specifically under "I saw Karp in the elevator, and he said..." WhatamIdoing (talk) 05:28, 23 May 2010 (UTC)
Oof. I just realized while I was walking the dog that I may not have been clear about the issue. The singer has a Wikipedia account, and our discussion was on a talk page here; I could provide a link to it if needed. Tezero (talk) 22:37, 24 May 2010 (UTC)
Display summary on WikiLink Hover
When a user hovers their mouse on a wiki link, the first 255 or so characters of the link's summary paragraph can display in a small box. The box disappears when the mouse is removed from the link. It would then be easier to read an article without following every wiki link that one is unsure of.--Brylie (talk) 06:19, 27 May 2010 (UTC)
The idea isn't that bad in principle, but that'd cost over two hundred more bytes per link, which for readers with slow connections would be a Bad Thing. A. di M. (talk) 17:29, 28 May 2010 (UTC)
I always open multiple tabs when browsing the web. (And only a tiny part of each HTML-page-title is shown by the web browsers' tab-titles).
I use the Wikipedias of various languageges. Some of them have the exact same standard ending on their HTML-page-titles, namely: "- Wikipedia". (Which sometimes makes it a bit cumbersome to keep the various language-versions apart, when I save Wikipedia articles to disk for offline reading).
It would be a gret help if I could:
Automatically shorten the first part of the HTML-page-title on all wikipedia titles starting with: "Wikipedia:<The rest of the title>" into: "W:<The rest of the title>" and from: "Help:<The rest of the title>" into: "H:<The rest of the title>", and so on. This would make the tabs in the browser more navigable.
Automatically change the ending of the HTML-page-title, on all wikipedia pages, from: "<The beginning of the title> - Wikipedia, the free encyclopedia" into: "<The beginning of the title> - Wikipedia,EN". Of course, for instance on the swedish (sv.wikipedia.org) I will want to change the ending from: "- Wikipedia" into: "- Wikipedia,SV", and accordingly for other languages. This would automatically make the articles saved to my harddisk more navigable, because the browser's proposed save file name is based on the HTML-page-title.
(In case you who read this, happen to only use English Wikipedia, I had better mention that each language Wikipedia has its own set of preferences setings, so even if one uses the same username everywhere, the different behaviour for the various language editions clearly will not be anyway difficult to set up).
Now I wonder:
Can these things be done from a line of javascript code in the file: [[User:<username>/vector.js]]?
And, if so, :-P would anyone be so kind as to please tell me what to write?
It will substitute "WP:" for "Wikipedia", "WT:" for "Wikipedia talk", and "Wikipedia,EN/SV/etc." for "Wikipedia, the free encyclopedia", but currently nothing else. PleaseStand(talk)21:57, 30 May 2010 (UTC)
Why does Wikimedia need more than one MediaWiki installation?
In the course of trying to fix bug 3525 (and thereby help implement Wikipedia:Integrated watchlists), I've been trying to set up a small wiki farm, and realizing what a pain in the neck it is. And it occurred to me (not for the first time), why does Wikimedia need more than one wiki?
Why not design MediaWiki with a field in the page table designating language? Then the user, rather than going to the French Wikipedia, or the English Wikipedia, or whatever, could just switch between French mode, English mode, etc. It could be set up so that if you click on, say, en.wikipedia.org/wiki/Fromage, it will map that to some parameter to Index.php telling MediaWiki to show you the English version. That could help handle name collisions between, for instance, en:fromage and fr:fromage. Interwiki prefixes could also be mapped to the appropriate parameterized url.
RecentChanges, watchlists, etc. could be set up to optionally filter by language. But they could also be integrated, if the user wished. The issue of interwiki page existence detection (or lack thereof) would also be addressed by this (see bug 11).
I'm not sure which is more awkward — our current approach or this one. Either way, some coding will be needed to manage in a more unified way the content that is spread across Wikimedia's several hundred wikis. While you ponder this, I'm going to go back to trying to figure out MediaWiki.org's instructions on wiki farms, Central Auth, and related configuration settings. Tisane (talk) 12:11, 27 May 2010 (UTC)
Strongly support the concept of unification of infrastructure (that is, the MediaWiki installation), but very strongly oppose the actual incorporation of individual projects within the Wikipedia umbrella, as it couldn't possibly work from an editorial point of view. If the MediaWiki installations get merged someday there should be different namespaces for the sister projects, and editorial and behavioural policies and guidelines should be kept separate for each of these namespaces. --Duplode (talk) 20:11, 28 May 2010 (UTC)
Well, okay. It's probably overreaching to support unification of projects/policy/adminship/etc. So I suppose a bug should be submitted to Bugzilla suggesting that a new division be created that basically fits somewhere in between different namespaces and entirely separate MediaWiki installations? I suppose the most plausible way this could be implemented would be as an extension. Tisane (talk) 20:22, 28 May 2010 (UTC)
Just a technical note. If you're starting a wiki farm from scratch, you don't need CentralAuth. CentralAuth was basically designed for Wikimedia. If you're starting from scratch, there are easier options. Mr.Z-man01:50, 29 May 2010 (UTC)
Thanks for the tip; I may well use that in the next wiki farm I create. The difficulty in getting CentralAuth to work properly, and the fact that most wiki farms don't need CentralAuth, probably accounts for a big part of the reason why no one has yet created the CentralAuth enhancement needed to fix bug 3525. I've begun some preliminary work trying to gain an understanding of CentralAuth (and of what I need to do to get it to work properly). mw:Extension:IntegratedWatchlists. CentralAuth is undoubtedly the hardest extension to properly configure that I've ever encountered. Brion was not exaggerating when he called it "horrible and scary." Tisane (talk) 07:25, 29 May 2010 (UTC)
Limiting sockpuppet creation by requiring a verified email address during account creation
Sockpuppets are one of the scourges of Wikipedia. See: WP:SOCK. They may discourage more editors than almost anything else on Wikipedia. They ruin many articles for long periods of time. They waste lots of admin time. It is too easy to create sockpuppets.
A simple way to limit their numbers would be to require a verified email address during account creation. Currently, a verified email address is not required to create an account at Wikipedia. We might grandfather in all existing Wikipedia login accounts. All new account creations would require a verified email address. It will discourage many people from creating sockpuppets.
Logins at many places require a verified email address. That is where one gets a confirmation email with a link to verify. It makes it more difficult to spam sites with multiple logins and sockpuppets. Wikipedia could use the same method.
Many people, myself included, have multiple email accounts. One with my real name for family communications, etc.. One alias email account for Wikipedia and other editing and activism. One alias email account to receive list mail that I check less often.
There are only a limited number of big email providers: Gmail, Yahoo Mail, Hotmail, etc.. So once someone creates a few accounts it is problematic to create more email accounts with better-quality email providers.
Cookies make it problematic to maintain more than one account with any particular email provider. Signing in and out of 2 accounts with the same email provider takes time, and doesn't always work well. One can put one Yahoo Mail account with Firefox, and one with Internet Explorer. But then there are bookmark synchronization problems. Plus there is the time factor of checking multiple email accounts. So most people limit themselves to only a few email accounts. Even masters of sockpuppet farms will dislike all the cookie manipulation, email account creation, and remembering all their accounts. --Timeshifter (talk) 03:57, 17 May 2010 (UTC)
It seems to be a good Idea. It would <censored></censored> me off if i had to create a ton of email addresses. But couldn't someone just use one email account for all their socks, or is there a way to prevent that? wiooiw (talk)04:25, 17 May 2010 (UTC)
I don't know if the current MediaWiki software settings allow the same email address with multiple Wikipedia accounts or not. Maybe someone else knows. Many other sites do not allow the same email address to be used for multiple login names. So I assume it can be done at Wikipedia if it is not being done already.
In my Wikipedia preferences I unchecked "Enable e-mail from other users". So my alias email address is not known to other Wikipedia editors in most cases. So I could create a sockpuppet farm without average editors noticing I was using the same email address. So I don't think using the same email address should be allowed for multiple Wikipedia accounts.
My real name is not used anywhere in my alias email settings, and so I maintain anonymity at Wikipedia, etc.. Registering with an email address mainly allows me to retrieve my Wikipedia password if I lose it. People have nothing to fear from the requirement of an email address during account creation. --Timeshifter (talk) 04:51, 17 May 2010 (UTC)
This makes a lot of sense. The other thing is, though, that temporary email addresses should not be permitted either in order for this to work. {{Sonia|talk|simple}}05:25, 17 May 2010 (UTC)
I mean that it is possible to mass-generate email addresses that expire after an hour, but are nevertheless valid at the point of registration. {{Sonia|talk|simple}}07:57, 17 May 2010 (UTC)
Just for the record, there's no problem with having piles of email accounts with Hotmail, Gmail, etc; many people do so to segregate their mail. In fact, many ISPs grant half a dozen email addresses as part of their service, and will usually provide even more if requested. Finally, I am not sure that requiring an email address for registration would be in keeping with the WMF principles that overlay all of the Wiki(p)(m)edia communities, in particular the privacy policy, but also the "anyone can edit" principle. Risker (talk) 05:30, 17 May 2010 (UTC)
I have 2 Yahoo Mail accounts. One has to sign out of an account in order to change to another account. One has to then sign into the other account. I just tested it again to be sure. It is time-consuming and a pain.
There is no privacy problem for me. I am anonymous right now as I edit Wikipedia. I use an alias email account from Gmail for my Wikipedia account. My real name and info is not used anywhere in that email account's settings. I haven't used ISP email for many years. Many people do not want to risk losing their ISP internet access by using ISP email for spam and harassment. ISPs can be contacted and people can lose their internet access. My idea is not perfect, but it will help. Anyone will still be able to edit. --Timeshifter (talk) 05:58, 17 May 2010 (UTC)
Anyone can make an email account. Also, any limitation is better than none- I have 4 gmail accounts, two hotmails, a yahoo, plus several on relatively unknown sites and most of them forward to the one account, meaning I don't even have to sign into them. But it would still be a pain for me to have to type one in every time I make a new account. I'm not actually so concerned about fully-fledged sockfarms with this approach- it won't hinder them very much at all. I think it will be good for restraining users like Pickbothmanlol's account creation rate. Just stopping users "flooding" with new accounts that need to be blocked- or worse, oversighted. {{Sonia|talk|simple}}07:57, 17 May 2010 (UTC)
The problem is that the more you make it a pain in the neck for the sockpuppeteers, the more you also make it a pain in the neck for legitimate new account creators. Tisane (talk) 08:06, 17 May 2010 (UTC)
Aye, but I have to fill out my email, check it and click on a confirmation link for many if not most other websites already. The proposal here is just that you enter a valid email address. It shouldn't take too much longer for your average netizen, but it will be a massive pain in the neck if I'm trying to make work for oversighters. {{Sonia|talk|simple}}08:12, 17 May 2010 (UTC)
Are sockpuppets even a big problem? What potential do they have to negatively impact the project? Article content is determined not by voting but by reliable sourcing, manual of style, etc. And xFDs, blocking decisions, and such are determined more by policy and guidelines than by measuring numbers of users on each side. They could theoretically affect elections (e.g. checkuser/arbcom/admin) but there are safeguards there too. E.g., if a bad user is elevated to one of those positions, everything he does is subject to scrutiny by others, so there are limitations on how much havoc he can wreak. Then there is the fact that new users' comments in forums like xFD are usually flagged as coming from new users, which can clue the closing admin in to the possibility that manipulation is occurring. It would take a lot of time to create a bunch of accounts and then get them to a point of having a lot of good edits in their histories. I think we have enough mechanisms in place to prevent sockpuppetry from being a big deal. Tisane (talk) 08:35, 17 May 2010 (UTC)
Sockpuppets are a big problem. Sockpuppets become old users in a few months. Many last for years undetected. Less sockpuppets is a good thing. There have been campaigns and groups to create sockpuppets. --Timeshifter (talk) 09:54, 17 May 2010 (UTC)
I would actually take it a step further, and make it a requirement of editing. There is probably more time spent chasing random IP vandalism than there is in tracking down sockpuppets. The same argument applies - many sites, forums, etc. require an active email account to post. Why not here too? And it really doesn't take that much time that it is likely to deter new, genuine editors - but might just reduce the overhead burden placed on existing editors whose contributions would be more productively applied in tasks other than vandal patrol. It won't eliminate it all, but any reduction would be worthwhile, and requiring a valid email might act to reduce the persistent ones who seem to relish the wait for a block to be lifted to start their nonsense again. --Haruth (talk) 10:12, 17 May 2010 (UTC)
Preventing IP editing is a separate issue, and should be discussed in a new thread. I have mixed feelings about that idea. Cost-benefit analysis, etc.... --Timeshifter (talk) 12:23, 17 May 2010 (UTC)
Now you've hit the third rail of Wikipedia proposals, the WP:PEREN "prevent annonymous editing", which has been done totally to death. Happy‑melon13:08, 17 May 2010 (UTC)
I'm ambivalent about requiring a valid email to edit, I think it has both upsides and downsides. But I definitely think that requiring each account on a project to have a different email address is a very bad idea. It's extremely disruptive to legitimate editors (I have three accounts, for instance, User:Happy-melon, User:Also-Happy-melon and User:MelonBot; do they really all need different addresses??), and no real hindrance at all to legitimate users. What we rather need is the ability for CheckUsers to do match-tests on email addresses: "get a list of accounts with the same email address as this account". Happy‑melon11:30, 17 May 2010 (UTC)
I don't have a problem with the same email address being used for multiple accounts if permission of an admin is required each time, and all the user names are listed on each user page.
I also don't think that initial implementation should require old editors to provide verified email addresses. Only new editors. We could see how it works out with new editors before thinking about phasing this in for old editors. We may never require old editors to provide email addresses.
Requiring a verified email address upon new account creation does not require action by CheckUsers, or anybody else, to work. It is preventive. --Timeshifter (talk) 12:39, 17 May 2010 (UTC)
It's just not viable to restrict email duplication at all, there are perfectly legitimate reasons why two accounts could have the same address. Email addresses are private data; they can't be shown by the software except to CheckUsers and Oversighters. Implementing an admin interface for "this person wants to set the email address on this account to be the same as the email address on that account" doesn't achieve anything except to irritate legitimate editors. Much better to allow duplicate email addresses but give CUs the ability to look for them, and thus wrap up whole farms of naive socks in one go. Happy‑melon13:08, 17 May 2010 (UTC)
It won't take long for word to get out, though. The naive socks are probably the least of our worries. Tisane (talk) 13:30, 17 May 2010 (UTC)
It certainly won't take long for the 'pro' sockmasters to start using separate email accounts, but that's expected. The point is that you've achieved the same effect (sockmasters have to go to the trouble of setting up many email accounts) without inconveniencing legitimate editors. If you force email accounts to be unique, you a) lose the opportunity to catch naive sockmasters easily, b) don't force experienced sockmasters to do anything they wouldn't have done anyway, and c) needlessly annoy legitimate editors. Happy‑melon13:57, 17 May 2010 (UTC)
(unindent) Most other sites have no problem during account registration with checking for other usernames with the same email address. And anonymity is maintained since it is the software that does the checking.
There aren't that many people legitimately using the same email address for multiple accounts. So I don't see it as a big inconvenience. And it is faster to check ahead preventively than to check afterward. And it is less work for CheckUsers. Inconvenience overall is less. CheckUsers will have less work to do. And naive socks can cause a lot of damage and irritation in a short time. They can cause other editors to stop editing pages they camp in. So cut them off quick and early before they have a chance to inconvenience honest editors. --Timeshifter (talk) 14:13, 17 May 2010 (UTC)
I think this is a bad idea because the bad would outweigh the good. The good is that it would make a little bit more trouble for sockmasters (but really, changing IP's to evade checkusers is a lot harder than changing email addresses), the bad is the trouble that it would cause the 99% of users that are legitimate. Also that many legitimate users would create throwaway accounts that they would never intend to use, because they would not want WP email coming to their main email box, and then people would email these people and they would never see the emails. —Soap—16:55, 17 May 2010 (UTC)
Most people use watchlists not email. Changing IPs is not necessary currently to evade CheckUsers. CheckUsers are too busy to check all suspected sockpuppets. It is difficult and time-consuming to go through the process. It is no real trouble for users to give an email address. There are no lack of comments at blogs and elsewhere. Most use their verified email address while filling out the form for a username. Email address is kept private. Wikipedia is behind on this one. --Timeshifter (talk) 17:47, 17 May 2010 (UTC)
Your comments on the CheckUser tool and sockpuppet investigations are not correct. Editing from multiple accounts on the same IP will result in a sockmaster being caught by a CU very easily; it is in fact essential to vary your IP to evade a casual Checkuser. CheckUsers are indeed very busy and are not involved with all SPIs, but their assistance is invaluable in many investigations, and any extra tool for them is invaluable. Happy‑melon18:42, 17 May 2010 (UTC)
I agree that evading Checkuser requires varying your IP. But you misunderstood me. Most sockpuppets are never investigated by Checkuser. New sockpuppets are constantly being created.
So you are for requiring a verified email address for all new usernames, but without restricting the number of usernames per email address? I could go for that as a start. Especially if Checkuser does frequent sweeps. But won't that overwhelm Checkuser with having to question all these users about why they have more than one username? --Timeshifter (talk) 05:01, 18 May 2010 (UTC)
After reading all of the above arguments I still fail to see why one should believe the proposal would slow down sockmasters to any noticeable extent. It's not like creating new e-mail accounts was hard and troublesome enough to stop someone willing to cause disruption. Furthermore, webmail providers like Yahoo allow you to create an alias mail address associated to your existing account, meaning it wouldn't take more than a couple seconds for someone to set up a throwaway - but perfectly valid - address. As far as I'm aware of mail confirmations are generally used to stop robot spammers, and not real persons creating alternate accounts. I stand by Soap's position - there would be no significant benefits to justify the nuisances created. --Duplode (talk) 18:05, 17 May 2010 (UTC)
Yahoo Mail only allows alias email accounts if you have the paid Yahoo Mail. Very few people have that. From Yahoo Mail options for my account: "Disposable Addresses: Disposable email addresses help guard your primary address against spam. Upgrade to Mail Plus to get this feature."
Comment. Most people don't want to create another email account. Requiring a separate verified email address per username would probably stop about 90% of new sockpuppet creation. --Timeshifter (talk) 04:54, 18 May 2010 (UTC)
Comments:
As an user of free Yahoo Mail which does actually have an alias mail address I can ensure you that even without a paid plan you can have one (and exactly one) alternate address - which is a different thing from their disposable addresses. Also, once created the alias can be changed at will, so badfaithuser_AT_yahoo.com can easily create a sockpuppet1_AT_yahoo.com alias, register in Wikipedia using this address and then just as easily change the alias to sockpuppet2_AT_yahoo.com, rinse and repeat. I'm talking about Yahoo Mail because I do know the procedures, but I guess there should be similarly easy ways of dealing with the restriction for people using other mail providers.
Why "most people" wouldn't want to create another email account? In other words, is there any reason not to believe this additional restriction would make bad-faith sockmasters instantly change their minds and want to create other email accounts?
Any particular reason for using boldface in your comment?
Emphasis is a study aid, and helps focus. I only see one Yahoo email address allowed. What tab (or page) in options, profile, account info, etc. are you referring to in Yahoo Mail? I mainly use Gmail, so I may be missing out on how to create another Yahoo Mail address.
On the Yahoo account info page ("your account information") I see a place for an alternate email address so that Yahoo can contact me. That is common with most web-based email, and is mainly for retrieving lost passwords. There is only one spot for a Yahoo Mail address. It is labeled "Yahoo! Email". The other spots are labeled "Email 1", "Email 2", etc..
The "Add Email" button allows one to create more and more spots for entering more of those alternate email addresses. It does not create email addresses. If I am having all this difficulty creating another Yahoo Mail address with the same password, then so will many others (such as many sockmaster wannabes).
Most naive sockmasters aren't going to go to a lot of trouble to create a sockpuppet. In my experience most sockmasters are not very experienced editors, and are looking for a shortcut to get their way in editing conflicts. If they had more patience they wouldn't be bothering with sockpuppets. Since they don't have a lot of patience they are more easily discouraged by having to provide a verified email address for each Wikipedia username.
I'm still not clear why there is this perception that sockmasters will have any difficulty at all creating throwaway email accounts (gmail has an unlimited number, as far as I can tell). A lot of them already use throwaway email accounts, so this would have a negligible effect on them. Meanwhile, the more steps involved in registering an account, the less likely someone is to do it. We do not under any circumstances want to dissuade participation in this site; we are still the encyclopedia that anyone can edit, and that is a feature, not a bug. And all of my alternate accounts (they're listed on my userpage, I forget them all) go to the same email address; in fact, I think that is pretty standard for most people with acknowledged alternate accounts. Risker (talk) 19:39, 18 May 2010 (UTC)
I do not see a way in Gmail to create additional gmail addresses for the same account. I just checked the settings.
Anyone can edit Wikipedia, and will be able to with a verified email address. Most people do not need multiple Wikipedia usernames. For the rest of your questions please see my previous replies, and try to understand them. Additional ideas and variations welcome. Please see the note at the top of the page. --Timeshifter (talk) 22:08, 18 May 2010 (UTC)
Suggestion for all the people worried about legit alternate accounts: What about if, you didn't have to create a new email if you went to special:CreateAccount while logged in? That produces a clear entry in the logs that this person created these accounts. Ergo, useful for us to confirm alts, very unhelpful for sockmasters. {{Sonia|talk|simple}}08:39, 19 May 2010 (UTC)
Sounds like a good idea. No need to contact an admin first in order to use the same email address for multiple Wikipedia usernames. --Timeshifter (talk) 11:22, 19 May 2010 (UTC)
Having to provide a verified email address for every separate username would slow down this sockmaster, and others. Having to create 800 email accounts would take a few minutes for each one. All those hours and days creating email accounts is less time distorting articles, discouraging other editors, and hurting NPOV. And less time spent by Checkusers. --Timeshifter (talk) 11:22, 19 May 2010 (UTC)
By the way, I bagged and tagged my first sockmaster today. :)
After spending hours researching just one small-time sockmaster, and following through on it at Wikipedia:Sockpuppet investigations/Harmonia1/Archive, I see that anything that prevents even a small percentage of sockpuppets saves a lot of time.
Each one of those 4 sockpuppets of Harmonia1 had to be investigated. If Harmonia1 had to have created 4 email accounts, he would have been less inspired to create them all. He may have created only 1 sockpuppet. He also fabricated stories for all of them. That all takes time.
So why not make it more difficult and timeconsuming to create sockpuppets? Why do editors have to suffer? Make the sockmaster have to waste time.
In the last few months I have seen sockpuppet problems in multiple areas I work on. In various topic areas. Why are we tolerating more sockpuppets? Wikipedia quality is more important than their games. --Timeshifter (talk) 11:45, 22 May 2010 (UTC)
Although I feel strongly about reducing sockpuppetry, I do not as a rule give out personal information online, and I would have to oppose this proposal because of concerns over two groups of users who would be excluded if this proposal takes effect. The two groups would be those who do not desire to give out personal information online, and those who do not have an email address. I feel a better way of reducing sock puppetry would be to increase the use of checkuser. Immunize (talk) 13:07, 22 May 2010 (UTC)
There are people online without email addresses?! Just kidding. I agree with you about increasing the use of CheckUser. We need more Checkuser admins. I don't know why its use is made so difficult. As far as I know it does not pull up personal info. I thought it just pulled up IP numbers.
Providing an email address does not necessarily provide personal info online. My Wikipedia email address provides no info about me. The name is an alias, and the street address and city are not mine. My email address would have to be followed back to my internet provider, and they would have to provide their IP logs attached to their internet accounts. They usually don't give them out except to law enforcement. Law enforcement can follow the Wikipedia IP logs back the same way to the internet providers, and so providing an alias email address is not a problem to users.
As for the few Wikipedia editors without an email address we could provide a link to info about alias email accounts, and their ease of use. --Timeshifter (talk) 13:31, 22 May 2010 (UTC)
The considerations about giving out a mail address in registration not being a big deal are certainly correct, but they are only sound natural to us, experienced Internet users. For the average citizen that fact would not be obvious at all, and so it is very likely that many people would think twice before registering. --Duplode (talk) 17:07, 22 May 2010 (UTC)
Re. Timeshifter: The checkuser tool pulls up (among other things) a user's IP address; that is their location and their ISP. As such, it provides very personal information about a user, and could potentially be used to facilitate unwanted contact with a user in real life. Per WMF's privacy policy and their policy on checkusers, we need to be very careful about a) who is given the checkuser tool, and b) how it is used. On the note of compulsory registration (with a verified e-mail) I'm pretty sure that this idea has been turned down before, as it is deemed to go against the spirit of an open wiki, furthermore to this, it's very much an indiscriminate slash and burn method to solving the problem of sockpuppetry (it would effect legitimate users as well as illegitimate ones), and it also wouldn't make it that much harder to sock. Kind regards, SpitfireTally-ho!18:13, 22 May 2010 (UTC)
Duplode and Spitfire. People comment on blogs all the time. Most blogs I have seen require registration with a verified email address nowadays. I sometimes think many Wikipedia users don't get out enough. :) Out of Wikipedia that is. Email addresses are not seen in most blog comments. They are kept private. If people are worried about admins seeing email addresses, then email addresses can be kept encrypted except to checkusers.
There can be periodic searches for accounts with duplicate email addresses by the Mediawiki software also, as initiated by checkusers. If we allow people to use the same email address for more than one username, then that would be a way to catch some of the sockmasters.
I agree that we should be careful with who gets Checkuser access. I am just repeating what others have said, and echoing the thought that we need more people with that access. All vetted thoroughly. --Timeshifter (talk) 20:20, 22 May 2010 (UTC)
The point we're making is not what you seem to think it is: "you shouldn't make people have to register with a verified e-mail to edit because that would reveal their email address to the public". The point we're making is: you shouldn't make people have to register with a verified e-mail to edit because it goes against the idea of an open wiki and it is a hassle. It would also have the opposite to the intended effect: if I didn't have an account and I was reading an article and I noticed a spelling error, I wouldn't go to all the hassle of making an account and verifying an email address just to fix that error, however, if I was a long term sockpuppeteer who got a kick out of disrupting wikipedia, I see no reason why I wouldn't go to a few extra lengths to continue my disruption. As I have said this idea has been rejected before. You may also want to look over Wikipedia:PEREN#Prohibit anonymous users from editing (which also includes some arguments I haven't mentioned). In my honest opinion, this idea (if implemented) would probably not have the intended effect, and would have some nasty secondary effects. Although I understand the reasoning behind what you;re trying to put across, I don't think it'll be very effective in practice. Regards, SpitfireTally-ho!20:59, 22 May 2010 (UTC)
It isn't a hassle to provide a verified email address when registering one user name. It is common all over. Almost everybody has an email address. Many sockpuppet masters would not go to the trouble of creating new email accounts. A percentage would go through the process. This has not been rejected before as far as I know. This isn't a vote anyway. --Timeshifter (talk) 21:43, 22 May 2010 (UTC)
Never said it was a vote, the idea lab is for receiving feedback on ideas before putting them forward, to help perfect them. However, normally ideas listed at Wikipedia:PEREN are very unlikely to be approved. Kindest regards, SpitfireTally-ho!22:36, 22 May 2010 (UTC)
It is not listed there as far as I have heard. Idea lab is for creativity and feedback that expands further on things, and not just repetitive negativity as often occurs at VP-Proposals --Timeshifter (talk) 04:05, 23 May 2010 (UTC)
Just because it's common doesn't mean it's "not a hassle"; indeed it unquestionably is a hassle. You can argue that the extra hurdle is justified, but to claim it doesn't exist is disingenuous. It's certainly the case that implementing compulsory email verification would deter a fraction of sockpuppeteers, especially if we built email-matching into CheckUser. It would also definitely deter a fraction of legitimate users. Which group is larger, and which more valuable, are legitimate questions. But it's simply not realistic to argue that one such group simply doesn't exist. Happy‑melon22:46, 22 May 2010 (UTC)
It unquestionably is not a hassle for me to put in an existing email address in a registration form. Several keystrokes are not a hassle. Cost-benefit analysis favors requiring a verified email address. --Timeshifter (talk) 04:09, 23 May 2010 (UTC)
How'd you run that analysis, BTW? "I don't mind spending three minutes verifying an e-mail address (theoretically, because I've already got an account, so this new process won't apply to me); therefore, the entire world thinks this is the best use of their time"?
It's not merely a question of typing in an e-mail address. For this to work, the steps are:
Have (or create) an e-mail account (that you don't mind using for this purpose)
Create a Wikipedia account
Give Wikipedia your e-mail address
Wait for Wikipedia to send you an e-mail message
Log into your e-mail account to find the message
Read the message to figure out what you need to do (click a link in the message? copy and paste a verification code into a form?)
Follow the directions in the message (hope that it works, or wonder what to do if it doesn't.)
I can type an e-mail address in two seconds, but "put in an existing email address" is a noticeably incomplete description of the process. Since the vast majority of new editors are not sockmasters, it looks to me that the costs will be many minutes of legitimate users—not to mention loss of users that refuse to be hassled with this—to prevent each sock account registration. WhatamIdoing (talk) 05:02, 23 May 2010 (UTC)
I have had discussions with you, WhatamIdoing, on other talk pages, and I usually find it to be a waste of time. Please see my previous replies. I summarize: Enter existing email address. Receive confirmation email. Click confirmation link. The tiny minority of people who don't get it are not that important. Sockpuppets are important. --Timeshifter (talk) 14:25, 23 May 2010 (UTC)
But the "tiny minory of people" who don't get it is likely still larger then the number of sockpuppets being deterred by this. Personally I don't think any sockmaster will be deterred by this. This proposal will only make it a bit harder to create an account. Garion96(talk)15:31, 23 May 2010 (UTC)
Sockpuppets dumb down Wikipedia, and waste many editors' time. Also, do we really need the couple dozen people who can't figure out a confirmation link for verification? Cost-benefit analysis is the way here. --Timeshifter (talk) 16:15, 23 May 2010 (UTC)
Yes, we do need them. They are not too dumb to figure out a confirmation link, but for some it is just too much hassle. We shouldn't make it harder to create an account. And yes, cost-benefit analysis is indeed the way here. The cost is making it harder to create an account while the benefit is non-existent since I don't think any sockmaster will be deterred by this. Garion96(talk)16:31, 23 May 2010 (UTC)
Those few lazy people can keep on IP editing. The benefit is great even if only a few dozen or a few hundred of the 800 sockpuppets mentioned previously for one sockmaster are prevented. --Timeshifter (talk) 16:46, 23 May 2010 (UTC)
So you are asking me to began IP editing and lose access to Twinkle, HotCat, Huggle, Friendly, Rollback, hope of adminship, a watchlist and a userpage? Immunize (talk) 14:43, 28 May 2010 (UTC)
Although I am aware that oppose and support statements are not welcomed at this village pump, I have to at least suggest that this would decrease the number of both sockpuppets and productive editors. I feel that there is a certain appeal of wikipedia in that "you do not need to give out any personal information, not even an email address". If this passes, that will be lost, and I fear a drop in the number of new contributors. Immunize (talk) 14:50, 28 May 2010 (UTC)
To summarize various ideas. The registration form would ask for an email address. "Alias email addresses are fine." The link would be to a FAQ that would point out that one can maintain total anonymity this way. Even admins would not know the real name of the user. "The same email address can be used for multiple user names."
Multiple usernames could be listed at "Other usernames". That link would be in the sidebar of every user page. --Timeshifter (talk) 15:57, 23 May 2010 (UTC)
I have to agree with this suggestion. Anyone can still edit, they can edit as an IP without any registration at all, they can register with an email which remains hidden to all but C/U etc and lets face it an email addy isn't exactly personal information in the sense that we normally mean it. They can even use the same email for multiple accounts. If we can slow down sock creation its a win. Unomi (talk) 00:22, 3 June 2010 (UTC)
Yes, checkuser (C/U) would see the email address. For an alias email account if necessary for some editors (like me) who are anonymous. --Timeshifter (talk) 00:39, 4 June 2010 (UTC)
I S U P P O R T
It's a great idea! Sockpuppets and SPA are making me thinking to give up.. sorry for the bold capitals, I'm a little euphoric at the idea.. :)) --Theirrulez (talk) 21:28, 7 June 2010 (UTC)
Checkusers/oversighters have too much power?
The Wikipedia:Arbitration Committee/CheckUser and Oversight/May 2010 election only resulted in one candidate reaching the 70% threshold required to be elected. Could it be that the community essentially voted none of the above for a lot of the open slots because they view hardly anyone as being trustworthy enough to hold that much power? I wonder if there is a way to reduce their power without making the process too bureaucratic. The problem is that these functions, by their nature, don't lend themselves to much community oversight, so it's hard to even know whether the officeholders are doing a good job.
If there were a few people who could be trusted, they could be put in charge of hiring and firing assistants who would help with these tasks. I guess the proposals to put the ArbCom in charge of hiring/firing checkusers and oversighters are along those lines. Which raises the question, Can ArbCom be trusted? I was going to put forth ideas, but then realized I really have more questions than answers on this issue, and every idea I've thought of for fixing the process has its own fatal flaw. E.g., if you require the assent of more than one checkuser or oversighter in order to make a decision, then a cabal/voting bloc/whatever of mutually-supporting officeholders can still arise to defeat such a safety mechanism. Tisane (talk) 14:43, 6 June 2010 (UTC)
What power do Checkusers have? Maybe we need to encourage people to use pen-names when creating email addresses for use with Wikipedia accounts. Then we could give all arbitrators checkuser rights. If an arbitrator can't be trusted with checkuser access, then they shouldn't be arbitrators. We should require people to use a fake name and alias email address for Wikipedia user accounts. That would solve many problems. --Timeshifter (talk) 20:14, 6 June 2010 (UTC)
I agree it's a bad practice to use one's real name. Actually, I think it's better to give out as little personal information as possible. If you say that you have a certain political or religious leaning, for instance, then people may scrutinize your edits more for bias. Tisane (talk) 20:20, 6 June 2010 (UTC)
I try not to give out personal info that is too specific to me. But I give out some of my political and spiritual leanings on my user and talk pages. It helps people understand where I am coming from, and that I am conscious of some of my POVs.
I usually say something concerning unbalanced POVs (even ones I agree with) when it is brought up concerning parts of articles I have worked on. I try to be intellectually honest and fair. I don't just do this out of charity. I want my edits to be treated the same way by others.
When I point out some unbalanced POV that an editor has inserted, I want them to be intellectually honest too. Fair is fair. It is common-sense fair play. When I say "Unbalanced POV" I am referring to a POV being expressed in an article without the balance of other POVs. Wikipedia maintains a neutral point of view in the narrative voice of the article by expressing the various POVs in the form of X says Y.
[Languages] are now hidden behind a drop-down list.
Hi All
I wasn't sure which was the appropriate section to post in: perhaps someone would do me the honour of reposting where appropriate.
Visually it makes a lot of sense to tidy the languages away behind a drop-down menu, but it was always nice to see that metadata for context on a given article as it gives useful contextual info at a glance as to the international interest in a given subject. I also felt that it sat well with the international ethos of wikipedia to show this. Though i speak only a few languages, it can also be quite useful for navigation. I would guess that in say 2-5% of cases I cross-check other language versions of a page.
Even if this isn't for the masses, I would love it if wiki incorporated functionality to reconfigure options like this at the meta level, e.g. if my browser-saved keyword search contains a tag that expresses an option such as -->[Languages]="expanded" (i'm not a coder but you get the point), so that regardless of session cache / cookies etc, i have this feature.
Recently I was observing a several month edit war at an article, and it occurred to me especially on things like Move proposals being able to Observe the individual sections of the page would be highly useful. For example in My Raw Watchlist instead of having Talk:Neotribalism in there simply to be able to observe Talk:Neotribalism#Tribal society?. this would allow user to monitor one section rather than the whole page.
Another though i have been thinking about is being able to maintain more than one watchlist in single account like being able name one watchlist "Religion" and another "News orgs" so that my entire page does not end up being eaten up by a single Edit war... currently i operate a secondary account just to observe an edit wars
Thanks for the info, Tisane. I guess that is one of the reasons talk page section watchlisting hasn't been implemented also. "Some software enhancement proposals, such as a proposal to allow sections of articles to be watched via watchlist, have been rejected because the necessary schema changes would have required excessive Wikipedia downtime."
I don't think people would mind much if Wikipedia were down for a day if it allowed implementation of article and talk section watchlisting. Maybe incorporate integrated watchlists, too. Those 3 watchlist improvements have been requested by many people. --Timeshifter (talk) 20:08, 6 June 2010 (UTC)
Given that the vast majority of Wikipedia users probably have no idea what a watchlist is, I think they would mind. Mr.Z-man03:19, 9 June 2010 (UTC)
@Timeshifter: Don't worry, integrated watchlists are coming. Or, to be more precise, the code to implement them is being developed. I don't take it for granted that Wikimedia will install anything, though. Tisanetalk/stalk03:25, 9 June 2010 (UTC)
Wikix generated a sh. curl try to get http://upload.wikimedia.org/wikipedia/commons/0/00/Air\ composition\ pie\ chart.JPG in that sh. curl shows error 400 for all files. All files had /0/00/ prefix. I commented the md5() functions because g++ shows linker error: undefined reference to MD5. What have to be replaced in /0/00/? If you cannot solve the problem, Please propose another way to download wikipedia and commons images. Please plan to dump images again. We can satisfy if you at least dump images once or twice a year. All files had same problem. Only image00 is written and others had only env. variables.
Is there anything preventing dumps of the images from being done, by the way? It would be a good step forward for openness, and probably more efficient than the other methods of obtaining images (e.g. scraping). Tisane (talk) 18:24, 6 June 2010 (UTC)
I believe the main issue is size. Commons would be several TB, the English Wikipedia would be several hundred GB. I think there's some effort to split them up in some logical way, though the text dumps have more priority. There are also copyright issues with the English Wikipedia due to all the non-free images. Mr.Z-man03:24, 9 June 2010 (UTC)
I like openness of Wikipedia. Downloaders will take care of Copyright. Is there any links to contact the person responsible for dumps and a programmer of Wikipedia. —Preceding unsigned comment added by Rishikeshan (talk • contribs) 05:45, 13 June 2010 (UTC)
Pending Changes (nee Flagged Protection): update for June 10
We proceed boldly toward launch. The main update is that we have pushed the English Wikipedia launch back one day to Tuesday, June 15. That will let us avoid stepping on the WP Academy Israel event, and it means Jimmy Wales will be available to talk to the press, which in turn will yield a better public understanding of Pending Changes.
However, we will still be rolling the new FlaggedRevs code into production on Monday, June 14th (circa 4 pm Pacific, or 23:00 GMT). We hope that this, aside from some minor UI improvements, will pass unnoticed on the project currently using FlaggedRevs. If there are bugs, we look forward to hearing about them via the usual channels, including #wikimedia-tech. Minor bugs will be fixed in place; any major issues will result in a quick rollback to the existing code.
More prosaically, we had a number of bits of work verified complete this week, including a number of little bugs. Our thanks to the German community for their diligent testing of a labs instance of the German configuration.
If you'd like once last chance to see what's coming, try the latest code updates on our labs site.
To see the upcoming work, it's listed in our tracker, under Current and Backlog.
Currently, when one previews an edit, one sees the following reminder in bright red text at the top of the preview page:
"Remember that this is only a preview; your changes have not yet been saved!"
(Thank you, warning. On several occasions, you have prevented me from failing to save an edit.)
Unfortunately, I am sometimes absent-minded, so that occasionally, during a complex series of edits and previews and checking of links, after I've scrolled far down into a preview, I can forget having seen the warning.
My idea, then, is to strengthen the warning just a bit by making the whole preview page look slightly different from an ordinary encyclopedia page. (This is similar to some reminder techniques I use in database GUI design.) Thinking about the existing red warning message, I am imagining something pink or red that would be visible in any part of the preview page. Here are two possible techniques:
1) Add a thin red vertical line to the left edge of the preview page.
2) Make the entire background of the preview page pale pink.
Other kinds of visible reminders are possible, and might even be more practical to implement -- I don't know. The two key points are that the different appearance of the page should be rather noticeable, and that the difference should be visible from any scroll position.
I remember the confusion I has as a newbie. Good idea. I l[ke technique #2 because it is more noticeable, but the ultimate decision has to be the programmers. Rebele | Talk The only way to win the game is to not play the game. 06:38, 4 June 2010 (UTC)
I'd like to add my support for this. It's just good UI design, especially option 2. One caveat is that it would be necessary for the colour to be modifiable using vector.css or similar for accessability reasons (some people need to use particular coloured backgrounds due to visual problems). For the same reasons it would have to play nicely with custom background colours people may have set up in their browsers. Finally just to say that if this doesn't gain support as a default I imagine it should be possible to implement it as a UI gadget in preferences. Equisetum (talk) 12:05, 4 June 2010 (UTC)
I like this idea, especially a pale color (and as suggested, customizable). I was tripped up by this just yesterday, wondering why I had an error in a page that I was sure I had addressed, then to look at the other screen and realize it was still open, not yet saved.--SPhilbrickT15:47, 4 June 2010 (UTC)
I agree it would be good if there was a more in-your-face reminder you're still on a preview - your edits are not saved yet. Incidentally, this is extremely easy to achieve with a snippet of custom CSS. I have made the warning at the top of the page larger, with a thick red border, and the actual page with a pale background colour as suggested. Very clear, no missing that. Superp (talk) 22:55, 5 June 2010 (UTC)
Auto-saving drafts
A more comprehensive solution would be to auto-save article drafts similarly to what Gmail does; this would also protect against loss of unsaved revisions from power failures, computer crashes, and such. Tisane (talk) 23:18, 5 June 2010 (UTC)
I've separated this idea out into a subsection, because from the implementation perspective it is rather different from the other ideas here, even though it addresses a similar need. Feel free to revert me if you object to this separation. Equisetum (talk | email | contributions) 21:06, 8 June 2010 (UTC)
That's good for home computers; I'm not so sure about, e.g., university library computers and other locked-down systems that don't allow new software to be installed. Tisanetalk/stalk04:05, 17 June 2010 (UTC)
New approach to vandalism?
This has probably already been mentioned before but what do people think about utilising principles of deviance and social psychology in countering vandalism on Wikipedia? —Preceding unsigned comment added by Oxio-a (talk • contribs) 05:56, 7 June 2010 (UTC)
I propose a world-view tab on each page, giving the version of truth for that topic, from each of the existing world-views. Actually each page would have thus several personalities.
Editors would be divided into groups, based on their WV, and they could edit the pages under their own tab.
The world-views might be: Wikipedia's current WV(Polytheistic Evolutionary Pantheism), Pantheism (Hindu or similar), Muslim and Christian.
This would free us from the revisionists, and enable people to see the different explanations side by side. Instead of deleting people's accounts and entries, on the basis of religious bias, they could be directed to their particular tabbed page.
This is called "Diversity", and also "Freedom of Speech" or "universal suffrage".
The differences between WV's are easily established. Currently any world-view except Polytheistic Evolutionary Pantheism is deemed to be vandalistic by definition.
Nope, not going to happen, and you're obviously banging a drum here. WP:NPOV does allow for different viewpoints to be presented, but not advocated for. You'll be wanting Conservapedia (to write from a Christian Right POV) or Wikinfo (to write from a "Sympathetic POV"). Fences&Windows01:25, 17 June 2010 (UTC)
It's not great practice. We should have "Reception of..." sections and articles, not "Criticism of...", as editors assume "Criticism of..." means negative criticism. Anyway, if I'm not mistaken the OP is a Young-Earth Creationist who wants to write about the Biblical Flood as though it were fact, and that's a non-starter on Wikipedia. Fences&Windows16:27, 17 June 2010 (UTC)
Well I have wanted to have flags for the use of people who have various hangups so they can self-censor and protect themselves from, for instance, seeing naked people. I believe this would be useful in enabling WIkipedia to be used by more people. It could be perverted I suppose so creationists could protect themselves from statements based on science for example. I'm not sure that's an altogether bad thing if a box is shown that the can click on to show themselves what they are hiding from. Dmcq (talk) 18:14, 17 June 2010 (UTC)
It's a good idea, although a better way to implement it might be to have a Wikipedia mirror install something like mw:Extension:ImageFilter. That software needs some enhancement in order to be very practical; good luck getting the MediaWiki dev community to work on it though, since they're generally more interested in openness than in censorship, and in software that will run on Wikimedia projects than on software that won't. You may have to develop it yourself if you want it. Tisanetalk/stalk18:23, 17 June 2010 (UTC)
Modification to BLP -- exemptions for non-article spaces
Can you provide any diffs showing this happening? Or a hypothetical example case? -- Ϫ18:12, 19 June 2010 (UTC)
First of all, BLP is not (only) to protect Wikipedia, as the proposal states in its first sentence, its main purpose is to protect the subject. It's difficult to discuss a proposal when it's based on a faulty premise. But I can recall at least one instance where we have gotten a complaint about talk page content. Do people abuse BLP sometimes? Yes. But weakening the policy is not a solution. Mr.Z-man.sock (talk) 18:29, 20 June 2010 (UTC)
Yes, I can. Need I? Are you asserting that it is appropriate for policy and actual de facto practice to widely differ?
Yes you are partially correct that a secondary reason is to protect the subject. However, that is subsidiary to Wikipedia's primary purpose. Are you making the assertion that if I provide an edit to a BLP that is 1) accurate, 2) important info about a notable subject, 3) and supported by proper refs, but that is liable to hurt the feelings of the subject if he reads it, we should not include that info????
As to the assertion, that for example, to say (as noted in the proposal talk page) that saying (for instance) "That idiot, Jimmy Carter..." on a talk page, while not recommended for reasons of tone and other reasons, causes proximate harm to Mr. Carter... I would consider such an assertion to be ridiculous on its face. Are you making such an assertion?
Finally as to your statement: "Do people abuse BLP sometimes? Yes. But changing the policy is not a solution," All I can say is.... wow. Just... wow. Herostratus (talk) 01:11, 21 June 2010 (UTC)
Oh well. My main question was, should I send this page to RfC or let it be kicked around here in the idealab first? I think because it's formed and written it is ready to go to RfC, and I have done this. I hope this is correct. Herostratus (talk) 02:45, 21 June 2010 (UTC)
Where on earth did I say anything about hurting people's feelings? If its accurate and well sourced, then it can't really cause much actual harm. That's what I'm talking about. I'm sure you knew that though. But if you seriously think getting rid of the policy (or in this case, just getting rid of it in the area where people abuse it) is not only a good solution to people abusing it, but the only solution (because any suggestion otherwise is apparently met with sarcastic scorn), I don't really see why you even wanted a discussion. Mr.Z-man03:04, 21 June 2010 (UTC)
I'm sorry, I think you misunderstood me, I was not being sarcastic! You said "It's [BLP's] main purpose is to protect the subject." That is what I meant by protecting the feelings of the subject. In what way would "protect" be applied? That is what I meant, is all. Sorry, didn't mean to upset you. Herostratus (talk) 13:15, 21 June 2010 (UTC)
I was actually referring to the "All I can say is.... wow. Just... wow." comment. Is there another way that one can interpret that? I'm talking about protecting people from actual harm. The incident that I referred to earlier was about a talk page discussion where a few editors were discussing whether an author might have plagiarized something. They didn't have any actual sources, it was pure original research. It might hurt his feelings a little bit, but I think the subject was more concerned about the effect it could have on his career when he contacted us. Mr.Z-man03:54, 22 June 2010 (UTC)
"I'm a little bit concerned about how WP:BLP is sometimes being used as a hammer an talk pages etc." The context for this is that Herostratus is currently subject to an admin recall request for BLP issues in an AfD. Fences&Windows13:58, 23 June 2010 (UTC)
Deletion Safeguards
N.B. Please excuse my ignorance in this realm - I've been a user of Wikipedia for many years but have avoided getting involved in the internals until now. Go easy if I have made a faux pas.
There seems to be a recent trend that has caused increasing levels of distress in many of us: the number of articles that have been deleted as the result of a single user who believes the article to be unworthy of inclusion. Frequently, the person simply isn't aware of the importance of the article to a comparatively small number of people. As Wikipedia is global, "a comparatively small number" could mean many thousands of people. An bunch of editors in North America may not consider a stub article about an English version of an Indian foodstuff that is very popular in England worth keeping - but is that a valid reason to delete it? Likewise, an active editor from Canada may not appreciate the value of an article on an 18th century family of architects in northern France. But interested parties would disagree (if they knew how).
A simple solution to this problem would be to allow deleted articles to be reanimated by ordinary users providing they then argue their case appropriately on the articles talk page. A new form of "protected deletion" could be instigated where there was a general consensus view that the article was genuine crap. veghead (talk) 03:43, 21 June 2010 (UTC)
Importance is not a reason for inclusion or exclusion, notability is. You have to find references to it in newspapers journals or books. That's the only way Wikipedia has of measuring 'imporance', not the number of interested people which no one has measured. If you can find a survey saying lots of people are interested that would establish notability in itself! You can always contest a proposed deletion by removing the tag - it says so when such a tag is stuck on an article. Dmcq (talk) 11:39, 21 June 2010 (UTC)
You can also recruit people to contest a deletion by putting a notice about it on a relevant project page or closely related article talk page. See WP:Canvassing and beware of votestacking described there. Dmcq (talk) 12:17, 21 June 2010 (UTC)
Thanks for the feedback. My issue is really that unless one notices that the article is marked for deletion at the time, there's no way to revert it into existence again afterwards. But I see your point; if someone really felt the article was notable, they should find some references to prop it up in the first place. veghead (talk) 12:47, 21 June 2010 (UTC)
Talking to the deleting admin, going to WP:REFUND or seeking a deletion review are options. Only articles meeting the criteria for speedy deletion can be deleted by a single user. WP:PROD stays open a week and can be contested by anyone at any time, even after deletion. WP:AFD invites input from anyone and the closing admin considers consensus, so rarely does one user's whim decide AFD debates. Fences&Windows01:15, 23 June 2010 (UTC)
θiːˈɒdəlaɪt (if you can pronounce that, ignore this)
Can we supplement with the apparently exacting pronunciation alphabet with something that does not need automatic deciphering? A quick, simple approximation would be okay most of the time.
Maybe [~thE'-ahh-dO-lIt] would suffice? (Though, in that case, the capital 'I' and lower-case 'l' are impossible to tell apart.) —Preceding unsigned comment added by 67.236.210.187 (talk) 06:32, 7 June 2010 (UTC)
Oh my, I've thought about this one many, many times. That little pronunciation language we use, albeit technically and pedantically correct I'm sure, is pretty useless to what I'm guessing are about 99% of Wikipedia's readers. I'd be on board with either replacing it or perhaps supplementing it with a more widely recognizable phonetic spelling. Equazcion(talk) 06:35, 7 Jun 2010 (UTC)
So the heading seems to say that only people who don't know the IPA should read and respond here. Forget that. This is really an issue only because the IPA isn't widely taught in the United States; everybody else's dictionary uses it. Before trying to replace it with something most Americans can read, please see Wikipedia:Pronunciation respelling key—there's already an option. Ntsimp (talk) 18:53, 7 June 2010 (UTC)
I for one would be devastated if this went. IPA is the de facto international standard for phonetic transcription and includes many sounds not renderable in what appears to be some kind of pigeon-IPA. though native speakers may not be aware, each vowel in English alone has multiple length variations - not to mention the schwa which is not a letter but used by all of us in most sentences (often without express knowledge). Transcribing the world's languages is necessarily complex, and the IPA already does a great job of simplifying/codifying this. Perhaps the instigator could take 15 mins to brush up on the basics of IPA - it's not too hard and is IMHO very rewarding. —Preceding unsigned comment added by 81.106.108.180 (talk) 22:57, 7 June 2010 (UTC)
I can understand your idea, but I think that it would simply create problems of its own. By replacing a globally-understood pronunciation guide (which takes all of about an hour to learn to an adequate extent) with an arbitrary non-standardised system of capitals, punctuation and syllables it would make Wikipedia less global and more idiosyncratic. On an aesthetic point, it looks uglier and clunkier. I think the best way to clarify the pronunciation would be to provide a link to a sound file just after the IPA if it's a tricky word: no need to decipher anything, since the a human voice clip is only a click away. Brammers (talk/c) 09:53, 9 June 2010 (UTC)
A side note: the pronunciation of theodolite has the "o" sound found in "pod" and "dog", rather than an "ahh". Brammers (talk/c) 10:42, 9 June 2010 (UTC)
Ah, ok. Sorry, I'm a speaker of what can best be described as Received Pronunciation English. I think this illustrates the importance of using IPA, namely to provide a pronunciation guide that is accurate across the world (i.e. where the reader can readily read the IPA symbols as the correct diaphonic variants, regardless of accent). Brammers (talk/c) 16:58, 9 June 2010 (UTC)
Precisely demonstrating why IPA is a good idea - I would render the above as "thee-od-o-lite", which may or may not have been what you were thinking of when you wrote "[~thE'-ahh-dO-lIt]". The IPA is unambiguous and works across regional variations of pronunciation. OrangeDog (τ • ε) 20:00, 16 June 2010 (UTC)
Brammers+1. Surely there is some voice synthesizer software out there that we can enter the phonetic data into, and it will provide a sound file, which can be uploaded and linked from/to the article. Tisanetalk/stalk21:50, 16 June 2010 (UTC)
Resolved