Wikipedia:Village pump (proposals)/Archive 43

• 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

Add a "new draft" tab between "article" and "discussion"

An idea in the case of editors authorizing changes to Wikipedia articles. Where editors are available for an article, to move public edits to a secondary tab. The editors would then authorize changes to the article from the "new draft" page. Where no editors are available (or are no longer available), the system reverts to the current wiki system, with edits going directly to the primary article and no "new draft" page is displayed. 91.84.88.163 (talk) 10:28, 6 February 2009 (UTC)

This is already proposed, more or less: see Wikipedia:Flagged revisions. {{Nihiltres|talk|log}} 14:15, 6 February 2009 (UTC)

Jimmy Wales proposes flagged revisions

According to the website of the BBC, Jimmy Wales is proposing a change to Wikipedia editing, such that only flagged changes (i.e. changes that are reviewed) will appear visible in Wikipedia. The BBC website claims that this has been the system with the German Wikipedia for about a year. How do people feel about this policy? It is important to alert all Wikipedians to these proposed changes. Wikipedians in the United Kingdom may have heard the Radio 4 programme "Today" on January 31, when Jimmy Wales was interviewed. You can read more fully what the BBC have said if you go to the website for "Today" for January 31, and follow the links accordingly. ACEOREVIVED (talk) 14:28, 6 February 2009 (UTC)

Where have you been? :-) See User talk:Jimbo Wales/Archive 44#Why I am asking Flagged Revisions to be turned on now. - Rjd0060 (talk) 15:06, 6 February 2009 (UTC)

Thank you - I have looked at this debate now. How about only making changes to articles per se flagged, but still allowing unlimited editing of the "Discussion" pages? Just a thought. ACEOREVIVED (talk) 16:35, 6 February 2009 (UTC)

Flagged revisions will only work in the mainspace and the portal space, if I recall correctly. Discussion pages would be unaffected. PeterSymonds (talk) 16:39, 6 February 2009 (UTC)

It can work on all non-talk pages (except special pages), we're free to enable it where we want and how we want. Nothing will happen soon. We need more discussions and consider more proposals, but unfortunately redundant and useless discussions on this happen everywhere. In part due to the media imagining we're going to request review for all edits (some even think it's already enabled on the English Wikipedia) and so misleading readers and users. Cenarium (Talk) 19:06, 6 February 2009 (UTC)

Feature Request: Special:Random&Category=&CategorySearchDepth= for random featured article, random article needing cleanup, random insert-category-here article

This would pull up a random article out of a named category, going up to CategorySearchDepth subcategory levels deep.

Special:Random?Category=FA-Class&articlesCategorySearchDepth=0 could be linked on the side-bar as "Random featured article."

Individual editors could add Special:Random?Category=All_pages_needing_cleanup&CategorySearchDepth=1 to their sandboxes or user pages as a link to a random article needing cleanup.

davidwr/(talk)/(contribs)/(e-mail) 21:03, 6 February 2009 (UTC)

WP:NOMORE proposal is being redirected to WP:CREEP without wide consensus

Please consider giving your opinion at the discussion here. Latest non-redirect version of the page is here. Thanks. 212.200.240.241 (talk) 13:46, 4 February 2009 (UTC)

Since there were no grounds for redirecting the page without a deletion discussion, I've reverted it. Equazcion •✗/C • 14:32, 4 Feb 2009 (UTC)

A couple of editors, and perhaps more, continue to edit war, after Equazcion's last coment, to delete / redirect the (now) essay, claiming a consensus to do so. Frankly, I don't see where they are coming from. I don't really see the point of the page either, but some people seem to be working on it and there would have to be a very strong reason to want to delete a policy proposal people are still drafting. I've restored it one time but don't want to end up in an edit war... normally I would suggest the page be protected but that seems to defeat the purpose of letting people work on proposals if they wish. Wikidemon (talk) 17:48, 4 February 2009 (UTC)

The people working on it are mostly the same person, and the person who originally wrote the essay. The consensus on the talk page there was to redirect. Thanks. Verbal chat 18:04, 4 February 2009 (UTC)

Watchlisted. –xeno (talk) 18:05, 4 February 2009 (UTC)

Why don't they just move or copy it to a sandbox and come back when it's ready for prime time (which, at the risk of sounding too harsh, may be never)? Also, if as they say it is a proposal for augmenting CREEP, when they are ready to propose something it would seem to make the most sense to add a sentence or a brief section to CREEP about the hurdle that a new proposal should overcome before it gets added to a policy or guideline page, which is itself....CREEP. Wikidemon (talk) 18:27, 4 February 2009 (UTC)

I'd have to agree that userfication seems to be the path of least resistance. –xeno (talk) 18:32, 4 February 2009 (UTC)

I agree with that. There is an ANI discussion about this editors account and IP hopping. Thanks, Verbal chat 21:34, 4 February 2009 (UTC)

Well, all the discussion was suddenly "archived"[1], and the decision made that the consensus of what to do would come from here. Is this a case for userfication (per Wikipedia:Wikipedia essays), or should this very unstable essay remain in WP namespace (after all it has in the past few days undergone a drastic change in scope)? NJGW (talk) 03:53, 8 February 2009 (UTC)

Fundraising...could donation requests target both editor-contributors and readers

Hi, during the last donation request period, I noted that the requests for donations seemed to be aimed at general readers and users of Wikipedia (and not enough towards editors and volunteers). Even after you logged in with your user-name, there did not seem to be a change in the types of appeals that were appearing in the header box. I am worried that general appeals to donate to Wikipedia (aimed at readers who just come on the site to read an article here and there) may not be motivating to a Wiki editor who volunteers hundreds of hours a year to Wikipedia. That is, if an editor spends many hours a week working on Wikipedia, they may respond to requests for donations with the sentiment that "Donate to Wikipedia?? Excuse me, but I ALREADY donate to Wikipedia..with my time and expertise as a programmer/editor/ administrator/ etc." Perhaps next year, during the fundraising campaign, there may be some merit to consider specifically targetting Wiki editors and volunteers (e.g., once an editor has logged in). A Wiki editor-targeted donation request might go something like this............"Thank you for giving many hours of your time to write and edit articles and maintain the encyclopedia. However, even with your generous contribution of your time, Wikipedia still needs financial assistance to pay for servers and other administrative costs."OnBeyondZebrax (talk) 11:31, 7 February 2009 (UTC)

Personally I would find that even more offensive than the begging messages I already get when logged in. DuncanHill (talk) 12:40, 7 February 2009 (UTC)

It's a possibility to do something like this, but it would still be better for the Foundation to concentrate mostly on the messages for readers, since there's a lot (I'm not sure of the exact figures) of readers per editor. Tra (Talk) 15:51, 7 February 2009 (UTC)

Make bullets, numbers and tabs all indent by the same amount

Moved to VPT, more appropriate forum. Happy‑melon 22:07, 7 February 2009 (UTC)

WP:Notdirectory should be clarified

I AFD'd a large group of lists (about 150) basically named "List of companies in ..." as violations of wp:NOTDIRECTORY. It seems from the initial responces that the NOT policy is either unclear on this point or I am misunderstanding it's purpose. Please consider either commenting at the above linked AFD or helping to reword the policy to give clearer guidance. NJGW (talk) 04:37, 2 February 2009 (UTC)

Still no comments at Wikipedia_talk:What_Wikipedia_is_not#Can_we_clarify_NOTDIRECTORY.3F. I plan to start rewording this in a few days, so any input would be helpful. NJGW (talk) 17:19, 5 February 2009 (UTC)

Proposed change to NOTDIRECTORY

A proposed change to the text has been made. Please comment at Wikipedia_talk:What_Wikipedia_is_not#Proposed_change_NOTDIRECTORY. NJGW (talk) 17:16, 8 February 2009 (UTC)

TfD nomination of Template:1911 talk

Template:1911 talk has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for Deletion page. Thank you.

NOTE: This particular discussion has been going on for more than a week already. I am a bit surprised that there has not been a greater response. I feel that I have given a good rationale for deletion in my nomination statement, but I would like to see what you all think. --Eastlaw ^talk ⁄ _contribs 09:43, 8 February 2009 (UTC)

Isn't this canvassing ? --DFS454 (talk) 17:02, 8 February 2009 (UTC)

No, it's an announcement. I'm not telling anyone how to vote. --Eastlaw ^talk ⁄ _contribs 22:44, 8 February 2009 (UTC)

It's not canvassing. Posting in one or even a few neutral forums to call attention to a discussion is fine, and often necessary to garner a more broad consensus. Equazcion •✗/C • 22:55, 8 Feb 2009 (UTC)

RfC to add line to criteria for speedy deletion

I thought it would be important to let you guys know about this.

Essentially the call is to add:

If an article is deleted under any of the applicable Criteria for Speedy Deletion, this deletion can only be reversed via WP:DRV discussion or via disciplinary discussion in the case of misuse of tools.

Please see why at the RfC here: Wikipedia_talk:Criteria_for_speedy_deletion#RfC:_Reverting_speedy_deletions_-_administrator.27s_guide

Thanks!--Cerejota (talk) 10:41, 8 February 2009 (UTC)

Year bug

From Template talk:Citation

When I type

* {{citation|last=Staniland|first=Martin|year=1973a|title=The Three-Party System in Dahomey: I, 1946-1956|journal=The Journal of African History|publisher=Cambridge University Press|volume=14|issue=2|url=http://www.jstor.org/pss/180543}}.,

I get

• Staniland, Martin (1973a), "The Three-Party System in Dahomey: I, 1946-1956", The Journal of African History, 14 (2), Cambridge University Press.

What the hell? I never said it was published on February 8. ~EDDY ^{(talk/contribs/editor review)}~ 00:47, 9 February 2009 (UTC)

The notation 1973a would only be used with Harvard style notation. When using footnote numbers, there would be no reason for the "a". That doesn't mean it shouldn't be fixed.

Also, I disabled the editprotected tag, since no solution to the problem is ready for implementation. --Gerry Ashton (talk) 00:50, 9 February 2009 (UTC)

But how am I supposed to cite two sources by the same author in the same year? ~EDDY ^{(talk/contribs/editor review)}~ 01:06, 9 February 2009 (UTC)

By avoiding Harvard notation. DuncanHill (talk) 03:06, 9 February 2009 (UTC)

Editnotice for all blps

To see how the blp edit intro works, add the line   importScript('User:RockMFR/blpeditintro.js');   to your monobook.js and edit any blp after bypassing your cache.

I propose to use an editnotice for all biographies of living persons. It would be added to all articles in Category:Living people, similarly to what has been done for disambiguation pages. We may use the text from {{blp}} for example, thus it would render this (from Template:BLP editintro):

I'm sure it would help highly that editors become more aware of the blp policy, and it's prevention, which is particularly important when it comes to blps. We really should try this before considering implementing some drastic measures. Cenarium (Talk) 22:50, 31 January 2009 (UTC)

I like the idea - is there an automatic way to do it, or does it have to be done on a per-article basis? Dendodge Talk^Contribs 22:56, 31 January 2009 (UTC)

This has been done for all disambiguation pages, see Template talk:Disambig editintro. I've asked at VPT if this is adaptable. Cenarium (Talk) 23:17, 31 January 2009 (UTC)

Apparently this can be done. You can try to add User:RockMFR/blpeditintro.js to your monobook to see the result. I'll add this discussion to WP:CENT. Cenarium (Talk) 00:23, 1 February 2009 (UTC)

Good idea. Sceptre ^(talk) 00:31, 1 February 2009 (UTC)

Yes, I like this. I think the wording of the editnotice should be changed to something along the lines of 'if you want to add material that might be controversial, make sure it's reliably sourced, otherwise please don't add the material' rather than focussing on what to do after the bad material is added. It would also be good to also have a template which activates the editnotice, in addition to the category. This could be added to certain articles which are not biographies but which contain a lot of content about living people. Tra (Talk) 00:35, 1 February 2009 (UTC)

I agree.Bsimmons666 (talk) 01:43, 1 February 2009 (UTC)

The wording can be changed, this is just to begin with something that I used the text from blp. Cenarium (Talk) 15:12, 1 February 2009 (UTC)

As for non-blp articles that may need this, it is possible to directly use the editnotice for the page. But a template, why not. Cenarium (Talk) 17:14, 5 February 2009 (UTC)

What is the main idea that we want to tell the editor?

1. That they should includes sources for everything they add.
2. That there is a Wikipedia policy that covers articles on living persons.
3. That vandalizing an article on a living person is bad and can have real-life consequences.

The editnotice should focus mainly on one thing, and it should be the thing that causes the most problems. In my opinion, it is #3. --- RockMFR 06:06, 1 February 2009 (UTC)

To be blunt, we're dealing with people that have trouble with the concept of "saying someone is dead when they really aren't is a bad thing." I don't have much faith that an editnotice will actually have any positive impact. I'm not trying to rain on the parade here, just pointing out the obvious. EVula // talk // ☯ // 06:21, 1 February 2009 (UTC)

• I'm bearish on the idea of edit-notices that admonish people to not vandalize or otherwise fool around actually working. One of the reason edit notices...get noticed (Sorry) is that there aren't many of them. The dab edit notice jumps out at you because you aren't used to seeing edit notices. Before we consider reducing the overall effectiveness of edit-notices in general, we should be pretty sure that this one will actually stop people. Unless we can be sure of that, I'd rather we not have one. Protonk (talk) 07:04, 1 February 2009 (UTC)
  • It's not about asking people not to vandalize (to which I'm also opposed), it's rather to spread the knowledge of the blp policy and explain to editors how to deal with blp issues (and how to report them: at the blp noticeboard). It's wrong to say that users breaching WP:BLP are necessarily evil, vandals, etc, some are just not aware of blp policy and the consequences of their edits, so it's also preventive. Cenarium (Talk) 15:12, 1 February 2009 (UTC)
    • Well, replace the word "vandalize" with the words "not follow the BLP policy". I'm just not sure that we will get a significant return out of it. Protonk (talk) 16:01, 10 February 2009 (UTC)
      • I have seen users who violated WP:BLP but later became aware of the problem and stopped, and are now in very good standing. Informing users is needed, and it also gives a direct link to BLP/N, to report blp-related issues. We'll certainly have an increase of participation there. Cenarium (talk) 16:25, 10 February 2009 (UTC)
• Good call. Go do it :) Stifle (talk) 11:54, 2 February 2009 (UTC)
• Yes, this is an excellent idea and deserves at least a trial run. Protecting BLPs from crap is our highest priority, far more important than properly formatting dab pages. Point of information: other than dab pages, article edit-notices currently number about 60: [2].--chaser (away) - talk 04:30, 3 February 2009 (UTC)
• This is a good idea indeed. -- lucasbfr ^talk 22:21, 3 February 2009 (UTC)
• Sounds good to me.--Esprit15d • talk • contribs 12:30, 5 February 2009 (UTC)

• There seems to be enough support for a trial at least. Before implementing, let's agree on the wording of Template:BLP editintro (). I have reworded it a bit to say 'should not be added'. Cenarium (Talk) 17:14, 5 February 2009 (UTC)
  • I changed living persons biographies noticeboard to biographies of living persons noticeboard - it's like that everywhere else. Also, I added please to the request to report problems. Oh, and I support adding it to all BLPs. – wodup – 17:32, 5 February 2009 (UTC)

The technical implementation is discussed at MediaWiki talk:Common.js#BLP editintro. Cenarium (talk) 08:24, 10 February 2009 (UTC)

Another Proposal regarding "moving pages"

Recent events show certain users abuse this feature. In a similar fashion to the number of rollbacks a non-admin users can perform per minute, I propose limiting the number of page moves done by autoconfirmed users to 1 per minute. This has the benefit that ligitamate users can still move pages ,allbeit more slowly, without the need to be penalized. --DFS454 (talk) 18:37, 2 February 2009 (UTC)

I agree with DFS454 here. It would stop Grawp in his tracks if he is throttled... for a while anyways, at least until he manages to get a bunch of socks to bypass it. But even then, he can only do so much with those accounts. UntilItSleeps PublicPC 20:17, 2 February 2009 (UTC)

What technical capacity exists within the revision of mediawiki employed currently here to do this? I know admins are free from "rate limits" but I was under the impression that we don't actually have rate limits enabled anyway. Protonk (talk) 22:43, 2 February 2009 (UTC)

We didn't do this for Willy on Wheels back in the day and I don't see a reason to do it for Grawp. Page-move vandals move pages because they know it's more disruptive, but sometimes legitimate users do need to move large numbers of pages; for example, when naming conventions change, which may be happening right now with regard to plants. Dcoetzee 22:50, 2 February 2009 (UTC)

Maybe have it throttled for non-rollbackers? JoshuaZ (talk) 22:55, 2 February 2009 (UTC)

But that isn't what rollback is for. I could see devolving the right to users like rollback, but that is always a contentious issue. I'm not against placing technical limitations on the wiki for the purposes of restraining vandalsim, but I think we need to know what is within our capacity and what we intend to do. For instance, what is the average page move/mintute for editors working at RM? At NPP? How is that distributed? Could we get a guestimation of some threshold which would restrain only 5% of those editors? 1%? do we have that data? Protonk (talk) 23:09, 2 February 2009 (UTC)

I don't think it's necessary to create yet another rights group just for something like this... If you're gonna go the group route, just use rollbackers. Rollback is only given to people who are trusted enough to have a feature that could allow the potential for the perpetration of faster vandalism -- which is the same case as here. Whoever we trust with one should be trusted with the other, as it's a very similar risk. Equazcion •✗/C • 22:26, 4 Feb 2009 (UTC)

How about a throttle that eases up automatically (without additional rights being granted through any formal process) based on the length of time the user has been active, and the number of edits made? I had proposed a moves-per-day limitation algorithm above, but a moves-per-minute would be similarly effective. (And if anyone should object on the grounds that such an algorithm would be too complicated to put in the software, remember that a computer program is all algorithms). Cheers! bd2412 T 05:59, 5 February 2009 (UTC)

And here is exactly the kind of thing that we need to adjust our defenses towards preventing. A tailor-made sleeper vandal account. One edit made in August of 2008, followed by nothing for nearly six months, followed by a handful of "legit" edits - less than a dozen, actually - followed by a short blast of page moves. The speed with which the page moves were done suggests that the vandal opened up multiple move screens and pasted the same message in all of them. What is it, exactly, about an editor who has made a grand total of ten very minor edits that allows us to trust them with the power to make page moves (and to make this many in the space of a minute)? And how is it that our system is set up in a way that allows articles and project space pages at good titles to be moved to titles that are, to human eyes, so obviously bad? I simply don't think that the above edit pattern could be made by any user with a legitimate purpose. Newbies don't launch into good and useful mass page moves after their tenth regular edit, and following a six month period of inactivity. bd2412 T 02:51, 6 February 2009 (UTC)

Agreed with above comments. Without going all BEANSy, page moves are probably the most disruptive thing a vandal can do. They should definitely be limited to rollbackers. It won't stop Grawp, or anyone else if they're determined enough, but it'll help. Majorly talk 03:00, 6 February 2009 (UTC)

Protonk asks the right question above - do we have the data? So lets get the data. Can someone generate for me a list of recent page move vandals? For parameters, let's say anyone who was permablocked in the past three months after having made four or more page moves. That should be enough data to pull out the most common patterns of behavior. If we compare that up against a list of page moves by newbies, we'll find the gap, the behavior that we can prohibit through technical means without impeding good edits. bd2412 T 03:37, 6 February 2009 (UTC)

Here is another example (they're falling in our lap today). Account made in August and never actually used at all until today. Very first edit was a vandalizing page move. How do we permit this? bd2412 T 04:10, 6 February 2009 (UTC)

I concur, the current system of allowing page moves after 10 edits is ludricous. I recently saw someone literally write "sock edit no.1" "sock edit no.2" [on the sandbox no less] all the way up to 10 before starting to perform disruptive page moves. In fact this happened twice.--DFS454 (talk) 20:56, 6 February 2009 (UTC)

One of the main reasons for objection against this proposal is that it may penalise users who want to make legitemate moves from namespace to article space or when naming convention changes. Well, we could have a "whitelist" that includes users who created an account before 2005, users who have made more than say 1000 edits, rollbackers and account creators. Users may request to be put on the whitelist and will be put on accordingly per Admin's discretion.--DFS454 (talk) 21:15, 6 February 2009 (UTC)

^That's a good idea. Heck, we could even just apply it to new accounts rather than change existing ones. We'll deal with the existing sleepers as they reveal themselves, but at least we'll know that no new ones can be created. Equazcion •✗/C • 20:22, 10 Feb 2009 (UTC)

Free media categorization

I have made a proposal to make an All free media category like for the non-free media template in order to improve bot detection of free media, and possibly better facilitate bot recognition of "interesting" scenarios for WP:PUI (like automatically listing it and notifying the uploader if there is a Non-free media tag present and a Free media tag on the exact same page).

Think this could be good? You can never have enough categorization! ViperSnake151 17:07, 8 February 2009 (UTC)

A bot could just as well use all subcats of Category:Free images to the same demise. §hep • ^Talk 06:12, 10 February 2009 (UTC)

Multi-column TOCs

The automatic TOC's could make better use of space on the majority of monitors if they displayed headings in a multi-column layout, rather than a single column as they do currently. The useless whitespace created on a page can be enormous, depending on how many headings an article contains and how large one's monitor is.

The caveat would be small screens and mobile devices. However, I'm pretty sure coding could be concocted such that if the horizontal space is available in the browser, the TOC would expand into multiple columns, while staying single-columned otherwise.

Just to preempt one response, I'm aware of some quasi-TOC "index" templates for long pages, that extend width-wise along the top or bottom of a page, but those either contain an index of all alphanumeric characters or need to have their entries set up manually. I'm not looking to make this modification in particular instances for my own use. I'm talking about the standard automatic article TOCs, which I think would benefit universally from the modification I describe. Equazcion •✗/C • 09:05, 9 Feb 2009 (UTC)

Also, an option could be added in preferences to toggle multi-column TOCs on and off, since I know some users will prefer to keep single-column TOCs. Equazcion •✗/C • 09:17, 9 Feb 2009 (UTC)

One issue with this is that some articles take advantage of the space to the right of the TOC for lead images and that sort of thing. But in many cases it would be an improvement. Dcoetzee 20:23, 9 February 2009 (UTC)

Don't forget that they do collapse.

I don't think I'd like a multi-column TOC which monopolizes a chunk of vertical article space completely, or pushes article content below the fold. I'd prefer collapsible TOC subheadings or something (also see Brittanica Online's approach, with collapsed subheadings and a scrolling TOC box, but I don't like their mouse-over scroll widgets). —Michael Z. 2009-02-09 21:06 z

Just to clarify, I'm only suggesting TOCs should extend width-wise when that space would otherwise be empty, not that content should be pushed around to make this possible. The point of this proposal is only to utilize space that would otherwise be wasted. Equazcion •✗/C • 03:08, 10 Feb 2009 (UTC)

Interesting idea. Could you prepare a mock-up please, or point us to a website where this layout works well? I would like to test my instinct: that the eye works better guided down a single vertical column. I often use a 'landscape' monitor (aka widescreen) and despair at the amount of unused space. --Hroðulf (or Hrothulf) (Talk) 07:00, 10 February 2009 (UTC)

Well... this would still be single vertical columns... just two or three single columns, rather than one :) I'm only half-joking when I say that. I mean, it works in newspapers and magazines, and no one seems to have complained in a hundred or so years. I think your theory is correct as far as how wide a contiguous line of text can be before it gets more difficult to read -- that's been proven, and that's why newspapers and magazines use multiple narrow columns of text rather than long lines that stretch from margin to margin. But long contiguous lines isn't what this would be -- rather, multiple relatively narrow columns, which should be pretty easy to read. Equazcion •✗/C • 20:31, 10 Feb 2009 (UTC)

Wikipedia needs a Public Domain Media Mechanism

In many articles (for instance: "grapes"), I have found that the main image of the article is not in the public domain, while there are many other similar images in the public domain.

I thought the idea was that the more free content should be preferred to less free content. However, the opposite seems to be true. People are using the least free license they can get away with. There is a profit or vanity reason for contributors to do this-- public domain images don't require attribution, so they will just replace PD images with their own!

I have no idea how this could be controlled.

Here is an example: http://en.wikipedia.org/wiki/File:Table_grapes_on_white.jpg "If you are a (commercial) publisher and you want me to write you an email or paper mail giving you permission to use my works in your products or a license with the terms of your choice, please email me to negotiate terms." -- not compatible with free usage, much less public domain usage.

--Agamemnus (talk) 21:26, 9 February 2009 (UTC)

That image is freely licensed (GFDL 1.2). The copyright-holder also offers to release it under other licenses if you ask, but so what? Algebraist 21:29, 9 February 2009 (UTC)

1) GFDL 1.2 is not public domain, and (2) his little message there is contrary to GFDL 1.2--seems like trying to trick people to pay for use even though it is not required. —Preceding unsigned comment added by Agamemnus (talk • contribs) 21:36, February 9, 2009 (UTC)

He has the right to offer to license it for use under other terms, for a fee. For example, someone might want to incorporate the photo into a proprietary work without having to release that entire work under the GFDL; or they may wish to use it without attribution. Dcoetzee 21:43, 9 February 2009 (UTC)

(ec)

1. We're not required to use public domain materials, merely freely-licensed materials. Where a freely-licensed image is better than a public-domain work, we'll use the freely-licensed image.
2. As the copyright holder for his work, he can violate many of the terms of the license without fear—he won't sue himself. Further, his offer allows individuals or organizations to use his image(s) without the restrictions of the GFDL, which is a significant difference for many applications.

There's no issue here. {{Nihiltres|talk|log}} 21:45, 9 February 2009 (UTC)

(1) & (2) That is true, but ...? I am not against this one person using that particular image, but against the general process in which public domain images are being passed over for other images.--Agamemnus (talk) 23:23, 9 February 2009 (UTC)

If you think public domain materials are automatically better than freely-licensed materials that can be used by anyone for any purpose, then you've come to the wrong website. Wikipedia is built on free licensing. Algebraist 23:25, 9 February 2009 (UTC)

I never said that.--Agamemnus (talk) 23:34, 9 February 2009 (UTC)

You certainly appeared to say that. You complained that Wikipedia did not give enough priority to PD images, citing as an example a freely-licensed image that was used when a PD image could be. When it was pointed out that the image was freely-licensed, you replied that free licensing is not public domain. If this wasn't a claim that PD is preferable to freely-licensed, what was it? Algebraist 23:59, 9 February 2009 (UTC)

Yes, it was a claim that PD is preferable to freely-licensed (and I thought it was the policy), assuming that the quality of both images are the same. That's the basic problem I would like to see addressed--if public domain images are preferrable for wikipedia, how can wikipedia reconcile these aims with the aims of the image uploaders, who may change articles from PD to their own, due to their own selfish reasons?--Agamemnus (talk) 02:13, 10 February 2009 (UTC)

Since when do public-domain images not require attribution?

What they don't require is permission. But one still tries to attribute them if at all possible. Michael Hardy (talk) 21:59, 9 February 2009 (UTC)

They don't require permission (free images don't require permission by definition) or attribution.--Agamemnus (talk) 23:23, 9 February 2009 (UTC)

(e/c)Wikipedia text requires attribution anyway as its released under a free license, and not PD; I fail to see how having images that also require attribution creates any sort of problems. If there is a PD image that's better in quality than a freely licensed one, we should use it, but we shouldn't prefer PD over free licenses where it sacrifices quality simply because its freer. Mr.Z-man 23:43, 9 February 2009 (UTC)

Right, but again, how do you reconcile the interests of uploaders to replace PD images with their own... with that of Wikipedia (as an entity) to use as much high quality PD material as possible?--Agamemnus (talk) 02:16, 10 February 2009 (UTC)

Wikipedia has an interest in using as much high-quality PD material as possible? That's news to me. We make little distinction between levels of freeness here. Something is either free to use, which may or may not include an attribution requirement or a free license, or its not free because its either copyrighted but not under a free license or it uses a license with incompatible restrictions. There's no obligation to use the "most free" image. We use whatever free image suits the usage the best. Mr.Z-man 03:04, 10 February 2009 (UTC)

I don't know what to make of this...--Agamemnus (talk) 17:52, 10 February 2009 (UTC)

Public domain images can be used with or without attribution without fear of copyright infringement. Depending on the situation, however, using an image without attribution (public domain or not) may constitute plagiarism. TenOfAllTrades(talk) 00:42, 10 February 2009 (UTC)

Public-domain images do not require attribution (they impose no requirements whatsoever). It's still considered good practice to attribute them though, for the sake of being able to track down the source. Dcoetzee 23:39, 9 February 2009 (UTC)

Strictly speaking, some moral rights jurisdictions require attribution in perpetuity even once the material becomes otherwise public domain. The US does not have such a law, of course. Dragons flight (talk) 00:58, 10 February 2009 (UTC)

You're right, I apologise for my US-centrism. :-) To respond to the original poster, we generally prefer freely-licensed works to works used under fair use, but we consider all free licenses (and PD) roughly equivalent and use other factors such as quality to choose one. The desire for attribution does not come into play, but it is common for the highest quality image to be a licensed one, just because authors of high-qualities works frequently prefer to be guaranteed attribution for them. Dcoetzee 02:50, 10 February 2009 (UTC)

I don't think public domain should be preferred because it's not viral. The GFDL and relevant CC licenses require that if you modify the content, you make your resulting work available under the same viral license. Public domain content has no such requirement and is therefore detrimental to the promotion of free content. --B (talk) 02:57, 10 February 2009 (UTC)

Interesting. So, you want to force people to use a certain license... consider the amount of people who WON'T use non-PD instead. Non-PD images are difficult to use for people who want to include them or parts of them in their websites or website designs. Consider photos-- not just logos or diagrams or whatnot--the amount of use a "viral" license is minimal, and there are many uses for regular unadulterated good photographs that are made that much harder by a non-PD license.--Agamemnus (talk) 17:52, 10 February 2009 (UTC)

No, I said nothing of the sort. I don't want to "force" anyone to use any particular license; I only said that we should not prefer PD over an acceptable free license—they should be treated equally. I didn't say that non-viral content isn't useful to someone somewhere, but promoting the business interests of a third party is outside of our scope. In my profession, I often have a need for images and would, of course, love it if all Wikipedia images were public domain. That serves me and my employer and my professional interests. But then whatever work I produce using those images, we are going to copyright. That's great for my employer, but not so much for someone wanting to promote free content. Our goal is not to create a public domain clip art library—our goal is to promote the growth of free content. To that end, I don't see any reason to prefer public domain images. The ONLY exception to that rule is that I think we should actively get rid of images where the author demands attribution in the article itself (as opposed to on the image description page). Under the CC licenses, I think that gives us legal problems. But that's a different subject. --B (talk) 18:41, 10 February 2009 (UTC)

It does not. Wikipedia does not need another "mechanism". It needs fresh quality editors, new content, enforcement of existing policies. Simply replacing licenses (or images with ... other images) does not improve anything; rather, it alienates long-term contributors who, until today, were unaware of any "their own selfish reasons". Thank you, Agamemnus, for reminding the unwashed masses of who they really are. NVO (talk) 18:48, 10 February 2009 (UTC)

Mysterious Redirect

The page Austria-Hungary is supposed to redirect to Austria–Hungary. However a few users (including myself) have raised concern that it doesn't work. Yet it does work fine for other users. It appears like a soft redirect (except it doesn't say soft redirect) for me. Any suggestions why it doesn't work, or better yet how to fix it? --DFS454 (talk) 19:53, 10 February 2009 (UTC)

That is really strange, the talk page redirect works fine otherwise I would have said it was something to do with the emdash--Jac16888^Talk 19:59, 10 February 2009 (UTC)

Yeah, it doesn't work for me either. EVula // talk // ☯ // 20:00, 10 February 2009 (UTC)

(ec)Looks like this might be the same as a recent error, which could be fixed with a dummy edit to the redirect. For some reason it's protected, so I can't test this theory. Algebraist 20:00, 10 February 2009 (UTC)

I just added an extra space before the wikilink; appears to be working now. EVula // talk // ☯ // 20:01, 10 February 2009 (UTC)

For completeness, here's the previous discussion. Algebraist 20:05, 10 February 2009 (UTC)

Working for me now EVula.--Patton^t/c 23:14, 10 February 2009 (UTC)

Chain of subjects

I have used Wikipedia to compile information supporting a group of topics. For example, in preparation for a family vacation to London, I entered the Tower of London, the London Eye, Kensington Palace and Big Ben. I printed each wikipedia write-up separately. It would have been very useful if there was a place to list a collection of Wikipedia articles that could be compiled into a mini book with an index and page numbering which could be either printed or formated into a .pdf. Add the ability to include directions with maps, and that would rock!

This would be useful on holidays (example above), but it could also be useful elsewhere in areas such as research, or general familiarizations of topics, that could be compiled while connected to the web, but then studies or otherwise used off-line.—Preceding unsigned comment added by 24.170.233.76 (talk • contribs) 02:48, 9 February 2009

This is something currently in development (except for the maps and directions part). Its being tested on wikibooks now. Mr.Z-man 02:58, 9 February 2009 (UTC)

Look at User:Pediapress - you already can prepare a collection of pdfs of Wikipedia articles, and then print them out yourself, or for a smallish price get them printed and bound as a book. DuncanHill (talk) 03:01, 9 February 2009 (UTC)

To use the PediaPress JS you need an account though. §hep • ^Talk 16:59, 11 February 2009 (UTC)

IM and VOIP

Have we considered a way to use IM or VOIP to help in the editing process. If we could integrate it in a transparent way, I bet we could reduce acrimony and increase collaboration. - Peregrine Fisher (talk) (contribs) 05:13, 11 February 2009 (UTC)

This may be completely missing the point, feel free to ignore it if it is Unfortunately I can see a few problems arising with this, firstly - contributing to the wiki isn't the easiest thing in the world at the moment, we make editors jump through hoops to learn how to edit and how to use talkpages and a lot of new users have problems understanding these even though we have vast amounts of documentation. Adding another level of complexity might not be a good thing. If on the other hand we integrate some form of IM or VOIP, how will it be logged? Any discussion that would affect the article or wiki would need to be able to be read/listened to at any future point in time so that future editors can find old consensus', decisions and notifications. This is relatively simple with the current talk page facilities, I can't see how we could do this for IM or VOIP. On the one hand I can see it helping on current events or collaborations, but these types of articles generally attract a level of acrimonious comments - can we deal with BLP violations and uncivil actions that happened in a VOIP or IM session? If we use it purely as an admin 'call to action' hotline, do we then have to instigate some kind of ticket system? We use irc a lot, this of course comes with it's own rules, and some collaborations, wikiprojects and sister projects utilise it extremely well (Wikinews in particular sees regular breaking news discussions in irc) but that comes with it's own pitfalls of having both to make users aware that the servers/channels exist and the etiquette for using them which in a lot of those channels including the prohibition of posting logs - stopping the creation of any documentable consensus ("we sorted it on irc last night" "prove it" "err..."). And my last issue, users edit Wikipedia at all times of the day all around the world. IM and VOIP would only be useful if there were other people available on a call/session at that particular time. So in conclusion, it's a nice idea but I can't see it ever working in practice. Nanonic (talk) 05:39, 11 February 2009 (UTC)

It would be quite the undertaking, I'm sure. There's probably some free IM client that could log the discussion and include it on our servers. It would be like a talk page converstion, but real timish. Obviously, it would only work when both people are online, but a lot of pages enjoy this. VOIP is probably a lot harder. - Peregrine Fisher (talk) (contribs) 05:44, 11 February 2009 (UTC)

I'd rather read through carefully-crafted talk page comments rather than the chatter of IM logs to find out what went on. I don't think this is viable for Wikipedia. Things need to be documented, and IMs and voice recordings make for significantly lower-quality documents. Equazcion •✗/C • 05:48, 11 Feb 2009 (UTC)

They may be hard to read or listen to, but I bet many days of talk page tag could be worked out in minutes. - Peregrine Fisher (talk) (contribs) 05:51, 11 February 2009 (UTC)

Users are welcome to use any means at their disposal to improve Wikipedia. However Wikipedia itself generally only facilitates fully transparent and documentable communication. While possible with more complex systems, what we have seems to be working. Chillum 05:51, 11 February 2009 (UTC)

That's right, in fact isn't there an IRC server or channel or something for Wikipedia? I'm not sure how much it actually gets used, but anyone wanting to live-chat can check that out. I'd post links if I knew where to point them to, I'm sure someone else will know. Equazcion •✗/C • 05:55, 11 Feb 2009 (UTC)

Found it: Wikipedia:IRC. Equazcion •✗/C • 05:57, 11 Feb 2009 (UTC)

Maybe the work is half done. I have a degree in computer science, but I've never bothered (I looked into it for maybe an hour) to figure out the whole IRC thing. What we need is where editors can, with a click, talk to other editors about an article or page. It would probably require a (hopefully easy) installation of some open source software, but after that, they just click on a link and talk. I don't know how IRC works, but maybe it can do this. My experience with IRC is that it ain't that easy. No newbies or non geeks allowed. - Peregrine Fisher (talk) (contribs) 06:03, 11 February 2009 (UTC)

It's gotten easier over the years. There's a web link protocol for it now, so the entire process is pretty much 1) install the client software and 2) click a link, and then the client puts you in the chatroom automatically. The links are at WP:IRC#List of useful channels (click "show" to expand the list). Once in a room, you pretty much just chat like in an IM. The text input box responds to text commands also (they start with a /forward slash ), but I don't think knowledge of those is really necessary just to chat. Equazcion •✗/C • 06:08, 11 Feb 2009 (UTC)

Can we set it up so that people 1) install a program 2) click on a talk page link and they're discussing a particular article 3) profit. - Peregrine Fisher (talk) (contribs) 06:13, 11 February 2009 (UTC)

Short answer, I don't know, but if it is I don't think that's likely to be implemented. You want to have links on every article, each leading to its own chatroom? That would be a lot of mostly-empty chatrooms. The logistics of this would be a very large undertaking. And, "profit" -- HA, excellent reference, I did laugh out loud. Equazcion •✗/C • 06:17, 11 Feb 2009 (UTC)

Well, my first imagining would be this. Included in every talkpage's header would be something with a link to download the program. There would also be a link to start the articlename/chatroom. They would only be created as needed, and every talk page that has such a chatroom would have a link to it. Probably some instructions, or a link to some instructions as well. The instructions might tell people to set up a time to talk on the talk page in the normal way, plus whatever else they need to know. - Peregrine Fisher (talk) (contribs) 06:26, 11 February 2009 (UTC)

←It's an interesting idea, but again I doubt its viability for Wikipedia. Chillum said it best above -- things are generally transparent and documented clearly here. Even the present IRC rooms are not officially part of Wikipedia, as WP:IRC states very deliberately. I'll let others chime in on this though, see what they think. Equazcion •✗/C • 06:31, 11 Feb 2009 (UTC)

I will too, after this comment. I've been recently uploading videos, which is a new and cool thing. Everything is getting fancier as technology improves. It's clear to me that we will also improve our ways of communicating, but the question is how and when. I'm of the opinion that we figure it out now, and start as soon as possible. 10 years ago, just the idea of a wiki was like magic. Let's take it to a next level, whatever that may be. - Peregrine Fisher (talk) (contribs) 06:41, 11 February 2009 (UTC)

I'm currently talking to another editor on AIM right now and I've been part of Skype discussions. Before becoming an admin I also published my IM contact info on my userpage (I only ever had two people contact me). I'm sure other do this as well, but I can't see this working on a sanctioned basis (e.g. WMF run Jabber server). It may however be worth it to try and start a "IM contact info" page for people to post their username. BJ^Talk 07:03, 11 February 2009 (UTC)

There is a Category:Wikipedians who use IRC though. There was a similar page for Wikipedians by IM, but I can't find it now. Jay (talk) 09:07, 11 February 2009 (UTC)

Where there's a will, there's a way. It looks like people are skeptical, though. There's lots of ways for users to talk. What I'd like to see is something centered around articles. I'd converse with people about this proposal using IM or IRC right now, if I could. - Peregrine Fisher (talk) (contribs) 07:11, 11 February 2009 (UTC)

IRC is pretty easy to use, I'd reccommend the Chatzilla extension if you don't want to worry about installing software. (To connect to the wikipedia channels on Chatzilla type in /server freenode then /join #wikipedia and /join #wikipedia-en) If you really don't want to install anything there is always Mibbit and [3]. As far as the proposal I think that due to the problems of logging real time chat it is something that we should encourage, but not implement directly. VOIP and video chat would be espically hard to implement, because you'd need to have someone transcribe the chat sessions if you want to do it accuratly. Though I wouldn't mind having a vent server around. --Nn123645 (talk) 17:29, 11 February 2009 (UTC)

Collaborative Moderation

Similarly to Wikipedia, other social networks also have to deal with massive amounts of low quality contributions from the public. It seems that the moderation model on Slashdot works fairly well. I propose to use something similar on Wikipedia.

The challenge is to design a mechanism for orchestrating the collaborative moderation effort on Wikipedia. I propose the following model.

1) Edits can only be done by registered Wikipedians.

2) Wikipedians will have a reputation or karma, depending on the quality of their contributions.

3) Long standing Wikipedians of good reputation are selected to moderate edits. Alternatively they can also moderate any page they want. These are Level 1 moderators. Authors of high quality edits will rated up, and authors of low quality edits will be rated down, and this will affect their reputation.

4) Wikipedians with reputation under a threshold will be restricted or banned from doing edits.

5) Long standing wikipedians of good reputation are invited to moderate Level 1 moderators. These are Level 2 moderators. They will judge whether the Level 1 moderators were fair. Altenratively they can moderate any Level 1 moderator they want. Fair Level 1 moderators will be rated up, and unfair moderators will be rated down, which will influence their reputation.

6) Wikipedia staff are all-powerful, and can sanction any Level 1 or Level 2 moderator.

Introducing reputation will give Wikipedians recognition for their work. —Preceding unsigned comment added by Josang (talk • contribs) 09:27, 11 February 2009

I have many reservations about this:

1. We already have a shortage of both reviewers and admins. I doubt if many editors would sign up for yet another non-editing task.
2. IP editors often do useful copyedits. Instead of restricting IP editors en masse, we should be much tougher on vandals, including those using shared IP addresses (if the shared IP's admins complain, we should tell them to produce evidence that they are taking effective steps to control their users).
3. "Long standing wikipedians of good reputation" creates a danger of domination by cliques, of which WP has enough already.
4. The alternative would be to create an automated system such as used by EBay. However Ebay's "reputation" system has been gamed by suppliers who give complaining customers black marks. And an automated systemfo rWP woudl be more complicated and less reliable, as it woudl have to rely on assessments by other editors who have watchlisted the articles, rather than by the principals to discrete transactions. Reliance on other editors who have watchlisted the articles would also increase the danger of of domination by cliques. --Philcha (talk) 12:19, 11 February 2009 (UTC)

No, it's just not going to happen, for various reasons. It's not even worth discussing why, because it simply won't. ♫ Melodia Chaconne ♫ (talk) 12:27, 11 February 2009 (UTC)

Unfortunately, the fundamental premise of your proposal, that only registered users (that is, those capable of collecting 'karma') are able to edit, has been explicitly rejected innumerable times; see PEREN, WP:Editors should be logged in users, meta:Anonymous users should not be allowed to edit articles, WP:Disabling edits by unregistered users and stricter registration requirement etc etc. Any proposal which involves disenfranchising anons of the ability to edit Will Not Succeed. Happy‑melon 12:28, 11 February 2009 (UTC)

Too hierarchial, given the amount of opposition flagged revisions got there is NO way this would ever be implemented. —Nn123645 (talk) 13:15, 11 February 2009 (UTC)

Wikipedia is not Slashdot, and we do not intend to make it so. If you want a collaborative writing site based on a karma system, you may want to check out Everything2 instead. Zetawoof_(ζ) 05:19, 12 February 2009 (UTC)

Notable Sports Peolple / Speedway Riders

Whilst I appreciate the reasoning behind the editors seeking some agreed selection criteria of notable riders I would suggest that there are some sports, like speedway, where riders could be considered to be notable for example they were characters with a strong personal following (fan base) yet did not achieve any of the above. For example a rider who raced at Glasgow Speedway called Joe "Whaler" Ferguson. Joe wrecked bikes regularly but still came back for more. He was never a star but was nonetheless a natable. Views please.

Can you provide reliable sources for his notability? Who then was a gentleman? (talk) 22:30, 11 February 2009 (UTC)

Category of redlinked categories

Could somebody create a "Category of broken categories" (or "Category of redlinked categories")? I'm serious. I would be willing to put in some serious work on emtying such a category. I know about Special:WantedCategories, but that is a list and not a category, and just of the 1000 mostly found, not of all of them. Debresser (talk) 18:14, 11 February 2009 (UTC)

See Special:UncategorizedCategories.-gadfium 20:36, 11 February 2009 (UTC)

Which is 5 months out of date, and displays bluelinks when they should be red. DuncanHill (talk) 22:40, 11 February 2009 (UTC)

This is not what I meant. I checked a few of those categories. Most have been deleted (the right way, without leaving articles that link to them), while at least one of them (and probably a few others too) is a nice category with a lot of articles and 2 parent categories. See the Special:WantedCategories talk page for a discussion on the subject. Debresser (talk) 22:43, 11 February 2009 (UTC)

Edit conflict notification on preview

As long as previews require a server query, they might as well check for edit conflicts while they're at it, and notify the user. Equazcion •✗/C • 22:35, 11 Feb 2009 (UTC)

I agree; it's particularly annoying to catch an edit conflict using the "Show changes" button as well—an explicit notice of the intervening edit would be useful. {{Nihiltres|talk|log}} 03:10, 12 February 2009 (UTC)

You'll have to file a feature request over at bugzilla. — Blue-Haired Lawyer 11:36, 12 February 2009 (UTC)

Well yeah, once consensus is shown here that it's something everyone wants, that will be the next step. Equazcion •✗/C • 13:32, 12 Feb 2009 (UTC)

No, changes to MediaWiki don't need the approval of the English Wikipedia. We aren't the only ones who use the software. If you want a discussion before going to Bugzilla (Bugzilla itself isn't especially suited for long-ish discussions), the wikitech-l or mediawiki-l (there's a lot of subscriber overlap between the 2) mailing list would be best or possibly meta, if you think this might be for some reason controversial. Unless its a feature specifically for the English Wikipedia, like a feature no one else will ever use, a config change specifically for here, or an extension installation, it doesn't need consensus here. Mr.Z-man 17:35, 12 February 2009 (UTC)

Point taken. I've submitted a bug: Bug 17467. Please vote for it if you think this would benefit MediaWiki/Wikipedia. Equazcion •✗/C • 17:49, 12 Feb 2009 (UTC)

Proposal for slight but important change to main page layout

We often have a number of articles featuring topical subjects on the main page. For example, currently there is a featured article on evolution, and a whole bunch of Darwin/Lincoln articles in DYK that are being featured for the 200th anniversary of both Lincoln's and Darwin's birthday.

The trouble is, there is no obvious announcement that the reason these articles are being featured is because it is an important anniversary. Only if you happen to look at the bottom right hand corner of the main page, in the "On This Day" section, do you notice a line mentioning that this is Darwin's and Lincoln's birthday.

I would like to suggest that on dates on which we are featuring such topical content, there should be a line at the TOP of the page, right above the featured article/in the news sections, which announces the anniversary, so that readers can instantly make the connection between the content of the featured article/DYK sections and the anniversary in question. Otherwise, readers are liable to miss the anniversary, see a lot of articles on similar subjects, and just conclude that there isn't much variety on Wikipedia, which is not the sort of conclusion they are supposed to draw! By making it clear it's a special day on the other hand, we showcase the topical relevance of the site. Gatoclass (talk) 09:30, 12 February 2009 (UTC)

Great idea. It'd have to be coordinated across multiple areas of the project, for example in a case where there are multiple choices of thing to choose as a topic for a particular date - and different parts of the project choose to highlight different events on the same day... Cirt (talk) 09:39, 12 February 2009 (UTC)

Sounds good to me. Maybe there can be a subpage (like Wikipedia:Main page/Topic banner and Wikipedia talk:Main page/Topic banner) and at the talk version of it people could leave suggestions for what to do with a banner on a certain day (something along the lines of "Hey this is Joe from TFA and we're gonna be doing an article on X on March 5"), where people from multiple subprojects could coordinate the stuff beforehand; then it would just be a matter of Joe alerting all the other main page projects ("hello DYK, just so you know, we are doing a TFA on some topic, do you also have topical stuff?") and yada yada. rʨanaɢ ^talk/_contribs 12:35, 12 February 2009 (UTC)

Support - I think that featuring something related to a specific day is a complete waste if the average reader doesn't see the connection, or believes it to be a coincidence. I remember that I saw the January 20th TFA (Washington, D.C., for the presidential inauguration) several times before I suspected a connection, and then I had to dig through the TFA discussions to confirm it. עוד מישהו Od Mishehu 12:39, 12 February 2009 (UTC)

I actually sorta always considered that to be a subtle and welcome clue that we were an institution of intellectual standards. Not explicitly telling everyone something they could figure out with a little brain power and maybe a single link click really said something. Something about not catering to the lowest common denominator, or something. Something like that. It's a subtle message that I can't completely articulate without sounding elitist, which isn't how I mean it. Or maybe it is and I'm just in denial. Whatever. Equazcion •✗/C • 14:18, 12 Feb 2009 (UTC)

It's not "elitism", it's "avoidance of condescension" ;) {{Nihiltres|talk|log}} 17:02, 12 February 2009 (UTC)

Oh, and in case it's not obvious, I completely agree with your sentiment, and I think that it's quite nice that we leave the fact that we'll feature stuff on relevant dates completely unspoken. It's also quite useful to leave it unspoken as we often don't feature things on relevant dates. {{Nihiltres|talk|log}} 04:25, 13 February 2009 (UTC)

Hmmm .maybe something like:

Today: Charles Darwin and Abraham Lincoln's 200th birthday

or in another situation:

Today: The 2008 United States presidential elections

Would this be sufficient? ViperSnake151 15:46, 12 February 2009 (UTC)

I was thinking more of a line of discreet italic text saying something like: Today, Wikipedia celebrates the 200th birthdays of both Charles Darwin and Abraham Lincoln, or, Today, Wikipedia commemorates the anniversary of [anniversary here].

But yes, I think you have the basic idea. The actual layout and formatting would obviously be a matter of negotiation. Gatoclass (talk) 16:34, 12 February 2009 (UTC)

This presents an implicit endorsement of the subjects mentioned. {{Nihiltres|talk|log}} 17:02, 12 February 2009 (UTC)

I rather like this suggestion - I was thinking about typing something similar myself on this day (Feb 12) being the Lincoln-Darwin anniversary, but I see it has already been made. ACEOREVIVED (talk) 21:29, 12 February 2009 (UTC)

For Milton's birthday, we handled it by adding "born 400 years ago today". However, a common denotion of a whole range of specialty hooks being devoted to a topic would work as well. It all depends on how broad the topic and how many articles are devoted to it. Allowing it? Definitely. When and where and how? That could be discussed later. Ottava Rima (talk) 04:15, 13 February 2009 (UTC)

New template to help new users

I suspect the first part of the following is a template because I see it so often on the Help Desk. The second part was written by a separate editor and probably is not a template.

I would like to propose the following text be used for the question "How do I create an article?"

Please see Your first article.

1. Ensure that you have an account and you are logged in. If you don't have an account, create one
2. Make sure the subject is notable enough to have their own article
3. Find references
4. Make sure no article on the subject exists under a different title by typing the subject into the search box to the left (←) and clicking 'Search'
5. Type the page name in the search box to the left (←) and click 'Go'
6. Click 'Create this page'
7. Create the article, including all your references, making sure you adhere to the Manual of Style and our article layout guidelines
8. Be aware that Wikipedia deletes thousands of new articles for failing to adhere to our policies and guidelines. New articles by new users are at extra risk of deletion, due to new users' unfamiliarity with our rules. Consider gaining experience by editing existing articles before attempting to create new ones.

If you are sure you should create your article after reading all of the above, then go ahead. If you are unsure, then, after creating an account, you can then create a sub-page in user space. For example, if your user name is Foobar987, your user page will be User:Foobar987. If your new article is to be named "Blatification" then you can initially create it at User:Foobar987/Blatification. After you create the article and get it up to a standard you are happy with, come back here and ask for someone to review your article. We will then help you to make sure your article is OK according to our strange and wonderous rules. We may even help fix the article or help you to find someone to assist you. Once the article is good enough, you can move the article to "mainspace:" that is, use the "move" feature to change the name of the article from User:Foobar987/Blatification to just Blatification. This approach works because by convention a subpage of your user page is not required to follow all of the rules of a mainspace article. (Note, however, it must still adhere to some fundamentals such as no copyright violations and no personal attacks.) —Preceding unsigned comment added by Vchimpanzee (talk • contribs) 14:20, 12 February 2009

There are two templates in common use for this purpose: {{HD/new}} and {{creation}}. Since these questions are asked almost exclusively at the help desk, the correct place to discuss the templates is probably WT:HD. Algebraist 14:27, 12 February 2009 (UTC)

Thanks. I figured they get enough questions, but OK.Vchimpanzee · talk · contributions · 14:30, 12 February 2009 (UTC)

Oh, I see, that's a different page.Vchimpanzee · talk · contributions · 14:32, 12 February 2009 (UTC)

Taxobox

Sorry if this isn't the place, but everywhere else was locked from editing. So here's the question: do any users have the ability to copy the taxobox over to another site? If you could, that would be very helpful indeed. The site in question is RationalWiki. --ConservapediaUndergroundResistor (talk) 00:59, 13 February 2009 (UTC)

I put it in Template:Taxobox2 (taxobox was taken). It's a complex template though and might rely on some other templates specific to Wikipedia... Give it a try and see I guess. Equazcion •✗/C • 01:05, 13 Feb 2009 (UTC)

Central overview page for certain processes

I would like to propose the creation of a page where all the current cases involving disputes etc, are listed in the one place. So, in other words, one would have all the current RFC, RFA and RFAR cases listed, in abbreviated form, so that users could see at one glance who or what was being debated. Part of the current problem we have, I think, is that such processes are scattered around on different pages and obscured from ready view. If we had a central page that listed all such processes, users would know they needed to go to only one page to keep tabs on things, and it might encourage more participation, which is often woefully lacking. Gatoclass (talk) 10:00, 27 January 2009 (UTC)

Support. It absolutely makes sense. Rivertorch (talk) 10:34, 27 January 2009 (UTC)

Support. The whole layout of the behind-the-scenes Wikipedia needs a way more centralised approach I think. Autonova (talk) 12:37, 4 February 2009 (UTC)

Support. I'd like to see something like this. §hep • ^Talk 17:29, 11 February 2009 (UTC)

Support. Anything to try to get the system to work properly, which it doesn't at present (see my user page). Peter jackson (talk) 10:25, 13 February 2009 (UTC)

Proposed guideline on close paraphrasing

Recent investigations have uncovered some contributors who habitually employ close paraphrasing over a long period, causing frustrating copyright issues. A while ago I wrote an essay about close paraphrasing, what it is, and how to avoid and detect it. Since it's linked from the cleanup box {{close paraphrase}}, I'd like it to have the force of a guideline. Please visit Wikipedia:Close paraphrasing and Wikipedia talk:Close paraphrasing#Proposed_as_guideline to leave your opinion. Thanks! Dcoetzee 20:39, 13 February 2009 (UTC)

Proposal to change default coloring of navboxes

There's a proposal to change the default styling of navboxes, here. Any comments would be appreciated. SharkD (talk) 05:10, 14 February 2009 (UTC)

"speedy" mass category moves in progress

Please note Wikipedia talk:Categories for discussion#Speedy removals.3B opposition to hyphenations. In the spirit of "adjectival hyphenation", all "nth century $THING" categories are being speedy-moved to "nth-century $THING". This affects literally thousands of long-standing categories. The "consensus" this is based on is a couple of CfDs with two or three votes. As far as I can see based on a generic rule of "adjectival hyphenation", not on evidence of actual widespread use of hyphens in the case of centuries in particular.

I am opposed to this move as premature and misguided, and would ask that it is backed up be a wider community consensus before these speedy moves proceed. --dab (𒁳) 09:50, 11 February 2009 (UTC)

Hyphenation aside, I don't see what's wrong with following consistent consensus on Categories for Discussion. If only two or three people were interested enough to vote, so what? We would get the same problem with voting for page moves. What happens if you need five votes to move a page, but only three people are interested enough to vote? It might be nicer if more people were interested in CfD, but in the meantime two or three is enough.

Anyway, I think the hyphenation checks out. When "second century" is used as an adjective it should be hyphenated. Rather than being called "adjectival hyphenation" is called "grammar" -:) — Blue-Haired Lawyer 13:32, 11 February 2009 (UTC)

Did it occur to you that Wikipedia has been going for eight years, with its share of grammar nazis, and until late 2008 nobody ever objected to "20th century philosopher"? I will tell you why: when "second century" is used as an adjective it should be hyphenated is simply not a rule that is alive in the real world. I readily admit it sees some use. But by no means is it more common than the unhyphenated spelling. Check the google books results for

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

at first glance well below 1:10. This is nowhere near anything that would make this giant move at all arguable. What irks me is that this huge transition went underway with all of two CfD votes, no community review, and nobody even bothered to check who is prescribing this, which major publications use it and which don't, the very basic minimal standard for any significant rename. --dab (𒁳) 09:30, 14 February 2009 (UTC)

And on top of that, it's now a precedent which can be used to make the same change to articles. I have to agree: making sweeping changes on the basis of the discussion of two or three people is not adequate consensus. The original CfDs should have been denied procedurally and forced into a larger discussion context first. Mangoe (talk) 13:28, 14 February 2009 (UTC)

Non-free reduce bot proposal

A bot has been proposed to deal with the non-free reduce backlog. The discussion is at Wikipedia:Bots/Requests for approval/NeuRobot 2, and everyone is encouraged to participate and assist in establishing consensus. — neuro^(talk) 23:50, 14 February 2009 (UTC)

Replacement of biota by country categories

I've made a "test proposal" at CfD to see if there is a consensus for replacing the categorization system of classifying biota "by country" with a system that would categorize biota "by ecozone". See here to read or comment. Good Ol’factory ^(talk) 03:50, 15 February 2009 (UTC)

age and education requirements

I know this is similar to other proposals, but I propose that (1) Wikipedia allow editing only by users at least 18 years old and with at least a high school education, (2) a Kidpedia be set up so they can do what ever they want. We have too many problems with edits from kids. Bubba73 (talk), 03:46, 5 February 2009 (UTC)

I don't see how this would be policed, or what purpose it would serve. The important thing is the ability to contribute constructively to the encyclopedia. In the natural run of things people too immature to contribute either go away or end up permanetly blocked. But if under-18s are able to contribute, why on earth would we want to deny them? Algebraist 03:52, 5 February 2009 (UTC)

Against for reasons too numerous to mention. We have means at our disposal to handle problem editors of any age, and we should welcome productive editors of any age. The only reason we should have age limits of any kind is where required by law. For example, users with certain privileged access rights have to be legal adults and file their real-life identity with the Wikimedia foundation. But other than that, Wikipedia is an encyclopedia anyone can edit. davidwr/(talk)/(contribs)/(e-mail) 03:58, 5 February 2009 (UTC)

There is one major problem with the "anyone can edit" policy, and that is that anyone can edit. Bubba73 (talk), 04:01, 5 February 2009 (UTC)

That is rather the point of that policy. How is it a problem? Algebraist 04:03, 5 February 2009 (UTC)

Still, that line is classic "signature/userbox" material :) --Ron Ritzman (talk) 05:03, 6 February 2009 (UTC)

Are you telling me you wouldn't let Peter Jennings, Patrick Stewart or Sydney Poitier edit Wikipedia? They never graduated high school. And most of the banned users are over 18 and high school graduates, so those barriers of entry would not serve your desired purpose. We have loads of responsible "under age" and "not yet graduated" editors here, and even some admins. Anyway, there are important reasons we allow access to anyone. A cornerstone of the foundation of Wikipedia is that anyone can edit. We want to attract new users, and we are willing to help new users learn the ropes. Anyone has potential to be helpful here. We block and ban those who can't comply. Kingturtle (talk) 04:08, 5 February 2009 (UTC)

I think that the edits by kids are a net negative - more problems than positive edits. And that doesn't count the time lost by good editors. I spend at least 10% of my wikitime fixing these type of problems. Yesterday I had to spend a great deal of time dealing with it. I thought the idea of Wikipedia was to have a useful source of information, not to give every idiot a soapbox and to let him have fun wasting more of other people's time than it cost himself. OK, I can see this is going nowhere, so this is all I have to say (it is off my chest). Bubba73 (talk), 04:14, 5 February 2009 (UTC)

I think that edits by people who are mentally immature are a net negative .... However, there are plenty of 12 year olds that are more mature than some "adult" Wikipedians. davidwr/(talk)/(contribs)/(e-mail) 04:45, 5 February 2009 (UTC)

Here's something for Bubba to do: please offer proof of all your assertions, please. —kurykh 05:03, 5 February 2009 (UTC)

Yeah, I don't doubt that Bubba is accurately presenting the vandalism issue we're all more than familiar with. But where's this assumption coming from that it's all being perpetrated by "kids" and those lacking formal education? Equazcion •✗/C • 05:23, 5 Feb 2009 (UTC)

I oppose and denounce this proposal in the strongest terms. Many of our best admins have been under 15. Kids are frequently immature, but they can be highly capable if they're just given the tools and the trust. Besides that, there's no technical way to ascertain the age of contributors, particularly anonymous contributors, who are not ever going to be forced to register. Dcoetzee 07:04, 5 February 2009 (UTC)

• The only way we could do this would be to have no anonymous editing, unless if we went with the honor system... Plus, some children are indeed genuises, just as some adults are not. In any event, we would no longer be the encyclopedia that "anyone" can edit. Best, --A Nobody^{My talk} 07:10, 5 February 2009 (UTC)

• Extraordinarily poor idea. I'm all for reducing immaturity, but to do that, we should remove the immature people, who aren't necessarily children. I spend a lot of my time dealing with disruptive adults. You don't see me suggesting adults be banned do you? And the point about the High School education bit is completely ludicrous. Majorly talk 02:56, 6 February 2009 (UTC)

• Aside from it being impossible, on a practical level, to enforce this proposal, it's also wrong-headed. One of the editors I most respect on Wikipedia is, as I understand it, only 13 years old. And I personally am a high school dropout. Yet I am so learned even I sometimes have to get out a dictionary to understand what the heck I'm saying. ;-P --Father Goose (talk) 06:04, 6 February 2009 (UTC)

• I can understand why you would suggest such a thing but it is entirely streotypical. Not all children are immature and not all adults are perfect. The fact anyone can edit is Wikipedia's Achilles Heel and simultaneously it's greatest asset. A prima face argument against you is the fact on the whole the site is usuable ,not full of complete nonsense, is testement to the system working.--DFS454 (talk) 10:16, 6 February 2009 (UTC)

I would have thought that it is up to the parents or guardians of children to keep any eye on how they might use the Internet, and, if possible, to block their children from accessing certain websites. They may be able to guard their children against using Wikipedia if they feel that children were using Wikipedia for poor purposes. However, let us be realistic. Is it really likely that young children will edit articles on quantum mechanics, existentialism, predicate logic or genetics? There is a Simple Wikipedia - the one that is written in Simple English - which is likely to be more accessible to children than this one, and so may be more likely to be read (and edited) by children. ACEOREVIVED (talk) 16:32, 6 February 2009 (UTC)

Okay... trouble is, nobody knows about the Simple English Wikipedia. Besides, kids could well be more mature than adults. Which does bear repeating. By the way, tell Bubba that the Wikimedia Foundation, as a condition for supporting us (i.e. we couldn't make it on our own without it), requires that "anyone can edit" be preserved.

(Besides, I'm not even 16 yet!) ~user:orngjce223 how am I typing? 19:23, 6 February 2009 (UTC)

The Simple English Wikipedia is primarily targeted at speakers of English as a second language, not at children - anyone young enough to not have the language skills to read the English Wikipedia, is most likely also too young to have the technical skills to edit anything. I think most kids 8 or older can probably read a lot of English Wikipedia articles. Dcoetzee 23:36, 6 February 2009 (UTC)

I'm strongly against imposing age or education requirements, for a number of reasons, but I've been working on a page providing some introductory guidance and suggestions for our younger group of editors, and hope to have it completed and up for comments within a couple of days. Newyorkbrad (talk) 23:50, 6 February 2009 (UTC)

Well I think its a good idea. Although i support raising the age requirement to 25 at least and a college degree. Silk Knot (talk) 02:51, 7 February 2009 (UTC)

Yeah that'd really lower the server burden, being that roughly 99% of registered members would need to be evicted. Equazcion •✗/C • 02:58, 7 Feb 2009 (UTC)

I would like to see some statistics to back that claim up. Silk Knot (talk) 03:15, 7 February 2009 (UTC)

There are none, for the same reason that implementing this idea would be impossible: Wikipedia doesn't keep track of, or even ask for, any credentials or personal information upon registration. Hell they don't even make you register. Equazcion •✗/C • 07:50, 7 Feb 2009 (UTC)

• It occurs to me that this proposal is already implemented... on Citizendium. Strangely, it has not resulted in a superior encyclopedia.--Father Goose (talk) 07:37, 7 February 2009 (UTC)

• Oppose, we're the free encyclopedia anyone can edit. Also Silk Knot, you're joking around right? ViperSnake151 17:11, 8 February 2009 (UTC)

• Oppose, LittleDan, Ilyanep, One, Messedrocker, etc. Blanket statements don't work. §hep • ^Talk 01:19, 11 February 2009 (UTC)

• Oppose This proposal is completely unenforceable. It also makes the dubious assumption that age and education guarantee superior editing. Further, it completely misidentifies the most damaging editors to Wikipedia. Edward321 (talk) 17:18, 15 February 2009 (UTC)

• Oppose, of course. I believe that Wikipedia would not be nearly as well maintained if it were not for the power of bored high schoolers. Second Life's community died when they evicted the young'uns, and Wikipedia's would as well. Not that this proposal needs to be opposed any more thoroughly, as it's also a non-starter due to the invasion of privacy, but I just wanted to say that I appreciate what our younger contributors do for Wikipedia. rspεεr (talk) 17:48, 16 February 2009 (UTC)

• Eh, does my GED count? — CharlotteWebb 18:33, 16 February 2009 (UTC)
• Support - Because it would mean no more Neuro on ENWP, which is surely a plus. But seriously, oppose. Unenforceable, ridiculous, pointless, senseless, much too broad, and it would mean I would have to piss off (my teachers would love you). Seriously, the majority of the immaturity comes from the old fogeys. I say ban everyone over 25. — neuro^(talk) 00:32, 18 February 2009 (UTC)
• Oh hell no! We need people. We judge people by the contributions they make. Chillum 00:34, 18 February 2009 (UTC)
• Hell to the motherflipping no. 1) you could never enforce/judge such a thing 2) under 18 users do a lot of good work (I know of one under-18 admin, for example) and 3) age is not DIRECTLY indicative of maturity. I'm sure we get a lot of over-18 vandals as well. In addition it is just.. restrictive and wrong. Wikipedia is Not Citizendium. Ironholds (talk) 00:59, 18 February 2009 (UTC)
• Extreme oppose. Ageism is frowned upon in the modern world. It would be a logical tragedy for it to seep into Wikipedia. Haipa Doragon (talk • contributions) 01:05, 19 February 2009 (UTC)
• Strongest Oppose Possible I'm 16, and don't think it would be fair for me to be denied access to Wikipedia because of my age. Besides, they already have a "kidpedia" at Unpedia Tavix (talk) 03:11, 19 February 2009 (UTC)

• Oppose Firstly, While I agree that kids are often very disruptive in their edits, one should also stop to consider the numerous correct and serious translations that kids have made. However, this proposal could be adapted. For example, require age limits for modifiers who have been accused of vandalism, say, two times. Secondly, Wikipedia is supposed to contain the entire sum of all human knowledge (sorry, but I have no time to cite that; I hope that most of you recognize where it's from). By blocking children from editing Wikipedia you are saying to us (yes, I count myself amongst the insulted) that children have no mental capacities what so ever and are naught but slow-witted, immature air-heads that want nothing but to cause disruptions. What percentage of children that you know go running around saying, "well, today looks like a nice day, let's go and vandalize a Wikipedia article! Just think how funny it'll be!" Finally, let's get down to the frank truth: a "kidpedia" would be laughingstock. Look at yahooligans.com for an example. "Kidpedia" would be nothing but a sandbox. Besides, look at this page (the one you're on). What is it? A list of discussions. Debates. Fights. If we're having enough trouble already to maintain Wikipedia, imagine what it would be like to manage both Wikipedia and "kidpedia"! That's something to think about, now, isn't it?—Preceding unsigned comment added by 72.49.122.167 (talk • contribs) 23:39, 19 February 2009

• Oppose Definition of Wikipedia: The Free Encyclopedia that Anyone can edit. What happened to the "anyone" part? Is it being inferred that children are not people? Just a thought.

• Oppose it would stop alot of young good editors that try to help

• Support and a year's ration of soylent green to anyone who can explain how it can be done. NVO (talk) 08:59, 22 February 2009 (UTC)

• Support Oppose Vehemently! Here's the problem in my book. I am only 15, but I do think I make changes that are useful to the general public. Banning kids would be like, say, re-segregating the voting public. It's just not right. By the way, the thing at the beginning was because it looked like a good idea at first, but became more and more Stupid as time went on. It just would NOT work. Nameless9123 (talk) 12:51, 23 February 2009 (UTC)
• Oppose, of course. ╟─TreasuryTag►contribs─╢ 12:54, 23 February 2009 (UTC)

Community something about ArbCom

Moved to Wikipedia:Village pump/ACFeedback 01:00, 17 February 2009 (UTC)

Special:ListUsers email sort

In terms of how Special:ListUsers is implemented (I see that it was updated into a different format recently), could it indicate whether users have email enabled? I'm not sure how helpful this would be (since there's so many accounts), but I see that some users activate wiki email so that they can send malicious messages via wiki. Perhaps this could be enabled like "Show only users with edits". ~ Troy (talk) 20:49, 15 February 2009 (UTC)

This would be abused by spammers in a heartbeat. Their only real disadvantage now is that they have to try Special:Emailuser for one person, so our hope is that they will give up due to an unacceptable reject rate (too many accounts with no address set), but even this assumes they are paying attention to the server's response which often won't be the case. — CharlotteWebb 18:50, 16 February 2009 (UTC)

If spam is really a problem, why not limit the number of outgoing emails per user account per day (say, to 10 or so)? -- John Broughton (♫♫) 20:40, 16 February 2009 (UTC)

Adult content notification for articles with explicit images or links

The purpose of this idea is a solution to the controversy about minors having easy access to articles with explicit content (possibly without even knowing this before they view the article) that will help to avoid arguments over whether explicit content should be in a certain article or not (Wikipedia is not censored so there's no immediate bar to explicit content of course). As for exactly how this would be implemented with the software, I'm not an expert on that but here's my general idea:

Articles that contain (or new articles that are likely to contain) adult content (such as sexually explicit images or links to adult sites) will be placed in a "category" for "articles with explicit content" (this doesn't have to be a normal Wikipedia category necessarily but they'd have to be designated as such in order for the software change to affect them). If an unregistered user tries to view the article, before the article itself is loaded a screen will appear notifying them that it contains explicit content and that they must be of legal age for their country state before viewing the article, and provides them with a link to either acknowledge their age and view the article or go back (the same as most adult websites do). This seems like a good idea to me, but the main downside to it would be that users who are of legal age would have to go through this routine repetitively just to view those articles. My solution to that is to allow registered users an option in their user preferences to confirm that they are the legal age to view adult content (similar to the system on Youtube) at which point they'll be able to view any articles with adult content just as they would a regular article (without the "warning screen" I mentioned appearing before the article itself is loaded). I'd like to hear opinions on this idea as I think it would eliminate defacto the controversy by some Wikipedia critics that Wikipedia "peddles porn to kids" (some would still argue that it's still easy for children to access the explicit content but this would not be any more so than with any other site on the internet that contains adult content so they'd have no real case against Wikipedia).--The Jazz Thief (talk) 03:13, 16 February 2009 (UTC)

And you define 'adult content'....how? ♫ Melodia Chaconne ♫ (talk) 04:35, 16 February 2009 (UTC)

Not my personal definition. Every government has their own definition and I was going by that, not personal preference.--The Jazz Thief (talk) 05:07, 16 February 2009 (UTC)

So do we go with the most restrictive definition out there and warn whenever an article shows a woman's bare face, or do we go with the most liberal, in which case we have no warnings? Or do we try to find something inbetween, and if so, what? --Carnildo (talk) 07:58, 16 February 2009 (UTC)

Isn't it kind of interesting that the generally agreed-upon best way to fix (U.S.) national underage sex statistics is to educate about the choices regarding that? Having "explicit" link warnings not only goes against the spirit of WP:NOT#CENSORED, but also against the spirit of an encyclopedia: An encyclopedia exists to educate. If people want access to an explicit article, then they are going to get access, because they want it and not because they stumbled into it. Critics of porn peddlers are the same critics saying that WP should have died a grateful death a long time ago; it seems to still exist to me. I.e., changing our rules to solve problems which don't exist is a silly practice. Overall, a bad idea, and one that exists as the very first heading of WP:PEREN. --Izno (talk) 04:48, 16 February 2009 (UTC)

As far as accessing explicit content unintentionally, my concern there were a person running across sexually explicit content unintentionally by using the random page or random image feature. There are also a few articles that aren't about sexually explicit subjects but do contain nude or explicit images (such as the Rage Against the Machine article) so I can see a person looking up that article and seeing explicit images without knowing they were there.--The Jazz Thief (talk) 05:07, 16 February 2009 (UTC)

It is not hard to define adult content. For example the United States code legal definition of of "sexually explicit conduct"[4] as "actual or simulated (A) sexual intercourse, including genital-genital, oral-genital, anal-genital, or oral-anal, whether between persons of the same or opposite sex; (B) bestiality; (C) masturbation; (D) sadistic or masochistic abuse; or (E) lascivious exhibition of the genitals or pubic area of any person". Most of these have been further refined by associated regulations and court cases. At some point and in some jurisdictions we may be required to give adult content warnings, and track it to avoid child porn, depending on what the legislators and courts have to say. You could probably devise similar systems for rating violence and other adult topics, and it does not have to be a 100% perfect definition to accomplish the general goal. Most people do think that there's some value in keeping certain subject matter away from kids until they are ready. Nevertheless, if parents want to do it for themselves, I'm sure they could sign up for a Wikipedia clone site that filters, rates, or warns about adult content... but fixing Wikipedia won't do much for these parents if their kids have access to google. Perhaps the parental control software already does it. Avoiding warnings is a different thing than avoiding censorship - but I think we have a similar attitude towards all this stuff, e.g. not flagging film plots with a "spoiler alert"... reader beware! Wikidemon (talk) 05:24, 16 February 2009 (UTC)

It's hard to define adult content; you focused on one aspect in the law of one country, and that law didn't even define it as 'adult'. Is the history of the Crusades adult content? This is an area that is not worth spending time on. Tempshill (talk) 06:45, 16 February 2009 (UTC)

The proposal was to protect children by warning about mature content, not to try to define "adult". Presumably the concern is sexually explicit material, something easy to define (as per the US law). If there's another concern such as violence it's just as easy. You make a good point that there are different standards and we shouldn't impose US norms on everyone. For that reason content filters, which can be localized and customized for different parents, is a better idea than inconveniencing everyone with the a less flexible regime. However, the US is the legal jurisdiction where any criminal or civil laws on the subject would come to bear because the servers and management are in the US. Protecting children online is a reasonable question and a rather important issue - it's been to the US Supreme Court and back several times. If it's such a perennial proposal that it's not worth discussing again then it's best to point to a place where this is written up. Wikidemon (talk) 08:23, 16 February 2009 (UTC)

But why should we have to go by the standards of the US? Legally we have to obey U.S. (and more specifically, Florida's) laws (because of the server's location), but there's nothing illegal about having encyclopedic content here even if it might be considered pornographic; however, as far as any sort of scheme saying "this fits, this doesn't", there's no reason that the U.S. need be elevated. As implied above, different governments have different standards (and it's not always a single straight line scale). So I ask again, how do you define it? What possible way is there of saying "this is, this isn't"? You have to think about the fact that if we start to separate certain topics, it could very easily turn into something Very Bad because we didn't do it for x-topic. ♫ Melodia Chaconne ♫ (talk) 12:30, 16 February 2009 (UTC)

there's nothing illegal about having encyclopedic content here even if it might be considered pornographic. See also: Streisand effect. davidwr/(talk)/(contribs)/(e-mail) 15:54, 16 February 2009 (UTC)

What possible way could adult sexual content be defined? The US law or some other standard - however we wanted. If there ever is a legal warning or recordkeeping requirement in the US or any US state, something quite foreseeable given repeated attempts to pass these laws (e.g. see 2257), it would be illegal to do otherwise and US state or federal law would be the standard. Wikidemon (talk) 16:28, 16 February 2009 (UTC)

Besides the question of US-centrism, there are basic cultural assumptions here that are going unquestioned; mainly, that viewing sexual images is somehow damaging to children, even when accompanied by explanatory text that educates them about what the image describes in a neutral fashion. It's very difficult to attempt to control when children encounter and learn things; and I would be the first to direct my own children to Wikipedia for learning about sex. Images on this site, sexual or not, are not decorative and emphasize informational content over aesthetics. Dcoetzee 18:55, 16 February 2009 (UTC)

I think as soon as parents realize most of what they teach their kids is considered pseudoscience, they'll want to censor a lot more than the sex pages. — CharlotteWebb 18:43, 16 February 2009 (UTC)

Anyway, see Wikipedia:Perennial proposals#Content warnings and, if you need to read more about the Wikipedia community's reaction to proposals like this, see the entries under the topic "Censorship", in the Editor's index.-- John Broughton (♫♫) 20:38, 16 February 2009 (UTC)

Adoption of V2-style Infobox headers, as developed on other Wikipedias (includes links to mock-ups)

Propose adopting, or investigating adoption of, "Infobox/V2" graphical style in Infobox headers on English Wikipedia. The presentation is much more professional (& better looking) than the current style. Basically, the title/topper of each infobox type (Music, film, person, society, etc) gets its own background color and background graphic. (For example, infoboxes about transport have a specific background, as seen in Golden Gate Bridge article link below) Other mock-ups can be found in the link below. I raised this at the Infobox Wikiproject's talk page about a month ago, and the response was that while technically possible the question would be if it should be done (so proposing it here to see if there is interest in pursuing/investigating its application here). Examples below (including link to French Wikipedia's Infobox V2 project)

• File:Infobox-french-music.jpg — French Wikipedia mock-up of music infoboxes, other examples at next link:
• French Wikipedia: fr:WP:V2 — French Wikipedia's Infobox wikiproject (V2 subpage) Rough English translation courtesy Google at: [5]
• fr:Golden Gate Bridge — Golden Gate Bridge article at French Wikipedia, infobox uses V2 style.
• Commons:Category:Infobox_pictograms — transparent-background Infobox pictograms used as watermark-type graphics on top of background colors & under title text in the infobox titles.
• Hungarian Wikipedia: hu:Sablon:Képregényszereplő_infobox#Minta comics character infobox.

Outsider80 (talk) 05:50, 2 February 2009 (UTC)

It does look quite good. The selection of background graphics looks like it could use some refinement. I'd like to see a more comprehensive set of examples, at least covering the top-level subject areas seen in Portal:Contents/Portals . —Michael Z. 2009-02-02 07:28 z

fr:WP:V2#Feuilles de style has examples of various top-level topic areas (afaik this is the most comprehensive examples they have, apart from the pictograms on Commons). the examples all use orange backgrounds, but the mock-ups in other examples show different background colors used for different topics. Outsider80 (talk) 08:09, 2 February 2009 (UTC)

hu:WP:IB (project page @ Hungarian Wikipedia) also has some examples about 1/4th of the way down the (long) page. it is mostly redundant w/ the French examples, though it does use a Bridge-specific graphic for bridges, and a football instead of the olympics symbol for sports. Outsider80 (talk) 08:15, 2 February 2009 (UTC)

Current guideline discourage decorating and inventing icons Gnevin (talk) 08:47, 2 February 2009 (UTC)

True (mainly for user-level editing), but this would be built-in to the template at a non-user-editable level, as an automatic design based on which type(topic) of infobox is used, and would not be very distracting. Outsider80 (talk) 11:12, 2 February 2009 (UTC)

It looks nice, sure, but whatever they're doing to get that effect hides both the title of the infobox and the lead image in text-only browsers like Lynx. --Carnildo (talk) 10:04, 2 February 2009 (UTC)

The text seems to work fine, as in the example article at fr:Golden Gate Bridge. I think it may be just the example mock-ups which use graphical titles instead of text. Of course the graphics won't be visible in a text-only article, and if we consider them to be strictly presentational, then they are best implemented as CSS background images with no alternate text. On the other hand, one might argue that the information conveyed by icon and colour should also be conveyed in alternate text as well.

If this project gets some momentum, then we can get more feedback from WP:WPACCESS. —Michael Z. 2009-02-17 20:46 z

aside from resolving that bug, I think this is something we should simply move to as quickly as possible. the only questions I have show it will work on some of the more complicated infoboxes--the ones shown are rather simple. I certainly do nott thinks we'dwant an orange color in general, sicne we use that a a color for warnings. DGG (talk) 10:25, 2 February 2009 (UTC)

The French model (and likely other Wikipedias) use different colors for different topic categories, the orange was just used for all of them on the mock-up. English Wikipedia could of course decide which colors to assign to which topics (I think we already do this w/ infoboxes, or at least I have seen different colors used) Outsider80 (talk) 11:12, 2 February 2009 (UTC)

Note: The following message was just posted at Wikipedia talk:WikiProject Infoboxes, in the thread I mentioned at the top of this proposal. Am cross-posting it here since it contains useful links (and examples/mock-ups) for other language Wikipedias not mentioned above. Outsider80 (talk) 11:12, 2 February 2009 (UTC)

Hallo. Also the both sorbian wikipedias use such background images. The project pages are at hsb:Wikipedija:Infokašćik and dsb:Wikipedija:Infokašćik. But also the Esperantowikipedia has such a project at eo:Vikipedio:Informkestoj. I added some background images there, which are not in the french page. You can find all my added images on my commons user page. Greetings --Tlustulimu (talk) 10:19, 2 February 2009 (UTC)

It's attractive, but it needs some consistent graphical guidelines and set of icons before it's ready for deployment.

Specifically, the theatrical masks, game console, and compass are realistic 3-d images, with a lot of detail and shading, while most of the others are 2-d solid-colour graphical icons. Some are light-coloured only, while others have a lot of dark tone in them, and the bridge and highway add dark backgrounds for some reason. They vary too much in size (e.g., the filmstrip is 4 times the width of the beer mug). And a few are poor quality, like the planet and star, which seem to have contrasting edges, which appear to be antialiased for some other background colour.

We also need a comprehensive directory of subject areas, so that a full set of icons can be assembled. If we start with 20, then there will be 100 others of varying appearance and quality thrown in by various wikiprojects.

I think we need one or more artists ready to develop icons specifically to meet some guideline, rather than trying to mix and match found icons. This is on the right track, but if we're going to suggest changing infoboxes project-wide, the design should be a bit more mature to have a good impact. —Michael Z. 2009-02-02 16:50 z

It looks great. Work out any bugs and deploy it gradually to infobox templates. --Apoc2400 (talk) 22:33, 2 February 2009 (UTC)

• (Prodding this since it is about to hit the 7d archive point...) So is consensus to slowly test-roll out, or should it go to a MoS talk page (or elsewhere) for further discussion? Thx, Outsider80 (talk) 00:36, 10 February 2009 (UTC)
  • Slow roll-out; maybe pick a couple of medium-sized WikiProjects to start? -- John Broughton (♫♫) 23:56, 16 February 2009 (UTC)
    • sounds good to me... that might be a good way to assess initial feedback to the change (in addition to the working out of kinks). Maybe WP:COMICS (since a counterpart already exists for this on the Hungarian Wikipedia — Example), and then maybe a specific music genre's wikiproject for artist/album infoboxes (as seen on the French V2 mockups — Example)? Outsider80 (talk) 19:50, 17 February 2009 (UTC)

"show/hide cleanup tags" button to pages

See Wikipedia:Village_pump_(policy)#Drive-By_Editorials for background.

Proposal: Add a "show/hide cleanup tags" button to the top of each page, which would make article, section, and in-line cleanup templates visible or invisible.

There are many variants of this which can be decided later. I'm just trying to get a feel if the basic concept is useful. davidwr/(talk)/(contribs)/(e-mail) 20:08, 12 February 2009 (UTC)

I think this would be a good idea, Ambox would need a bit of a change for it to work out. --Izno (talk) 03:08, 13 February 2009 (UTC)

I'd prefer to see most of these templates show up in compact form, providing a minimal interface and explanatory tooltip, and being individually expanded with a click. In many cases there should be an indication that there are content issues, but there is no need for a huge array of banners always in the reader's face, or a flotilla of inline tags reducing readability, when a few icons or widgets can inform the reader. —Michael Z. 2009-02-13 21:10 z

• Oppose. The very purpose of the cleanup tags is to be obtrusive and annoying. If you don't want the tags, then fix the problems. —kurykh 22:21, 13 February 2009 (UTC)
  • A tangential discussion was moved to User talk:Equazcion. Equazcion •✗/C • 06:46, 14 Feb 2009 (UTC)
    • Per the linked discussion, I would be amenable to compacted tags rather than hiding altogether. —kurykh 08:18, 14 February 2009 (UTC)
• Oppose. per Kurykh Fiddle Faddle (talk) 22:56, 13 February 2009 (UTC)
  • I concur with Kurykh on compacted tags. I oppose show/hide but support compact/uncompact. It is important that the banner is present, it is unimportant that it be obtrusive. Fiddle Faddle (talk) 17:40, 14 February 2009 (UTC)
• Support We are supposed to be producing an encyclopedia. It's also a work in progress, but the overwhelming majority use is simply for reading it. (I need to check the numbers, but its over 99%), Reading is therefore what shoud be facilitated. DGG (talk) 00:41, 14 February 2009 (UTC)
• Support - As long as we don't shrink 'em by default (but, hopefully, do allow for users to set that as their preference), I say go ahead. To attempt to impose on our readers as Kurykh would seems unprofessional and annoying which, admittedly, is the point - It's more important to amass knowledge here than to be reader friendly, hence my disinclination to have this feature enabled by default. To allow the reader to dismiss these messages, however, would seem like a nice in-between. You may have to get in people's faces every once in a while to serve your ends, but you're going to just piss people off and break Wikipedia:Don't be a dick if you refuse to get out of their face when asked nicely afterwards. MrZaius^talk 07:20, 14 February 2009 (UTC)

  Mr Zaius, Mr Zaius, amassing knowledge is not in the least bit incompatible with being reader friendly. If by the latter you mean making the encyclopedia as readable, usable, and accessible as possible, then we are clearly obliged to do it. We just have to aspire to good design for the reader, and avoid bad design, or design which favours editors over readers. —Michael Z. 2009-02-14 16:04 z

• Support As I said at VPP, I think this is a neat idea. Equazcion •✗/C • 20:11, 12 Feb 2009 (UTC)
  • PS, I like the idea of compactable notices too, as Michael Z describes, as long as there's a way to show and compact all notices on a page at once. Equazcion •✗/C • 07:31, 14 Feb 2009 (UTC)
• Support compacted tags but not doing away altogether. Our real audience is the reader and user of the free content, not the editor. They should be cautioned when they are at an admittedly substandard article. A compacted, expandable tag strikes the right balance of dignity, readability, yet not misleading readers. Ideally this should be universal with the compacted as the default, to avoid any contention. I'm mainly annoyed by NPOV and related tags inserted by editors who fail to gain consensus... the tags themselves become a point of contention and end up diminishing otherwise decent articles.Wikidemon (talk) 14:12, 14 February 2009 (UTC)

this certainly--we dont have to give all the possibilities. it's enough to indicate a problem, and link to the talk p. Fuller explanation belong elsewhere. The colours that we use are considerably softer than in the past, but we could go still to a gentler approach to things. s for NPOV tags, it should be obvious that any article on a contentious subject will have a disputed POV--our readers are not in general idiots. Getting rid of this particular tag would furthermore save a good many unnecessary quarrels about whether or not in should be on a particular article. MfD, anyone? DGG (talk) 09:23, 15 February 2009 (UTC)

• Support compacted tags, such as the following (copied from a section below; I'm not sure that the wording is optimal, but I like the size and coloring). -- John Broughton (♫♫) 23:02, 16 February 2009 (UTC)

This section requires expansion.

• Comment: having just played around with such templates (in order to get the more-formal-looking third variant below), I have been made aware that (barring arcane parameters that I'm not aware of), it is not possible to generate them using current standardised templates (the template-indentation appears to be the insuperable barrier). If wide-scale rollout of subtle templates was planned, a standardised template tailored to the concept would be a really really good idea (but unfortunately well beyond my coding skills). Hrafn^Talk_Stalk^(P) 03:19, 18 February 2009 (UTC)

• Support compacted tags: This is fine for a compress/expand thing like the table of contents and project banners do. The compressed tags still need to be noticeable so casual readers can see if a section is unreferenced or similar. -Fnlayson (talk) 23:23, 16 February 2009 (UTC)

I was thinking of the alert-box templates defaulting to collapsed boxes in the right margin. (The sample here is the huge block of two templates from T-44.) While in the collapsed state, they would have a mouse-over tooltip summarizing the message, defaulting to an indication of the message type. Any click would open the box, or all boxes, up to the full width, and a small control would allow them to be re-collapsed. Perhaps the coloured bar could serve as the control, with a bold white + or - in it to invite the action and indicate the state. Alternatively a black or grey + or - could appear in a corner.

Alternatively, they could sit in a horizontal line still floated to the right of the article text. This would have the advantage of not pushing down an infobox as far. In this configuration, the coloured bar could be shown running across the top of the box array.

In the collapsed state, I'd also like to see them made less colourful, perhaps with a greyed-out version of the icon, or having the coloured bar reduced to a 1-pixel border.

Thanks to the modular design of {{ambox}}, this could be accomplished with a fairly simple javascript, I think. I've created the alternative presentation above using the standard template mechanism's parameters only.

Inline templates, like {{fact}} and {{dubious-inline}} are a separate issue, but I'd like to see them appear as minimal symbols or dingbats by default, with tool-tip text. —Michael Z. 2009-02-17 00:02 z

The problem of ones without text is accessibility, though. I would personally keep the (usually) bolded part of the template, which should also allow for better eye catching. Oops... Misunderstanding. o.o --Izno (talk) 02:52, 17 February 2009 (UTC)

I think it's important that text spelling out the problem be visible, though (of course) in smaller font. Yes, it's easy to run the mouse cursor over the symbol to find out what it means, and yes, after after a while an experienced editor will have memorized the symbols, but bother of those are a bother. I also think it would be a mistake to have all compacted tags be grey; color-coding again helps with near-instant recognition.

If the smaller versions can be implemented via javascript, then it would seem to me that the next step would be to prove out that concept, reach some kind of consensus (on another page, not here) regarding a set of compact tags to be used for a pilot demonstration, and then - ideally - make this available as a gadget for all registered editors. -- John Broughton (♫♫) 14:13, 17 February 2009 (UTC)

I've created a crude version which requires no javascript at all, CSS only. This will give you a sense of the functionality, although the user experience is lacking. Mouse-over tooltips are missing, and the fly-out boxes jump awkwardly, so try not to judge harshly.

Minimally tested in the latest Safari and Firefox; MS Internet Explorer 6 and 7 probably can't understand this at all. Add the following text to your style sheet, at User:<you>/monobook.css.  —Michael Z. 2009-02-17 19:24 z

/* pop-open ambox alerts */
 
table.ambox { /* collapsed by default */
    clear: right;
    float: right;
    margin: 0 0 0 1em;
    }
 
    table.ambox .mbox-text {
        display: none;
        }
 
table.ambox:hover { /* open on hover */
    float: none;
    margin: 0 0 0 20%;
    }
 
    table.ambox:hover .mbox-text {
        display: table-cell;
        }

Book sources

Does anyone think that it would be a good idea to include Amazon in Book sources? I know that this is a blatantly commercial site but the precedent has already been set by the inclusion of Yahoo! and Amazon has a highly useful "search inside" feature on many books. I have come across a number of instances where Amazon gives better access to the book than Google books. For instance I have used Boyer's A History of Mathematics as a ref in several articles (it happens to be on my bookshelf) but anybody trying to find the citation in Google books gets a near useless snippet view whereas Amazon provides a full page preview complete with diagrams. Another example is the book Mutiny on the Amistad: The Saga of a Slave Revolt and Its Impact on American Abolition, Law, and Diplomacy which recently got an article. Google books version compared with Amazon version. I have even come across cases where no preview is available at all on Google but it is on Amazon, could nto recall an example unfortunately. SpinningSpark 20:25, 15 February 2009 (UTC)

• Amazon has been a listed book source since the list of book sources was first compiled by Eloquence in 2003. Uncle G (talk) 02:25, 16 February 2009 (UTC)
  • Ah, so it is. Thankyou, I've never scrolled down that far. It seems odd that Yahoo! is given such prominence in that case, since it is much less of a useful resource. It is only acting as bookseller, not a search engine, in this respect. SpinningSpark 11:43, 16 February 2009 (UTC)
    • {{sofixit}} Project:Booksources is editable, and also has a talk page. ☺ Uncle G (talk) 23:52, 17 February 2009 (UTC)

Page move vandalism proposals

I have undertaken a searching investigation of recent bouts of page-move vandalism, and I have identified the following patterns, and steps which I believe will significantly impede such conduct.

• Observation 1: The worst page-move vandals are aware of the existing four-day delay before new users are able to engage in page moves, and they evade this measure by setting up sleeper accounts, which they may not access for long periods of time - sometimes six months or more - before awakening those accounts to engage in a vandalism spree.
• Solution 1: In order to hamstring sleeper accounts, I propose that page-move permissions be automatically reset for any account with fewer than 50 mainspace edits that goes for a particular length of time - perhaps sixty or ninety days - with no edits emanating from that account. The sleeper wakes up the account and finds that they are still unable to make page moves with it, and will have to make good edits and then wait another four days.
• Observation 2: Page-move vandals tend to make a very small number of "good" edits - maybe a dozen - before launching into vandalizing edits.
• Solution 2: Set the a higher minimum number of mainspace edits before an editor is granted page-move permission. I'd say at least 25 would be worthwhile - it would at least inconvenience vandals who make dozens of sleeper accounts, to have to make 25 edits from each of those accounts before being allowed to move a page.
• Observation 3: Page-move vandals tend to make large numbers of moves very quickly, indicating that they open and prepare a number of page-move screens at once.
• Solution 3: Take some measures that put a brake on first-time page movers:
  • 1. The very first time a page move is performed from any account, direct that editor to a screen explaining policies governing page moves and require that they check off an acknowledgment of having read it before the page move will go through. For typical editors, this will be a brief one time inconvenience. For page-move vandals who make numerous sleeper accounts this will be a more significant impediment.
  • 2. The very first time a page move is performed from any account, flag that edit on a list for quick review.
  • 3. A throttle mechanism was proposed above, which would limiting page moves to one per minute. This would be a reasonable restriction for very new accounts (or potential sleeper accounts) which have not previously made page moves. I would propose that such a limitation be put into place for the first six page moves from any account which has not produced at least 50 mainspace edits, as that should provide enough time to catch and stop any vandals, and will create a substantial brake for vandals with many sleeper accounts.

Please discuss the above on their individual merits. Cheers! bd2412 T 21:28, 6 February 2009 (UTC)

I don't like solution 2, we only quite recently (I think in the last year) introduced the 10 edits requirement for autoconfirmation and I have seen no evidence that it has reduced page move vandalism and cannot see them being discouraged no matter how many edits the requirement is made as. The only people who are going to be put off are the good faith new contributors. Moving pages is also linked through autoconfirmation with being able to upload files and edit semi-protected articles both of which I would strongly oppose making more difficult. Davewild (talk) 21:36, 6 February 2009 (UTC)

I am highly skeptical that anyone other than a vandal will find it necessary to move a page within their first 25 edits. bd2412 T 21:48, 6 February 2009 (UTC)

The number of new artcles created by new editors at bad titles (wrong capitalisation for instance) is quite large. Further making it more difficult for them to correct their own mistakes is not something I think we should be doing. Davewild (talk) 21:53, 6 February 2009 (UTC)

Maybe an exception could be programmed to allow users to move pages they've created themselves. Equazcion •✗/C • 22:05, 6 Feb 2009 (UTC)

I would very much support such an exception. But frankly I don't think those editors frequently correct their own bad titles - more often than not, that is probable done by seasoned users watching the new pages list. In any event, very new users can't move pages until they have been registered for a few days anyway. bd2412 T 22:08, 6 February 2009 (UTC)

I think that the number of page move vandals who would be discouraged by an increase in the number of edits from 10 to 25 would be less than the number of good faith newer editors who would be prevented from sorting out their own mistakes. Page move vandals are the most committed type of vandal and for them a few more edits would make no difference. The introduction of 10 edits has made no difference and I see no reason 25 would either.

However if this was disconnected was autconfimation (ie. 10 edits would still be the standard for editing semi-protected pages and uploading files) and if there was an exception for them to be able to move pages created by themselves then I would withdraw my opposition. I would still not be supporting however because I think this would be a lot of work for very little benefit and some potential downside. Davewild (talk) 22:23, 6 February 2009 (UTC)

If you can show me one instance where a user has made a non-vandalistic page move within their first 25 edits, I will withdraw that prong of the proposal. bd2412 T 00:12, 9 February 2009 (UTC)

Special:Contributions/Fractalgirl Tra (Talk) 00:40, 9 February 2009 (UTC)

That was to correct mis-titling of pages created by that user, for which we said there should be an exception. I think BD was referring to moves of existing pages, cause that's where the risk for vandalism lies for new users, rather than in moving their own created pages. Equazcion •✗/C • 02:27, 9 Feb 2009 (UTC)

Page move vandalism break 1

• I think unrestricted page moves should simply be limited to rollbackers. As I stated above in the original discussion, the rollback rights group was created due to a similar concern -- that rollback permission had the potential for faster vandalism. Page moves entail a similar risk, so anyone we trust with rollback should be trusted with unthrottled move privileges. Autoconfirmed users without rollback could be prohibited from moving, or allowed in some very limited capacity. Moving pages is really not essential to new users, and most well-intentioned editors probably wouldn't even have the confidence to try it until well into their Wikipedia experience. Equazcion •✗/C • 21:43, 6 Feb 2009 (UTC)
  • There is a difference - a person without rollback rights can still "roll back" an edit, just not as quickly. However, a person without page move rights can only approximate a page move by cutting and pasting, which leads to duplicated pages and attribution headaches. bd2412 T 21:46, 6 February 2009 (UTC)
    • Then like I said, we can restrict moves for autoconfirmed users, only allowing unrestricted moves to rollbackers, so then it'll be a similar system. Equazcion •✗/C • 21:48, 6 Feb 2009 (UTC)
      • That has been proposed before, and shot down. What I have proposed is sort of a middle ground - restrict or throttle page moves for very new users (by time or by edit count) or users who have gone a long time without editing. bd2412 T 22:05, 6 February 2009 (UTC)
        • Well I guess I'm proposing it again, cause I think it's the best solution. Hey, I'm pretty sure rollback was shot down a few times before it was implemented too. Big changes take time to gain support. Equazcion •✗/C • 22:09, 6 Feb 2009 (UTC)
          • You propose to ban me from moving pages (move log)? Care to elaborate why? NVO (talk) 17:12, 7 February 2009 (UTC)
            • Of course not. Ban means you can never do it. I'm suggesting restrictions on non-rollbackers, not a ban. And besides which, you could always just request rollback. If you're a somewhat experienced editor in good standing, you'll get it. Equazcion •✗/C • 17:15, 7 Feb 2009 (UTC)
              • Why should I request something that's with me for the last two years? What's next, approving each edit? Fingerprinting? First they took my guns, my cigarettes next, and now ... my battery-operated love machine! It takes quarters! NVO (talk) 18:06, 7 February 2009 (UTC)
                • Because in addition to protecting your rights you also possess a passion for helping to protect the encyclopedia from vandals, and to that end you would accept the very minor inconvenience of having to put in a one-time request for a feature to be switched on for you permanently. Equazcion •✗/C • 20:33, 7 Feb 2009 (UTC)

Page move vandalism break 2

I don't like any of the proposed solutions: all this means is that pagemove vandals will change their patterns and continue vandalizing, while new users are inconvenienced. Pagemove vandalism is dead-simple to spot after the fact, so it's simple enough to have a bot watch for it, block the offender, move the pages back, and delete the redirects. --Carnildo (talk) 22:18, 6 February 2009 (UTC)

My rollback suggestion wouldn't have that issue, cause people would need to be approved by a live person to gain the privilege. That said, a bot sounds like a good idea, if malicious moves are that simple to detect. But if it really is that simple then why hasn't it been done yet? Equazcion •✗/C • 22:21, 6 Feb 2009 (UTC)

Indeed! If it is that simple to resolve, then why are we dealing with nonsense like this: [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17]. bd2412 T 22:30, 6 February 2009 (UTC)

Because such a system is reactive rather than proactive. If you look at the logs, the user was detected, blocked, and reverted in less than 60 seconds. --Carnildo (talk) 01:29, 7 February 2009 (UTC)

That does not seem to have dissuaded the vandal, who was able to make over sixty page moves from those collective edits (counting talk pages, that's 120 pages that had to be moved back). Anything that slows a sleeper down would have cut the repair work substantially. bd2412 T 01:44, 7 February 2009 (UTC)

*Actually, 158 pages were moved in this latest streak. I went back and counted. bd2412 T 01:49, 7 February 2009 (UTC)

Hm, weren't we discussing possible solutions? You seem to now be questioning whether there's even a problem. The block was rather fast there, but that's not always the case. And the cleanup seems to have taken a bit more time. Also, the reverts were easy in this case because the redirects weren't edited afterwards. Many move vandals know that reverting moves is more complicated if the redirect has a history, since in those cases an admin needs to manually delete the redirect and then move the page back. In any event, it seems plain that move vandalism is a more serious problem than ordinary vandalism, as evidenced by the multitude of times this issue appears at Village Pump. The multiple steps required to correct move vandalism, often requiring an admin rather than just any user, and the fact that page moves are a separate right that we could restrict, makes a preemptive system something to consider. Although again, a bot sounds good too, if one can be written to reliably detect move vandalism and perform all the necessary steps to correct it, even when the redirects have been edited. Equazcion •✗/C • 01:53, 7 Feb 2009 (UTC)

Yes, I'm questioning whether there's even a problem. 158 pages got moved in the past day? Almost all of them got reverted in less than 60 seconds? Is this really worth locking down the pagemove function for? --Carnildo (talk) 04:39, 7 February 2009 (UTC)

I think you might be just looking at the block, which was done rather quickly, but the actual reverting seems to have taken a bit longer. See here for example: [18]. And again, easy reverting of move vandalism depends on the vandal not touching the redirects afterward. Besides which I'm under the impression that most editors familiar with the issue are in disagreement with you, and do indeed consider move vandalism to be a problem that may be worthy of some additional restrictions on new users. Equazcion •✗/C • 04:51, 7 Feb 2009 (UTC)

Page move vandalism break 3

As has been said before, the reason rollbacking is fine is because it's simply a shortcut for what anyone can do ANYWAY. IPs can do the same function as a rollbacker, just with a couple extra clicks. Moving pages isn't like that. ♫ Melodia Chaconne ♫ (talk) 23:14, 6 February 2009 (UTC)

Right, so if we then restrict moves for most people, but allow it unrestricted for rollbackers, then it'll be the same system -- Most people will still be able to move pages, just not as "fast" (though technically, it would probably be "not as frequently"). Equazcion •✗/C • 23:28, 6 Feb 2009 (UTC)

A Few points:

1. I don't mean to boast but we do have a bot, as well as this at least two other admins run anti grawp bots on their main account
2. 10 edit limit is good, 25 is overkill. The 10 edit limit is good because it allows for detection of sleepers building up their editcount (the real problem is we don't have enough admins online who are able to pick up the sleepers when they do the sudden ten edit rush)
3. Throttling, this should be possible with the Abuse Filter
4. Sleepers, the real problem here is we need more checkusers around to dig out the sleepers when grawp starts moving
5. If we really want to get rid of grawp we need to contact his ISP --Chris 02:39, 7 February 2009 (UTC)

• I didn't know about that abuse filter thing. Sounds interesting. It seems like that could help significantly with all vandalism issues, including this one. Maybe we should wait and see how effective that is. Equazcion •✗/C • 03:12, 7 Feb 2009 (UTC)

As the Abuse Filter is still in progress, it's hard to say how it will work out until then. However, you should remember that it's main purpose is for serious Grawp-style vandalism only; basic vandalism is not a part of it cause the false positives would be really bad, in that case. ~ Troy (talk) 03:19, 7 February 2009 (UTC)

I like the throttling idea. It could significantly decrease the damage by a page-move vandal and it has create very little inconvenience - the only way I ever did more than 1 page move per minute is when I reverted a moving vandal. Regarding locking the pagemove permissions IMHO we have three different classes of articles:

1. User's own article (created by him) - he should be able to fix his own errors as soon as possible. In ideal world as his own second edit. Moving of those articles is of no interest to vandals.
2. Newly-created articles- they often need their title fixed. More people can help here the better. Not much interest of moving those articles from vandals as the new articles are hardly visible.
3. Established articles (say more than 1 year old with more than 5 editors). Every move of such articles is controversial. In an ideal world they should only be moved after an WP:RM by a closing admin. Strong interest of moving by vandals.

IMHO the software should be smart enough to separate those classes. 1 should be moved by everybody, 2 by somehow experienced users, 3 - only by rollbackers or even only by admins Alex Bakharev (talk) 08:56, 11 February 2009 (UTC)

I completely agree that the ability to move an article should be limited in accordance with the number of editors and the age of the entry. Keep in mind, I'm not seeking a prohibition against page moves, just a slowing down of the process for a very small class of inexperienced users (and possible vandals). bd2412 T 18:05, 18 February 2009 (UTC)

Page move vandalism - What about resetting the permissions?

I do not see that anyone has squarely addressed proposal #1, which is resetting the permissions of a user who has (a) made fewer than 50 mainspace edits, and (b) been completely inactive for a sufficient length of time (60 or 90 days). This would in fact encourage productive users to log in and contribute more often, as they would thereby retain those privileges. Cheers! bd2412 T 00:12, 9 February 2009 (UTC)

Wouldn't help. The sleeper accounts usually make the necessary edits right before they start moving pages. Mr.Z-man 00:16, 9 February 2009 (UTC)

I have certainly seen sleeper accounts "wake up" after many months and start making page moves right away. I was under the impression that a brand new account can not move a page for around four days. Is this not the case? bd2412 T 00:38, 9 February 2009 (UTC)

From my experience, they create an account, let it sit around for 4 days to several months, then make 10 edits and start moving pages. Mr.Z-man 00:54, 9 February 2009 (UTC)

If the permissions were reset after, say, 60 days, then the vandal who had let the account sit for more than two months would come back to find that they had no move permissions, any more than they could on their first day. bd2412 T 02:57, 9 February 2009 (UTC)

That's already the case. You need 10 edits and have an account > 4 days old to move pages. They leave the accounts to age for a while, then make the 10 edits when they're ready to start moving pages usually the same day. Resetting the permissions after 60 days wouldn't do anything, as there would be nothing to reset. Mr.Z-man 03:50, 9 February 2009 (UTC)

What I mean by resetting the permissions is that after no use for 60 days, the account reverts to the status of a brand new account - until an edit is made from it, at which point the four days would start running. So if the account requires four days plus ten edits, the sleeper account would revert to being treated as one that lacks the four days. bd2412 T 04:01, 9 February 2009 (UTC)

So all that means is they can't create accounts more than 60 days in advance, or whatever we choose the threshold as. That sounds even easier to get around than the 10 edit requirement. Mr.Z-man 04:04, 9 February 2009 (UTC)

No, no, no, that means that if they create an account and do not use it within 60 days, it becomes useless as a sleeper account. All of Grawp's accounts made last summer (and they do keep popping up) would be rendered useless as sleepers, because their permissions would be reset. He would not be able to wake one up and use it; he would wake it up to find it having no permissions, as if he had just created it that moment. That is what I am proposing. bd2412 T 04:20, 10 February 2009 (UTC)

This sounds like a good idea, with little or no downside. --Ckatz^chat_spy 05:07, 10 February 2009 (UTC)

All he would have to do is make an edit, wait sometime less than 60 and more than 4 days, make 9 more edits, and start moving pages. The downside is that nothing like this exists in the software, so it would have to be coded first, yet it provides virtually no benefit. Mr.Z-man 15:54, 10 February 2009 (UTC)

• Out of all of these proposals, I rather like the third one the best. This essentially would act as a better stopgap measure until the Abuse Filter arrives (any day now, hopefully) and educate new editors at the same time. NuclearWarfare _(Talk) 01:46, 9 February 2009 (UTC)
  • The third proposal is a three-parter. You mean 3-1, sending first-time page movers to an instructional screen to check off before they can engage in moves? bd2412 T 02:55, 9 February 2009 (UTC)
    • That could be easily bypassed using scripts. --Chris 07:40, 9 February 2009 (UTC)
      • Presuming that we are dealing with a vandal who uses scripts, or knows how to use them. Otherwise, it imposes a burden on the vandals with little or no cost to us. bd2412 T 03:46, 11 February 2009 (UTC)
        • Actually, I can think of a way to keep up the same rate of pagemoves as now, even by hand using tabbed browsing. It'll add a small amount of inconvenience (on the order of a few seconds depending on internet connection speed), but except possibly for some surprise the first time it happens, I don't see this having any effect at all on the amount, frequency, or rate of pagemove vandalism. Mr.Z-man 15:18, 11 February 2009 (UTC)
• This proposal would make it harder to vandalize, but it would not stop determined vandals. They would need only make 4 edits every 2 months to keep their sleepers active, and do it in such a way that it didn't arouse checkuser suspicion of all the socks if one sock was flagged. However, if it reduces the workload on vandal-fighters so they can concentrate on the most hard-headed cases, then it's a good thing. Just be aware of its limits. davidwr/(talk)/(contribs)/(e-mail) 16:08, 10 February 2009 (UTC)
  • Nothing will stop determined vandals. All we can do is make it harder on them. bd2412 T 03:46, 11 February 2009 (UTC)

Semi-automated translation of missing articles

The other day, someone made a change to the Meaning of life article, changing the linked word for Heaven in the Islamic section to Syurga. Because it was redlinked, I searched it on google to see if it might be a more appropriate link to have, and if I should created the article. Surprisingly, I see a wiki link on the first page, so I quickly clicked on it. Turns out the article was in Malaysian, so I couldn't read it, but it seemed odd that no article (or even redirect) exist in the English wiki.

So that got me thinking, a lot of other wikis have quality articles in different areas than the english wiki, be it local geography, biographies, books, films and such. And content in other wikis is most likely welcome in this wiki too, it just needs to be translated. So I wondered, what if there was a process setup between Wikipedia:Requested articles, the many wikis in other languages, and one of the many free translators. I envision an automated fetching system, where a bot takes a redlink from Requested articles, searches all the other wikis for that phrase (translating common words like of, in, the etc), then outputting possible results to a list, which includes links to different wiki articles, and if possible, a link to a free translator. There could also be some sort of suggest feature, where articles in other wikis could be selected for potential inclusion, and perhaps something that measures the length of existing English language articles and compares them to existing other language articles, and flags when the English one is shorter.

Keep in mind that no articles get created unless a human takes the translated content, fixes it up, and creates the article by hand. The only thing automated in this process is the suggesting, and the adding of links to pages and translations. Actually, it occurs to me that this process could work in reverse too, it could flag articles from the English wiki for inclusion in other language wikis.

I lack the technical expertise, as well as the wikicratic experience of "the process" that makes something like this come to fruition. Hopefully someone with more experience in these areas can chime in. --NickPenguin_(contribs) 03:23, 16 February 2009 (UTC)

There is Wikipedia:WikiProject Echo which posts on the talk page when articles are featured on other Wikipedias. I think the easiest way to identify topics on other Wikipedias with no corresponding English article is merely to take advantage of interwiki links, and look for articles with no en interwiki link. This could be used by a bot to generate a list of requested articles. However, this may turn up some false positives in cases of differences of article organization; for example, if the German Wikipedia happens to have spun out a separate page on 20th century history of France, do we really want a matching page? Not a bad idea though. Dcoetzee 19:01, 16 February 2009 (UTC)

You might want to take a look at the "Translation" topic in the Editor's index, particularly the subtopic "Moving information from other language Wikipedias to the English Wikipedia". -- John Broughton (♫♫) 20:31, 16 February 2009 (UTC)

User:Dr. Blofeld, User:AlbertHerring, and I are currently developing templates that can be applied to (mostly) stub articles that are in need of expansion from other wikis. See {{Expand Spanish}} for example. This generates an automatic link in the template to a machine translation of the better foreign-language article. I think this is the best way to go because it won't flood wikipedia with crap, helps translators find articles in need, highlights the need for translations to potential editors, and allows readers to easily access machine translations that they may find useful. Maybe in future a bot could detect which articles are much longer on other wikis, then apply these tags to our crappier articles. Calliopejen1 (talk) 17:59, 18 February 2009 (UTC)

Ah, I think you have the right idea! Rather than try and maintain a cumbersome list that no one will ever read, we use a template that adds articles to a maintenance category. But so far this is still a manual task, and it would be great if we could have bot assisted tagging. --NickPenguin_(contribs) 03:29, 19 February 2009 (UTC)

random images...

Like the already existing "Random article" button, it would be nice to also have a "Random images" button. Kingturtle (talk) 04:54, 16 February 2009 (UTC)

Special:Random/File. Algebraist 13:35, 16 February 2009 (UTC)

Needless to say this works with all other namespaces too. — CharlotteWebb 18:38, 16 February 2009 (UTC)

That's a link, not a button - if you catch my drift. A button would be the link, but placed on the sidebar or in another re-occurring, consistent spot. When I click the "Random article" button, I get a new article AND I get the "Random article" button again, on the same part of the screen. When I click on the link Special:Random/File I get a new File page, but I lose the link. Kingturtle (talk) 19:35, 16 February 2009 (UTC)

If this is something you want to do just for pleasure, the place to do it is Wikimedia Commons. They have exactly the persistent link that you're looking for, plus a lot more, often better, pictures (because the trend is to use Wikipedia primarily for fair use images). -- John Broughton (♫♫) 20:25, 16 February 2009 (UTC)

Perhaps KingT wants to use it to patrol for fair use violations? Really none of our business though, just saying… — CharlotteWebb 20:28, 16 February 2009 (UTC)

This will give you something like what Commons has:

addPortletLink("p-navigation", "/wiki/Special:Random/File", "Random file", "n-randomfile", null, null, null);

Or you can change it so it still says "image", doesn't matter. You would want to paste this at User:Kingturtle/monobook.js (assuming you use the monobook skin) then clear the cache of your browser. — CharlotteWebb 20:23, 16 February 2009 (UTC)

That has to go inside an addOnloadHook(function(){ }), of course. Algebraist 20:27, 16 February 2009 (UTC)

Okay. I figured out how to add Special:Random/File to my monobook. Thanks!! Kingturtle (talk) 14:09, 18 February 2009 (UTC)

Deliberate Misspelling Marker

I think there should be a marker for deliberate misspellings. For instance, Febuary would become double-curly-bracket misspelling|Febuary double-curly-bracket when explaining the misspelling itself. This would do nothing but allow deliberate misspellings to be excluded from the search results (should the user choose to do so). I've spent some time correcting typos and spelling errors using the search engine, and it seems to me this task could be easily automated if the misspelling marker were implemented so the bot could distinguish between deliberate misspellings and accidental misspellings and typos.

Misspellings and typos seem trivial, but I think that as a whole they detract from the professionalism of Wikipedia. For instance there are over instances of the misspelling "Febuary" on the English Wikipedia right now. --24.254.194.26 (talk) 03:50, 17 February 2009 (UTC)

Do you mean [sic]? --NE2 04:10, 17 February 2009 (UTC)

Or {{typo}}? עוד מישהו Od Mishehu 07:01, 17 February 2009 (UTC)

Yeah, “[sic]” has a very long editorial tradition. Readers know what it means, and it works in print. Replacing established conventions with novel technology is self-defeating.

By the way, which bot are you referring to? Please don't use unsupervised machines to make editorial changes. —Michael Z. 2009-02-17 17:14 z

In the article titled Nena, a song title is given as "Ich Kann nix Dafür". Recently someone corrected the spelling "Ich Kann nichts Dafür". I changed it back and added a commented-out note that it's an intentional misspelling—only those who edit will see the comment. In this case that seems appropriate; I don't want to see a visible [sic] there, although I'd usually use that. I'm not sure I can explain exactly why I want this to be an exception. Michael Hardy (talk) 17:42, 17 February 2009 (UTC)

Because it would be confusing? — neuro^(talk) 00:40, 18 February 2009 (UTC)

Perhaps. I wan't the sentence to flow smoothly. Michael Hardy (talk) 01:16, 18 February 2009 (UTC)

Okay, I was looking at the article on the {{sic}} template, and I believe {{sic|hide=y}} provides the functionality I had in mind. Michael (Hardy)? --24.254.194.26 (talk) 04:04, 19 February 2009 (UTC)

having 'centralized discussion' box in the 'welcome new user' template

it will jump start the new user's involvement and understanding of Wikipedia, and will bring fresh input on discussions from many more users. 212.200.241.153 (talk) 12:03, 17 February 2009 (UTC)

Alternatively, it will distract new editors from actually learning to edit, and will bring more edits by uninformed editors to the centralized discussion pages. (Also, I can remember the first time I came across WP:VP pages; most of the detailed discussions were simply unintelligible to me. It wasn't particularly encouraging, and I didn't return to the pages for what probably was at least a year.) -- John Broughton (♫♫) 20:40, 17 February 2009 (UTC)

On the subject of welcome messages, I think a lot of them need to be simplified instead. I've seen quite a few that are loud, vibrant, and bombastic, effectively drowning the hapless newbie with a barrage of text and color. Keep it simple, [insert appropriate word here]. —kurykh 20:47, 17 February 2009 (UTC)

I see little to gain by funneling users who do not yet know how the place works into major decision making. Let them find their way around before thrown into the lion's den. Chillum 03:28, 18 February 2009 (UTC)

Clearly a lot has to be improved to provide a simplified introduction, and at the same time a detailed introduction, which is more what we have today. With now a Billion people online, and NPR predicting the collapse of Wikipedia, and having to make a choice between content and collaboration, we need to stay ahead of the game and do both. While it is not necessarily a good idea for someone to find the edit link and click it to make a change without knowing some of the ramifications, it also could be a lot clearer what is expected. Currently all that appears at the top when anyone clicks "Edit" is a couple of warnings (You are not currently logged in, and Please do not save test edits), and nothing when someone is logged in - are we assuming that once someone has figured out how to register a username they know everything they need to know? I think everyone should get a link to Welcome to Wikipedia, thanks in advance for helping to improve this project; at the top when they click edit. Apteva (talk) 16:09, 18 February 2009 (UTC)

Straw poll

There is a new straw poll for granting crats the technical ability to desysop. Synergy 07:06, 18 February 2009 (UTC)

CheckUser Lite

Just brainstorming. What about a software feature that allows an admin to input two user names and the software would tell if the IP is identical. The IP would not be revealed to the admin, but it might reduce workload in some areas and make socking less likely. Thoughts? --MZMcBride (talk) 17:57, 18 February 2009 (UTC)

Wouldn't be the first time someone suggested it. It's definitely a good idea. —harej ;] 17:58, 18 February 2009 (UTC)

This would be a good idea, for dealing with trivial/obvious socking, and provide a grounding base for valid use of actual checkuser lookups. rootology (C)(T) 18:00, 18 February 2009 (UTC)

"Two users have used the same IP" is not sufficient information to make a judgement on whether the two are sockpuppets. The actual IP address being used affects this. — Werdna • talk 18:04, 18 February 2009 (UTC)

Scare quotes don't "help" things. --MZMcBride (talk) 18:18, 18 February 2009 (UTC)

True, but if their edits and interests also intersect, and they support each other... that's where this can come into play as useful. rootology (C)(T) 18:06, 18 February 2009 (UTC)

I second that - having the same IP can support a suspicion based on similar patterns of vandalism. bd2412 T 18:07, 18 February 2009 (UTC)

Two users edit-warring about a university from that university's IP address? You just don't know, and our problem is half-information leading to blind accusations leading to drama, not "not enough CheckUsers". If we don't have enough CheckUsers, appoint ten or twenty more. — Werdna • talk 18:09, 18 February 2009 (UTC)

Checkuser also can compare browser headers, which is no secret--that's all CU checks: IPs and browser headers. If two users from the same IP are using the same browser build down to the minutae to support each other, it's more than likely they are socks. It would be a good thing to make it harder for people to sock. rootology (C)(T) 18:11, 18 February 2009 (UTC)

Eh? I agree with Rootology. CUs are just going to see the private info, but either group isn't going to be able to make absolute determinations ("CheckUser is not magic pixie dust" and all that). This could actually limit the need for more CUs, which would limit the number of people having access to non-public data, a Very Good Thing in my mind. --MZMcBride (talk) 18:18, 18 February 2009 (UTC)

Same here. Plus, this would at least reduce the number of CUs that turn out negative, no? — Hex (❝?!❞) 18:25, 18 February 2009 (UTC)

This would be a very useful feature indeed, and it would allow the checkusers to focus on the more involved cases. --Ckatz^chat_spy 19:04, 18 February 2009 (UTC)

I forgot who I was discussing this with, but a year or so ago I was brainstorming a way for admins to be accomplish what they would need from a checkuser without being one themselves—but without disclosing anything too invasive. Now, granted, these are only very, very rough brainstorm ideas, so ideally don't shoot them down as bad/evil/whatever reflexively (I'm far from arguing for implementation any time in the foreseeable future), but instead contribute other ideas just to toy with the ideas:

• SpamAssassin-like similarity scoring system — if you had three or so users that were all doing the similar vandalism in a relatively short period of time (e.g., less than a few days), you could paste their usernames into a textarea and the backend could assign scores based on class B/C ip similarity, country similarity, registration dates across the ips, edit counts across the ips, etc. From there, an admin could propose a block to the system, the system could return an encompassing rangeblock (or set of small rangeblocks), and the system could return back the probability of others (and perhaps the number of others) getting caught up in a short-term block. It'd be really good if it could integrate with pluggable databases (like rbls and suspected proxy lists).

• Possible upsides: Preserves privacy; would be great for issuing very short term blocks (e.g., enough time for a checkuser to actually get to a request for a formal checkuser); reduces zOMG-need-a-checkuser-now demands on checkusers when there are vandal attacks; increases autonomy of admins while decreasing bureaucratic process involved in requesting checkuser for simple vandals/obvious edit warriors; logged to prevent abuse; could be easily restricted to a super-admin/sub-checkuser user level.
• Possible downsides: Since it's a blind block, greater possibility of accidental blocks (but in theory system would warn, and blocks would be forced short in duration); fishing; "magic number" doesn't necessarily mean same person/false accusations of puppetry; complexity of design + prettyifying + idiot-proofing + integrating with existing bureaucracy.

• More lax checkuser-granting to begin with. Somewhat derailing on a "checkuser lite" topic, but I think this is something that needs addressing and is inevitable for several reasons. Anyway, some background: coming with experience from analogous staff-level positions in irc and multiple other types of online communities, having someone's ip has always been second nature for me, so it's been a bit of a gear shift on Wikipedia to only have it half of the time. :P That said, I do understand and respect that those involved in editing value that highly and have always helped maintain others' privacy in my actions as an admin. Even THAT said, I do feel that as any only service grows in size, one thing seems to remain constant: more abuse happens, and as more abuse happens, staff must escalate their abilities in order to counter it. We saw it on IRC, for example:

1. In the early days, abuse was sparse and was handled with a channel ban or in rare instances a local server ban (kline). ircops (the equivalent of wiki admins) could remove users off the server ("kill" them), but server administrators (shell access on wikipedia) were the only ones who necessarily could modify their server's configuration files to add a server-wide kline (block).
2. As things progressed and simple bots emerged, the requirement for a way to more easily and quickly block abusive clients from servers became more urgent. Some ircds created kline commands that ircops could use that actually would modify the server's config file and add the ban without the server admin's action.
3. Networks of irc servers got bigger, and while one ircop could ban a user from his server, that user could simply hop onto another server and continue to wreak havoc on the same network. From here, global network bans (akills/glines; "global blocks" on wikipedia) started to be implemented. On efnet, a server had to opt in to glines, and from there, three ircops had to agree to ban a host/hostmask in a short period of time before the gline would activate. On other networks, only high-level admins or server admins were allowed to place glines autonomously, and usually only for fairly short durations (e.g., 1 hour).
4. With the advent of drones and other ddos coordination attempts, even more automation and increase in ircop abilities was needed. Connection monitors, which were local ircops ("adminbots" on wikipedia), kept an eye out for open proxies (remotely like User:ProcseeBot and the tor extension does) and clients that matched certain patterns (kind of like abusefilter does). G-lining permissions generally became more widespread to keep up with the disproportionate abuse that required such permissions, while most ircds implemented temporary klines (or "local glines") that could expire without intervention from the server administrator. To prevent user-to-user abuse, some networks implemented user host hiding, which hid the user's ip/hostmask information from non-ircops.

You can also see similar, parallel trends in bulletin board/forum software development, mmorpg network operations, and other popular online communities. So, while I do champion privacy, it eventually needs to reckon with overpowering abuse (while, ironically, at the same time, that ability to reckon also needs to reckon with preventing overpowering abuse from those reckoning with overpowering abuse).

I do favor expanding the checkuser right simply out of practicality, and, as it would have it, inevitability given my experience. However, we must still satisfy the second requirement— preventing abuse in that expansion. With that, if checkuser is to be more broadly given, I would highly suggest a stronger trust/verification process than simple RFA (naturally), but a slightly less rigorous process than the conventional CU approval process (which has basically consisted of only arbcommers and OTRS workers, which seems to create a group that's perpetually busy doing other things, :P :P :P). I think a good status quo compromise would be IRL-intensive verification (i.e., admins willing to submit to the proverbial anal probe of identity verification by submitting notarized documents to the foundation and/or IRL meetups). At least then we'd have uber-trusted, verified admins that don't necessarily have to love OTRS to be able to fight obvious ip-hopping vandalism or zap blatant socks. I understand that would select-out a portion of good admins unwilling to go through such an intrusive process, but it obviously wouldn't be required for normal administratorship.

Annnnnnyway, that's just brainstorming. Sorry for the ridiculously long length. :P

--slakr^\ talk / 20:00, 18 February 2009 (UTC)

Sorry, the proposal which was put forth initially is based on a misunderstanding of what CheckUser is and how it works. I'd suggest that if English Wikipedia needs more CheckUsers then more should be appointed. MZMcBride should review prior discussions about this before re-proposing a bad idea which has been rejected before.  — Mike.lifeguard | ^@en.wb 21:51, 18 February 2009 (UTC)

As Mike and I discussed elsewhere, the ultimate goal here is to reduce the current time, energy, and other resources that are being spent on sockpuppet investigations. Any efforts in this direction would be welcome. Generally, we've consistently tried to keep private info in as few hands as possible. Just adding more CheckUsers goes directly against this principle. And, I don't believe that throwing more (trusted and respected) people into the bottomless pit that is sockpuppet investigations is healthy for the project. --MZMcBride (talk) 23:35, 18 February 2009 (UTC)

Templates: AfDM and Dated prod

Both templates have the same background color, and the removal of one of these templates often leads to the insertion of the other one. A new editor, thinking it was the same template that got reinserted, will mistakenly remove the AfDM template, which is in violation of policy, but in the vast majority of cases an honest mistake.

To avoid confusion, I suggest that one of these two templates have a different background color. Since red is already in use on speedy deletion templates, I would suggest something bluish like this for the AfDM template. Anyone else has an opinion on that?

So this is actually a two-part discussion:

1. Do we even want such a change?
2. If we agree that a change must be made, what are the specifics of it?

-- Blanchardb -^{Me•MyEars•MyMouth}- timed 19:07, 16 February 2009 (UTC)

• By the way, the above link, which is to my personal sandbox, is not editprotected in any way despite what the page says. If you want to try a different color scheme please feel free to do so. -- Blanchardb -^{Me•MyEars•MyMouth}- timed 19:56, 16 February 2009 (UTC)

Behold the downside of standardizing the appearance of all these bloody templates. I kinda miss not having to read them to tell them apart. — CharlotteWebb 20:39, 16 February 2009 (UTC)

My current proposal looks like this:

-- Blanchardb -^{Me•MyEars•MyMouth}- timed 21:36, 16 February 2009 (UTC)

Looks fine. Not likely to have a similar template with the same background color, right? -Fnlayson (talk) 21:49, 16 February 2009 (UTC)

Not among the ones that matter. This scheme keeps the red sidebar (deletion process currently under way) and has a background dissimilar than {{dated prod}} and {{db-meta}}, which is all that matters. -- Blanchardb -^{Me•MyEars•MyMouth}- timed 22:03, 16 February 2009 (UTC)

I don't like the blue at all, it really goes agains Ambox conventions. If any other color is to be choosen for AfD, yellow would be the best alternative IMO:

— Edokter • Talk • 22:47, 16 February 2009 (UTC)

Both look horrible IMO. Is there any particular reason why a different background should be 'inflicted' upon all editors? I don't find the OP's original argument at all convincing. Happy‑melon 23:50, 16 February 2009 (UTC)

Unless you'd want to change the {{dated prod}} template instead? It is seen less often. The AfDM template is seen by virtually everyone who takes part in an AfD discussion. -- Blanchardb -^{Me•MyEars•MyMouth}- timed 00:27, 17 February 2009 (UTC)

In retrospect, I don't like either change. It should stay white. — Edokter • Talk • 02:41, 17 February 2009 (UTC)

You may wish to read about banner blindness. The human brain tries desperately to avoid reading these kind of notices. This is a case where familiarity truly does breed contempt. The eyes subconsciously move away from anything resembling a banner. Introducing icon art or differences in color or inner/outer shape can at least keep the templates distinguishable in users' peripheral vision. — CharlotteWebb 02:58, 17 February 2009 (UTC)

I think we should use different colors for the different deletion levels. It will help make sure that users notice that they are different. I, as a user who veiws an article which had been put up for deletion, shouldn't need to read the banner to know which deletion process is being used.

I also think that the XfD templates ({{AfDM}}, {{cfd}}, {{tfd}} etc) should all be the same color, since it's the same process. עוד מישהו Od Mishehu 06:42, 17 February 2009 (UTC)

Indeed, since speedy deletion templates have a devoted color scheme, why not make one specific to deletion discussions, or one for proposed deletions? Anyone else agreeing with Od Mishehu and I on the principle of this? -- Blanchardb -^{Me•MyEars•MyMouth}- timed 00:56, 20 February 2009 (UTC)