Wikipedia:Village pump (policy)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Yaris678 (talk | contribs) at 17:18, 30 December 2013 (→‎Technical Feasibility: Already an option). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

"WP:VPP" redirects here. For proposals, see Wikipedia:Village pump (proposals).
 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
The policy section of the village pump is used to discuss proposed policies and guidelines and changes to existing policies and guidelines.
If you want to propose something new that is not a policy or guideline, use the proposals section.
If you have a question about how to apply an existing policy or guideline, try the one of the many Wikipedia:Noticeboards.

Please see this FAQ page for a list of frequent proposals and the responses to them.


« Archives, 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



In Culture- in "popular" culture- in "Literature"- Legacy

Many articles have sections listing references to the subject of the article in fiction or arts.

I submit that certain headings for these sections imply a judgment that a work is high-quality, or is Literary, or is low-brow. I submit that these judgments are not ones we are qualified to make, as verifiable sources disagree, and there is even disagreement as to what popular culture is: whether it is less important or less valuable than "High culture" or what kinds of "culture" might not be "popular culture". Does "popular culture" comprise artistic works which do not require particular education to appreciate them, and if so, do such works exist?

Examples: Experience machine- "In literature", (literature sounds high-brow) referring to a story in Amazing Stories, and the film The Matrix. Dresden bombing "In popular culture" (sounds low-brow) and I found the novel Slaughterhouse-five outside this heading. This illustrates how invidious the judgment is. Whether a school could exclude it from the school library on moral grounds reached the US Supreme Court. Thomas Becket "Legacy" includes Murder in the Cathedral, a play by TS Eliot so arguably High culture, and churches named after him.

Is it worth creating a policy for a single heading for such parts of articles?

Advantages for such a policy: there would be no judgment, express or implied, on a work, whether it was written for a specific public, or was high quality, or was high-brow or low-brow. The judgment would only be whether it was significant enough to be included- I see this is not a question of WP:Notability.

Proposed heading:

In culture. I propose "In culture" to include literature and all other arts, to include "high-brow" or "serious" or "quality" or "politically correct" culture, and works which are arguably not. Abigailgem (talk) 15:59, 13 December 2013 (UTC)[reply]

You'd have people calling out that that's discriminating more mainstream media compared to what is "high-brow". The better solution is to use independent third-party sourcing that identifies when a topic is part of the pop culture, instead of relying on the just primary (the work itself). --MASEM (t) 16:03, 13 December 2013 (UTC)[reply]
I agree that needing third party sources is a good thing- the long list aboutAlpha Centauri in fiction saying that it was mentioned in so many shows seem unencyclopaedic to me- but the purpose of my proposal is to avoid that judgment or discrimination. Is something not "popular" culture because it is something else- unpopular, highbrow, whatever? Everything fits under "In culture". Abigailgem (talk) 22:46, 14 December 2013 (UTC)[reply]
I think Masem missed the point of what you were talking about, which is the variation in header naming and how it sometimes purports to target only "literary" cultural references and other times "pop culture" references. I agree with you that these distinctions should not be made in these sections, that the header naming should be something more neutral regardless of what threshold we decide for when a reference is substantive or notable enough to merit inclusion in that section. postdlf (talk) 17:50, 17 December 2013 (UTC)[reply]
Oh, I see on naming the section, "Legacy" is the way to go. This implicitly puts weight on needing third-party sources that others considered the use of a previous work in a later work to be part of the previous work's legacy - irregardless if it is a classical or contemporary work. --MASEM (t) 22:47, 22 December 2013 (UTC)[reply]
The question posed by the OP addresses not just a reference in a later cultural work to an earlier one, but cultural references to or depictions of any article subject. "Legacy" would be an odd if not outright absurd place to put dramatizations or fictionalizations of a notable person's life ("Lincoln's legacy includes the Emancipation Proclamation and being fictionalized in Abraham Lincoln: Vampire Hunter"). And if the article subject is a cultural work, in my understanding "legacy" then focuses more on how the subject is later thought of popularly and academically and how it influences later works and culture, which is both more broad and more subtle than explicit references to that work within other works. And "legacy" would be an odd way of characterizing references in other cultural works that are roughly contemporaneous to the original work (such as opportunistic parodies of a popular movie). postdlf (talk) 23:15, 22 December 2013 (UTC)[reply]
Reception history? --Hegvald (talk) 09:25, 22 December 2013 (UTC)[reply]
I don't see how that's relevant here. postdlf (talk) 22:24, 22 December 2013 (UTC)[reply]

RFC: On the controversy of the pseudo-namespace shortcuts

Background: There has been a recent spate of discussions surrounding the nature of the pseudo-namespace shortcut redirects laying 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)[reply]

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)[reply]

  • 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)[reply]
    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", C: 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)[reply]
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)[reply]
That sounds like something that should be taken up at Talk:Mossi language, if anywhere. Anomie⚔ 22:09, 22 December 2013 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
(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)[reply]
  • This is the most unclear RfC I have ever read. --SmokeyJoe (talk) 08:15, 27 December 2013 (UTC)[reply]
  • 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)[reply]
    Thanks for getting the conversation started. John Vandenberg (chat) 11:52, 27 December 2013 (UTC)[reply]
I don't understand the discussion. I support keeping the shortcuts. --NaBUru38 (talk) 21:28, 27 December 2013 (UTC)[reply]
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)[reply]

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)[reply]

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)[reply]

Use of notability essays during AfD nominations

Wikipedia notability essays serve a useful purpose - providing thoughtful suggestions of notability, particularly when it comes to presumptive notability. However, there are instances when these (and possibly other essays) are invoked as the entire or predominate reason to nominate an article for deletion. When this occurs (particularly when supplied as an authoritatively-appearing Wikipedia:Shortcut), new and/or less experienced editors who may not be well-versed in the substantial differences between things like policy, guidelines, and essays can be misled by their invocation. While there are a few small warnings in place to keep editors aware that essays are not established policy, this type of use for an AfD nomination can still easily give the false impression that meeting the suggestions given by the essay are what is being debated, rather than the standards established in actual policy. Moreover, the suggestions given for presumptive notability are high, as they well should be. Thus, it can become discouraging for editors to even participate in AfD discussions where it appears that meeting those achievements is what is being debated, rather the true policy behind it.

My suggestion would be a small addendum to current deletion policy – a formalization that prohibits or strongly discourages the nomination of articles for deletion for simply not achieving the suggestions given in essays, rather than their adhering to actual policy or guidelines. As mentioned in the template for notability essays, they very much should be consulted for assistance during the AfD discussion, particularly when it comes to presumptive notability, but they however should not be listed as the deletion reason per se, as again this can appear to some as misrepresentative of what is actually being debated.

So, in sum, with this change an article would and should still be nominated for deletion for not meeting something like WP:GNG, WP:BLP, or as listed in WP:SPEEDY; it would not and should not be nominated for "failing to meet" the suggestions given in WP:MILNG, WP:CCWMOS, or WP:MMANOT. Rather, these essays could be used in the actual discussion as evidence toward deletion or retention. I believe that making this a best practice could go a long way to providing clarity for editors of all experience levels during AfD nominations. Thoughts? Buddy23Lee (talk) 19:31, 19 December 2013 (UTC)[reply]

Yes, wikiproject notability guidelines do not have global consensus like the subject-specific ones (like BIO), and certainly cannot override the GNG and these subject-specific ones, so nominations that are based on deletion due to failing to meet a project's guidelines (while still meeting the GNG or a subject-specific one) is not appropriate. At the same time, articles failing the GNG and subject-specific guidelines cannot be justified being kept because they meet a project's notability guidelines. (Project guidelines can be elevated to global ones if they work to include the concepts in one of the appropriate subject-specific ones, of course). --MASEM (t) 19:38, 19 December 2013 (UTC)[reply]
Exactly, and I believe that this minor policy change would seek to address that inappropriateness. I consider myself an at least averagely savvy editor, and it took me quite a while to realize the essential difference between essays and policy when it came to AfD nominations. I think the process should be transparent to all sides of an AfD debate. Buddy23Lee (talk) 20:09, 19 December 2013 (UTC)[reply]

There is already WP:NOTPOLICY. Barney the barney barney (talk) 20:45, 19 December 2013 (UTC)[reply]

Good point, but that appears to be an essay as well. I was thinking of a sentence or two could be added to actual deletion policy discouraging some of the practices mentioned in WP:NOTPOLICY and above. Buddy23Lee (talk) 21:20, 19 December 2013 (UTC)[reply]
  • IMO, this suggestion is a solution looking for a problem. AfD does alright even though some nominators appear to be clueless. At the end of the day the closing admins know what they are doing. Problem is, I feel pretty sure that many nominators don't follow up and see how their AfDs were closed. When I come across the rare misplaced AfDs, I usually leave some friendly advice for the nominator. Kudpung กุดผึ้ง (talk)
  • Oppose per WP:CREEP. Failure to grasp the differences and nuances between policies, guidelines, essays, etc makes one look like a bit of a noob, but isn't big enough a problem that we need to legislate even more policy to prohibit it. Besides, if there were such a rule, editors likely to make such a basic mistake are exactly the sorts of editors who wouldn't know about the rule. Kudpung's assessment of "a solution looking for a problem" is about right. Andrew Lenahan - Starblind 00:33, 30 December 2013 (UTC)[reply]

URL Links in Infobox

Im looking to firm up consenus re URL Links in info-boxes. Info-boxes such as Template:Infobox theatre advise us to use the template {{URL}} and display like so http://www.majestic-theatre.com, this leaves a full URL on display. The template allows the link to be formatted as we may do in main articles to display like so Majestic theatre, however this is depreciated although it does explain in the template documentation how to do it and it works. Im looking for two things, consensus on whether or not we should display full URL's in info-boxes (whether thats wrapped in an template or not) and if they should be displayed as a full URL should parameter 2 in {{URL}} be removed meaning the template cannot display a formatted link, the latter has been proposed here anyway. This has been discussed at various locations previously but not in big scale discussions and i feel it would be beneficial to bring consensus up to date and obviously look at what template URL should be used for.Blethering Scot 17:53, 20 December 2013 (UTC)[reply]

  • I note that this is for derivatives of the {{Infobox}} template that support the website parameter. The {{URL}} subtemplate doesn’t actually require a full URL, but will also accept an abbreviated form, omitting the protocol, e.g. www.example.com, and create the correct URL in the underlying tag's HREF attribute. In an infobox, the URL is almost always a domain name, only, so it's usually relatively short. If the URL has a path that makes it long, then it's really not a "website" and shouldn't be in the infobox website section. The domain name itself is an important visible means of identifying an entity, so I feel that it should remain as it is. (Also, is this a "policy" issue or a "style" issue?) —Danorton (talk) 18:23, 20 December 2013 (UTC)[reply]
  • The point of displaying a website in an infobox is so that a reader can quickly see the address of that website without necessarily having to click through to read the resulting page address. For that reason we display the word 'Website' followed by the url. There is no point whatsoever in clogging up the infobox for Apollo Theatre, for example, by displaying 'Website Apollo theatre'. As Basil Fawlty put it: "Next contestant, Mrs. Sybil Fawlty from Torquay. Specialist subject - the bleeding obvious". --RexxS (talk) 18:48, 20 December 2013 (UTC)[reply]
  • Agree with Rexx (and concur with invoked apropos comment by Basil ).Make it simplest and easiest for the reader, always.(Littleolive oil (talk) 18:58, 20 December 2013 (UTC))[reply]
  • There is already consensus for the display of URLs in infoboxes, as was recently explained to Blethering Scot elsewhere. When challenged to find any dissent from that consensus other than his own, he offered none. It's hard to see this RfC as anything other than disruptive. It needs a WP:SNOW close. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:06, 20 December 2013 (UTC)[reply]
  • Why is this being discussed here instead of at WT:EL? Well, never mind: IMO you should display the bare URL, unless the URL is so long and unwieldy that it wraps onto several lines. WhatamIdoing (talk) 20:06, 20 December 2013 (UTC)[reply]

Showing the URL is useful for when someone prints an article on a sheet of paper, or reads it on a device without mouse-over capability. Showing the protocol could be useful if a new protocol someday becomes popular. For instance, SPDY is meant to replace HTTP in the same way that HTTP replaced Gopher. —rybec 01:07, 28 December 2013 (UTC)[reply]

WikiProjects against portals

There is a dispute involving WP:Portals that could probably benefit from the views of uninvolved editors. To give you a quick summary, the fundamental question seems to be whether a WikiProject can reject links to (relevant) portals in articles within their scope. One way to put it might be this: May Members A, B, and C, none of whom are actively editing the article in question, tell Non-Members D and E, who are editing the article, that portal links are never acceptable, or is the inclusion or rejection of portal links something that must be decided article-by-article, by the editors on each separate article's talk page?

If the WikiProjects' WP:Advice pages are considered binding, then they apparently need help figuring out what to do when WikiProject #1 rejects the links and WikiProject #2 supports the same links.

The main discussion seems to be at Wikipedia talk:WikiProject Film#Cross WikiProject relations and decisions about portals right now. A variety of responses about the general issues as well as whether you would support or oppose inclusion of portal links on pages like this would probably be helpful.

Thanks, WhatamIdoing (talk) 02:26, 25 December 2013 (UTC)[reply]

Were infoboxes getting old so people had to find something else to argue about? I haven't kept up with the latest in the "can WikiProjects force use or non-use of infoboxes on articles in their scope" debates, but it seems to me this should go the same way. Anomie⚔ 16:05, 25 December 2013 (UTC)[reply]
This seems like another obvious overstepping of authority by WikiProjects and a WikiProject stating an portal, infobox, etc. cannot be used on their articles is a clear vilation of Own. Kumioko (talk) 16:26, 25 December 2013 (UTC)[reply]
To be fair, some portals are rather tenuously associated with the topics where they're being placed. When you get down to specifics, the anti-portal group may well have a totally valid point.
But, yes, this seems to be the latest incarnation of people sincerely, though erroneously, believing that self-identifying yourselves a "WikiProject" means that you are supposed to set some rules. We (the community) let this rumor persist without serious challenge for several years, and that means that hundreds of good editors have heard this misinformation through the grapevine, from people they trusted, and have no reason to disbelieve them. We're making progress, but based on how long it's taken to deal with the WP:Secondary does not mean independent problem, I'm guessing that this will take at least two or three years to get the news to everyone. Apparent "facts" that "somebody told me when I was a new editor" are very hard to dislodge. WhatamIdoing (talk) 16:51, 25 December 2013 (UTC)[reply]
I think that each link should be decided y the whole community. In other words, WikiProject members should never have a higher status to decide things that non-members. --NaBUru38 (talk) 21:02, 27 December 2013 (UTC)[reply]

Tag people at Wikipedia

I would like to make a suggestion to mark all articles about real persons (humans).

At the moment it is very difficult to extract persons from Wikipedia. However, it is humans who write Wikipedia articles and who create all the knwoledge appearing at Wikipedia.

At present all humans are scattered over various categories (date birth, living people, lived people etc).

The Google matrix analysis with various ranking methods show that Wikipedia hyperlink network correctly selects the most influencial people of humanity (see Refs.1-5 below for ademic research). However, a computer selection of humans (real persons) is very difficult as the moment, not only for other languages but even for English.

In my opinion it will be very useful if a special tag (or Category people) would mark all real persons existed or exisitng in human hystory for all languages of Wikipedia. This would allow to perform an efficient network analysis of enhanglement of cultures and their interactions based on computer science methods.

Refs: 

    Ref1. A.O.Zhirov, O.V.Zhirov and D.L.Shepelyansky, "Two-dimensional
     ranking of Wikipedia articles", Eur. Phys. J. B v.77, p.523-531 (2010)
     (arxiv:1006.4270[cs.IR]) http://www.quantware.ups-tlse.fr/QWLIB/2drankwikipedia/

     Ref2. P.Aragón, A.Kaltenbrunner, D.Laniado, Y.Volkovich,
     "Biographical Social Networks on Wikipedia - A cross-cultural study of
     links that made history", Proceedings of WikiSym, 2012,
     (arXiv:1204.3799)

     Ref3. Y.-H.Eom, K.M.Frahm, A.Benczur and D.L.Shepelyansky, "Time evolution
     of Wikipedia network ranking", Eur. Phys. J. B v.86, p.492 (2013)
     (arXiv:1304.6601 [physics.soc-ph])

     Ref4. Y.-H.Eom and D.L.Shepelyansky, "Highlighting entanglement of
     cultures via ranking of multilingual Wikipedia articles", PLoS ONE
     v.8(10), p. e74554 (2013) (arXiv:1306.6259 [cs.SI])

     Ref5. S.Skiena, C.B.Ward, "Who is bigger?",
     Cambridge Univ. Press (2013) http://www.whoisbigger.com/


D.Shepelyansky

--shepelyansky (talk) December 25, 2013 —Preceding undated comment added 12:49, 25 December 2013 (UTC)[reply]

Hi shepelyansky, I suggest that rather than trying to extract information out of Wikipedia, you use DBpedia or Wikidata, as they are two projects that extract information out of Wikipedia and allow it to be queried. John Vandenberg (chat) 00:13, 26 December 2013 (UTC)[reply]

We have {{Persondata}}. It isn't always used but it's currently on 1,111,893 pages. Category:Living people is the largest people category. It currently has 643,730 pages. PrimeHunter (talk) 00:22, 26 December 2013 (UTC)[reply]
  • Hi DS - it appears you are the author of those studies? I do work in category space here so I could perhaps be of help. As you have found, it is indeed difficult to extract all people - I believe Category:People_categories_by_parameter will give you the best superset if you enumerate the contents recursively, but will also include fictional people, as well as other non-people articles esp those that are members of eponymous categories. We don't have any pure 'people' categories - even the pure ones will include lists and occasional other topical articles. There are many bios here, I would bet over 1.5m, so a suggestion to add a new category to so many pages is likely to be viewed in a dim light. I'd rather instead suggest you focus on use of other techniques to use nlp or other post processing to clean the superset list from the category above of articles that are either a) not about people (shouldn't be too hard) or b) not about real people (harder).--Obi-Wan Kenobi (talk) 16:45, 27 December 2013 (UTC)[reply]

RfC: template main versus template details and for what purpose(s) to use template main

This seems to be a perennially controversial issue, so I've started a RfC at Template talk:Main#RfC. Someone not using his real name (talk) 00:53, 26 December 2013 (UTC)[reply]

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

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)[reply]

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)[reply]

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)[reply]
(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)[reply]
(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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]

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)[reply]

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)[reply]
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)[reply]

Tagging articles with multiple non-free problems for NFCR review

{{non-free review}} exists to tag images that may be a problem with NFC as to be listed at NFCR rather that FFD. This is accepted. About May of this year, as NFCR began to be brought up more in light of recent NFC issues at that time, a couple editors decided to adopt the template to use in article space for article with overall NFC problems (too many, for example). After some editors objected to this tag being left at top of article pages, they opened an RFC which closed that the bold change to use on article space was imporoper consensus.

This still leaves the issue of how to alert editors of articles with NFC problems that are being discussed at NFCR. Tagging indiviuduasl file pages will not catch the right eyes. There doesn't seem to be any problem with these in article pages no I more than other maintenance tagsd and will look just as ugly. Or we could put the on article talk pages but I suspect this will reduce participation at NFCR , the primary reason we have been using NFCR more often. We need some type of alert template for article pages. --MASEM (t) 07:33, 27 December 2013 (UTC)[reply]

Template Vandalism

Background

For the past few days, trolls have been persistently vandalising a number of highly visible templates with official-looking advertisements and other explicit images. For example, see these two screenshots - [1] [2]. Every time one of these vandalisms occur, it takes quite some time for editors to revert, as well as causing issues with purging, which make the templates be displayed even after they're edited back to their original form.

So far the following templates have been vandalised, almost all of them used in multiple highly viewed articles (Number of transclusions available)-

As is visible, all of these templates are either transcluded in many pages, or are transcluded in some pages which have a lot of viewers, making it a deliberate attempt to cause disruption for a large number of our readers.

Relevant discussion can also be found at ANI Post1, ANI Post2, ANI Post3 Village Pump Post.

There has been one abuse filter at work but given how the vandals appear to know Wikipedia enough to know which templates to attack, it probably would not hold them off for long, even if it does. Meanwhile, it misleads a significant number of our readers (See the number of edits at this supposed "Discussion" page where the readers were directed to. Also see the now deleted Wikipedia_talk:Advertising_on_Wikipedia page on testwiki.)

Proposal

To deal with this vandalism, I propose the following steps to be taken to immediate effect-

  1. The Pending Changes (See comparison table) protection level be enabled for Template space.
    1. To allow this to be effective for Templates, 59102 has been filed at bugzilla.
  2. PC1 will be enabled for all high-risk templates. If the vandalism persists, this will be converted to PC2
    1. For both these protections, template editors will have the same rights as reviewers
    2. Special:PendingChanges can be used to allow for effective maintenance of any pending changes on the templates.
    3. The high-risk will include the following templates. More pages may be added to the high risk templates on further discussion
      1. Templates transcluded on more than 250 pages
      2. Sidebars with collapsible lists (Example - {{Politics}})
      3. Expansive navboxes. (Example - {{Chess}})
      4. Any templates transcluded in any of the above

The Fallout

  • The immediate very significant advantage for this will be to deal with these recent vandalisms. Any other such template vandalisms in the future will also be dealt with.
  • A number of edits made to template by inexperienced users break things. This would allow an extra set of eyes on changes made to the templates.
  • The load for reviewers and template editors would increase, who have to monitor the PendingChanges page.
  • There will be some collateral good-faith IP editors who will require the edits to be confirmed by TE or reviewers.

TheOriginalSoni (talk) 19:40, 29 December 2013 (UTC)[reply]

Note - The RFC was changed from including PC1 for all templates to including PC1 for only high risk templates on 20:45, 29 December 2013 (UTC) by TheOriginalSoni (talk)

The various protection levels explained
Interaction of Wikipedia user groups and page protection levels
  Unregistered or newly registered Confirmed or autoconfirmed Extended confirmed Template editor Admin Interface admin Appropriate for
(See also: Wikipedia:Protection policy)
No protection Normal editing The vast majority of pages. This is the default protection level.
Pending changes All users can edit
Edits by unregistered or new editors (and any subsequent edits by anyone) are hidden from readers who are not logged in, until reviewed by a pending changes reviewer or admin. Logged-in editors see all edits, whether accepted or not. 		Infrequently edited pages with high levels of vandalism, BLP violations, edit-warring, or other disruption from unregistered and new users.
Semi Cannot edit Normal editing Pages that have been persistently vandalized by anonymous and registered users. Some highly visible templates and modules.
Extended confirmed Cannot edit Normal editing* Specific topic areas authorized by ArbCom, pages where semi-protection has failed, or high-risk templates where template protection would be too restrictive.
Template Cannot edit Normal editing High-risk or very-frequently used templates and modules. Some high-risk pages outside of template space.
Full Cannot edit Normal editing Pages with persistent disruption from extended confirmed accounts. Critical templates and modules.
Interface Cannot edit Normal editing Scripts, stylesheets, and similar objects central to operation of the site or that are in other editors' user spaces.
* In order to edit through extended confirmed protection, a template editor must also be extended confirmed, but in practice this is almost always the case.
Other modes of protection:

Technical Feasibility

  • Can anyone with the knowhow please tell us how feasible making this change will be, from a technical perspective? Likewise, how difficult will be the implementation? TheOriginalSoni (talk) 20:17, 29 December 2013 (UTC)[reply]
    • According to the Bugzilla report, there is already an option in the software to have templates transclude as the approved version, rather than the latest version. It just needs consensus for us to turn it on. This seems like the sensible way for the software to work so I don't think anyone would object to that per se, but obviously there is the question of when PC protection would be applied to templates, which is more controversial, as we can see from the discussion below. Yaris678 (talk) 17:18, 30 December 2013 (UTC)[reply]

Discussion

If there are any parts of this RFC that ought to be changed, please feel free to make that change, and note it here. I would be happy to have any changes according to what the Consensus is. TheOriginalSoni (talk) 19:40, 29 December 2013 (UTC)[reply]

  • Based on discussion at IRC, there was another view calling for PC1 to be limited only to the high-risk templates, rather than all templates. If other editors also agree with this view, then the proposal will be changed. To that extent, please state whether you prefer the current version or the alternate one. TheOriginalSoni (talk) 19:40, 29 December 2013 (UTC)[reply]
  • Based on discussion with a couple editors and the initial !votes, I have changed this proposal to the above suggested alternate. If consensus so demands, I'm still open to reveting back. TheOriginalSoni (talk) 20:45, 29 December 2013 (UTC)[reply]
  • I support the original variant, PC1 being applied to all pages in the Template namespace. Jackmcbarn (talk) 19:51, 29 December 2013 (UTC)[reply]
  • Template protection and the template editor user level were recently deployed a couple of months ago. This allows users with experience in template editing to maintain high-visible protected templates. Granted that not all highly-visible templates have yet been switched to the new protection setting, but this is an alternative option. I'm not sure if adding all templates to pending changes will be efficient: unless these experienced template editors will also be willing to monitor Special:PendingChanges, and most of those on pending changes patrol have little or no template experience to know whether incoming edits are valid or produce bugs, there will probably be lots and lots of backlogs. I'd rather have template editors monitor requests in one place (Category:Wikipedia template-protected edit requests) rather than both places. Zzyzx11 (talk) 20:46, 29 December 2013 (UTC)[reply]
  • While I do think pending changes protection should be used a little more than it is currently, PC1 protecting all high-risk templates could overload reviewers like myself monitoring Special:PendingChanges, especially those of us who aren't regular template editors and may not be able to distinguish good edits from bad at a glance. A better idea would be to apply template protection on the high risk templates, as that is exactly what that protection level was created to handle. Temporary PC1 or semi-protection could be used on templates that aren't high-risk, but still face vandalism. Novusuna talk 21:02, 29 December 2013 (UTC)[reply]
    • Hi Novusuna, one of the features of WP:PC is that there is no urgency to approve the change. Reviewers should always skip a pending change unless they understand it and approve of the change. That applies to any type of change. If reviewers approve a change they dont understand, the community should consider removing their reviewer right, especially if the reviewer frequently does it, or they approve an obvious problematic change. Special:PendingChanges can be filtered by namespace, so reviewers can focus on namespaces that they are confident in. I don't think we'll have problems finding reviewers competent in the Template namespace. John Vandenberg (chat) 06:20, 30 December 2013 (UTC)[reply]
      • Point taken, and comment struck-through to reflect. I still feel that template protection is the solution for high risk templates, as that is precisely the situation it was created for. As for lower risk templates, I'm open to the possibility of expanding PC1, but I don't think the community agrees with me there. Novusuna talk 06:43, 30 December 2013 (UTC)[reply]
  • I support the proposal except "If the vandalism persists, this will be converted to PC2." This is because there is "no consensus for use on the English Wikipedia" for PC2. Holdek (talk) 04:48, 30 December 2013 (UTC)[reply]
  • Hi all. I am a new account holder here. Had been using wiki since the 2nd year of my college for my studies as well as source of numerous other unbiased information. I do not think implementing a PC1 or PC2 can actually go with the original essence of Wikipedia and the values with which it started. The path, in my sense, is absolutely wrong and will soon end up our wiki becoming a personal thing, monopolised therefore, in prime interest of corporate profit maximisation. Please do not do that. It is the only thing we all have when even "Education" and "Knowledge" is monetary profit oriented business. We need this place to express we have some rights. Right to knowledge, right to offer betterment, right to take part in unbiased knowledge sharing irrespective of time and situation. Even if we may have shortage of resources (time is one of the prime resources).

There is only one final solution for long run : Increase the number of registered editors and content suppliers. To get there, we can do the following:

  1. For the time being can use PC1 protection
  2. Within that period, there can be implementation of intelligent security to contents added or altered. [using standard identification of spam content etc. with different parameters, based on original contents]
  3. Image uploading must be under PC1 for a longer period, untill we get a working opensource to identify abusive image content.
  4. There should be a easy "complain" tag, like the "edit" one, which will redirect the complain to all active registered editors. The complain process must be easy, without much hassles, with a complain reason, and antibot checking. name field may be there, but should be optional. The editors will verify the complained content at once and issue a report to the administrator after making necessary changes if required at all. If a certain number of registered users find that content abusive but not easily restored to its original version, that content can be made hidden by the administrator. And for that content which has got complaint(s) and verified that it needs treatment, but not a major abusive one, and only needs a little time to restore, can be flagged as "Complaint issued, Restoration in Progress".
  5. There can be a special type of "Complain" alert in each registered user's notification icon.
  6. It can be added to the list of ethics that each online registered user (who were active at his or her account, at the time of complain and also upto 5 mins afterwards) must respond to the complained content, and send a preliminary "Able"/"Unable" report with a brief reason. These reports can be auto managed and filtered as required.
  7. The last edit of a content, for which the complaint is lodged, must be tracked back and the user must be given alerts / the registration may be cancelled depending upon the extent of abuse.
  8. We can have a spell checker (and syntax checker for each language. After all language detection processes are evolving.) here in text area.


We must still keep faith in collective global "Conscience" of "Humanity". We can do better without exercising our selfish interest on a global asset. Even the person, who posted those stuff, is one of us, just diffrently troubled. -- This should be the message. United we stand.

I donno if I am being stupid. Felt this as right. Thanks. --Aaniya B (talk) 13:27, 30 December 2013 (UTC)[reply]

Votes

In the first few days, the proposal may be altered as per consensus. It is advised to discuss the proposal than oppose a part of it. TheOriginalSoni (talk) 19:40, 29 December 2013 (UTC)[reply]

  • Support as proposer. Template edits are hard to find, and harder to restore on all transcluded pages. We certainly need some protection against such vandalism. TheOriginalSoni (talk) 19:59, 29 December 2013 (UTC)[reply]
  • Neutral as amended (see below) Oppose as it stands. While I agree something needs to be done, there is just no way that locking down the entire Template: namespace is technically feasible or wise. PC1 in Template: is a bad idea as it inhibits may too many users from the trial and error needed to make proper /sandbox and /testcases pages to test their ideas and to propose proper edit requests. This is simply trying to hang a picture on the wall with a thumb tack and a sledgehammer. Technical 13 (talk) 20:02, 29 December 2013 (UTC)[reply]
  • With the change of the proposal to only high risk templates, the only question I would have left is what is the threshold for "high risk" I could see possibly a transclusion count of >100 for templates not designed to be substituted (which poses its own set of technical difficulties and decisions). Technical 13 (talk) 21:09, 29 December 2013 (UTC)[reply]
  • Support This doesn't inhibit any kind of editing, since even anons can see unapproved versions of pages when they choose to. This vandal is persistent, and I don't think anything short of this will stop him. Jackmcbarn (talk) 20:05, 29 December 2013 (UTC)[reply]
  • Oppose as per Technical 13. Not everything is Template namespace should be protected. —TheDJ (talk • contribs) 20:18, 29 December 2013 (UTC)[reply]
    • Comment the problem here is that visibility is much more important part of this type of vandalism than transclusion count. I would even support applying PC1 to all templates transcluded in article space. We would need a bot for that to keep that up to date though. —TheDJ (talk • contribs) 21:37, 29 December 2013 (UTC)[reply]
  • Oppose this proposal. There are many thousands of templates. Protecting all of them at any level would do more harm than good. We have appropriate protection levels for high-risk templates. Why not use those levels on an as-needed basis? [This statement has been changed based on an updated version of the proposal.] – Jonesey95 (talk) 21:10, 29 December 2013 (UTC)[reply]
  • Oppose as overreaching. The only difference between template vandalism and normal article vandalism is the difficulty of rapid detection and the slow pace at which articles transcluding the templates are automatically purged. I think that (along with user education on how to detect template vandalism from an affected article) a combination of bot activity and edit filters can handle the vandalism itself, while a developer-side tweak to the job queue allowing promotion of the sort of purge jobs involved by a user with advanced permissions. I think that, with such a change, we can even roll back the level of protection to templates we're already protecting as "high-risk" when it's just because the specific template has been abused in the past. —/Mendaliv/2¢/Δ's/ 22:52, 29 December 2013 (UTC)[reply]
  • Oppose either version. High-risk templates should have template protection, rendering the suggested measure redundant. The original idea (to apply PC to all templates) made more sense in the respect that such a change would make an actual difference, buy I regard this as major overkill. Additionally, there isn't even consensus to use PC level 2 at the English Wikipedia (and I don't believe that this is the correct context in which to establish it).
    TheOriginalSoni noted that "in the first few days, the proposal may be altered as per consensus", thereby rendering the discussion confusing and difficult to parse (as the version on which someone has commented might be unclear). A material revision already has occurred once, and TheOriginalSoni is "still open to reverting back". This suggests that the idea hasn't been fleshed out to a reasonable extent, which should have occurred before a formal proposal was made. —David Levy 23:18, 29 December 2013 (UTC)[reply]
  • Support - I personally have combated these vandals. Some are outright hate speech. Commons is typically slow to remove offending images and there's not an easy way to monitor template edits specifically that I know of. I think this proposal for an adequate response to the problem. EvergreenFir (talk) 00:29, 30 December 2013 (UTC)[reply]
    How, in your view, would adding PC protection to templates that already have template protection (with all editors capable of editing them also possessing the reviewer right) improve the situation? —David Levy 00:38, 30 December 2013 (UTC)[reply]
  • Oppose. First of all, if a template is WP:HIGHRISK, it should be permanently or template protected. If it isn't high risk, then we are the free encyclopedia that anyone can edit, and we have to tolerate needing to revert vandalism so that we can also get good edits from anons or new editors - which we all were at some stage. Secondly, PC1 and PC2 aren't the right tools for the job - the reviewer right has been given out with any consideration for template editing expertise. Iff this were to go ahead, then users that are trusted with templates (admins and template-editors) should be accepting the pending changes (ie, a pending changes level 3, rather than PC1 or PC2), and if you're gonna do that, why not just apply full or template protection, and have users make edit requests? So basically, we already have ways of protecting high risk templates. If you want to broaden the definition of high risk, perhaps you should propose that, rather than involving pending changes protection. If you want to patrol recent changes to the template namespace, then go to Special:RecentChanges and set namespace to template. - Evad37 [talk] 02:01, 30 December 2013 (UTC)[reply]
  • Oppose. We have an edit filter that's been created for the advertising thing; it should be stopping this, and if it's not, the solution is to improve the filter. Also, per Evad, you ought to propose a change to the "high risk" standards instead of making this request, because this request would involve a massive amount of work, causing much more work for almost all of our pages and overall producing much more difficulty than it would prevent. Nyttend (talk) 02:24, 30 December 2013 (UTC)[reply]
  • Strong Oppose. It is not at all necessary that all reviewers are good enough in template coding and would be able to help without breaking the codes. I am a reviewer too and I don't think that I would be able to do that. - Jayadevp13 02:35, 30 December 2013 (UTC)[reply]
  • Support protecting high risk templates. Note there is no prefect solution, just "good enough for now." -- Safety Cap (talk) 02:52, 30 December 2013 (UTC)[reply]
    As discussed above, we already protect high-risk templates. Are you expressing support for the general concept, or do you believe that the proposed change would constitute an improvement? —David Levy 02:56, 30 December 2013 (UTC)[reply]
  • Oppose. Protection of any sort should not be applied pre-emptively, certainly not on the scale proposed here. SpinningSpark 03:34, 30 December 2013 (UTC)[reply]
  • Oppose. High risk templates are already protected. I would rather see something see something like User:Anomie/previewtemplatelastmod provided automatically by the history of articles. Showing the latest changes to all templates ( and other transclusions) intermixed with the direct page edits. It would make template vandalism easier to handle by editors as it would bring the eyes of all impacted pages to the changes in the template. See also my comments to Template vandalism with images at WP:VPR. PaleAqua (talk) 03:48, 30 December 2013 (UTC)[reply]
    Also as I've commented on other pending change RFCs for templates, pending changes encourage the wrong approach to working with high risk templates. We should be encouraging sandboxes and test cases. PaleAqua (talk) 04:19, 30 December 2013 (UTC)[reply]
  • Support With this change, "high-risk" templates are no longer high-risk, effectively removing one type of high profile vandalism, and reducing the number of {{edit protected}} requests needed, thereby reducing admin workload. John Vandenberg (chat) 04:00, 30 December 2013 (UTC)[reply]
  • Oppose per my comment in the discussion section. Holdek (talk) 04:52, 30 December 2013 (UTC)[reply]
  • Oppose. Reviewers have no special ability to recognize template vandalism. And no matter how many back doors are tried, there's still no consensus to broaden the use of PC on the English Wikipedia. (There is consensus not to enable PC2.) Who is doing the vandalizing, anyway? If it's IPs and newbies, the solution here is semi-protection, and there is a newly created user group that is, one hopes, specially qualified to deal with the requests. If there's persistent template vandalism from sleeper socks, the solution is full protection. Rivertorch (talk) 05:19, 30 December 2013 (UTC)[reply]
  • Oppose: WP:TPROT already exists and is sufficient. Richard75 (talk) 13:00, 30 December 2013 (UTC)[reply]
  • Oppose: I have mentioned my logic and views in the Disciussion panel. --Aaniya B (talk) 13:32, 30 December 2013 (UTC)[reply]
  • Oppose as unnecessary. Isn't this what Template Protection and its associated usergroup/permission is supposed to do? ElKevbo (talk) 14:20, 30 December 2013 (UTC)[reply]
  • Oppose using PC. This is a big problem, as it presents Wikipedia in a very negative light to the average user, who has no idea that templates even exist, much less the technical details of how they are implemented. (Even as a long-time Wikipedian, I've learned a lot about how purging works in the past couple days by following this issue and related discussions.) That said, pre-emptive implementation of PC1 goes against the policy at WP:PC1. I also haven't been able to find any info on what the actual pattern of vandalism has been…how big of a sock puppet problem are we facing? I'm also very concerned about using template protection too widely, as there are only 63(!) current users with template editor privileges. As a 10-year registered user who has done some infrequent but moderately advanced template work, I would be upset and discouraged if I got closed out of making ordinary edits to templates that affect hundreds, rather than thousands or millions of pages. —Ed Cormany (talk) 15:39, 30 December 2013 (UTC)[reply]

Propose additional exceptions to interaction bans

In a one-way interaction ban, the banned editor is currently not allowed to reply to the other editor, even in discussions they are involved in, or in their own userspace or user talk space. The exceptions I am proposing are being allowed to reply to the other editor in discussions about the banned editor, but not reference their contributions outside the discussion, and an exception in the banned editor's user and user talk space, apart from making a reference to the other editor. Dark Sun (talk) 10:29, 30 December 2013 (UTC)[reply]

About Time

information Note: Moved from Wikipedia:VisualEditor/Feedback where it was left in error. — Scott • talk 14:00, 30 December 2013 (UTC)[reply]

It's about time for change as I have a lot to contribute but can't figure out your code. A few suggestions. First is that you lock the topics so that not just anyone can edit them which would make Wiki more trustworthy. Include options instead where an edit is submitted to the original author, an email can be sent to the original author or the edit can be submitted to someone to review it who can submit it.

I used your current guide to submit an article for someone else to create it and submitted a request for a Chicago Gunners page to be created. Why? Professional football is interesting to me and there's some articles about obscure teams and league but others are missing. There were negro leagues during segregation but little about them is available online without a lot of effort so that when you find it, you want to share the information to make it easier for others. I submitted a request for an article about the Chicago Gunners as I keep running across the name in regard to games played back in the early 20th century but what little I have found out about the actual team is scant. By having a Wiki page where I could actually request more information, maybe other sports fans could contribute what they know and we could build an article from verifiable sources. But if people can't understand the code and the options are like pulling teeth, most people with this knowledge won't share it. If they had more options to contribute and get involved, that would be very good for Wiki.

But you have to do more to protect the existing articles from people adding false information or removing what's already been submitted so that locking the pages and forcing them to go through more official channels would be a better way to do it. Armorbeast (talk) 08:23, 26 December 2013 (UTC)[reply]

Discussion on Discretionary Sanctions needs more voice

See this discussion. Add your voice  KoshVorlon. We are all Kosh   17:01, 30 December 2013 (UTC) [reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(policy)&oldid=588394178"