Jump to content

Wikipedia:Village pump (policy)/Archive 112

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

This page contains discussions that have been archived from Village pump (policy). 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, AS, AT, AU, AV, AW, AX, AY, AZ, BA, BB, BC, BD, BE, BF, BG, BH, BI, BJ, BK, BL, BM, BN, BO · 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

Wikipedia:Homosexual and related guidelines and policies - meta page for stating site-wide consensus on GL and related issues

Proposed page was deleted at MFD, so thread is moot. postdlf (talk) 02:44, 6 January 2014 (UTC)

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

Please note that Wikipedia:Miscellany for deletion/Wikipedia:Homosexual and related guidelines and policies has been initiated and your comments might be better served there. Killiondude (talk) 20:52, 27 December 2013 (UTC)

I've stubbed this little page (at shorty WP:HGI or WP:HRG) for site-wide meta discussion of issues related to Gay and Lesbian and related issues. I think its important to make editorial pages for issues-specific topics, if only to list where editorial discussions are taking place, and give non-partisans and birds-eye access to such discussions. A comment was left at the WT:LGBT page. Comments are welcome both here and there, as well as at the WT:HRG page. Regards, -Stevertigo (t | c, ed. 2002) 01:24, 27 December 2013 (UTC)

In answer to two comments delivered at WT:LGBT, I am crossposting my response here, to start discussion:
Sportfan, I don't see how this title listed should be regarded as "offensive," as it does not use inappropriate language or slang, and rather uses pretty standard terms like "homosexual" and "guidelines" and "policies." Htonl, I do not agree that containing all meta-discussion within the confines of a particular WikiProject is the right thing to do for any area where editorial policy needs to be discussed. In all but the most general cases editorial policy needs to be discussed with a broader audience, in the spirit of inclusiveness. I am crossposting this comment at the above WT:VPP talk page thread, where I will elucidate further. Regards, Stevertigo
Further comments forthcoming -Stevertigo (t | c, ed. 2002) 02:46, 27 December 2013 (UTC)
(Continued). My proposal is simply for sake of taking issues that might be related to GLBT issues and put them in an appropriately meta context. Some issues are politicized and should not be entirely controlled by advocates, such that the topic is contained within a context of a WikiProject that takes an advocacy point of view. Note that the proposed meta title of "Homosexual and related guidelines and policies" is open to criticism and suggestion as to an alternative. A title such as WP:LGBT guidelines might be possible, but I assert that this title is problematic for the simple reason that centralizing site-wide edtiorial discussion at a page that uses the "LGBT" initialism would ask those of us in the non-LGBT community to use an initialism from 'LGBT' advocacy and gender politics.
To put all discussion in the "LGBT" conceptual context, along with the rainbow flag, regardless of how accepted it might be within those who include themselves in said group, is to exclude others from discussion. To express this basic idea in a metaphor, we would not accept that all discussion about how to deal with Communism in editorial contexts should be owned by advocates for Communism, or that the page should be titled something like "WikiProject:Comrades Union," or "WikiProject:Worker's Group." Others can come up with their own metaphors. Note also that "LGBT studies" suggests that discussions come within a context of some greater implied "studies," which naturally are dominated by those with some accepted scholarship or expertise, when typically some affiliation comes with such expertise. This excludes others from these discussions. Regardless of the political issue, its important that meta-discussion be inclusive of non-'LGBT' points of view. Regards, -Stevertigo (t | c, ed. 2002) 21:49, 26 December 2013 (UTC)
Rejecting LGBT, all world-wide used acronym, suggests a troubling agenda, (note: this was in response to this version of the above comments) the obvious parallel is that we would not entitle an internal page under other offensive terms (fill in your own offensive examples here). We do use those terms on Wikipedia in limited ways to show how culture has evolved, and homosexual is an antiquated term when referring to people as a general rule. You'll find that most newer generations use a variety of self-descriptor terms but generally LGBT is an acceptable non-offensive catch-all. Sportfan5000 (talk) 03:14, 27 December 2013 (UTC)
(Edit conflict) (Note that I've edited down my above comments a bit). I disagree that the term "homosexual" is offensive. I disagree that the term "LGBT" is neutral, and suggest that the term is political and owned by those who who self-identify as "LGBT." Evidence for this is that the coinage of the "LGBT" initialism has gone through some changes, all of which have been governed by people who self-identify. That we can indeed accept the terms which ethnic groups self-identify with is an argument in your favor, but in this case the term is not an actual name, but a initialism, and one with controversial coinage as well usage. Also "LGBT" does not enter into the speech naturally in the way that "Gay" does, for example "Gay rights" does, and in context "Gay rights" naturally includes Lesbians (and related) as well. -Stevertigo (t | c, ed. 2002) 03:33, 27 December 2013 (UTC)
Why do you not believe the word homosexual is offensive? Many gay people find the term to be excessively clinical. I'd like to point out that the MOS:IDENTITY says, "When there is a discrepancy between the term most commonly used in reliable sources for a person or group and the term that person or group uses for themselves, Wikipedia should use the term most used in sources; if it isn't clear which is most used, use the term the person or group uses. (For example, see the article Jew, which demonstrates that most Jews prefer that term to "Jewish person".)" I don't even think that applies because LGBT seems to me to be easily the most common term used, and your argument seems to be more of a screed against excessive political correctness than a source-based inquiry, but still, there it is: if it's ambiguous, use the group's preferred term. I question whether you would advocate the same result for other terms that arguably apply to other ethnic and religious groups, but I will leave it at that. AgnosticAphid talk 04:22, 27 December 2013 (UTC)
  • I'm sorry, but this really does not make much sense. For example, the proposed title "Homosexual and related guidelines and policies" is ungrammatical. "editorial pages for issues-specific topics": Yes, those are called article talk pages. Why do we need policies and guidelines for one very specific sexual identity? What site-wide problem or deficiency is this attempting to solve?- MrX 04:27, 27 December 2013 (UTC)
  • Comment as someone who doesn't identify with either LGBT nor homosexual (but is also not heterosexual), I see the premise (it "came to mind with regard to recent discussion about male/female name changes" as misguided and I don't agree that LGBT excludes non-LGBT people from contributing or participating in dialogue. "Homosexual" as a person or behaviour refers to only 2 or 3 of those groups, and it's clinical, somewhat pejorative, and dated. I don't regard LGBT as in any way a perfect term, it's an ugly portmanteau, and its replacements are little better, but it at least signifies what it means: issues relevant to lesbians, gay men, bisexual and trans people. What actually does a policy on homosexuality have to do with a discussion on male/female name changes, unless one is assuming that trans people are intrinsically homosexual? Nsw2042 (talk) 05:22, 27 December 2013 (UTC)

Did this come out of the recent Manning naming dispute? Why do we need a policy on this? TeleComNasSprVen (talk • contribs) 07:38, 27 December 2013 (UTC)

I have to agree with that last comment... Before we determine what to call the policy, I think we need to have a fuller discussion on whether we want to have (or need to have) a policy on this at all. Blueboar (talk) 16:27, 27 December 2013 (UTC)
As a gay male who's been editing Wikipedia for several years now, I'm at a bit of a loss as to why we need this policy myself. But it's always nice to have another conversation thread I feel I should pay attention to. I guess this is Wikipedia's Christmas gift to me. :p DonIago (talk) 16:33, 27 December 2013 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

How does FRINGE interact with BLP?

This is just an FYI that a new paragraph has been created at WP:FRINGE to deal with the Treatment of living persons who hold fringe views. While I applaud the careful writing and effort of the eds involved, thus far I'm not persuaded that the new paragraph creates a tool instead of producing WP:CREEP, but your mileage may vary. Please consider sharing your views in the talk thread on point. NewsAndEventsGuy (talk) 13:56, 5 January 2014 (UTC)

Please!

See this! Thx! --SergeWoodzing (talk) 21:13, 5 January 2014 (UTC)

Sourcemonkeys

This WP:CNR goes to Wikipedia:Sourcehelpers, which was written and marked as {{Proposed}} by user: Stevertigo in March 2009, and never discussed or advertised onwiki for discussion. There was a short discussion (9 posts) on the WikiEn-l mailing list[3]. I assumed that it was a dead proposal, but user:Paine Ellsworth believes that proposal is alive and kicking still[4]. How long are pages like this typically allowed to be 'proposed'? John Vandenberg (chat) 04:37, 3 January 2014 (UTC)

🙈🙉🙊 Can't we just ignore it? 😃 Wnt (talk) 05:10, 3 January 2014 (UTC)
John Vandenberg: I think the relevant Policy section you are looking for is located at WP:PROPOSAL. Based on what you have said it sounds like this article was never tagged with {{rfc|policy}} and thus never got a proper chance at discussion as required. I would suggest either Paine Ellsworth or yourself
  1. add the {{rfc|policy}} tag,
  2. announce the proposal at WP:VPR,
  3. mention/link to the old off-wiki discussion at the beginning of the discussion (for historical reasons only, not to add any undue weight to the present discussion), and
  4. let the proposal process start now as it should have started then (i.e.: let nature take its course).
If -- after being given a real discussion -- then the last two paragraphs of this Policy sub-section should be applied and that will answer your concern about "How long?" for this proposal. Of course this is just my personal opinion. F6697 FORMERLY 66.97.209.215 TALK 06:41, 3 January 2014 (UTC)
  • I don't know what the strict answer to JV's question is, but IMHO, a proposal that went nowhere in the three years after it was created, not even getting discussed, is dead in the water. I've tagged it as historical. That doesn't mean the originator can't try again, but as it stands right now, that proposal is absolutely not alive. — Scott • talk 22:17, 3 January 2014 (UTC)
    "Historical" is usually used for pages that were actually accepted at one point in time. A page that was proposed and rejected is normally tagged as {{failed}}, or in some cases simply re-tagged as an {{essay}}. WhatamIdoing (talk) 23:22, 3 January 2014 (UTC)
    You are of course right. Thanks! — Scott • talk 11:49, 7 January 2014 (UTC)

Is there a policy on chronological ordering of movie/game/etc. credits?

Most articles on actors, musicians, and other people with large bodies of work have some form of list of work section, usually as a table. Michael Mando#Filmography is an example. When it comes to the ordering, I've seen them in two different styles, where the work is listed in 2009 > 2010 > 2011 order and where the work is (as in the linked example) in 2011 > 2010 > 2009 order (i.e. newest on bottom versus newest on top).

To be frank, I think that the way it's done in the page I linked to looks really, really stupid. A majority of articles use newest on bottom, and a few times when I saw newest on top I changed it to newest on bottom, but before I continue to do that, I wanted to know if there was a policy anywhere that commented one way or the other on ordering of works.

Thanks, Sven Manguard Wha? 18:14, 2 January 2014 (UTC)

The general consensus is that an encyclopedia article, unlike a resume or IMDb listing, lists such matters in historical chronological order (i.e., from beginning to end/present). I don't remember a specific chapter and verse (so to speak). --Orange Mike | Talk 18:36, 2 January 2014 (UTC)
I always find it surprising and even confusing to find the newest listed first. It just doesn't seem intuitive, maybe because English reads from top to bottom and so it should be more natural for a chronology to progress from top to bottom. I think top to bottom is the norm, and I'm fine with making that an express standard as I can't imagine a good reason not to do it that way. postdlf (talk) 18:38, 2 January 2014 (UTC)
I am not aware of any formal rule but I would go with oldest on the top since it seems more natural to me for the reason already mentioned, English speakers read from top to bottom.--174.93.163.194 (talk) 05:16, 3 January 2014 (UTC)
There's at least one article (Mort Sahl) that has a oldest-on-top discography and a newsest-on-top filmography right after each other, which looks bizarre to say the least. Anyway, oldest-on-top makes much more sense due to standard English reading order and the fact that it follows the general flow and direction of articles (a Legacy section would be further down the page than an Early Life, for example). Andrew Lenahan - Starblind 05:29, 3 January 2014 (UTC)
It's not a policy, but MOS:WORKS does state that list of works—which includes bibliographies, discographies, and filmographies—should normally be listed in chronological order of production. It also gives guidelines on how those lists should be formatted. Unfortunately, it is probably one of the most ignored MOS guidelines on Wikipedia. 24.149.119.20 (talk) 13:06, 3 January 2014 (UTC)
Be WP:BOLD and use WP:COMMONSENSE. A lot of the guidelines, like this one, are just statements of common sense, anyway. I just fixed Mort Sahl and Michael Mando#Filmography. —Ben Kovitz (talk) 19:18, 3 January 2014 (UTC)
I've seen several lists with oldest items first, especially in sports. I think that we should enforce making lists chronological. --NaBUru38 (talk) 23:31, 8 January 2014 (UTC)

Should Autopatrolled be "included" in Reviewer?

I assume there has been discussion of this in the past (because I can't possibly be the first person to think that being able to review the edits of others should mean your own contributions don't systematically require review), but I cannot seem to locate previous consensus that users assigne the Reviewer user-right should be not be automatically Autopatrolled. ☺ · Salvidrim! · ✉ 07:46, 5 January 2014 (UTC)

There's a fundamental difference, autopatrolled is for new page patrol, reviewer is for flagged revs/edits. You can easily make good edits but not write good articles. Really enwiki should just turn on RC patrol, but I can keep dreaming. Legoktm (talk) 09:16, 5 January 2014 (UTC)
I can see how it could make sense to grant autopatrolled to reviewers. Both involve a similar level of trust, and as you said, reviewers are expected to know Wikipedia policy well enough to review others' edits, so one would think they also know them well enough to not require review. But the thing is, there are two different kinds of review here. Autopatrolled exists to make new page patrol's job easier. NPP is all about reviewing entire pages to ensure they comply with policy and have no glaring problems. Reviewers, on the other hand, review individual edits to ensure they comply with policy before allowing them to go live. A reviewer is expected to be able to make good edits, but may not be able to write a good page from scratch. They're two different skill sets. Novusuna talk 18:59, 5 January 2014 (UTC)
Yes, they're different skill sets.
On the other hand, does anyone actually know of a person you'd trust with one but definitely not the other? I can't think of anyone that I'd accept one and refuse the other for. (Please don't name names here; just a yes or no is sufficient.) If, in practice, we don't need to keep them separate, then we could merge them or defaultly assign both to everyone (even though, in practice, far fewer people have any practical need for autopatrolled, because far fewer people create large number of pages). WhatamIdoing (talk) 22:58, 5 January 2014 (UTC)
I can think of users I'd assign autopatrolled to but not reviewer; trusting the user to follow policy in his own edits and trusting him to review the work of others on PC-protected articles are two things. I cannot think any cases where I'd grant reviewer and not autopatrolled, and as such nearly automatically approve their userright request unless there is evidence it shouldn't be done (mostly: deleted contribs to articles created), whether they've actually created 50 articles or not. ☺ · Salvidrim! · ✉ 23:04, 5 January 2014 (UTC)
That's interesting because the suggested standard for qualifications for autopatrolled ("prior creation of 50 valid articles") is far higher than for reviewer ("a reasonable editing history"). I've never understood the gulf between the two. Thincat (talk) 20:00, 6 January 2014 (UTC)
What we need from autopatrollers is a good reason to believe that the person won't create WP:CSD-able pages. But the benefit of granting autopatroller to most individual editors is low: the community gets a cost from every request (time spent reviewing the person's edit history to see whether he's created a bunch of pages that were speedy deleted or had other issues; it might take ten minutes per person), but the benefit only appears if the person actually creates pages—and even then, the benefit is low, maybe around 20 seconds per page the person creates.
So what we want is to only bother reviewing people who are creating large numbers of pages, so that the ten minutes of review time will eventually be repaid by saving patrollers' time. (I thought it had gotten lowered to 40...and even 20 is probably good enough.) WhatamIdoing (talk) 01:20, 8 January 2014 (UTC)
  • I trust that if Technical 13 creates a page, it doesn't need automatic review for unsuitability. NPP is backed up to last fucking summer, and every bit helps. I'd rather have the user-right be active and unused for trusted editors like Technical 13, then leaving them not-autopatrolled and potentially wasting the NPPer's time reviewing a page from a trusted editor. ☺ · Salvidrim! · ✉ 23:21, 8 January 2014 (UTC)
  • Feel free to fix my indentation because editing from mobile sucks. The answer is, articles aren't the only thing marked that "need patrolling" and all of the other ns add to the backlog as well and we should stop treating it as such. Technical 13 (talk) 23:25, 8 January 2014 (UTC)

Wikipedia:NO CONSENSUS and Wikipedia:NOCONSENSUS

Currently, Wikipedia:NO CONSENSUS and Wikipedia:NOCONSENSUS go to two different places, where there are overlapping but not identical explanations of what happens where a discussion does not yield a consensus. I propose that both of these titles should point to the same place, and that there should be a single consistent policy (not an "essay") on what it means when there is a determination of no consensus in various kinds of discussions. Cheers! bd2412 T 14:07, 6 January 2014 (UTC)

There's already a section in WP:CON on what happens when there is no consensus. Doesn't WP:NOCONSENSUS link directly to that section? -Well-restedTalk 14:55, 6 January 2014 (UTC)
Yes, it does. However, oddly enough, Wikipedia:NO CONSENSUS, which is different only by a space, links somewhere else - it goes to an essay that reflects some aspects of the section of WP:CON, but also goes off in other directions. bd2412 T 15:18, 6 January 2014 (UTC)
I wonder if this should belong at Wikipedia:Redirects for discussion as a problematic redirect. Too often RFD is de facto mistaken for "Redirects for deletion" rather than "discussion". TeleComNasSprVen (talk • contribs) 18:06, 6 January 2014 (UTC)
The problem is not the redirects, the problem is that Wikipedia:No consensus has one set of instructions, and Wikipedia:Consensus#No consensus has another. They overlap, but are not identical, and one is presented as policy while the other is presented as an essay. bd2412 T 18:33, 6 January 2014 (UTC)
In that case, I would consider merging the two and perhaps ditching the essay (it is only an essay after all, and they're considered to have less strength than actual policy), but that'd probably require more discussion and RFC-wringing. TeleComNasSprVen (talk • contribs) 18:39, 6 January 2014 (UTC)
  • The essay is older than the policy section. Some, but not all, of the shortcuts were found and usurped after the policy section was created. You may redirect any others you have found.
  • The fact that an essay gives a different view is, by definition, not "a problem". Essays are the #1 authorized and accepted place for editors to offer viewpoints or advice that contrast with policies and guidelines. WhatamIdoing (talk) 18:43, 6 January 2014 (UTC)
BD, I think a page move is fine, but you should suggest it on the essay's talk page. WhatamIdoing (talk) 19:35, 6 January 2014 (UTC)
I actually do prefer the notion of merging the parts of the essay that reflect policy into the policy page. Nothing to move. bd2412 T 20:18, 6 January 2014 (UTC)
I think before we do anything, we need to look deeper into the history of the essay. Check with its authors... why did they create it? Do they still agree with what the essay says, or do they now agree with what is in the policy.
Given that it predates the policy section, it is possible that this essay could be considered essentially a draft of what later became the policy section and deleted. The differences may be due to the fact that the policy has slowly evolved over time, while the essay was simply forgotten about.
However, it is also possible that it still represents a minority view on what should be done in "No Consensus" situations... in which case it should be kept (but perhaps renamed so there is less confusion). Blueboar (talk) 05:51, 7 January 2014 (UTC)
I have pinged everyone who has edited the page. Cheers! bd2412 T 14:46, 9 January 2014 (UTC)
  • Logged at essay WT:No_consensus: I have added the required thread at the essay's talk-page:
Discussion should be expanded there, as the issues have been centered around the essay, not an attempt to change the wp:CON policy here. -Wikid77 16:52, 9 January 2014 (UTC)

RfC on usage of Pending Changes level 2

Please comment at Wikipedia:Pending changes/Request for Comment 2014. Jackmcbarn (talk) 23:25, 8 January 2014 (UTC)

Original research?

The building in question

Just how strict is our original research policy these days? I recently went and took a photo of the historic former Methodist Episcopal Church of Port Hadlock, listed on the U.S. National Register of Historic Places. In fact, it turns out to be at the corner of Matheson & Randolph Streets, and its geo-coordinates are 48° 2′ 2.93″ N, 122° 45′ 23.52″ W (48.034148 N, -122.756533 W). Neither of these accords with the article (and, in fact, the street address given in the article, "Randolph and Curtiss Sts.", does not match the coordinates given in the article which is over a kilometre away). I would like to correct this with an accurate street address and coordinates, but I don't have a citable source. - Jmabel | Talk 06:02, 8 January 2014 (UTC)

Yeah... incorrect addresses and geo-coordinates is a common problem in our articles on NRHP buildings (especially the sub-stubs that only cite the NRIS database). The NRHP project is aware of the problem.
I see that the article does not cite any source for the (incorrect) address and geo-coordinates that it currently gives... which means that you can challenge the incorrect information as being Original Research. The question is whether you should simply remove the incorrect info (and, for now, not give any address or geo-coordinates), or replace the info with your own (more accurate) info (which is also Original research). I would suggest that you ask this question at Wikipedia talk:WikiProject National Register of Historic Places. They are the most likely people to know of some sources you can use to substantiate the correct info. Blueboar (talk) 14:38, 8 January 2014 (UTC)
(edit conflict) For geo-coordinates, I'd say the location itself counts as a primary source - anyone could verify them by walking by the building and measuring the coordinates with a GPS. Barring that, the coordinates could be referenced to several independent online maps (Google, Apple, Bing, OpenStreetMap ...) If the building appears in several of them with the same coordinates, that should be proof that the sources are reliable. Diego (talk) 14:39, 8 January 2014 (UTC)

religious and political propaganda and users that could perhaps be the same person

Hi, I'm not sure if this is the right place to ask these questions. If it's not, please accept my apologies and direct me to the right place.

1) Is religious and/or political propaganda allowed on Wikipedia? I've stumbled upon this and this and it seemed a bit strange.

2) Could these 2 users be the same person? If so, is that allowed?

Thanks,

Azylber (talk) 09:15, 5 January 2014 (UTC)

I can at least attempt to answer these questions. On the topic of religious/political propaganda, the relevant policies are Wikipedia is not a soapbox or means of promotion and neutral point of view. We have a duty to provide information on religious and political topics without promoting a particular point of view. (That said, the two pages you linked are user pages, not articles, so that doesn't apply.) As for the possibility that those two users are the same person, it seems very suspicious, and generally, it is not allowed. See the policy on sockpuppetry. There are legitimate reasons to have an alternate account, such as an account used on open wi-fi, or a bot account, but in such cases the alternate account should usually be disclosed on one's user page. I have no experience with the sock puppet investigaton process myself, but that is where cases of suspected sockpuppetry are investigated. I do hope I've managed to be helpful. Novusuna talk 19:10, 5 January 2014 (UTC)
Hi Novusuna, thanks for your answer.
So religious and political propaganda/attacks is allowed on user pages then?
As regards the fact that these users could be the same person, following your advice I've asked the question here
Cheers, Azylber (talk) 18:58, 6 January 2014 (UTC)
And what religious or political propaganda/attack is on other of those user pages? The fact that the both user pages have a single statement that support the Palestinians? In itself, a single statement isn't the same as being on a soapbox. As for them possibility being the same person, give the format of the user pages, that is a strong possibility. But unless the two accounts are disruptively editing the same set of articles, there is no point in opening an SPI case. SPI is for cases where multiple accounts are being used to disrupt Wikipedia. 24.149.119.20 (talk) 22:39, 6 January 2014 (UTC)
Well...no. The past few days have been quite busy for me, so I was a bit hasty in my first reply. User pages should still follow the user page guidelines, including a section on what cannot be on user pages. And personal attacks directed at other Wikipedia users are never allowed anywhere on the project. Novusuna talk 22:46, 6 January 2014 (UTC)
As 24.149.119.20 points out, though, the behavior of the user in question is not particularly disruptive, and they haven't done anything (that I can see) that could be considered a personal attack, so they aren't falling afoul of policy. Novusuna talk 22:49, 6 January 2014 (UTC)
I thought that it violates WP:UP#PROMO and WP:UP#POLEMIC, but I might be wrong. Azylber (talk) 00:32, 7 January 2014 (UTC)
Well, actually they seem to be a vandalism-only account (or, at best, have zero experience editing Wikipedia and showed zero ability in learning basic policies).--Ymblanter (talk) 10:50, 7 January 2014 (UTC)
Regarding the accounts themselves, it's rather obvious that Melody Nurramdhani Laksani (talk · contribs) is Robin Van Persie Aceh (talk · contribs) is (maybe) Isabella Leong (talk · contribs). This is not a case of sockpuppetry, but a case of sequentially abandoning an account to start another one. No comment on the userpages or account activities. Someguy1221 (talk) 10:56, 7 January 2014 (UTC)
First of all Paul William Walker (talk · contribs) is most likely also the same person. QED237 (talk) 12:53, 8 January 2014 (UTC)
@Someguy1221: You say "No comment on the userpages or account activities" but Melody Nurramdhani Laksani (talk · contribs) has been disruptive and even recieved a final warning for inserting the same material Paul William Walker is now inserting on his user page. Soccer matches that never will be played and is fantasy. QED237 (talk) 12:53, 8 January 2014 (UTC)
@Azylber: are you not supposed to notify the users? And I am thinking about adding Paul William Walker (talk · contribs). QED237 (talk) 12:54, 8 January 2014 (UTC)
@Novusuna: Is it allowed to open all these account when only one is disruptive? Now as I said an other account adds the info that was disruptive to his userpage instead. QED237 (talk) 12:53, 8 January 2014 (UTC)
As the user appears to be using the accounts sequentially, abandoning one account after creating the new one, they probably aren't violating the sockpuppetry policy. I can't say whether they're violating policies on disruptive editing, though they appear to mostly be editing in their own userspace. Novusuna talk 16:20, 8 January 2014 (UTC)
I agree that this is not a violation of WP:UP — it's two sentences, and if we started sanctioning people for this kind of thing, we'd have to sanction tons and tons and tons of people, with no particular benefit. By the way, Qed, there's no requirement to notify people that we're discussing them here. Nyttend (talk) 01:47, 9 January 2014 (UTC)
RCTI1989 (talk · contribs)‎ and KLIA1998 (talk · contribs) can now be added to the list. This since PWW moved some of the userpages to these "new" users. However these users are not new and have existed for a while so this person has been using multiple accounts on the same time. And there are warnings on the accounts for example edit warring, so I am about to consider it disruptive. QED237 (talk) 11:30, 9 January 2014 (UTC)
@Nyttend: I was more thinking about a notification for opening a SPI and not the discussion here. I thought you had to notify when opening a SPI? QED237 (talk) 11:30, 9 January 2014 (UTC)
I don't think it's completely required (you might need to start the report without tipping off someone), but you generally should. But I misunderstood you and thought you were talking about notifying about a discussion here. Nyttend (talk) 13:10, 9 January 2014 (UTC)
Hi guys, thanks very much for your answers. Azylber (talk) 14:16, 13 January 2014 (UTC)

Blanking a sockpuppet's sandbox?

User:Shabiha was discovered to be a long running sockpuppet account per Wikipedia:Sockpuppet investigations/Msoamu/Archive. Currently, User:Shabiha/sandbox is a duplicate of an older version of the Sufi–Salafi relations article. I searched the archive here and found a discussion that didn't seem definitive. I am not sure if WP:FAKEARTICLE covers this situation, and I am sure that Template:Inactive userpage blanked and Template:Discussion blanked don't apply here. Do we have any clear policy on whether or not that sandbox can now be blanked? MezzoMezzo (talk) 10:42, 12 January 2014 (UTC)

The same question goes for Portal:Sunnibarelvi, a fake portal, and User:Sunnibarelvi/sandbox. User:Sunnibarelvi was another one of the sock accounts discovered by the checkuser. MezzoMezzo (talk) 10:44, 12 January 2014 (UTC)
G5 deletions as created by a blocked or banned sock. Done. Dougweller (talk) 15:00, 12 January 2014 (UTC)
Alright, it seems that per Wikipedia:Criteria for speedy deletion, we can say definitively that WP:G5 covers such situations. Just posting here with the Wikilinks in case anybody searches for this in the village pump archive in the future. MezzoMezzo (talk) 04:16, 13 January 2014 (UTC)

Articles Juggalo, Juggalos (gang) violate NPOV

discussion copied to Talk:Juggalos (gang) —rybec 01:14, 14 January 2014 (UTC)

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

https://en.wikipedia.org/wiki/Wikipedia:NPOV states "Editing from a neutral point of view (NPOV) means representing fairly, proportionately, and, as far as possible, without bias, all of the significant views that have been published by reliable sources on a topic. All Wikipedia articles and other encyclopedic content must be written from a neutral point of view." The ACLU is suing the FBI over the categorization of Insane Clown Posse's fans as a gang. There is no evidence linking music fandom to gang activity. The article Juggalos (gang) should be renamed "allegations of Juggalo gang activity" or deleted/merged, to correspond with factual data on the ICP fandom. http://www.aclumich.org/Juggalos

It should also be noted that allegations of gang activity connected to ICP fans have origin in racism, as pointed out by an interviewer here: http://steed.bangordailynews.com/2014/01/09/rachel-healy-of-the-aclu-on-why-the-civil-rights-advocacy-group-is-getting-down-with-the-clown/

Who states; "What makes me nervous is seeing these emerging reports about the changing nature of gang affiliation, where affiliations are becoming much more fluid and less rigid than they were even a decade ago. Based on this changing scene, and these blanket assumptions of affiliation, the FBI and other agencies could ultimately justify going after any black or Latino kid in urban areas based on a suspicion of affiliation by proximity."

Is this really what Wikipedia should be encouraging by labeling ICP fans as a gang in spite of factual evidence proving that they are not a gang and lawsuits from ICP themselves and the ACLU? — Preceding unsigned comment added by ACLUSupporter1 (talk • contribs) 18:40, 13 January 2014 (UTC)

It should be noted that there are also significant problems with citations in the 'gang' article - it has largely been sourced to supposed official documents from law enforcement agencies uploaded to file-sharing websites - making the documents (some of which are evidently internal and unpublished) unverifiable. AndyTheGrump (talk) 18:55, 13 January 2014 (UTC)
Wikipedia's definition of "published" is "made available to the public in some form". I glanced at one of the documents; it says "UNCLASSIFIED FEDERAL BUREAU OF INVESTIGATION". Such documents are made available when someone files a request for them, are they not? —rybec 19:56, 13 January 2014 (UTC)
Available on request? Not necessarily, no. Explicit exceptions may be made regarding such requests if they concern law enforcement matters. In any case, we have no way of knowing if the uploaded versions are genuine or have been tampered with, and accordingly should be citing verifiable documents, rather than uploaded files of unknown provenance. AndyTheGrump (talk) 20:22, 13 January 2014 (UTC)
I don't agree with "in any case". In case an open records request should be denied, then yes, we might not be able to verify the documents. In case a request were fulfilled, the person who filed the request could compare the copy provided by the FBI with the uploaded one. We're supposed to use primary sources with extra caution; taking a quick look at the "(gang)" article, I see in the infobox the claims "Membership: 1,000,000+ non-criminal Juggalos; 100,000–150,000 Juggalo gang members"; it is footnoted to one of the primary sources, as well as to a newspaper article [5] which says

West Valley City Police Detective John LeFavor, who teaches a Juggalos class to police officers, teachers and social services workers at the Utah Gang Conference each year, said the majority of Utahns who define themselves as Juggalos are not violent. [...] LeFavor said police don't have a firm figure on the number of Juggalos in Utah, but said there are 'thousands.'

The newspaper account alone doesn't support the numbers in the infobox. —rybec 22:19, 13 January 2014 (UTC)
For all intents & purposes, this is a content fork, much in the same way it would be if we had one article for Hamas to focus on their socio-political aspects, and Hamas (terrorists) to make all the other side happy with a highlight on that angle. I detest both the music and the fan base, but this is absurd. Merge the stuff about the FBI and the gang classification into a paragraph or two of the main "Juggalo" article. Tarc (talk) 20:20, 13 January 2014 (UTC)

This really needs to be moved to Talk:Juggalos (gang), as this is merely a content issue specific to this topic, and currently no one who has that or Juggalo watchlisted is necessarily aware of this thread. Note also the prior discussion at Wikipedia:Articles for deletion/Criminal activity attributed to Juggalos. postdlf (talk) 22:42, 13 January 2014 (UTC)

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

Use the character's real name as disambiguator

WP:NCDAB mentions three options for parenthetical disambiguation, namely the generic class, the subject or context to which the topic applies, and an adjective describing the topic. So when I found the article Destiny (Irene Adler), I moved it to Destiny (X-Men), believing this is a better name. Then BOZ moved back to the original name, claiming "in the case of comics characters there are many examples of using the 'real name' as a disambiguator". I doubt whether such practice comply with the guideline.--Quest for Truth (talk) 17:43, 9 January 2014 (UTC)

Yea, the disambiguator term should be more generic that encompasses a broader topic of knowlegde - in this case "X-Men" is broader than just the real name of the character. In nearly all other areas of fiction works the disamb name is that of the work/franchise it is from. --MASEM (t) 18:21, 9 January 2014 (UTC)
There probably would need to be an RFC on this, as it is common practice when there are two more more characters by the same company. See Spider-Woman (Jessica Drew), Spider-Man (Miles Morales), Black Widow (Natalia Romanova), Black Knight (Dane Whitman), Ant-Man (Scott Lang), Spider-Woman (Mattie Franklin), Ghost Rider (Johnny Blaze), Captain Marvel (Mar-Vell), Ghost Rider (Danny Ketch), Mastermind (Jason Wyngarde), Night Thrasher (Dwayne Taylor), Nova (Richard Rider), Quasar (Wendell Vaughn), Thunderstrike (Eric Masterson), Union Jack (Joseph Chapman), and Yellowjacket (Rita DeMara) for examples. BOZ (talk) 18:43, 9 January 2014 (UTC)
But see, all that's isolated to the comic field. Arguably, I can see the cases of the above where you have the same superhero name from the same series but a different civilian name, and assuming each iteration is notable on their own, I would think the more appropriate disambiguation is to use the civilian name for the article, using "(comics)" or the series name for further disambiguation; this appears to be how its down for the various Robin (comic) comics, with the individual iterations being like Dick Grayson or Jason Todd. --MASEM (t) 19:27, 9 January 2014 (UTC)
BOZ's example all seem reasonable under both WP:COMMONNAME and WP:PRECISE.--TriiipleThreat (talk) 19:49, 9 January 2014 (UTC)
I don't think we can make a firm and fast "rule" here. How we disambiguate depends on WHY we have to disambiguate. In some cases, the reason is that two comic book companies have published books with the same name... and so we have to disambiguate which comic book company we are talking about... for example Captain Marvel (DC Comics) vs Captain Marvel (Marvel Comics)... On the other hand, sometimes what is being disambiguated are different "people" who took the same "hero name" (within the same comic universe). Then we have to disambiguate by person - for example Ant-Man (Eric O'Grady) vs Ant-Man (Scott Lang) vs. Ant-Man (Henry Pym) (all published by Marvel).
That said... I note that in the last example I just gave, the actual article title is at Henry Pym, and the disambiguated Ant-Man (Henry Pym) title is a redirect... As someone who is generally familiar with the genre, but not an avid fan, I think that is backwards. I find the format: hero name (civilian name) much more helpful and instantly recognizable than just the "civilian" name alone. With the former, I instantly recognize that the article was talking about a specific version of Ant-man... with the latter I would not have know what the article was about. Blueboar (talk) 20:57, 9 January 2014 (UTC)
Some characters, such as Henry Pym, Carol Danvers, Monica Rambeau, Jean Grey, Kitty Pryde, and others, have used multiple different superhero names over a long time, and/or are often referenced by just their civilian names (often enough, because they have had so many hero names), so we have the article moved to the civilian name. BOZ (talk) 21:17, 9 January 2014 (UTC)
I agree with BOZ. The character's real name as disambiguator has worked well for {{WikiProject Comics}}, when as pointed out above, there is more than one character of that name by the same company. The few instances where it does not apply, are when a character has gone by more than one superhero name. In those instances, it makes more sense for the article to use the character's real name. Fortdj33 (talk) 21:25, 9 January 2014 (UTC)
Right, I think Henry Pym has even been depicted more as Giant-Man (as he is currently) than he ever was as Ant-Man, and for a long time was even just Avengers supporting character "Henry Pym" without any superhero identity (as I think the '80's Official Handbook of the Marvel Universe listed him). postdlf (talk) 21:30, 9 January 2014 (UTC)

The example that started the thread, as well as the Henry Pym discussion above, highlight why we can't just impose across-the-board superficial uniformity without paying attention to the particulars. Not only is "Destiny" not an obvious fictional character name (let alone a superhero one), "Irene Adler" is the name of a Sherlock Holmes character that's not only a much earlier use, but a prominent part of the current American and British TV series adaptations and the recent feature films. So even if in many cases "[SUPERHERO NAME] (ALTER EGO)" makes perfect sense, it clearly doesn't always. postdlf (talk) 21:30, 9 January 2014 (UTC)

With respect to the case in question, Destiny (X-Men) suggests (to me, at least) that the character is a member of the X-Men, rather than than the foe she actually is. bd2412 T 21:48, 9 January 2014 (UTC)
Is there anything wrong with Destiny (Marvel Comics)? Another Destiny in a different Marvel title, or some such? There's no need to be more specific than necessary, especially in the comics world, where characters do crossovers between different titles/story arcs all the time. --Trovatore (talk) 21:58, 9 January 2014 (UTC)
There are at least two other Marvel characters who have used that name, even if they are not as notable. If anything, Destiny (Marvel Comics) would make a good disambiguation page, but it is superfluous with Destiny (disambiguation), which is why it is a redirect. BOZ (talk) 22:14, 9 January 2014 (UTC)
Those other two characters are incredibly obscure by comparison, such that the primary meaning of "Destiny (Marvel Comics)" is overwhelmingly the mutant character. Surely a hatnote to the disambiguation page is enough for the other very minor meanings. postdlf (talk) 22:27, 9 January 2014 (UTC)
I think that might be a failure to follow the spirit of the guidelines; I would expect to see in the disambiguator a short phrase that identifies what the page is about without knowing anything about the topic so that anyone can disambiguate the page (as necessary). These real name disambiguations fail that criterion. In this case, I would much rather see Destiny (X-men character) or possibly Destiny (X-men series character), if there is really a concern that "X-men character" might indicate the good guys. Which I also find flawed, as still speaks to the "I already know something about the topic, so I'm confusing myself"…. --Izno (talk) 23:29, 9 January 2014 (UTC)
Right, I agree with Izno. The current way assumes prior knowledge of the topic. For someone who is not a fans of the X-men series, the real name or the civilian name of the character is not a piece of useful information. A title like Destiny (X-men character) or Destiny (X-men series character) can at least tell that the character is from the X-Men series.--Quest for Truth (talk) 16:16, 10 January 2014 (UTC)
Part of the problem with characters in Marvel Comics is that they fictionally exist in the "Marvel Universe" – that is, there are many characters in the same fictional world, and they can each be featured in each other's stories. Doctor Doom is primarily an enemy of the Fantastic Four, but he has fought the Avengers and the X-Men plenty of times, so do we consider him only a Fantastic Four character? Magneto is primarily an enemy of the X-Men, but he has fought the Avengers and Fantastic Four plenty of times, so do we consider him only an X-Men character? Loki is primarily an enemy of Thor and the Avengers, but he has fought the X-Men and Fantastic Four plenty of times, so do we consider him only an Avengers or Thor-related character? A disambiguator based on "this is the series where they appeared in more often than not" may not work as easily in Marvel Comics than it does in other series or fictional universes as it is somewhat arbitrary. BOZ (talk) 19:03, 10 January 2014 (UTC)
Interestingly the current titles of your exammples are properly named. Doctor Doom is the primary topic so it has no disambiguator. Magneto (comics) and Loki (comics) have ambiguity so they come with "comics" but not their real name as the disambiguator. Using "comics" is perfectly fine as it is a more general class so it complies with WP:NCDAB. If they are named as Magneto (Max Eisenhardt) or Loki (Loki Laufeyson) then I will question such naming.--Quest for Truth (talk) 18:17, 11 January 2014 (UTC)
Anyway, if it is necessary to choose one from several fiction titles, I would suggest use either the first appearance or the most often appearance as the criteria. It is open for discussion. Then make redirects for other titles.--Quest for Truth (talk) 18:24, 11 January 2014 (UTC)
...and when there are several versions of the same superhero identity published by the same comics company, then what? postdlf (talk) 18:35, 11 January 2014 (UTC)
Well, the Transformers world puts them in the same article, even the reincarnations with different names (e.g. Optimus Prime). Did you have distinct examples (that I might not be able to pick out from the above)? --Izno (talk) 01:27, 12 January 2014 (UTC)
In the case of the Transformers variants, they are (always?) basically adaptations of the same character in different series, plus the franchise as a whole is barely 30 years old, with none of the individual series lasting more than a few years, so there isn't much to write about the individual adaptations. The best analog to that in comics characters articles would then be the "in other media" sections (or sometimes separate articles) describing the adaptations of the character in cartoons, movies, etc.

That treatment doesn't work for what are actually separate comics characters who at one time or another took on the same superhero identity just like multiple actors all playing Hamlet. See Flash (Jay Garrick) and Flash (Barry Allen), both distinct characters despite the shared superhero code name and same basic power set. One article obviously would not work when the newest of these characters debuted nearly 60 years ago (Flash (comics) gives an overview of the "franchise"), and a more general "DC Comics character" disambiguator would not work when they are from the same publisher and even exist in the same continuity (so share a world and have appeared together in stories occasionally). On the other hand, the Wally West Flash character is titled by the "civilian" name, probably because he was "Kid Flash" for many years and so hasn't had just one superhero name throughout his publication history (as have the various Robin characters, such as Dick Grayson, Tim Drake...), unlike Jay Garrick and Barry Allen, who have each only been known as the Flash. See also Alternative versions of Superman to see how complicated it can really get, with different periods of the same character's long publication history retconned into different characters living on parallel worlds (such as Superman (Earth-Two))... So we just come back to the fact that there is no one-size fits all solution. postdlf (talk) 18:37, 13 January 2014 (UTC)

I don't think anyone is arguing that there is a one-size fits all. However, let's take Flash as an example: You could still disambiguate by the year of introduction, as is common for ordinary people, ships, and video games. Flash (1940 comic character) and Flash (1956 comic character). --Izno (talk) 21:01, 18 January 2014 (UTC)
Other than what Izno suggested, the "Natural disambiguation" can be used, that is when the identity is shared by different character, use the civilian name. Instead of Flash (Jay Garrick), one may simply use Jay Garrick where the civilian name has no ambiguity. For Flash (Barry Allen), since Barry Allen is ambiguous, then Barry Allen (comics) can be used.--Quest for Truth (talk) 22:38, 18 January 2014 (UTC)

Keeping it honest - Proposal to REQUIRE talk page thread before using POV tag

Not sure which pump was best for this... I put it here because the idea seeks to support our policies at minimizing disruption.

Your opinion on an idea are invited at

Template_talk:POV#Keeping it honest - Proposal to REQUIRE talk page thread before using POV tag

NewsAndEventsGuy (talk) 13:38, 17 January 2014 (UTC)

What exactly is "honest" about it? It's simple, if somebody puts on a POV talk but doesn't start a talk page discussion, then someone else can remove it. There's no need for extra rules here.Volunteer Marek (talk) 15:06, 17 January 2014 (UTC)
Per WP:MULTI please post all comments in the link in the original post. NewsAndEventsGuy (talk) 15:15, 17 January 2014 (UTC)

Academic Organization Notability

A discussion has been started at the Prof page. Comments sought. Alanscottwalker (talk) 16:42, 19 January 2014 (UTC)

Ukrainian Wikipedia

Dear English-speaking editors. To you a question from a citizen of Ukraine: what can you say about the criticism, the neutrality of Ukrainian Wikipedia? Thank you for your answer.--37.73.215.51 (talk) 17:37, 18 January 2014 (UTC)

What can we say? Clearly contributors here who speak the Ukrainian language might be able to offer personal opinions, but beyond that, the English-language encyclopaedia has no authority over other Wikipedias, and no remit to offer commentary on them either. Consequently, this isn't a policy issue as far as we are concerned, and not something that can be properly addressed here. AndyTheGrump (talk) 17:46, 18 January 2014 (UTC)

I'd say that there are probably so few significant English Wikipedians who speak Ukrainian language, to allow you to get any real idea of that. עוד מישהו Od Mishehu 14:00, 22 January 2014 (UTC)

Requested move

See this discussion. Alex discussion ★ 19:58, 23 January 2014 (UTC)

WP:FLORA vs WP:COMMONNAME

Is there a reason why we here on Wikipedia name plants using the scientific namesakes? For example Blue Spruce would be the commonname and not "Picea pungens", while Eastern White Pine not be "Pinus strobus". The reason why I bring this up is that we have animal articles using common-names (Guinea pig (not: Cavia porcellus) ) so what makes plants any different? The scientific names I can see as being confusing to those who are not familiar with the jargon. - Knowledgekid87 (talk) 20:05, 21 January 2014 (UTC)

WP:FLORA itself seems to answer your question, both to justify the presumed use of scientific name, and also to allow for the use of the common name in some instances ("when a plant is of interest outside botany"). The blue spruce article is located at the common name. postdlf (talk) 20:18, 21 January 2014 (UTC)
i believe this was decided by consensus at WT:PLANTS when deriving Wikipedia:PLANTS#Guidelines. You may want to post to WT:PLANTS for their specific input to this thread.
 — Berean Hunter (talk) 20:30, 21 January 2014 (UTC)
First... it will be helpful to note that there is a difference between Wikipedia's term COMMONNAME and what the rest of the world calls a common name (also known as the vernacular name or colloquial name) people often get this confused. By COMMONNAME, Wikipedia means "the name used by a significant majority of reliable sources"... not "the name used by the common folks". (Too prevent such confusion, I will use "vernacular name" when talking about "the name used by common folks").
With that explanation WP:FLORA actually makes some sense. Plants often have different "vernacular" names depending on where in the world you are. The same type of tulip might be known as "Witches Hat" in the Eastern US, "Poor Man's Rose" in the southern states, and "Prairie Tulip" in the mid-west. However, in all three locations it is also known by its scientific name. What that means is that the scientific name may actually more commonly used in reliable sources than any of the three vernacular names. And in such cases, the latin scientific name is the COMMONNAME. It happens so often that we can make a consistent generalized "rule" about it... a "convention". Of course there are always a few exceptions to such rules... but in general it holds true.
This does not happen nearly as much with fauna... the vernacular names for animals tend to be the same everywhere... Bengal Tigers are called "Bengal Tigers" no matter where you are. In these cases the vernacular names are used by more reliable sources than the latin scientific name is... so the vernacular name is the COMMONNAME.
Hope that helps explain why things are the way they are. Blueboar (talk) 20:39, 25 January 2014 (UTC)
👍 Like Great explanation. Additionally, the same vernacular name is sometimes used in different regions to describe different plants. See Strawberry tree for example, though there are much better examples. First Light (talk) 21:41, 25 January 2014 (UTC)
Thanks for the kind words .... Since this isn't the first time this confusion of terms has come up, I have added something about it at WP:FLORA... it probably needs tweaking, but it may help. Blueboar (talk) 21:54, 25 January 2014 (UTC)
That's a big improvement. I just did some minor tweaking. First Light (talk) 00:09, 27 January 2014 (UTC)

Is it wrong to use thumbnail in infobox?

I noticed there's an administrative page named Category:Pages using infoboxes with thumbnail images as if this is wrong and should be corrected. Should I be using something like |175px instead of |thumb when putting an image in an infobox?Weeks1956 (talk) 14:20, 25 January 2014 (UTC)

  • The "thumb" parameter creates a image with a frame and caption box, even if you don't provide a caption, looks visually odd. If you need a caption, nearly all infoboxes that include an "image=" parameter include a "caption=" parameter for this. As to the size parameter, it depends on the infobox type; many infoboxes are aimed for 250px images but this is not a fixed value across the board. But setting the pixel size rather than thumb is absolutely correct. --MASEM (t) 14:53, 25 January 2014 (UTC)
  • There's nothing wrong with it, but I'm certainly of the opinion that it's better when infoboxes receive only parameters for constructing images, e.g ones with names like image_file, image_size, alt, and caption. It's cleaner code (parameters are atomic) and it ultimately produces something that looks nicer. I'll have to check out this category. :) {{Nihiltres|talk|edits}} 14:58, 25 January 2014 (UTC)
  • I'm of a similar opinion as Nihiltres here. The infobox templates should all be getting the parameters and constructing the image call. Thumbnail should almost always be used instead of setting a fixed parameter for image size because of the wide array of screen resolutions that readers visit from. 500px may be way too big for someone running at 640×480 and way too small for another person running at 1920×1200 or finer... It's best to let the MediaWiki software decide what size the image should be. Someday I'll get good at Lua and modify the module to strongly advise against entering actual dimensions into infoboxes. Anyways, happy editing! Technical 13 (talk) 15:15, 25 January 2014 (UTC)
I think that you and Nihiltres disagree. He says, "It's better to use this:
{{Infobox
| image=File:Example.jpg
| image_size=200px
| alt=An image of an example
| caption=A boring image
}}
You, on the other hand, are saying, "It's better to use this:
{{Infobox
| image=[[File:Example.jpg|thumb|alt=An image of an example|A boring image]]
}}
These are opposites. Most editors support the first option, not the second. The first option is far and away the normal method. The second mostly appears when someone inexperienced copies a new file into an infobox. (And it's pixel density, not the number of pixels in any given dimension, that determines whether something is too small. 500 px is too small when it produces an image that's an inch across, not when it produces an image that is only a quarter the width of a very large screen.) WhatamIdoing (talk) 16:34, 25 January 2014 (UTC)
  • Nope, I think it should be:
{{Infobox
| image=Example.jpg
| image_size=200px
| alt=An image of an example
| caption=A boring image
}}
as well. But, I think that {{Infobox}} should take those parameters and do something like:
[[File:{{{image|Example.jpg}}}|{{{image_size|thumb}}}|{{{alt|An image of an example}}}|{{{caption|}}}]]
so that the template always uses thumb by default (the actual code would be a Lua implementation of a much more complex system of parser functions to determine when which parameter should be used and how resisting actual defined sizes). Technical 13 (talk) 18:14, 25 January 2014 (UTC)
  • Why not omit both thumb and image_size? Then the server will decide the correct width for the infobox and will scale the image to fit optimally within that width.
{{Infobox
| image=Example.jpg
| alt=An image of an example
| caption=A boring image
}}
The problem with specifying image_size for an infobox is if you make it too small the image has unnecessary air around it and if you make it too big, the infobox ends up wider than it needs to be. (And the problem with "thumb" is you get a space-wasting, sort-of-funny-looking box around the image.) So leave them both out. Weeks1956 (talk) 18:49, 25 January 2014 (UTC)
  • Omitting image_size and letting the server make the decisions works well on phones, too.
Imagesize Result on PC Result on phone
=50px tiny image (bad) tiny image (bad)
=220px 1/8" white on each side (good) 1/4" white on each side (good)
=500px infobox bloated, impinges on article (bad) full width of phone screen (good)
=thumb grey box and image off center (kinda bad) light grey box around image (kinda bad)
(omitted) 1/8" white on each side (good) same as 220px 1/4" white on each side (good) same as 220px
So I'd argue that omitting the image_size in an infobox is best: the result is just as good as if you'd nailed the px number but there's no risk of getting the px number wrong. Less work, good-looking results on PC and mobile, no risk. Weeks1956 (talk) 20:33, 25 January 2014 (UTC)
That simply doesn't work. When I try it with Media:Saint Petersburg Florida Panorama.jpeg I get an image so huge it have to scroll across almost three pages wide worth of screen on my mobile. It doesn't scale the image...
I believe that the result you get when you skip the image size depends a lot on the infobox template and sometimes on the other contents of the infobox. WhatamIdoing (talk) 16:45, 29 January 2014 (UTC)

Wikipedia:Follow all rules

Just came across this. Nominate for deletion?... Keep as is?... Mark as an essay?... Promote to Guideline?... Promote to Policy and make it the 6th Pillar? Please advise. Blueboar (talk) 20:05, 25 January 2014 (UTC)

Wikipedia:Citing IMDb has been marked as a guideline

Wikipedia:Citing IMDb (edit | talk | history | links | watch | logs) has recently been edited to mark it as a guideline. This is an automated notice of the change (more information). -- VeblenBot (talk) 02:00, 30 January 2014 (UTC)

Where was the consensus discussion? DES (talk) 02:12, 30 January 2014 (UTC)
I un{{guideline}}d it as a disputed action. DMacks (talk) 02:13, 30 January 2014 (UTC)
I'm going to take a wild guess and assume the user wanted to add a shortcut, not promote to guideline, and either messed up the copypasting from another guideline or didn't know shortcuts could be added to the {{essay}} template. No harm done. ☺ · Salvidrim! · ✉ 03:36, 1 February 2014 (UTC)

Text content on redirect pages

Is there a policy or guideline that supports making text from Category:Redirect templates visible on redirect pages? For example, the redirect Soccer has a significant amount of text for not being a Wikipedia article. Also, the text is redundant. The page says at the top "A redirect page from Wikipedia, the free encyclopedia" Right below that, it says "This is a redirect from a title that is another name", "This page was kept as a redirect." and "This is a redirect." Redirects aid navigation and searching. All that text does not aid navigation and searching and perhaps we should changes things so that all that text can be/is put on the redirect talk page if needed. -- Jreferee (talk) 14:47, 2 February 2014 (UTC)

This text is entirely invisible to the user in most circumstances - they'll go directly to the target page unless something is broken or they navigate to it specifically (perhaps by accident). If they've got there by accident, eg through a multiple redirect or a ?redirect=no link, then the text serves to explain what's going on; if they are actually looking for it as a redirect page, then the text isn't really a problem as it's contextually meaningful for maintenance purposes. I don't think we'd gain anything by moving it. Andrew Gray (talk) 15:20, 2 February 2014 (UTC)

RFC: On the controversy of the pseudo-namespace shortcuts

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

My head hurts, having spent over an hour picking through this discussion. It's far more complicated and difficult to follow than it needed to be (which might be why it's been sat waiting for a close for so long), so I would beg participants to do closing admins a favour and make it easier for closers to work out who's commenting on what!

I make these conclusions based on my reading of the discussion and of some of the background (special thanks to John Vandenberg and Scott Martin for dredging through the history and summarising the result of a painfully large number of discussions, and to Thryduulf for coming up with a set of bullet points that people can discuss coherently):

  • There is consensus that new "pseudo-namespace" redirects ("MOS:", "T:", etc) should be strongly discouraged if not prohibited in all but exceptional cases.
  • There is just about a consensus that existing pseudo-namespace redirects have grandfather rights, and should not be deleted en masse.
    • Grandfathered redirects are not inherently immune from deletion, but their being a cross-namespace redirect is not—in and of itself—a reason to delete them. Any potential deletion of grandfathered redirects should be discussed on a case-by-case basis.
  • There is no consensus to treat such redirects (eg "T:" and "MOS:") as being as acceptable as "WP:" and "WT:", which work through software magic; whether the developers should be asked to make similar provisions for such shortcuts as they did for the project namespace is a matter for further discussion.
  • There is consensus that all such redirects should (as a general rule) point to a designated namespace (eg "T:" to "Template:" or "T:" to "Talk:", but we shouldn't have redirects to both namespaces beginning with "T:" as a general rule).
  • As a similar general rule, such redirects should be in matching pairs (eg if "FOO" points to "foobar", "Talk:FOO" should normally point to "Talk:Foobar").
  • The "MOS:" pseudo-namespace (for the Manual of Style) seems to have quite wide support, and is widely used.
  • The "CAT:" pseudo-namespace (for the category namespace) has less strong support an is less widely used, but could find support if somebody wanted to create an RfC for it.
  • Consensus is unclear on the specific removals and modifications of clauses suggested in the opening, partly because discussion moved on to more general issues.
    • The clause in Wikipedia:Redirects could possibly be altered to less strongly endorse pseudo-namespace redirects. A clause discouraging the creation of new such redirects could be added.
    • "May be used freely", in Wikipedia:Cross-namespace redirects, should be modified to discourage the creation of new such redirects.
    • There is no consensus for any list of circumstances under which such redirects are encouraged/discouraged/permitted/restricted. Further discussion is needed if such a list is desirable.
    • There is no consensus for the removal of the clause in Wikipedia:Pseudo-namespace.

—HJ Mitchell | Penny for your thoughts? 19:18, 3 February 2014 (UTC)

Note: clarification regarding "MOS:" and "CAT:". HJ Mitchell | Penny for your thoughts? 20:28, 4 February 2014 (UTC)

Background: There has been a recent spate of discussions surrounding the nature of the pseudo-namespace shortcut redirects lying around the mainspace. These discussions have proven to me that whatever previously established consensus regarding the existence of these shortcuts is now unclear. The most recent and foremost of these discussions was the controversial close at Wikipedia:Redirects_for_discussion/Log/2013_November_18#T:WPTECH which has led to this Wikipedia:Deletion_review/Log/2013_November_26 (and which still needs outside input for proper closure). In that deletion review, I've noted several past discussions that were linked to by User:John Vandenberg:

  1. Wikipedia:Perennial_proposals#Create_shortcut_namespace_aliases_for_various_namespaces
  2. Wikipedia:Redirects_for_discussion/Log/2010_December_6#T:
  3. Wikipedia:Redirects_for_discussion/Log/2013_September_10#CSD:G1
  4. Wikipedia:Requests for comment/CSD pseudo-namespace
  5. Wikipedia:Redirects_for_discussion/Log/2010_December_29#T:
  6. Wikipedia:Redirects_for_discussion/Log/2010_July_6#T:APPLE
  7. Wikipedia:Redirects_for_discussion/Log/2011_August_17#T:DEFCON
  8. Wikipedia:Village_pump_(proposals)/Archive_68#Proposal_for_an_alias_to_templatespace

plus a variety of admin actions summed up by him:

People regularly delete T: CNR, such as user:Amalthea speedy deleting T:Asbox. user:MSGJ speedy deleted T:APPLE, saying "sorry these are not allowed", it was taken to CfD by user:Xeno who used the rationale "Recently created, unnecessary cross-namespace redirect. The banner template is not linked often enough in discussions to require placing a redirect in the mainspace." [and talked about the syntax problems which were repeated in the discussion we are now reviewing]. In response, the creator of the template (user:Mono) agreed and it was speedied again. user:Thumperward successfully argued here that T:DEFCON that be deleted despite other CNR because "We shouldn't encourage people to drop new cross-namespace redirects into the mainspace unless they're genuinely considered to be a good idea." user:Ruslik0 deleted it. user:RHaworth speedy deleted page T:IBT. Back in 2007, user:RockMFR batch nominated 5 C: redirects and 3: T: redirects arguing that lack of incoming links was sufficient and noted that "C: and T: are not usually used as pseudo-namespaces for shortcuts." With only User:delldot and User:Gavia immer commenting, both in agreement, User:JLaTondre deleted them. On the same page User:Radiant! nominates more C: and T:, which were all deleted. user:Tikiwont deleted T:ITN/C when User:B.Wind argued there were better shortcuts available. John Vandenberg (chat) 11:13, 5 December 2013 (UTC)

In the same discussion User:Jreferee suggests:

Both you and DePiep made good arguments in the RfD to exclude T: from the Wikipedia:Redirect guideline major exception. However, that cannot be done through an RfD. The change can be done by posting a request at Wikipedia talk:Redirect -- Jreferee (talk) 14:14, 5 December 2013 (UTC) My 14:14, 5 December 2013 comment you replied to was a suggestion to John on how to address the larger issue. The default length of an RfC is 30 days. Thirty days after posting a request at Wikipedia talk:Redirect to change the text as noted above can resolve the a larger issue. -- Jreferee (talk) 13:23, 7 December 2013 (UTC)


Thus in following his suggestion, I've decided to gain wider community input to clarify the pseudo-namespace issue and any policies/guidelines surrounding it. and I believe that the future construction of an RFC might be in order Before there is an RFC however, I wanted to discuss how the RFC might look like and what key points other than the ones I will list might need addressing, such as specific policy or guideline pages that I might have missed that might pertain to this issue.

The RFC I suggest is twofold:

  1. Specifically the language of certain pages, including WP:Redirects, WP:Cross-namespace redirects, and WP:Pseudo-namespace. In the deletion review, one editor cited the fact that my edit back in November 2010 was indicative of consensus and/or policy. While I do not recall what it was that prompted my change (the result of a different RFC perhaps), I still agree with the wording I had introduced. However, this point may need to be revisited. One editor also cites Wikipedia:Cross-namespace redirects as a reason supporting his position and although I noted that this was an essay and not policy, I feel that the last clause in the header "that pseudo-namespace redirects (CAT:, P:, MOS:, etc.) may be used freely" is a bit ambiguous. This definitely requires discussion, and as indicated on the talk page an editor once tried to remove the phrasing, only to have another editor object. Lastly the language of WP:Pseudo-namespace reads thus: "These shortcuts are mainspace shortcuts, but a pseudo-pagename is a combination of a redirect and a shortcut. To understand the appropriateness of redirects of this type, see Wikipedia:Cross-namespace redirects. Shortcuts are to a namespace what a redirect is to the mainspace, so all shortcuts are discoverable by looking for redirects." This is ambiguous because it refers to WP:CNR which primarily lists the reasons for/against deletion of such redirects rather than address the distinction between redirect and shortcut as implied, and the analogy is also somewhat vague and inadequate.
  2. The second part of the RFC (or a 2nd RFC might be needed) is that, in the event that there is a new consensus/policy which discourages these pseudo-namespaces, which of the pseudo-namespace prefixes at WP:Pseudo-namespace are allowed. Each of the prefixes will be decided on a case-by-case basis by the community, and the MOS:, CAT:, H:, T:, and P: prefixes will have their own header and their own sub-threaded discussions (again, only if part 1 results in a need for this discussion).

Please note that I am completely neutral as to the outcome of the deletion review in this proposal and am merely using it as background for this proposal. The only thing I am trying to do is, as suggested by User:Jreferee address broader issues about pseudo-namespaces that are not limited to the T-colons specifically and clarify existing consensus/policy surrounding them. Which I have reason to believe is unclear at the moment. TeleComNasSprVen (talk • contribs) 03:10, 19 December 2013 (UTC)

Wikipedia:Redirects
clause removed

"The major exception to this rule are the pseudo-namespace shortcut redirects, which technically are in the main article space. "MOS:" redirects, for example, are an exception to this rule."

Wikipedia:Cross-namespace redirects
clause removed

"and that pseudo-namespace redirects (CAT:, P:, MOS:, etc.) may be used freely"

Wikipedia:Cross-namespace redirects
clause amended to allow only under certain circumstances

"and that pseudo-namespace redirects (CAT:, P:, MOS:, etc.) may be used freely"
(circumstances to be discussed in the Discussion section)

Wikipedia:Pseudo-namespace
clause removed

"Shortcuts are to a namespace what a redirect is to the mainspace, so all shortcuts are discoverable by looking for redirects."

Discussion

It's always wise to revisit these issues, especially when there are recent discussions that reveal various new thoughts as well as to return to old, valued community consensus. I do not find vagueness in the lead of the essay on cross-namespace redirects or "CNRs". The longstanding community consensus is to keep older CNRs so as to not chance breakage of links that come in to Wikipedia from the vast Internet. Young CNRs, on the other hand, are discouraged. One type of CNR has, for a long time, been considered a major exception to the general treatment of CNRs – the pseudo-namespace shortcut redirect or "PNR". When the community consensus is that these may be used freely, it clearly means that consensus condones the creation of shortcuts in these pseudo-namespaces if and when contributors deem such creations to be helpful, useful and harmless. Also, the longstanding consensus means that while PNRs are generally considered immune to deletion, there may sometimes be good reason to delete specific PNRs that cannot be shown to be helpful, useful and harmless.

  • Helpful – it only takes one editor to create a PNR shortcut. I have found that there are some editors who create shortcuts (not just PNRs) that they think will be helpful to others, but that they themselves may never use.
  • Useful - (goes hand-in-hand with "helpful") during deletion discussions the page-view statistics are frequently cited to determine the usefulness of one or more PNRs. It was shown, though, in more recent talks that there are some uses of PNRs that will not increment page-view statistics. If, for example, a T-colon shortcut to a template is used in a "Show preview" screen to call the template, and then is erased before the "Save page" button is clicked, such very convenient usage does not show in the statistics. There may be more uses like this of which I am unaware. One measure of usefulness is the potential of PNRs to become full namespace aliases like "WP:" and "WT:", which are not in mainspace.
  • Harmless – some editors (to include myself) use this to challenge the deletions of PNRs. We are told at the Rfd to delete only "really harmful" redirects. Not one single editor has been able to show the harm that PNRs do just because they are in mainspace with the sole exception of "printworthiness", which is a determination of whether or not a redirect is suitable for a full printed version of this encyclopedia. PNR shorcuts are not suitable for such a printing, so all that we come across should be so tagged and categorized as "unprintworthy". At present, all PNRs have been so tagged with the exception of very, very new ones, because contributors who create them do not always know to categorize them. Statements have been made in recent discussions that are equal to or roughly equivalent to "PNRs contaminate mainspace". Then when challenged, they have not been supported with any explanation of what actually does make PNRs, or any given single PNR, "really harmful" to mainspace.

This subject was evidently a point of controversy many years ago, and the present wordings in the clauses above are the results of those discussions that surrounded that controversy. It should come as no surprise that some contributors continue to disagree with that longstanding community consensus. There is as I said no harm in taking another look at the controversy from time-to-time. Times, they do change, and so may community consensus if new information can be provided. Thus far, discussions have pretty much just rehashed old information, "reopened old wounds". If there is any new information that challenges the usefulness, helpfulness and harmlessness of PNRs, I have yet to hear it. – Paine Ellsworth CLIMAX! 02:35, 21 December 2013 (UTC)

  • I wont try to rebut Paine Ellsworth, as they have shown above that they refuse to acknowledge the many reasons given and show why PNR can be problematic. A fresh look at the cost/benefit is desirable, and the more important aspect of PNR for me is the future opportunity cost. Colon's are a special character in mediawiki software. As a PNR includes a colon (':'), each PNR reserves a prefix, that is extremely difficult to reclaim for a 'better' purpose. For example, the liberal and unrestrained use of the 'T:' prefix has meant it was used for Talk: pages, Template: pages, and Template talk: pages too. The defenders of these varied T: prefixed CNR often argue that T: should be automatically an alias for Template: , like WP: is an alias for Wikipedia:, citing benefits of easy of use, however they oppose any attempts to standardise the existing T: redirects so that this can happen. We now have the software to automatically make 'T:' an alias for Template:, just like WP: is an alias for Wikipedia: and WT: is an alias for Wikipedia talk: , but we cant use it because 'T:' is already used in the main namespace. All CNR pollute our content namespace, but CNR that include a colon prevent new languages, features and concepts being implemented. For example, 'mos:' is a language code for the Mossi language (spoken by 7.6 million), and 'cat:' is the language code for Catalan language. Catalan has a two letter code 'ca', so that language isnt in conflict with our use of 'CAT'. However there is no other code for Mossi language. The supporters of the MOS: prefix are effectively preventing English Wikipedia from ever linking to Mossi language Wikipedia content using the appropriate language code. That is a hard cost/benefit decision for me, but I personally support the 'MOS:' PNR for Manual of Style, as enwp could concoct a new code like 'iso639mos:' when a Mossi language Wikipedia is established.(not if but when! : Mossi is in the top 100 languages of the world by speakers). IMO, CNR which include a colon should only be allowed where there is a significant positive community agreement for a well-defined use/purpose. They are shorthand; we should agree on what that shorthand is. While not tested, I believe there is sufficient community agreement for MOS:, CAT: and P: PNRs. There has been regular dissent over H: and T:, because one group of the community believes single letter prefixes should be used for Wiki projects (like wikidata), and they havent been convinced that three letters saved from Help: by using H: is a sufficient usability gain compared to the cost. The case for T: to access templates, esp. template documentation is more defensible IMO, but if we want that then we surely want it to work for every template, which means we need an T: alias. John Vandenberg (chat) 02:19, 22 December 2013 (UTC)
    Superb! Mention should also be made of several articles and article redirects that use the colon in their titles, such as T: The New York Times Style Magazine, A: "Sorry" / B: "That's The Trouble", The Contra Adventure, "p:Machinery" and many more. I certainly don't mean to refuse to acknowledge any opinions given. I do reserve the privilege to disagree with those opinions, and if that is viewed as a refusal to acknowledge, then I admit that I have absolutely no control over your or anyone else's perception of my disagreement. Interesting read, John, thank you! – Paine Ellsworth CLIMAX! 08:42, 22 December 2013 (UTC)
I doubt if it solves any issue, but there is no such thing as a Mossi language. There is a Mossi people (tribe), based in Burkina Faso, but they call their language Moore (pron. Mawray). DrMennoWolters (talk) 21:42, 22 December 2013 (UTC)
That sounds like something that should be taken up at Talk:Mossi language, if anywhere. Anomie⚔ 22:09, 22 December 2013 (UTC)
Hi Dr Menno Wolters. I have started a discussion at Talk:Mossi_language#Mossi_vs_Moore. The point here is that the language with code 'mos' isn't a dying language, by any stretch of the imagination - it is in the top quadrant of languages, and we can expect a Wikipedia at http://mos.wikipedia.org/ 'soon' (hampered by Technology, then Education, but meta:WikiAfrica may help), in which case we would normally refer to its pages using the syntax 'mos:title'. John Vandenberg (chat) 00:58, 23 December 2013 (UTC)
I've never seen anyone use cross-namespace redirects in mainspace besides MOS:. I don't doubt that it happens, but it doesn't seem to be very common. Why don't we just ban all of them besides MOS:? We should probably even get rid of MOS: at some point (or make it a legit namespace). Kaldari (talk) 22:12, 24 December 2013 (UTC)
We do use "CAT:" for shortcuts to the category namespace; such titles are never used except as redirects. עוד מישהו Od Mishehu 09:15, 25 December 2013 (UTC)
"For example, 'mos:' is a language code for the Mossi language (spoken by 7.6 million), and 'cat:' is the language code for Catalan language." Except for the first character, titles are case-sensitive, thus mos:caps is distinct from MOS:CAPS in that they lead to different destinations. WP:SHORTCUT enumerates the accepted pseudo-name-space prefixes, all of which are in upper case. Hence mos: and cat: are fully available for cross-wiki linking. Even if that weren't true, Catalan has an ISO 639-1 code, "ca", which is what Wikipedia currently uses (e.g. ca:Portada is the home page of the Catalan Wikipedia.
Wikipedia-specific redirects may be tagged with {{R to project}}. Operators of mirror sites, and other reusers, may delete the contents of Category:Redirects to Wikipedia project pages and Category:Redirects to project space from their copies. The two categories contain around 4600 items (assuming no overlap), whereas the project as a whole has nearly 32 million pages. That's about 0.14% by quantity (less by size). If someone mirrors the site but neglects to tend to the cross-name-space redirects, then users of the mirror would reach a non-existent page if they attempted to open "MOS:HYPHEN" or whatnot. They might unexpectedly see Wikipedia: in a URL. —rybec 05:52, 11 January 2014 (UTC)
Interwiki prefixes are case-insensitive, for example DE:Foo. Note that "cat:" is safe though, since the interwiki prefix for Catalan is ca:. Anomie⚔ 20:12, 11 January 2014 (UTC)
(did discover this RfC only now - strange) I can agree with the reasoning of Vandenberg; I call it mainspace rot. At least this could lead to a conclusion of deprecation of such namsspaces (my niche being T: which has additional reasons): no new ones, no advertisement, provide alternatives.
A special word is needed for the arguments from history of these ns's. I get the impression that a grandfathers right was expanded to cover more that originally intended. It looks like the exceptions saettles in the core. I find it telling that out main page is supported by three prehistoric counter-definition redirects from mainspace. -DePiep (talk) 06:09, 27 December 2013 (UTC)
  • re Paine Ellsworth, the longstanding consensus means that .... Time and time again PE repeats this slogan, while others (like me) have pointed often enough that is is an essay with personal editors text injected (after if tellingly failed to gain any consensus, as a psoposal). Thus repeating that it represents or even defines a "consensus" is wrongfooting this discussion from post one. The essay is 'not describing any policy, guideline, or consensus. John in their original RfC post here described the existant abiguities far better. -DePiep (talk) 11:02, 15 January 2014 (UTC)
  • This is the most unclear RfC I have ever read. --SmokeyJoe (talk) 08:15, 27 December 2013 (UTC)
  • Sorry! I've been busy lately and haven't been keeping up with the latest developments here, but I basically wanted to format the RFC so we'd have separate discussions for each of the problematic clauses I wanted to highlight, but it looks like people are still speaking only in a general sense about the PNR issue, which was what this header was for. If there was consensus on removing some phrasing, I wanted to discuss which of the 5 PNRs we have right now people would consider acceptable. I guess I didn't really plan or look at how other RFCs were structured, considering we're getting very little discussion and it's perhaps I tried to tackle too many issues across various pages at once. I considered opening an RFC on each clause (on the talkpage of the page containing the clause), but figured that'd spread discussion out too thinly to address what I considered a sitewide policy-language issue. TeleComNasSprVen (talk • contribs) 09:19, 27 December 2013 (UTC)
    Thanks for getting the conversation started. John Vandenberg (chat) 11:52, 27 December 2013 (UTC)
I don't understand the discussion. I support keeping the shortcuts. --NaBUru38 (talk) 21:28, 27 December 2013 (UTC)
The discussion is about how policy pages should be edited to reflect the current status of these shortcuts: do we only keep the currently existing ones, do we allow creation of new pseudo-namespace prefixes, do we allow creating new shortcuts using existing prefixes. Right now the policies are quite vague. Keφr 09:13, 28 December 2013 (UTC)

We also need to discuss whether a pseudo-namespace shortcut redirect should point to a different target than the equivalent shortcut in the target namespace, and whether different capitalisation should point to different targets. We don't have many that break this rule. The last one discussed is T:MI vs Template:MI, which was discussed at Wikipedia:Redirects_for_discussion/Log/2013_December_15#T:MI_and_Template:MI, with an outcome of no consensus. On the same page was listed T:WPTECH and Template:WPTECH (outcome was: align them to point to the same target) and T:AD and Template:AD, which was relisted and is subject to an ongoing discussion at Wikipedia:Redirects_for_discussion/Log/2013_December_26#T:AD_and_Template:AD and is heading towards no consensus also. I havent looked thoroughly through the Portal namespace yet, but I assume there will be only a few problems there (as people dont usually create Portal:X shortcuts, so there are less opportunities for conflicts). However I have found P:BR->Portal:UK Railways and P:br->Portal:Brussels (what about Portal:Brazil??). Note that P:BR/P:Br problem doesnt appear on Wikipedia:Database reports/Cross-namespace redirects/4, so there may be a SQL bug in that database report. (however P:nj and P:NJ are both listed) John Vandenberg (chat) 12:40, 30 December 2013 (UTC)

I think the only thing that can be said is that there is no consensus to expand WP:CSD#R2 and so CNRs to the Category:, Template:, Wikipedia:, Help: and Portal: namespaces must not be speedy deleted simply because they are cross-namespace. Such redirects need discussion on their individual merits because some are useful and some are not, and differences of the T:MI/Template:MI sort are not inherently harmful (i.e. there are some circumstances in which different targets are fine and others in which they aren't). For a standard, I'd propose these simple tests

  1. Is the redirect plausible and plausibly useful? (evidence of use is evidence of usefulness)
  2. Is the redirect harmless? (assume yes in the abscence of evidence to the contrary)
  • If the answer to both questions is "yes" then the redirect should not be deleted.
  • If the answer to both is "no" then the redirect should be nominated for deletion or retargetting at RfD.
  • If the answer to one question is "yes" and the other "no", or either answer is "maybe" or "unknwon" then it should be discussed at RfD. Thryduulf (talk) 16:34, 30 December 2013 (UTC)
  • @Thryduulf: according to most of the deletion discussions which have occurred so far about the pseudo-namespace issue, which have in most cases resulted in no consensus, most people would be inclined to disagree with you merely on this criteria. For one, the issue of "usefulness" is a very limited and subjective criteria to judge a redirect by; it's been seen that even though one editor (User:Paine Ellsworth) has described it as useful, some of these deletion discussions have resulted in the cross-namespace redirect being deleted by the closing administrator regardless. Not only that, but the "evidence of use is evidence of usefulness" is also hard to determine: people in the deletion discussions argued that readers were taken out of Wikipedia mainspace and into project-space with much confusion, this would obviously show up in the stats reports for page views, but it also calls into question how this supposedly 'objective' and 'mathematical' measure of usefulness can really determine actual usefulness. The fact that it can be used to support both sides of a redirect deletion discussion proves that it's problematically ambiguous and ambiguously problematic.
  • In any case, as regards to your second point, I also wanted to start either a 2nd RFC or a 2nd part of the current RFC to re-examine all the current pseudo-namespaces to see which ones deserve keeping and which ones deserve discouragement or even outright deletion. That was part of this RFC that I never really got around to. In my personal belief, I think it's appropriate that people have been and continue to use the MOS: pseudo-namespace, at least until as John Vandenberg says a Mossi Language Wikipedia is created, and we would have to make room for that new interwiki-colon link. CAT is also sufficiently long enough that it is unlikely to cause confusion or have an article/redirect specifically prefixed with CAT. As to the P: pseudo-namespace, I was not too familiar with them, but I read up a bit on Wikipedia:Portal and according to that the Portal namespace is a bit like part of the main namespace broken into smaller chunks, so they can generally be allowed, although the ones that cause confusion (and thus harm) like noted above should be discussed as either retargeting or deletion. The rest of the pseudo-namespaces should go, but again that's only my personal opinion. And it's the reason I wanted to bring this issue to the larger community.
  • Onto your third point about the Criteria for Speedy Deletion, I note that it is peculiar the criteria never made mention of any particular pseudo-namespace targeting the various Talk namespaces, although there's one very obvious one (T:MP) that ought to be excluded for its sheer usefulness over its apparent harm. There do exist such redirects, and I believe they should be deleted, but it is not mentioned to be "excluded" per se from the CSD criteria, so we can use that to delete them.
  • Although I appreciate the attempt at a starting point for the criteria by which we can judge redirects at these deletion discussions, sadly they are already based off the current criteria at Wikipedia:Redirect and are not reflective of how the current consensus at these deletion discussions are judging said redirects. The community seemed to have formed its own criteria, and based on Wikipedia:Cross-namespace redirects have determined that in fact these redirects appear to bring more harm than good, not just on this criteria alone. But it's a good start so far. TeleComNasSprVen (talk • contribs) 09:12, 2 January 2014 (UTC)
We continue to hear about how these harmless PNRs are so harmful. For example, you write above, "readers were taken out of Wikipedia mainspace and into project-space with much confusion." Where is the confusion, exactly? Most readers are not even aware that PNRs are in mainspace. The shortcuts are often used like I use the one below. C:WRONG has already been used on talk pages in several situations because it is short, descriptive and much shorter than its target. I find it useful, and when more people begin to participate in the work of redirects, they will find it useful, too. In fact, I would wager that many of the people who do not understand the usefulness and harmlessness of these PNRs rarely if ever work with redirects. Most people find it tedious work and would rather write articles and be involved with arbcom. Those of us who work with these almost everyday, and not just at RFD, have no problem with them and find them quite useful and harmless. They are so useful and harmless, in fact, that I find it hard to believe that such a frenzy erupts each time there is a listing at RFD. Sorry, but there are far more harmful and pressing needs here at Wikipedia than pushing to delete useful, harmless and cheap PNR redirect shortcuts. – Paine Ellsworth CLIMAX! 17:06, 2 January 2014 (UTC)
I think that you're misinterpreting me again. I am mainly quoting arguments made in other deletion discussions about how "readers were taken out of Wikipedia mainspace and into project-space with much confusion," the truth-value of that has yet to be evaluated. Whether or not something is 'useful' to a certain editor, namely you, does not invalidate the fact quite a number of these RFDs have resulted in the deletion of the redirect regardless of your saying that they're useful. When you question the 'harm', perceived or not, that these redirects have on the encyclopedia, I again point you to the arguments ad nauseum to delete at Wikipedia:Cross-namespace redirects. If you do not read and do not respond properly to the arguments, I have no choice but to take John's arguments above that you "have shown above that [you] refuse to acknowledge the many reasons given and show why PNR can be problematic". TeleComNasSprVen (talk • contribs) 06:18, 3 January 2014 (UTC)
  • I just encountered C:WRONG, created a few weeks ago by Paine Ellsworth, and to be honest, it strikes me as... wrong. I was going to raise it directly with Paine, but then noticed a link on their talk page to this discussion, from where I've learned that there are apparently lots of these "PNRs". I for one am of the opinion that the benefits of supporting the existence of an additional realm of alphabet soup, namely occasionally saving a few keystrokes, are vastly outweighed by the detriments, namely increased complexity and maintenance overhead. — Scott • talk 11:16, 2 January 2014 (UTC)
    Please describe what you mean by "increased complexity" and "maintenance overhead", and then please pinpoint for me how these "vastly outweigh" the saving of a few keystrokes especially as it pertains to pseudo-namespace shortcuts. – Paine Ellsworth CLIMAX! 17:06, 2 January 2014 (UTC)
    • Increased complexity is having multiple optional ways to do the same thing. Maintenance overhead is having to write documentation for them and educate users on their use (note my complete surprise at discovering these things exist; as I have been here for a long, long time, clearly no significant effort has been made on that front). These things set up an entire parallel naming convention to be discussed, agreed-upon and implemented by current and, more importantly, future users. They're already generating maintenance issues: editors are being forced on this very page to debate the most appropriate uses of particular abbreviations and strategies for avoiding conflicts. That is work. There is no reason to believe that the amount of similar work required in the future would decrease; in fact, should these things see adoption (an unlikely prospect, given the lack of consensus for them on display in this discussion), the amount of work needed to maintain them will increase. Also, if a decision is made in the future that they were a bad idea, more work will be required to remove them. This is classic technical debt beginning to accumulate, in the form of a weakly-designed ad-hoc system being implemented on the fly with absolutely no form of project management. It should be stopped as soon as possible. — Scott • talk 12:24, 3 January 2014 (UTC)
    An important point is the mystique factor—many editors are aware that "WP:" is some kind of trick, but once seen, it is extremely obvious what it does, and using mouseover on a WP:xxx link shows that it links to Wikipedia:xxx. When editors see "T:xxx" or "C:xxx" they think more magic is being used, but the magic is opaque as mouseover shows nothing useful, and the shortcuts are just another impediment to understanding. By contrast, "Template:xxx" and "Category:xxx" are crystal clear—if an editor is going to provide a link, that link should be helpful. Johnuniq (talk) 22:04, 2 January 2014 (UTC)
    Can someone remind me why CAT: isn't an official shortcut, just like WP:? "T:" is ambiguous (talk or template?). WhatamIdoing (talk) 00:16, 3 January 2014 (UTC)
    @WhatamIdoing: I believe it is because if CAT: was a namespace aliases for Category:, it would add the linking pages to the category, rather than linking to the category page. i.e. the result would be the same as [[Category:foo]] rather than [[:Category:foo]]. The prefix 'CAT:' is listed as a "Commonly used" shortcut prefix at WP:SHORTCUT. — Preceding unsigned comment added by John Vandenberg (talk • contribs) 01:52, 3 January 2014 (UTC)
    Thanks. That would be Very Bad. Do you suppose it might be possible to make 'CAT:' actually mean ':Category:' rather than just plain 'Category:', and thereby bypass this problem? WhatamIdoing (talk) 19:58, 3 January 2014 (UTC)
    @WhatamIdoing: & @MZMcBride:. I recall that CAT: was discussed when mw:Manual:$wgNamespaceAliases was introduced, but that idea was dropped due to this technical issue. A search for "wgNamespaceAliases" only shows four threads of little importance. @Happy-melon: put forward a proposal in October 2008 at Wikipedia:Village_pump_(proposals)/Archive_36#Namespace_aliases, but it fizzled. If nobody else finds the link to the original discussion, I will, as it will probably help this current discussion. If you look at the syntax of that configuration, you can see it isnt a string - it is a constant (number), so the aliases functions identical to the namespace. Some coding could change that behaviour, but there are projects which are using CAT: (with the behaviour described above; e.g. see n:CAT:Australia and then try adding [[CAT:Australia]] and [[:CAT:Australia]] into a sandbox page and preview it - the page is added to the category). See noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php (very large file) and search for "'CAT'" to see five projects are using this namespace alias. enwikibooks, enwikinews, aswiki, zhwiki, and zhwikibooks. I would support a CAT aliases here on enwiki, as the '[[:CAT:x]]' syntax works; we would need to alter quite a few pages to add that colon, and there would be a bit of collective retraining the brain required, but it seems worth it. John Vandenberg (chat) 03:16, 6 January 2014 (UTC)

(outdent, good grief) There's a bug somewhere that discusses "cat:" in Bugzilla. As I recall, "cat" is the Catalan language code-3 or something? If you find the bug, you'll be roughly caught up, I imagine. --MZMcBride (talk) 04:03, 6 January 2014 (UTC)

  • Uh, what about the pointless inflation of editcounts e.g. here through pointless categorization of redirects? Which may or may not change depending on if a template Rcat is changed, shifted around or even deleted? This seems like lots of unnecessary maintenance work to me, when the redirects could afford not to be created in the first place. TeleComNasSprVen (talk • contribs) 05:04, 3 January 2014 (UTC)
To editor TeleComNasSprVen: I suppose I shouldn't dignify that with a response, but that "pointless inflation of editcounts" with a link to one of my diffs borders on personal attack. But I'll AGF, I guess, and gently remind you that the redirect maintenance cats are here for a reason, and much of the work is wikignomish. I've always liked the work so I guess that makes me a Wikignome. It's personally satisfying to know that I help the project in ways that are rarely if ever recognized outright. But I take strong exception to your characterization of redirect catting as "pointless". Drop that one where the Sun don't shine. – Paine Ellsworth CLIMAX! 23:20, 6 January 2014 (UTC)

OK, can we at least all agree on something concrete? As I read most of the comments here, I'm interpreting a no-consensus on the fact that the clause at Wikipedia:Cross-namespace redirects "and that pseudo-namespace redirects (CAT:, P:, MOS:, etc.) may be used freely" should be removed. Consensus has not shown that this clause is accurate, and any discussion about whether PNRs are restricted or allowed in limited circumstances should belong on that project page's talkpage. Do I have permission to remove this clause? To summarize, "there is no consensus that pseudo-namespace redirects may be used freely." TeleComNasSprVen (talk • contribs) 03:45, 3 January 2014 (UTC)

First you say:
I'm interpreting a no-consensus on the fact that the clause at Wikipedia:Cross-namespace redirects "and that pseudo-namespace redirects (CAT:, P:, MOS:, etc.) may be used freely" should be removed.
Then you say:
To summarize, "there is no consensus that pseudo-namespace redirects may be used freely."
Which is it? Is it a no-consensus that the clause should be removed? or is it no consensus that PNRs may be used freely?
I strongly object to the removal of that clause! There is a longstanding community consensus behind it, and there hasn't been near enough input here to justify an ignoring of that consensus. – Paine Ellsworth CLIMAX! 04:51, 3 January 2014 (UTC)
Sorry for the confusion, but I meant to say that no-consensus on the inclusion of that clause leads to its removal. Also, consensus can change. TeleComNasSprVen (talk • contribs) 05:04, 3 January 2014 (UTC)
Per WP:CCC, "Editors may propose a change to current consensus, especially to raise previously unconsidered arguments or circumstances." Your proposal is still young; do you truly believe that there has been enough input here to override longstanding community consensus? Where are the "previously unconsidered arguments or circumstances"? I haven't seen any arguments that haven't been used before. Pretty much all I've seen is WP:IDONTLIKEIT, and that's never enough to delete anything from articles to redirects to clauses in editing guidelines. Sorry, but it seems that your proposal is not old enough to have developed a consensus that would override that which established this clause and the other clauses in the first place. – Paine Ellsworth CLIMAX! 05:18, 3 January 2014 (UTC)
Yes, in fact from this discussion alone, I've gathered at least ten different opinions about the subject. According to this discussion, I believe that John Vandenberg, DePiep, Kaldari, Scott, and Johnuniq have all advanced arguments that these redirects should be discussed individually and that we should not try to include them under the banner of "may be used freely". I also interpreted User:Thryduulf's comment in the discussion as saying that "such redirects need discussion on their individual merits because some are useful and some are not" indicating that current consensus and practice is to judge each redirect individually rather than collectively include every general redirect under the banner of "may be used freely". (He is free to correct me if he wishes.) Especially pertinent is Kephir's comment related to WP:RFD#K5 that "current wording suggests that a redirect will be kept if merely one person deems it "useful", even though this is not how the criterion is usually interpreted in practice." If you bothered to read some of the discussions linked to at the top of this section, you'd realize actual current practice runs counter to what the clause for that page suggests. (Not only that, it's also an essay page.) I don't think you should dismiss the opinions of at least five other users as another reading of WP:IDONTLIKEIT and then saying that that is non-indicative of a consensus. TeleComNasSprVen (talk • contribs) 06:18, 3 January 2014 (UTC)
Well, of course you don't, because you disagree with me. You feel as if you have conquered a longstanding consensus with a 3-week RFD and a handful of participants. You do what you feel is best. I am so thankful that we have people like you and John, who help to keep those nasty and dastardly PNRs off the streets and away from our children. Y'all be sure that those PNRs die a horrible and tortuous death, for that is all they deserve. Now, I think I'll go do stuff that actually helps and improves Wikipedia. Sayonara sensei. – Paine Ellsworth CLIMAX! 14:08, 3 January 2014 (UTC)
re Paine Elsworth: this is drama only and not a helpful contribution. It does not contain any content reply to the arguments provided. I agree with you wisely concluding: I'll go do stuff that actually helps. DePiep (talk) 11:42, 4 January 2014 (UTC)
Paine Ellsworth: a longstanding consensus - Again, not true. A personal statement in an essay.
Then, a point of logic. Ellsworth, if the pseudo-namespaces can be used freely (as a guideline you say), that implies that each and every redirect can be created? You mean there not any holdbacks for creating redirects from mainspace, by the hundreds? -DePiep (talk) 11:14, 15 January 2014 (UTC)

@Thryduulf: I too would prefer that CNR are not speedy deleted, as a deletion discussion can not hurt, except in that it consumes a few minutes of a few people to reconfirm existing consensus, if one exists. Often the devil is in the details. Based on recent discussions, I believe there is consensus that

  1. new PNR with prefixes other than those listed on WP:Namespace(info)/WP:SHORTCUT(guideline) are not permitted (c.f. discussions re NS:, Mos: and Cat: (lowercase), CSD:, BLP:, SP:, etc),
  2. new CNR with separators other than ':' are not permitted (c.f. ; (and other deletions such as WP;NAMB); @; blah (foo), -, space, ,)
  3. new CNR that end in a colon are not permitted (see msgnw:)
  4. new CNR without a prefix will only be accepted if the target is a highly visited page.

I think there may also be consensus for

  1. existing CNR to failed proposals may be deleted or repurposed. (c.f Allwiki)
  2. CNR should be listed on the target page; if there is no consensus to list it as a shortcut indicates it isnt a community endorsed shortcut.
  3. prefix:foo and prefix_talk:foo must refer to the same target (e.g. WP:MP & WT:MP)
  4. prefix:foo and namespace:foo should refer to the same target (but not must, as this some opposition to this) (e.g. T:AD and Template:AD)

I disagree with your 'plausible' and 'harmless' criteria. A shortcut is a limited resource; there is only one of each. The '[Almost] any PNR is safe from deletion' rule has unfortunately meant that the project documentation about shortcuts is lacking, resulting in lots of cruft and a usability nightmare. We need to have more discussions, with the intention being 'good of the project' rather than 'anyone can create a PNR for anything and RfD rules and regulars will protect it if at all possible' being used to prevent useful discussions. We need to think about how shortcuts should be organised, in order to benefit both new and regular contributors. We need to write down rules of thumb, like naming conventions typically have the prefix WP:NC, and notability being at WP:N and discourage people using N* and especially NC* for other purposes as we will eventually need them, or at least introduce notes into the guidelines that indicate that shortcuts need to have positive community adoption before they are considered stable. John Vandenberg (chat) 15:37, 4 January 2014 (UTC)

I need more time to think about all these, but my initial impressions are generally favourable. For your first section I'd prefer "strongly discouraged" rather than "not permitted" in point 1 and perhaps point 3. For point 4 in that section I'm not sure I like "highly visited page" but I'm not sure what I'd replace it with yet, maybe something about pages aimed at readers or new editors rather than experienced folk (e.g. I'd by more tolerant of a CNR to AfD or the disclaimers than to a WikiProject maintenance page).
In the second section, I disagree that lack of mention on the target page always equals lack of acceptance - there is a strong desire in some quarters to restrict the number of shortcuts appearing on one page/section to only the most commonly used rather than all those that are used (from memory many shortcuts were unilaterally removed from WP:NOT for this reason for example). At the moment I don't think its safe to say there is any consensus about T:X/Template:X pairings, just some loud voices. Getting organised is a good aim, but we need to recognise the need for grandfather rights. In my opinion (and I don't know how widespread or otherwise this is) no actively used shortcut should be retargetted without a discussion that looks at how it is used and to which identifiable prominent users have been invited.
All discussions about this need to be careful not to confuse pseudo-namespace redirects (PNRs) with cross-namespace redirects (CNRs or XNRs) - the former (with the exception of WP: and WT:) are a subset of the latter. Thryduulf (talk) 16:06, 4 January 2014 (UTC)
Hi Thryduulf, thanks for the serious consideration given. "strongly discouraged" for new prefixes is good enough for me. However I think that a trailing ':' should be prohibited for CNR until someone puts forward a strong argument for them. I have seen a few existing CNR with a trailing ':' that I thought they had a good rationale for existing. If we find and discuss them, we might be able to compose a better summary of existing accepted naming in this regard. Re "highly visited page", I think I too have used phrasing similar to your "aimed at readers or new editors rather than experienced folk". It is a good distinction to formulate; it wont be easy but we can come up with something.
I can see what you are saying regarding "lack of mention on the target page", however please note that I was not referring to all incoming redirects - I said CNR. WP:NOT only has three CNR (from mainspace): What wp is not, What Wikipedia is not and NOTFORUM. The redirects from WP: (and User:) are not relevant to that proposal. The rationale for that proposal is that if a CNR is not worth mentioning, the cost/benefit of a CNR is probably in favour of deleting as they are not a) an optimal or common shortcut, or b) discoverable. I am guessing that you would object to 'CNR must be listed on the target', in which case would you consider 'PNR must be listed on the target' acceptable? John Vandenberg (chat) 13:17, 8 January 2014 (UTC)
I would object to both "PNR must be listed on the target" and "CNR must be listed on the target" as while being listed correlates well (but not perfectly) with being useful, not being listed is not a reliable indicator of either usefulness or uselessness, for the reasons I gave previously and this applies equally to PNRs and CNRs. However please see my detailed statements below (which I was composing when you left this comment) for more. Thryduulf (talk) 13:38, 8 January 2014 (UTC)
p.s. CAT: & MP: end in a colon. Note that 'WP:' and 'WT:' fail with a 'bad title' error, because they are a namespace alias. John Vandenberg (chat) 05:00, 10 January 2014 (UTC)

For Wikipedia:Redirect, since no one wants to propose their version an alternate wording, I've come up with one of my own as an alternative to the current wording: "The major exception to this rule are the pseudo-namespace shortcut redirects, which technically are in the main article space. Some long-standing cross-namespace redirects are also kept because of their long-standing history and potential usefulness." ---> "Some, but not all, cross-namespace redirects are kept because of their long-standing history and potential usefulness. The current consensus is to discourage the creation of new cross-namespace redirects. This includes the pseudo-namespace redirects." Or maybe change the second sentence into "there is no consensus on the creation of new cross-namespace redirects." TeleComNasSprVen (talk • contribs) 18:04, 6 January 2014 (UTC)

That's okay, except for the part about pseudo-namespace redirects. There just hasn't been anything here that seriously challenges the longstanding community consensus. And please don't say that I haven't acknowledged your ideas. As I said before, I disagree with some of your ideas, and if I'm not mistaken, the acknowledgment of your ideas must be an automatic given for someone who disagrees with them. If you or John or anyone else says that I do not acknowledge the ideas expressed here, I will take it as the unfounded accusation it is and will feel that I've been called a "liar". So please don't call me a liar again, either directly or indirectly. Thank you warmly for your honored compliance! – Paine Ellsworth CLIMAX! 00:03, 7 January 2014 (UTC)
No, I understand. The fact that you were the first to respond to my RFC is enough of an indication that you at least acknowledged some of the arguments presented here. It's possible that in a lengthy conversation when more than just debate and arguments are thrown around a few words here and there slip through the cracks. I have never wanted to call you a liar, and I believe we just don't share the same beliefs. And so far, John has been the one nominating the cross-namespace redirects; I brought this topic here to better gauge community consensus on the inclusion of these redirects. I don't think I've lately been going out of my way to get any of these redirects. TeleComNasSprVen (talk • contribs) 01:00, 7 January 2014 (UTC)
Paine Ellsworth, you have been active in a lot of the recent CNR discussions. Have you voted delete on any of them? If you have, I must have missed it. John Vandenberg (chat) 01:36, 7 January 2014 (UTC)
Frankly, I don't see how that is relevant, nor do I remember all my Keeps/Deletes. At RFD I've probably !voted to delete about as many redirects as I've !voted to keep, but the only PNR discussion I can remember where I !voted to delete was this one, and yes, I think you did miss that discussion. I was adamant about not creating a new pseudo-namespace without community consensus. I helped to delete about fifty PNRs on 23 Sept 2013. To be clear, at present I strongly uphold the longstanding community consensus that protects the existing pseudo-namespaces and their useful, helpful and harmless shortcut redirects. Yet I adamantly oppose the creation of new pseudo-namespaces without good, solid discussion and consensus, which was not the case for those fifty I helped to delete. – Paine Ellsworth CLIMAX! 04:14, 7 January 2014 (UTC)
I remembered another instance where I voted to delete (within a Comment) the Mos:intro PNR, which itself was indicative of what may be a software problem. While one can enter lowercase into a search engine and usually land at the uppercase shortcut target, the rub comes when one tries to link to that lowercase version. Then one gets a red link. Not knowing better, some editors will create the lowercase shortcut to change their link to blue. Gnarly little challenge. – Paine Ellsworth CLIMAX! 04:50, 7 January 2014 (UTC)
Thank you for mentioning those. It is easier to understand your position here, which is very pro-PNR, if we can see which types of PNR you deem undesirable, and by which processes you think new ones should be possible. John Vandenberg (chat) 05:41, 7 January 2014 (UTC)
TeleComNasSprVen, directly above your post I have tried to outline some basic rules (eight) that we might find consensus on. For PNR, I think the emphasis needs to be on the prefix, not suffix. i.e. there is consensus for strongly discouraging new prefixes being 'created' without prior discussion, but new suffixes appear every month and without issue. For CNR, I think "there is no consensus on the creation of new cross-namespace redirects" is easily a better summary of the current situation, but doesnt go far enough, however "The current consensus is to discourage the creation of new cross-namespace redirects" goes too far, I think. John Vandenberg (chat) 01:34, 7 January 2014 (UTC)
  • From the sidelines is creeping in the suggstions that prefixes C:, INTRO:, MP: are "pseudo-namespaces" (from here?). To prevent this ending up in any conclusion as being correct or even changed into being correct, I state that they are not, and that there is no proposal to include them. The text in the linked section is wrong. -DePiep (talk) 14:14, 9 January 2014 (UTC)
    "From the sidelines"? There is no "suggestion" that those are pseudo-namespaces – they are indeed pseudo-namespaces based upon community consensus, longstanding consensus. One editor cannot change that, not you nor I can just say they are not pseudo-namespaces. It takes a community consensus to overthrow an existant community consensus. For one editor to say they are not pseudo-namespaces does not make it so. – Paine Ellsworth CLIMAX! 16:35, 10 January 2014 (UTC)
And I am also compelled to add that a study of bug reports shows that even the developers consider any redirect that is titled with one or more letters and a colon to be in a pseudo-namespace, with the obvious exception of WP: and WT: shortcut redirects. – Paine Ellsworth CLIMAX! 18:07, 10 January 2014 (UTC)
Community consensus? Show where and how established. Also provide some links to that developers-thing you found. Then, please show how your mw developers considerations decided this for this en wiki (and what this would mean for T:kort). -DePiep (talk) 21:21, 13 January 2014 (UTC)

Discussion of PNRs and CNRs (continued)

Based on the 8 statements proposed by @John Vandenberg: earlier and subsequent comments I present the following statements (organised slightly differently) that I think approximate the current state of consensus about CNRs and PNRs from the main namespace. CNRs from other namespaces (e.g. Help: to Wikipedia:) are not considered here.

A: Cross-namespace redirects (CNRs) from the main (article) namespace, other than Pseudo-namespace redirects (PNRs):

  1. New CNRs are usually discouraged
  2. Discussion of new CNRs before they are created is strongly encouraged.
    The talk page of the proposed target or the talk page of a relevant WikiProject are often a good locations for such discussion.
  3. Retargetting a CNR so it is no longer cross-namespace can be done BOLDly where this would not be controversial. Where the redirect is highly visited or retargetting would or may be controversial for any reason then it should be discussed first at WP:RFD

B: Pseudo-namspace redirects (PNRs) from the main (article) namespace and WP and WT namespace aliases.

  1. New PNRs without a suffix are not permitted without prior consensus
  2. New PNRs with unapproved prefixes (i.e. ones not listed on WP:Namespace (info) or WP:SHORTCUT (guideline)) are not permitted without prior consensus.
  3. PNR prefixes are case sensitive, i.e. "MOS", "MoS" and "mos" are three different prefixes.
  4. New PNRs with separators other than ":" are not permitted
  5. New PNRs that use an existing prefix followed by ":" may be created freely, but it is strongly encouraged for suffixes that are shortcuts or acronyms to be in ALLCAPS without spaces
  6. A shortcut PNRs not listed on the target page may indicate that it is not endorsed, but this is not always true.
  7. Prefix_talk:FOO must refer to the talkpage of the page Prefix:FOO links to (e.g. WP:CSD leads to Wikipedia:Criteria for speedy deletion so WT:CSD must link to Wikipedia talk:Criteria for speedy deletion).
    If you find mismatched pairs they should be listed for discussion at WP:RFD.
  8. In most cases Prefix:FOO and Namespace:FOO should refer to the same target, but there are exceptions. New PNRs should usually avoid creating mismatched pairs as they can be controversial.

C: All CNRs and PNRs from the main (article) namespace and WP and WT namespace aliases:

  1. Deletion of CNRs and PNRs that do not meet the letter of the Criteria for speedy deletion must be discussed at WP:RFD.
  2. Simply being a CNR or PNR is not a reason on its own to delete a redirect.
  3. As with all redirects, having few or no internal links is not a reason on its own to delete a CNR or PNR.
  4. Converting an existing redirect to a CNR or PNR should be discussed at WP:RFD first, except following a page move.
  5. The status of the target page may be taken into account when discussing a redirect. Inactive pages and failed proposals often (but not always) make poorer targets than active, highly visited pages for example.
  6. New CNRs or PNRs to inactive pages, failed proposals and similar pages should not normally be created without discussion at an active page.
  7. Notifying the target and/or a relevant WikiProject of discussions at RfD is encouraged. For retargettings it is encouraged to noitfy the proposed target as well.
  8. Tagging the talk page of CNRs and PNRs with the banners of WikiProjects associated with the target page (using using the "class=redirect" parameter) is encouraged (except where an individual WikiProject objects).
    This means they will be listed on the relevant Article alerts page if they are nominated at RfD for any reason.

I know this is a lot, and includes things not really discussed here yet, but the idea is to try and avoid statements that people partly agree and partly disagree with (and I'm generally a fan of long lists of simple criteria over short lists of complicated ones). I intend this as part of the discussion, not necessarily as a final conclusion. Thryduulf (talk) 13:30, 8 January 2014 (UTC)

  • Yes, thank you so much for drafting a much clearer general outline about the current state of PNRs/CNRs than the previous two criteria you gave above. I think this will help establish a consensus much better than what I tried to do when I started this RFC at the top of the page. This should probably form its own page as a guideline to the reasonings behind the many varied RFDs we have on these two issues everyday, on whether the consensus should choose to keep or delete such redirects. TeleComNasSprVen (talk • contribs) 16:21, 8 January 2014 (UTC)
  • Thanks for this expanded list. Overall it looks good. Re C.4, is "except following a page move" meant to mean "except when automatically created by way of a page move" ? 'following' is a bit to vague IMO. John Vandenberg (chat) 23:56, 8 January 2014 (UTC)
    • With C4 I mean that if Page A redirects to Page B, and Page B is moved to Wikipedia:C then you don't need to discuss things before fixing the double redirect at A. If you can express this better then please do so! Does the list need some language about the new CNR at Page B too? Thryduulf (talk) 01:20, 9 January 2014 (UTC)
  • From a study of bug reports it appears that the developers consider any redirect that is prefixed by a letter or letters and a colon separator to be in a pseudo-namespace (with the obvious exceptions of WP: and WT:) and are therefore PNRs.
Re: B5, above – May I ask about the issue of the creation of new PNRs to their historic targets (H: to Help:, P: to Portal:, C: and CAT: to Category:, and so on)? For example C:WRONG → Category:Pages with templates in the wrong namespace, which is presently being discussed at RFD – we are again asked if "created freely" does not mean that consensus allows me to create such a shortcut without concern that it may be deleted just as long as it is found to be useful? – Paine Ellsworth CLIMAX! 17:46, 10 January 2014 (UTC)
"Can be created freely" does not mean "Can not be nominated for deletion", in exactly the same way that redirects that are not cross-namespace may be created freely but nominated for deletion if someone doesn't think its useful. Simply having a "C:" prefix though is not a valid reason to delete it unless there is a prior consensus to deprecate "C:" or limit it in some other way. Thryduulf (talk) 20:29, 10 January 2014 (UTC)
But doesn't nomination for deletion (and subsequent deletion) of a subset of CNRs/PNRs necessarily imply that the creation of that subset of redirects are to be discouraged? Deletion of an object in the mainspace implies that it did not warrant any value in the mainspace, though the deletion rationale does not necessarily point to it being a CNR and could identify other problems, such as being a promotional article or a variety of other reasons. I like the outline as it is, but the current wording at the essay is much too broad and vague to be of any use, and permits carte-blanche creation of pseudo-namespace redirects without heeding consensus or conventions. Regarding the acceptance of and consensus for C, if there exists any, hat's what we want to know, that's what we want to find out. TeleComNasSprVen (talk • contribs) 21:16, 10 January 2014 (UTC)
The nomination of a subset of redirects does not imply the creation of those redirects should be discouraged. The consensus deletion of a subset of redirects may or may not imply that that subset should be discouraged, depending on what the subset is and on why they were deleted - the deletion of a bunch of redirects similar to say "T:BOB" → "Template:House of Windsor" for being implausible does not imply that all T: redirects are implausible for example. The only way that the status of any set or subset can be changed is to hold a discussion about changing the status of that set/subset. Thryduulf (talk) 02:48, 11 January 2014 (UTC)
Thank you for this clarification, it gives your sentences above more sense, especially in regards to the consensus deletion supporting or discouraging certain redirects. This is, I believe, what is in currently in line with both policy and practice. I also agree that the only way to determine what subset of redirects these cases fall under is to hold discussions such as this one. TeleComNasSprVen (talk • contribs) 09:45, 11 January 2014 (UTC)
Yes, that makes sense, Thryduulf. There have been WP: and WT: prefixed shortcuts nominated at RFD, and they are certainly "created and used freely". All that remains is that I feel the shortcut is useful, the nominator feels that it's not useful and other contributors add their !votes and rationales to the benefit of either the nom's or the creator's rationale. It makes me really appreciate what closers do, especially for the more controversial nominations. – Paine Ellsworth CLIMAX! 23:34, 10 January 2014 (UTC)

Thryduulf, do you think we could create a separate page to host your suggested list in the meantime at some page, say "Wikipedia:Pseudo-namespace redirects", and maybe we could refer to it better until we reach consensus to turn it into a guideline of sorts? And then we could link back to it from Wikipedia:Redirects, Wikipedia:Cross-namespace redirects and Wikipedia:Namespaces#Pseudo-namespaces. TeleComNasSprVen (talk • contribs) 09:45, 11 January 2014 (UTC)

That sounds like a good idea. Thryduulf (talk) 10:15, 11 January 2014 (UTC)
Uhh, well, actually, I wasn't sure what title to give it since it already covers both CNRs and PNRs and both those titles were taken, so I've subpaged them under here for the time being, but I will find a way to get them out into Wikipedia's Project namespace so they'll be more 'official'. TeleComNasSprVen (talk • contribs) 10:42, 11 January 2014 (UTC) somehow I'll do it


Separate from the outline above

Alright, as I tried to say at the top of the discussion, I wanted to open one RFC to examine the history behind, discussion of, consensus for, and clauses relating to pseudo-namespace redirects. Now that we have I think some of the basics up and running, I wanted to open a second RFC to determine which of pseudo-namespace prefixes are still acceptable as pseudo-namespaces. Does anyone think this is a bad idea, or have suggestions othewise? TeleComNasSprVen (talk • contribs) 21:16, 10 January 2014 (UTC)

There are five possible categories of PNR prefixes, listed here with my suggested meanings:
  1. Approved - free to use with new suffixes.
  2. restricted - existing uses allowed but new uses strongly discouraged without prior consensus.
  3. Not approved - consensus is against all uses of this prefix.
  4. No consensus - be cautious and prior discussion is encouraged, but no consensus against their use or creation.
  5. undiscussed - no discussion has taken place about this prefix (although individual redirects using it may have been discussed), strongly recommended to get consensus for new redirects using the prefix beforehand.
A discussion to assign prefixes to one of the four lists (category 5 is just everything not on another list) needs to happen, but not yet. First I recommend getting agreement on a set of statements similar to the ones I wrote above (which people seem to like) but incorporating the comments and clarifications, and get consensus to use that as the framework for CNRs and PNRs from the main namespace. Then we need to agree what categories of PNR prefixes we are going to use, and what each one means. Finally when that has consensus we can assign prefixes to categories. All this I think should happen on a specific policy proposal page, linked from here, WT:RFD, WT:R, the talks of the existing pages noted above and the user talk of everyone who has commented here, Thryduulf (talk) 02:48, 11 January 2014 (UTC)
I was actually thinking about discussing each of the pseudo-namespace prefixes listed at Wikipedia:Pseudo-namespace individually, with their own headers and such but categorizing them under these terms seem just as useful. And I'll stick with hammering out the framework some more before starting the second RFC. TeleComNasSprVen (talk • contribs) 09:45, 11 January 2014 (UTC)
  • As for creating new prefixes that even pass as pseudo-namespaces, I object. Redirects away from content should nbe limited at all costs. Remember the T: was only used to allow some genbtle switchover to template-namespace (original templates being in mainspace); most of them are deleted since. Accepting a new prefix/redirect pseudo-namespace should be discussed individually, and the burden is on the proposer to prove it being usefull & harmless. By default, however, every redirect outside of mainspace or content space is harmful and not helpful for the reader.
I object to any institutionalisation of misleading variants. C: for CAT: is to be disallowed (how is a reader helped by splitting it? Are we gonna make all redirects double by creating both CAT:xxx and C:xxx?). Also, no institutionalising of the horrenduous misnomer of T:MP: the exception should be ruled out one way or the other. No suggestion of normaity for this one.
T: should be discarded in the long run for being incompatible with its target Template: sister wrt transclusion. Exactly that is the fiort thing such a prefiux should do: emulate the real namespace.
Any new creation should confirm to much more strickt rules that is proposed here ("should be discussed" is not enough. Better: should be proven to be both a useful addition and harmless.
Most of all, remember that these redirects using pseudo-namespaces to outside of mainspace (broadly taken, whether shortcut or not) are harmful by definition because they are non-content in mainspace. -DePiep (talk) 11:35, 15 January 2014 (UTC)

I have edited Wikipedia:Shortcut (and put a note at the top of the page to indicate this), sort of clustering the prefixes by level of community support, and being descriptive of best practise rather than trying to mandate anything (I think we're close to having a policy formulated, but we're not there yet). I have tried to put them all in clusters everyone can agree on, and describe the clusters in a way everyone can agree on, but I wouldnt be surprised if slight amendments are needed to get the balance right or take into account usages I haven't remembered to mention. John Vandenberg (chat) 11:33, 15 January 2014 (UTC)

Bravo! – Paine Ellsworth CLIMAX! 03:03, 21 January 2014 (UTC)

Changes to Wikipedia:Cross-namespace redirects reverted by User:Paine Ellsworth

User:Paine Ellsworth has recently reverted twice the removal of the specified clause on this page, and subsequently posted their reasoning on the relevant discussion page here. I'm moving it back along with my response to it to provide greater visibility, as well as subsectioning this off from the discussion above to make it distinct and separate. TeleComNasSprVen (talk • contribs) 17:12, 8 January 2014 (UTC)

  1. That is an essay page, and is in fact less binding than policy. The main thing that I wanted to 'overcome' was merely that the previous change to the page that removed that clause had been reverted and explained further up the talk page here, and discussion languished so there was no apparent consensus on it.
  2. There is no consensus on how pseudo-namespaces should be used, in fact there's a big debate right now about how they ought to be used. Note that I did not say "there is consensus against use of pseudo-namespace redirects", but this clause supports an inherently nonexistent consensus that they should be used freely, when scores of them are being discussed and debated about at RFD. In fact, the vague wording of 'may be used freely' ignores the many varied issues raised at the village pump about how creation of pseudo-namespace redirects should be controlled, and instead issues a carte-blanche statement to do whatever one wants with these redirects contrary to current consensus, including creating completely new pseudo-namespaces for pseudo-namespace redirects. (Note how it does not say anything about the creation of new pseudo-namespace prefixes, just that if they exist, then redirects for them could potentially be created.)
  3. You missed the point of the RFC, it was to reexamine the consensus gathered from all previous past discussions in RFD in order to establish the guidelines under which new PNR/CNR may be created. It has not itself managed to 'overcome' anything, I've managed to point to discussions going back at least three years indicating that there is in fact, no consensus on what PNRs to keep and which to delete. Places where I've indicated that for the past three years there has been no consensus for inclusion of this clause include here, here, here, here, and here.
If there is such a longstanding community consensus for this clause, then answer me this: how come in those deletion discussions spanning over three years worth of consensus building has this clause not been consistently applied in practice or even supported? TeleComNasSprVen (talk • contribs) 17:11, 8 January 2014 (UTC)

Alright, I think the last thing I'll say is, has there ever been a consensus discussion surrounding what would warrant including that phrase on the current essay page on Wikipedia:cross-namespace redirects? If not, then that renders the clause illegitimate in light of the current discussion here, which actively seeks to build an actual consensus for guidelines about these redirects. If it was simply inserted arbitrarily by one editor without any discussion on its legitimacy whatsoever, then it can and should be challenged by any new discussion, and has little to base itself on other than the whims of one editor. TeleComNasSprVen (talk • contribs) 17:18, 8 January 2014 (UTC)

I've just spent some time examining the history of that essay. The text in question derives from this addition in September 2007 by (now-blocked user) Melsaran (itself a slight modification of text he added a month earlier). The consensus which it refers to was very poorly documented, only referring in a general sense to contemporaneous RfDs, and was unaccompanied by any discussion of the specific consensus on the talk page. As can be seen, the same edit was the source of the statement in the introduction that the issue was "moderately controversial". This is an extremely weak basis for claiming an established consensus on the matter, and sorely overdue for a refresh after such a long time. Given the absence of convincing historical record on a specific consensus, it's my opinion that this current discussion, and once again the related RfDs, easily provide sufficient consensus to remove the clause from the essay. — Scott • talk 18:26, 8 January 2014 (UTC)
It's good that you do this, Scott, because it enables us to study more in depth the history of the longstanding consensus to use PNRs freely. But that essay, which has been often quoted in support of old CNRs as well as PNRs, is not as editors have noted policy nor guideline, and neither is it the root of the Wikipedia:Redirect PNR clauses, but only a result of whatever happened to produce and create those clauses in the first place. One of the original thoughts IIRC was to eventually set up the software to accept the shortcut prefixes as real namespaces. At the time you note, 2007, as found at Wikipedia talk:Namespace, WP: and WT: were still in mainspace and among the PNRs, and those two did eventually work themselves out of mainspace and into the Wikipedia and Wikipedia talk spaces, respectively. I have never been able to find out why the project stalled, but I've always felt that other considerations, such as expressed by editors here that have to do with things like languages, i.e., other uses of (some of) the remaining PNRs, were brought out as they have been brought out here, and that those put the PNRs in a limbo awaiting the devs to get back to them after putting out other software fires. Perhaps it is time to address this again with the devs and find out if it would be feasible to make the presently used pseudo-namespaces the same as WP: and WT:, take them out of mainspace and put them into their respective target namespaces. That is probably why the 2007 changes were made – to ready the stage for conversion of the pseudo-namespaces to other namespaces, which allowed for the PNRs in those pseudo-namespaces to be used freely. Then perhaps instead of ridding the guideline of these material clauses we should be reviving the discussion about the pros and cons of taking the existing pseudo-namespaces out of mainspace in the same manner as WP: and WT: went from mainspace to their respective namespaces. – Paine Ellsworth CLIMAX! 00:02, 9 January 2014 (UTC)
re PE: it enables us to study more in depth the history of the longstanding consensus ... - This is lousy reasoning. There is no such consensus. It is just a circular self-approving reasoning. -DePiep (talk) 14:18, 9 January 2014 (UTC)
It's a consensus that's been in place for at least six years, probably closer to seven years, since 2007. The idea in this discussion is to change clauses in Wikipedia guidelines (the essay itself should not be changed, but instead should be tagged "historic" if this discussion changes its effectiveness) in regard to existant pseudo-namespaces. Those pseudo-namespaces were made for a reason, and it is incumbent on all contributors to this discussion to fully understand why they were made and what the effect will be if and when the longstanding community consensus is either upheld or overturned. And let me restate my conviction that the consensus that put these clauses in place should be upheld, and the clauses should stay as they are. – Paine Ellsworth CLIMAX! 16:47, 10 January 2014 (UTC)
What, why? Just because one clause in the essay you so often cite is taken out, doesn't render the rest of the essay invalid so that you could tag {{historical}} on it. I think the arguments for/against CNRs are pretty pertinent today as they were when the essay was created, and I see no reason to ditch the entire essay because of this. It sound like a case of "throw out the baby with the bath water" to me because the page isn't a version you prefer. TeleComNasSprVen (talk • contribs) 20:06, 10 January 2014 (UTC)
I was just saying what usually happens to essays. They are usually treated differently from guidelines and policies, because as we've heard so much, they are "just" essays. However, if it is decided by contributors to go a different route for whatever reason, I would not be averse to that. I certainly am averse to any instance of tossing out the babe with the bathwater! Maybe then, as regards that essay, we must try to come to an agreement about that one snag in its lead – the part that you and others seem to think is vague – that the pseudo-namespaces can be used freely. Do we want to get rid of that? Or do we want to clarify it? Maybe I should explain what I think the phrase "used freely" means?
The essay began on 24 July 2007 and the phrase was added on 4 September 2007. That was evidently when at least some or most of the existing pseudo-namespace prefixes began to be used. The idea was apparently to convert them all into "real-namespace" (or just "namespace") prefixes. The WP: and WT: pseudo-namespaces eventually were converted. So to be "used freely" also applied to them, as well, back then. Until they were converted, it was okay to create "WP:MOS" and "WT:MOS" as shortcuts to the Manual of Style and its talk page. It was also okay to make any other shortcuts (and believe me, there are a lot of them) using those prefixes. When those two were converted, there was no longer a need for a separate "WP:Manual of Style" shortcut, because those two prefixes could then be applied automatically. And you could continue to make shortcuts with those prefixes, WP: and WT:, because they continued to be "freely used". For me, that idea of "used freely" has always applied to the other prefixes that have come down to us in the same manner that it applies to WP: and WT:. If you run a portal about Maine lobsters, "Portal:Maine lobster", and you make two shortcuts to it, "Portal:ML" and "P:ML", that is the free use of the P: pseudo-namespace. At some point it seems contributors in 2007 hoped that one day they could type "P:Maine lobster" to get to the portal in the same way "WP:Manual of Style" gets us to the MOS, but that hasn't happened yet. That is how I understand the phrase "used freely". Those contributors expected and were hopeful that all of the existing pseudo-namespace prefixes would eventually be converted to namespace prefixes, so it was thought that they should all be used as freely as the WP: and WT: prefixes are used today. As Thryduulf pointed out previously, this doesn't mean they won't or can't be discussed at RFD. Even WP: prefixed shortcuts are sometimes discussed. It just means that if a contributor feels that P:ML would be a useful shortcut, then it is okay to create it and use it freely. If P:ML falls into non-use, then it might be listed at RFD and either kept, retargeted or deleted. That is what "used freely" means to me. If that is what you think it means, and you either agree with the meaning or disagree with it, then at least maybe this is where we can start? – Paine Ellsworth CLIMAX! 22:57, 10 January 2014 (UTC)
What, how can you nominate WP: and WT: "pseudo-namespaces" (they're actually namespace aliases) for deletion, when you can't even get to them using &redirect=no because you're pointed directly to Wikipedia-space? TeleComNasSprVen (talk • contribs) 23:57, 10 January 2014 (UTC)
Forgive me if I was unclear. I said that back when the idea of shortcut prefixes began, there were no shortcut prefixes that were not "pseudo-namespace". I think the idea was to make them all namespace aliases, but so far only WP: and WT: have been converted to namespace aliases. As for nominating them, that is where I was probably most unclear. The shortcuts or general redirects that can be titled with the WP: prefix, for example, would actually be listed as "Wikipedia:(name)". Sorry if that was clouded in my above response. – Paine Ellsworth CLIMAX! 23:50, 11 January 2014 (UTC)
That's an extremely creative interpretation of the result of my investigation, which was that the basis for even claiming any reasonable degree of consensus since 2007 is highly questionable at best. Your comment about the software developers and "probably why the 2007 changes were made" are pure hand-waving. I can't see one single person in this discussion, even if it is of only limited participation thus far, that agrees with your interpretation of history. — Scott • talk 18:07, 10 January 2014 (UTC)
It seems then that you disagree with Thryduulf's statement in the section above, "...approximate the current state of consensus about CNRs and PNRs from the main namespace"? Maybe your study might include when these clauses were added to the guidelines and perhaps what discussions took place on those guidelines' talk pages? They didn't just magically appear six or seven years ago, Scott. It took consensus to add them, and it has taken consensus to keep them as they are. I'm sorry, but it is very difficult for me to see how that can be denied. How else do you think these clauses, which are the main issue here in this discussion, came to be in the first place? – Paine Ellsworth CLIMAX! 18:21, 10 January 2014 (UTC)
Because you have yet to answer the question I posed above, Paine Ellsworth. I've not seen you supply a single diff, discussion link, bugzilla report, or otherwise to back up your assertion that this is in fact a longstanding community consensus. Scott on the other hand has been generous enough to take the time to investigate the history of that clause, and backed up his assertion with diffs and links as appropriate. You've also refused to acknowledge the three+ years of RFD discussions that have suggested this "longstanding consensus" is nonexistent. TeleComNasSprVen (talk • contribs) 19:09, 10 January 2014 (UTC)
Actually, the three years of RfD consensuses that I've seen, up to about a month ago, do support the consensus as written. Since then however there have been a proporitonately very large number of PNRs and CNRs nominated as a couple of users appear on a crusade to eliminate all the bad ones without worrying what happens to the good ones that get swept up with them. This merits a reevaluation of the consensus, which is happening right now on this very page, but until a consensus is arrived at to either remove or replace the statements they need to stay. BRD applies - you boldly removed them, you were reverted, now things stay as they were until there is consensus. Thryduulf (talk) 20:18, 10 January 2014 (UTC)
I still don't see how they support the current phrasing as is; the clause "may be used freely" suggests as I have mentioned above a carte-blanche statement to do whatever with pseudo-namespace redirects so long as they are considered pseudo-namespace redirects, which we have yet to establish criteria for. This 2011 discussion among many other examples suggests that certain pseudo-namespace redirects are still not accepted and that we need stricter wording than a carte-blanche statement on the "free" creation of new pseudo-namespace redirects. The many administrator "speedy deletions" John Vandenberg notes above at the beginning of this RFC, as well as this discussion from September 2013 suggests that at least a portion of these redirects are to be discouraged from creation, even though we might not know which portion that is. The general outline you provided above for the CNR/PNR situation seems like a reasonable starting point for what should be acceptable or unacceptable CNRs/PNRs, and I'd prefer we replace again the very vague wording that was introduced by one sole editor many years ago with your notes. TeleComNasSprVen (talk • contribs) 21:02, 10 January 2014 (UTC)
Even edits backed by consensus are made by "one sole editor". The fact that one editor made the edit does not mean that there was only one editor behind the reason for the edit, does it? – Paine Ellsworth CLIMAX! 23:50, 11 January 2014 (UTC)
Every edit and admin action either confirms or rejects written consensus. And for a long time, the reality is that the written consensus was out of sync with what was in that essay. Admins are regularly deleting these shortcuts. Even today, MOSS:SECTION HEAD was deleted immediately by a different admin when it was listed in my batch of nominations today. That is interesting because the shortcut was created by an admin. Admins don't usually delete redirects created by other admins, as drama be that way. If you are interested in helping formulate better wording that is more useful guidance for editors, please give your opinion on the lists of new 'rules' put here for consideration. If you are only here to write long screeds that dont help formulate new guidance, you are being disruptive. John Vandenberg (chat) 13:25, 13 January 2014 (UTC)
I am not here to formulate better wording because the wording is just fine as it is. Any other choices? Oh, and since this is Wikipedia, my long screeds are just as important as your long screeds are. – Paine Ellsworth CLIMAX! 04:10, 14 January 2014 (UTC)
Which good ones have been swept up with the bad ones? I can only speak for myself, but I have been very cautious about nominating only bad ones, or redirects that I consider to be quite questionable, where I feel consensus has moved significantly since 2007 or whenever that essay was written and needs to be reconsidered. I have invested hundreds of hours into reviewing them all, trying to work out where there are unwritten rules in play, and leaving alone CNRs that I feel conform to & confirm existing consensus. By reducing the set of irregular CNR, we can see what remains better, and formulate guidelines around those, allowing new CNRs to be created within the parameters of an editing guideline so they cant be nominated for deletion without good cause. For example, I dont like 'X wikiproject', as it pollutes search results for X, but at least the target is self-evidently going into wiki-land, and there are lots of them. 'X portal' has the same problem regarding polluting the search results, but at least the target consists of content about X, so the reader isnt far from where they want to be. I have only nominated 'X Project', and user:rybec helpfully found that the CNR had actually been positively problematic, as it had caused a real topic to be forced to use a '(books)' disambiguator, unnecessarily. Over there years there have been many instances where a CNR has held the title of what should have been a real topic, but the potential creator didnt feel empowered to overwrite the redirect. I also havent nominated 'WikiProject:X' , despite it being a PNR that isnt on WP:Shortcut, as there are quite a few of these, and they are not too different from 'WikiProject X'. I very much dislike 'Portal X', because they fill the search results for 'Portal' with lots of CNR that hinder the reader from finding the real-world portal thingy they are looking for, and most of them are using lowercase proper nouns like Portal thailand. The MOS crowd would cry if they saw it. If every portal had a 'Portal x' redirect, searches for real topics using the term 'portal' would be nearly unusuable. But, I found 15 of the f*ers, so I left them be. I can give you many other examples of what I haven't nominated for deletion. John Vandenberg (chat) 11:14, 13 January 2014 (UTC)
"Portal x"? Argh! That's a motion well worth re-pursuing, IMHO. — Scott • talk 11:33, 13 January 2014 (UTC)
"Which good ones...?" every single one that I recommended keeping for a start. The deletion of the MOSS: redirect as R3 was grossly out of process - the criteria specifies that eligible redirects must be recently created, with redirects created 3 months ago regularly declined and sometimes even 3 weeks being regarded as too old. I've urged the deleting admin to reverse their actions, not least as these discussions stand testament to the fact that your crusade against PNRs is far from uncontroversial. Far from "Portal x" redirecting to "Portal:x" being a bad thing, it is exactly the sort of thing that serves our readers well. Where there is a conflict with a real world entity, then there should be a hatnote to aid the finding of the portal. Thryduulf (talk) 17:30, 13 January 2014 (UTC)
Hey, thanks for letting me know when discussing my actions on a noticeboard. See my talk page; R3 may not have been the best criteria, but it's also a valid G7 deletion; and deleting a unusued, obvious typo redirect is common fucking sense. You're welcome to request a DRV but I'm not going to undelete it just because you've got the hots for useless RfDs discussions. ☺ · Salvidrim! · ✉ 17:53, 13 January 2014 (UTC)
B'Geezus! Another contributor trying to turn this into the Napoleonic Wars. This may very well be a useless RfD discussion (yeah, I'd have to agree with that); however, the deletion of an obvious {{R from typo}} is by no means common sense, fucking or otherwise. And I have to wonder – is that the best Wikipedia policy for an admin to go around citing? – Paine Ellsworth CLIMAX! 10:32, 15 January 2014 (UTC)
The criteria applying to redirects are ludicrous, R3 in particular. It encourages cruft for cruft's sake by imposing an unrealistic timescale for spotting and resolving issues - we work for the long-term future on this project, and a three-month deadline is completely arbitrary, not to mention based on completely fact-free assumptions about external linking (themselves attached to a mythic sense of responsibility for link integrity ni third-party hypermedia). Passing the three-month mark instantly imposes an absurd amount of bureaucratic overhead on simple corrections, such as the deletion of obvious typo redirects. Salvidrim, you deserve a commendation for ignoring it and making a common sense decision. — Scott • talk 12:44, 15 January 2014 (UTC)
@Scott Martin:, regarding external incoming links, we might introduce some fact based reasoning by improving the template. See Template talk:Rfd2#Google link search. John Vandenberg (chat) 14:04, 15 January 2014 (UTC)
Very good. More facts, less hand-waving. — Scott • talk 14:34, 15 January 2014 (UTC)
  • I have to ask though, Paine, why do you resist these changes to our Wikipedia pages? They're meant to reflect existing consensus and best practices, but all I've seen is outdated information from some 5+ years ago. When 'sole editors' want to make controversial changes to our current pages to better reflect the consensus, they usually leave a short comment pointing where they got they're consensus and the lengthy discussions that led to it, plus any relevant policies that would support the changes they make. This has none of the makings of consensus, and it has all the whims of one editor. So then I have to ask, Paine, how does the current wording reflect actual practice? How does it reflect anything we've discussed so far? Consensus is based on actual practice, not on the word of any Wikipedia page; if I remember correctly, those were considered descriptive not prescriptive of current consensus. And the current consensus - the current practice - has changed drastically since then. P.S. you've still yet to supply one diff, discussion or other piece of evidence that this was a consensus-based edit. TeleComNasSprVen (talk • contribs) 01:29, 14 January 2014 (UTC)
    I resist these changes because I feel they are unnecessary. And six or seven years of overall agreement not to change the wording is an ongoing consensus. Even the talk page of the essay reflects one editor trying to change the words and another changing them back, so it has been challenged more than once in seven years. Nothing much has changed. This is an issue that erupts from time to time, but nothing's really changed. During some periods there are more deletions than other periods. Sometimes there are more being created and other times there are fewer being created. I still say that it is more important to come to a consensus in regard to seeing which of these the devs want to convert into real namespace aliases. That's what they were created for in the first place, and I disagree with changing the status quo until we get such a reading from the devs. – Paine Ellsworth CLIMAX! 04:25, 14 January 2014 (UTC)

Timeline of discussions

  • Proposal for P: and T: in 2008. Half a dozen people like it.
  • Revival of the proposal in 2009 by a Bugzilla developer looking at a bug filed with the 2008 discussion (more on that in a moment). Eight people like it. Two people don't like it.
  • Proposal later in 2009 for T:. Met with complete indifference.
  • Another proposal in 2010 for T: fails to gain consensus.
  • A mass nomination in 2010 of T: redirects is speedy kept.
  • The Bugzilla bug for P: and T: is closed in 2011 after three years of waiting for someone to adequately demonstrate consensus support for the proposal.
  • Another mass nomination in 2013 is controversially closed as "no consensus, because discussion did not address the merits of each particular redirect". Even though several of them are addressed and there are more general calls to delete than there are to keep. A deletion review happens but the decision is not overturned. (If I had participated I would have called for an overturn as the close was a clear example of a supervote.)

I think I've now read almost all the discussion that's happened on this topic in the last few months, not to mention from the years before. My eyes are melting. What I can extract from all of this is that the notion that there's "long-standing consensus" for PNRs is absolute nonsense. Various people have proposed or supported the idea over the years only for it to be rejected, time and time again. It's the very definition of a perennial proposal, which is why shortcut namespaces have an entry at WP:PEREN. Bits of the idea, in the form of PNRs, have crept into the system here and there over the years, and the only reason that they manage to survive is from the efforts of the few people who like them. Yet those few are not even remotely enough to create a genuine consensus for wide implementation. If they were, this discussion (number 7,469,308 on the topic) would not be happening. — Scott • talk 23:28, 10 January 2014 (UTC)

That is all very interesting, Scott, and thank you for it! I guess my eyes would melt, too, if I had waded through all nearly seven-and-a-half million discussions about pseudo-namespaces to try to come up with a viable opinion, rationale and support/non-support for the PNRs. More than my eyes would melt. Here is what I think "consensus" means (just my opinion): agreement – plain and simple agreement. Agreement can be attained in any number of ways. You may boldly modify a policy or guideline and find that others think, 'Yeah, that was a good edit." They may not voice their approval, but they don't revert you either. That's a form of agreement, a form of consensus. Consensus may take place only after discussion (for the controversial issues), or it may take place just by people accepting an idea without challenging it. Maybe that is what happened here. Only a few people (just like now) had any feeling at all about the pseudo-namespace prefixes other than it would be a great idea to eventually convert them into "real" namespace prefixes, which would save a ton of keystrokes over time. It's an idea whose time has come only for the WP: and WT: prefixes, though, so far. This is a good time to challenge the rest, though. It's a good time to say, "Look, we either turn these into "real" namespace prefixes or we get rid of them. Or maybe it's a good time just to limit their future usage and treat them like other CNRs – keep the old ones and discourage new ones. When the 2nd RFD starts, I am not yet fully certain how I will !vote thanks to your efforts in this discussion. Much food for thought. – Paine Ellsworth CLIMAX! 23:55, 10 January 2014 (UTC)
"This is a good time to challenge the rest, though. It's a good time to say, "Look, we either turn these into 'real' namespace prefixes or we get rid of them. Or maybe it's a good time just to limit their future usage and treat them like other CNRs – keep the old ones and discourage new ones." Yes that's exactly right, that was one of the points of this discussion. However, I think the main takeaway from this is that there has never been a longstanding community consensus about pseudo-namespace redirects. TeleComNasSprVen (talk • contribs) 10:35, 11 January 2014 (UTC)
One reason that it can be difficult to change something on Wikipedia (and this is only one of many) is the passage of time. For example, if a page has existed with a certain title for six years, and an editor boldly decides that it could use a better title, the change might be reverted simply because there has been a six-year consensus to leave the title just as it is. That, too, is a consensus. Some call it "grandfathered in", but whatever you call it, it still represents a six-year agreement to keep the title as it is. – Paine Ellsworth CLIMAX! 23:59, 11 January 2014 (UTC)
If there's something that doesn't represent consensus even though it pretends that it does, it should be removed as misleading. There's a limit to how much a 'longstanding community consensus' can apply to present and future discussions. It's completely illogical to, say, have to ask for consensus to correct a misspelling that has remained in an article for six years, and to be reverted on the basis of 'no consensus for change'. There's always room for change on Wikipedia; it's just there seems to be an unnecessary resistance to change that's prevalent here. TeleComNasSprVen (talk • contribs) 01:16, 12 January 2014 (UTC)
It is true that a grandfathered-in title or text is still subject to change; however, if only a handful of editors want to change it, then their rationale(s) should be up to the task. There should be very good reason(s) to change anything that has lasted, that has survived for several years, that has stood the test of time. This is true especially for issues that, when raised, generate intense controversy, like this issue. Forgive me if I'm wrong, but I don't remember saying that this applies to copyedits like the one you described. These are no copyedits that you propose here. There is room on Wikipedia for both change and for resistance to change. Anyone who thinks that resistance to change is "unnecessary" should, in my opinion, rethink it! – Paine Ellsworth CLIMAX! 04:55, 12 January 2014 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

@HJ Mitchell: Clarification request: Where you say "There is consensus that new "pseudo-namespace" redirects ("MOS:", "T:", etc) should be strongly discouraged if not prohibited in all but exceptional cases", are you saying that e.g. MOS:FOOBAZ should not be created even though many "MOS:"-prefixed pseudo-namespace redirects already exist? Anomie⚔ 13:02, 4 February 2014 (UTC)

Sorry for the ambiguity. That wasn't my intention—by addressing "MOS:" under its own bullet point, I intended to make it clear that its use has wide support, so such shortcuts can continue to be created (unless consensus later deems otherwise); "CAT:" (the other pseudo namespace that has its own bullet point) is less clear cut, so such shortcuts should be created with caution. HJ Mitchell | Penny for your thoughts? 20:26, 4 February 2014 (UTC)

Where is the consensus for removal of text from WP:CNR or for any of the suggested clause changes? A few editors who want to make changes does not make a consensus! Never has, never will. The only true consensus is still to maintain the status quo, a seven-year status quo that has stood the test of time. – Paine Ellsworth CLIMAX! 14:08, 4 February 2014 (UTC)

Enough. Enough!
Consensus is formed in discussions like this one, where editors who have an opinion on a matter express that opinion. Any historical consensus was formed by editors of that time. The discussion above, on an incredibly abstruse and obscure part of this project's functionality, has sat at the very top of one of Wikipedia's most prominent noticeboards for six weeks, and generated a large amount of discussion from everyone who could reasonably be expected to have participated in it. Now an uninvolved admin has heroically waded through the whole thing and extracted the measure of current consensus from it, in exactly the way that an RfC is supposed to be assessed. Consensus can change, and it has changed. Following the outcome of the RfC, the community is free to move forward in updating and rationalizing the policy and guidelines in question. You had every possible opportunity to express your opinion, and you did; it's been shown that your opinion does not represent the current general position on the matter. Your comment about "the only true consensus" is insulting to all the people, myself included, that spent a long time hashing out the issues in this RfC, and especially insulting to HJ Mitchell, who stepped up entirely unbidden, as a volunteer, to undertake the large and difficult task of closing it and providing the community with a usable conclusion.
If you continue onward into I didn't hear that territory, and consequently attempt to impede any changes made on the basis of the consensus in this discussion, I will not hesitate to seek consensus for you being topic banned from the entire area of CNRs. — Scott • talk 17:26, 4 February 2014 (UTC)
Your problem seems to be that you like to speak for others, Scott. HJ Mitchell has helped me in the past with edits and even very recently. I have the utmost respect for HJ Mitchell, and I believe that contributor is well-aware of that, so you don't speak for other editors. Also, your threats are noted, and I do hope that other contributors will take it to heart just what kind of threatening person you have been and can be.
All I do here is respectfully contest an outcome, and you seem to think I am Hannibal out to get you. But then, all you know of me are these recent discussions where you and I have disagreed, sometimes heartily. If you knew me, then you would know that I have no problem with following consensus, old or new, so you have no worries about me attempting to impede any changes made on the basis of this discussion. I merely challenge the opinion that a strong enough consensus to challenge the tried and true old consensus on this subject has been reached. Please don't make any more groundless, useless and hollow threats, Scott. You're better than that! – Paine Ellsworth CLIMAX! 18:08, 5 February 2014 (UTC)
I don't think anything of the kind. Thank you for acknowledging that you have read and understood my warning. — Scott • talk 18:40, 5 February 2014 (UTC)
No problemo. No, nothing incredibly abstruse about that. – Paine Ellsworth CLIMAX! 22:31, 5 February 2014 (UTC)

Wikipedia:Signatures has been marked as a policy

Wikipedia:Signatures (edit | talk | history | links | watch | logs) has recently been edited to mark it as a policy. It was previously marked as a guideline. This is an automated notice of the change (more information). -- VeblenBot (talk) 02:00, 4 February 2014 (UTC)

FYI, only sections of it are so marked. NewsAndEventsGuy (talk) 10:45, 4 February 2014 (UTC)

Noindex in Non-free files?

I have a question - Non-free files should be non-indexed or not? Please see Category:Noindexed pages, there are many images with _NOINDEX_ tag, but I don't see any policy or even reason for adding this. Can we remove it? --Rezonansowy (talk • contribs) 17:19, 1 February 2014 (UTC)

I think we definitely should have a clear poicy on the use of __NOINDEX__. I do think that non-free images should be NOINDEXed, and thst this should be applied using the rationalle tags. עוד מישהו Od Mishehu 04:39, 5 February 2014 (UTC)
In effect the matter was discussed at Template_talk:Non-free_media#Adding_NOINDEX and nothing was done. WMF said it was not legally necessary but gave no opinion over whether it should be done. Thincat (talk) 21:48, 7 February 2014 (UTC)

Shared accounts for GLAM institutions?

This note is to ask for some more input at WT:GLAM#Usernames for GLAM participants. The story starts with my block of user Swiss National Library (talk) for reasons described here. In the WT:GLAM discussion, user Micha L. Rieser (talk) has made a case for an exception to the WP:GROUPNAME and WP:NOSHARE policies to allow GLAM institutions to have role accounts, operated by multiple people, some Wikimedians-in-residence and some institution staff. This is apparently permitted on de-wiki. I am not myself convinced that it is either necessary or desirable, but I have said that I will help to set up an RFC if it appears that the idea has any support. Unfortunately WT:GLAM seems to be a low-traffic page and there have been no further comments. Opinions welcome, but at WT:GLAM, please, not here. JohnCD (talk) 22:53, 7 February 2014 (UTC)

Article titles RFC

There is an RFC that may be of interest to the pump Wikipedia_talk:Manual_of_Style/Trademarks#RFC_to_resolve_conflict_between_MOS:TM.2C_MOS:CT_WP:TITLETM_WP:RS_WP:COMMONNAME Gaijin42 (talk) 17:15, 7 February 2014 (UTC)

I urge editors to drop by and participate in this RFC... so far, we have heard from the "usual suspects" (editors who have expressed their opinions on this issue many times in the past)... what we need is the input of those who have not expressed opinions before. Blueboar (talk) 16:02, 8 February 2014 (UTC)

Central Wikipedia / Wikimedia Foundation noticeboard

I think there should be a noticeboard where the editors can report problems about the Wikipedia on their language. For the sake of the argument, imagine there is a small "Romulan" Wikipedia with three administrators and 20 editors. If the administrators abuse their powers by blocking those who disagree with them without having good reasons to block them, or if they tolerate severe personal attacks or fascist propaganda, then the editors should have a place to report such things.

Why such a noticeboard is necessary:

  • An editor should feel comfortable when editing Wikipedia in good faith. They should rest assured that, if the administrators abuse their powers or if they are not doing their job, then the editor can report the problem at the central Wikipedia noticeboard and then he/she can get the problem solved.
  • The administrators will know that they can't abuse their rights since they can be reported on the central noticeboard.
  • For the regular user, it feels uncomfortable or intimidating to have to report such conflicts directly to the owner of Wikipedia - Jimmy Wales, who might be too busy or not, or they might feel like they are too small in face of the owner of the website. It's much more comfortable to report problems to a group of people who are in charge to handle such things.
  • I suspect that on small Wikipedias there are good chances that abuses can happen, and the editors who are abused don't know where to report them and don't have the courage to talk with the boss. Usually smaller Wikipedias are created by communities under-developed, where the people tend to be afraid about those who have more power.

I recently informed the administrators on English Wikipedia about a blackmail case that was not solved since two years ago on Romanian Wikipedia. The problem is, English Wikipedia has no jurisdiction over Romanian Wikipedia. I can report extremely severe attacks (death threatds, bombs etc) at emergency-at-wikimedia.org but that's not the case here. Yet, the problem should be solved (the perpetrator fully retracts his threat or he gets blocked indefinitely) by someone, since the Romanian Wikipedia seems incapable or unwilling to solve it. The case is reported here: Wikipedia:Administrators' noticeboard/Incidents#Unsolved severe personal attack on Romanian Wikipedia

I know, opening such a noticeboard can get to some flooding from people who complain about this and that. Although the noticeboard can be opened specifically for some certain type of abuses, therefore limiting the flow of complaints. On the other hand, it can spot abuses that otherwise go under the radar and can prevent administrators on smaller wikipedias to try to group and act like tyrants. —  Ark25  (talk) 16:33, 11 February 2014 (UTC)

This belongs on meta:, not here. Jackmcbarn (talk) 16:38, 11 February 2014 (UTC)
Thanks, I did it. —  Ark25  (talk) 17:26, 11 February 2014 (UTC)

The way Wikipedia treats editors today: An open letter to Jimmy Wales

Imagine a world in which every single person on the planet is given free access to the sum of all human knowledge. That's what we're doing. - 2004

The way I was treated when creating a new article - this is very typical of the way editors, new and old, are treated on wikipedia, see Wikipedia:Newbie treatment at Criteria for speedy deletion

One of four articles which was deleted - it had major sources - before we argue about the legitimacy of this article, please post it here.

There is no legal reason that this article should have been deleted. It followed all guidelines for free use under United States law. There is a section of wikipedia policy which recognizes this, but I can't find it, all I can find is punishments for copyright infringement.

Mr. Wales, its not fun to create content here anymore. I will never add an image to wikipedia because it will be deleted immediately. I have had images with no copyright protection deleted. I still add articles, but 60% of the time, they are deleted, even though every sentence is exhaustively sourced. 20% of the time the article is put up for speedy deletion within 5 minutes.

A fear of lawsuits not surprisingly has created a atmosphere of fear. Your decisions have created an entire social structure in which content creators are bullied. You are responsible for this culture. Your choices of bullying leaders has consistently shown that you are responsible for this bullying culture. Your support of deleting content, again and again and again has shown that you are responsible for this company culture.

Last time you responded to me, you made statements which were factually incorrect, that only seasoned editors would know were false. Your not addressing the problem, your only consistently making it worse.

Mr. Wales, I don't blame any editor for deleting my contributions - because these editors are only responding to the company culture that you created and fostered. Your ultimately responsible for the disrespectful way content creators are treated here.

Mr. Wales, you have made a mockery of your own 2004 statement. You have lost your way, and should step down, and let new, true visionaries take your place.

(Let the personal attacks on me by your most virulent supporters commence. People who dare to question and threaten the status quo here are [passive] aggressively crushed.)

Igottheconch (talk) 07:12, 12 February 2014 (UTC)

Except that fear of lawsuits is probably not the main reason we delete copyvios such as yours apparently was. Wikipedia is supposed to be a free encyclopaedia and if you're using copyrighted material in an inappropriate way, even if it's justified under US law, then you're not serving our purposes to create a free encyclopaedia.
I'm not even sure that 'fear of lawsuits' really exists for most editors dealing with copyvios. Definitely the small number of times I've dealt with copyvios my main concern has been how this affects our free content ideals, not lawsuits. (IIRC I did once mention that violating a lawyers copyright as someone did in a copyvio I dealt with once was particularly stupid. But I didn't intend that to mean I thought there was any serious legal risk to the WMF.)
And dealing with such copyvios quickly is incredibly important yet also incredibly annoying so you shoudn't be surprised if people get frustrated with you for violating copyright. You should remember that not only is a fair amount of editors time spend finding and dealing wich such copyvios but a lot of time can be wasted in between. Consider this example I dealt with somewhat recently [6]. A lot of stuff was deleted which was part of the original copyvio, but of course that's just the work of the person who introduced the copyvio so while I feel some sadness, it's also their own fault. Yet there had also been a lot of touchup of the copyvio by other editors in good faith [7] which was wasted effort. So not only is it annoying but it's also vitally important we nip it in the bud.
Nil Einne (talk) 13:28, 12 February 2014 (UTC)
@Igottheconch... If you have had an article deleted due to copywrite concerns... the obvious solution is to start over - and rewrite it without the copyrighted material. Write the article in your own words. I would suggest creating a draft version in your User Space... then, before you "take it live" (by moving it to Article Space), ask a few experienced editors to review it. They can note if there are any issues that need to be addressed. If you work with other editors, there is a greater chance that the resulting article will pass any deletion review. Blueboar (talk) 13:42, 12 February 2014 (UTC)
Good idea. Just start it from scratch in your own words. Bearian (talk) 22:27, 12 February 2014 (UTC) Oh, and avoid using more than 25 % of text of quotes and more than two or three sentences. That's because the text gets "picked up" as a copyvio, even if it isn't. There's no strict guideline for fair use, but check out that article and Salinger v. Random House. Bearian (talk) 22:29, 12 February 2014 (UTC)
In addition to what others have mentioned, I would point out that even if we didn't care about legal implications, free content, or anything to do with copyright, using published text verbatim or with only superficial changes without marking it as a quote - even if you cite it - is plagiarism. Mr.Z-man 23:07, 12 February 2014 (UTC)
From what I have read I agree with the others, you placed copy-written material in the articles and they were deleted. Hey if the material is not yours then don't use it. Paraphrasing is okay as long as it is not done too closely, in short try to use your own words when you retrieve information from a source. - Knowledgekid87 (talk) 23:15, 12 February 2014 (UTC)
I recommend patrolling Special:NewPagesFeed for a while. It will change your perspective on article deletion. There's a lot of plagiarism, spam, and vandalism that tries to wade in, so it's necessary to keep the wall very high. Try assuming good faith and try to understand what lead to your articles being deleted. Ian.thomson (talk) 23:38, 12 February 2014 (UTC)
  • Clarification please. First, no offense to the individual or individuals who concluded material in those article contained copyright material -- I would be a lot more comfortable if an uninvolved third party looked at the deleted articles, ab initio, and confirmed first that those articles did contain copyright material; second, if only part of the article was a copyright violation, couldn't the non copyvio portion have been preserved?
I know there are instances where some good faith contributor flags material as a copyvio, where it turned out that, while a passage had been previously published elsewhere, and copied word for word into a wikipedia article, the individual who cut and paste the previously published material had been the original author and copyright holder of that material, where it was first published. Such instances are false positives. They are not copyright violations, as a wikipedia contributor is free to republish their own previously published passages, when they retain the copyright to those passage. Is it possible that there is confusion over these copyvio claims because OP republished passages they themselves wrote? Geo Swan (talk) 11:55, 13 February 2014 (UTC)

Thank you for your thoughtful responses As requested above if we are going to discuss this article Why don't we post it here and I can go by the article line by line why it is not a copyright violation, that the article falls within wikipedia policy also. May i ask How many of you are an administrator that can look at the article? will this exercise change anyone's opinion about hoe content creators are treated? No will this exercise change the company culture of Wikipedia? No. so there really is no point in continuing this discussion. Igottheconch (talk) 15:53, 13 February 2014 (UTC)

A Question about how to interpret WP:NFCC images

A question has come up during a challenge to the non-free image File:The John Irwin House, supported on temporary piles, 2014-01-26.png [8]

  1. 2014-01-26 -- the image was apparently taken 2014-01-26, and uploaded to flickr.
  2. 2014-01-30 -- By 2014-01-30 it had been republished half a dozen times or more, in articles that commented specifically about the image that accompanied them. I had never heard of the John Irwin House, prior to seeing the remarkable photo. I started an article on John Irwin House, and I claimed fair use and uploaded the image that inspired me to write the article, to illustrate the article.
  3. 2014-02-03 -- The National Post published an article on the house, and sent out their own photographer who took their own images, 2 of which are from the same POV as the original unfree image.
  4. 2014-02-05 -- A contributor who challenges a lot of NFCC images could be replaced by a free image challenged whether this image could be replaced by a free image.

On January 30th I considered going to Grenville Street, with my own camera, and checking first, whether the remarkable pylons were still visible? Second, if the pylons were still visible, could I get close enough to get a picture? I've taken hundreds of photos of construction sites, and there are complications in doing so. They are often surrounded by opaque fences that prevent photography. Construction staff will scream blue murder if they see you take one step onto the construction site, because you aren't wearing a hard hat, wearing safety boots, and represent a huge insurance claim against them if you injure yourself. The original flickr photographer may have found an open door, that should have been locked, which they were able to step through to take that photo. Even if I went to the construction site, and a remarkable photo was still theoretically possible, I could have waited all day, and not been able to get that shot. The series of photos taken by Darren Calabrese, the professional photographer dispatched by the National Post, seem to have been made with the cooperation of the site management, as his POV is within the security fence. Well, a big developer would be prepared to phone the construction management, and give the photographer from a National newspaper every cooperation, while telling a blogger or wikipedia volunteer to buzz off, and stay off the construction site or face trespassing charges.

  • So, how slim does the theoretical possibility that a free image could be made have to be, before that possibility is dismissed as not practically possible?
  • Today, is February 13th, and I don't have a couple of hours to go to the site, to check to see if a free replacement was possible. Suppose, by the time I am able to go to the site to check to see if a free replacement is possible, an administrator has agreed with the nominator, and deleted the image? Suppose I find a free replacement is absolutely no longer even theoretically possible, and document that with my own camera? Should I feel obliged to initiate a DRV, or can I then re-upload the original non-free image on the grounds I can prove no free image is even theoretically possible? Geo Swan (talk) 11:55, 13 February 2014 (UTC)
My two cents: This photograph captures a unique moment in time, and the positioning of this house as shown in the photo has generated a fair amount of media coverage in Toronto. Geo Swan has uploaded hundreds, if not thousands, of construction photos from the Toronto area to Wikimedia Commons. I think a site visit is needed, ideally documented with some photographs uploaded to Flickr (and if appropriate) to Commons, but if after such a visit Geo says that it is no longer possible to obtain a photograph showing the house in this state, then I trust that assessment and believe it suffices for our purposes. --Skeezix1000 (talk) 15:03, 13 February 2014 (UTC)
If you presently cannot get a picture due to 1) the pylons now being gone or obscured, or 2) the pylons would still be visible but to photograph it reasonably clearly would require access to the private site or illegal trespassing, then yes the non-free would be considered irreplaceably by free imagery as to meet NFCC#1. There may be other reasons the image can't be used, but that's the first check to be done if the image can be replaced. --MASEM (t) 15:19, 13 February 2014 (UTC)

Proposal: MOS should apply to portals

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

The supporters outnumber the opposers, but not by a wide margin. Further, several supporters raise caveats, and other participants suggest that this discussion may have been initiated as part of a specific content dispute rather than an abstract proposal. Taking all that into consideration, it is my opinion that there is no consensus to make any change based on this RfC, but that further discussion may be appropriate. HJ Mitchell | Penny for your thoughts? 14:49, 29 March 2014 (UTC)

Should MOS applies to portals? Mitch Ames (talk) 08:13, 18 January 2014 (UTC)


There has been some discussion at

about capitalisation of portal names, for both the page name and the use of the portal name in the banner on the portal page - specifically whether they should use title case or sentence case. It has been suggested that portals do not need to follow the general MOS: rule of title case, because MOS only applies to articles, not portal namespace.

Given that portals are:

  • explicitly intended for readers - according to WP:PORTAL, they are intended to serve as "Main Pages" for specific topics
  • linked to from article pages using {{Portal}}
  • required (by WP:P) to "comply with Wikipedia's core content policies"

I suggest that from the readers' perspective a portal page serves the same purpose as an article, and so we should update WP:PORTAL to explicitly state that portals should comply with MOS, and update MOS to state that it apples to portals. Mitch Ames (talk) 05:57, 5 January 2014 (UTC)

Just a really quick comments for now: IMHO,
  1. WP:MOS should definitely apply to portals too, where possible (in this case page titles). Portals are already required to comply with WP:V, WP:OR, and WP:NPOV, and are meant for readers too. It would actually be great if the MOS could have quick line or two on its applicability; if such a section is created I think we would expect it to say that it applies to pages meant for readers in general.
  2. I don't think it's immediately obvious that portal titles are proper nouns. The phrase "Portal:Page" just describes the page as a member of the set of portals. That said, I'm no linguist.
-Well-restedTalk 07:42, 5 January 2014 (UTC)
I would expect that portal titles would follow the same rules as article titles - if it's named after an existing capitalised proper name then we keep that capitalisation (eg Portal:Janet Jackson), but otherwise use sentence case (eg Portal:Australian roads, because "roads" is not a proper noun). Mitch Ames (talk) 10:01, 5 January 2014 (UTC)
I agree. The question shouldn't be whether all portal titles are proper nouns; it should be whether the phrase that comes after "Portal:" in the portal title, is a proper noun.-Well-restedTalk 15:01, 5 January 2014 (UTC)
My intent was that portals should comply with MOS for issues such as:
  • capitalisation (obviously),
  • date and number formats,
  • use of bold, italics, etc
and the like. I hadn't actually thought about layout, sections vs boxes, although as you point out they are quite significantly different. Personally I'm a minimalist, and I'm not that keen on multicolour boxes - but don't expect anyone else to be convinced on that point. So I limit my proposal to things like the bullet points above, and exclude WP:LAY and the like. This obviously makes it a bit harder to codify, but I still think that it is worth doing. Suggestions as to "exactly" what should or should not be included are welcome. Mitch Ames (talk) 13:25, 5 January 2014 (UTC)
Seems obvious that MOS should apply to portals, and if the nature of portals requires separate treatment, that is an editing issue for improving the MOS so that it meets all of our needs - including the any unique aspects of portals. NewsAndEventsGuy (talk) 15:19, 5 January 2014 (UTC)
If every guideline in MOS applies to portals, then the first sentence ["The Manual of Style (often abbreviated MoS or MOS) is a style guide for all Wikipedia articles."] can be expanded with the two words "and portals" ["The Manual of Style (often abbreviated MoS or MOS) is a style guide for all Wikipedia articles and portals."]
—Wavelength (talk) 02:50, 6 January 2014 (UTC)
As Mitch pointed out above, its unlikely that there will be consensus to completely restyle portal layout/sections to the current MOS standards. There may be other areas of the MOS that haven't been designed with portals in mind, because portals aren't articles – they are mini-Main Pages for specific subject areas. - Evad37 [talk] 04:18, 6 January 2014 (UTC)

(Note: I have placed on Wikipedia talk:Manual of Style a notice of this discussion - Evad37 [talk] 01:36, 6 January 2014 (UTC))

Let me reiterate my views since the discussion have forked all over the place. As I raised earlier on the other page, this is a classical bicycle shed (aka Parkinson's law of triviality) discussion. Other than having a consistent "look and feel" on the header, nothing else is achieved (while at the risk of breaking many subpage components). And going along with the law of triviality, I see that no one raises WP:EMDASH and WP:ENDASH issues (both fall under MOS) on the Main Page today. Perhaps, like what "the law" described, everyone is too intimidated to touch it because the Main Page was deemed to be too technical and "so one assumes that those that work on it understand it" while WP:TITLEFORMAT is easy to understand so "everyone involved wants to add a touch and show personal contribution" (and we haven't even begun on whether MOS applies on portals)? I'm glad that portal is drawing more attention. But sadly this is more drama than actual content improvement. OhanaUnitedTalk page 08:07, 6 January 2014 (UTC)

  • Looking at the featured portal criteria, portals - or at least featured portals - are already required to comply with parts of the MOS... "It adheres to the standards in the Manual of Style and the relevant WikiProject guidelines; this includes conventions on naming, spelling, and style". Does this resolve the (main) issue in this thread? - Evad37 [talk] 16:14, 7 January 2014 (UTC)
Ping @Mitch Ames: - Evad37 [talk] 10:17, 9 January 2014 (UTC)
WP:FPO? does indeed imply that portals should follow MOS, in that "our very best work on portals ... adheres to the standards in the Manual of Style". Assuming that we all agree that portals should (in general) follow MOS, I do think we need to update WP:PORTAL and/or WP:PORTG to explicitly say so, and update MOS to say "applies to articles and portals". It ought only be few extra words on each page, and should then prevent future disagreements along the lines of "portals are not articles (because they are in different namespaces) and MOS says it (only) applies to articles".
As far as WP:MOS#Section_organization and WP:LAY are concerned, I don't think there is a problem. They currently explicitly refer to articles, so we leave them unchanged. Lots of other parts of MOS probably also refer to articles, but I don't propose going through and changing them all (or those that are appropriate) to "articles and portals". I think one statement at the top of WP:MOS that "The Manual of Style ...is a style guide for all Wikipedia articles and portals" would be sufficient to express the intent. Mitch Ames (talk) 13:13, 9 January 2014 (UTC)

The proposed change

I propose the following specific changes:
WP:MOS, first sentence:

The Manual of Style (often abbreviated MoS or MOS) is a style guide for all Wikipedia articles and portals.

WP:PORTG, lead section, insert new paragraph between the existing two:

Portals should normally follow the Wikipedia Manual of Style, although the nature of a portal will sometimes preclude this. (For example, WP:LAY will generally not apply to portals.)

Can I have some indication of agreement or objection to these changes. Naturally suggestions for improvements to the wording are encouraged. Mitch Ames (talk) 13:42, 9 January 2014 (UTC)
I support you proposal, Mitch Ames. --NaBUru38 (talk) 23:23, 10 January 2014 (UTC)
The proposed changes seem appropriate - Evad37 [talk] 06:02, 13 January 2014 (UTC)

I don't get it. This seems like trying to change the rules to force the renaming of a portal to what the proposer wants it to be. Am I missing something? Are there other examples where said "noncompliance" has been an issue? --Rschen7754 06:10, 13 January 2014 (UTC)

I've proposed the additions to the guidelines for the reasons that I listed in my initial post. Obviously I would prefer that the specific instance (Portal:Australian roads) follow the new guidelines - for the same reasons as listed in my original post, to present a consistent style to the readers. Note that my proposed change is not a radical change - it is consistent with the overall reason for having a Manual of Style (to present a consistent style to the readers), and is also consistent with what is stated (eg WP:FPO?) or implied (eg adding portals to articles) in other parts of the guidelines anyway.
If you disagree with the proposed additions, and/or my reasoning for the additions, please say so explicitly, and also why you disagree. Mitch Ames (talk) 12:09, 13 January 2014 (UTC)
First of all, this needs a sitewide RFC, and posting to the appropriate pages (WP:FPOC?) Secondly, it's generally a bad idea to change a rule when we don't like one certain implementation of it. Have we thought through all the ramifications? In such a short discussion, I don't think so. --Rschen7754 09:46, 15 January 2014 (UTC)
Also, when one of the Featured portal candidate directors is telling you this is a bad idea, you should stop and pay attention. And you still haven't answered my question "Are there other examples where said "noncompliance" has been an issue?" --Rschen7754 09:51, 15 January 2014 (UTC)
"this needs a sitewide RFC, and posting to the appropriate pages"
I've raised an RFC. There is already an item at WT:PORTAL, but feel free to mention this discussion anywhere else you think appropriate.
"it's generally a bad idea to change a rule when we don't like one certain implementation of it"
It's not I "don't like one certain implementation" - I would "not like" any of the portals that use title case, when articles generally use sentence case, because it seems to me to be inconsistent. I raised the matter at one specific portal (Portal:Australian roads) because I was looking at that portal for other reasons and noticed the discrepancy in the use of capitalisation. When I raised the matter on that portal's talk page it was suggested that a broader discussion was required and then ultimately at WT:Portal#Capitalisation of portal names it was suggested that there was no need to change the portal(s) because MOS did not apply to portals. At that point it occurred to me that perhaps MOS should apply to portals, for the reasons I listed in my initial post here.
"Have we thought through all the ramifications?
The ramifications are much like any other change to the guidelines. With any luck new articles/portals will follow the new guidelines. Editors may or may not update existing articles/portals as they see fit. If specific portals can be updated easily, good. If there are problems on specific portals then we will ignore the new guideline and not change the portal.
"Also, when one of the Featured portal candidate directors is telling you this is a bad idea, you should stop and pay attention"
OhanaUnited's primary objection to this proposal (other than that it is not something more important) appears to be that it might break subpages - presumably on existing portals. However changing the guidelines does not automatically mean that we must change every portal to comply. What I hope it will mean is that over time, the majority of portals will become more consistent in style to the articles. I also remind both the Featured portal candidate director and Rschen7754 that the featured portal criteria already state that featured portals should comply with MOS. Given that featured portals "exemplifies our very best work on portals" and featured portals should follow MOS, it seems logical to me other portals would be better if they also followed MOS.
"Are there other examples where said "noncompliance" has been an issue?"
I'm not aware of other examples of editors debating whether sentence or title case should be used on a portal page. There are other portals that use title case, eg Portal:Molecular and Cellular Biology. Portal:History of science uses title case in the banner (but not the page title).
Mitch Ames (talk) 09:10, 18 January 2014 (UTC)
In short, if it ain't broke, don't fix it. I still don't see why this is a serious enough problem to justify the large page moves and cleanup that this would require. And now that this is officially a RFC, Oppose. --Rschen7754 09:39, 18 January 2014 (UTC)
This proposal is not to move any pages, it is to change WP:MOS and WP:PORTG. Mitch Ames (talk) 12:42, 18 January 2014 (UTC)
But it would require the portals to be moved to hit/keep featured portal status, no? --Rschen7754 08:05, 24 January 2014 (UTC)
According to WP:FPO? item 2, even without my proposed change, featured portals should already follow MOS, so strictly speaking my proposed change would make no difference to featured portals or candidates. As I said previously if portals (featured or not) can change to comply with MOS where appropriate without major problems then they should, although there's no urgency to do so. As with any other change to MOS, we don't all stop work on everything else just to make sure all existing articles comply with the new guidelines - we try to follow the guidelines on new material, and fix existing material when convenient. I'm not going to check every featured portal and insist that its status be revoked because it doesn't follow MOS, and I doubt anyone else will either. (But if I or anyone else was inclined to do that, we could do that anyway because of the existing WP:FPO? item 2.) Mitch Ames (talk) 04:00, 25 January 2014 (UTC)

Is there a proposal? It has been pointed out that the MOS already applies to portals. Can we leave it at that? Dicklyon (talk) 03:01, 20 January 2014 (UTC)

The specific changes proposed are listed above - in particular this edit of 13:42, 9 January 2014 (UTC).
Currently WP:MOS says it applies to articles and doesn't mention portals (which are a different namespace, so might be thought not to be articles), and WP:PORTG doesn't mention MOS. One can indirectly deduce that portals ought to comply with MOS by virtue of the mention on WP:Featured portal criteria, but I think it should be state explicitly on the "front page" of the relevant guidelines. Mitch Ames (talk) 13:16, 20 January 2014 (UTC)
The new heading helps. Dicklyon (talk) 16:39, 20 January 2014 (UTC)
  • Support – the small reminders may he helpful if some editors are unaware or are claiming that MOS is not applicable to their portals. Dicklyon (talk) 16:39, 20 January 2014 (UTC)
  • Support – if featured portals are already supposed to comply with the MOS then it stands to reason that the other portals would be better if they did, too. And these changes are extremely modest. AgnosticAphid talk 09:36, 22 January 2014 (UTC)
  • Oppose - This seems to me to be yet another case in which the Manual of Style, rather than being used as a set of good writing practices, is used as a weapon by one side of a dispute. In one of the other forums where this came up, both Featured Portal directors told you that moving portals is a difficult and risky proposition. As one of the most active portal namespace editors other than those two, I am going to tell you the same thing. Literally a few hours ago, someone broke a portal by botching a move, and I had to track down someone with more experience and fancier tools than I have to fix the mess. There are plenty of portals that could be renamed. I'll note that three of the roads portals are Portal:Australian roads, Portal:Canada Roads, and Portal:U.S. Roads. Aside from that Roads is capitalized in one and not the other, we have one portal using the demonym (Australian), one using the simple name (Canada), and one using an acronym (U.S.). If you take a look at the running list of portals that I have, you'll note that Portal:Canada Roads and Portal:U.S. Roads are in the minority in capitalizing the second word; with the obvious exclusion of proper nouns, no one else is doing it that way. Portal:Alternative rock, Portal:Ancient warfare, Portal:Arab–Israeli conflict, Portal:Artificial intelligence, and Portal:Atmospheric sciences are some of the ones that don't capitalize the second word, while Portal:Aquarium Fish and Portal:Atlantic Archipelagoes do. Does this bother me? Yeah, a tiny bit. Am I going to force the issue? No. Considering that some portals will have to be manually fixed, which may take hours, I don't think it's worth it. If people spent as much time improving portals as they do arguing about them, we might not have so many terribly shitty portals out there. TLDR: I am not convinced that this is a good faith effort to improve the portal namespace, but rather an attempt to use the MoS to further a dispute. As such, I'll have no part of it. Sven Manguard Wha? 23:43, 26 January 2014 (UTC)
My response to this is basically the same as to Rschen7754 (2014-01-18, 17:10 (UTC+8)) - just because we change the guidelines doesn't mean we must change every portal.
"If people spent as much time improving portals as they do arguing about them, we might not have so many terribly shitty portals out there"
If we made the guidelines consistent (per my proposed changes), we might get slightly better portals in future. Mitch Ames (talk) 09:49, 27 January 2014 (UTC)
  • Oppose, portals are a niche area that should stay open to experimentation in style issues (and otherwise). Hard rules (especially rules that are codifications of best practices on non-portals) = less fun for portal creators. The capitalisation of portal titles seems like a complete non-issue to me, certainly not worth the substantial amount of work that renaming portals brings with it. —Kusma (t·c) 12:05, 27 January 2014 (UTC)
  • Support in principle, with the caveat that all users present understand that there's no urgency in enforcing MoS on portal pages. Users can continue to ignore MoS where there's good reason and consensus to do so. SamBC(talk) 12:09, 27 January 2014 (UTC)
  • Oppose for now. I have always loved the idea of portals, but they aren't working right now - they barely get any traffic. If they are to re-invent themselves in something that are used more (and I hope they do, I think they could be really useful) they need to have as little interference of "but rule x says y" as possible. Once they start taking off and getting more use again, we could then (optionally) set up style guidelines in MOS that govern portals, but now MOS "interference" is the last thing that portals need, and if they can become better by ignoring MOS they should certainly do so. Martijn Hoekstra (talk) 09:35, 31 January 2014 (UTC)
"if they can become better by ignoring MOS"
How does portals having different styling (eg capitalisation) to the articles make them better? Perhaps the portals would be "better" if they looked more like they were a part of Wikipedia, with similar style.
"they barely get any traffic"
Perhaps we should pick the best of them, ones that we think exemplify our very best work. We could look at what makes them so good then propose that other portals should perhaps follow similar guidelines so the other portals would improve. Mitch Ames (talk) 03:05, 1 February 2014 (UTC)
  • Support this should be a no brainer but it nothing ever is any more... Portals are designed to be a front page for a topic area they should follow MOS. This isnt so much creating a another branch to the MOS stick beat people up in discussions with but ensuring that MOS/PORTG reflects best practices already in use by the community. Gnangarra 11:40, 2 February 2014 (UTC)
  • Oppose Virtually all discussions are directed towards WP:TITLEFORMAT part of the MoS. I just can't connect the dots on how adhering to TITLEFORMAT will bring "slightly better portals in future". Materials don't get written by itself nor having an MoS rule will encourage participation rate in portal namespace. Having stepped away from this discussion for close to a month allowed me to look at this issue from a fresh perspective. Up to this point, I have not seen an example where this issue results in content of inferior quality. Can anyone show an actual example where MoS non-compliance caused poor contents to appear in portal? If no evidence can be produced, then to me it appears to be a non-issue. OhanaUnitedTalk page 02:43, 5 February 2014 (UTC)
    • "Virtually all discussions are directed towards WP:TITLEFORMAT part of the MoS."
      The matter that caused me to raise this proposal in the first case was MOS:CAPS, rather than WP:TITLEFORMAT. ("Use lowercase [for artitle titles], except for proper names" is a subset of WP:TITLEFORMAT and MOS:CAPS.) So my specific example is about capitalisation, but it could just as easily have been any of (most of) the other things covered by MOS.
A specific example is Germ theory of disease, which includes in its See also section a link to Portal:Molecular and Cellular Biology. If we accept the MOS:CAPS guideline that we should consistently use sentence case – not necessarily because sentence case is better, but because consistency is better – then Germ theory of disease would be a better presented article if it consistently used sentence case, including in its See also section. Likewise if the reader decides to further investigate the subject of molecular and cellular biology by clicking the link (an internal link, not an external link) from See also, the reader is still reading Wikipedia so would get a more consistent, and thus better, experience if the portal generally followed the same styling guidelines where feasible (eg not WP:LAY). I know it's not a major improvement in the grand scheme of things, but if we think it's important enough to have a Manual of Style at all, presumably it ought to apply all of the pages that we explicitly want our readers to look at. Mitch Ames (talk) 11:24, 5 February 2014 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Another Question about how to interpret WP:NFCC images

I have been concerned that many of our discussions over NFCC images have inappropriately placed concerns over the possible loss of revenue to the copyright holder over the value to the public over the "fair use" of the image.

At its base, the reason nations grant copyright protection to intellectual property is that new ideas, new inventions, new ways of expressing ideas, new ways of expressing our culture(s), are all in the public interest. Almost every nation on Earth believes in progress. Copyright holders and inventors, are encouraged to go on and create new inventions, new works of art, because there is a limited term where they can make a profit from their earlier works.

Well, at its base, nations also allow the "fair use" because lawmakers recognized there are certain limited circumstances where making an image that would normally be protected by copyright, available to the public is in the public interest. I suggest when the conditions where the law allows a re-user to claim "fair use" apply, the fair use usage takes precedence over the copyright owner's rights.

If copyright owners could challenge any and all claims of "fair use", solely on the grounds they might lose money, could any claim of "fair use" withstand a court challenge?

I am not a lawyer, probably almost none of us in their fora are, and since no wikimedia contributor participating here who is coincidentaly a lawyer, is putting their professional reputation on the line, and has presented any credentials showing they have any genuine expertise in intellectual property law, we shouldn't regard any of us as having any reliable legal expertise.

The wikimedia foundation has employed lawyers, lawyers whose credentials were on record, who were paid for their legal advice, and whose legal reputation rested, to some extent, on whether that advice turned out to be well-advised. I don't believe the WMF legal advisors have offered an opinion on this issue. But I suggest there are parallels to the legal advice offered with regard to when we should treat images that were taken outside the copyright protection of US copyright law as if they were protected by international intellectual property right protection.

Afghanistan had never passed any copyright laws, patent laws, trademark laws, and had never signed the Berne agreement, or any other international intellectual property right agreement. Up until recently we regarded images taken by Afghans, in Afghanistan, and published in Afghanistan, and not "simultaneously" published in Berne-world, as being in the public domain. The flip side of this for Afghans is that there was nothing in Afghan law that prevented them from using any intellectual property from anywhere else as freely as they wanted. A couple of years ago we learned that Hamid Karzai, the President of Afghanistan, had enacted the Afghan equivalent of an Executive Order on intellectual property, and we started to treat images from Afghans as if they were as protected by International intellectual property right agreements as any other image.

My recollection of the legal advice we received from our legal team was that we had a legal obligation to respect the intellectual property of images of citizens of any country that had both passed its own intellectual property right laws, and had signed an intellectual property right agreement. Our legal team went on to say that the Wikimedia Foundation was free to enforce its own further restrictions, but we weren't obliged to do so, and such restriction had no legal force.

So, although many people involved in the discussion of Afghan images asserted we were "legally obliged" to treat Afghan images as if they protected by intellectual property laws, they actually remain in the public domain.

Similarly, nothing prevents us from agreeing on a policy on fair use images that offered copyright holders far more extensive protection of their right to make a profit than that we are legally obliged to offer. Fine. But if that is what we choose to do, let's make sure we all continue to understand the difference between the restrictions we are legally obliged to offer, and the more extensive protection we chose to offer.

Did we ever really explicitly decide to provide revenue stream protection to copyright holders, or did that clause get included into WP:NFCC due to an excess of enthusiasm or an excess of caution?

Personally, I don't see why we should protect the revenue stream of copyright holders, in those rare and limited circumstances when their images do legitimately qualify for fair use usage. Geo Swan (talk) 17:17, 13 February 2014 (UTC)


Our concern with non-free images is not the legality side of IP, but the fact that anything burdened with IP will be an issue to a potential redistributor of our content. As such, we will take careful steps to make sure anything that carries a recongized copyright to be treated as non-free. Jimmy Wales has also gone on record (I'd have to search for this) that we should respect the copyright of countries that do not have reciprical copyrights with the United States , even though under US law material copyrighted in those nations would not be considered copyright here. --MASEM (t) 18:29, 13 February 2014 (UTC)
  • Thanks for your reply.
WRT your first point, "anything burdened with IP will be an issue to a potential redistributor of our content." Are you referring to readers, who see an image on one of our articles, and decide to re-use it on some non-WMF site? Potentially, any of our readers could download an image we were using in a valid "fair use" context, and re-use it elsewhere in a way that would never qualify as a "fair use". But how would that be different than one of our readers re-using a creative commons or gfdl image, and either treating it as public domain, or crediting the wikipedia contributor who uploaded it instead of the actual photographer?
It isn't different. In both cases we have fulfilled our obligations when the information templates we used accurately stated the source, and the license or fair use rationale. There have been a couple of dozen times when I have seen a free image I merely uploaded has been credited to me, personally, or to the wikipedia -- rather than to the actual copyright holder.
What should I do in that case? Well, what does the WMF do, when a WMF contributor has uploaded one of their own images, only to find one of our readers is lapsing from compliance with the license the uploaders chose? If I am not mistaken it is WMF policy to do nothing. Haven't we left the legal burden of making sure the remaining IP rights of our contributors are respected totally up to the individual contributors.
Way back in 2005 or 2006 there was a change in what kind of licenses we accepted. Up until that time licenses that "no commercial reuse" were allowed. As I recall, the explanation offered at that time was that the "no commercial re-use" clause was that someone thought it complicated a deal being cooked up that would see a canned version of the wikipedia distributed with a linux distros.
But, as I wrote above, is policing our readers, to make sure they comply with the licenses our text and images were released under, our job? If we really thought it was our job the simplest solution would be to only use public domain images. If policing our readers is not our job, readers who mis-use fair use images are no more of a problem for us than readers who misinterpret and mis-use gfld or cc licensed material.
With regard to Mr Wales' opinion that we should "respect the copyright of countries that do not have reciprical copyrights with the United States"... This might seem respectful, but it is actually a kind of colonialism. Inherent in our attitude about IP rights, their need for protection, etc, is the idea that "progress is good". (Limited) protection of IP rights is good, because inventors and creators of works of art, cultural expressions, get a monetary reward, that encourages more scientific, technical and cultural progress.
Well, the Taliban, and a lot of our non-Taliban Afghan allies, don't believe in progress, and would happily see several centuries or millenium of progress rewound. The reason why the Afghanistan legistlature has never passed laws protecting copyright of images from Afghanistan, or endorsing and signing on to international IP agreements is not they were too stupid to know how to run their countries, and too stupid to understand that such laws would encourage progress. I suggest that there was not enough political support for "progress" in Afghanistan and the other nations with no IP protection for such laws to be passed. I suggest they weren't too stupid to pass those laws; they weren't too slow to have apssed those laws yet; rather, they knew what they were doing, they didn't believe in "progress", and so did not pass laws to encourage "progress".
There are small slivers of anti-progress people in the USA too. Lovely, peaceful old order Amish and Mennonites have stuck with horse and buggy, and foregone electricity, because they do not subscribe to the idea progress is always a good thing. Well-armed and dangerous survivalists like the Unabomber don't believe in progress either.
When a nation, like Afghanistan, whose legislature have never passed copyright laws or passed legislation endorsing international IP right agreements, it is colonial to act like their passage of such laws is inevitable. If my recollection is correct the Wolesi Jirga and Meshramo Jirga did not pass a copyright law, rather President Karzai issued something like an Executive Order. His proclamation was taken so seriously it took us years to even hear about it.
Karzai's term is almost finished. Allied presence in Afghanistan is almost at an end. The USA proved in Iraq you can't easily force a whose other country to adopt a whole new set of values.
On a personal level I dread the idea that the next Afghan President might withdraw the limited support for educating girls, and other reforms Karzai introduced. It is not unlikely. I would not agree to a second invasion. Geo Swan (talk) 22:04, 13 February 2014 (UTC)
We are not here to fight copyright problems and incongruities around the world. We are here to build an encycloped with a free content mission as to allow end users to be able to reuse and redistribute it. As such, we have no control on what the end user does with the material (and we have disclaims to disavow WP from anything wrong they do), but that's why we focus on media that is free for reuse and modification. The FOundation does allow otherwise non-free images to be used in limited circumstances and readers are expected to verify that they are allowed to do what they want with these images before reusing/modifying. We are not policing readers but editors to make sure that if there is a chain of copyright we have properly documented it so that readers know what they are getting if they're doing more than reading on WP. --MASEM (t) 22:52, 13 February 2014 (UTC)
With regard to the international copyright treaties, most (including Berne) are both for reciprocal protection and at least some harmonisation of law. This means that a country may not want to sign, not because they don't want progress, but because they don't see the law changes that would be necessary for them to sign up for the treaty as promoting progress. MChesterMC (talk) 11:23, 14 February 2014 (UTC)

SARS, anti-virals, and IP protection -- a cautionary tale

SARS started in China, but Canada was one of the first nations where it spread, and, after China, it had among the most casualties. The USA was orders of magnitude more lightly hit.

When SARS hit it was recognized that it was viral, but no one knew how it was spread, but a particular anti-viral drug was believed to be of value in preventing front line health workers from acquiring it from infected individuals, and in preventing front line health workers from spreading the virus to previously uninfected patients visiting hospitals for other reasons.

Allan Rock was Canada's Minister of Health during the SARS crisis, and he personally contacted the management of the pharmaceutical company that owned the rights to manufacture and distribute the trusted anti-viral drug in Canada. He asked if they could ship enough doses to give a preventive dose to all the front-line health workers in Toronto, the city most seriously affected by the crisis. And he was told "no", the company couldn't ship that many doses.

Rock then invited bids from other pharmaceutical companies in Canada -- could they provide the urgently needed anti-virals?

Well, the original pharmaceutical company went ballistic. THEY owned the IP rights to that drug in Canada, and they promised to use every means at their disposal to impede the emergency delivery of this drug.

I think this incident highlights why we always have to remember why nations grant IP protection. Nations grant (limited) IP protection because it is seen to be in the public interest. If that pharmaceutical company really didn't have a stockpile of the anti-viral, they could have volunteered to license other firms to manufacture the anti-viral, for the duration of the crisis.

My recollection was that the company in question was only nominally a Canadian company, that it was really the Canadian face of a much larger US company, and that most or all of its senior management we US citizens. My recollection was that their stock of anti-virals was large enough they could have supplied Rock's entire order, but that they decided not to ship any drugs to Canada, and to reserve the entire stock for distribution within the USA.

Even from a purely US public health standpoint this was extremely short-sighted. It would have been far better for public health, far better for world public health, to use the anti-virals to stop the spread of the virus from cities that were the most heavily affected, without regard to borders.

So, with regard to those whose feeling is that we have to protect the revenue stream of those who hold intellectual property rights -- at all costs, I offer this example as to why we should not protect IP rights owner's revenue streams at all costs. Geo Swan (talk) 17:17, 13 February 2014 (UTC)

I personally think you're looking at this the wrong way. Wikimedia projects go beyond what the law requires in not using nonfree material because free is better than nonfree. Wikipedia is a free encyclopedia project. We're working on producing a free product here. Regardless of what different legal regimes allow us to do with nonfree material, every introduction of nonfree material adulterates the free product. We place a high priority on trying to minimize the impact of that. It's not about the revenue streams of rights-holders; it's about our free encyclopedia. Ntsimp (talk) 05:01, 17 February 2014 (UTC)

Proposed naming convention (UK Parliament constituencies)

Advertising the proposed Wikipedia:Naming conventions (UK Parliament constituencies) here, as specified in Wikipedia:Article_titles#Proposed_naming_conventions_and_guidelines PamD 13:41, 17 February 2014 (UTC)

ro.wikipedia on things across Dnestr river

Dear friends,

I find it's just a shame the language used by ro.wikipedia as soon as it comes to issues across river Dnestr.

We all know there is an unresolved conflict. And those who are not biased also know who, by slogans calling for ruthless expulsion of all Russian and Ukrainian taxpayers, started the tensions leading to the break-off.

I deem it is NOT wikipedia's role to blame and slander the citizens of Transnistria. They have several parties; they elect their president and parliaments. The constant use of "terrorist", "separatist", "illegal" is unworthy of Wikipedia and unfit to its style. So my question is: Is there anyone in position to suppress those outbursts of chauvinism - be it in Wikimedia, be it in ro.wikipedia?


Apart of being full of bias, the articles are stubs and are full of spelling mistakes - cf. e.g. Grigoriopol city and rayon, and compare it to the Ukrainian version. Thank you for reply to: Lillian Happel on facebook.com (as you warn against publishing one's email address)

P.S. I did follow those revengeful and fruitless discussions prior to the closure of the Moldovan Wikipedia. In fact, those wanting to express themselves in Cyrillic script just publish in ru. or uk.Wikipedias. The ideal solution would be like the Serbian Wikipedia - a two-scripts Wikipedia, but I know it is politically not feasible. 131.188.2.11 (talk) 16:13, 14 February 2014 (UTC)

Er, we can't help with other language wikis here. You might try [9]. KonveyorBelt 16:30, 14 February 2014 (UTC)
Why not just ask on rowiki itself? πr2 (t • c) 19:29, 20 February 2014 (UTC)

Fair use video clips

Hello,

Can we use, in Wikipedia articles, short video clips of non-free content as "fair use"? For instance, to show the specific ambiance and graphic style of a film like Sin City, or to show on Frankly, my dear, I don't give a damn how the line is delivered (voice tone, facial expression, ambiance, etc.). I think it would significantly add to an article about a movie line, to show the line itself being delivered, no?

The same kind of thing is done with numerous images or short audio clips (e.g. a screenshot to show the ambiance of Sin City, an extract of "I Have a Dream" to show King's voice and intonation, an extract of "We Are the World" to show its musical structure), and they generally add really useful information to the article; but I've never seen it done with a video clip, is there a specificity about video that prevents to do the same? Was there a consensus to try to avoid non-free videos on Wikipedia? Wouldn't that be useful? Or is it simply that nobody did it yet, but we can?

I haven't found a precise recommandation about that; Wikipedia:Non-free content #Unacceptable use simply says that "a short video excerpt from a contemporary film, without sourced commentary in the accompanying text" would be unacceptable use.

Thanks for your help! - Cos-fr (talk) 11:46, 17 February 2014 (UTC)

For examples, there are File:Janeway's exit in Tuvix (reduced).theora.ogv for GA Tuvix, and File:Dredd (film) - Visual Effects.ogv for FA Dredd. If this helps. Chris857 (talk) 16:25, 17 February 2014 (UTC)
Video clips can be used as non-free media, but they should be as short as possible (we don't have exact advice but I would recommend no more than 30s, and trimmed to the most important portion), need to be low resolution, and encoded properly. But the use needs to be something where either the combination of video or audio, and/or the actual motion/direction is the subject of discussion of the article (and nearly always going to need sourcing to explain its importance); if the same can be done by stills, it is better to use that. Take for example Sin City - I know the movie is noted for capturing the harsh black and white world with very limit color use, but this can be done with a screen shot showing this palette; the motions aren't as critical in terms of discussion (but this is off the top of my head). In contrast, the Dredd clip is there to show the use of the slow motion effects of the drug-induced state which was discussed critically in the article.
I'd strongly recommend avoid using this to show how movie lines were delivered, unless, like in the case of your "Frankly..." example, the line itself is notable, and been discussed a lot of times in context, so a video might be appropriate. But again, before using a video clip, make sure that it is the combination of video and audio that makes it notable or if we can get away with just audio, a still, or the like. --MASEM (t) 17:08, 17 February 2014 (UTC)
I agree with Masem's take on this... while short clips are allowed, we don't want articles to include gratuitous clips... just because we can. The clip should clearly illustrate something said in the article... and if there is a better method of illustration (a still, an audio file, etc), use that other method instead. Blueboar (talk) 17:56, 17 February 2014 (UTC)
I'd say 30 seconds is on the long side, and to be safe you should keep it very short. -- Fuzheado | Talk 23:18, 17 February 2014 (UTC)
Thanks a lot for all this advice, and the existing examples (which led me to Category:Non-free video samples). Yes, I meant short clips, strictly reduced to the most relevant part, and when I mentioned movie lines I only thought about those notable enough to be heavily discussed in a dedicated article or section.
I understand the general guideline like this: don't put gratuitous clips, i.e. use them when needed to illustrate something discussed in the article, and only use video when any "less rich" medium (still image, audio clip) wouldn't suffice to illustrate.
I suppose that this "no gratuitous clips" limitation was more decided by the Wikipedia community (because we're writing an encyclopedia here, or other reason decided in the project; and also to minimize legal exposure hazards), than it is really required by fair use strictly speaking? I mean, for instance, if Wikipedia wanted to include for each film a short video excerpt to show what it looks like, that would be something legally feasible as fair use, right? (Disclaimer, just in case: no, I don't plan to do it. I'm just asking this theoretically, to better understand the rules regarding non-free content here.)
Cos-fr (talk) 03:01, 19 February 2014 (UTC)
From a true fair use standpoint, short video clips should not be any legal problem. Our issue with video clips from non-free sources is two fold:
  • Accessibility - we're still working on getting it easy for video clips to be played. One should assume that not everyone yet can play them or have the bandwidth for them.
  • Our free content mission, or more specifically the Foundation's Resolution that we minimize non-free use, means we should consider the least amount of non-free media that does the job. Take the Sin City case - while a video clip and a still will show off the color palette equally well, the extra content in the video part will likely be excessive. As such, the still is generally preferred over the clip.
We're otherwise do allow clips but we just ask to consider if there are better alternatives before resorting to them. That's why you see so few of them around. --MASEM (t) 04:17, 19 February 2014 (UTC)
Understood, thank you very much for your explanations! - Cos-fr (talk) 17:17, 19 February 2014 (UTC)

We seem to have a slight disagreement on this subject at Talk:Sports in Alaska. I recently converted what was an extremely poorly constructed article into a more comprehensive list consisting solely of internal links. As the individual articles linked to would have the actual content on this subject I deliberately removed the few refs that were attached. As a result another user tagged it as unreferenced and we've been playing "dueling policy links" since then. So what would be great would be if more users comment on the situation so that we know what, if anything, needs to be done to the article. Beeblebrox (talk) 08:20, 24 February 2014 (UTC)

Policy question about article content

Can somebody help me with a phrase which is embodied within Wikipedia?

I have heard that it is the goal of wikipedia that articles should be able to reach the general public.

Does anyone know one place where this policy is stated online? Thanks! --HowiAuckland (talk) 19:25, 24 February 2014 (UTC)

Are you looking for WP:MTAA? WhatamIdoing (talk) 23:51, 24 February 2014 (UTC)
I would ask what you mean by "reach the general public". Do you mean be written in a manner that can be understood by the general public or are you asking about the distribution of content to the general public? Wikipedia is free, but you do have to have some sort of internet access to use it, although there was the Wikipedia CD Selection some years back as well that was intended for use in schools. Beeblebrox (talk) 23:59, 24 February 2014 (UTC)
Hi! You may mean this or this. Good luck! --NaBUru38 (talk) 18:30, 25 February 2014 (UTC)

Four paragraph leads

An RFC has been opened on the guideline that leads normally be a maximum of four paragraphs at Wikipedia talk:Manual of Style/Lead section#RFC on four paragraph lead SpinningSpark 12:24, 28 February 2014 (UTC).

Why are some articles removed?

What is the policy on removing articles that seem significant?

Specifically, why was an article on "Dr. Geza De Kaplany" removed, while the article on "Richard Speck" was not? — Preceding unsigned comment added by 67.180.237.77 (talk) 18:51, 22 February 2014 (UTC)

I see that Geza de Kaplany was speedy deleted four years ago as an "attack page" or "negative unsourced BLP", but this appears to have been incorrect to me. There are multiple references included in the last article version that was deleted (including a whole book about this convicted murderer), just no inline citations. Looks like a good WP:DRV candidate to me. postdlf (talk) 19:05, 22 February 2014 (UTC)
There are not "multiple references", there is actually only one cited source, an encycloedia referenced at the end and there are no details or page numbers and so it is impossible to say what, if any, of the negative material came from it. It's a crime bio, so it is all negative. However, if someone wants to write a new article, properly referenced there there's no problem with that, and no reason an admin wouldn't e-mail them the contents of the deleted article to assist them. Review the WP:BLP policy (unless you've got cited sources saying he's dead) and go ahead. Nothing to discuss on DRV.--Scott Mac 21:09, 22 February 2014 (UTC)
You must've also missed the sentence in the article beginning "As recounted by San Francisco Chronicle reporter Carolyn Anspacher in her 1965 book, The Trial of Dr. De Kaplany..." And why is it "impossible to say what, if any" came from the cited Encyclopedia of American Crime? Presumably one would consult the printed work and look for an entry on De Kaplany in the TOC or index, really no harder than if a page number was given. Whether it would have survived AFD at the time may be another question, but this was an inappropriate speedy deletion. Now in 2014 we also have numerous Google books hits clearly about this murder case, with visible previews that verify many of the details even if we ignore the two print references for some reason in the deleted article history. postdlf (talk) 01:01, 23 February 2014 (UTC)
For negative BLPs, I think it's best we err on the side of deletion rather than keeping, in the best interests of the article's subject. The deletion at least has not caused further harm to the encyclopedia, but the article is, if what you say is true, a valid candidate for reexamination at deletion review. In which case it would probably need to be restored and userfied with NOINDEX so the rest of us non-admins can examine it. TeleComNasSprVen (talk • contribs) 11:22, 23 February 2014 (UTC)
There is no need for this to go to deletion review. If someone is wanting to work on it, and ensure that all negative claims are precisely referenced, I'm willing to give them the material right now so that they can do that.--Scott Mac 14:03, 23 February 2014 (UTC)
Postdlf, you are missing the point. No one is commenting on whether the subject deserves an article - if there are sources out there then there can be an article. What there cannot be is negative information on a living person that isn't properly referenced. That's why this was speedied - and quite properly so. But there's no objection to a recreation, providing it meets the highest standards of BLP. And no, we don't undelete BLP violating material, even with a NOINDEX.--Scott Mac 15:40, 23 February 2014 (UTC)
The point is it wasn't unsourced. You didn't even notice one of the references mentioned in the article (a whole book just about the criminal trial) apparently because it was given in the body of the article, and you concededly did not consult the one you did notice that was under a "references" header because you thought it too difficult to look up (in a print encyclopedia, no less, which should have a fairly straightforward organization). The general fact of the subject's murder conviction is easily verifiable from the references given, and if individual details about the crimes proved too difficult to readily verify then those details could have been removed pending further research. It's unfortunate that this article, which is about an apparently notable subject and was actually pretty well written, was deleted without discussion four years ago and this was only now brought to light. WP:CSD#G10 is limited to negative articles that are "unsourced". This wasn't unsourced when it was deleted. As far as what BLP requires, as is consistent with policy at WP:PRESERVE, WP:BLPDEL says "Biographical material about a living individual that is not compliant with this policy should be improved and rectified; if this is not possible, then it should be removed." (emphasis added). And that's even just talking about removing bits of content from an article, not speedy deleting the whole thing. To the extent that the lack of inline citations was not BLP-compliant, this is and was easily fixable with the references given.

What's the best Wikiproject to notify to get interested editors at work on this? I'll restore it for their improvement once someone voices interest. postdlf (talk) 17:01, 23 February 2014 (UTC)

No you will not restore it, unless you want desysopped for wheel warring. There is no way in hell this is referenced adequately for a negative BLP. I'm not disputing it could be fixed, but we remove such material until it is fixed. We don't rely on eventualism for negative BLPs. I will userfy the article (blanked) and someone can rebuild it with all negative material properly referenced. I will do that as soon as someone indicates a willingness to do this. Until then it remains deleted.--Scott Mac 20:54, 23 February 2014 (UTC)
Scott, if an admin restores the article now they would not be wheel warring. Wheel warring is when an administrator's action is reversed by another admin, but rather than discussing the disagreement, administrator tools are then used in a combative fashion to undo or redo the action. It would only be wheel warring if an admin re-deleted it after it was restored. GB fan 00:02, 24 February 2014 (UTC)
Not with BLP. If content is removed by someone citing BLP concerns, you may not restore it without a consensus that it is safe to do so. Thus with a BLP deletion, you either need the deleting admin to agree or a DRV.--Scott Mac 10:25, 24 February 2014 (UTC)
I kindly suggest you re-read what I wrote again, and think about how your comment could improved to be more responsive to the whole of what I said, more substantive, and more constructive. Cheers, postdlf (talk) 21:46, 23 February 2014 (UTC)
I generally deny such passive aggressive requests, can't see a reason to vary that here.--Scott Mac 22:56, 23 February 2014 (UTC)
Having looked at it just now, it's pretty gruesome so you'd want sources. The article would make no sense if the most gruesome bit was removed as that is what it is (supposedly) notable for, so as far as being on wiki and publicly accessible, it is easiest to do from scratch, however there are several ways of sending the written material to someone to work on in the meantime. Cas Liber (talk · contribs) 23:10, 23 February 2014 (UTC)
PS: Yes, just looking now, I can see the book on google though not sure how extensive or limited the preview is...so let's frame this positively....we'll be most happy to make available the deleted page one way or the other once someone says they want to work on it and inline/rework the text. Cas Liber (talk · contribs) 23:14, 23 February 2014 (UTC)
THanks for reviewing. Yes, I've no problem with that. Not disputing an article can be written, and not trying to deny anyone access to the deleted content to create it. --Scott Mac 23:44, 23 February 2014 (UTC)

Sooo......ummmmm, anyone wanna work on the article then? If not now, there is a category of admins who will explore ways to make deleted content appropriately available. Cheers, Cas Liber (talk · contribs) 12:13, 24 February 2014 (UTC)

  • Setting aside the really unnecessary hyperbole of comparing this to the much more famous Richard Speck case, I'd definitely say the de Kaplany case is notable and verifiable enough for an article. In addition to being the focal subject of an entire book, the article mentions that the San Jose Mercury News tracked him down as recently as 2002, indicating enduring interest in the case after 40 years. The tricky bit is that most of the sources are going to be from the early 60s, and while tracking them down won't be a cakewalk I don't think it would be impossible. Andrew Lenahan - Starblind 04:08, 26 February 2014 (UTC)
I'd be happy to have a go at it. Looks interesting.--Auric talk 11:54, 26 February 2014 (UTC)
Okay - as Scott outlined above, I have restored, userfied and then blanked it - see User:Auric/Geza de Kaplany - I found one book on google straightaway so tat should allow you to get started quickly. You should be able to move it to mainspace yourself but let me know if there is a problem. Cas Liber (talk · contribs) 13:01, 26 February 2014 (UTC)
The article is live now. --Auric talk 13:36, 2 March 2014 (UTC)
Looks great, good work all around! Well done, Auric. Not everyday this kind of thing happens on the VP policy board, but the encyclopedia has a solid new article and is better for it. Andrew Lenahan - Starblind 17:26, 2 March 2014 (UTC)

RFC: Should "Conspiracy Theory" be listed as a contentious label?

https://en.wikipedia.org/wiki/Wikipedia_talk:Manual_of_Style/Words_to_watch#RfC:_Should_.22Conspiracy_Theory.22_be_listed_as_a_contentious_label.3F Stax68 (talk) 00:51, 3 March 2014 (UTC)

Question on OR and Synthesis as relates to sun hours

Is it either original research and/or synthesis to include the %possible sun if a meteorological agency only lists the total monthly sunshine duration and then one proceeds to use another reliable source to state the following: in Washington, D.C., for example, during March, the sun shines 55% of the time? Please {{Ping}} me with when you have a response. GotR Talk 03:47, 3 March 2014 (UTC)

Hi GotR, why don't you ask this at WP:NORN, which is were the people best versed in NOR hangout? WhatamIdoing (talk) 20:04, 4 March 2014 (UTC)

THIS MUST BE DISCLOSED. NO EXCEPTIONS — Preceding unsigned comment added by 98.15.143.172 (talk) 02:27, 5 March 2014 (UTC)

You tell 'em! .. Mr. Mysterious Anon IP.. -- Ϫ 07:44, 5 March 2014 (UTC)

RFC: Should we hide template and image deletion notices from users not logged in?

Closing under the snowball clause. It's obvious this will not happen. —DragonLordtalk/contribs 19:36, 6 March 2014 (UTC)

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

Moved from WP:VPT; one comment removed.

Images and templates currently undergoing a deletion proposal always have a notice similar to the following:

‹ The template below (<template name>) is being considered for deletion. See templates for discussion to help reach a consensus.›

Is it really necessary to involve users that are not logged in, most of which are not experienced with the Wikipedia deletion process, by displaying this notice to everyone? Can we hide this notice from users who are not logged in? —DragonLordtalk/contribs 20:01, 5 March 2014 (UTC)

  • Absolutely not. Non-logged-in users are not debarred from participating in XfDs, therefore must not have information about XfDs hidden from them. --Redrose64 (talk) 21:05, 5 March 2014 (UTC)
  • And why not allow new users the chance to become familiar with our more... peculiar internal working processes? It's a chance for a brand new user to sign up to vote for or against deletion of their favorite "whatever" page they want deleted/kept. And just speaking of which, that's one of things the Wikimedia Foundation was targeting, wasn't it? TeleComNasSprVen (talk • contribs) 10:27, 6 March 2014 (UTC)
  • Not a chance as this is one of the things that may cause them to become contributors in many other topics or areas as well. Seeing something that interested you is going to be deleted, inspires emotion, and emotion inspires action to prevent deletion, and positive action to improve articles prevents deletion, and this chain of events inspires pride and sense of self accomplishment, and this sense of pride and confidence that they can make a difference encourages application of the same techniques to improve other articles or create new ones, and the project grows... Everyone should see the product of these templates. I will say that based on my current observations, although there is a net good from this flow right now, I think the ratio of people that try and improve articles based on these templates could be better if we made some adjustments to some of the wordings... However, that was not the question posed here, so I'll save that discussion for another day. — {{U|Technical 13}} (t • e • c) 11:46, 6 March 2014 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Primary usage for works with derivatives

Suppose you have a work, Foo, that has spawned one or more derivative works. Assume that the title "Foo" is unique enough that all significant occurrences refer to the original work or derivatives thereof. What belongs at the article "Foo": the original work, the disambiguation page, or perhaps the most famous derivative work?

A related question occurs when there are a cluster of similarly-titled works, e.g. the original work was entitled "The Adventures of Foo: A Novel", but is more commonly known as just "Foo". Other complications include when the work is part of a series or franchise with the same title, or when the work's title is also the name of a character or entity within the work.

Here are some examples I have collected. Note that in most of these examples the original work is written and the derivative work is a film, but this need not always be the case.

Examples where "Foo" contains the original work:

Examples where "Foo" contains a disambiguation page:

Examples where "Foo" contains a derivative work instead of the original:

Other interesting examples:

  • 2001: A Space Odyssey - article is about the concept (interestingly enough, the film and novel were produced in parallel so there is no single original work)
  • Mary Poppins - article is about the eponymous character, not any particular work
  • King Kong - article is about the monster, not the original film
  • Shrek - article is about the film, not the original novel Shrek!, with a separate article about the franchise
  • Star Trek - article is about the franchise, not the original series
  • Star Wars - article is about the franchise, not the original film (which has since been retitled)
  • Titanic - redirects to "RMS Titanic", the passenger liner about which several works with the title Titanic have been produced

This is somewhat covered by WP:PRIMARYUSAGE but I think a more specific guideline might be helpful, as this question seem to come up pretty regularly. The general policy is often difficult to apply because users have differing opinions about which work is the most well-known or significant and this often changes over time, for example a book that was once extremely popular might be now almost unknown, while a film adaptation may have become hugely popular. Thoughts? Augurar (talk) 02:18, 22 February 2014 (UTC)

Every decision here can be justified, except one (the omission of an article for the book Fast Times at Ridgemont High. ) not only justified, they actually match what I would think of first most of the time, except that for some of the ones with a disam p. the film is by far the most notable to me, tho I know the book also., Obviously, people's individual experience will differ, and cultural knowledge and fashion will change, so there is no way of doing it right. , When popularity changes, so can our handling of the title.
But if I had to suggest a guide, I would say, that normally the original work is the primary title, unless the derivative is very much better known. For works about events (eg. Titanic, the RW event or whatever is always the primary) However, for popular media franchises in many forms, the franchise should be used when rational, because it can list all the manifestations. DGG ( talk ) 07:19, 22 February 2014 (UTC)
There are other options that are often overlooked in discussions over WP:PRIMARYUSAGE... one option is to Merge articles. Nothing says we have to have separate articles on each version of a work. There is always the option to combine our coverage into one single article that discusses all of the versions (the original work and its various derivatives)... each in its own section. Another, similar, option (good when a merged article would be overly long) is to create an "overview" article... this "overview" article would summarize the key information about all the various versions of the work (and essentially do double duty as a dab, taking the non-disambiguated title)... and would point readers to (disambiguated) articles on each of the various versions. Blueboar (talk) 15:19, 23 February 2014 (UTC)
I think that DGG and Blueboar both have excellent advice.
I only add that my first impulse on seeing this was to see whether you're involved in WP:ANIME, because that's the usual source of disputes (e.g., a few editors insisting that "original" works must be primary, even when they are barely known and the derivative is wildly popular [so that's what our readers expect to see] and extensively discussed by reliable sources). So while this advice is excellent, and while I agree with it, in practice it is unfortunately possible that you will not be able to apply it quite as widely as it deserves. WhatamIdoing (talk) 23:44, 24 February 2014 (UTC)
I also agree in general with what Blueboar and DGG said above. One caveat: it sometimes happens that a relatively obscure real event becomes the basis of a well-known literary work. Usually the natural article titles will differ in such a case, but if they do not, the literary work might be the primary topic if the actual event is known largely through the work. DES (talk) 01:52, 25 February 2014 (UTC)
Hmm. I'm getting a sense from the responses so far that the preferred page is the "most well-known" work, even if that is a derivative. The context I was thinking of is generally books turned into films (with "One Flew Over the Cuckoo's Nest" as the example that inspired this post), although I'm not surprised it comes up in comics/animated films as well.
I tend to think the original work should be the default, as otherwise this seems to make Wikipedia too dependent on popular culture. As an example, take some obscure element, say Osmium. Now suppose some pop band is started with that name and becomes all the rage. Is there a level of popularity at which "Osmium" should refer to the band instead of the element? I would argue that the element should always be the primary article, even if the average reader (and editor) will be much more likely to have heard of the band than the element.
As another example, I refer you to this xkcd comic. Note that this is slightly out of date, as younger generations are less likely to be familiar with the Ninja Turtles than the author of xkcd -- this illustrates the danger of, say, putting the Ninja Turtle character as the primary article for "Donatello".
Anyway, I think the observed policy on existing articles does not seem to be as clear-cut as "choose the most popular work". For example, more people are probably familiar with some film version of Frankenstein, yet the book is the primary article. In fact, just going by "brand recognition", the primary article would be Frankenstein's monster. Same with Aladdin, where the primary meaning in popular culture is the Disney film or character, rather than the folk tale. And I didn't even know The Phantom of the Opera started as a novel, yet that is the primary article. However, in all of these cases, I would argue that the current primary article is the more 'fundamental' meaning of the title even if it is less familiar to me personally. Film adaptations may come and go, but there will only ever be one original work.Augurar (talk) 07:12, 27 February 2014 (UTC)
You have to consider what the reader is looking for per WP:PRIMARYTOPIC. It's unkind to the readers to say, "I know that 90% of you really want to end up at this derivative. But, ha! I say that your search must take you to the page for the original instead!"
You must also consider what high-quality secondary sources discuss. Chemical elements will never be overtaken by pop culture because of that—Osmium has been mentioned in two centuries' worth of chemistry textbooks, reference works, and research papers—but in literary works, it's possible that any given version could be the one most discussed by sources. After all, basically everything literary is pop culture at some level (just for differing values of "popular" and "culture": Bleak House was definitely pop culture for its culture, even if it's serious literature for us). It's okay if the "right answer" changes over time. We're not trying to set up an immutable answer. WhatamIdoing (talk) 16:44, 27 February 2014 (UTC)
I assume you mean soul's Osmium (album)..... NewsAndEventsGuy (talk) 16:59, 27 February 2014 (UTC)

There are no absolute rules to use simply by knowing the history of the word. For example, the page Java was, for some time, a redirect to Java (programming language). However, I doubt that anyone would be likely to think it should be a redirect to Java coffee, which is the source of the name "Java" for the language. עוד מישהו Od Mishehu 18:09, 27 February 2014 (UTC)

There's a difference here though. The Java programming language wasn't an adaptation of Java coffee. Derivative works share the same name in reference to an earlier work. Augurar (talk) 04:24, 28 February 2014 (UTC)
That's a good point, and helps clarify some of the counterexamples I gave to the "most popular right now" guideline. Augurar (talk) 04:24, 28 February 2014 (UTC)

I support a two-step inquiry for these kinds of splits. If there is no single version that is clearly the most prominent, then the base page name should go to the original work, and the article on the original work should discuss the adaptations. The Adventures of Tom Sawyer is an example of this. If there is an adaptation that clearly supersedes the original, and all other adaptations sharing the same title, then the base page name should go to that adaptation. The Godfather is an example of this. Finally, if the original work is relatively obscure, and multiple adaptations that are better known, but none stands out against the others, then there should be an article on the franchise. An example of this is Jurassic Park. There should never be a disambiguation page at the base page name if the only meanings of a term are for an original work and its own adaptations, as these are not unrelated concepts. bd2412 T 15:34, 7 March 2014 (UTC)

Consider changing the thinking of Wikipedia. Wikipedia is not the NSA spy agency.

The culture of WP should be liberal, open, and transparent. Instead, it has developed into a secret policy, spy agency, and lack of privacy. The checkusers are spies that can spy on anyone they want. The whole of WP should end this. Wikipedia is not a vote. If there is a disagreement on editing, there should be compromises. Maybe even a wise committee of administrators who can settle disputes might be the key.

Instead, people try to block others by calling them socks. They try to "prove" that the person is a sock. If there is no voting, the concept of socks doesn't matter. Remember, wikipedia is not a vote.

Proposal: Get away from spying, get away from socks and checkusers.

ComingBackAgain (talk) 01:51, 5 March 2014 (UTC) Note: I am in the United States, State of Texas.

Facepalm Facepalm — The Hand That Feeds You:Bite 16:07, 5 March 2014 (UTC)
(expletive deleted) DonIago (talk) 16:53, 5 March 2014 (UTC)
A wise committee. Now, I wonder who else they'd choose... Peridon (talk) 19:57, 5 March 2014 (UTC)
But who monitors the wise committee to ensure that they don't do anything bad? And who monitor the monitors. And who monitors the monitors who monitor the monitors? (Repeat ad nauseatum). Wikipedia isn't a vote as far as I can tell, and there are already mechanisms in place to resolve disputes through discussion and compromise. Socks are typically people who have been blocked in the first place, and are trying to evade the block in order to cause more disruption. Bjelleklang - talk 14:18, 6 March 2014 (UTC)
"Maybe even a wise committee of administrators who can settle disputes might be the key.": I don't know about the wise part, but there is WP:ARBCOM, WP:MEDCOM. Second Quantization (talk) 15:01, 8 March 2014 (UTC)

File:1930 John Nicholson Barran.jpg

Not sure if I should post it here, but could somebody take a look at this discussion and help a bit? It shall be appreciated.--The Theosophist (talk) 15:56, 7 March 2014 (UTC)

"Nominated for a Nobel Peace Prize"

Many biographical articles emphasize "nominated for a Nobel Peace Prize" as a major career achievement when in reality it doesn't mean anything. Any college professor can nominate anyone and then make an announcement; the prize committee does not acknowledge it and does not publicize the actual short list for 50 years.

Should there be a policy on this? It seems like undue weight bait. - Richfife (talk) 18:09, 5 March 2014 (UTC)

I agree that being nominated for a Nobel can be irrelevant. The problem is that nominations are covered by the press, and here it seems that press coverage equals relevancy, which I disagree with. --NaBUru38 (talk) 18:17, 5 March 2014 (UTC)
Does it really mean nothing? How does one become "nominated"? NewsAndEventsGuy (talk) 18:31, 5 March 2014 (UTC)
At minimum, a university professor sends a letter to the prize committee saying "I nominate so and so". That's it. They could be a community college professor. Seriously. - Richfife (talk) 19:36, 5 March 2014 (UTC)
Thanks for posting that link, which definitively answers the question, I think. See below. NewsAndEventsGuy (talk) 19:51, 5 March 2014 (UTC)

Support

Given that the Nobel committee explicitly requires people to shut up about nominations for 50 years
"The statutes of the Nobel Foundation restrict disclosure of information about the nominations, whether publicly or privately, for 50 years. The restriction concerns the nominees and nominators, as well as investigations and opinions related to the award of a prize."
combined with the low bar for nomination, saying so-and-so was nominated (A) violates the Nobel Committee's rules and (B) lacks WP:WEIGHT, and this is true whether or not RSs toot this particular horn or not. Seems reasonable to add something, including the nobel link above, to both our standards for establishing notability in general (specifically at Wikipedia:Notability_(people)#Any_biography) as well as our policy on how to actually present a biography once notability has been established, e.g., somewhere in WP:BLPNewsAndEventsGuy (talk) 19:51, 5 March 2014 (UTC)
To clarify, I think that a properly sourced nomination from a notable person or organization does deserve notice. But if the nominator is unnamed or non-notable (and they almost always are), then we should assume the worst and avoid mentioning it at all. - Richfife (talk) 20:14, 5 March 2014 (UTC)
I think that it should almost always be omitted unless the Nobel archives confirm it (i.e., it was more than 50 years ago). If it is included before then, then it should specify the name of the person who claims to have made the nomination and an explanation of what that nomination entails or how many other people were nominated (usually a couple hundred different people each year for the peace prize alone), to help the reader put it in context. WhatamIdoing (talk) 21:16, 5 March 2014 (UTC)
My Plan A is to say we shut up unless it is over 50 years ago, because the Nobel folks said those are the rules. Alternatively, I agree with WhatamIdoing. NewsAndEventsGuy (talk) 21:25, 5 March 2014 (UTC)
I agree in general, but the Nobel committee's rules aren't Wikipedia's rules, so we shouldn't worry about breaking them. - Richfife (talk) 21:47, 5 March 2014 (UTC)
Agree with the idea we shouldn't say anything else it is directly out of the mouth of the Nobel committee. --MASEM (t) 21:50, 5 March 2014 (UTC)
Agree, it's up there with "tried out for" a major league sports team, or a mention in some pay-to-get-in who's who directory. It means nothing.--agr (talk) 16:26, 6 March 2014 (UTC)

I gently disagree with some points. First of all, a nomination for the Peace Prize takes a government official's nomination as well as a professor in the humanities. Secondly, being nominated is notable when it becomes documented in public.

I think nomination is NOT adequately notable for creating a Wikipedia article. But if a person is already notable for other reasons, and then is also nominated, then the nomination can legitimately be cited in a Wikipeida article. Pete unseth (talk) 18:06, 6 March 2014 (UTC)

Here is the exact text (emphasis mine):
According to the statutes of the Nobel Foundation, a nomination is considered valid if it is submitted by a person who falls within one of the following categories:
Members of national assemblies and governments of states
Members of international courts
University rectors; professors of social sciences, history, philosophy, law and theology; directors of peace research institutes and foreign policy institutes
Persons who have been awarded the Nobel Peace Prize
Board members of organizations that have been awarded the Nobel Peace Prize
Active and former members of the Norwegian Nobel Committee; (proposals by members of the Committee to be submitted no later than at the first meeting of the Committee after February 1)
Former advisers to the Norwegian Nobel Committee )
This statement: nomination for the Peace Prize takes a government official's nomination as well as a professor in the humanities is patently not true - Richfife (talk) 18:28, 6 March 2014 (UTC)
I was wrong about the details for who is needed for a nomination, I apologize. But I still gently contend that a documented nomination can be mentioned in an article about a person who is already considered notable.Pete unseth (talk) 13:15, 8 March 2014 (UTC)

Let's put an example: Pope Francis has been nominated by the Argentine Congress, which is clearly not the same than a mere professor. Perhaps we can decide on a case-by-case basis, according to who made the nomination? Cambalachero (talk) 13:30, 8 March 2014 (UTC)

That puts undue weight on the fact that the nomination was made by a gov't body than anyone else. Yes, to be recognized by ones gov't for that is definitely not just a minor thing, but again, the effort to nominate is also not a difficult barrier. It is better to go by the list the Nobel committee produces to actually know who is on the short list in their decision- even if that means we're waiting 50 years. --MASEM (t) 14:38, 8 March 2014 (UTC)
Cambalachero, it is not possible for anyone to know who nominated a person. "The Argentine Congress" is not permitted to nominate anyone. Only individual members of the Argentine National Congress may do so—and there is no way for anyone to verify that any of them actually did. We (or our sources) could accurately report that Politician Joe claims to have nominated someone, but there is no way to find out whether this statement is true, or if it's just another lie told by a politician. WhatamIdoing (talk) 17:24, 8 March 2014 (UTC)
  • As already noted, it generally fails verifiability due to the 50 years rule. There is no clear way we can determine who was nominated. We know this. If a newspaper says someone was nominated, then this leads to inherent questions on their reliability. Combined with the low bar for nomination, it is not a significant achievement at all, Second Quantization (talk) 14:50, 8 March 2014 (UTC)

RfC: Does COMMONNAME apply to grammatical forms?

Does, or should, WP:COMMONNAME apply to differing grammatical forms, such as plural vs singular? Please take part in the discussion at Wikipedia talk:Article titles#RfC: Does COMMONNAME apply to grammatical forms?. Curly Turkey (gobble) 23:34, 9 March 2014 (UTC)

Admins protecting their personal pages

Why is it not a violation of policy that admins are allowed to restrict access to their talk pages? I regular editor can't do this so admins should not be allowed to either. If a page needs to be protected they should ask just like anyone else. Too many admins on here restrict access to their talk pages for no other reason than because they can and this seems like a borderline abuse of the admin tools. 172.56.3.58 (talk) 18:47, 9 March 2014 (UTC)

I don't know if user talk pages count but admins are permitted to protect their user pages. That said, I do think admins should have their talk pages available for comment if needed, but I would assume good faith that they might have good reasons for doing so. If you believe someone is protecting their talk page without a good reason and can demonstrate that, it could be dealt with on a case by case basis. 331dot (talk) 18:54, 9 March 2014 (UTC)
It's okay for admins to temporarily semi-protect their user talk pages if an IP-hopper or socker keeps posting there. What cases specifically are you referring to? Jackmcbarn (talk) 18:56, 9 March 2014 (UTC)
I can't point to any one in particular but it seems like a large number of the admins pages are at least Semi protected so an IP couldn't leave a comment if they had a question or needed something. I tried to leave a comment on 6 and finally just gave up. 172.56.3.58 (talk) 18:57, 9 March 2014 (UTC)
Worth noting that nobody cares. Either way, he makes a valid point. KonveyorBelt 17:09, 11 March 2014 (UTC)
More like gaming then valid, because as noted, page postings by banned user may cause page protection. Alanscottwalker (talk) 17:28, 11 March 2014 (UTC)
  • To be honest, I don't agree that an admin should protect their own talk page. Their talk pages should be "more" accessible, not less. If they're getting abused on their talk page (it's almost part of the official admin job description to take at least "some" slack), then it is more appropriate to block the offender than it is to prevent all IPs and unconfirmed from posting on their talk page. As far as those that would say that this block is abuse of power, it wouldn't be hard for the admin to note the reason for this action (even if obvious) in a place such as AN or AN/I, as long as upon any resistance the block is undone immediately until discussion determines a consensus. If it happens to be an IP hopper and a small rangeblock won't fix it, then it should be discussed like any other request anyways... — {{U|Technical 13}} (t • e • c) 19:57, 9 March 2014 (UTC)
    • I strongly disagree. Last year I had some issues with an indian vandal, where he repeatedly kept adding a picture of some naked guy to my userpages, blanking or other types of vandalism. I'm not bothered personally, but for any other user approaching me with questions or in need of help, it'll look terribly un-adminlike and might even end up turning people away. Sure, admins should have thicker skin and be able to handle more abuse than the regular user but at certain times a semiprotect is a better way to handle repeated vandalism (as with any other WP page). As for requesting and discussing protection requests in order to have consensus, there is only one word. Idiocy. Adding yet another layer of bureaucracy is the last thing we need, _especially_ for basic stuff like this. Bjelleklang - talk 21:10, 9 March 2014 (UTC)
  • Admin talk pages should not be indefinitely semi-protected; and aren't. Temporary semi-protection to deal with socks of banned users aiming to cause disruption is entirely reasonable. --Demiurge1000 (talk) 20:08, 9 March 2014 (UTC)
    • No, the kind of abuse that I and many others get is absolutely not "part of the job description", and I personally very much resent the implication that it is. Please have a look at the page history here to see what happens on projects where they apparently make it a point to not protect such pages as a matter of principle. The number of vandal edits on this one page there – and this is only what a single disturbed individual will do! – must go into the tens of thousands by now, and it's continued like that for years. I have my talk page indef-semiprotected because of that same deranged individual (plus several others who've also been a pest in the past), and I will absolutely not, ever, allow it to be unprotected again. And, frankly, I don't give a damn about what you or others think about it. Fut.Perf. ☼ 20:11, 9 March 2014 (UTC)
@172.56.3.58: we need names. Without those we have no hope of finding out who protected the talk page, for how long, or why. But with names (you state "I tried to leave a comment on 6" - which six?) we can at least look in the protection log. --Redrose64 (talk) 20:22, 9 March 2014 (UTC)
Why do we need names from a banned User - editing from a banned user would be a sound reason for protection. Alanscottwalker (talk) 20:29, 9 March 2014 (UTC)
There won't be very many. Category:Wikipedia protected user and user talk pages lists 214 pages, and exactly one (this redirect) took me to an admin's talk page. Most of them were blocked users, many were subpages or user pages (maybe we need a Category:Wikipedia protected user pages of blocked users to match Category:Wikipedia protected talk pages of blocked users‎?)‎, and a few were deceased editors. The cat is presumably incomplete, and some enterprising person might like to check the complete list, but long-term semi appears to unusual for most admins. WhatamIdoing (talk) 21:22, 9 March 2014 (UTC)
Looks like there are about 20 admin User talk: pages (including Jimmy Wales') that are currently semi-protected. VanIsaacWScont 06:53, 10 March 2014 (UTC)
Jimmy Wales I can understand, since some people are in the habit of using his talk page as a general noticeboard/complaints desk. But if there are just 20 in total, and there are 48,298,361 users851 admins, that makes the chances of picking a user talk page at random and finding that it's semi-prot less than one in a millionseventy. For 172.56.3.58 to pick six user talk pages and find that all of them were semi-prot is 1 in 10361011 - a vanishingly small chance. That's why I'd like to know who those six are. --Redrose64 (talk) 14:13, 10 March 2014 (UTC)
There are several hundred semi-protected user talk pages, most of them being of blocked users. About 20 of them belong to admins. VanIsaacWScont 14:20, 10 March 2014 (UTC)
For 172.56.3.58 to pick six user talk pages and find that all of them were semi-prot is 1 in 1036 - a vanishingly small chance. Not necessarily, if you consider that some of those pages have been semied because of him... That's why I'd like to know who those six are. Mine is one of those. Salvio Let's talk about it! 14:44, 10 March 2014 (UTC)

Program notes (in concert)

Are program notes considered to be reliable sources, and if so, how should they be cited? Cloudchased (talk) 02:12, 10 March 2014 (UTC)

I guess a preliminary question is: is it for the orchestra or the music pieces or the artists? Chris857 (talk) 02:17, 10 March 2014 (UTC)
Pieces and artists. Cloudchased (talk) 02:37, 10 March 2014 (UTC)
Of course they're reliable sources... for some purposes. Just about anything published is reliable for some purpose (see the FAQ at the top of WT:V).
You should treat that sort of source the same way you would treat exactly the same words appearing on the orchestra's website: self-published, potentially self-promotional, perhaps primary (but NB that WP:Secondary does not mean independent), and probably as accurate as the newspaper article reviewing the first performance (because the journalist is probably not going to bother double-checking the facts from the program). If you could cite a better source, like a book from a respected publishing house or article from a scholarly journal about music, then that would be ideal, but this is not prohibited as a source. If you have questions about exactly what statements can be safely supported, then try asking at WP:RSN. WhatamIdoing (talk) 21:16, 11 March 2014 (UTC)

Proposal that MOS should apply to portals

My proposal that MOS should apply to portals was recently removed by ClueBot, presumably because there had been no activity for a while, although there did not appear to be any formal "closure" of the proposal. I still feel strongly about the matter. :

  • What's the normal process for such proposals? Should there be a formal review and closure, with a definite outcome (possibly "no consensus")?
  • Can/should the proposal be resurrected from the archive with a view to establishing a definite outcome?

Mitch Ames (talk) 14:13, 10 March 2014 (UTC)

  • The normal process is that ClueBot archives any section without recent activity. Formal closures are usually avoided.
  • You are permitted to unarchive any section for further discussion. However, if you personally believe that the outcome is either "no consensus" or "against your proposal", then doing so is likely a waste of time. WhatamIdoing (talk) 21:18, 11 March 2014 (UTC)

Infobox image changing — a policy please!

Issue

Some editors upload new images of celebrities and BLPs and replace old images with some edit summary "new image looks better", "new image is most recent" or in the worst case just without any edit summary. Actually most of these editors try to display their own uploads at Wikipedi.

Affected area

This is a serious issue at WikiProject India (I do not know about other projects, I don't work there very much) celebrity articles. Being a BollywoodHungama files reviewer at Commons, I see it everyday.

Please establish a policy or guideline for this. Tito☸Dutta 20:40, 10 March 2014 (UTC)

Do you have a suggestion for what the policy should be? Jackmcbarn (talk) 21:16, 10 March 2014 (UTC)
I really don't see any new policy needed for this, as long as we're talking free images replacing free images. There's are already established guidelines to avoid edit warring over any part of an article. --MASEM (t) 21:30, 10 March 2014 (UTC)
Nicolas Sarkozy's this image was considered the best of the lot available as on 29 August 2009
  • Wikimedia Commons has something they call as Valued images which picks out an image that is best in a given category. It does have drawback such as that (a) the image might be outdated now as the person might look different currently or (b) the image had been the best from the then available lot and better ones are actually available now but have been uncontested or (c) the fact that Wikipedians don't trust Wikimedians even if they are mostly the same people here and there.
    A solution would be to have local consensus on individual article's talk pages to gauge which is the best for infobox. If the venue seems to fall short for sufficient discussion as not everyone would watch the pages, a small mini-project might be started on trial basis; like WP:INDIA can have a subpage to start their own different Valued Image contest. If successful the Valued Image concept can be taken to a bigger level to whole of enwiki. We anyways do have our own featured images evaluation which is independent of what happens at Commons so why not this as well. But before jumping into expanding into more mini-projects, think of something simpler if possible. (Try blocking some editors who constantly remove your favourite image. Just kidding!) §§Dharmadhyaksha§§ {T/C} 10:59, 11 March 2014 (UTC)
Oops! "Valued pictures" was actually shut down in December 2010 per Wikipedia:Miscellany for deletion/Wikipedia:Valued pictures (3d nomination). §§Dharmadhyaksha§§ {T/C} 11:06, 11 March 2014 (UTC)
What exactly is the problem? "People like to edit articles" is not normally considered an actual problem. WhatamIdoing (talk) 21:20, 11 March 2014 (UTC)
  • Nobody minds when an WP editor adds to or updates an article, but please let us forbid other content creators, such as phographers, from contributing to articles without getting the permission of an involved editor first. I mean, how can we trust photographers to know what is actually a better picture. Everything they do is inherently a conflict of interest. What they do is nothing but self-deluded self-promotion. Saffron Blaze (talk) 13:41, 14 March 2014 (UTC)
within the India space at least, it is not actually affecting any "content creators"- the "new and better" images are mostly snagged from supposedly free sites and simply uploaded.-- TRPoD aka The Red Pen of Doom 02:31, 16 March 2014 (UTC)
So the solution to an India problem is to generate a policy for the whole world? Saffron Blaze (talk) 04:27, 16 March 2014 (UTC)
  • The main post mentioned This is a serious issue at WikiProject India (I do not know about other projects, I don't work there very much). If any other WikiProject is not affected with this issue, we may go for the alternative. Tito☸Dutta 04:44, 16 March 2014 (UTC)

Discretionary sanctions review. Comments welcome on Draft v3

The Arbitration Committee has recently been conducting a review of the discretionary sanctions system. You may wish to comment on the newest (third) draft update to the system, which has just been posted to the review page. Comments are welcome on the review talk page. For the Arbitration Committee, AGK [•] 00:19, 16 March 2014 (UTC)

Discussion on Banning policy, specific to proxying needs your input

A discussion is now going on on the talk page of the Banning Policy specifically addressing proxy edits. A suggestion has been made to shorten the policy to specifically dis-allow proxy edits for banned users. Your input is kindly requested.  KoshVorlon. We are all Kosh   15:52, 18 March 2014 (UTC)

Should it be policy to limit our media publication articles to only 100 year old images because of NFCC?

This deletion discussion suggests that for publications (newspapers, magazines etc) we cannot use modern images of the current publication but should instead rely on old images that have fallen out of copyright. Such a result seems absurd since we are covering the modern publication in our artcles not [just] what they were 100 years ago. The publications do not look remotely the same as they did. Alanscottwalker (talk) 00:43, 14 March 2014 (UTC) Added "[just]" because of an objection below. No change in substance. Alanscottwalker (talk) 11:38, 14 March 2014 (UTC)

Aside from copyright, I see good reasons to use the title page or cover of the very first (or at least an early) issue, as it will always remain relevant, regardless of changes in the current appearance of a publication.
And if "we are covering the modern publication in our articles not what they were 100 years ago", this is a bug, not a feature. An article should cover the entire history of a journal or newspaper, not just the present. And I don't think it would be too difficult to find examples of journals or magazines that, albeit still extant, were most influential in their early years and where the article probably should give more weight to the history than a (comparatively speaking) less distinguished presence. --Hegvald (talk) 07:37, 14 March 2014 (UTC)
  • Also, it's not "100 years old". It's pre-1923, or PD for another reason. (Say, no copyright notice) — Crisco 1492 (talk) 07:42, 14 March 2014 (UTC)
  • What will remain relevant? The look? No. The title? The publisher? The publication address/location? No, not always. Not only are they not suitable for identifying the current publication, the proposed use misrepresents the current publication. Alanscottwalker (talk) 11:08, 14 March 2014 (UTC)
If showing the modern logo is genuinely vital, just find a suitable version of the cover and crop it to a {{PD-text}} image. If the font used constantly changes, then what's being demonstrated, anyway?
Of course, if there's a notable cover you want to discuss with sources, that's quite different. Adam Cuerden (talk) 10:32, 14 March 2014 (UTC)
  • Just look at the modern publications that we cover. In the ones that existed 100 years ago, we use the modern publication image because it encyclopedically covers the modern publication, despite the fact that there will always be old publication images that can be obtained from any library. Alanscottwalker (talk) 10:54, 14 March 2014 (UTC)
Not always; see The Railway Magazine - first published 1897, I recently received the March 2014 issue. --Redrose64 (talk) 13:41, 14 March 2014 (UTC)
The Atlantic (1857), Chicago Tribune (1847), Times of India (1838), Sydney Herald (1831), The Guardian (1821), etc. -- Alanscottwalker (talk) 16:47, 14 March 2014 (UTC)
And what ought to be on this list, but isn't, is Financial Times, which shows only a very early copy on white paper, and not the iconic pink salmon color from which its nickname is derived. A good encyclopedia article about The Grey Lady should show black and white images; a good encyclopedia article about The Pink Un should show a pink one. WhatamIdoing (talk) 18:27, 14 March 2014 (UTC)

Just a friendly reminder that we can always ask a magazine or other media outlet to release one of their covers as CC-BY-SA 3.0 (or even straight PD), or at least inform them that we have a fair-use basis, and ask them if there are any particular covers that they would have a problem with our using, thereby getting an effective waiver for those to which no objection is raised. bd2412 T 17:22, 14 March 2014 (UTC)

First, it rather strains credulity that modern publications - at least those in the developed world -- are unaware of Wikipedia and our articles about them, including the images used (some for several years) in them. Moreover, under NFCC, a license "free for use on Wikipedia" is not a valid license -- it must be a free license for everyone. The image being usable as "fair use" is probably quite enough to satisfy the rights holder, and protect their interest from other uses.
As it seems some above are avoiding the policy issue, it seems good to repeat it since this is the policy board. Under NFCC, the Pedia has generally allowed the image of the modern publication in their article for identification (as fair use) - primarily in the infobox. But now it is claimed that all publications, published before 1923 can be replaced, so all modern images must be deleted, where used for identification. (Please remember that for NFCC, it matters not whether a replacement image is available, but rather can an old one be made available.) Thus, it is not an issue of editorial discretion whether to use the modern or the old, we must, according to the NFCC deletion argument raised, use only the old (if we use any image at all), and delete the modern. The question thus is, is that the correct working of the NFCC policy? Alanscottwalker (talk) 14:44, 15 March 2014 (UTC)
While I can see this a result of the NFCC policy as currently written, I think this is an absurd misapplication of that policy and an attempt to toss out some more fair-use content that has a legitimate place on Wikipedia. Once upon a time there were many who were far too liberal with fair-use on Wikipedia (never as bad as YouTube, but it did get pretty bad) to the point of straining credibility, but in this case it may be going too far in the other direction.
This said, I think it wouldn't hurt anybody if a well written and reasonable request to one of these publications if they could produce a sample cover with the current masthead and cover design that represents their publication for use on Wikipedia under a free content license (aka something acceptable for use on Commons). You would be surprised at how many people are not aware of these issues in spite of possibly even using Wikipedia on a regular basis. I am glad that Wikipedia and its volunteers take copyright issues seriously, but not everybody has really thought of the issues involved. Considering the scope of Wikipedia, it wouldn't surprise me if such a request would get honored as well. Education on these issues of copyright is always something to strive for. --Robert Horning (talk) 02:19, 17 March 2014 (UTC)
Agree with your first paragraph but as to your second, am doubtful that a current publication would find it a good idea to release their masthead, etc. rights for commercial use by anyone, which is what free license requires. Alanscottwalker (talk) 02:47, 17 March 2014 (UTC)
I think, as a matter of policy, it is rather absurd that we wouldn't accept a release with respect to a magazine cover sufficient to allow its educational use in Wikipedia and mirrors thereof (i.e. something less than a Commons-worthy release). Such a release would amount to little more than a tacit acknowledgment of our fair use claim, and would explicitly protect us from any copyright claim with respect to the media at issue. It is worth noting that even if we reasonably believe that our use of an image constitutes fair use (or even that an image is uncopyrightable), this does not prevent a non-consenting copyright owner from filing a Digital Millennium Copyright Act takedown notice with Wikipedia, nor does it present that copyright owner from suing any downstream user, even if they ignore our use and only go after a downstream user. bd2412 T 04:15, 17 March 2014 (UTC)
Fear of DMCA takedown notices should never be a legitimate reason to make any sort of policy. Such notices can be filed by anybody for anything, even if there is no law (either statutory or case law) which suggests that the reasons for the notice are even valid or regardless of whether there is even a copyright claim possible by the person filing the request. I don't mind policy being very cautious with regards to fair-use images and bending backward in terms of keeping the scope of fair use images on the obvious side of the law, but we need to use some common sense. Regardless, the OTRS policies have no exception toward the acceptance of things like logos, mastheads, or magazine covers so I see no reason why this would be different.
One thing about "educational fair use": Don't even go there in terms of using that as rationale on any Wikimedia project (including Wikiversity... where it might possibly have a remote claim). We don't need it for any content being produced and it is so complex that it isn't worth the hassle. Educational fair use simply does not apply to Wikipedia at all. If a for-profit commercial publisher can't use the image for non-educational uses, we simply shouldn't be using it on Wikipedia either. --Robert Horning (talk) 17:19, 19 March 2014 (UTC)

RfC: I do not want to be bothered by editing bots any more

There is a clear consensus against making DPL bot, ReferenceBot and BracketBot opt-in only. (Snow close) Armbrust The Homunculus 09:50, 22 March 2014 (UTC)

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

Statement

Bots that constantly bother users about minor issues should be opt-in only. This includes:

  • DPL bot (especially curly bracket function)
  • Reference bot
  • Bracket bot for curly brackets
Reason

I spend enough time editing content, I do not want to be constantly bothered with what are essentially pointless both statements that have very little impact on the page overall. For example: I have failed to include a closed-bracket, of the non wiki-link kind. I have used incorrect formatting on the page number part of a reference. I have made a wikilink to a disambig page. These are essentially minor, inconsequential, and time-consuming edits that I am being pestered about.

What is next, a spelling-correct bot? A bot to inform me I have not used the correct date format? A bot that informs me I don't use the correctly recognised English variant? I am irritated about this and feel other users feel the same.

Consistency

In addition, many more important processes (eg RfCs, merge proposals) are not posted on my talk page. In addition, even Wikiproject data requires me, personally, to view a separate page (Article Alerts)

Lastly, Mass messages and even wikinewsletters are generally op-in. So why aren't these irritating bot messages?

Utility

These bots represent yet another bias of Wikipedia, the expectation that users will be logging on daily, and therefore able to fix these messages. If I choose to edit once every week or month, I may return with several messages from these bots. During the intervening period, these errors are likely to have been fixed by other users. In addition, this is not a very 'welcoming' return to Wikipedia, and may be one of the many factors that are contributing to Wikipedia's editing decline (a symptom of an overactive bureaucracy).

Sig

--LT910001 (talk) 01:34, 17 March 2014 (UTC)

Support/Oppose

  • Oppose Often Bracket bot catches issues where a user breaks a table or template and makes the resulting article a disaster. If you dislike these bots you can opt-out. An opt-in process would defeat the purpose and not help new users. Werieth (talk) 01:33, 17 March 2014 (UTC)
Yes, but what about the other bots, or bracket bot when it uses curly brackets? --LT910001 (talk) 01:35, 17 March 2014 (UTC)
These bots should already have an opt-out process in place. The notices from these bots impact not just editors (as RfCs,Merges,Article alerts, mass message do) but it impacts the readers as well. (Issues with references not appearing, breaking tables or templates, or issues with wiki links). Werieth (talk) 01:39, 17 March 2014 (UTC)
  • Oppose. Newer users are often not even aware of the havoc they may be causing, and experienced users should be experienced enough to know to opt out if they so choose (I don't so choose). If they bot messages are frequent enough to be disruptive, then maybe the real solution is to slow down and proofread your work. Curly Turkey (gobble) 02:00, 17 March 2014 (UTC)
  • Oppose If the bots are bugging you, most of the time, it's because you did something wrong. A lot of users find them helpful, but probably wouldn't be bothered to manually opt in. Jackmcbarn (talk) 02:00, 17 March 2014 (UTC)
  • What the hell is wrong with you? - The bots serve the very useful function of notifying editors when they make minor mistakes while editing. You have three choices: opt-out of bot notifications, stop constantly making the mistakes that trigger their behaviour, or be thankful for the bots who remind you when you forget to close a bracket or properly disambiguate. ☺ · Salvidrim! · ✉ 02:45, 17 March 2014 (UTC)
  • Oppose If you don't like being bothered, opt out. --Jayron32 04:49, 17 March 2014 (UTC)
  • Oppose- Don't like the bots? Opt out or, better yet, stop making mistakes that summon them. Reyk YO! 05:01, 17 March 2014 (UTC)
  • Oppose opt-in, but opting out should be "easier", or at least better advertised. See "Opinions" below. Mitch Ames (talk) 12:46, 17 March 2014 (UTC)
  • Oppose opt-in, also oppose opt-out. These people should be bugged and bothered when they create errors in articles that others will have to fix. Not only should there be no opt-in or opt-out, these users should get a notification daily (or at very least weekly) until the issue that they introduced into the article is fixed. — {{U|Technical 13}} (t • e • c) 13:02, 17 March 2014 (UTC)
  • Close as unnecessary. Posts by DPL bot (talk · contribs) headed "Disambiguation link notification for March 17" (or similar) include a link to opt-out instructions in the last paragraph. Posts by BracketBot (talk · contribs) headed "March 2014" (or similar) include a link to these opt-out instructions, also in the last paragraph. For posts by ReferenceBot (talk · contribs) headed "Reference Errors on 16 March" (or similar), there are no apparent opt-out instructions, but the infobox on the bot's user page states that it is exclusion-compliant, so you should be able to use {{bots|deny=ReferenceBot}}. --Redrose64 (talk) 14:37, 17 March 2014 (UTC)

Opinions

Can't you use Template:Bots to opt-out of any bot messages that you don't want? --Atethnekos (Discussion, Contributions) 01:38, 17 March 2014 (UTC)

I don't want me or other users to have to opt out in the first place. I am plugging leaks (so to speak) by dealing with whatever new bot has been developed. A better system would be for interested users to opt in. --LT910001 (talk) 01:50, 17 March 2014 (UTC)
Actually this appear to be more of a I break stuff so often I dont want to get bugged by bots reminding me and instead of fixing your behavior you want to stop the useful bots. Werieth (talk) 01:52, 17 March 2014 (UTC)
Making a minor spelling error (such as this , or failing to correctly direct a page to a non-disambig is not 'breaking stuff'. --LT910001 (talk) 02:00, 17 March 2014 (UTC)
Spelling bots will never be approved, and as for dab links, they cause problems. When referring to John Smith in an article which one is the reader supposed to guess that you meant when they are reading though on a topic that they are not familiar with? Werieth (talk) 02:03, 17 March 2014 (UTC)

Suggestion: I wasn't aware (until I read the above) that I could opt-out. Admittedly, I haven't looked for the ability to opt-out - I do get the occasional message from BracketBot but I'm happy for it to find my occasional error for me. Perhaps all bot messages should come with a small note, eg "You can opt out of some or all bot messages by putting {{Bots}} on your talk page." (A more sophisticated note would be "click here to opt out of notifications from this specific bot".) Mitch Ames (talk) 12:46, 17 March 2014 (UTC)

If you look at any of the bot's user pages they provide methods for opting out. Cluttering notices with that information can detract from the real issue and adds more text, we dont want the notes to be a tl;dr. Werieth (talk) 13:37, 17 March 2014 (UTC)

Just an observation. These bots may, in the long run, help prevent editors from "cluttering" the revision history with avoidable edits to correct minor mistakes just as brackets, but in the short-term they just add to the problem by making edits themselves. Still don't know why we're not given the option to simply hide bot edits in the revision history the way we can in recent changes. -- Ϫ 04:06, 18 March 2014 (UTC)

@OlEnglish: When you say "hide bot edits in the revision history", which revision history? I take it from "in the short-term they just add to the problem by making edits themselves" that you mean the revision history of the articles. With the exception of DPL bot, which adds and removes {{incoming links}} (a process that is largely independent of telling users that "when you edited Foo, you added a link pointing to the disambiguation page Bar"), none of the three bots in question edit articles, so the only revision histories that get "cluttered" are the user talk pages. Even I get hit myself, but I don't get angry with the bot - it's my own silly mistake for using <ref>{{sfn}}</ref> instead of <ref>{{harvnb}}</ref> (or a bare {{sfn}}). --Redrose64 (talk) 14:00, 18 March 2014 (UTC)
@Redrose64: Any page's revision history. If I'm looking for something in a page's history I don't want to have to wade through reams of bot edits to find it. How hard is it to just add a button to Hide bot edits?? -- Ϫ 03:57, 19 March 2014 (UTC)
@OlEnglish: it would require a new column to be added to the database. Right now the bot status is just recorded in the recent changes table, and not the revision table. Werieth (talk) 03:59, 19 March 2014 (UTC)
Take a look at this madness. More than half the page is unimportant clutter from bots. So is it technically a pain in the ass to add a new column to the database? -- Ϫ 04:02, 19 March 2014 (UTC)
Adding a new column is complex, and it would only work for edits that have been made within 30 days of when the feature is deployed. For older edits nothing can be done. In the example you linked those edits where primarily interwiki bots, which have been made obsolete via wikidata, which should reduce that clutter. Werieth (talk) 04:06, 19 March 2014 (UTC)
@OlEnglish: The page which you mention as "this madness", i.e. 778, has never been edited by any of the three bots which are the subject of this discussion. --Redrose64 (talk) 12:46, 19 March 2014 (UTC)
Yes I know I'm sorry I'm off-topic. I'll drop this now. -- Ϫ 12:48, 19 March 2014 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Articles carrying Refimprove tags established many years ago

Consider this article Object (philosophy) and the tag it carries at the top {{Refimprove|date=February 2007}} I'd like to cleanup these tags if enough revision has been made since the date on the tag, but occasionally someone immediately reverts my edit without comment. Is there a policy page I can refer to in my Edit summary to help explain why I am deleting the tag? - Bevo (talk) 22:05, 21 March 2014 (UTC)

Well, you could say that the reference problem has been fixed. However in the case of that article, I'm not sure the tag should be removed. So if you want to remove, adding more inline references should address the core problem. Then the tag could be removed. Vegaswikian (talk) 23:42, 21 March 2014 (UTC)
Is there a Wikipedia policy page that instructs us in this circumstance? - Bevo (talk) 03:55, 22 March 2014 (UTC)
Or just change the date on the tag. -- Ϫ 02:43, 22 March 2014 (UTC)
Wikipedia:Tagging pages for problems is an essay that seems to be fairly well regarded. It has a section on removing tags.[10] Thincat (talk) 10:16, 22 March 2014 (UTC)
Thanks! - Bevo (talk) 17:12, 22 March 2014 (UTC)
The "without comment" part of the reversion is problematic; the users doing that should be encouraged to at least use an edit summary for such reversions to better start the WP:BRD cycle. Anomie⚔ 13:18, 22 March 2014 (UTC)

An alternative to leaving the tag in place or updating the date is to remove content which is not supported, so that the content is brought into compliance with verifiability policies. I'm not a fan of this approach, but it is a valid one. --User:Ceyockey (talk to me) 13:37, 22 March 2014 (UTC)

The most important question is whether or not the tag is currently appropriate. And IMO a top level tag means that the article is unusually weak in that area. In the case, (for example) I think that the article has progressed enough to where it is currently only a "bit weak" in that area, and thus a top level tag is probably not warranted. North8000 (talk) 13:42, 22 March 2014 (UTC)
If you remove a tag that you think is inappropriate, and someone restores it, then I'd suggest just moving on. You could clean up a dozen inappropriately templated articles in the time that it takes to explain things to one user at one article. WhatamIdoing (talk) 23:11, 22 March 2014 (UTC)

citable

I would like to know if www.asia-pacific-connections.com/hakwon_franchises.html is a citable soruce.Kdammers (talk) 07:38, 22 March 2014 (UTC)

A better place to ask is Wikipedia:Reliable sources/Noticeboard--S Philbrick(Talk) 15:11, 22 March 2014 (UTC)

Proposal for revision of WP:IMPARTIAL

A handful of Wikipedians have participated in a discussion on whether and how to tweak the language in the policy statement on writing Wikipedia with an impartial tone. We would like to involve others in the discussion, so I am bringing the matter here for greater exposure.


Part of the Wikipedia policy on maintaining a neutral point of view currently states (my emphasis in green): 

Wikipedia describes disputes. Wikipedia does not engage in disputes. A neutral characterization of disputes requires presenting viewpoints with a consistently impartial tone; otherwise articles end up as partisan commentaries even while presenting all relevant points of view. Even where a topic is presented in terms of facts rather than opinions, inappropriate tone can be introduced through the way in which facts are selected, presented, or organized. Neutral articles are written with a tone that provides an unbiased, accurate, and proportionate representation of all positions included in the article.


The tone of Wikipedia articles should be impartial, neither endorsing nor rejecting a particular point of view. Try not to quote directly from participants engaged in a heated dispute; instead, summarize and present the arguments in an impartial tone.

There are two problems with the highlighted section.
First, some editors take these two lines to mean that no direct quotations may be used when describing controversies; and even with a more liberal reading of the passage, allowing that inclusion of quotations may occasionally be appropriate, the text of the policy does seem to imply that paraphrasing is always preferred over inclusion of direct quotations when describing controversies. (For a few examples of disagreements over application of the policy, see [11][12][13][14][15][16][17][18].) Yet there are many cases in which an actual quotation will best capture a speaker's or writer's intent with the least distortion. And there are times that editors are able to reach agreement on inclusion of a direct quote more readily than they can agree on using a paraphrased restatement, because the former is regarded as more 'objective' and less susceptible to bias and manipulation. In short, we shouldn't be avoiding or removing quotations needlessly when the quotations are clear and relatively succinct.

Second, the paragraph as currently written implies that editors should remove from descriptions of positions taken by participants on controversial matters any language that editors feel might be considered inflammatory. While there is wide agreement that quotations should not be cherry-picked to find the most outrageous statement that has been made on a topic, I don't think we should be enshrining at the policy level the practice of using a paraphrase in order to tone down what an editor feels is "especially incendiary language". Wikipedia should faithfully reflect its sources. A paraphrase should never be written so as to change the meaning of the original statement. There are times when a speaker/writer intends his or her statement to be polemical. In such situations, the best way to describe the message in a Wikipedia article may be with a direct quote, not a paraphrase, because communicating the precise language and the tone used in the statement can be essential to faithfully describing the person's position.
Everyone agrees that the policy statement should make it very clear that Wikipedia faithfully describes positions in controversies and does not take sides. Rewriting what someone has said with an intent of toning down the remarks conflicts with the goal of faithfully representing their position.


As I read it, one of the primary intents of the language in the section is to discourage the use of overly long quotations when a shorter rephrasing can convey the same information.[Note 1] So why not simply have the policy statement say that more explicitly?

Among several proposals in the recent discussion considering whether and how to revise the policy language are the following two possible revisions (for the statement highlighted above in green): 

The tone of Wikipedia articles should be impartial, neither endorsing nor rejecting a particular point of view. When describing controversies, be especially careful in the use of quotations. Avoid quoting extensively from any individual speaker or point of view, which might lend the impression that Wikipedia endorses a particular position. Careful paraphrasing may help maintain an impartial tone by allowing a position to be expressed in less space than a direct quotation would require; however, iconic, well-known, or particularly vivid quotes are often better left unparaphrased. Quotations should be representative of the author's or speaker's views and should never be used out of context so as to distort the original meaning.

or 

The tone of Wikipedia articles should be impartial, neither endorsing nor rejecting a particular point of view. When describing controversies, be especially careful in the use of quotations.

Other participants in the discussion have said the current language of the policy is fine as it is and should not be changed.

What do you think?
If you agree that the language should be revised, do you support one of the above proposals? Or do you have a different suggestion for a revision?

  1. ^ The text highlighted above was introduced in 2008 by a Wikipedian who at the time, commenting on the use of a quotation from a newspaper editorial, wrote that "Editorials do not have to use NPV language, but we at Wikipedia must do so WP:NPV. Therefore, we should not quote extensively, as this will 1) introduce POV language into the article, and 2) make it seem that wikipedia advocates the position of the person quoted. See WP:QUOTE".[1]
    At the time that that post was made, the WP:QUOTE essay said: "while quotations are an indispensable part of Wikipedia, try not to overuse them. Too many quotes take away from the encyclopedic feel of Wikipedia. Also, editors should avoid long quotations if they can keep them short. Long quotations not only add to the length of many articles that are already too long, but they also crowd the actual article and remove attention from other information" and "when editing an article, a contributor should try to avoid quotations when ... a summary of a quote would be better. This may be due to lack of importance, lengthy articles, etc. On lengthy articles, editors should strive to keep long quotations to a minimum, opting to paraphrase and work smaller portions of quotes into articles".[2])

Dezastru (talk) 23:01, 13 March 2014 (UTC)

I agree with your earlier statement "quotations should not be cherry-picked to find the most outrageous statement", but I'm concerned that "however, iconic, well-known, or particularly vivid quotes are often better left unparaphrased." may encourage it. I understand what you mean, but I'm thinking about how others will use it. Morphh (talk) 01:01, 14 March 2014 (UTC)
Morphh, are you saying that you believe the current text should be left as it is? Or do you feel some kind of revision may be in order (and if so, what would you propose)? Dezastru (talk) 14:56, 19 March 2014 (UTC)
Dezastru, I would probably strike "; however, iconic, well-known, or particularly vivid quotes are often better left unparaphrased" and then prefix the last sentence with "When used, quotations ...". So you're saying be careful and describing that paraphrasing can help maintain impartial tone. I think it could cause problems if we describe when you should use a quote, at least with this language. Also, you could probably strike "Careful paraphrasing..." as unnecessary - I think you can just say "Paraphrasing often allows". While I'm not sure how best to say it, I think the statement "Avoid quoting extensively from any individual speaker or point of view" might need to take into account quoting a person and their POV on their own BLP, where the reverse logic would apply. Morphh (talk) 18:10, 20 March 2014 (UTC)
Some form of statement acknowledging that maintaining a neutral tone does not mean that quotations that contain vivid images or that are strongly worded cannot be used needs to be incorporated into the policy. Otherwise, there will situations in which some editors will interpret the policy as saying that evocatively worded quotations should be excised, such as in the examples I linked to above. A couple of your other suggestions to tighten up the language seem reasonable:
The tone of Wikipedia articles should be impartial, neither endorsing nor rejecting a particular point of view. When describing controversies, be especially careful in the use of quotations. Avoid quoting extensively from any individual speaker or point of view, which might lend the impression that Wikipedia endorses a particular position. Paraphrasing may help maintain an impartial tone by allowing a position to be expressed in less space than a direct quotation would require; however, iconic, well-known, or particularly vivid quotes may be better left unparaphrased. When used, quotations should be representative of the author's or speaker's views and must never be used out of context so as to distort the original meaning.
Dezastru (talk) 22:18, 20 March 2014 (UTC)
I don't know, it seems to me that the second sentence (and the long standing meaning) will be in conflict with that statement, because anyone quoting controversial material will argue it's inclusion on the basis that it's well-known or vivid. Admittedly, in some situations, the best way to be impartial is to quote, but I worry such wording would become a defense for the primary situations that the policy originally intended to prevent. Morphh (talk) 03:20, 21 March 2014 (UTC)
(edit conflict) Disputes over what constitutes a quote that is sufficiently well-known or otherwise significant enough to be included will be settled the same way as any other content disputes, through discussion and consensus. The problem with the current policy wording is that it strongly implies disapproval of use of quotations in describing controversies without any indication that there are times that quotations are appropriate or even preferable. To my knowledge, there is no other policy-level statement that deals with use of quotations vs paraphrasing. The result is that in disagreements over whether to use quotations or to paraphrase, those favoring the use of a particular quotation will never be able to find support for their position in policy, and under the current language, the default will always be against the use of any quotations. Dezastru (talk) 13:01, 21 March 2014 (UTC)
I'm not sure I see much difference in the result between what is being proposed and just removing the policy altogether if there is little preference and we're just going to debate it like any other content. It's vague enough to be meaningless. It seems to me that we have a larger problem with the improper and over-use of quotes within heated disputes then the opposite, and it would seem a rare situation where someone would oppose including an iconic quotation that is impartial and presented neutrally. I tend to agree with the policy that paraphrasing is preferred in most of these cases, but as you point out, in some situations, when cautiously applied, quotations can be useful. I'm cautious in losing the spirit of the policy. Morphh (talk) 16:21, 24 March 2014 (UTC)
The difference is that what is being proposed makes it clear that quotations may be appropriate for inclusion but quoting at length from one side is discouraged. The existing language does not make these points clearly. And if the section were completely removed, it would be much easier for editors to load up articles with one-sided quotes. Consensus could override attempts to do so, but it would be harder to build that consensus because there would be no policy directly supporting the arguments. You say we have a larger problem with improper and excessive use of quotes than the opposite. I spend a lot of time (in fact, most of my time, I hate to say) editing articles that deal with controversial views, and I have not seen a large problem with improper and excessive use of quotes in heated debates, where substitution of quotations with paraphrased material has improved the articles in terms of NPOV goals. I suspect most editors aren't even aware of this particular part of the WP:NPOV policy that we are discussing, so I don't think the benefit of the existing language is as great as you seem to feel. Dezastru (talk) 17:08, 24 March 2014 (UTC)
Perhaps a better way to address it may be to reference a quote's prominence in reliable sources on the topic. Maybe something like:
Paraphrasing may can often help maintain an impartial tone by allowing and allow a position to be expressed concisely; although, a direct quotation for a topic that is prominent among reliable sources may be better left unparaphrased.
Morphh (talk) 12:54, 21 March 2014 (UTC)
"Prominent among reliable sources" is a bit too vague. I'm not quite sure what it means. Does it mean that a large proportion of sources on the topic need include or refer to the quote? Does it mean merely that several prominent reliable sources mention the quote? What if the quote is included in an article on the topic in the Encyclopedia Britannica (or some similarly authoritative reference) but in no other reliable source? Would that qualify as prominent among reliable sources? And what about topics for which there are only a handful of reliable sources? What if a topic could otherwise be sourced with cites of just one or a couple of reliable sources? Suppose a reliable source says, for example, that "MacMillan famously said, 'The winds of change are blowing through this continent.'"; ordinarily a single citation might suffice for such a statement. But "prominent among reliable sources" (sources being plural) implies that the sourcing requirement is now much higher, doesn't it? Is that the intent? It would be better to let the individual editors working through the usual process of consensus decide whether any particular quotation is appropriate for an article. "Iconic, well-known, or particularly vivid" covers all of these various situations without imposing additional burdens for sourcing. Dezastru (talk) 15:06, 23 March 2014 (UTC)
I generally like the first of the two possible revisions, but agree that the "iconic, well-known" sentence is problematic. "Particularly vivid" to me implies least NPOV. Also. I *like* the fact that a paraphrase can filter out additional biased statements. How about:
The tone of Wikipedia articles should be impartial, neither endorsing nor rejecting a particular point of view. When describing controversies, be especially careful in the use of quotations. It can be difficult to find a brief quotation that accurately summarizes one point of view, and quoting at length from any individual speaker or point of view might lend the impression that Wikipedia endorses that position. Careful paraphrasing often allows a position to be expressed more succinctly and with less tangential rhetoric. Quotations should be representative of the author's or speaker's views and must never be used out of context so as to distort the original meaning.
(Also note the should/must change, which is not so much my recommendation as a question: should both be changed to "must"?) 71.41.210.146 (talk) 11:06, 14 March 2014 (UTC)
71.41.210.146, I agree with the should-to-must change. I am not so sure about the other part. How about keeping a line mentioning 'iconic, well-known, or particularly vivid', but changing "are often" to "may be"? In other words: "however, iconic, well-known, or particularly vivid quotes may be better left unparaphrased". Dezastru (talk) 15:01, 19 March 2014 (UTC)

Procedural comment This is not how things are done. YOu sould have posted an invitation for people to join the discussion in the corresponding talk page, Wikipedia talk:Neutral point of view. Now the discussion is broken into two parts, making it fiddicult to keep track of arguments. I suggest to cut and paste this section to the place where it IMO belongs. Staszek Lem (talk) 20:10, 25 March 2014 (UTC)

RFC: Indefinitely blocked IP addresses

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

There exists no clear consensus on what, if anything, to do about indefinitely blocked IP addresses. I suggest further discussion (that is, not voting) is needed on why indefinite blocks of IP addresses are undesirable and what we should do about the several thousand IP addresses currently indefinitely blocked. It might be helpful to distinguish between open proxies and IP addresses blocked 'for cause' in such a discussion. HJ Mitchell | Penny for your thoughts? 01:56, 28 March 2014 (UTC)

Moved from Wikipedia:Village pump (technical)/Archive 123#Indefinitely blocked IP addresses

Hi, this RFC is meant to facilitate discussion as part of an ongoing cross-wiki trend of various discussions and discussion boards I've noticed recently opened concerning the issue of indefinitely blocked IP addresses. Specifically the purpose of RFC is twofold, namely:

  1. The unblocking of currently indefinitely blocked IP addresses at Special:BlockList.
  2. Deprecation of the {{Indefblockedip}} template and updating of several policy pages to prohibit future indefinite blocks, which are variously located at Wikipedia:Blocking policy#IP address blocks, Wikipedia:Blocking policy#Indefinite blocks and Wikipedia:Blocking IP addresses#Block lengths.

As I have explained elsewhere on other wikis, my reasons for doing so are thus:

  1. IP addresses should never be indefinitely blocked as they can change hands pretty quickly.
  2. In the event that any single IP address does need an indefinite block, the Meta Stewards have already undertaken the necessary measures to solve that issue.

Please add your comments to the discussion below. Thanks! TeleComNasSprVen (talk • contribs) 20:47, 2 February 2014 (UTC)

Support 1 (unblock existing indefed IPs)

  1. Per OP. NE Ent 21:05, 2 February 2014 (UTC)
  2. Partially, I think we should change from indefinite blocks to ~5 year blocks, all ip blocks that are currently indefinite should be changed to 4 years plus a random nubmer of days between 180 and 360, that way each ip gets released slowly and we aren't re flooded with a bunch of vandals on one day. CombatWombat42 (talk) 20:18, 21 February 2014 (UTC)
  3. The case for blocking an IP is sometimes not a thorough decision so indefinite is a mistake. In Wikipedia, indefinite really means infinite. Very rarely is an indefinite overturned. Probably less than 0.001% of the time, especially if more than a week has passed. ComingBackAgain (talk) 01:46, 5 March 2014 (UTC)
  4. There shouldn't be ANY indefinitely blocked IPs because they are dynamic - they all change eventually. I love CombatWombat42's idea.--Launchballer 08:10, 10 March 2014 (UTC)
  5. Even IP addresses do get reassigned over time. The block on all indefinitely blocked IP address should be at least changed to a block with a definite length. Epicgenius (talk) 11:56, 10 March 2014 (UTC)
  6. per CombatWombat42. Regards, Sun Creator(talk) 20:40, 10 March 2014 (UTC)
  7. My thoughts are with CombatWombat42. The stats shown in the discussion below show that most indef IP blocking stopped five years ago or so anyhow. The idea behind blocks is not to ban people, but to slow down and discourage those who would disrupt our processes. Given that IP addresses change hands and that people do in fact get bored we shouldn't use indef blocks on IP users. If it is being used to stop an open proxy one has to keep in mind the length of time that most of them are around. In my experience (though I have no numbers to back this up) most open proxies don't last particularly long. (Unrelated: Can we find a good way to non-disruptively unblock Tor as well?) Zell Faze (talk) 15:25, 11 March 2014 (UTC)
  8. I support the well-thought proposal by our resident battle-hardened marsupial. bd2412 T 17:12, 14 March 2014 (UTC)
  9. per ComingBackAgain. --Mysterytrey 00:46, 16 March 2014 (UTC)
  10. I don't think we should unblock them all immediately, but something like CombatWombat42's suggestion would work. Mr.Z-man 15:30, 27 March 2014 (UTC)

Oppose 1 (leave indefed IPs blocked)

  1. Some IPs are open proxies that have been stable for a very long time. Others are blocks designed to counter specific vandals, or hotbeds of vandals. A blanket unblock is not helpful. Lukeno94 (tell Luke off here) 21:06, 2 February 2014 (UTC)
  2. Oppose - they are indefinite, not infinite. Some are stable cases that simply should be shut down for a long time. No need to have to wait until the vandalism/abuse/whatever starts again from that address. It is easier to have a regular review of indefinite blocks than to have to block again and clean up the mess. --Dirk Beetstra T C 04:00, 3 February 2014 (UTC)
    User:Beetstra, when do those reviews happen? IP registrations are not permenent, they can switch users, ISP's and even countries at random. If you show me more than a handful of these blocks being reviewed ever, I will beleive you, but "they are indefinite, not infinite." does not seem true to me. CombatWombat42 (talk) 23:07, 26 March 2014 (UTC)
    I am not saying that it is being done, I say that it should be done. We should set up a mechanism for that. You are right that IPs are not infinite being used by the same user, but if I see editors pushing the same POV using the same IP for more than 5 years, then having to reblock that IP every 6 months is an action in futility (for a show of futility: block log of 142.227.243.2 - since 2005 regularly blocked, since 2008 blocked regularly for vandalism (school-kid like vandalism like diff in 2005, I blocked it for 3 years after a summation of previous blocks of about 3 years (and only vandalism edits of over three years as well in the time that it was unblocked - and the IP is still assigned to the Canadian Department of Education; RegDate: 1993-08-11; Updated: 2008-12-31; it looks like this IP is registered there for 21 years now! If the vandalism restarts in November, I would consider to block it for 6 years to come as the minimum, though maybe indef until it gets reassigned is better). Sure, there will be IPs that are indeffed and that have already be reassigned, but my counterargument is that this proposal also did not review on a substantial subset of indeffed IPs how many have been reassigned (within x time from the moment that they were blocked) - unless someone can show me that that number is really significant I still strongly oppose this proposal. This perennial proposal just floats on the unproven assumption that even ALL static IPs are being reassigned significantly fast. If anything, the block length should be longer than the time in which a large percentage of the IPs are reassigned, but just having a scheduled review of indef blocked IPs is better. I am sure that IPs have in the WhoIs an assigner ID, and it should be easy for a bot to a) source and record that assigner ID (e.g. (re)block with that in a parameter), b) check on an hourly (though more realistically, monthly or half-yearly) basis whether the assigner ID for the IP has changed, and c) unblock if the assigner ID has changed and other conditions are met. Indef them, have a bot check them regularly whether they were reassigned (and consider auto-unblock when conditions are met), manually check the others. --Dirk Beetstra T C 07:10, 27 March 2014 (UTC)
    I agree that if there were a way to force a review every so often that would be the optimal solution, but how many administrator noticeboards have backlogs now? What does adding another thing that will inevitibly have a backlog do? In a project that is supposed to be all about openess, we are potentallly keeping a number of editors silent out of lazyness, I'm personally not ok with that. CombatWombat42 (talk) 14:38, 27 March 2014 (UTC)
  3. Oppose I oppose because I would be happy to require a log in for all purposes other than talk pages.NewsAndEventsGuy (talk) 13:31, 3 February 2014 (UTC)
  4. Oppose. Just as one size doesn't fit all, there can be varying reasons for blocks. I'm fine with the idea that indeff blocks of IPs should be done cautiously, etc., but there can be circumstances when such blocks are helpful and appropriate. Review them, and unblock case-by-case on the merits, but not this proposal. --Tryptofish (talk) 19:28, 3 February 2014 (UTC)
  5. Oppose - most of these IPs were blocked for good reason (usually vandalism). As for the argument that IP addresses can change hands... If that occurs, the new owner of the IP can easily contact an admin, explain the situation and have the address unblocked. Deal with them on a case by case basis. Blueboar (talk) 19:52, 3 February 2014 (UTC)
    I think part of your argument is a good point except no admin is going to unlock an IP just because they say its a new user and most users wouldn't bother or know what to do. They would just give up and Wikipedia would be out an editor. 138.162.8.59 (talk) 19:59, 3 February 2014 (UTC)
  6. Oppose - we should unblock them gradually, at least a year after the beginning of the block of each. Unblocking them all at once will cause too big a rise in vandalism and sockpuppetry; and keeping IPs blocked with an indef and unblocking them later, as opposed to reducing te block length, will prevent the vandal from knowing when (s)he can vandalize from there again. עוד מישהו Od Mishehu 09:50, 4 February 2014 (UTC)
  7. Oppose Chris Troutman (talk) 20:54, 16 February 2014 (UTC)
  8. Oppose not a great deal to be gained by unblocking open proxies. Unblocking them at all is probably a bad idea, unblocking them all at once is a horrible idea. -- Bfigura (talk) 01:07, 22 February 2014 (UTC)
  9. Oppose - Absolutely awful idea. Many of these IP's will pick right back up where they left off, as the worst vandals we have. Leave matters as they are, per Blueboar. IP's can ask nicely to be unblocked if they change hands and don't want to register an account. Jusdafax 06:12, 22 February 2014 (UTC)
  10. Oppose Bad idea. Little to no benefit to the encyclopedia and plenty of risk. Andrew Lenahan - Starblind 15:02, 22 February 2014 (UTC)
  11. Oppose: If we have a ceiling block limit, then it might deter a lot of vandals, but there'll still be some that come back. As per Dirk Beetstra, they can always be unblocked. Supernerd11 :D Firemind ^_^ Pokedex 00:17, 24 February 2014 (UTC)
  12. Oppose. Reviewing them is helpful, mass unblocking them is not. Kaldari (talk) 01:46, 26 February 2014 (UTC)
  13. Oppose Per Blueboar and Tryptofish. No obvious gain from this proposal, and some obvious risks. Second Quantization (talk) 14:56, 8 March 2014 (UTC)
  14. Oppose When IPs are left blocked indefinitely, there is usually a good reason for it. I see no reason to add this needless layer of bureaucracy to a system that already works. By the way, many IP addresses stay fixed for extended periods of time, and it makes no sense to assume all IPs are dynamic.--Jasper Deng (talk) 06:26, 10 March 2014 (UTC)
    @Jasper Deng: But Meta stewards already take care of this by applying on open proxies global blocks which can often last for years at a time. Also, these blocks are periodically checked near the block expiry dates to see if they remain static or become dynamic, and their duration renewed/extended in the former case. Why would we not have the same system, which would also facilitate better checks on open proxy blocks? TeleComNasSprVen (talk • contribs) 09:28, 10 March 2014 (UTC)
    I see absolutely no reason, whatsoever, for the English Wikipedia to put the burden on Meta, nor for an unnecessary layer of bureaucracy to be added to a system that works well. Also, not all indefinite IP blocks are proxies that should be globally blocked - schools are another repeat local offender. My oppose is firm and is here to stay.--Jasper Deng (talk) 09:59, 10 March 2014 (UTC)
  15. Oppose Erinamukuta (talk), 16 March 2014 (UTC)
  16. Oppose. Most are indef for very good reasons. -- Ϫ 03:41, 18 March 2014 (UTC)
  17. Oppose Dealing with daily mindless nonsense is sufficiently difficult as is without further tying the hands of admins attempting to staunch the worst abuse. Johnuniq (talk) 02:25, 25 March 2014 (UTC)
  18. Oppose When IPs are indef'd, they're indef'd for a reasion. If it's not a good reason or another, good-faith user hops onto the IP and finds themselves blocked that's what unblock templates are for. - The Bushranger One ping only 22:29, 26 March 2014 (UTC)
    And how many new good faith users are willing/capible of asking for an unblock? They are both our most abusive and abused users.CombatWombat42 (talk) 23:09, 26 March 2014 (UTC)
    No. People keep repeating this, but it's total nonsense. There is no good reason for blocking an IP indefinitely. Even static IPs are eventually reassigned. An indef block shows either a poor understanding of how IP addresses work or laziness. Many of the indef school blocks have been in place since 2006, which means the students who caused the block are probably old enough to be teachers now. Mr.Z-man 15:54, 27 March 2014 (UTC)

Support 2 (stop creating new indefed IPs)

  1. Per OP. NE Ent 21:06, 2 February 2014 (UTC)
  2. But we do need to take some time in going through all the current blocks. Mr.Z-man 21:33, 2 February 2014 (UTC)
  3. Support, the longest block should be ~ the age of the encylopedia. When wikipedia started did you know what it was going to look like now? Do you know what it will look like in (12?) years? Indefinite blocks are unlikley to ever get reviewd and are too easy to put in place, making them very long forces a review every <very long> atleast.CombatWombat42 (talk) 20:20, 21 February 2014 (UTC)
  4. Support. Long blocks of years are sensible in exceptional cases but indefed makes no sense at all. Regards, Sun Creator(talk) 20:42, 10 March 2014 (UTC)
  5. Support per my comment on Proposal 1. Longest block length should be five years. We are trying to discourage people from disrupting our processes, nothing more. Zell Faze (talk) 15:26, 11 March 2014 (UTC)
  6. Support; when we block an IP, we are not blocking a person, but whatever range of people happen to edit from that IP, well-intended or not. An IP that yields persistent vandalism should get a max five years, which may well be enough time for ownership of the IP address itself to change hands. bd2412 T 17:15, 14 March 2014 (UTC)

Oppose 2 (stop creating new indefed IPs)

  1. Opposing for essentially the same reason I'm opposing proposal 1. Lukeno94 (tell Luke off here) 21:06, 2 February 2014 (UTC)
  2. Not sure how one would either oppose 1 and support 2, or support 1 and oppose 2 - but since I oppose 1, this is a good one to keep and to explain to the rare cases where the IP does get reassigned and an editor needs to get through what they have cab do to appeal. --Dirk Beetstra T C 04:02, 3 February 2014 (UTC)
    Well, one is about removing current indef-IP blocks and the other is about preventing future indef-IP blocks. I think Mr.Z-man has it about right, though we still need to hammer out the details for implementation of the review process. TeleComNasSprVen (talk • contribs) 07:02, 3 February 2014 (UTC)
  3. Oppose Same reason as under Oppose 1NewsAndEventsGuy (talk) 13:33, 3 February 2014 (UTC)
  4. Oppose. Given what I said in opposition to 1. --Tryptofish (talk) 19:29, 3 February 2014 (UTC)
  5. Oppose Chris Troutman (talk) 20:54, 16 February 2014 (UTC)
  6. Oppose Why make things harder on editors and easier on vandals? Andrew Lenahan - Starblind 15:05, 22 February 2014 (UTC)
  7. Oppose Per my opposition to 1. Come on, really? The majority of hardcore vandalism comes from IP's. Some of them will vandalize for years. Without the vital tool of indef blocking them, you create a situation where the cycle can repeat endlessly. This and the first proposal need to be rejected firmly as ideas that will eat up massive amounts of editor time with no benefit to the 'pedia. I reject the concept that we are discouraging new editors, because those who newly own an IP number can ask to have it unblocked or merely register an account. Jusdafax 20:25, 22 February 2014 (UTC)
  8. Oppose Same as above. Makes things easier for long term vandals etc. Second Quantization (talk) 14:57, 8 March 2014 (UTC)
  9. Oppose To quote Jusdafax, "This and the first proposal need to be rejected firmly as ideas that will eat up massive amounts of editor time with no benefit to the 'pedia." Dougweller (talk) 17:04, 8 March 2014 (UTC)
  10. Oppose There are many valid reasons for indefinite blocks of IP addresses. I also see this as needless bureaucracy.--Jasper Deng (talk) 06:27, 10 March 2014 (UTC)
  11. Oppose Why would this assist the encyclopedia? Is someone suggesting it would be helpful if open proxies and long term abusers could never be indeffed? Johnuniq (talk) 02:28, 25 March 2014 (UTC)
  12. Oppose As mentioned, indefs are handed out for a reason. If an IP is bad enough it needs an indef, tying administrators' hands on the issue only feeds the trolls. - The Bushranger One ping only 22:34, 26 March 2014 (UTC)

Discussion (indefed IPs)

Why do we need to have the RfC on this page? If my watchlist starts filling up, I shall unwatch. --Redrose64 (talk) 22:01, 2 February 2014 (UTC)

The Villiage Pump Policy would of been a far better location for an RFC than here, with a note left on technical to advise. This isn't really a technical RFC.Blethering Scot 22:14, 2 February 2014 (UTC)
Sorry, I thought unblocking IPs was mainly a technical matter up for discussion. You can move the discussion to VPP as appropriate but please don't forget to update the links at Wikipedia talk:Blocking IP addresses, Wikipedia talk:Blocking policy, Wikipedia talk:WikiProject on open proxies and Wikipedia:Administrators' noticeboard. TeleComNasSprVen (talk • contribs) 22:27, 2 February 2014 (UTC)
Done, I've moved it from Wikipedia:Village pump (technical)/Archive 123#Indefinitely blocked IP addresses to the policy section of the Village Pump. TeleComNasSprVen (talk • contribs) 02:52, 3 February 2014 (UTC)
Could someone make a quick-and-dirty table of block reason class for these IPs? Before I can have an informed opinion on the subject, I like to know what class of problematic behaviour we're talking about. Specifically proxies could have a bot-based solution that is better than indef blocking. Martijn Hoekstra (talk) 09:26, 27 February 2014 (UTC)
@Martijn Hoekstra: The list of indef-blocked IP addresses can be found at Special:BlockList. You can autogenerate this tabulated report from it through the specified parameters. TeleComNasSprVen (talk • contribs) 07:36, 28 February 2014 (UTC)
Well considering that this proposal seems unlikely to pass and I've just discovered Wikipedia talk:WikiProject on open proxies#Review of indeffed IPs, maybe this should be closed and referred to by that WikiProject instead... TeleComNasSprVen (talk • contribs) 07:36, 28 February 2014 (UTC)


What a binary and rhetorical discussion, without reference to the evidence. There are many indefinitely blocked IP addresses that are not problematic, and are no longer open proxies. There are many blocked IPs that were blocked on many wikis in the early days, and their removal at other wikis has not proved problematic. We now have global ability to block IP addresses, and if they are OPs, then they are blocked globally, or they are not problematic.

  • Example: Special:Block/82.129.167.171 blocked in 2005 as an open proxy. There is no evidence that this is an OP now, or has been for a long time. In fact research on the IP address shows that it is an IP at a University in Egypt.
  • Example: Special:Block/66.213.118.194 blocked in 2005 as an open proxy. There is no evidence that this is an OP now, or has been for a long time. IP assigned to Canton Ohio Public Library Information Network

You will see many IPs blocked in 2005 BlockList that with a little research are clearly not problematic at this point of time. So without clear rigor, and full cluefulness of the IPs and a review process this is simply a really bad idea. People above are arguing that this is a good practice.

Have an escalating/extending blocking process, is an excellent idea. But what is the evidence that we have that there are problematic IP addresses beyond five years? How many? Unless you have the evidence that we do have long term, and many long term problematic IPs, then this is truly a rubbish discussion. I would suggest that the reality would show that we have more complaints about people being innocently blocked by indefinitely blocked IPs, than we have repeat spam/problems from IPs that have been blocked for longer than five years. And if they are truly problematic then they should be globally blocked. — billinghurst sDrewth 10:36, 10 March 2014 (UTC)

I completely agree. Some statistics about the issue:
20556 - the number of indef-blocked IPs
20246 (98.5%) - the number with "proxy" or "proxies" in the block reason
65 - (0.3%) - schools blocked indef
57 - (0.3%) - blocked for sockpuppetry but not specifically indicated as an open proxy
35 - (0.2%) - blocked for vandalism with no indication of sockpuppetry, a school, or a proxy
27 - (0.1%) - blocked for spam (but not any above reasons)
14 - (0.07%) - web hosting services (mostly rangeblocks)
112 - (0.5%) - some other reason
So less than 2% of indef IP blocks are for reasons unrelated to open proxies, which means that the idea that being allowed to indef block IPs is saving a significant amount of time in preventing common vandalism is complete nonsense (for comparison, there are nearly 8000 non-indef school blocks). As for how long some of these have been blocked, grouped by the year of the block:
2004 - 112
2005 - 3305
2006 - 9833
2007 - 4284
2008 - 2793
2009 - 54
2010 - 37
2011 - 31
2012 - 39
2013 - 54
2014 - 14
So the practice of indef blocking IPs already nearly stopped 5 years ago and half of the existing ones are 8+ years old. Mr.Z-man 14:53, 10 March 2014 (UTC)

Proposal 3 (indefed IPs)

Last October, there was an RFC on reviewing Indefinite IP Blocks, the consensus was that we should review them regularly to make sure they were still needed. However that review required the input of advanced permission holders, Other then some more talk about it, as far as I know, nothing ever happened. As a middle ground, recognizing that some portion of the indefinite blocks are still needed, I propose that all existing IP blocks be reduced to 1 year from the end of the RFC. Going forward, they may be reviewed by holders of appropriate permissions, and after review, if still justified, periodically extended up to a maximum of 2 years duration. New blocks would be limited to a maximum of 2 years. This would give us time to review them, while at the same time, any forgotten blocks would start to release 1 year from now. Monty845 03:25, 3 February 2014 (UTC)

Note that that RFC applied specifically to rangeblocks. There are only 200 indef rangeblocks, there are 20,000 indef blocks of single IPs. Reviewing all of them annually isn't really practical. 90% are proxy blocks. ProcseeBot only blocks proxies it finds for 60 days to 1 year (what criteria it uses to determine block length isn't really clear). So it would probably be safe to downgrade all of the current proxy blocks to 1 year. Mr.Z-man 04:33, 3 February 2014 (UTC)
Just to note, that I think that having them automatically become unblocked and having vandals coming through them isn't really practical either. Actually, it might be what certain 'contributors' are waiting for (well, I know they are). --Dirk Beetstra T C 05:07, 3 February 2014 (UTC)
I think the answer to this RFC really boils down to one question, do we want to encourage editing to Wikipedia or do we not? If the answer to that question is yes, then we should review these blocks and eliminate some of them. Probably a lot of them because although there is a limited number of range blocks, some of them include a huge number of IP's and potential editors. Will some be vandals, almost certainly, but it will also advocate more helpful editors as well contributing to the site. Some are valid certainly but probably less than half are still valid. I also agree that an annual review isn't practical but some of these have been blocked for years and in that time the use of proxy servers as a security measure has been adopted as an industry best practice, a few years ago it would have earned you an indef. We also need to look at the validity to ProcseeBot IMO. I never liked the argument of blocking only because its a proxy, most of which have never even done one edit which means blocking it is both pointless and a waste of resources akin to creating a bot to move a stub tag. The use of ProcseeBot is an afront to AGF. So if you want to continue to foster the culture of exclusionism and elitism that has been increasingly visible in Wikipedia, then continue to leave all these blocked and perhaps even pursue forcing people to create an account like Facebook. If you want to encourage people to participate and collaborate to build an encyclopedia then we need to unblock as many as possible to encourage that. 138.162.8.59 (talk) 15:09, 3 February 2014 (UTC)
"the use of proxy servers as a security measure has been adopted as an industry best practice" - There is a difference between a proxy and an open proxy. Only open proxies, which can be used by anyone, are blocked. There is nothing wrong with blocking open proxies pre-emptively, as they are used almost exclusively for abuse. There are few legitimate reasons to be editing through an open proxy, and these are generally dealt with through IP block exemptions. Mr.Z-man 18:17, 3 February 2014 (UTC)
Your right there is a difference, but regardless of whether they are open or not, if they have never edited, there is no point in blocking thousands of them for no reason other than speculation that someone, someday might be a vandal. Certainly we could setup a filter or something so that these can be monitored more easily, even have a bot notify someone or a WikiProject, but just blocking tens of thousands of edits "preemptively" is frankly not a good practice and worse at least a borderline violation of Wikipedia policy. Its still a lack of AGF. Not that folks care about either policy or AGF these days. If they aren't vandals then the action isn't being done to protect the project. Its just laziness on the part of admins that don't want to do their work and would rather block everyone so no one can edit and eliminate the potential that a vandal might masquerade as an editor. The bottomline is its being done to prevent editing...good and bad and really not even then because most have never edited. You say there are few valid reasons....but you admit the reasons are there. Let me ask this even though I suspect no one even bothered to look, partially because I honestly don't know and partially as an extension of good faith to bot and its operator, how many have actually been used to vandalize and which ones were used to do meaningful edits? I looked at a few and the only one of the ones I found that had even done an exit was a vandal, several didn't add much value I grant you (minor typos and such) but it still helps incrementally. 138.162.8.59 (talk) 18:51, 3 February 2014 (UTC)
An open proxy does not represent a "person" like a residential IP. They are typically servers that no one would normally be editing from. Anyone editing via an open proxy is connecting to it from somewhere else, which means they can edit without it. AGF is not a suicide pact. We know from years of experience that open proxies are heavily abused by vandals, spammers, and sockpuppeteers, with very few good edits (because, again, there are very few reasons for legitimate users to use an open proxy). And we have procedures in place to help the few legitimate users. Note that just because you see no edits on the IP's contributions page doesn't mean they're not being used. That just means they aren't being used by unregistered users. The biggest problem with open proxies is not casual vandalism, but spammers and sockpuppeteers using open proxies with registered accounts. The time and effort spent dealing with a persistent abuser is much higher than with a regular vandal. Mr.Z-man 21:32, 3 February 2014 (UTC)
Ok, case in point, I tried to reply again and now I am getting a messagem because I am editing as an IP, stating A"n automated filter has identified this edit as potentially unconstructive, and it has been disallowed. If this edit is constructive, please report this error." There is absolutely nothing in the statement that was negative or a swear word so why should it be blocked? 138.162.8.59 (talk) 21:59, 3 February 2014 (UTC)
Oh I see it failed for common vandal phrases. Way to go Wikipedia, way to go!. I submitted it to Wikipedia:Edit filter/False positives/Reports but really, how many IP's are going to do that and how many are going to make sense of that crappy template? 138.162.8.59 (talk) 22:07, 3 February 2014 (UTC)
Based on what you tried to post, I suspect the phrase that tripped the filter was "Wikipedia sucks". I don't think automated filters can be smart enough to understand you were quoting a hypothetical person's reaction. I can't think of a way to improve on the filter without letting in a lot of vandalism. As for the message, I suspect it's deliberately vague so vandals don't get hints on how to avoid the filter. See what the guys who work on the edit filters have to say, anyway; they will know better than me. – PartTimeGnome (talk | contribs) 22:24, 3 February 2014 (UTC)
Your probably right, in addition to the fact that I am an IP that is. Which only validates my point that Wikipedia, regardless of their bantor that they want to allow it, really doesn't want IP's to edit. I recently tried to add a citation and it required me to put in a captcha 3 times. I finally gave up and just posted the info without the citation...its still there....no citation. Not because I didn't have it or want to put it in, because Wikipedia's filtering and mecahnisms prevented me from doing it. 138.162.8.59 (talk) 22:31, 3 February 2014 (UTC)
In general, I think I would support laxing restrictions to encourage chances for possibly constructive editors to join us as more important than holding back vandalism like "you suck", especially considering how high the vetting process is for AbuseFilter managers. Besides we got a lot of RC patrollers and Twinkle users and random bots running amok doing that anyway, and it's not like they won't appreciate more chances for adminship worry about rolling back Vandalism™ to our website with less AF restrictions. TeleComNasSprVen (talk • contribs) 00:52, 4 February 2014 (UTC)
I would point out that many of these features exist not to pointlessly harass anonymous editors, but so that we can still allow anonymous editing. Imagine if the #6 website in the world allowed anyone to edit any page, but made almost no attempt at preventing spam? We basically have 3 options:
  1. Require registration to edit. This would drastically reduce the amount of spam and vandalism, but would also hinder positive contributions.
  2. Use fairly standard anti-spam measures like captchas and link blacklists. This can slow down positive contributions, but still allows them.
  3. Have no filtering. This would make contribution easiest, but comes at the cost of wasting immense amounts of volunteer time reverting spam.
The abuse filter was developed for similar reasons (pagemove vandalism, long-term abusers). We could have simply locked pages down, raised the autoconfirmed threshold, restricted pagemoves to a smaller subset of users, or continued wasting more volunteer time reverting. But a more targeted approach, despite being considerably more effort to develop, was decided to be more preferable. There may be some filters that are overly broad, but when we're discussing these systems, we have to look at them in the proper context. Mr.Z-man 17:04, 4 February 2014 (UTC)
The autoconfirmed threshold is almost like a filter all on its own, and it has existed long before the AF extension did. That's interesting, I'll research the history behind the user group rights some more. TeleComNasSprVen (talk • contribs) 21:14, 4 February 2014 (UTC)
Sorry, I don't know why but I must have missed the previous discussion when I tried to search through the Village Pump archives for them; that's probably the thread that started this crosswiki trend of removing indefinite IP blocks anyway, as with most cases on the English Wikipedia. Well anyway now that the RFC is underway I don't think there should be anything to stop the process of consensus formation, so I feel I can't close it now. I've found lots of interesting points and arguments raised in this thread, but curiously enough I haven't seen anyone try to rebut my second point on letting Meta Stewards handle abusive open proxies with indefinite blocks, and I'd like to see someone at least attempt to counter that argument, besides the vapid "I don't like Meta" argument. TeleComNasSprVen (talk • contribs) 00:46, 4 February 2014 (UTC)
One word: manpower. There are currently only 36 stewards, and thus there can be periods where none of them are active online. Meanwhile, we have 851 administrators, and there are usually several of them active at all hours of the day. If there is a severe attack from several open proxies, do you really want to wait hours for the nearest steward to arrive on the scene? The English Wikipedia is the most visible and visited wiki, let alone one of the top visited web sites, and thus always a larger target for vandals than all the other wikis combined. Zzyzx11 (talk) 14:33, 16 February 2014 (UTC)
I do not want to encourage more new editors, especially among the general populace. I would support blocking all IPs from editing since they are not people. Chris Troutman (talk) 20:54, 16 February 2014 (UTC)
Re: ProcseeBot (@User:Mr.Z-man), it's 60 for the first discovery, 1 year for each subsequent (to prevent spillover on DHCP pools). The main reason for indefinitely blocking an IP or IP range would be school vandalism—not proxies (see also: transclusions of {{repeatvandal}}). As far as anyone complaining about "the validity" of the bot, you're more than welcome to re-experience the joys of trying to hunt down, block, and clean up rapid-fire, ip-and-account-hopping vandalism across multiple articles, but I wouldn't recommend it. I was there for that, and it was the reason the bot was made and that the pragmatic decision to proactively—not simply reactively—block open proxies came about. --slakr\ talk / 18:44, 18 February 2014 (UTC)

One year is too short. This is by virtue of the fact that many school and proxy blocks need to stay at least two or three years long.--Jasper Deng (talk) 03:00, 14 March 2014 (UTC)

Proposal 4: Dealing with old (pre-2010) indefed IPs

I am more fond of a case-by-case approach. Let's be rational here.

  • Just because a student in some high school vandalized wikipedia consistently for 2-4 years does not mean we should keep it blocked until time ends.
  • Likewise we shouldn't keep IPs unblocked just because 1 good edit could come out of 100 bad ones.

There is a trade-off for each case and since 2010 this has not been much of a problem. Currently however there is a backlog of old (pre-2010) indef blocks that are the core of the problem. Can we please focus on these? Most of these blocks no longer serve a purpose aside from inflating the indef blocked IP count and serving as examples of collateral damage.

-- A Certain White Cat chi? 05:08, 23 March 2014 (UTC)

I'm not sure what course of action you're asking for here. Everyone pretty much agrees on these points, but how will we address them?--Jasper Deng (talk) 03:49, 25 March 2014 (UTC)
I think we should first agree on some sort of a cut-off date as everybody seems to be worried about something different about these IPs. The actions and decisions should be taken step by step, otherwise we fail to reach any consensus as we haven't for about a year now. As is these IPs will remain blocked until times end. -- A Certain White Cat chi? 04:10, 25 March 2014 (UTC)
Why indefinite though? Why not have a block duration of only five years? Or eight years? As we can see from the blocks stretching all the way back to 2004, indefinite really means infinite, despite what everyone might say to the contrary. At least, pre-2006 blocks should have a set expiry of three years, but as billinghurst notes above, no one has bothered to do the research necessary to for these IP blocks; people keep saying the encyclopedia will somehow blow up without the "vital tool" of indefinite blocking IPs when time-expiry blocks will do just fine. At worst, with collateral damage we are driving away the potential contributors this project needs (c.f. the WMF reports on declining editor activities) for the sake of targeting a few specific vandals - from 2004. My guess is they have already forgotten about Wikipedia... TeleComNasSprVen (talk • contribs) 07:54, 25 March 2014 (UTC)
I think we need to come up with some sort of a compromise in order to move forward. We have gotten nowhere with prior proposals and attempts. At the moment I strongly feel we need to have a step by step discussion establishing how to move forward. Can we agree on a cut-off date to exclude IPs blocked after 1 January 2010? Blocks after this (arbitrary) date are fairly recent and are more likely to cause problems. Can we also agree to exclude range blocks from consideration? We can then decide what to do with the remaining IPs in a step by step manner. -- A Certain White Cat chi? 05:53, 26 March 2014 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Protection of templates

When did we start to fully protect all templates with a few thousand transclusions? I thought the consensus was not to do so. Christian75 (talk) 18:10, 22 March 2014 (UTC)

There is a user right called template editor, which is given out in order to edit high use templates. Werieth (talk) 18:11, 22 March 2014 (UTC)
A user with the template editor right still can't edit fully-protected templates though. Christian75, please provide some examples of fully-protected templates with a few thousand transclusions. --Redrose64 (talk) 20:14, 23 March 2014 (UTC)
Maybe I should have includede template editor, but it still fully-protected for most users. Consensus is (was?) that we do not protect templates unless they are vandalized or it has been discussed on the talk page, even if its highly trascluded and then it should be discussed at the talk page first.
Our policy says WP:TEMP-P template-protected page: "This protection level may only be used on high-risk templates and modules, and possibly in rarer cases where pages in other namespaces become transcluded to a very high degree." and [...] "It should not be used on less risky templates on the grounds that the template editor user right exists – the existence of the right should not result in more templates becoming uneditable for the general editor population.". And Wikipedia:High-risk templates says "If fully protected, so that they can only be edited by administrators, or template-protected, so that they can only be edited by administrators and template editors, these templates should be changed only after consensus for the change has been established on the template's talk page."
Here is some with a few 1000 transclusions from today which have been protected (but templates with 10000 or 20000 transcluions get protected too - without any discussion) - Examples: Module talk:Location map/data/Italy/attribution, Module talk:Location map/data/Nepal/attribution, Template:IPA-all (4000 transclusions, no discussion at the talk page, but he links to WP:High-risk templates which says "If fully protected, so that they can only be edited by administrators, or template-protected, so that they can only be edited by administrators and template editors, these templates should be changed only after consensus for the change has been established on the template's talk page"), Template:Bot (1500 transclusions), template:REMOVE THIS TEMPLATE WHEN CLOSING THIS AfD (800) and so on. Christian75 (talk) 10:36, 27 March 2014 (UTC)
The /attribution pages are just for historical records to maintain edit attribution from the template>Lua conversion. Those types of pages shouldnt ever be edited. Werieth (talk) 10:42, 27 March 2014 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(policy)/Archive_112&oldid=1245213091"