Wikipedia:Village pump (policy)

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, 193, 194, 195, 196

RFC: On the controversy of the pseudo-namespace shortcuts

Please consider joining the feedback request service.

An editor has requested comments from other editors for this discussion. This page has been added to the following list:

Wikipedia policies and guidelines

When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.

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:

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:

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.
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]

Biting from another side: I think the "useful" (WP:RFD#K5) clause should be restricted a bit. 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 (e.g. at Wikipedia:Redirects for discussion/Log/2013 November 18#Scw,c). 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

Is the redirect plausible and plausibly useful? (evidence of use is evidence of usefulness)
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]

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

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

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

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

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

@Scott Martin: I have listed that shortcut at Wikipedia:Redirects_for_discussion/Log/2014_January_3. John Vandenberg ^(chat) 01:47, 3 January 2014 (UTC)[reply]

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

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

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

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

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

I don't see how it would be much of an instance of creep when we already have extensive deletion policy and deletion guidlines that cover all sorts of minutia about AfDs aside from this. Obviously not all newer editors would be aware of this rule or suggestion, but it seems to me the vast majority of all AfD nominators are relatively experienced editors who are aware of policy and guidelines. Compelling them to only nominate articles based only on violations of policy and guidelines could only help to bring transparency and legitimacy to the process. Buddy23Lee (talk) 20:11, 30 December 2013 (UTC)[reply]

Oppose - per WP:NOTPOLICY and WP:CREEP. I just feel like these sort of things tend to regulate itself - if things are wrongfully cited, they tend to not pick up much support either. Sergecross73 msg me 22:33, 30 December 2013 (UTC)[reply]
Oppose because there probably doesn't need to be a policy to stop people from using essays as if they were policy if there is an essay that tells people not to use essays as if they were policy. Also, WP:CREEP, even though that makes it look like I'm treating an essay as a policy myself (!). -Well-rested ^Talk 09:21, 1 January 2014 (UTC)[reply]

URL Links in Infobox

Please consider joining the feedback request service.

An editor has requested comments from other editors for this discussion. This page has been added to the following lists:

When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

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]

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?- Mr X 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]

Please can this be closed per WP:MULTI, because it's a strong overlap of WT:LGBT#Wikipedia:Homosexual and related guidelines and policies (WP:HGI), a thread which was started first. --Redrose64 (talk) 19:10, 27 December 2013 (UTC)[reply]

FYI, Wikipedia:Miscellany for deletion/Wikipedia:Homosexual and related guidelines and policies. Sportfan5000 (talk) 19:53, 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

Per overwhelming consensus, I think it is sensible for the current proposal to be completely scrapped. I'd leave the discussion sections as they are, so other ways of dealing with this vandalism can be hashed out and discussed. TheOriginalSoni (talk) 19:34, 30 December 2013 (UTC)[reply]

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

The Pending Changes (See comparison table) protection level be enabled for Template space.
To allow this to be effective for Templates, 59102 has been filed at bugzilla.

PC1 will be enabled for all high-risk templates. If the vandalism persists, this will be converted to PC2
For both these protections, template editors will have the same rights as reviewers

Special:PendingChanges can be used to allow for effective maintenance of any pending changes on the templates.

The high-risk will include the following templates. More pages may be added to the high risk templates on further discussion
Templates transcluded on more than 250 pages

Sidebars with collapsible lists (Example - {{Politics}})

Expansive navboxes. (Example - {{Chess}})

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 administrator. Logged-in editors will 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	Normal editing*	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 for a template editor to be able to edit extended confirmed protected pages, they must also be extended confirmed, but in practice this is almost always the case.
Other modes of protection: Create protection Move protection Upload protection Office protection Cascade protection view talk edit

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]
  - I read that statement as meaning that FlaggedRevisions (PendingChanges) is an optional, existing feature, not that applying it to transcluded pages is an optional, existing feature. I'll ask around and see if I can find someone who knows the answer. Whatamidoing (WMF) (talk) 19:50, 30 December 2013 (UTC)[reply]
    - Cool. I see you have now made this and this change, which note what you have found. Thanks. I see the devs have also updated the Bugzilla report. Coolio. Yaris678 (talk) 13:04, 1 January 2014 (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:

For the time being can use PC1 protection
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]
Image uploading must be under PC1 for a longer period, untill we get a working opensource to identify abusive image content.
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".
There can be a special type of "Complain" alert in each registered user's notification icon.
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.
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.
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. Spinning Spark 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]
The strongest support that I can puff out. We need good faith IP editors! Dret h 17:32, 30 December 2013 (UTC)[reply]
Oppose per SpinningShark. Spencer^T♦C 17:49, 30 December 2013 (UTC)[reply]
Oppose This is what template protection is for. Besides, PC can't be applied to the template namespace.—cyberpower ^Chat_Online 19:25, 30 December 2013 (UTC)[reply]

That's not entirely true Cyberpower678 (C678—[[User:{{{3}}}|{{{3}}}]]). According to Matma Rex PC is used in Template: on pl.wp (IIRC) on an as needed basis. Technical 13 (talk) 00:50, 31 December 2013 (UTC)[reply]
I'm just going off what was told to me about this Wiki. That it can only be applied to Article and Wikipedia namespaces and the software disallows the rest. Although, I haven't been following PC lately.—cyberpower ^Chat_Online 01:22, 31 December 2013 (UTC)[reply]

If PC is PendingChanges (=FlaggedRevs), then on pl.wp the entire Template namespace (as well as main, Help and Portal namespaces) are entirely, fully and non-configurably under it (every edit needs to be accepted by a "trusted" user, the rights to do this are given automatically after some conditions are met). It definitely works. (Note that I have no idea what this discussion is about, I was pinged, so replying.) Matma Rex talk 01:27, 31 December 2013 (UTC)[reply]
Yesterday, I asked the devs who wrote FlaggedRevs about this. PC can be used to protect transcluded pages (e.g., templates) if and only if the target page (e.g., articles using that template) is also PC protected. On Wikipedias where everything in the mainspace is already protected by PC, then it works fine. Here, it would only work for a tiny fraction of pages. Whatamidoing (WMF) (talk) 22:04, 31 December 2013 (UTC)[reply]
Oppose. I've opposed PC in general from the start, but there are specific problems in template space.

Template editors aren't that common, so the changes may not get acted on while they are in a generic queue of recent PC changes
Generally speaking a template edit - especially to a high risk template - needs to be checked very quickly to make sure nothing went wrong (sandbox development or no, there's always a chance) - and even more quickly reverted if something did. PC could hinder that and make it hard to observe changes as they happen.
It is trivial to write a sub-template that pops up vandalism only after a specified timestamp and incorporate that into a template in a way that nobody but a superbly punctilious reviewer could ever possibly spot. You've noticed templates sometimes aren't all that easy to follow? Note that when I say "sub-template" I mean that in the functional sense - any page, in userspace, in talk space, wherever, can be transcluded.

The bottom line: the vandals will eat your reviewers alive. They'll slip their content right past them, then they can stack up an extra edit so your PC1 acts as de facto PC2 when a regular editor tries to revert their change, and then you have to scramble for a template reviewer to undo the change they make before you're even ready to start purging ... by which point, if they're feeling mean, they'll have another account or IP lined up to do it again. Look at old-fashioned semi-, template- or full- protection grades and forget PC. Wnt (talk) 04:33, 3 January 2014 (UTC)[reply]

Alternate proposal

Change the AN/ANI editnotices, and possibly push a notification to watchlists, reminding editors that upon encountering possible template/advertising vandalism they should:
- First, purge the page, and if that does not fix it:
- Go to "Related changes" and select only the "template" namespace, and inspect any changes from the last five to ten days,
- Revert vandalism and request template protection for the affected templates, and
- Post at some central discussion place (probably an AN subpage) so the appropriate process may be started at the wiki hosting the transcluded "ad" image to delete that file ASAP.
Request a feature via bugzilla to allow bureaucrats (and possibly administrators) to raise the priority of jobs in the job queue.
- This would allow such users to rapidly purge all pages depending on affected templates (clicking "purge" on a page has this effect with a single page, but it is probably inadvisable to encourage the mass use of this feature)
- Upon the release of this feature, we can gradually roll back template protection on less prominent templates.

This should address all the problems we're currently facing and allow a means of resolving it with the minimum of interference with everyday life here. —/Mendaliv/^2¢/_Δ's/ 19:23, 31 December 2013 (UTC)[reply]

A technical feature that would help enormously here is to automatically also put on a watchlist images and transclusions on a watched page. That would put an awfully lot more eyes on this sort of vandalism. Spinning Spark 23:39, 31 December 2013 (UTC)[reply]

That should be trivial or nearly trivial to implement with a bot, especially in conjunction with an edit filter. Any edit that displays a file in template namespace triggers the filter, and a bot watching recent changes sends the edit to the noticeboard for examination. That would actually be an awesome way to build up a sufficient corpus of edits to train a bot on. Editors mark the entries as good, simple vandalism, or advertising. Hell, it'd be simple even without an edit filter, but with would mean less workload on the bot/toolserver since it'd have to fetch all template namespace edits and check the diffs otherwise. —/Mendaliv/^2¢/_Δ's/ 02:42, 2 January 2014 (UTC)[reply]

On that note, has it ever been considered that Patrolled Revisions (sans pending changes) could be used in this way to train vandalism-fighting bots? —/Mendaliv/^2¢/_Δ's/ 09:20, 2 January 2014 (UTC)[reply]

I haven't seen this particular batch of ad spam, but you can make a pro-looking ad with some skill at CSS; you don't actually need to access a file. Wnt (talk) 04:38, 3 January 2014 (UTC)[reply]

It's generally been file links thus far. But point taken: it's a game of cat and mouse. But a cascading purge should help stem the tide of all of this. —/Mendaliv/^2¢/_Δ's/ 08:29, 3 January 2014 (UTC)[reply]

REVIEW

I'm sort of fed up by all these people suggesting ideas for tricking the job queue. The job queue is there for a reason and you shouldn't bypass it. You guys are solving the wrong problem. If you don't want to accidentally cascade a template change into all pages, you need to use a turnstile instead of a seesaw to toss people back into the ~~row~~ [line] after they have passed the door. What you need is some form of flagged revisions. Be it PC or I don't give a crap how we configure and call it. THAT is what you need. We can FIND reviewers, we can ASSIGN groups and permissions. As far as I'm concerned, we retool template protection into a PC1 like protection, apply it to all templates used in mainspace (bot controlled) and we use PC2 where needed. This is not content space, content space decisions don't matter, we can use PC1 and PC2 just fine, as long as we set it up properly. —TheDJ (talk • contribs) 20:06, 2 January 2014 (UTC)[reply]

Hey, I don't disagree in principle, but the current consensus is no PC. If PC is barred, this is the best solution. And messing with the JQ is already available in the form of action=purge. I don't see why this is such an outlandish proposal, if even as a stopgap solution until PC gains consensus. Limit the people capable of executing immediate cascading purges to 'crats. Simple. —/Mendaliv/^2¢/_Δ's/ 02:41, 3 January 2014 (UTC)[reply]

That's because the current consensus is based on FUD. The various forms of protection are technical measures and names like PC, Patrolled Revisions and Sighted versions are failed (content space) definitions around configurations for these measures. We should separate technical implementations from the proposals. template protection == full == semi protection, but with a different user group administrating it. The problem here is that no one dares to touch anything with regards to FR/PC/PR/SV with a ten foot pole anymore. And that means sane technical solutions are being discarded simply because we engage too much in politics here.. We'd rather use a badly performing wipe to clean up after the tsunami because we once decided we don't want a dike in front of our rivers. Time to consider building a sluice for this specific problem. The problem here is the cascading effect that templates have, not the job queue. People seem to want a bigger wipe. Any engineer will tell you that is a mediocre change to countermeasure your problem of regular tsunamis. As a volunteer MediaWiki developer I can tell you that quite possibly, we can make the job queue a bit smarter, with more priorities for instance and we can add more servers to process it quicker (both will probably happen at some time). The thing is, in the long term it's just not gonna help this problem much. If there are 2 jobs of 1500 pages with priority "very high", we still can't process those all at once and there are going to be plenty of times that ppl will think it won't be quick enough. —TheDJ (talk • contribs) 11:07, 3 January 2014 (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]

This sounds complicated to me.

Imagine that I've got a one-way interaction ban, so I'm not supposed to talk to you. You would like to propose that (for example):

If you post a note on my user talk page, that I can talk to you (in that discussion) all I want.
If someone else posts a note on my user talk page about you, then I can talk about you (in that discussion) all I want.
If there is a discussion somewhere about me, and you comment in it, then I can reply to you (in that discussion) all I want.

Do I understand your proposal correctly? WhatamIdoing (talk) 20:00, 30 December 2013 (UTC)[reply]

Are interaction bans even construed that way? I would think that the simple rule would be to treat them like orders of protection. If party A (the beneficiary of the order) interacts with party B (the one constrained), it should work as a waiver of the order within the scope of that interaction on that page, and party B would be permitted to interact within reason in that discussion.

Limitations would be that if it looks like party B is preemptively sticking his head into places where party A could later become involved, this would be constrained. For instance, suppose party A primarily or only edits sexology articles; if party B went and made some trivial response to every single discussion thread on every single sexology article talk page, that should not only prevent the exception from being triggered, but should probably count as an in-spirit breach of the interaction ban. Of course, in most situations this would be hard to figure out; few editors edit solely within one topic area, and few editors are going to intentionally set up a minefield for another editor to evade their interaction ban.

And of course, no party should be restricted from starting or participating in a discussion to impose or lift community restrictions against himself. But this just seems like common sense. Anything I'm missing? —/Mendaliv/^2¢/_Δ's/ 02:51, 2 January 2014 (UTC)[reply]

One-way interaction bans are unusual, but they do exist. They're not necessarily conceptualized as someone being a "beneficiary"; it may be one-way simply because the second person does some routine work that requires contacting the banned person every now and again (e.g., to deliver semi-automated notices of a suspected copyvio).

If the banned person feels he is being needlessly provoked by the non-banned person, then his primary recourse is to request that the ban be converted to a two-way ban. The interaction bans frequently extend to not permitting the banned editor to edit or post comments on talk pages that are being edited by the non-banned editor, so your example would likely count as a violation. WhatamIdoing (talk) 21:30, 2 January 2014 (UTC)[reply]

About Time

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]

A few of your proposals have been made and rejected in the past. Allow me to provide a few helpful links

On the subject of disallowing IP editing: This is a proposal that has been made and rejected by the community a number of times, as IP editors make a large number of useful contributions to the wiki. Additionally, the ability for anybody to edit Wikipedia is a founding principle of the project.
On the subject of submitting edits to the original author: Wikipedia is the encyclopedia that anybody can edit. The creator of an article does not own it; the encyclopedia is a collaborative project.

As for the Wiki markup being confusing, I can sympathize. It can take a while to master the markup, and if you are having trouble figuring it out, you could try a beta feature called VisualEditor. It is a WYSIWYG editor for Wikipedia, which you can enable in the beta section of your preferences. Keep in mind, though, that VE is a beta project, and may have some bugs. I do hope this has been helpful. --Novusuna ^talk 22:33, 30 December 2013 (UTC)[reply]

In addition, the original article author can add the article to their watchlist to monitor any changes. GoingBatty (talk) 23:19, 30 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]

New MassMessage user group here

Hi. There's a new MassMessage user group on the English Wikipedia, following Wikipedia:Village pump (proposals)/Archive 108#Create new user group for m:MassMessage.

User:EdwardsBot/Access list should be transitioned to this user group, but that may be a matter of policy (of which there's none currently, besides "use good judgment"). Thoughts? --MZMcBride (talk) 01:40, 31 December 2013 (UTC)[reply]

Wikipedia:Village pump (proposals)/Archive 108#Questions (MM) clearly says (and I supported based on this) that all users on the existing list, excluding the ones on the talk page that aren't on the actual list yet, would be grandfathered in and not have to reapply. Are you asking if we should ignore the consensus already reached? I'm guessing no, but would like to be clear. Technical 13 (talk) 03:18, 31 December 2013 (UTC)[reply]
- Okay, that's simple enough to implement. I'll post to WP:AN now asking any passing admin to transition the list over. Any thoughts on how to approve new/future requests? --MZMcBride (talk) 16:48, 31 December 2013 (UTC)[reply]
- Posted the request. --MZMcBride (talk) 16:53, 31 December 2013 (UTC)[reply]
- Granted the group to all users who were not already sysops. —TheDJ (talk • contribs) 18:17, 31 December 2013 (UTC)[reply]

As part of describing Massmessage procedure for mass message rights I'd like to point out that the user group currently links to Wikipedia:Massmessage senders, so that might be a place to start :D —TheDJ (talk • contribs) 18:23, 31 December 2013 (UTC)[reply]

Restore vs Restart -- Copyright Question

I am curious about the copyright issues on what happens when an article is deleted for insufficiency and then later comes back to life. Please note these questions are semi-legalistic and I know that only the WMF can give official legal answers but I am looking for a sense of what the WP community feelings are on this matter, especially my last question.

Essentially here is a common scenario of what happens as I understand things:

an article stub is created by an editor.
other editors may or may not work on the stub.
at some point the article/stub and related talk and history pages are deleted for insufficiency (WP:N, CSD:A7, whatever).
later an editor finds the needed sources and decides to resurrect the article.

At this point there are four options:

(A) restore the deleted article pages into the mainspace and add in the new material.
(B) restore and WP:INCUBATE the article pages.
(C) restore and WP:USERFY the article pages.
(C) restart the deleted article as a new article written from scratch.

My questions are as follows:

What happens to the edit history of the first version of the page if the page is restarted (option D above)? Is it overwritten or can it be accessed somehow if needed?
If the first version was created under the WP:CC-BY-SA license and any follow-up work (including a total rewrite) is essentially a derivative product of that work then does the first version of the page history need to be restored in order to keep faith with the Attribution condition of the CCA license?
Per Section 11 of the GFDL v1.3 any article content added to Wikipedia after 1-November-2008 but before 15-July-2009 that work MAY fall exclusively under the GFDL (there are incompatible elements between the two licenses). How can this origination date be determined if the original edit history has been deleted/overwritten (see question #1 above)?
Finally, and most significant to me, is the moral rights of the WP editors of the first version to have their good faith contributions recognized. I personally believe in giving credit where credit is due. If I am inspired by an article to do research and help that article, I like to be sure that the work of all the editors before me is acknowledged. What is the community consensus on this?

F6697^{FORMERLY 66.97.209.215}_TALK 08:53, 2 January 2014 (UTC)[reply]

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

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

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

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

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

Making guideline on signatures into formal policy?

See Wikipedia talk:Signatures#Promotion to policy. DES ^(talk) 23:21, 2 January 2014 (UTC)[reply]

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

🙈🙉🙊 Can't we just ignore it? 😃 Wnt (talk) 05:10, 3 January 2014 (UTC)[reply]

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

add the {{rfc|policy}} tag,
announce the proposal at WP:VPR,
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
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)[reply]