Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

New ideas and proposals are discussed here. Before submitting:

• Check to see whether your proposal is already described at Perennial proposals.
• Proposed software changes that have gained consensus should be filed at Bugzilla.
• Proposed policy changes belong at Wikipedia:Village pump (policy).
• Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
• Proposed new wikis belong at meta:Proposals for new projects.

« Archives, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

Trans-wiki collaboration

First of all this may be more of a global Wikimedia issue, but I feel having a discussion here first would be more interesting and useful. Also, this post is, in a way, a means of getting some frustration off my chest. (Hopefully I won't bore you too much in the process)

I have an Wikipedia account since 2004, and have been an utterly satisfied user of the encyclopaedia for a long while now. Occasionally I do some edits, mostly fixing patent mistakes and reverting vandalism I happen to come across, but I never became a prolific editor. A couple weeks ago, however, I began to study programming following a particularly well written Wikibook, and I felt totally at ease with the Wikibook model (probably just because my brain is best suited to tasks more modular and self-contained than building the incredibly complex web of cross-linking articles Wikipedia is. But I digress) and began doing some serious copyediting of the book right away. I felt that I finally found my home in the Wikimedia projects, and so decided to look around to learn more about how Wikibooks worked.

My worries began when, on reading the RfD page of Wikibooks, I took issue with a particular book on physics, and decided, after checking some policies and deciding it was reasonable to do so, make an RfD against that book. You can read all the gory details on the RfD entry itself if you wish, but the issue which really concerns me is totally independent on whether that RfD will be accepted or not by the community. The problem is that at several points during the process it looked very appropriate to ask other Wikibookians with some knowledge of physics for their opinions, as it is done in a RfC around here. Unfortunately, it appears impossible to locate a single regularly active editor of any of the better Wikibooks on physics, or find a place where asking for comments on the RfD would be useful. In fact, many of the RfD discussions at Wikibooks, particularly those on "specialist" subjects like physics, get no input other than from the proponent and the (currently 12) admins (and, occasionally, from the main contributor of the book to which the RfD refers to).

A pertinent question at this point would be what Wikipedia has to do with my complaints. The answer is very simple. Wikipedia has millions of registered users, an useful RfC system, some functional Wikiprojects and lots of public recognition. Wikibooks has none of these things. The point I'm trying to make is that Wikipedia could use some, even a little bit, of its leverage and brain power to support its sibling projects. Maybe something like having smallish (10-20 people) rotating boards of contributors in the main areas of knowledge (natural sciences, humanities, computing...) dedicated to providing comments in discussions and working at improving books at Wikibooks (the members of the boards could well be permanent, but for practical reasons I guess a rotating cast of volunteers would work better). It wouldn't cost much to Wikipedia, but would help the smaller projects a lot. The way things are now, I am afraid most of the existing Wikibooks are condemned to remaining eternally as stubs, and I feel the Wikipedia community could do something about that situation.

Note that I didn't post this either at Meta or at Wikibooks, as I feel it would be more productive starting this discussion at Wikipedia. Hoping to read your opinions, whatever they are. And thanks for putting up with my lamentations. --Duplode (talk) 23:03, 6 May 2010 (UTC)

I doubt boards would get off the ground. But the basic idea of cross-pollination has merit. Maurreen (talk) 01:03, 7 May 2010 (UTC)

Encouraging cross-pollination seems worthwhile. Two ideas: find suitable wikiprojects on specific topics to try and link with; and create a Wikipedia Noticeboard specifically for transwiki coordination/collaboration. (There may already be something on Meta but that gets so much less traffic.) There's also Wikipedia:WikiProject Transwiki, which might perhaps be expanded. Rd232 ^talk 01:54, 7 May 2010 (UTC)

I'd like to see some Wikiprojects making an effort at cross-wiki collaboration. Wikiprojects are built to organize groups of people interested in working on a particular topic, and it would be great if some Wikiprojects were to take some off-Wikipedia content and consider improvement of it to be part of their mission. Wikibooks needs groups with knowledge of a particular topic, Wikinews could use people organizing news relevant to a field, there could be groups knowledgeable about a specific subject adding words relevant to that subject to Wiktionary. --Yair rand (talk) 01:57, 7 May 2010 (UTC)

Good to see positive responses... engaging Wikiprojects in the cross-pollination makes a lot more sense than my suggested implementation, as it uses an already existing infrastructure. Speaking of infrastructure, it is worthy to note the unified Wikimedia accounts we now have will prove incredibly useful for making it easier for collaborators. By the way, if this idea gets enough support to take off, how do you think it should be kickstarted - that is, finding the first few Wikiprojects willing to try out the system? By a global "call to arms" to recruit interested projects, or by several "private" talks with individual projects to spread the idea? --Duplode (talk) 23:22, 7 May 2010 (UTC)

I'm in favor of trying talks with individual projects, there could be problems with a global "call to arms". (Just thinking aloud now, I can think of a bunch of Wikiprojects that it would be amazing if they could collaborate with sister projects. Wikiproject Video Games or one of its sub-projects working on Wikinews, some of the descendent WikiProjects of WP:COMP working on Wikibooks, WP:MED helping on Wiktionary...) Maybe the Wikiprojects could develop local "branches" on sister projects, and everyone could work together. --Yair rand (talk) 21:21, 9 May 2010 (UTC)

Collaboration on content across projects is a good idea. Anything that can spread some of en.wikipedia's momentum to other projects is good. I'm less convinced about trying to collaborate on processes. When it comes to the behind the scenes stuff, even the smaller projects prefer to maintain their sovereignty. It could end up looking like a takeover - "We don't think your processes are running efficiently enough, so we're bringing in our own people to do it right." Mr.Z-man 15:52, 8 May 2010 (UTC)

"Collaboration on content across projects is a good idea. ... I'm less convinced about trying to collaborate on processes." I understand your point about not butting WP into other projects - but how do you distinguish between the two (content/process), and still have something that enhances collaboration, especially given the problem that en.wp has the most contributors? The best I can come up with is trying to create some equivalent "wikiproject" on the other project, and creating links between the two, maybe with some kind of regular communication. Would it be impossible to get a bot to help synchronise projects (not the entire wikiproject, probably, but a noticeboard subpage say)? That could help quite a bit. Rd232 ^talk 14:50, 9 May 2010 (UTC)

Its not that hard to separate them. If all you're doing is collaborating on content directly via projects, that's fine. But if you're trying to overhaul their deletion process or RFC process or even just flood them with wikipedia users to make them go faster or if you're going over there to set up some new bureaucracy, then it becomes a problem. Mr.Z-man 16:10, 11 May 2010 (UTC)

These concerns are legitimate, but I feel the usefulness of having a larger pool of contributors make it worthy to find ways to deal with any new convivence issues that might arise. Of course, the wikipedians "recruited" via Wikiprojects to work in, say, Wikibooks would make their collaborations as regular members of Wikibooks, and would have to follow Wikibooks policies and respect the community they are getting into. It would be no different to what should happen if, for instance, I convinced some friends at college to make an improvement drive on Wikibooks about some subject we're knowledgeable about - except that done in a potentially much larger scale. --Duplode (talk) 18:41, 11 May 2010 (UTC)

Sure, they would have to follow local policies, but there could also be enough of them in comparison to the number of regular Wikibooks users that they could get consensus to change the policies as well if they get in their way. What might be dealing with a convenience issue for us might look like a hostile takeover to people who have been on Wikibooks for months or years. I'm not saying we shouldn't collaborate with smaller projects, I'm just saying we need to be very careful not to make it look like we're seizing control from the regulars. Mr.Z-man 19:52, 11 May 2010 (UTC)

Precisely what I meant above by 'there could be problems with a global "call to arms"'. I think this would be best started off small-scale, with a few projects helping out off-Wikipedia, preferably divided over multiple sister projects. --Yair rand (talk) 21:18, 11 May 2010 (UTC)

Some sort of cross-wiki-WikiProject thing might be beneficial. There have been times on other projects where I've felt something was an issue, but there was no analog to a WikiProject I could go to and say "okay, I feel there's a problem in the domain of topic X, what do you all think?" For instance, I don't agree with the way the categories for roads/road sign photographs are set up on Commons. If this had happened on Wikipedia, I could consult with WP:USRD and work out a consensus, but it doesn't exist over there, so I couldn't go seek the input of people specifically knowledgeable about road photos. As a result, last time that I attempted to broach that topic, it ended up with two or three Commons categorizers shouting that I didn't understand Commons and me arguing that they didn't understand the reasons the photos had been taken in the first place, and thus their categorization scheme was silly. Very little got done. —Scott5114↗ [EXACT CHANGE ONLY] 06:15, 11 May 2010 (UTC)

You'll find that Wikibooks has a friendly small-town atmosphere, so don't worry about encountering the same situation. -- Adrignola (talk) 21:46, 11 May 2010 (UTC)

I think this is a very important proposal. Unfortunately, if we do this we will be fighting against the software because there are no cross-wiki watchlists. There is currently a strategy discussion here (you may have to log in there separately even if you have a global account), and on the talk page I have proposed adding cross-wiki collaboration as an explicit goal. Hans Adler 09:21, 11 May 2010 (UTC)

In the short term, a bot synchronising pages across projects could to some extent make up for not having cross-wiki watchlists, no? Rd232 ^talk 15:35, 11 May 2010 (UTC)

(Without breaking the flow of the current discussions: I just told people at Wikibooks about this thread. --Duplode (talk) 15:59, 11 May 2010 (UTC))

I think it's a really good idea. Cross-wiki watchlists would help, sure, but there's plenty of users who have coped without them across an admirable number of projects. I think that the most feasible way to do this would be, as suggested above, have individual wikiprojects run "outreaches" to other projects. This kind of thing is a start.

A way to get more traffic (both reading and editing) would be to include these projects in a separate section of the interwiki bar. Maybe not the way the languages are structured, but there nevertheless. It might even be as simple as one link to a page listing all the Wikimedia projects, or maybe more like this:

More about Foo
Books about Foo
Quotes by Foo
Current news related to Foo
Definition of Foo
Pictures of Foo
Opinions? {{Sonia|talk|simple}} 05:40, 12 May 2010 (UTC)

{{sisterlinks}} --Cybercobra (talk) 06:11, 12 May 2010 (UTC)

Oops. Yeah, like that, but defaulted into the left column for every article. {{Sonia|talk|simple}} 09:30, 12 May 2010 (UTC)

That would be nice if it could be part of every article. For what it is worth, I have made my attempt at to the math community here over at Wt:WPM. — Preceding unsigned comment added by Thenub314 (talk • contribs)

{{sisterlinks}} just isn't applicable on every article; fact of the matter is, enwiki's scope is far, far, far broader than any other projects', so cross-pollination (which I'm all for, as evidenced by my cross-wiki edits) isn't a simple "we need to get A talking to B". EVula // talk // ☯ // 16:48, 12 May 2010 (UTC)

How about adding some optional parameters to {{Talkheader}}, to generate notes at the bottom (just above the archive links, I suppose) that for contributions of type X1 (where X1 is, presumably, something that Wikipedia is not) consider Y1 (some specific thing on a sister project), for X2 consider Y2, etc.? It's technically simple to do, once we thrash out just what the wording ought to be; readily customizable for each article; and may actually catch the attention of more contributors than something left-column-ish or Wikiproject-ish. --Pi zero (talk) 18:56, 12 May 2010 (UTC)

re: to the comments above, I would probably lean towards Sonia's stance in that the key thing is getting potentially interested contributors involved (and thus Wikiprojects are important); and things like watchlists or how extra links to sister projects would be tailored to individual articles and subjects are mostly convenience issues. On the other hand, talkheader does looks like (another) great place to slip these links into. --Duplode (talk) 19:48, 12 May 2010 (UTC)

Anyone want to just go ahead and try to organize a cross-wiki collaboration effort on a Wikiproject? Seems like it's time for some actual action, hm? --Yair rand (talk) 03:08, 14 May 2010 (UTC)

I am attempting to at W:WPM, but there doesn't seem to be a lot of interest as of yet. But maybe I am going about it the wrong way... Thenub314 (talk) 11:47, 14 May 2010 (UTC)

That link goes to Words per minute, which I feel is not the intended destination. Can't find what is, to fix it. Rd232 ^talk 11:53, 14 May 2010 (UTC)

He meant to point us to Wikipedia_talk:WikiProject_Mathematics --Duplode (talk) 16:23, 14 May 2010 (UTC)

First: great anecdote, and collabs across Projects is a great idea.

Second: the easiest way to support a project may be to drive traffic to it, particularly editing traffic. This doesn't have to have any particular structure (such as the rotating boards).

One thing we could consider is setting up a more effective banner system to sharing project-related messages for editors -- so that editors would see notices of other projects related to their interests, or randomly selected notices about something cool going on across Wikimedialand.

Third, Yair is right :) Maybe one big WikiProject here devoted to collaboration and barnraisings across Projects would be enough, could have weekly or monthly drives, and could call on specific WikiProjects here for each of its efforts. –SJ+ 15:53, 17 May 2010 (UTC)

I just say that I wish to add my support, as many have, to the idea of trans-wiki collaboration - it makes sense to me. ACEOREVIVED (talk) 21:21, 21 May 2010 (UTC)

Integrated watchlists

The main reason Wikipedia editors don't edit much at Wikibooks, etc. is multiple watchlists.

Please see:

• Wikipedia:Integrated watchlists --Timeshifter (talk) 05:14, 17 May 2010 (UTC)

Hm, I don't really think that's accurate. Having separate watchlists might be a little inconvenient, and make it harder to keep up with things across projects, but I don't think that they're really causing people to not edit on multiple projects. --Yair rand (talk) 19:59, 18 May 2010 (UTC)

I also don't think that's accurate – in fact, I'm not sure why you'd want to watch pages from multiple projects on the same page. There are no main reasons why editors from one project don't often migrate to others, but I would say it's largely an issue of not being aware that they exist. It's also difficult to acclimate to a foreign project, where the rules and atmosphere are completely different. Juliancolton | ^Talk 23:04, 18 May 2010 (UTC)

Lack of an integrated, global watchlist is the main reason I have heard from people as to why they don't edit much on other wikis outside Wikipedia. The other reasons are also true, but much less used as reasons why people don't participate. Most registered editors on Wikipedia are aware of the other projects in my opinion. The other cultures on the other projects are a slight hindrance, but not a real reason why people don't participate in my opinion.

The Commons is the second most popular wiki in the Wikimedia universe, and its culture does not really hinder people. What hinders the Commons is the lack of a global watchlist. Many people start on the Commons, and then stop. Illustrating Wikipedia is so important that some people continue editing on the Commons in spite of having to use a separate watchlist. But others hate having to upload images to the Commons, and continue uploading to Wikipedia instead. If there were one watchlist there would be no essential difference, and many more people would upload directly to the Commons.

This user supports global, cross-wiki, integrated watchlists.

I personally prefer separate watchlists for Wikipedia and the Commons, because I do a lot of work on the Commons, and like to keep image work separate from Wikipedia work. But I would like to integrate all the other wikis with the Wikipedia watchlist. People could make their own choices about which watchlists to integrate and consolidate. --Timeshifter (talk) 13:07, 22 May 2010 (UTC)

This is really a technical issue, and integrated watchlists are probably not going to be available for a long time. We need to discuss more how we can get people to contribute on sister projects, even without more helpful software. --Yair rand (talk) 22:48, 25 May 2010 (UTC)

See related discussions:

• Wikipedia:Village pump (idea lab)#Why does Wikimedia need more than one MediaWiki installation?
• Wikipedia talk:Integrated watchlists --Timeshifter (talk) 15:39, 27 May 2010 (UTC)

Based on my own habits and those I've observed of others, I think TimeShifter is right. People will often, for instance, create a page at one of the non-Wikipedia projects, and then totally forget about it, even when people are posting comments to the talk page or making major changes or whatnot. If it doesn't show up on the watchlist at the project they're most involved in (which is usually Wikipedia), it's not really on their radar screen. Who has time to check a bunch of different watchlists frequently, and who has the inclination if one's involvement in the project is minor, and therefore there are not a lot of watched pages? Heck, if it weren't for unified login, I probably would check my watchlists on other projects even less frequently than I do now.

Having said all that, this is indeed a technical issue and someone just needs to bite the bullet and put the time in to figure out how to implement this, and then to implement it. That someone could very well end up being me, although the way things are going, I'm not sure that I'll end up taking an approach that Wikimedia will be amenable to, so someone else might have to come up with an alternative method that uses CentralAuth. Really, if people would put as much time into coding as they do into debating, we would have some pretty good software by now. (See m:Mediawikianism.) Tisane (talk) 21:04, 27 May 2010 (UTC)

If mw:LiquidThreads used the regular watchlist, then it could be used at WP:Village Pump (technical). Threads on an issue such as integrated watchlists wouldn't be duplicated numerous times, and then buried in the VP archives. Developers would be more inclined to participate. --Timeshifter (talk) 22:12, 27 May 2010 (UTC)

Well, it is a trivial matter to put a link to the pertinent VP archive in a centralized location, e.g., Wikipedia:Integrated watchlists, and thereby keep the content of those conversations from being forgotten. But devs tend to use Bugzilla; that way, they can subscribe to the Bugzilla listserv and/or to particular bugs that they have an interest in, and get an email whenever someone makes a comment.

I want to raise another issue about this proposal, which is that, by encouraging cross-wiki participation, integrated watchlists will likely increase homogenization across Wikimedia projects, as users bring the values and norms of their own preferred wikis to other wikis. I personally think that's a good thing; we could use some cross-pollination. But the downside is that, Wikipedia being the 400-kg gorilla of the group, the other wikis will probably tend to be pushed even more in the direction of Wikipedia-like standards. E.g., strict adherence to "reliable sourcing" and notability, etc. But I think it's unavoidable; really, our only alternatives are for those wikis to remain neglected, or for them to become homogenized/dominated by Wikipedia-like standards. I don't think that's a false dichotomy. Wikipedia really reflects the standards of the Wikimedia Foundation in purest form, and it seeks to ultimately make all of its projects conform to those standards. It just hasn't made it a high priority for those smaller wikis, because no one really cares about them all that much, since they don't show up much in the Google search results. Tisane (talk) 23:50, 27 May 2010 (UTC)

Er, I hope this doesn't sound incivil, but I completely disagree with everything you just said. Carry on. :) --Yair rand (talk) 01:36, 28 May 2010 (UTC)

Bugzilla is not that great. It does not use wikitext, and it can't be put on a watchlist. Same problem of lack of integration (format and watchlists). Also, email addresses are exposed (other logged-in users can see all the email addresses). The other wikiprojects were set up by the Wikimedia Foundation, and the main rules were created by the Wikimedia Foundation. So the homogenization can't be voted in by users. Integrated watchlists would gradually cause higher placement in Google results for the other wikis as they became more popular, and more and better content was created. I have websites and blogs, and have watched how Google results improve as particular pages become more popular. --Timeshifter (talk) 13:57, 28 May 2010 (UTC)

Yeah, Bugzilla has a lot of drawbacks, but it remains one of the main tools used by devs. It has a lot of other useful stuff too; e.g. bugs can easily be marked as duplicates of other bugs, resolved bugs are denoted as such by a strike like this, and it is in general less cumbersome to work with than MediaWiki. If you want the devs to code something, you pretty much have to put it on Bugzilla (as has been done with this proposal.) Probably a better approach would be to code a MediaWiki extension to provide the functionalities that Bugzilla offers, but that would probably be a major pain in the neck to code, and there's no guarantee it would be particularly well-integrated with the rest of MediaWiki; for instance, mw:Extension:CodeReview isn't integrated with watchlists either.

I think that as the other wikis start showing up higher in the search listings, Wikimedia and its editing community will become less slack about enforcing certain values, such as notability. Right now, for instance, Wikiquote has a notability essay and quotes can theoretically get removed for lack of notability, but it isn't enforced all that strictly. That will probably change when the project becomes more high-profile, much as Wikipedia became stricter as the project matured. Tisane (talk) 14:50, 28 May 2010 (UTC)

There are differences between Wikipedia and the other projects. Tutorials are accepted in Wikibooks and Wikiversity. Wikipedia does not allow tutorials. Some sections in a tutorial will not be notable, but are still necessary in order for the tutorial to teach people effectively. Also, reliable sourcing is different in Wikibooks and Wikiversity. Editors who know their subject can be the source for parts of tutorials. --Timeshifter (talk) 03:14, 29 May 2010 (UTC)

If your username is Example%%%%% and if you have edited at English Wikiversity, then you can leave a message at http://en.wikiversity.org/wiki/User_talk:Example%%%%%, inviting editors to leave a message at http://en.wikipedia.org/wiki/User_talk:Example%%%%%, which might say "You have a message at http://en.wikiversity.org/wiki/User_talk:Example%%%%%." -- Wavelength (talk) 03:12, 28 May 2010 (UTC)

Like Yair rand, I feel it is important to state my disagreement with Tisane's position. In particular, I will refer mostly to Wikibooks (the project I have more experience with), but the argument is extensible to the other projects as well. The main reason why we have a different project culture and editorial guidelines is because the activity of writing books is inherently different from writing an encyclopaedia, and the differences call for different practices. Otherwise there would be no reason for the existence of the sister projects, and everything would be done within Wikipedia. The viewpoint that we do not adhere to certain standards just because we have less visibility (and therefore nobody cares) is mere prejudice. If you abstract it from the current context (Wikimedia projects), the notion is analogous to the anthropological stance of seeing people from very different cultures as "primitive barbarians" that must be "civilized". Of course, some principles (reliable sourcing, maintenance of NPOV) are more or less universal, even if the extent of enforcement that the editorial needs of the project call for might vary. The key point is that each project has their own appropriate editorial guidelines, and the admins and contributors work hard trying to enforce them. Disregarding that is not only inaccurate but borderline disrespectful.

This argument lends support to a closely related observation Yair rand made earlier on the discussion: that the lack of cross-wiki cooperation is not just due to technical obstacles. There are cultural issues involved, and one of them is people not understanding the point of the smaller projects, falsely believing that all of the human knowledge can be feasibly covered by the encyclopaedia umbrella.

Finally, a corollary from the perspective of a Wikibookian. To me it seems that the general feeling at Wikibooks is that more contributors would do good to the project, and there is no significant fear that an influx of, say, Wikipedians could harm our project culture. Just as much as the values of newcomers could modify the project direction they also would necessarily adjust, to some extent, their views and behaviour, since our practices are coherent with the goals of the project (which are different from the goals of Wikipedia). --Duplode (talk) 20:33, 28 May 2010 (UTC)

P.S.: I noticed Tisane's proposal at Wikipedia:Village pump (idea lab)#Why does Wikimedia need more than one MediaWiki installation?. Just to keep things clear: unifying the underlying infrastructure is actually a very good idea. The argument I made on the paragraphs above doesn't apply to that proposal - it concerns content and editorial decisions, and not software infrastructure. --Duplode (talk) 20:42, 28 May 2010 (UTC)

Clarifying WP: shortcuts and Wikipedia: page titles

Currently, the Wikipedia: namespace contains all manner of help, guidance, policy, guideline, essay, supplementary essay, wikiprojects and other miscellaneous pages. Mostly this is not a problem (though it is untidy and contributes to confusion for newcomers), but it is at least occasionally a problem for confusing all but the most experienced of Wikipedians when it comes to referring to policies, guidelines, and essays - particularly in cryptic shortcut form - in discussion. Two related proposals to improve this situation (more ideas welcome):

1. Have a bot expand shortcuts on talkpages where wikilinked. So WP:NPOV becomes Wikipedia:Neutral point of view. Basically, decryptify shortcuts a bit.
2. Create a "Policies and guidelines" pseudospace and PG: pseudospace for relevant shortcuts, and move policies and guidelines there; and/or an "Essay" pseudospace and E: pseudospace, and move essays there. Create a U: pseudospace for shortcuts for userspace generally, but of particular relevance here to create appropriate shortcuts for userspace essays. Basically, make it clearer from the links what the target is.

Note that point 2. in prior discussion at WP:VPD was felt to possibly be an attempt to demote essays or discourage reference to them; far from it. It is simply to avoid creating confusion, and a sense which too often seems to arise that new users feel cheated "I thought that was a policy you were raising". Clarify that it's an essay, that it's a convenient encapsulation of a user's view in a particular situation, and communication should be enhanced and discussion should just work better. Another issue raised has been (more or less) that it doesn't matter if shortcuts are confusing; it's users' fault for not following the shortcuts whenever they're mentioned. To this I would say (a) not very helpful, or friendly to newcomers, who have to try and remember all this new alphabet soup and cryptic abbreviation; (b) even more experienced Wikipedians can get confused, and think they know what shortcut X means, but they're wrong; expanding shortcuts is just being helpful all round. Rd232 ^talk 00:08, 7 May 2010 (UTC)

Previous discussion: WP:Village pump (development)#Move all essays to userspace (e.g. User:Essay/Coatrack) or separate namespace (e.g. Essay:Coatrack). Flatscan (talk) 04:18, 8 May 2010 (UTC)

I think that this is more a problem with how the users link. I think people should not link shortcuts at all, especially as sole reasoningsin !votes. Rather than "Oppose WP:NPOV", I believe one should say "Oppose The article lacks a neutral point of view, a Wikipedia policy" or something of the sort to more justify their reasoning. The link and its status should be secondary, IMO. I know this would make it "easier" because people don't want to do that, but I don't think it would help anything. VerballyInsane 03:46, 7 May 2010 (UTC)

Well it's not going to make anything worse is it? It may or may not change behaviour for the better in terms of using links (I think it might), but it should certainly help other users who are reading the links follow things better. Especially new users. Please don't judge a proposal for not solving a related problem it doesn't seek to address - that's so annoying. Rd232 ^talk 04:09, 7 May 2010 (UTC)

I apologise. I thought that was what it was trying to address. VerballyInsane 14:35, 7 May 2010 (UTC)

I think that the essay "WTF? OMG! TMD TLA. ARG!" sums up my thoughts on this. It is not directly related, but I do not think that adding these namespaces would help unconfuse readers. The essay " What does per mean? also has a bit of information on what I think. Whenever you link to a page, whether it is policy, guideline, or essay, it is up to the person to go to it. It is also your responsibility to mention how it affects the specific situation. And for that matter, even if it is a policy, people should still feel free to refute it (or ignore all rules) if they think that it does not apply in this case. Please feel free to disagree with me. And if I'm judging "a proposal for not solving a related problem it doesn't seek to address," then I obviously missed what problem it was seeking to address and it was not on purpose. VerballyInsane 17:08, 7 May 2010 (UTC)

"Whenever you link to a page, whether it is policy, guideline, or essay, it is up to the person to go to it." - you realise that by this logic, we should ban seatbelts, on the grounds that it's up to drivers to drive sensibly? Bottom line, this is supposed to help communication. In a perfect world, it wouldn't be necessary. In a perfect world, people would communicate clearly - and probably avoid using shortcuts at all, using the full page title instead, and certainly fully explain the relevance in the context. Well we can't automatically explain, but we can automatically clarify the links. Why is this not helpful, in an imperfect world? Rd232 ^talk 21:34, 7 May 2010 (UTC)

I'm really confused as to what problem(s) this is supposed to solve. Sometimes shortcuts are mentioned the way that they are because that's the easiest way to do so; in an AfD where the nominating statement specifically states that the article lacks a neutral point of view, it's perfectly reasonable for follow-up statements to simply cite WP:NPOV. Hell, I find it kinda funny that you say "prior discussion at WP:VPD was felt" without spelling out the development village pump (which is far more obscure than your given example of "NPOV").
As for separate namespaces for policies and guidelines and another for essays... ugh, please, no. There's no point in it, and it's needless fragmentation. The Wikipedia: and WP: namespaces/pseudo-namespaces are for project-level pages, which guidelines, policies, and essays all are. If someone is incorrectly citing a user essay as a policy, that's a behavior issue that needs to be addressed, not a technical one. EVula // talk // ☯ // 04:31, 7 May 2010 (UTC)

It's not "kinda funny" that I didn't spell out WP:VPD - it was deliberate!! It was an illustration of how a bot expanding links can be helpful! Now you know how newbies feel all the time! Also, you're missing the point - it's not "incorrectly citing" which is the issue; this is rare. It's citing in an ambiguous way. This is common, because people often say "see WP:whatever", rather than "my opinion on this subject is encapsulated in the essay WP:whatever". I don't see the "fragmentation" argument - we have different namespaces for different purposes, this is just applying the same principle for a pretty clearly explained reason. Finally, "there's no point in it" is just plain rude. You may disagree with the point, but the point has been made. It contributes to slightly reducing the newbie-offputting alphabet soup effect. This effect has been cited often enough as a big reason why people find it hard to get seriously involved. Rd232 ^talk 21:34, 7 May 2010 (UTC)

Might be kind of neat if the tooltip of linked redirects displayed the target page title. Hover over these two links to see what I'm talking about: WP:NPOV · WP:NPOV.

More generally, people should simply ensure that they always link when using an initial abbreviation / initialism. And, if possible, spell out the initial instance. --MZMcBride (talk) 04:55, 7 May 2010 (UTC)

That (tooltips showing redirects) is one of my favorite features of popups. VerballyInsane 14:35, 7 May 2010 (UTC)

What about something like this: NPOV or V (code: {{User:Nmajdan/Test3|NPOV}}). It provides a tooltip and a link. Granted, the hard part would be the initial population of all shortcuts into the template, but this would allow editors to hover over the link and see what page/policy it is linking to.—NMajdan•talk 15:17, 7 May 2010 (UTC)

WP:POPUPS already does this, and it does help. But we're talking about helping make things clearer for new users who haven't found that; unregistered users who can't; or passersby who find the whole thing ludicrously impenetrable and are put off ever trying to edit. Remember them? Remember that getting new editors to replace those leaving is not an optional extra, but essential to the long-term survival of Wikipedia? We should constantly be striving to be friendlier and more welcoming, and I think these suggestions would be help. Rd232 ^talk 21:34, 7 May 2010 (UTC)

I usually use direct page links in my comments, varying between full page names and piped links (which show the actual link on mouse-over) displaying the common shortcuts or in running text. I use shortcuts when they redirect to specific sections, which are easily renamed, breaking direct links. I tend to avoid linking when a term has been linked nearby, e.g. in a comment that I am responding to. I think that the shortcuts will be used regardless of any discouragement (short of outright deletion and creation protection), and linking them allows inexperienced users to educate themselves and gain familiarity. Full page names are more readable, but they often contain jargon and are not substantially less opaque. Flatscan (talk) 04:18, 8 May 2010 (UTC)

Indeed they may contain jargon, but surely you can't disagree that even the most jargonistic of full titles conveys more information than a shortcut. The point about breaking section links is a more substantive issue. That would suggest taking the piped approach you mention - the bot leaving the shortcut for the link part, but providing the full title for the description part of the wikilink. Rd232 ^talk 17:30, 8 May 2010 (UTC)

While alphabet soup is a turnoff, full page names do not convey the pages' contents. I would be cautiously supportive of a bot that converted untargeted shortcuts to full name links without changing their original appearance. Flatscan (talk) 04:35, 10 May 2010 (UTC)

"without changing their original appearance" - doesn't that mean the shortcut wouldn't look any different? What do you mean? (And if you mean that, what's the purpose of that?) Rd232 ^talk 09:25, 10 May 2010 (UTC)

It would change the tooltip text only, making it available if the reader needs a quick hint. My opinion is that actively removing initialisms will make users less familiar and more confused if they come across unlinked/unconverted ones. Flatscan (talk) 04:09, 11 May 2010 (UTC)

I like the idea of an auto-tooltip when using WP: space a lot. It seems like the perfect solution. ♫ Melodia Chaconne ♫ (talk) 13:44, 11 May 2010 (UTC)

OK. Sort of like a mini-version of WP:POPUP which doesn't need installing, I suppose. Anyone have any idea how to do it? Rd232 ^talk 07:36, 12 May 2010 (UTC)

Bot possibility:

1. Identify shortcut links, generally of the form [[WP:SHORTCUT]].
2. Verify that it is an untargeted redirect.
3. Replace with a direct link to the target, using a piped link to maintain its appearance.

A slightly smarter bot could parse signature timestamps and use historical revisions to find the target at the time of comment. Flatscan (talk) 04:20, 16 May 2010 (UTC)

Note: There is currently a bot request (DASHBot 13) to automatically tag such redirects with {{r from short}}. All community input would be greatly appreciated. Tim1357 ^talk 22:17, 21 May 2010 (UTC)

Rather than a PG (Policy and Guidelines) namespace, it would be better to have separate P and G namespaces, since policies are of higher authority than guidelines. Tisane (talk) 14:54, 28 May 2010 (UTC)

No they're not; any of these pages can have rubbish written on it, and in my experience nearly all of them do. Certainly the tag at the top of the page doesn't magically cause it to be more authoritatively edited.--Kotniski (talk) 15:02, 28 May 2010 (UTC)

Proposal: Switch back to the old skin as default

This vanishing topic was moved to Wikipedia:Requests for comment/May 2010 skin change/VPR.

WMF paid for this?

This vanishing topic was moved to Wikipedia:Requests for comment/May 2010 skin change/VPR.

Adding dates to assessment templates

(I originally raised this at Wikipedia talk:WikiProject Council where it received no comment) I've been taking part in an assessment drive, and coming across a number of articles which range from stub in one project's assessment to B-class in another's. The most likely reason for this is that the article has been expanded considerably since assessed as a stub.

This gave rise to the idea of adding an assessment date parameter to each Wikiproject template, and having the assessment date displayed with the quality class. (It is currently possible for a user to discover the assessment date, but only by trawling back through the history of the talk page). In future, the date parameter could also be used by bots to compile lists of pages last assessed, say, 3 years ago, which could be a basis for reassessing. dramatic (talk) 19:45, 14 May 2010 (UTC)

I can see problems of the parameter not been completed or updated when the rating is changed. If this could be done, somehow, automatically when the page was saved then it would be useful to be able to see when each of the ratings was made. The idea of producing lists of article potentially in need of re-rating is also appealing. Keith D (talk) 20:25, 14 May 2010 (UTC)

A bot might work as well, though Keith's suggestion would be the ideal. I'm in general support for this otherwise. It might be wise to bring up this discussion on Template talk:WPBannerMeta. --Izno (talk) 05:31, 15 May 2010 (UTC)

WP 1.0 bot already maintains assessment logs for each WikiProject. If that data would be computer-readable, it would be easy to create a tool that e.g. lists assessments that weren't changed the longest time. I asked about it on the bot's talk page. Svick (talk) 16:16, 15 May 2010 (UTC)

If you look at a table like this one, the dates are all listed, and should be computer-readable. The old bot used to produce a sortable table; the new bot is much better, but I see that you can't sort in order of assessment date. If that is a useful option, mention it on the bot's talk page and I'm sure User:CBM can do that. Walkerma (talk) 04:14, 17 May 2010 (UTC)

This could be accomplished by running queries directly on the bot's database in the Toolserver. Titoxd^{(?!? - cool stuff)} 02:56, 18 May 2010 (UTC)

I have no objection to charing the bot's data either by giving access to the toolserver tables or by writing an API to do it. However, in this case it looks like just adding another sort order would be better. I would be happy to have more devs for the WP 1.0 bot :) — Carl (CBM · talk) 03:15, 18 May 2010 (UTC)

I think that the issue is that some people want to place the assessment dates on article talk pages; as such it would probably be simpler (and faster, and overall less painful for the Toolserver) for SELECTs on the db... Titoxd^{(?!? - cool stuff)} 05:56, 18 May 2010 (UTC)

In that case, the technical issues for getting access to the bot's database are no problem. I would have some other concerns about adding the dates to the talk pages, though:

1. It's a lot of pages (over 2 million). Maybe this could be reduced by only worrying about pages marked "C" or higher; that would drop the count to under 150k. It seems excessive to edit a million pages for this.

   That kind of defeats the idea of being able to check on discrepancies in class (Today I found an article which ranged from stub to B across 3 different projects). Is it possible to create a link which retrieves assessment dates "on demand" for a given article? dramatic (talk) 00:07, 24 May 2010 (UTC)

   Sure, just enter the article name into the tool and leaver project name blank (example). Svick (talk) 12:03, 24 May 2010 (UTC)

2. Occasionally something happens that breaks the dates. For example, a small error in the WPBannerMeta template could cause all the category dates to reset, and random maintenance could accidentally reset the date as well. This is a pain to deal with robustly; since the dates are treated only informationally in the bot, I don't worry about it too much. Mediawiki does not keep a log of category membership, which complicates error recovery.

— Carl (CBM · talk) 12:40, 18 May 2010 (UTC)

Suggestion to have a "Possible Renames" feature in Wikipedia

Perhaps there is already an "Article Names for discussion" in Wikipedia,butI have not found it yet. If there is not one, then to have one would be an extremely useful feature. There are articles that have got renamed (such as the one called Inaccuracies in The Da Vinci Code, which used to be Criticisms of the Da Vinci Code) and such renaming is almost certainly going to lead to some people declaring that the older name was better. However - I know I must be mad to be concerned about such a trivial, facetious article - there was one article which really prompted me to make this suggestion.

It is the article Wikipedia: Editcountitis. Yes, perhaps I should not be overly concerned about what is really a joke article, but I still object to this article being called "Editcountitis" as "itis" means "inflammation" and so its title is giving a bad name. I have actually raised my objections to the article's name on the talk page of the article (go to Wikipedia: Editcountitis and then go the talk page, where you will see that I am not the only one to have done so, and you will also see I have made suggestions for other names). So, my proposal is to have a "Article Names up for Discussion" feature on Wikipedia, where, if sufficient discussion declares it, an article will be given a new name. ACEOREVIVED (talk) 20:32, 17 May 2010 (UTC)

Please see Wikipedia:Requested moves. The name might not seem intuitive at first glance, if you don't know that the way we retitle (most) articles and pages is by moving them to a new title. They are "moves", because we are not just retitling the page, but moving the page's entire history to the new name.--Fuhghettaboutit (talk) 21:36, 17 May 2010 (UTC)

Thank you Fuhghettaboutit - that seems the type of thing I had in mind, so that answers my proposal. Many thanks again, ACEOREVIVED (talk) 23:27, 17 May 2010 (UTC)

You're welcome.--Fuhghettaboutit (talk) 23:56, 18 May 2010 (UTC)

"itis" may mean "inflammation", but it's still a common suffix that people apply to random words to come up with a new "disease". (see Senioritis, where it specifically says "...in colloquial speech is assumed to mean an illness") The talk page has a whopping three people mentioning it, spread out over four years; that's not a particularly strong sign that it needs to be updated. Sorry, but it'll probably keep the name. EVula // talk // ☯ // 22:04, 17 May 2010 (UTC)

Thank you - and funnily enough, shortly after making this point, I heard people on BBC Radio Four using the term "commisionitis"! ACEOREVIVED (talk) 19:04, 25 May 2010 (UTC)

Proposed essay, discussion period

Some discussion periods are enshrined in custom or by instructions. RFAs last 7 days. So do AFDs. For talk pages, there is none. Some, like the Timor Leste page lasts 3 years and is on going. We never want to cheat the system by closing up discussion. Sometimes discussions get closed on ANI fast. I am interested in writing an essay about article discussions, not ANI discussions.

I was going to suggest that on-going discussions should continue until a clear consensus is reached. If not, the discussion should continue for up to one year. Even if there is a clear consensus, things should be kept open for at least 14-30 days. Too short and results could get skewed. This would preclude the 3 year wait in Timor Leste. Wikipedia is editable so discussion may be eventually re-opened. My essay would propose that discussion, barring a good reason, should not be immediately reopened because that might be looked at as edit warring. Perhaps a 6 week break would be sufficient. I might propose a term "preliminary consensus" or "provisional consensus" so that old decisions would not be cited with the force of law because that might stifle future discussion.

Essays do not require discussion. However, I do want to write an essay with some input from others. Thank you. Suomi Finland 2009 (talk) 18:16, 20 May 2010 (UTC)

Sounds like instruction creep. RfCs are the solution to stale or intractable talk page discussions, and last 30 days. Fences&Windows 16:45, 21 May 2010 (UTC)

So I presume that 30 days is the consensus standard for deciding a consensus except in specific instances, like AFD and RFA. Suomi Finland 2009 (talk) 19:37, 22 May 2010 (UTC)

Consensus is usually decided much quicker than 30 days, usually when the discussion peters to a halt, and it usually doesn't need formally closing. What has taken three years on Talk:East Timor? Oh, the name. How unsurprising, these sorts of debates are always intractable. To get a final consensus, post comments at relevant WikiProjects and policy and guidelines pages, e.g. Wikipedia:Naming conventions (geographic names) and open an RfC. Fences&Windows 22:55, 22 May 2010 (UTC)

This is reasonable. So the consensus is that consensus can be declared sooner than 30 days if discussion halts. Another good suggestion is that intractable discussions should be considered for RfC and/or wikiprojects. Suomi Finland 2009 (talk) 16:53, 23 May 2010 (UTC)

WP:Closing discussions might be of interest. Equazcion ^(talk) 18:01, 23 May 2010 (UTC)

WP:Usurpation

Currently, if a user who has made no edits and who's username is about to be taken does not object in 7 days to the usurpation, then the usurpation occurs. I feel that this should be extended to 14 days, to ensure that the user has sufficient time to become aware of the matter and object to it (if they want/need to). Immunize (talk) 23:17, 20 May 2010 (UTC)

I'd oppose that. The fact that they need to have made no significant contributions is an important part of justifying only waiting 7 days. No one who has really used the name significantly is in danger of being usurped, so I don't see the problem. You shouldn't be able to "reserve" a name just by registering it and then not doing anything with it. Equazcion ^(talk) 23:20, 20 May 2010 (UTC)

Although I understand you point of view, I feel that, given that this action is irreversible, it would be reasonable to give users at least 7 more days. Immunize (talk) 23:50, 20 May 2010 (UTC)

I wonder, is it possible (for someone) to see if a user has logged in, and when? ♫ Melodia Chaconne ♫ (talk) 00:09, 21 May 2010 (UTC)

I think Checkusers can, am I right? (And as an aside, since I usurped this account I've been regularly receiving password reset requests from a variety of IPs.) {{Sonia|talk|simple}} 07:25, 21 May 2010 (UTC)

2 questions:

• What if the editor who's username is about to be taken is preoccupied with RL at the time. I'd suggest a month. --Philcha (talk)
• What if it's a universal login username? --Philcha (talk) 19:25, 23 May 2010 (UTC)

• Again, the "no significant contributions" usually takes care of this, but if the account was recently created I think the 'crats also decline to grant the name.
• The 'crats will typically decline in this instance to prevent SUL collisions. –xeno^talk 17:26, 25 May 2010 (UTC)

• Unnecessary - the vast majority of usurp requests go uncontested. This really ought be discussed at WT:USURP, in any case. –xeno^talk 17:26, 25 May 2010 (UTC)

Agreed. Extending the wait time to 14 days just makes the long-time editor have to wait longer to receive his/her new usurped username. Because they aren't active, it is highly unlikely that they will return to Wikipedia anytime soon, and so this shouldn't really be an issue. —MC10 (T•C•GB•L) 17:18, 31 May 2010 (UTC)

Mark the entire contents of Category:Wikipedia_proposals and it sub cats as failed

There appears to be a large number of failed or stale proposals in Category:Wikipedia_proposals . Would there be an issue if I used AWB to mark these as {{failed}} with no restriction on active proposal being re-added Gnevin (talk) 08:38, 21 May 2010 (UTC)

Be careful, some may really be essays rather than active proposals so don't really need that pejorative label plastered on them. I think you should do this manually on a case-by-case basis instead of trying to automate it. Fences&Windows 16:41, 21 May 2010 (UTC)

Well maybe mark them all as Essay so. If still think it's an active proposal they can RV without objection Gnevin (talk) 16:42, 22 May 2010 (UTC)

I think that the reverse applies too: proposals which were clearly rejected should be marked as such rather than identified as essays. -- Black Falcon ^(talk) 19:47, 22 May 2010 (UTC)

Well there are hundreds of pages here and I ain't volunteering to read them all. So if we can't agree to a template to use then I guess nothing will happen Gnevin (talk) 23:35, 22 May 2010 (UTC)

Any suggestions as what to do here currently there are over 300 proposals listed there Gnevin (talk) 21:16, 24 May 2010 (UTC)

No suggestions, but I too would advise restraint on auto-tagging everything as "failed", and just letting the watchlisters sort out any problems. That's not really solving anything, except emptying out a slightly large category tree.

If someone did want to put the effort into reading them all (and their associated contrib-histories and talkpages), then updating the pages with a mix of {{Essay}}, {{Draft proposal}}, {{Failed}}, {{Historical}}, and {{Promote}}, would be the ideal mission. -- Quiddity (talk) 03:55, 25 May 2010 (UTC)

Or, if there are 2, 5 or 6 pages proposing the same thing from different angles, it may be a good idea to merge them into a single page MBelgrano (talk) 11:38, 31 May 2010 (UTC)

Forums

I was checking over Talk:0.999.../Arguments and found this. One of the comments there was "Wikipedia is not a forum" or something. Now, as an experienced wikian from some of the other wikis, i noticed some of the other wikis have forums. So I propose we make a forum for Wikipedia, so people can discuss stuff there, instead of littering the talk pages with statements that don't improve the wiki (like writing on the Google article: "I think so that Yahoo is better than Google and that we should delete this" or something). Sixeightyseventyone (talk) 02:14, 22 May 2010 (UTC)

If I may fill in the traditional argument against this sort of proposal, it is that Wikipedia/Wikimedia is not in the business of hosting forums, which have their own problems and complications. There are loads of forums out there on the internet, if users want to rant and rave about things, they can do it there. - Jarry1250 ^{[Humorous? Discuss.]} 13:57, 25 May 2010 (UTC)

Advanced search

I suggest an advanced search form, e.g. like Google's advanced search, with boolean operators, "exact phrase" and separate textboxes for intitle:, prefix: and incategory: Iceblock (talk) 17:48, 24 May 2010 (UTC)

A-class articles

Who thinks we should get rid of the "A-class" category from the quality scale? It seems to me that it is just confusing to have the ratings going C-B-GA-A-FA, especially as the A-class articles are internally assessed. Anyone? Gregcaletta (talk) 10:57, 25 May 2010 (UTC)

Yes, it is very confusing. I assumed that being a GA was a requirement for an article to be assessed as A-class by a WikiProject, but it turns out I was wrong. I understand that the scale isn't intended to be linear (e.g., if I understand correctly, a start-class article has insufficient comprehensiveness and a C-class article has insufficient quality, but neither level is necessary above the other); but I don't see the point of the GA-A-FA thing. A. di M. (talk) 11:43, 25 May 2010 (UTC)

OTOH it would make sense if the order was A-GA-FA, IMO. A. di M. (talk) 11:46, 25 May 2010 (UTC)

If you put in stub it looks like a game of hopscotch getting to FA :) Dmcq (talk) 12:36, 25 May 2010 (UTC)

... except that none of those steps are necessary to get to FA; you can take any article straight to FAC. Some of the classifications are clearly fairly pointless anyway, although I doubt there would be much consensus on which they were. Malleus Fatuorum 12:42, 25 May 2010 (UTC)

I've always treated A class as having been obsoleted by GA. A class is a project ranking that I rarely see used, GA is a "Wikipedia" one - i.e.: an independent reviewer is making the call on the rank. IMO, the two should be swapped on the assessment scale. Resolute 13:49, 25 May 2010 (UTC)

Some projects use A class, where (and I'm sure we'll hear from say, a MILHISTer) they are of use. For the other projects, they do no harm and can safely be ignored. Does getting rid of them accomplish anything then? - Jarry1250 ^{[Humorous? Discuss.]} 13:52, 25 May 2010 (UTC)

It gets rid of inconsistency, which is surely a good thing. There's no reason why project members shouldn't review each other's articles at GAN or FAC, so long as it's done openly and honestly. What does the infrequently used A-class add to that? Despite the recurring meme, although GAs are passed by one reviewer, they can just as easily be delisted by another. I've delisted well over a hundred. Malleus Fatuorum 22:55, 25 May 2010 (UTC)

Yeah, I'd say the main benefit would be that it is just simpler and clearer. It also kind of makes sense that articles above B-class should be externally moderated. It doesn't make much sense to have externally moderated "Good articles" and then to have an internally moderated class above that level. Of course, it is really for individual projects to decide if they want to get rid of that process. It's just a bit messy, frustrating for guys like me who aren't members of a particular project but would like to see the change made across the board, and confusing for novice editors or non-editors who nonetheless are trying to determine the quality of an article. Gregcaletta (talk) 01:14, 26 May 2010 (UTC)

I didn't even know there was an "A-class" — it's completely obsoleted by GA, in my opinion. Carrite (talk) 17:13, 26 May 2010 (UTC)

As Jarry pointed out, WP:MILHIST uses them extensively: there are 252 of them at the moment. That other projects don't use a formal A-class review system isn't a reason to trash the A-class system as a whole. At least at MILHIST, A-class standards are much closer to FA than GA. So from that perspective, to say that GA has made A obsolete strikes me as rather odd.

To answer Malleus's question about what A-class adds, I've found them to be quite useful in preparing an article for FAC. I can't find it now, but MBK004 crunched the numbers and determined that articles that successfully passed a MILHIST ACR stood a much greater chance of also passing FAC. And while you might argue that the peer review can adequately cover this function, I've found that they generally draw much less input. Take, for example, this PR I filed on 11 May; it's only had 1 reviewer so far. Meanwhile, this ACR, which I filed 13 minutes later, has since been closed as successful after 4 reviewers participated. Parsecboy (talk) 19:28, 26 May 2010 (UTC)

MILHIST's A class is considerably more rigorous than GA, and is highly regarded by those familiar with the project. The fact that it happens "internally" is actually significant: those familiar with MILHIST expectations/standards/MOS and general milhist knowledge offer a much better critique and judgement than most "external" assessors. As a step to FA, it is invaluable; for those not wanting to progress to FA, it offers much satisfaction as a mark of excellence/achievement, and guides readers to excellent articles. There is no point scrapping A class until GA standards meet the same bar. Gwinva (talk) 22:37, 26 May 2010 (UTC)

I wouldn't necesarily agree with you about MILHIST's A-class reviews, although I suppose it depends on what you call "rigorous" . I've seen several at FAC that were little more than plagiarised copies of old public domain documents. Malleus Fatuorum 23:20, 26 May 2010 (UTC)

If you're referring to those WWII transports that had significant copies from DANFS, those went through a couple of years ago, when standards were more lax than they are now (remember that they passed FAC at the time as well, so it wasn't just MILHIST dropping the ball). Parsecboy (talk) 00:02, 27 May 2010 (UTC)

Put simply the fact of the matter is that the A-class review system and the GA-class review system full fill the same general purpose: to provide projects a measure of where their articles lie in relation to the 1.0 assessment scale. From this angle therefore the whole debate over the GA and A-class as they relate to wikipedia are mute: offer both and see what the project members think. MILHIST uses A-class for a number of reasons, not the least of which is the fact that we have the man power to run such a department. Simply because our project has mastered the art of A-class while the rest of the projects haven't is no reason to penalize us. Moreover, GA and A-class both serve as stepping stones up the higher assessment chart. Lets stop having this discussion and simple work on the articles in question, that helps all project's articles move forward, does it not? TomStar81 (Talk) 01:58, 27 May 2010 (UTC)

It should be kept, as illustrated by WPMILHIST, it can and is used in a proper manner. The fact that other WPPs are not using it is not an issue, some projects don't use C-class either, are you also proposing to get rid of that? 76.66.193.224 (talk) 04:48, 27 May 2010 (UTC)

Analysis of the results of the WPMILHIST A class process conducted by MBK004 which is available here found that articles within the project's scope which had passed an A class review were much more likely to pass a FAC than those which hadn't gone through the A class process. To my mind that's reason enough to keep A class and other projects should be encouraged to conduct reviews. On a personal level, I've developed and nominated quite a few articles for A class status and can attest that the process works really well and adds a lot of value. Nick-D (talk) 08:38, 27 May 2010 (UTC)

(edit conflict) Full discussion and results are here on the MILHIST coordinator's talk page. -MBK₀₀₄ 09:19, 27 May 2010 (UTC)

I think a lot of editors have lost sight of the fact that article assessment, be it it A-class or GA/FA, is simply a tool: it is not an end in itself! A-class is a different tool from GA or FA. There's no problem with that, nobody is forcing anyone to write A-class articles and there is a great deal of useful work that can be done on the encyclopedia without even considering article assessment. But to go from there to say that editors should not be allowed to use the tool of A-class is just silly: many editors find it useful, if only occasionally, and for that reason alone they should be allowed to continue using it. Physchim62 (talk) 09:18, 27 May 2010 (UTC)

At WP:MED we do not use the A class system. It do not think it adds anything other than further bureaucracy and would have no problems with it being rescinded. But agree that this should be decided on a WP basis.Doc James (talk · contribs · email) 05:25, 29 May 2010 (UTC)

Proposal: Semi-protect articles of newly deceased people for 24 hours following knowledge of their death.

Yesterday, Paul Gray died. Following this knowledge, the page was vandalized a minimum of three hundred and twenty five times. The page was such a mess Cluebot couldn't revert it properly. When Ronnie James Dio died, the exact same thing happened. Dead famous people are, to put it bluntly, an asshole magnet. Now, given the sheer amount of vandalism to the Paul Gray article, it was clearly a coordinated attack, but much the same thing happened to the Dio article and that time it didn't seem to be. Locking the doors for 24 hours might help stem the 'tardtide, as this sort of thing tends to happen right after the information becomes public.

I realize this falls under 'pre-emptive protection' but this is the second time I've seen it happen, so perhaps this could be considered an ignore all rules situation. HalfShadow 16:52, 25 May 2010 (UTC)

It seems appropriate to semiprotect an article about a newly deceased person quickly if vandalism becomes a problem. We need to be sensitive to the fact that a bio article will get lots of views when the death is in the news, and many of the vandal edits on the Paul Gray article would be quite hurtful to friends or fans. It might be an overreaction to have a policy or guideline that all bio articles are semiprotected when the person dies, but there is no reason to leave the article unprotected when several idiots are vandalizing it. If I found that while I was posting a warning on the page of vandal #1, he and 2 others have re-vandalized, I would go ahead and semiprotect, since it would be impossible to keep up, and it would be hard to sort out useful edits from garbage. New or IP editors could propose edits on the talk page during the day or two of semiprotection. (edited)Edison (talk) 17:00, 25 May 2010 (UTC)

I think this is a great case for the "use common sense" clause of WP:IAR. There are some situations where the article should be protected upon announcement of the person's death. I'm thinking of Michael Jackson specifically, where the article was, if I recall correctly, protected before it stated that he was dead, because of the amount of rumours, untruths, and unverified statements flying around. I don't think it's necessary in every case—and for some lesser-known people, having the article open for editing after their deaths will improve the article. However, when it's clear the anonymous editors are doing more harm than good, and the harm is coming in quickly or in great quantity, then yes, the article should be protected. —C.Fred (talk) 17:02, 25 May 2010 (UTC)

I would support this proposal. Bios of the recently deceased are prime targets for vandalism, particularly in the case of those like Michael Jackson that are very famou and subject to some rather nasty rumours/vandalism. I see no harm in semi-protecting these pages after the death for a day or so. TomBeasley (talk) 21:10, 25 May 2010 (UTC)

I'm afraid I have to oppose any such blanket proposal. Most reported deaths of article subjects aren't a problem. A few, like Paul Gray, are ridiculous problems. It's better to just let administrators feel free to semiprotect such articles if there's a real problem (the Paul Gray vandalism, possible hoaxes, etc.) and not mandate that they must. However, I am all for defending individual decisions to use semiprotection in these circumstances; if this causes a brief delay in IP edits, that's not as big a problem as getting things wrong would be. — Gavia immer (talk) 21:53, 25 May 2010 (UTC)

• I don't think this is needed "as a rule", but I think that editors should feel free to report articles on the recently departed that are being vandalized to WP:RFPP swiftly. –xeno^talk 22:02, 25 May 2010 (UTC)

Last year, following the death of Kosuke Koyama in March 2009, I did suggest that just how there is a tag for biographies of living people, there should be a tag for the recently deceased. However, the proposal was not carried. There are definite problems here, we should be careful (after all, what would the friends and family of a recently deceased person think about the article in Wikipedia?) Yes, we do need to be careful, but a mere 24 hours of semi-protection seems quite a modest proposal to me - perhaps we should just say that we should keep a watchful eye on people for a week after they have passed away. I can, however, really understand the proposal, and this is certainly a sensitive, intelligently argued proposal. ACEOREVIVED (talk) 23:02, 25 May 2010 (UTC)

A good argument against this proposal for automatically semiprotecting is the article on Art Linkletter, former TV personality and commercial pitchman who passed away today. So far, 6 different IP editors have added the fact that he died and have made 9 appropriate edits which updated and improved the article (not to say vandals or wanna-be humorists won't jump in at some point in the future). Such proper edits are a good way for IP or new editors to get their feet wet in editing Wikipedia. Edison (talk) 19:34, 26 May 2010 (UTC)

Unnecessary process creep. The existing procedures for protecting a page will suffice. The question in this case is why an article that was apparently vandalized 325 times never went through WP:RFPP in a timely manner. Articles vandalized that often will almost always be protected regardless of the reason why. Resolute 20:55, 26 May 2010 (UTC)

Renaming the "Flagged Protections" feature

As mentioned on wikien-l, the team working on the Flagged Protections deployment plans to rename the feature. If you have an opinion, see a full description of the situation on wikien-l, and then comment on the 'Terminology" subpage talk page. WMF plans to pick a name no later than May 28. -- RobLa (talk) 18:15, 25 May 2010 (UTC)

Proposed Move Of WP:Ownership of articles To WP:Ownership

There is a proposal to move WP:Ownership of articles To WP:Ownership at Wikipedia_talk:Ownership_of_articles#Move.3F.174.3.121.27 (talk) 02:42, 28 May 2010 (UTC)

Toolserver IPs

As it is against both toolserver and enwiki policy for bots to edit while logged out, a proposal to permanently soft-block the toolserver IPs has begun at Wikipedia talk:Bot policy. Please join the discussion there. Anomie⚔ 15:13, 28 May 2010 (UTC)

Good article symbol on GAs

We currently have a star on FA. I do not know if this has been discussed before but what about putting the GA symbol on good articles?--Doc James (talk · contribs · email) 05:47, 29 May 2010 (UTC)

Comes up at intervals and does not gain consensus - see Wikipedia:Perennial_proposals#Indicate_Good_Articles_to_readers - Peripitus (Talk) 06:28, 29 May 2010 (UTC)

Actually, the very day you asked the question this started being rolled out. A straw poll revealed a 55-19 consensus at the project page, so they're making it happen. - Jarry1250 ^{[Humorous? Discuss.]} 14:19, 30 May 2010 (UTC)

Suggested Portal: Childhood and Parenting

WP might consider creating a portal for this topic. Parenting already has a substantial template but there's nothing on the Portal page that directs the potentially very large audience for this topic into the Opus.
I waited a year for it to magically appear before this suggestion. (I'm a parent but no other qualification to do it myself.) Twang (talk) 06:05, 29 May 2010 (UTC)

Browser Statistics

I'd like to see Wikipedia publish anonymous browser statistics based on the wikis' logs. We already have wikistats for page views. We used to have Wikipedia:Browsers, which is now inactive, and even a bug has been filed.
Over a year ago I spoke via IRC with Domas Mituzas who runs wikistats, and according to him the statistics he gets cannot identify a unique user, to this needs to go higher than him.

To web developers, browser statistics are an important tool to measure when browser support can be dropped. It is currently impossible to determine browser statistics (see Browser market share). Wikipedia is one of the most visited websites on the internet, its visits are not skewed to a certain user base, it strives to create a summary of all human knowledge. Please make this information available. --bitbit (pka Nezek) ^(talk) 10:05, 29 May 2010 (UTC)

http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm and friends. Happy‑melon 11:23, 29 May 2010 (UTC)

Will Wikipedia survive if in the future most of its editors leave?

No, it will collapse; vandalism will gradually rot it. Hence, one has to think what will keep people to it. More videos are urgently needed. People are developing a desire to watch videos all the time nowadays. Hence one should be including more and more open videos that are relevant to the article in wikipedia. --194.219.142.101 (talk) 10:43, 30 May 2010 (UTC)

I agree with you that Wikipedians keep this project going. I am not however sure if I like embedded videos. Medpedia uses them as one can see here [1] and it just clutters things. They would also be hard to change and edit further.Doc James (talk · contribs · email) 10:55, 30 May 2010 (UTC)

Doc James, I agree that the example at Obesity is bad, because the same information can be provided in a fraction as text. OTOH I've used small clips at Cnidaria and Annelid to show how these animals move, which quicker and easier for readers than the equivalent text. --Philcha (talk) 15:53, 30 May 2010 (UTC)

OTOH use of videos as citations is a mess:

• Hard to hear the speech, because of interruptions and other broken sentences.
• Videos are often longer than a section of a book. When citing a book, one must provide a page, and I suggest they should also be required for cited videos, so that one does not read the whole video.

You've completely misdiagnosed here. Poor newbie experiences are the looming problem; don't know how the heck you came up with "not enough videos" as the most pressing issue. --Cybercobra (talk) 11:23, 30 May 2010 (UTC)

Videos attract readers. Wikipedia is a top-10 (top-5?) website. We currently have no problem on that front. The problem is trying to convert them from readers to editors, then trying to get them to stay. Mr.Z-man 14:49, 30 May 2010 (UTC)

I agree with Cybercobra and Mr.Z-man that keeping would-be editors is the problem. New editors and WP want to work together, but WP's policies and guidelines, most of which are justified (e.g. WP:V) are obstacles for would-be editors. I'm in the early stages of a personal project to try to guide new editors through the first stages as they come in through the door. --Philcha (talk) 15:53, 30 May 2010 (UTC)

When I said editors I means users; i.e. with no users, no editors (even if you have a problem with converting them to editors). --79.130.5.74 (talk) 09:28, 31 May 2010 (UTC)

Copied from this thread at Jimbo's talk page.

On all pages that are not protected/semi-protected, the tagline should read: "From Wikipedia, the free encyclopedia. You can edit this page." followed by a button marked "edit" linking to a very short, simple few sentences about how to, and a link to the Talk and Edit pages of the article. That, alone, would double the editor activity overnight. I think that would be a good thing. Anthony (talk) 18:20, 30 May 2010 (UTC)

Call me an elitist, but I don't know if we really want to generate an income of editors which are still unable to understand that anyone can edit Wikipedia after so many years of its existence and the subtitle in the main page. --Cyclopia^talk 19:22, 30 May 2010 (UTC)

If we make it easy and obvious, stupid people might start editing? Interesting hypothesis. Only one way to find out, and it could be undone. Anthony (talk) 20:15, 30 May 2010 (UTC)

This is all quite interesting and should be raised with the usability team. Based on my non-Wikipedia experiences (at Wikia), encouraging more people to edit does not result in a reduction in quality, so I disagree with Cyclopedia's view. But, in the end, it is, as Anthonyhcole says, an empirical question. Most things are. :-) --Jimbo Wales (talk) 22:59, 30 May 2010 (UTC)
End of excerpt.

I have asked at WP:Project Usability if there are any technical obstacles. Is that the right forum to discuss whether this should be implemented? Anthony (talk) 12:28, 31 May 2010 (UTC)

I believe another important step is to massively simplify the body of "instructions" we give people - help pages, policies, guidelines and all sorts of other inward-looking pages that have multiplied and expanded over the years without any attempt to control them, and which really must freak people out when they arrive here, particularly when they start getting linked to them by way of "explanation" of certain things. I'm sure this must turn a lot of people away - and even well-established editors are not served by having this information presented in such a warpedly irrational manner that causes constant doubt and misinterpretation.--Kotniski (talk) 13:40, 31 May 2010 (UTC)

If someone has just come to Wikipedia to correct spelling sure. However if one has come to promote their current fringe views using self published books we need guidelines and policies to help established editors deal with this. The problem is not the number of policies it is often that the policies we have are not enforced (take WP:COI as not applied here for example). If one does reasonable work one can edit just find having read few or none of the policies. Wikipedia needs to promote the creation of top quality evidence based articles. This requires consistency between articles and an in-depth explanations of how to accomplish it.

In reply to the commend above I have no problems with the limited use of video as done by Philcha in these example. While I think it adds to the project it will make little difference in getting people involved.Doc James (talk · contribs · email) 14:49, 31 May 2010 (UTC)

I agree we need policies and guidelines. But we don't need the mass of words and pages that we currently have (which are often impossible to tidy up since certain editors attach an almost religious significance to them, believing that every word and nuance is vital to Wikipedia's continued survival, however illogical and incomprehensible the text actually is). Short, clear instructions would be to everyone's benefit, and would make enforcement more of a realistic proposition too. (That's not to say there isn't a need for detail on certain matters, but most of our texts at the moment don't add substantial detail, only waffle and deliberate fudge - it's much easier to get everyone to agree with you if you write something that everyone can interpret in their own preferred way.)--Kotniski (talk) 15:12, 31 May 2010 (UTC)

Personally, I think trying to reduce the number of rules and procedures as a way of attracting new users is a Sisyphean task. The reason we have so many policies and so much procedure is because we have so many users. Compare it to traditional education. If you have a student:teacher ratio of something like 5:1, you can rely less on textbooks and lectures and more on individual communication. But if its more like 30:1, then the teacher is forced to rely on lectures and reading textbooks since there isn't enough class time to work with each student. The more new editors we have, the less time we have to work with them individually and we're forced to communicate using template messages and links to policies and help pages. We might be able to trim and consolidate some rules and procedures, but if you do it too much, it will just naturally grow back as people realize that it was needed. Rather than actually reducing the amount significantly, I think more effort should go into organizing so that its presented in a logical fashion and self-guided tutorials so that new users can learn without having a textbook thrown at them but without the need for one-on-one discussions. Mr.Z-man 15:20, 31 May 2010 (UTC)

There seems to be no shortage of people of very low intelligence who find no problem in figuring out how to edit Wikipedia. If potential good editors are put off it isn't because it is too difficult. Dmcq (talk) 15:35, 31 May 2010 (UTC)

I disagree. To make such an assertion, you would need to not only know how many people do figure out how to edit, but also the number of people who don't figure out how to edit (a number very hard to come by). I consider myself an intelligent person, reasonably proficient with computers, but I found editing a very scary and confusing experience at first (and still do, at times). Our markup language is not intuitive. We have a lot of rules, some of which are very important to anyone editing (i.e. wp:V), and others which are much less important for new editors (wp:DP, etc.). I agree with Mr. Z-man: we could certainly use some more intuitive, self guided tutorials to throw in a welcome template, rather than just link to a bunch of rules. Actually, we do have a tutorial: wp:Tutorial. It would help if we actually linked to it in prominent places, like, I don't know, on the editing screen, or even on article pages near the edit button. Buddy431 (talk) 18:09, 31 May 2010 (UTC)

Hi, Buddy431, I don't think I've seen wp:Tutorial - WP is poor at delivering information to those who need it. The project I'm working on: --Philcha (talk) 19:01, 31 May 2010 (UTC)

• Goes through the first steps of a newcomer's attempt to edit/create an article.
• Uses a formal, conversational style, hoping to make the newcomer relax.
• Makes citations easy, as I think WP:V and citations are the major obstacles for newcomers.
• Provide a "lite" introduction to the most important policies and guideline, hoping that over 90% of the sitations are covered by about 20% of the text in the policies and guideline; and hoping that I can tell newcomers when more than the "lite" introduction is needed, and where newcomers can get advice.

I agree with Philcha on the above point. We needs a good process for welcoming and introducing people to Wikipedia. One of the problems I have encountered is a lack of awareness about sourcing. This I have created a page explaining how to find good sources for both text and images pertaining to medicine to go with out guideline W:MEDRS.

What we need is a Wikiproject to coordinate the efforts of introducing and attracting people to Wikipedia. I know we have the usability project but we could use a Wikiproject here.Doc James (talk · contribs · email) 19:38, 31 May 2010 (UTC)

Good Articles icon

In case someone is unaware of it (I was) there has been a discussion at Wikipedia talk:WikiProject Good articles, where many users agreed to create a simbol to indicate good article status at the article mainspace, similar to the star of featured ones (and not just at the talk page, as it was done so far). The template Template:Good article has been created and it's already being added to articles.

This is not a proposal I'm making, but a comment of something that is already being implemented. It's still listed at Wikipedia:Perennial proposals, so if the consensus achieved at that page is considered enough, this should be removed from that page MBelgrano (talk) 14:25, 30 May 2010 (UTC)

Oh, heh, I just did [remove it from 'Perennial']. Maybe someone can revert me if consensus changes (again). - Jarry1250 ^{[Humorous? Discuss.]} 15:09, 30 May 2010 (UTC)

Icon = good idea. Well done! (Are you planning to do a big AWB run and add it to them all?) I just signed up at Wikipedia:Bot requests#GA symbol to do it. ╟─TreasuryTag►most serene─╢ 15:12, 30 May 2010 (UTC)

• Query—some Good Articles appear to be absent from Category:Good articles. Why is this, and what should be done about it? ╟─TreasuryTag►hemicycle─╢ 15:15, 30 May 2010 (UTC)

  The category was only created yesterday! :) The new template adds to it... - Jarry1250 ^{[Humorous? Discuss.]} 15:42, 30 May 2010 (UTC)

  Ah, that would explain it! ╟─TreasuryTag►sheriff─╢ 15:43, 30 May 2010 (UTC)

• I think that the Pass part of the Wikipedia:Good article nominations, page needs to have this template explained so that users passing a article for GA now that they need to put this new template up on the GA status articles as of now. Like "put this template Template:Good article on the newly GA granted articles front page".Or similar.--ÅlandÖland (talk) 20:14, 30 May 2010 (UTC)

Can we get a bot to do it automatically?Doc James (talk · contribs · email) 21:17, 30 May 2010 (UTC)

I doubt it, as featured/good articles cannot be detected—they are human decisions, unlike protection, which is technical and can be detected by a bot. —MC10 (T•C•GB•L) 17:15, 31 May 2010 (UTC)

I think Jmh649 meant detect Talk: page good article tags. FA bot already does this per request and GA can have the same.—  Hellknowz  ▎talk  17:22, 31 May 2010 (UTC)

Yes exactly because people are currently adding them manually but you have the talk page tag that the bot could go on.Doc James (talk · contribs · email) 17:25, 31 May 2010 (UTC)

I ment more like having it on the Pass part of the Wikipedia:Good article nominations page so that the editor closing a successfull GA-status article knows that the template exist and can put it on the articles front page. As the template is so knew its possible that some editors arent aware of its existance.--ÅlandÖland (talk) 17:35, 31 May 2010 (UTC)

It could be point 5. on the Pass list.--ÅlandÖland (talk) 17:37, 31 May 2010 (UTC)

• Thinking ahead, may be the FA bot needs to be updated to remove the {{Good article}} template when applying the {{Featured article}} template. Keith D (talk) 19:02, 31 May 2010 (UTC)

My opinion about illicit/prescription drug use and how it's manners of use are described on Wikipedia

Resolved

 – Wikipedia is not censored. ╟─TreasuryTag►consulate─╢ 21:17, 30 May 2010 (UTC)

As a person who was just diagnosed with Bi-polar disorder as well as Adult Attention Deficit Disorder - one of the medications I was prescribed ( among a couple of others ) was Ritalin. I researched all the medications in a variety of areas. What really shocked me was when I researched Ritalin. Not only does it describe it's uses, effects, contraindications and the usual *stuff*, it also describes it's use as a street drug and even describes how some people like to "crush" it and "snort it" for a quicker high, when abusing the medication. I would have never even considered such a thing and wouldn't even know this was possible until I read it described on this particular page. What bothered me was that college students use this a lot to cram for exams, which is a well known fact and mentioned in the article. Most disturbing however was the description of how to use it in a crushed and snorted form, which I imagine could seriously cause problems for anyone, college student or not, and even lead to death. I wonder if leaving this sort of information out of drugs that can be abused in this manner is censorship or perhaps a smart thing to do?

Editing a page to delete the ways a standard prescription medication can be made to be more "potent" and "a quicker high" is something I think is worthy of debate.

I am wondering if anyone agrees with me or feels like it's just a fact, like it or not and it does need to remain under that specific topic ( or any other similarly abusable drug for that matter)

Is this so parents can prevent it from happening if they happen to see a straw with a mortar and pestle in their child's room? I don't think so. I think it is a way to teach creative and dangerous ways to abuse particular drugs.

Any comments?

BTW - If I were 18 or 20-ish, was on Ritalin for ADD and help with studies and attention problems, at that age - I'd be all over it. I'd be crushing and snorting and thanking Wikipedia for "turning me on". Alas, I am a 53 year old adult with no desire to ruin my life or health.

I have never posted anything, edited anything or even know if I'm in the right place to start a discussion on the matter.

Leeeeenda (talk) 21:06, 30 May 2010 (UTC)leeeeenda <Methylphenidate>

Well I hope this information helps people realize the importance of keeping this type of medication locked up and helps parents realize the potential seriousness of managing this medication use by their children. People may steal it from their kids or their kids may sell the stuff. For those who are involved in this type of behavior Wikipedia is not needed as they will have figured it out with the help of their friends and other resouces. Wikipedia however is not at how to guide. WP:NOT. Will look into it further.Doc James (talk · contribs · email) 21:16, 30 May 2010 (UTC)

Wikipedia is not censored in any way. That would include descriptions of drug use, which, I'm sure you can see, has encyclopedic relevance. ╟─TreasuryTag►consulate─╢ 21:17, 30 May 2010 (UTC)

Well not censored we do not provide how to instructions. It does not look like there are how to instruction in this case however. Here is the first google hit one gets when one types in "shooting ritalin" [2]. I do not think Wikipedia is what people need to be worrying about. I guess the main reason people bring up concerns here is we are one of the only sites that will actually license and address peoples complaints.Doc James (talk · contribs · email) 21:23, 30 May 2010 (UTC)

No, we don't provide how-to instructions per se. Inevitably, describing the way in which drugs are used could potentially indicate to someone how-to do so themselves, but that is not our responsibility. ╟─TreasuryTag►constablewick─╢ 21:24, 30 May 2010 (UTC)

I looked over the Methylphenidate (Ritalin) page - didn't see much anything that was how-to related to remove...unless I am missing something here. Casliber (talk · contribs) 00:09, 31 May 2010 (UTC)

Bots to fill proper accessdate=

I have moved this from misc. to proposals, continuing from inactive VP Misc.

I propose that:

A bot may add missing |accessdate= parameters to referenced templates with |url= parameters¹ setting the |accessdate= as the date this url² was first³ added to the page.

¹ Such as, {{cite web}}, {{cite news}}, {{cite journal}}, etc.

² Not the reference itself, as editors/bots may have reformatted it.

³ The bot should adequately check for vandalism/temporary removal, so tools, like WikiBlame should be used cautiously.

I presume it is very reasonable to assume access date matches the addition date in vast majority of cases. The problem pages are those with referenced content copied over (bots can easily ignore links added in the first revisions for new pages). The second is when users are accessing and adding material after the url is already added (although few editors, as far as I know, actually update the access dates afterwards). So the false positive rate should be quite small.

A couple bots currently in development are inadvertently assuming the addition date to be the |accessdate= in order to retrieve archive (e.g. Wayback) links for linkrot battling. I believe the benefit of editors knowing the access dates to work with dead links much outweights the possible mistakes. It would be nice if this discussion can be referenced for current and future bot development. —  Hellknowz  ▎talk  16:53, 31 May 2010 (UTC)