Wikipedia:Village pump (proposals)/Archive 55

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

Village pump (proposals) archive  

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

---

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

Abolish the silly headers

See also Wikipedia:Requests for comment/Wikipedia Forever. Rd232 ^talk 11:34, 14 November 2009 (UTC)

This very long section has been moved to /Fundraising headers.

"our early fundraising efforts extremely slow (less than 50% from last year)" - Rand Montoya, 17 Nov. [1] Rd232 ^talk 09:20, 17 November 2009 (UTC)

Wiktionary_Hover: a JavaScript on double-click

Wikinews proposes a script to display the Wiktionary definition in a small board, when one double-click on a word. It's already been installed in the following Wiktionaries gadgets: in French and in Italian.

To add it here, we should vote for an administrator, in:

1. MediaWiki:Gadget-dictionaryLookupHover.js, copies without the guillemets : "importScriptURI('http://en.wikinews.org/w/index.php?title=MediaWiki:Gadget-dictionaryLookupHover.js&action=raw&ctype=text/javascript');"
2. MediaWiki:Gadgets-definition, adds "* dictionaryLookupHover|dictionaryLookupHover.js"
3. MediaWiki:Gadget-dictionaryLookupHover, describes the gadget.

JackPotte (talk) 23:01, 13 November 2009 (UTC)

To explain: this script is a javascript tool which will retrieve the top definition for a word based on the language of the website the word is on, and the user's language preferences. The following user languages are natively supported: Spanish, Russian, Italian, French, English, Dutch. Other user languages will default to English until they are fully supported.

The script is currently available as a gadget or via common.js on many WMF projects; a good example is at fr.Wikinews where it is installed so everyone can use it.

The tool is particularly useful for readers who are not native speakers of the website's language. - Amgine (talk) 23:15, 13 November 2009 (UTC)

Fantastic tool. I don't see why we shouldn't turn it on. Fences&Windows 02:25, 14 November 2009 (UTC)

I agree. Count me as a !vote for immediate implementation.
— V = I * R (talk to Ω) 05:40, 14 November 2009 (UTC)

Not working for me. Screenshot of what this does? --Cybercobra (talk) 13:31, 14 November 2009 (UTC)

Here is a screen clip of the tool in use on a blogspot blog: clip. The blog is in English, and the user preferences are in English, so the definition returned is English. Here is a screen clip of the tool in use on fr.wikinews: clip. The website is in French, the user preferences are in English, so the definition is the French language entry from the English Wiktionary. - Amgine (talk) 15:25, 14 November 2009 (UTC)

As long as it does not function like the script at nytimes.com article pages (example) where, if you either click&drag-to-highlight or doubleclick-to-highlight a word, a small question mark link pops up, and prevents me (in firefox) from using all normal right-click functionality (copy, search google, etc). -- Quiddity (talk) 21:27, 14 November 2009 (UTC)

This script corresponds better to my needs than the http://nytimes.com one, I just invite you to test it individually, by copying my User:JackPotte/monobook.js, into yours. JackPotte (talk) 14:31, 15 November 2009 (UTC)

Today, it's used by at least 13 sister projects. JackPotte (talk) 20:42, 17 November 2009 (UTC)

Wikipedia data extraction

An WP:RFC is being drafted on how to organise data on Wikipedia better, to enable easier organisation/maintenance and data extraction. Comments/contributions please on constructing the RFC. See WP:VPT#Infobox Template Coherence Proposal. Rd232 ^talk 11:16, 16 November 2009 (UTC)

Movement Toward Clearer Language

Often times, I have seen the word 'as' used in the place of 'since' or 'because.' Most of the time this makes the proper use of the word 'as' less clear. I propose that we stop using the word incorrectly in what seems to be an effort to sound academic.— Preceding unsigned comment added by 199.111.190.206 (talk • contribs)

Wikipedia already has ample policies promoting clear writing. Having a policy for use of "as" (and presumably every other word in the lexicon that anyone takes issue with) would get daft. Anyone can rewrite passages that are confusing. Pseudomonas_(talk) 11:20, 17 November 2009 (UTC)

(ec) As as a synonym for since or because is normal English, although particularly common in some specific contexts. It's certainly not incorrect to use it in this way, and I doubt that most such uses are motivated by the desire to sound academic. Of course it shouldn't be overused, had better not be used outside its proper context, and must not be used when it can be confused with the other meanings of as. But some kinds of texts would have an extreme density of since and because if we didn't have alternatives such as as. This arises most often in academic texts, and that's why academic texts are the natural context for this use of as. Hans Adler 11:25, 17 November 2009 (UTC)

Didn't we just have this discussion two months ago? Anomie⚔ 12:44, 17 November 2009 (UTC)

Excellent point, as both IPs are from the University of Virginia. Hans Adler 17:48, 17 November 2009 (UTC)

NPP from the back

Special:Newpages has a delightful link that sends you directly to the end of the unpatrolled log. I use that option a lot. When a page is marked as patrolled (action=Markpatrolled), you get a link back to special:newpages, but not to the end of the patrolled log. I would love to see this added to that page. I propose that we add that option to the page. Martijn Hoekstra (talk) 14:39, 17 November 2009 (UTC)

Edits to MediaWiki:Markedaspatrolledtext would fix that. The return to language is in MediaWiki:Returnto but I don't understand how that works. Hipocrite (talk) 15:24, 17 November 2009 (UTC)

Thanks for the info, I really didn't have a clue where to find it. Before changing anything there, I want to make sure that people agree on them though! Martijn Hoekstra (talk) 17:17, 17 November 2009 (UTC)

That sounds like a good idea, though I think it is non controversial enough so that a bold admin (who know what they are doing) could add it. Graeme Bartlett (talk) 21:14, 17 November 2009 (UTC)

Sounds like a good idea to me, too. Regards Spitfire^Tally-ho! 21:59, 17 November 2009 (UTC)

I suppose it's non-controversial enough to go ahead and be Bold about it. If the trout hits my face, the shit must have hit the fan. Tally Ho! Martijn Hoekstra (talk) 22:48, 17 November 2009 (UTC)

Deleted articles

For articles deleted with non-malicious content, would an administrator create a website where all these articles would be viewable? --William S. Saturn (talk) 23:36, 17 November 2009 (UTC)

There are many administrators who are willing to mail any user non-malicious deleted content. To host it however is not one of Wikipedia's aims, but I do believe there are other sites that host previously deleted Wikipedia content. As long as their licence is compatible with Wikipedia's, there is no problem with hosting the content there. There are probably some people here who can tell you where you can find these sites. Martijn Hoekstra (talk) 23:40, 17 November 2009 (UTC)

Isn't that was Deletionpedia is about? SunCreator (talk) 23:51, 17 November 2009 (UTC)

Promote use of talk page for cleanup templates

I want to preface this with my personal opinion about cleanup templates: I think that they suck. I think that the fact that editorial tags are being placed on the article instead of on the talk page is the most obvious issue. More importantly though, the over use of these dang tags is just messy clutter that has always bugged the hell out of me.

Recognizing the obvious fact that many editors seem to take some pride in tagging articles however, I've never tried to TFD any of them or anything like that (deletions are not the answer to these sorts of concerns anyway, in my view). I do tend to remove tags that I come across though, either by simple removing those that don't seem to be supported (which occurs far to often) or addressing the relatively minor issue(s) which they are screaming at our readers about (which normally only takes as much time removing the tag!).

The biggest current issue with these tags though is that they are often simple placed on the article with the apparent expectation that the problem will be obvious to everyone else. Rather then being contentious about cleanup templates and their use, I think that the most constructive course to take is to try to encourage people tagging an article with a cleanup tag to post something about what needs to be done on the article's talk page. With that in mind I edited a couple of the templates to include a talk page link within the template itself. For an example, see: {{Anachronism}}, as well as several of the other (through "B") Category:Cleanup templates templates, which I edited back in September. The proposal here is to crowd source adding a similar talk page link to the remainder of those cleanup templates, as there are a tone of them (which is a whole other issue really, but that's something to be discussed elsewhere). If you're willing to help out please jump in and edit at least one template to include a link. Thanks!
— V = I * R (talk to Ω) 04:53, 9 November 2009 (UTC)

Tags should be applied to the article itself when they warn that there is currently a real problem with the article that the user should be aware of, such as not being neutral or seeming like original research. However, an acceptable article is not an ideal article. Tags made for issues for making an ideal article, rather than an acceptable one (such as {{Orphan}} or {{Dead end}}) should be moved to talk page instead MBelgrano (talk) 13:03, 9 November 2009 (UTC)

See WP:PEREN#Move maintenance tags to talk pages, MBelgrano. I do think the original idea here (encourage/require that the tagger actually use the talk page) is a good idea. Anomie⚔ 21:52, 9 November 2009 (UTC)

I was sort of tired when I wrote this, and reading over it now I realize that I got a bit off track and rambled a bit... not that I want to retract anything, as everything said above is the way I feel and I stand by it. However, the main point to posting this is to get help in adding links to the talk page, onto all of the cleanup templates.
— V = I * R (talk to Ω) 22:21, 9 November 2009 (UTC)

They don't all need links to the talk page. The likes of {{unreferenced}} and {{uncategorised}} are obvious problems that do not require further elaboration on the talk page. PC78 (talk) 22:36, 9 November 2009 (UTC)

Personally, I disagree. Even {{unreferenced}} should have something about it's addition to the article added to the talk page simply because if it's actually that obvious what the problem is then why not solve the actual problem rather then simply tagging the article? If there's a legitimate reason for the tag, then the person adding the tag should at the very least be able to say something like: "I can't find a source for (whatever) but I know it's true, so I've tagged the article with {{unreferenced}}."
— V = I * R (talk to Ω) 22:53, 9 November 2009 (UTC)

I see no reason at all to require any links to the talk page except for NPOV. Unreferenced is pretty darn clear - the article has no references. Ditto uncategorized. Its not for those who dislike tags to declare that those who find them useful must be forced to either fix the issue, write redundant and silly notes on the talk page to say "I tagged this as unreferenced because it is not referenced" or ignore it. Tagging articles for issues is valid Wikipedia work. -- Collectonian (talk · contribs) 23:08, 9 November 2009 (UTC)

You're mistaken in the belief that anything is being made to be "required" here. There's simply a link being added to the message boxes that points to the talk page. If the editor who adds the cleanup template does not wish to leave a message then (s)he doesn't need to.
— V = I * R (talk to Ω) 20:43, 10 November 2009 (UTC)

Not valid work

I see nothing about "tagging articles for issues" that makes it valid Wikipedia work. What is the purpose of fishing around from article to article (most of which the "editor" knows nothing about) tagging things, often without going to the talk page and seeing if there was a reason, checking history to see if a major rewrite is underway, what the status of the article is, how often people are working on it, etc. Fly-by editors are disruptive and usually ignorant of the topic. If you go to an article, know the topic, and actually fix the problems or go elsewhere. If you can take 20 seconds to slap a citation needed template on a sentence then you have 2 minutes to use Google and find the stinking source that is needed yourself. Perhaps if we implement Ohm's proposal and make more steps for these trollers then perhaps they find it too hard to keep doing and stop, or at least it will slow them down. We are here to put information in an encyclopedia, not learn new ways to tell others to do that job. Perhaps everyone should be forced to do at least four improving edits a week or they loose the right to tag at all.Camelbinky (talk) 04:23, 10 November 2009 (UTC)

Facepalm — The Hand That Feeds You:^Bite 23:56, 10 November 2009 (UTC)

Provide a metadata page for cleanup templates and wikiproject banners

Alternate proposal. Rationale: Many talk pages are created simply to hold WikiProject banners and are never used thereafter. A metadata page could hold both cleanup templates and wikiproject banners and said things could be displayed to users who want to see them based on prefs. Discuss. –xeno^talk 17:01, 10 November 2009 (UTC)

It sounds like an awful lot of work (almost every article has a project banner and more than 600,000 have maintenance templates). It has a high potential to break things (how many scripts, bots, and tools rely on the current system?). And the benefit seems rather minimal. I would like to eventually see metadata like coordinates and categories eventually switched to things that don't rely on the wikitext, but just creating a subpage to stick the templates on isn't that much better than what we currently have. Mr.Z-man 17:55, 10 November 2009 (UTC)

Yea, I agree that this seems to be too much work for too little gain. Besides, I like the project banners and everything else being right there on the talk pages. I never really have understood why people are bothered by that (aside from not letting things rage out of control on page headers, of course). Aside from that though, there's been some effort at removing sub-pages in slightly different topics anyway, so I don't think most editors (myself included, really) would appreciate this sort of thing going forward.
— V = I * R (talk to Ω) 20:37, 10 November 2009 (UTC)

Do talk pages created solely for placing talk-page templates constitute a problem at all? If so, why? MBelgrano (talk) 12:44, 12 November 2009 (UTC)

The bluelink indicates there might be some relevant discussion when in fact there is none. However, I do agree that this solution is a lot of makework with marginal gain. –xeno^talk 15:26, 19 November 2009 (UTC)

Syntax coloring on .js and .css pages

It would make editing such pages (ie. monobook.css, monobook.js) easier if there were color-coding, as most coding environments have. As such the colors would need to show up even during editing, in the text box, rather than only when viewing the page.

I know this isn't a major area of concern, but it would be a minor convenience, if it wouldn't take too much effort to implement. Equazcion (talk) 21:53, 12 Nov 2009 (UTC)

That's about the same deal as having syntax highlighting for editing wikitext. I think the Usability people are working on that, or were at least considering it at one point.

Personally, I just use It's All Text! to load it in a real editor when necessary. Anomie⚔ 22:17, 12 November 2009 (UTC)

WP:WIKIED. --King Öomie 15:35, 19 November 2009 (UTC)

Hide project banners of inactive WikiProjects

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Discussion here has dwindled. Therefore I have moved it to Template talk:Inactive WikiProject banner. — Martin (MSGJ · talk) 21:05, 18 November 2009 (UTC)

---

We have many WikiProjects which are inactive (see Category:Inactive WikiProjects); some never even got off the ground. Some of them have project banners which take up space on talk pages. If the project is inactive then the assessment data is not being used either. So I propose to hide these banners, by blanking their banner templates. The code and assessment would not be removed from talk pages, so the banner can easily be resurrected in the future if the project becomes active again. — Martin (MSGJ · talk) 22:58, 12 November 2009 (UTC)

easy support. –xeno^talk 22:59, 12 November 2009 (UTC)

I can see people removing the banners if nothing is visible... --Izno (talk) 23:04, 12 November 2009 (UTC)

(edit conflict) Along the same lines, I can also see someone deleting them if they're blanked. A <noinclude>ed note explaining the situation would be better than a blanking to solve that. Just a minimal banner rather than none might solve Izno's concern:

(which could probable be done easily enough through {{WPBannerMeta}} by adding an "inactive" parameter) Anomie⚔ 23:23, 12 November 2009 (UTC)

Hiding works for me, though why not just remove them or delete them. Most inactive ones that have been inactive more than a few months generally stay that way. -- Collectonian (talk · contribs) 23:09, 12 November 2009 (UTC)

Question Are we just going to blank the banner visually, or are you also proposing to remove the code that places those articles into categories? The box blanking is easily revertable. The deletion of thousands of now empty categories is a little more difficult. If a project is later revived, the recreation of previously deleted catagories could result in a mess at CfD. Jim Miller ^{See me | Touch me} 23:10, 12 November 2009 (UTC)

Why not just remove the banners, particularly if the project has been inactive for say 2 years, 1 year? There's no point in project banners on a talk page if a project is inactive. --IP69.226.103.13 (talk) 23:19, 12 November 2009 (UTC)

(to Collectonian and IP69xxx) Many particularly unnecessary edits to remove a short piece of code, and also the project can't be easily resurrected if we do that. –xeno^talk 23:21, 12 November 2009 (UTC)

I still think they should be removed if the project has been inactive for any reasonable length of time. I wouldn't say it's unnecessary to de-spam a talk page, and they shouldn't be left in place merely to facilitate the hypothetical resurrection of a project. PC78 (talk) 23:45, 12 November 2009 (UTC)

The project can be resurrected in the usual way, just get a bot to add the banners again, or save a list of the pages to the defunct project page. --IP69.226.103.13 (talk) 00:10, 13 November 2009 (UTC)

I see no reason to do anything about them. They might lead to the Project being restarted and they might remind people to replace them with teh banner of a parent project. I do not see that removing them improves wikipedia so why do it. --Bduke (Discussion) 00:03, 13 November 2009 (UTC)

I don't see how having banners to 3-year-old never active projects improves wikipedia. I see how it can make wikipedia an uninviting and confusing place for a new user, though. And that is, imo, reason to delete them. --IP69.226.103.13 (talk) 00:10, 13 November 2009 (UTC)

I have no problem with the removal if: a) there is still an active project banner on the page, and b) attempts are made to merge the inactive project to an appropriate parent project. I just removed over 600 banners from a defunct project that was converted to a task force of its parent project. Conversion is preferable to outright deletion, especially regarding the categories on those talk pages. Jim Miller ^{See me | Touch me} 00:25, 13 November 2009 (UTC)

I'm okay with upmerging or finding a different task force, first. AIDs can go to medicine, etc. I don't understand a, though. It seems you're saying okay to remove the banner if the banner is left? Oh, you mean if any banner from any project is left on a page? I think that's the most frustrating thing for someone who comes to wikipedia and wants to engage in discussion about a talk page for the first time, click on a project banner, post there, then get ignored forever. I don't see the benefit, if that's what you mean. --IP69.226.103.13 (talk) 00:37, 13 November 2009 (UTC)

How about hiding the bulk of the banner so it says "This article was part of defunct project Foo, to discuss what should happen to the project go to WP:Projects for disucssion. " then people would have the choice depending on concensus:

• Request removal of banners at WP:BOTREQ
• Restarting the project
• Up-merging to Project Bar with or without keeping the granularity info (|project was = Foo) either by [[WP:BOTREQ], redirecting the banner, or making one an expression of the other.

Rich Farmbrough, 05:59, 13 November 2009 (UTC).

(Or what Anomie said) Rich Farmbrough, 06:58, 13 November 2009 (UTC).

Thanks for all the comments on this. I agree that it would be a good idea to show something along the lines of what Anomie suggested, as just blanking the template would likely cause some confusion. So here is what I think I will do:

• Instead of adding a new parameter to {{WPBM}} I think it would be simpler to write a new template (e.g. {{Inactive WikiProject banner}} or perhaps a new subtemplate of Template:WPBannerMeta for this.
• The template should use the same parameters as WPBM, so to mark a template as "inactive" all one has to do is replace WPBannerMeta with WPBannerMeta/inactive (for example).
• The output will be just one row (like Anomie suggested) both in full display and in its collapsed form inside a banner shell.
• The word "inactive" could be linked to somewhere appropriate, so that editors can get more information about what it means.
• The actual template page will also explain what has happened and how to reactivate it. It could also show what the template used to look like to save people looking through the history.
• I don't see support for mass removal of these banners, although I think we should make it clear that editors can feel free to remove them locally on a page-by-page basis if it is deemed appropriate.
• Wikipedia:WikiProjects for discussion is an interesting idea, but I think that it is relatively rare for a wikiproject to be discussed and so Wikipedia:Miscellany for deletion should suffice.

— Martin (MSGJ · talk) 07:28, 14 November 2009 (UTC)

Okay, {{WikiProject Elvis Presley}} is the first guinea pig. You can see how it appears outside and inside a banner shell. — Martin (MSGJ · talk) 08:25, 14 November 2009 (UTC)

They look find. I still think, especially for projects that never did anything but post banners, the banners are just clutter, but I'm fine with collapsing to one line since there appears to be consensus for that. --IP69.226.103.13 (talk) 08:44, 14 November 2009 (UTC)

Good idea, but it would be even better if the 'inactive' banners could be removed altogether after a certain period of time. One year? --Kleinzach 09:37, 14 November 2009 (UTC)

Personally, I would oppose this move. To my eyes, it would make far more sense to try to deal with the essential problem of an inactive project, which is what to do with the project page itself. In general, the best way to deal with that is to see if the group can be turned into a taskforce of some larger group dealing with the same area. If that can be done, then there clearly would be no problem in having the banner of the new parent project in place of that of the older project that has been turned into a subproject. But, in at least some cases, these inactive projects may be the only ones that really deal directly with certain articles, and I would very much regret seeing the removal of a banner if in so doing the possibly sole existing assessment of an article is also eliminated. John Carter (talk) 15:51, 14 November 2009 (UTC)

• I prefer the "Inactive" styling per Anomie and {{WikiProject Elvis Presley}} / Martin's example. I am concerned that without showing that a project has existed, that is by deleting the banners entirely from talk pages, a second project might inadvertently be started with a slight variation of the project name. Unlikely but still possible. Further, calling attention to inactive status via the banner and link might help revive a dormant project. Sswonk (talk) 16:07, 14 November 2009 (UTC)

• Some of these inactive projects amount to a week's worth of work by one person. Someone made up a project name, got a template, added it to 50 articles, then disappeared. A second project inadvertently naming themselves similarly is not going to impact anything, it seems. If it is, please elaborate, because I don't understand the concern. --IP69.226.103.13 (talk) 20:22, 14 November 2009 (UTC)

• Using hypothetical, illustration-only names, suppose "WP Battletown" is inactive and the banner is removed from talk pages. A year later, without realizing the first exists another editor begins and recruits different members for "WP Battletown, Texas". The new user has created new banners, userboxes, project subpages, categories and so on. Then, the creator of "WP Battletown" returns from a 16 month hiatus and sees the new project. Both see a duplication of effort and waste of time that would have been avoided if the second editor had simply seen the "Inactive" banner and taken over for the first. Page merges, page moves and history merges might all be forced when they could have been avoided by leaving a vestigial, "Inactive" banner on Battletown related article talk pages. As I wrote, it is unlikely but possible that this might occur. Sswonk (talk) 22:13, 14 November 2009 (UTC)

• To me, that's just way over-hypothetically worried. I think that happens once in the history of wikipedia and it's the only thing that ever bothers those constituents it's just not going to matter, particular, if instead of two inconvienced-because they're careless sorts you settle for 5000 inconvenienced because they're new readers, possible editors. --IP69.226.103.13 (talk) 05:29, 15 November 2009 (UTC)

• Note that for "2 hours of work by 1 person" never-got-off-the-ground projects, there's always WP:MFD. Anomie⚔ 01:57, 15 November 2009 (UTC)

Thanks. --IP69.226.103.13 (talk) 05:29, 15 November 2009 (UTC)

• Support Inactive Template Nice job Martin. I like this better than removing them outright. Editors interested enough in a topic to be spending time on the talk pages are at least given the chance to see the inactive link, and hopefully click through. The best result is to reactivate some of these projects. The next best idea is to get them merged into an active project. I also agree with Sswonk that the re-creation of these projects is work that doesn't need to be done. By maintaining the historical WP, interested editors can get a project back into active status. Jim Miller ^{See me | Touch me} 16:37, 14 November 2009 (UTC)
• Comment: Would a single banner specifying multiple inactive WikiProjects (when applicable), rather than one banner for each inactive project be better? –Whitehorse1 20:31, 14 November 2009 (UTC)

  It might be, if such a banner could tolerate the multiple revisions it would receive fairly regularly, with the related changes to the talk pages that the inactive banners are placed on. Just remember, every time someone tries to reactivate a project, they will want their separate banner restored, with the material removed from the inactive banner. For those projects which are, basically, seriously dead, like perhaps a group for a musical act that hasn't had anything notable happen to it in years, such a banner might be useful. But I think the amount of busywork related to changing it as people activate and deactivate projects might be more trouble than it's worth. John Carter (talk) 20:42, 14 November 2009 (UTC)

  That seems to be a lot of work for little (if any) real gain, to me. The inactive banner is already "collapsed", for one thing. Many of these will already be within {{Wikiprojectbannershell}} templates as well.
  — V = I * R (talk to Ω) 20:44, 14 November 2009 (UTC)

  A benefit would be compactness, cleanliness, Ohms. As said at the start "Some [inactive projects] have [b]anners which take up space on talk pages", which they (poss. multiple banners) still do irrespective of being collapsed or not. Edit: See below for more on this. –Whitehorse1 21:12, 14 November 2009 (UTC)

  The big problem with that idea is that all the talk pages transcluding the now-inactive project's banner have to be edited to swap in your multi-project inactive banner. With the current proposal, only the now-inactive project's banner itself need be edited. Anomie⚔ 01:57, 15 November 2009 (UTC)

I fully support the 'display as inactive' proposal. We kill three birds with one stone: first of all, we declutter talk pages and assessment categories. Second, we avoid losing valuable data. Whether or not a project is active, the placement and extent of its project banners represents a huge amount of effort, labour, and valuable metadata. It is actively damaging to WP to erase that data by removing project banners from talk pages; there is absolutely no need to do so other than vague notions of tidyness. The more of the infrastructure of a wikiproject remains, the easier it is to restore and revitalise. Leading to point three: by presenting a banner marking the project as inactive, we let the banners fulfil their original purpose: as advertisments for the project. There is nothing more disingenuous or demoralising to follow a link from an upbeat project banner, to the dead shell of a wikiproject. Even worse is when editors fail to notice the project's inactivity, and join it anyway, only to realise at a later date that it's totally dead. If a project is marked as inactive, editors who follow its links are actively encouraged to take on the task of reanimating it, which can only be a good thing. A very promising development all round, I'd say. Happy‑melon 21:12, 14 November 2009 (UTC)

Good third point, I had not considered. Still, for the make-an-effort and never get anywhere wiki projects, deletion would be better in my opinion. --IP69.226.103.13 (talk) 05:29, 15 November 2009 (UTC)

• (Follow-on/expansion from above on single vs. multiple "Inactive" banners.) There are two banner-shell templates: WPBS, and WPB. WPBS is normally used when up to six banners are present, otherwise WPB is used. The difference between the two is that WPBS—which is much more common of course—defaults to displaying a one-line summary of each WikiProject banner, while WPB defaults to displaying only a "[show]" link. Although it's possible for the defaults to be overridden to hide/show or expand the one-line summaries, the ordinary aka default outcome of the current proposal means anything up to six one-colored-bar summaries (containing "Inactive") for articles using WPBS. –Whitehorse1 21:53, 14 November 2009 (UTC)

Is this a problem? Unless a page is inactive (or over-archiving) you need to page down to get to any recent content anyway. I usually find that the most recent comments aren't on the first screen of a talk page anyway, or there aren't any comments at all. Either way, the use of the screen real estate for banners isn't something I have ever thought of as a negative. Jim Miller ^{See me | Touch me} 22:21, 14 November 2009 (UTC)

• Could we not just give the banners a css class that hides them? although I would prefer something that makes it go slimline and basically says "<WP Name> (inactive)". Peachey88 ^{(Talk Page · Contribs)} 00:04, 15 November 2009 (UTC)

  A CSS class to allow people to hide them via their personal CSS file (or possibly via a gadget, if anyone cares to write one) wouldn't be a bad idea. But hiding them by default would run into the same problem that blanking them would. Anomie⚔ 02:00, 15 November 2009 (UTC)

And does nothing for the new editor who does not realize that lots of wikiprojects go nowhere and isn't going to blank them. --IP69.226.103.13 (talk) 05:29, 15 November 2009 (UTC)

• I would support something like an |inactive=yes parameter in the metabanner (or a fork at /inactive) which would tell you that the project is inactive, with a link to a general guide (yet to be written?) on what to do and how to do it when a project is inactive (upmerge, convert to taskforce, revive). I'm not convinced that different colors are needed, or that they should be minimized. If it's a clutter, {{WPBS}} or {{WPB}} should be used anyway. Headbomb {^ταλκ_{κοντριβς} – WP Physics} 17:23, 17 November 2009 (UTC)
• I'd like to see inactive projects' banners dimmed slightly, along with the current denotation method seen on, e.g., Talk:Cirque du Soleil. Powers ^T 03:40, 18 November 2009 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Sub-pages for Village Pump

What does everyone think about using sub-pages for the village pump? for those of you that may not be immediately clear on what I'm talking about, I'm asking about using a system similar to the AFD/RFA pages, where each individual discussion takes place on it's own page but is transcluded onto the main page (so that readers can see all conversations at once).
— V = I * R (talk to Ω) 12:24, 13 November 2009 (UTC)

You mean have a page like Wikipedia:Village pump (all)? PC78 (talk) 12:45, 13 November 2009 (UTC)

You might as well wait for LiquidThreads, which is on its way Real Soon Now (tm). --Cybercobra (talk) 12:53, 13 November 2009 (UTC)

It's a good idea, but ANI is in much more dire need of this than Village Pump. Changes occur so frequently there as to make watchlisting almost useless in keeping track of individual discussions. I haven't found that to be so quite as much here. Addendum: It would be more practical here, though, since things happen more slowly here, and more by experienced users, so posting instructions for creating and transcluding subpages might be more acceptable. The ability to watchlist individual discussions here would be a major plus, even if ANI is a relatively more dire issue. As for LiquidThreads, it's only been in live testing for a couple weeks now, and in my opinion still has a long way to go before being implemented at Wikipedia. Equazcion (talk) 13:06, 13 Nov 2009 (UTC)

What are liquid threads? It would be nice even simply to have threads, you know, like every other discussion forum on the Web has been using for the past few decades... --Kotniski (talk) 13:30, 13 November 2009 (UTC)

See here for an example (its "beta" feedback page). A developer (User:Werdna) is working on just that sort of thread system as an extension to MediaWiki, which he calls LiquidThreads. When completed it will hopefully be implemented in place of the current wiki discussion system, ie. on all Talk: and other discussion pages. Equazcion (talk) 13:42, 13 Nov 2009 (UTC)

Man, I'm literally waiting for a LiqudThreads(LT) rollout on en.wikipedia with "baited breath". that being said... I'm not positive that a page(es) such as the Village Pump would actually directly benefit from being converted to use it. The discussion pages certainly should be converted to use the LiquidThreads system, but I'm not sure that the mainspace page(s) should do so. Maybe it's therefore a good thing that I brought this subject up prior to the eventual LT rollout here... (or not, who knows. I'm not that egocentric!). For the "proposals" and "policy" sections, at the very least, I would think that it would be desirable to keep the... er: "formal" statements as "normal" wikitext. It's possible that I'm actually conflating/anticipating the rollout of LiquidThreds in this proposal, somewhat; after a rollout we would then have the page and an LT driven discusion page for each "thread" on the Village Pump, after all.
— V = I * R (talk to Ω) 14:21, 13 November 2009 (UTC)

Unsure

I don't know that we'd need subpages here. It makes sense for AfD and RfA to have a consistent location to link to and for archiving purposes, but this is essentially a talkpage for all intents and purposes. I don't think there's anything to be gained by splitting discussion up unlike everything else of this nature. ~ Amory (u • t • c) 13:39, 13 November 2009 (UTC)

The gain in my mind is the ability to watchlist individual discussions, which would mean having to check the main page less often manually for changes to a discussion of interest. Equazcion (talk) 13:47, 13 Nov 2009 (UTC)

They would also be useful in loading at computers with slow conections, a single thread would be much more quick than the entire village pump. It may also prevent edit conflicts made by users who didn't really intend to say something in the thread, but instead start a new one by opening the last and adding a title header. MBelgrano (talk) 14:11, 13 November 2009 (UTC)

Yes, and manual/bot archiving might not be needed either (though the two advantages mentioned previously are far more significant). Hope they can get this working soon (as far as I can tell it really is just reinventing the wheel of standard threaded discussions, so maybe it won't take too long...)--Kotniski (talk) 14:40, 13 November 2009 (UTC)

well geez... I (or anyone else) could technically implement this change right now (ie: within 30 minutes) to all of the Village Pump. It's extremely easy for any of us to implement... the fact that it's that easy to implement and that it's not currently used gives me significant pause, is all. If no one really objects I'm certainly be more then happy to go forward, but my last attempt to do this wasn't so smooth (politically) so I'm being a bit more pragmatic in this case.
— V = I * R (talk to Ω) 15:50, 13 November 2009 (UTC)

You have my support. — Martin (MSGJ · talk) 15:55, 13 November 2009 (UTC)

(edit conflict)Well I for one object. It just seems to be excessive slicing and dicing. This kind of approach makes sense for AfD and RfA - they are constantly changing pages where discussions are only relevant for a certain period of time, and direct, nonchanging links are required. The Village Pump is entirely different in setup, and is much more akin to a talkpage of an article. It wouldn't make sense to use a subpage approach for article talkpages, so why do it here? Moreover, RfA and AfD are really process pages, where this is most definitely not. Issues with watchlisting specific discussions are outweighed in my mind by an inability to watch this page in general. ~ Amory (u • t • c) 16:02, 13 November 2009 (UTC)

You could still watch this page for new discussions, as whenever a new one starts, another transclusion would be made. Village pump can be thought of as a talk page, but if so then it's a talk page for all of Wikipedia; As such it carries a group of discussions that are much more separate from each other, with a much higher degree of individual appeal (people likely being interested in one discussion but not necessarily another), than any article talk page. Equazcion (talk) 16:10, 13 Nov 2009 (UTC)

Yea, I've seen this argument before, and I don't quite understand it (meaning, I do, but...). I want sub-pages because it makes watching both the main <whatever> page and the specific sub-pages easier. It's easier to me... but maybe that's because I know what to expect?
— V = I * R (talk to Ω) 16:18, 13 November 2009 (UTC)

Amory, compare it to WP:AfC where we used to have all submissions going on one page. It is a lot easier to keep track of things now with everything being on a separate subpage. — Martin (MSGJ · talk) 16:27, 13 November 2009 (UTC)

I'll second that objection. I for one commonly read pages on my watchlist via the diff rather than by the actual rendered text, as it makes it much easier to not miss new comments. I sincerely hope before LiquidThreads is released that it gives the option to get one big diff of all the threads since a particular time/revision, as otherwise I am going to be extremely annoyed at having to dig through myriad little pages trying to find out what new comments have been posted. There's certainly no way to avoid that with a subpage-transclusion scheme. Anomie⚔ 18:10, 13 November 2009 (UTC)

Really though, it's easier to track everything with individual sub-pages (to me, at least). As Equazcion mentioned above, you watch this page for new discussions and tag interesting ones (or remove uninteresting ones) from your watchlist (I actually use separate lists with page links, utilizing the related changes tool, but it amounts to the same thing).
— V = I * R (talk to Ω) 05:36, 14 November 2009 (UTC)

Except for how often an originally-uninteresting discussion here on the Village Pump becomes interesting (often for Chinese values of "interesting") due to topic drift. Anomie⚔ 01:36, 15 November 2009 (UTC)

Previous discussion

Previous discussion on topics of this nature: archive 50 and archive 41. Initiated by the same person in each case, but the discussion from archive 50 has a good deal more in it. Just bringing these cases up. --Izno (talk) 16:05, 13 November 2009 (UTC)

Thanks! reading...
— V = I * R (talk to Ω) 16:18, 13 November 2009 (UTC)

no, no, no... the conversation that you linked to in archive 50 at least, is discussing documents within the Wikipedia namespace in general... which is an idea that I don't support myself. Having separate documents for (for example) Wikipedia:Naming conventions and "naming conventions (insert topic)" is a good thing (which is a particularly relevent topic by the way, considering that several of them were recently merged!).
— V = I * R (talk to Ω) 16:25, 13 November 2009 (UTC)

The discussion contains a relevant proposal. Hence, it would be time-profitable to take the ideas and arguments used in that discussion and apply them here. :) --Izno (talk) 16:28, 13 November 2009 (UTC)

Hey, good point... re-reading. Again, thanks!
— V = I * R (talk to Ω) 16:46, 13 November 2009 (UTC)

Partial implementation

I don't think the entire page needs subpages, however I do think when there is a seriously long threads, like the header and spoilers ones, they should be moved to subpages to save the watchlists of those not interested in them or only interested in them. -- Collectonian (talk · contribs) 22:18, 13 November 2009 (UTC)

Eh... the half implementation compromise solution would only create a mess. It would very likely confuse many, if not most, discussion participants, and it would kind of mess up the archiving. I think that we're stuck with either full implementation or nothing.
— V = I * R (talk to Ω) 05:23, 14 November 2009 (UTC)

I don't think it really would cause any confusion, since the edit link would go to the transcluded pages, the same as now...its done at ANI and the other admin boards now. I don't know how they deal with it with archiving, though. -- Collectonian (talk · contribs) 05:27, 14 November 2009 (UTC)

Well right... the archiving with a sub-page/transclusion system is essentially automatic, since pages are started on a log/<date> sub-page already. If only some are done that way though, then it doesn't really work out. Actually... I'm not really certain how we could manage using sub-pages for only some conversations. Someone would just manually have to create and transclude the sub-page to the appropriate regular VP page. I just think that it would be messy and confusing.
— V = I * R (talk to Ω) 05:44, 14 November 2009 (UTC)

• The way Collectonian suggest we do it is the way it used to work when the village pump had very high traffic. The issue about archiving is also not important for two reasons. As long as the section on the village pump is edited like this or replaced with a link to the new page archival integrity is maintained. That said, way back when we never retained archives of the village pump longer than a week, so it isn't actually that big a deal. I'd suggest splitting discussions off and making them sub-pages of WP:CENT when they grow too big, and just leaving a link to the discussion behind. That's what WP:CENT was created for, in some respects. Hiding T 10:24, 19 November 2009 (UTC)

  I think that this reply actually hits home on the real issue, in my mind. The disparate nature of the discussion forums on Wikipedia is bothersome, to me. WP:CENT is probably a net good kludge, but the fact remains that it's a kludge. The underlying technology of Wikipedia is very good for building encyclopedic content, but the fact is that it's a lousy platform in terms of community participation/discussion. I think that I've come to the conclusion that there is no good solution here, using what currently exists on the platform.
  — V = I * R (talk to Ω) 13:24, 19 November 2009 (UTC)

  The disparate nature bothers me too. I'd support merging most of the noticeboards and other central discussion areas into the village pump, so that we have "village pump (incidents)", "village pump (administrators)", "village pump (edit warring)", "village pump (arbitration)" and so on. That way, it might make future organisation better, and allow sections to split off to (topic) sub-pages rather than /topic, which would perhaps make organisation a little easier and allow continuity of discussion. Hiding T 14:40, 19 November 2009 (UTC)

Transcluded

Well, whatever the merits of this as a general proposal, I've moved the two very long threads we had on this page onto subpages - they seemed to be affecting the usability of the page as a whole. --Kotniski (talk) 11:28, 14 November 2009 (UTC)

I've transcluded the "Abolish the silly headers" sub-page back onto the main page. It was moved to a sub-page due to it's length causing accessibility/performance issues. I'm not positive about the impact (or rather, the lack thereof) of transcluding the content like this. If it's still a problem in terms of accessibility/performance, then please feel free to change it back to a simple link.
— V = I * R (talk to Ω) 13:22, 14 November 2009 (UTC)

Yes, I did that. I guess there must be many people with slow links like my current one - transcluding the content is just as bad as having it on the page.--Kotniski (talk) 13:28, 14 November 2009 (UTC)

I mean, there's the advantage that you don't get the changes showing up on your watchlist if you're not interested in the thread - but many people will see this as a disadvantage, since they won't notice that the page is transcluded, and will think they're watching the conversation when in fact they're not (that's a general disadvantage of transclusion, I think, and means it should only be used on pages where transclusion is the norm). With huge threads like this one, we just want them off the page so that other people can continue to use it for other things.--Kotniski (talk) 13:32, 14 November 2009 (UTC)

OK. Like I said, I wasn't sure, so it's good to know. I do agree with the other points that you've made, incidentally.
— V = I * R (talk to Ω) 13:46, 14 November 2009 (UTC)

Yeah, for something like ANI where you have a LOT of threads, and most of them are very specific to a few people, it makes sense, but here were you often want as many peoples' input as possible, it's best to just have a single page to watch. ♫ Melodia Chaconne ♫ (talk) 15:13, 14 November 2009 (UTC)

I moved this here off of the talk page, since it seems that we're talking about the wider use of su-pages and transclusion now. Personally I don't buy that view that sub-pages somehow limit wider participation. If there's anything to really support that viewpoint other then speculation I'd really like to hear about it. Interestingly to me though is that I've seen the opposite argument made as well, that sub-pages allow too much participation. I don't think that it really makes a difference myself, but I do think that sub-pages make managing the different threads easier, and it certainly makes linking to and tracking individual discussions much easier.
— V = I * R (talk to Ω) 16:10, 14 November 2009 (UTC)

Change archival methodology

What about changing the archival methodology used across the Village Pump? I can envision a system where all discussions are begun on the main Wikipedia:Village Pump page and then aggressively archived to sub-pages. The existing bots can relatively easily archive discussions to sub-pages which create dynamic page names.
— V = I * R (talk to Ω) 14:31, 19 November 2009 (UTC)

When a new(ish) user creates an article, default to preview and show WP:LUC

Some of the problems that wikipedia creates for people in "real life" emerge from the fact that so many people come here to write articles about themselves without having a clue how this place works. Crappy autobiographies (or articles on companies) then get taken in hand by experienced editors, and sometimes the result is real distress. If the person or company isn't notable, the article can get deleted, but it takes time to make that happen. The incidence of these situations might be reduced if new users who create a new article have to see a preview screen that shows WP:LUC before they can finally save/create the article. As things stand, WP:LUC is entirely ineffectual: there is no way a new user is going to see it.

This is my first post at the pump; I don't see this one at Perennial Proposals, but please feel free to set me straight if I'm not doing this correctly. Nomoskedasticity (talk) 17:15, 15 November 2009 (UTC)

This is literally earlier on this page already. Check #Force preview before saving for new users. --Golbez (talk) 17:17, 15 November 2009 (UTC)

I did see that. I trust it's clear that what I'm proposing is different, in its application only to creating new articles. Nomoskedasticity (talk) 17:22, 15 November 2009 (UTC)

Sounds like a good idea to me. Applying this to all non-autoconfirmed users might help. Fences&Windows 17:50, 15 November 2009 (UTC)

Can anyone guess my position on this? Are we up to 7 of these "restrict IP/Newby" proposals now in two months? I've lost count. Please, next time someone has this idea- think about how you would feel if a bunch of editors kept proposing to limit your ability to edit/create/move/etc! Would you like it? If you think you are more "reliable" or a "better" editor than an IP or newbie, what gives you that idea? We are all equal unless as an individual we show we are not reliable. Assume good faith. Trying to limit an entire group of editors is wrong.Camelbinky (talk) 21:30, 15 November 2009 (UTC)

Who said restrict? I said: offer some helpful information they're not going to get otherwise. Nomoskedasticity (talk) 21:49, 15 November 2009 (UTC)

"Forcing" is the same as restricting in my eyes if the "forcing" is done only to those in a certain group (newbies or IPs). Wikipedians learn by doing, you do not need to read a "rulebook" before editing. Yes, newbies might make a bad article or a non-notable one; itll get deleted, and they'll get contacted on their talk page; hopefully the learn. In no way should anyone have to read a single policy/guideline prior to editing. It is in fact specifically stated in many places that ignorance and violation of policies or procedures does not negate a good faith edit (or a proposal or creation of a new template or wikiproject, etc).Camelbinky (talk) 22:16, 15 November 2009 (UTC)

Wikipedia's approach at the moment is like putting a big sign on the front door of the sweetshop next to the school "Come And Take One"... "Slap! Not that one, you eejit, it says so in the terms and conditions on our website". That's how newbies often end up getting treated, because they're not given enough information up front, nor enough indication that they really need to take certain information on board which is available buried somewhere in often not terribly newbie-understandable terms. In a perfect world, there'd be a handholding clueful, nice editor with lots of time ready to deal with each newbie edit appropriately. Can't see that happening any time soon, so exploring other solutions is absolutely a sensible thing to do. Rd232 ^talk 22:59, 15 November 2009 (UTC)

(edit conflict)WP:LUC is at best a restatement of the text underneath the edit box. At worst, it can be largely irrelevant and WP:BITEy. Any editor shown that page who doesn't feel they have a COI could reasonably be assumed to take offense. ~ Amory (u • t • c) 22:17, 15 November 2009 (UTC)

If the problem is them writing about themselves or putting in links about the company they work for then I'd support having a warning about common problems put on IPs edit pages. LUC does not seem a particularly helpful bit of text and it is far too long. You want something that is very short and shows the basic sort of things to avoid assuming they are editing in good faith. Dmcq (talk) 12:15, 16 November 2009 (UTC)

The proposed solution to this problem—defaulting to preview—will have zero effect, except possibly to annoy good faith new contributors. If this problem actually needs a policy solution, then a better approach would be to modify the default Editnotice that IPs and new users see to include something about this. 72.95.238.235 (talk) 16:16, 16 November 2009 (UTC)

Perhaps a softer approach would work:

Add a few questions that must be answered before non-autoconfirmed people can create articles:

• Is this article about you, someone you know, or a company, place, school, organization, or other thing you are part of? _[yes] _[no] [show/hide link labeled "explain this"]
• Is this article entirely in your own words, and is it referenced clearly enough that people won't think you are making it up? _[yes] _[no] [show/hide link labeled "explain this"]
• Is this article ready for publication or do you want to save it as your user name:article name and come back to it later? _[yes] _[no] [show/hide link labeled "explain this"]

This first question's "explain" text would include links to WP:LUC, WP:BLP, WP:COI, etc. The second would link to WP:COPYVIO. The last's would link to an explaination of user space.

Depending on what the user checked, automated messages with more details would be put on his user talk page. If he checked the last one, the article would be renamed user talk:USERNAME/ARTICLENAME before being saved, and instructions to move it added to the user talk page. davidwr/(talk)/(contribs)/(e-mail) 02:27, 18 November 2009 (UTC)

I think it is better to warn people before they write anything than to get to a preview and then warn them. Dmcq (talk) 12:37, 19 November 2009 (UTC)

Educational game idea

Hi,

I am a huge fan of Wikipedia and have an idea for a game which might be of interest to you to use on your site. The format is very simple and involves the player choosing a start page within Wikipedia (for instance 'HAIR'), then trying to navigate to a finish page in as few moves as possible (lets say 'MILK'). The player is only allowed to use word/subject links within Wikipedia.

So, using the example above starting on the 'HAIR' page you could navigate through 'WOOL', 'SHEEP', 'DAIRY', and finally to 'MILK' (the score is 4 moves). The number of pages navigated through could be automatically calculated by using cookies to trace the path taken.

I think it could help promote Wikipedia by marketing the game as a fun educational tool! Also, if it is placed in the sidebar it is a simple enough format which would not slow down your site. Or it could even have a page of its own?

Thanks for taking the time to read my idea. I'd love to hear if you think it is a good one or not!

Regards,

Graham

Have a look at WP:SDOWP, WP:Wiki Game, WP:Wikington Crescent, and WP:Wikirace. Algebraist 20:29, 18 November 2009 (UTC)

Wikispeedia SunCreator (talk) 14:30, 19 November 2009 (UTC)

Proposed change to MediaWiki:Welcomecreation

Please consider and comment on the proposal I made here. Regards SoWhy 12:46, 19 November 2009 (UTC)

Lift the 1RR on Cluebot

Hello Wikipedia Community,

I have been thinking about all the time that fine editors spend combating vandalism, that they could instead be using for other things. I have also been noticing how good Cluebot is at finding various types of vandalism by itself. Now, as many of you know, Cluebot adheres to the 1 Revert Rule. That means:

This bot will not revert the same article and user more than once per day. There is one exception: This bot will revert today's featured article or any page listed in the opt-in list for angry mode as many times as it finds vandalism. The bot will not revert to itself or one of its friends (MartinBot/VoABot II).

I wanted to see how many editors here would be willing to lift/revise this rule as Cluebot has definitely proven itself (almost a Million Edits). I would love to see this wonderful bot allow users to spend their valuable time doing things other then hitting the revert button when a 12 year old decides to copy and paste "penis" 100 times on a page.
--Tim1357-(what?...ohhh) 02:02, 24 October 2009 (UTC)

It's not the number of edits that would prove its worth, but the accuracy. 1RR is probably to allow editors to correct false-positives. That said, I've never actually seen it make a mistake. Equazcion (talk) 02:09, 24 October 2009 (UTC)

Exactly, Ive never seen it make a mistake either!Tim1357-(what?...ohhh) 02:28, 24 October 2009 (UTC)

I'd support it on a trial basis, until more is known about what it could do. Kevin Rutherford (talk) 03:40, 24 October 2009 (UTC)

• I'm not taking a position at this time, but rather just explaining why it has a 1RR... If a human reverts something they think is vandalism and and they are undone, the person might re-evaluate their choice and come to a different decision. A bot, however, will always reach the same conclusion. --ThaddeusB (talk) 03:48, 24 October 2009 (UTC)

This might be reasonable, but a dry run should be done first. The bot would post to a page each diff that it would revert, but didn't due to the 1RR rule. The main issue with this is that the damage caused by an error can't be simply repaired by reverting the bot, as there's WP:BITE issues to deal with as well. One possible way of dealing with the issue ThaddeusB notes would be to give second or later reverts a higher vandalism score so that borderline cases wouldn't be picked up as vandalism the second time. Mr.Z-man 17:08, 24 October 2009 (UTC)

Wow, why didn't I think of that? Only edits that it is SURE are vandalism (i.e. have a very high 'score') would be reverted. And one other thing, despite repeated attempts, I cannot seem to get ahold of cobi to tell him about this, someone needs to do that. Tim1357--(what?...ohhh) 17:42, 24 October 2009 (UTC)

Z-man's approach sounds reasonable, as a toe in the water: let's see how many false positives there are. Incidentally, does the bot take page visibility into account? Rd232 ^talk 20:12, 25 October 2009 (UTC)

So how do I move forward with this? Tim1357 (talk) 21:51, 27 October 2009 (UTC)

User talk:ClueBot Commons, I think. Rd232 ^talk 11:27, 28 October 2009 (UTC)

Agree with Z-man, let's see if there is a problem here that needs solving before taking the handcuffs off. –xeno^talk 14:36, 28 October 2009 (UTC)

Seconded. Is there actually a problem that this proposal solves, or is it merely a solution in search of a problem? Shereth 15:27, 28 October 2009 (UTC)

Not sure what you're getting at. The proposed trial - listing (a random sample of) reverts Cluebot doesn't do due to 1RR restriction - will tell us to what extent the 1RR restriction limits Cluebot's effectiveness, and whether the restriction could be relaxed in some way to enhance effectiveness. I can't see how else you would know. Rd232 ^talk 15:50, 28 October 2009 (UTC)

Both of us simply agreed that having this listing is a necessary first step before lifting the restriction. –xeno^talk 15:53, 28 October 2009 (UTC)

OK. Textual communication, eh. Rd232 ^talk 16:20, 28 October 2009 (UTC)

This is kind of after-the-fact, but as long as cluebot continues to follow the "never revert to myself" rule, I can't see lifting the 1RR having a negative effect. --King Öomie 17:01, 28 October 2009 (UTC)

True, I think. But doesn't it also mean lifting 1RR won't have any positive effect? Well maybe not, but it certainly limits it. That would be another area worth exploring - how many cluebot edits are foregone due to that rule, and what do they look like, and how many false positives. Rd232 ^talk 17:09, 28 October 2009 (UTC)

As a small, unscientific sample, I took a look at ten consecutive ClueBot edits from a month ago. None of them were reverted so I doubt that 1RR makes much of a difference one way or another and it seems to me better to allow humans to override the machine rather than the other way around. A bigger problem is that ClueBot would undo a vandal and the vandal would then immediately go in and make a completely different vandalism edit on the same article which would then often have to be reverted by a human. Perhaps instead of changing the 1RR rule there should be a cooldown rule to block an anonymous user whose edit was reverted from making a change to the same page for 15 min. Users who really are trying to make constructive edits will probably be annoyed but willing to wait a short period of time before trying again but I think a vandal won't have the patience.--RDBury (talk) 17:02, 29 October 2009 (UTC)

That sounds improvable - I'd say Cluebot could treat 1RR as meaning it won't revert the same change twice in one day, by the same user on the same article. Different changes by the same user should be caught equally. How many false positives for that? ... Incidentally, where's the bot creator/owner? Does he know about this discussion? Rd232 ^talk 17:19, 29 October 2009 (UTC)

Well, that would require Cluebot to keep a running database of every change it reverts every day, and then compare every edit it scores against every one of those changes. At the end of the day, I think Cluebot would be running QUITE slowly. --King Öomie 15:44, 19 November 2009 (UTC)

(unindent)To follow up, I did another survey on 30 consecutive ClueBot edits (not including any of the previous sample. 28 of the reverted edits were from anonymous users. Of those, 7 users made follow-up vandalism edits on the same page, i.e. within a short time of making the original vandalism edit. Some of these made repeated edits for a total 10 follow-up vandalism edits. Of these 10, 9 were reverted by a human and 1 was reverted by a different bot. To respond to rd232, there wouldn't have been any false positives for his proposed rule in thie sampled edits. But I should note that while none of ClueBot's edits in the sample were reverted, some of the follow-up vandalism was very close to the original vandalism.--RDBury (talk) 18:02, 29 October 2009 (UTC)

PS. I left a note on User:Cobi's talk page.--RDBury (talk) 18:11, 29 October 2009 (UTC)

Another followup, just to cover all the bases I looked at the 3 reports on ClueBot's false positives page. It appears then the users making the edits did the edit over rather than reverting Cluebot's revert. In all cases while the edits weren't vandalism, they were controversial and aggressive and usually re-reverted by a human. Maybe there should be a some instruction to direct users to try suggesting the change on the article's talk page instead of re-doing the edit.--RDBury (talk) 18:38, 29 October 2009 (UTC)

Response by Cobi

After going over this discussion, I see a few suggestions here:

• Make the unreverted caught vandalism public for further review. This will be trivial to do.
• Turn 1RR off (turn the bot into angry mode).
• Interpret 1RR to mean 1 revert per user per specific edit data per article per day. This means I have to store the edit data for the day. This can get large in RAM.
• Add a cooldown. This needs to be done with MediaWiki, not ClueBot.

I'll create a page shortly for ClueBot to post unreverted caught vandalism to. -- Cobi^(t|c|b) 19:17, 29 October 2009 (UTC)

The bot will create a page at User:ClueBot/PossibleVandalism when it first has an unreverted caught vandalism. -- Cobi^(t|c|b) 19:32, 29 October 2009 (UTC)

Score 1 a bunch for the bot so far... Can you tell it to log new entries on a new line rather than blowing out the old ones? –xeno^talk 20:49, 29 October 2009 (UTC)

Second that - maybe with a limit of some kind to prevent the page bloating unmanageably. Rd232 ^talk 20:52, 29 October 2009 (UTC)

Could you have it so the bot doesn't clear the contents of the page whenever it adds new ignored vandalism.? That way we could see just how much vandalism is not reverted because of the 1RR. It would be nice to see how long that page gets after a week. Tim1357 (talk) 21:55, 29 October 2009 (UTC)

The Possible Vandalism log is a good start. You say "Interpret 1RR to mean 1 revert per user per specific edit data per article per day. This means I have to store the edit data for the day." I had imagined you could compare a user's edit with any prior edits they made that day; is that too computationally or bandwidth-wise intensive? Also, is Cluebot's user warning message (this one) editable? I think it may be improvable. Rd232 ^talk 20:17, 29 October 2009 (UTC)

Special:Prefixindex/User:ClueBot/Warning -- Cobi^(t|c|b) 20:29, 29 October 2009 (UTC)

Cool. Is that linked from the bot page? I did look there. Anyway, I've proposed a revision at User talk:ClueBot/Warnings/Vandal1. Rd232 ^talk 20:47, 29 October 2009 (UTC)

It appears that the 1RR makes the bot miss an average of 130 vandalism's a day. Tim1357 (talk) 19:59, 31 October 2009 (UTC)

Just curious, have there been any developments on this? Equazcion (talk) 08:05, 8 Nov 2009 (UTC)

Where do we go from here? The BRFA? Or do we just let it die? Tim1357 (talk) 01:36, 16 November 2009 (UTC)

The BRFA indicated it would stick to 1RR, so a new BRFA lifting the restriction would be ideal. Alternatively, an informal note at WT:BRFA asking a BAG member to simply rubberstamp may be adequate. –xeno^talk 15:49, 19 November 2009 (UTC)

I don't think rubber stamping this proposal is a good idea. Community members don't like being reverted by bots. I see that this is not going to revert the same editor twice, but I'd like a full discussion on the issue. --IP69.226.103.13 (talk) 19:37, 19 November 2009 (UTC)

Can you point out a diff where the bot reverted a community member, as opposed to a mere vandal? –xeno^talk 14:54, 20 November 2009 (UTC)

Proposal for Debate Pages/Debate Wiki

I was recently on Conservapedia, and I noticed that they have a very cool section called "Debates." They have moderated debates on that site, and knowing how many contributors there are to Wikipedia and its sister projects, some interesting debates could be had on this site. Granted, it could degenerate into some nightmare-ish version of a "Youtube" comments section, but if it worked, it could be very interesting and entertaining.

I'm thinking that the debates should be reserved for members of Wikipedia, but it would be interesting to hear from non-Wikipedia people as well.

As for what the debates section would be on this site (a separate Wiki, perhaps?), I leave you to decide.

Thank you very much for your time and consideration.

Sean 0000001 (talk) 07:01, 20 November 2009 (UTC)

I forgot to say that I'm fairly new to Wikipedia, so I don't know whether you need to take that into account when considering my proposal.

Sean 0000001 (talk) 07:03, 20 November 2009 (UTC)

Wikipedia is an encyclopedia / reference work, not a debate club (though I admit it can be hard to tell sometimes). You can propose that Wikimedia, Wikipedia's parent organization, undertake new sorts of wiki's by making a proposal on Meta-Wiki (this is how Wikinews, Wiktionary, etc. got started); your idea is particularly similar to Wikireason, so you could go and register your support for that proposal. --Cybercobra (talk) 08:20, 20 November 2009 (UTC)

Redesigning the citation errors

I posted this on VP:T, but after it was pointed out that it could be better here, I've decided to redo this, but with a change of plan.

Right now the "errors" are a bit scary looking and don't fit within our system of cleanup tags and such, so I think that for the citation errors that occur inline, we'd do it with the {{fix}} template styled messages, like say or . Of course we could maybe change the colors to be a tad more noticeable or something but still.

Some situations may be better explained using more "cleanup tag" styled messages, like say:

Of course this would be placed at the bottom of the page, but anyway, get the picture? ViperSnake151  Talk  19:29, 12 November 2009 (UTC)

Looks good to me, would be better then my eyes burning everytime I forget to add a reflist.--SKATER ^Speak. 19:37, 12 November 2009 (UTC)

I don't think this last part is currently possible. The current message is "Cite error: There are <ref> tags on this page, but the references will not show without a <references/> tag"; it is generated by MediaWiki:Cite error refs without references. That MediaWiki message does not support wikimarkup, nor do two other messages; see Template:Bug. Wikilinks and the like look good on the MediaWiki page, but don't transclude properly. We might be able to do this if it uses only HTML, but we will have to test this somewhere. Most of the inline errors look doable. ---— Gadget850 (Ed) ^talk 19:41, 12 November 2009 (UTC)

When I'm less busy, someone should remind me to fix that. Dragons flight (talk) 21:46, 12 November 2009 (UTC)

• Please don't change it. I know that I would probably ignore a template like the one listed, and I suspect many other editors would as well. I would prefer that calling the ref hook added a reference list at the bottom of the page automatically, but that probably won't happen anytime soon. Protonk (talk) 21:37, 12 November 2009 (UTC)

You'd add a banner and 40 words that interfere with reading the article instead of adding a {{reflist}} to an article? Why? --IP69.226.103.13 (talk) 21:48, 12 November 2009 (UTC)

I agree, the whole point of the big red error is that its saying "This is really broken, fix it now." The ambox version loses too much of the sense of urgency by lumping together an actual problem that's typically trivial to fix with more general cleanup issues. Mr.Z-man 23:22, 12 November 2009 (UTC)

The technical issues are one thing, but this argument really gives me pause... there was something about the first proposal that seemed more palatable, for some reason.
— V = I * R (talk to Ω) 05:00, 13 November 2009 (UTC)

Because cite.php wraps error messages in the error class, thus the references will be bold and red. Have to play to see if this can be overridden. I remember fooling with this and it wasn't pretty, but I don't remember the details. I'm not against improving the messages, just pointing out the technical issues, especially since I have had my head in those error messages a lot here lately.

While we are at this, I want to see if the British English versions of the messages can be redirected to the English versions. If a user has British English set as their language, then they see the default cite error messages (along with every other MediaWiki message). ---— Gadget850 (Ed) ^talk 23:27, 12 November 2009 (UTC)

OK- ran this on http://test.wikipedia.org. You have to escape the brackets and use an external link:

{{ambox
|type=style
|text=This page contains references, but it '''does not contain a references list''', which is required in order to show the references.<br /> One can be added by adding <code>{{reflist}}</code> under a "References" heading. For more information, see <span class="plainlinks">[http://en.wikipedia.org/wiki/Wikipedia:Citation_templates Wikipedia:Citation templates]</span>.}}

---— Gadget850 (Ed) ^talk 01:58, 13 November 2009 (UTC)

Stupid question:If we can automatically introduce a banner, can't we also automatically include the references section? --Stephan Schulz (talk) 12:35, 13 November 2009 (UTC)

LOL! Great question! Here's an obvious answer: "of course!" :) i guess that the question should then be: "should we automatically include a 'references' section?" Personally... I'm leaning heavily towards "yes", now that you bring the question up.
— V = I * R (talk to Ω) 15:43, 13 November 2009 (UTC)

I checked it on the test wiki and it will work— we will have to figure out how to suppress the error class that makes the whole references section bold red, but we can probably add something to {{reflist}}. ---— Gadget850 (Ed) ^talk 17:47, 13 November 2009 (UTC)

IMO, we should still include an error message and tracking category of some sort because quite often the very bottom of the article is not the recommended place for the references section, and we want to make it easy for WikiGnomes to find the problem articles. As for "suppressing" the error class, it may be as simple as putting "</strong>" at the start of the error message (and "<strong>" at the end). Anomie⚔ 18:04, 13 November 2009 (UTC)

My original idea for this was to use fmbox instead so it'd be a bit more, noticable.

Since the category box appears in a similar style, this would look a bit more "flush" into the footer and look a bit more fitting than just jamming an {{ambox}} down there. ViperSnake151  Talk  19:05, 13 November 2009 (UTC)

Wikipedia:Citation templates doesn't really help here. I would add a section to Help:Footnotes on how to add and style the reference list. I also recommend setting type=warning so that the message is highly visible. I know some just hate red error messages, but a missing reference list is egregious. ---— Gadget850 (Ed) ^talk 12:49, 14 November 2009 (UTC)

Here is what the message would look like with the warning style:

As to styling the inline errors like {{fix}}: fix and similar templates are really for content issues. Cite errors are an immediate technical problem. For example: "Cite error: Closing </ref> missing for <ref> tag" is caused by not closing the <ref>...</ref> tags, and it can eat huge chunks of the content. Making this look innocuous is not a good idea. ---— Gadget850 (Ed) ^talk 14:32, 14 November 2009 (UTC)

That looks even more scary than the current one. Why we can't add kinda an "orange" colored level for fmbox to use for stuff like this, I don't want to know. And I meant as in "sorta" like {{fix}}, but maybe in a slightly larger font (like this?) ViperSnake151  Talk  19:33, 14 November 2009 (UTC)

Well, everyone has a fairly good point that these messages probably should be somewhat "scary looking". These sorts of citation errors should scream at you, in order to get them fixed immediately. If the editor who created the problem doesn't know how to fix the problem, or is actually scared by it, then at least the next editor who comes along will fix it (and possibly the originating editor will ask for help). I like the idea of making them cleaner looking personally, but I'm not really supportive of making them "nice".
— V = I * R (talk to Ω) 19:40, 14 November 2009 (UTC)

Exactly. Content issues marked with templates like {{fact}} or {{unreferenced}} are notices; there are articles that have been tagged like this for years. They do their job by alerting readers that there are content or style issues. Cite errors deserve warnings and links to help pages because they can hide content and references. We have several editors who specifically work cite errors, so these messages should not stick around for long. ---— Gadget850 (Ed) ^talk 19:59, 14 November 2009 (UTC)

I completely agree with the previous two editors. Ergo, no need for banners. Especially since we are talking about messages that are being added via MediaWiki, and should not be added manually at all. Which makes for a sounding "against". Debresser (talk) 20:03, 14 November 2009 (UTC)

Well, I do think that it might be nice to make them look "prettier". It's hardly a pressing concern, in my view, but the plain text error message looks kind of... "ghetto".
— V = I * R (talk to Ω) 20:07, 14 November 2009 (UTC)

Please don't use {{fmbox}}, that's not what it's for at all. You're essentially saying "people see so many amboxes that they're getting banner blindness to them". The solution to that is most definitely not to introduce banner blindness in another set of warning box styles. We have three levels of ambox warning templates because some warnings are "more important" than others. No warning is objectively more important than the ambox series provides for. Are you really trying to say that a missing <references /> tag is more important than a CSD nomination? Reality check, please. Leafing through the collection of template styles until you find one that appears 'suitably scary' completely defeats the point of having a standardised set of warning styles in the first place. Why did you pick {{fmbox}} instead of {{cmbox}}?? That has some similarly-scary warning styles. But the "category message box" is intuitively and obviously not intended for the article namespace. Fmbox is absolutely no different, it is used for interface messages (the ones that appear around the edit screen and on special pages), not for content. Happy‑melon 23:35, 14 November 2009 (UTC)

Missing reference list

Current error message:

Using {{ambox}} styled for content issues:

Regardless of the style, we do need a better message than the cryptic current message. ---— Gadget850 (Ed) ^talk 14:54, 16 November 2009 (UTC)

Wouldn't it just be far simpler for someone to run a bot which finds these defective pages & adds {{reflist}} at the bottom? The hardest part of this would appear to be writing the query that would compile a list of these pages; the rest could be done by someone with AWB or Huggle, without any special skills. -- llywrch (talk) 20:49, 19 November 2009 (UTC)

Actually, that part is quite easy: the error message populates Category:Pages with missing references list. The reason I haven't added this to AnomieBOT yet is because I haven't felt like figuring out all the myriad variations on the standard naming and ordering of these end-of-article sections. Maybe I'll take a look later on. Suggestions and caveats are welcome. Anomie⚔ 22:15, 19 November 2009 (UTC)

Don't forget to look at WP:LAYOUT as well. I'm not sure which document is more relevant (although I personally tend to give much more weight to non-MOS documents, honestly), but both certainly exist. I thought about doing something along these lines myself, but this is the issue that essentially stalled my development (and "stalled" here is intentional, note that I didn't say "stopped"). Unless I'm missing something obvious, my conclusion is that I need to essentially develop an AI... which is something that I'm slowly in the process of doing. I like AI development anyway though, so I may be self selecting here. :)
— V = I * R (talk to Ω) 22:47, 19 November 2009 (UTC)

MOS:APPENDIX is a redirect to WP:LAYOUT#Standard appendices and footers ;) Thanks though. Anomie⚔ 22:53, 19 November 2009 (UTC)

er...oops.
— V = I * R (talk to Ω) 23:00, 19 November 2009 (UTC)

I am strongly against adding another message box. An error message is just that, and shoud not be mistaken for a maintenance template. Furthermore, I see no consensus in the section above to make such far-reaching changes, rather to the contrary, so I don't understand why this subsection was started in the first place. Debresser (talk) 16:05, 21 November 2009 (UTC)

The current message is not informative. I linked Cite error, but I suspect it is being overlooked. ---— Gadget850 (Ed) ^talk 16:56, 21 November 2009 (UTC)

Better idea

If you think "scaring" users on the page itself is not a good idea, why not configure the edit filter to be able to detect these things and display a suitable message? ViperSnake151  Talk  00:07, 15 November 2009 (UTC)

Is there a Special page or category or something to list pages in this error state? Pseudomonas_(talk) 10:43, 17 November 2009 (UTC)

There is Category:Pages with missing references list and Category:Pages with incorrect ref formatting. Which, incidentally, are rather shockingly large right now!
— V = I * R (talk to Ω) 19:28, 21 November 2009 (UTC)

Adding a missing list

One can modify the missing <references> error message to actually add a references list. It would be at the end of the page, but might be better than nothing. Dragons flight (talk) 15:17, 16 November 2009 (UTC)

Seems like the way to go. To me.

Wikipedia messages seem never to be in least declarative sentences:

"The references will not show unless you add a {{reflist}} or <nowki></nowiki> to this article."

Still, a bot that adds one is better, imo. --IP69.226.103.13 (talk) 02:12, 18 November 2009 (UTC)

I don't mind which of those two options are chosen. Doing it with an ambox is definitely not right though. Chris Cunningham (not at work) - talk 20:23, 19 November 2009 (UTC)

Proposal to include disambiguation tag for new biographies in Wikipedia

Given the number of biographical articles in Wikipedia, inevitably, there will be many articles on people who may share a name. I recently started an article on the priest who wrote to Jung, Father Victor White; it erroneously got merged with an article on a pilot who was also called Victor White. Fortunately, some one was quick to disentangle the two articles. If we do a "search" on Wikipedia and find some one shares a name with the subject of a biographical article, do we need a tag to the effect of "Disambiguation possibly needed" heading some articles? ACEOREVIVED (talk) 00:19, 21 November 2009 (UTC)

I'm not sure what you are saying exactly. We already have a system of disambiguation in place using parenthesis and hat notes. E.g. Victor White (priest) with a note on Victor White that says "For the priest see Victor White (priest). --ThaddeusB (talk) 01:49, 21 November 2009 (UTC)

I think the suggestion is that we have a "needs disambiguating" cleanup tag along the lines of "unreferenced" or "please copyedit" - am I correct on this? Pseudomonas_(talk) 10:06, 21 November 2009 (UTC)

I think we sort of already have that with {{confuse}}. As a general rule if there are two or more other articles to avoid confusing something with a disambiguation page is appropriate. ϢereSpielChequers 11:07, 21 November 2009 (UTC)

Thank you - I think you are right, the template you see seems appropriate, provided that people are prepared to use it. ACEOREVIVED (talk) 00:20, 22 November 2009 (UTC)

I assure you it's quite widely used; it is also known as {{distinguish}}. --Cybercobra (talk) 03:41, 22 November 2009 (UTC)

Stats on skins/gadgets/preferences

I'd quite like to be able to see some aggregate (no personal details necessary) stats on how many new or active editors have different gadgets/preferences/customized signatures/alternative skins? I'm thinking about usability and help/guidelines, and it'd be nice to know what people are likely to be (so, for instance, whether it's generally worth referring to the possibility that their "new section" button might be spelt "+", as mine is). It'd be useful to have a way of assessing whether people generally fiddle with these things immediately on creating an account, or only after they Know It All anyway - has this been done? Pseudomonas_(talk) 11:41, 21 November 2009 (UTC)

See mediazilla:19288 "Gadget usage statistics" which mentions translatewiki:Special:UserOptionStats. So in theory this is already possible with User Option Statistics Extension, which is not installed on Wikipedia (all we have is Special:PrefStats for 3 "beta" parameters). — AlexSm 14:59, 21 November 2009 (UTC)

Remove ellipsis character from editing help section

The ellipsis character (…) is included in the Editing Help section below the Save Page/Show Preview/Show Changes buttons on the edit screen. However, per WP:ELLIPSIS, the ellipsis character is not recommended while the simple three-unspaced-periods solution is preferred (...). Since the ellipsis character is not recommended, I think it should be removed from the list of special characters on the editing screen. It makes no since to make it easier to insert a non-recommended character.—NMajdan•talk 23:22, 21 November 2009 (UTC)

I agree and have removed it. However see MediaWiki_talk:Edittools#Ellipsis for possible objections. --ThaddeusB (talk) 02:47, 22 November 2009 (UTC)

SPOILER ALERT disclaimers

Very long thread; copied to /Spoilers.

Edits by anonymous users

After some 60, 70 edits in the article Dodo the progress has been aproximatly zero. Isn't it time to stop allowing anonymous users making edits in Wikipedia articles? Jan Arkesteijn (talk) 00:53, 7 November 2009 (UTC)

No, no, no, no. We've been through at least three different proposals already in the last two months about restricting IPs and newbies. When will it end? What is the point in getting ride of IPs? Why is everyone so intent on keeping out new blood? Why not put on the main page- we have all the editors we need, dont bother editing unless you want to be one of us". (reference to an old horror movie "Freaks") No more IP or newbie bashing around here ok?Camelbinky (talk) 01:21, 7 November 2009 (UTC)

That was rather harsh (and ironic) considering by most measures Jan is also a newbie.

Jan, please see this link explaining why this perennial proposal is unliekly to ever be adopted. --ThaddeusB (talk) 01:25, 7 November 2009 (UTC)

The other responses notwithstanding, we do semi-protect articles which are frequent or ongoing targets of anonymous vandalism. TenOfAllTrades(talk) 01:41, 7 November 2009 (UTC)

Well, considering the fact that of the 5 effective improvements in that list only one was made by an anonymous IP (which sheds a doubt on the 82% mentioned here) this article applies for an everlasting state of semi-protection. All the edits minus one were with the benefit of hindsight vandalisms and subsequent corrections. Eventually people will get tired of reverting vandalism and will stop doing so. There are articles on the outskirts of Wikipedia, where barely anyone goes. The information presented there is by the nature of Wikipedia unreliable. The motto of Wikipedia is to feel free and improve. This means, we should improve Wikipedia itself also, by safeguarding against the presentation of mis-information. A "No, no, no, no" will not suffice. Jan Arkesteijn (talk) 11:11, 7 November 2009 (UTC)

Camelbinsky, well do I remember how you responded when, I think it was in September this year, just this very idea was put forth.

I hardly think I need to repeat that my own policy was we need to remember Wikipedia: Please do not bite the newcomers, and should not put new editors off who may still have to learn to set up userpages. A common response when this proposal was made before was why did the initiator of the proposal not check the "perennial proposals" - I rather think that if this proposal is made again, it should be sent to the "perennial proposals list" (sorry, I need an administrator to help me here!) ACEOREVIVED (talk) 19:48, 9 November 2009 (UTC)

Above it is claimed that requiring registration would "keep out new blood" by deterring new users. But the rationale at WP:Perennial proposals#Editing is that registration would not deter vandals because it take them only "10 seconds to register". Whoa, wait a minute, which way is it going to be? Does registration deter, or not? This is argument based on perception, and that it is being swung both ways brings its validity into question. For all that everyone here may have an opinion about this, I have yet to see any solid data.

Similarly for the implied argument that registration would simply eliminate the "76% or 82% of anonymous edits [which] are intended to improve the encyclopedia". The implicit assumption is that in such cases anonymity is an absolute requirement, without which these editors (and editing) will simply disappear. Again, we really have no data about that, but I rather doubt that taking "10 seconds to register" would deter serious editors. (See also WP:Editors should be logged in users.) - J. Johnson (JJ) (talk) 23:42, 9 November 2009 (UTC)

Well, its a good thing that policy on Wikipedia is determined through consensus of the Community and not consensus of facts and figures. So really, I dont see why some want or need to see any solid data. If the majority of us figure it probably isnt a smart idea (and I'm confident the majority does not want to force everyone to sign up) then it isnt going to happen and it doesnt matter how much data you have to support your idea that forcing them to sign up would be beneficial to Wikipedia. Some things, like these perennial "Wikipedia Patriot Act" ideas to eliminate vandalism by controlling IPs and newbies arent acceptable due to their loss of our core ideas of being open and freedom of editing and equality for all. Whats next, IPs and newbies cant comment on Village Pump, AN/I, noticeboards, article talk pages?Camelbinky (talk) 00:07, 10 November 2009 (UTC)

It may not deter "serious editors", but most serious editors already create accounts. The issue is that it would deter casual editors - people who might add some info or correct an error in what they read, but won't go out of their way looking for things to edit. Mr.Z-man 01:01, 10 November 2009 (UTC)

Mr Z, as usual, hit the nail on the head. Most of the IP editing I see are from IPs correct my poor spelling or grammar, and I assume but of course cant verify that they are doing so because they happened to be looking up something, saw the misspelling and corrected it, not because they are hardcore Wikipedia fanatics on a mission. Many seem to think that if your not a fanatic and not signing up you must be a vandal. Some just like to edit as they find things when reading things they are looking up, why force them to sign up or make it uncomfortable for them so they feel forced; we become a less effective source for the casual reader. And let us remember- the casual reader, our audience, is why we do this endeavor; we write for them, not for each other or for ourselves, in a way they are our boss. We should strive to function as they need us, and not attempt to convert them into editors or to force readers to understand our backroom bureaucracy (and despite resistance by myself and others, bureaucracy is what we have, unfortunately).Camelbinky (talk) 03:40, 10 November 2009 (UTC)

I am inclined to agree with Camelbinky's last comment. Some of us, such as those who have signed our names above, are happy to be logged-in editors - but there may be casual Wikipedians who only visit Wikipedia sporadically, who think they may have a go at editing and who have no intention of setting up a userpage. And why should they? That is up to them. To insist in edits from only logged-in editors would be a little like saying, in a parliamentary democracy, only members of politcal parties should have a right to vote. Each to one's own, some may be interested enough in Wikipedia to set up a userpage; others may have other pressing interests and not wish to do this. ACEOREVIVED (talk) 21:02, 11 November 2009 (UTC)

I really don't have any opposition to "casual editing" as such. But I am rather irked at the invalid argumentation used here. Particularly this argument that registration (eek! scream! there's that nasty word again!) is both a massive deterrent to casual editors, and, simultaneously, a negligible deterrent to vandals. Unless someone wants to explicate how that can be (I could, but I leave that as an exercise for the reader) you're arguing a contradiction, which is usually an indication of error. Of course, perhaps that doesn't matter if there is consensus ("burn the witches!") that false and invalid argumentation is perfectly acceptable. I had rather hoped that the expected level of argument would rise at least to the level expected of articles, but so be it. - J. Johnson (JJ) (talk) 23:51, 16 November 2009 (UTC)

I have been thinking about J.Johnson's comments - and thank you, you gave me something to think about. However, I think the syllogism you present does not stand. It seems to be:

Some new Wikipedians, or casual Wikipedians, may be put off by having to register;

Some people intend on vandalism would quickly register;

Ergo, there is a contradiction here.

The fault in this syllogism is that "Some" does not equal "All". It seems to fall down because it assumes that "Some A is B" = "All A is B". Also, please remember that the Wikipedians who may be put off by registration are unlikely to be the vandals - so I think we can call the syllogism an error. ACEOREVIVED (talk) 21:01, 18 November 2009 (UTC)

I think you've gotten it somewhat backwards, but at the core, yes, that's my point, that there is a contradiction. Try looking at this way: there is a relation, call it "R" (something like "registration is a massive deterrent to editing Wikipeida"), which when applied to one group is argued to be true, but when applied to another group is argued to be false. So we have a seeming instance of "R()" and "not R()" – which would be a contradiction, and an indication of invalid argumentation.

Not that this is necessarily a contradiction, for, as you have hinted, it could be a matter of different domains. E.g., that most vandals are tough-minded characters not easily deterred by anything, and the casual drive-by editors that some folks are so keen on encouraging mostly panty-waisted wusses. (Note that no one [?] is saying that "all vandals would be deterred", or "no anonymous editors deterred"; we're contemplating overall effects. For which data would be useful.) But until that or some similar distinction is made, it is invalid to argue that registration is BOTH a massive deterrent and a negligible ("10 seconds") deterrrent. I think it is likely to be one OR the other, on which suitable data might inform us, but it is invalid to argue both ways without some kind distinction. Indeed, at this point arguing "R" either way is only an uninformed opinion. - J. Johnson (JJ) (talk) 23:06, 19 November 2009 (UTC)

What J. Johnson seems to be saying above is that we should leave attempts at a priori reasoning behind, and therefore we should not work by looking for contradictions in syllogisms (or pointing out when contradictions are apparent and not real), and instead go for empirical data. Is registration a deterrent or not? Well, perhaps some one has done some empirical research into this, and it would be good to have a record of his or her data. You seem, J.Johnson, to be calling for more empirical research into Wikipedia editing. ACEOREVIVED (talk) 00:15, 22 November 2009 (UTC)

Close enough. What I have been saying is that in regard to the issue of whether anonymous editing should be allowed or not (our main topic here) a certain relation ("R") has been argued in a contradictory manner. Now it may be that this relation has some relevance to the issue, and as a side comment I have also suggested that suitable data could determine the truth or falsity of this relation, or even how it might appear to be both true and false. It is not so much empirical research as such that I am calling for as better argumentation – in which empirical data could play a role. - J. Johnson (JJ) (talk) 20:32, 22 November 2009 (UTC)

Wikipedia:Naming conventions (architecture)

I propose (re)creation of this convention:

• Wikipedia:Naming conventions (architecture)

In 2006 this page was created, but it is not good, and it is inactive now.

I would love to expand it, and propose a lot of things, so it could be useful again (or for the first time). For all other information, i am here and willing! Just tell me what to do next!

Tadija (talk) 14:44, 22 November 2009 (UTC)

You should probably get in touch with the folks at WT:WikiProject Architecture, if you haven't already. Or write out some concrete proposals and mention them there (and probably at WT:Naming conventions as well).--Kotniski (talk) 15:58, 22 November 2009 (UTC)