Wikipedia:Village pump (all)

From Wikipedia, the free encyclopedia
Jump to: navigation, search

This is the Village pump (all) page which lists all topics for easy viewing. Go to the village pump to view a list of the Village Pump divisions, or click the edit link above the section you'd like to comment in. To view a list of all recent revisions to this page, click the history link above and follow the on-screen directions.

Click here to purge the server cache of this page (to see recent changes on Village pump subpages)

Village pump sections

To discuss existing and proposed policies

To discuss technical issues. For wiki software bug reports, use Phabricator

Dialog-information on.svg
To discuss new proposals that are not policy-related. See also: perennial proposals and persistent proposals.

Dialog-information on.svgNuvola apps package development.png
Idea lab
To discuss ideas before proposing them to the community and attempt to find solutions to issues

To post messages that do not fit into any other category

View all village pump sections at once

It can only be speculated that, like the modern office water cooler, the village pump must have been a gathering place where dwellers discussed ideas for the improvement of their locale.
Other help and discussion locations
I want... Where to go using Wikipedia Help desk find my way around Wikipedia Department directory
...specific facts (e.g. Who was the first pope?) Reference desk
...constructive criticism from others for a specific article Peer review resolving a specific article edit dispute or making a user conduct dispute complaint  Requests for comment comment on a specific article Article's talk page view other Wikimedia projects Wikimedia Meta-wiki learn about citing Wikipedia in a bibliography Citing Wikipedia report sites that copy Wikipedia content Mirrors and forks ask questions or make comments Questions


Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).


Appending the Manual of Style on gender-neutral language

The present text of the Manual of Style's guidelines on gender-neutral language is as follows:

Use gender-neutral language where this can be done with clarity and precision. This does not apply to direct quotations or the titles of works (The Ascent of Man), which should not be altered, or to wording about one-gender contexts, such as an all-female school (When any student breaks that rule, she loses privileges).

Ships may be referred to using either feminine forms ("she", "her", "hers") or neutral forms ("it", "its"). Either usage is acceptable, but each article should be internally consistent and employ one or the other exclusively. As with all optional styles, articles should not be changed from one style to another unless there is a substantial reason to do so. See WP:Manual of Style/Military history § Pronouns.

The proposed new text is as follows. Bold print indicates a change:

Use gender-neutral language where this can be done with clarity and precision. For example, avoid the generic he and prefer words such as "chair"/"chairperson" or "firefighter" to "chairwoman" and "fireman." This does not apply to direct quotations or the titles of works (The Ascent of Man), which should not be altered, or to wording about one-gender contexts, such as an all-female school (When any student breaks that rule, she loses privileges).

Ships may be referred to using either feminine forms ("she", "her", "hers") or neutral forms ("it", "its"). Either usage is acceptable, but each article should be internally consistent and employ one or the other exclusively. As with all optional styles, articles should not be changed from one style to another unless there is a substantial reason to do so. See WP:Manual of Style/Military history § Pronouns.

An editor at Wikipedia Talk:Manual of Style has proposed this new wording, and it has been introduced here so that the community can comment on whether it should be adopted. RGloucester 21:25, 1 February 2015 (UTC)

Support (GNL)

  • Support – the added example is useful for showing what is meant by preferring gender-neutral language. Dicklyon (talk) 21:45, 1 February 2015 (UTC)
  • Support reference to generic he; other examples negotiable. I only included the "chair" and "firefighter" examples for balance, because they're one of the best and clearest parts of the GNL essay. The reason I suggested changing the text of the MoS is because of confusion regarding whether the MoS already bans the generic he (it does, but there are a few editors who think it doesn't). I see this as a clarification rather than an actual change in MoS rules/guidance/policy/what-the-MoS-does. Darkfrog24 (talk) 01:31, 2 February 2015 (UTC)
I don't think it matters if a few editors hold this view. It's obviously wrong and they are never going to win in a showdown. I wouldn't necessarily oppose just adding this clarification, though. Formerip (talk) 11:02, 2 February 2015 (UTC)
  • Support avoiding the generic he. The rest of the sentence needs work. — (talk) 07:33, 2 February 2015 (UTC)
  • Support An example would be useful because it can better show how thing should be done. It shows how it can be done. People will better know what it is talking about (talk) 18:21, 2 February 2015 (UTC)
  • Support gender neutral pronouns but oppose requiring quasi-neologisms such as chair/person. BethNaught (talk) 19:21, 3 February 2015 (UTC)
  • Support. Without specific examples this instruction is open to interpretation, and there will be arguments whether a certain gender-neutral expression has "clarity and precision". There should even be a more detailed list of examples of GNL, something like this. Per BethNaught the content of this list should be discussed separately, but eventually it should be very easy to know weather an expression is recommended/allowed/discouraged/forbidden by the MoS. WarKosign 11:26, 8 February 2015 (UTC)
  • Support clarification re gender-neutral language, especially that "generic he" is to be avoided, preferably using the text proposed below by Darkfrog24. --Boson (talk) 13:28, 8 February 2015 (UTC)
  • Support. While I think a lot of MoS (such as related to hyphen) is largely a crock of shit, I think that this is genuinely useful giving valid contribution to issues like NPOV. As an aside I would also appreciate comments at Wikipedia talk:WikiProject Religion#Disambiguations of divinities as I think that this is an issue where consistency could be beneficially applied. GregKaye 08:43, 17 February 2015 (UTC)
  • Support. But there does also need to be a source of advice, like the Canadian Government one referenced above. Peter coxhead (talk) 10:30, 17 February 2015 (UTC)

Oppose (GNL)

  • I dont see any reason to add examples to the current wording most people are aware of gnl and adding examples which clearly show a non-neutral point of view that he and man applies just to males where they have been used as gender neutral terms for years if not centuries. The current wording allows discussion and the use of such terms as used by reliable references when needed so I dont see a need to expand it. MilborneOne (talk) 21:40, 1 February 2015 (UTC)
    Comment: The point of view that the "he" implies that all subjects are male did not come from any Wikieditor but from the sources: Oxford Dictionaries [1], the American Heritage Dictionary [2], Purdue [3], [4], the National Council of Teachers of English [5], Chicago Manual of Style [6] and others all describe the generic he as sexist, advise against using it, or both (OED was also consulted and is silent on the matter). It is not inappropriate for the MoS to reflect English as it is. The MoS has held this position for a long time. The current proposal is intended as a clarification, not a change. Darkfrog24 (talk) 04:53, 2 February 2015 (UTC)
  • I think the current wording is clear enough and I don't see what value the examples would add. I also think that the guidance would benefit from more flexibility (if only a little), rather than less, because it says something that it can't possibly mean. Am I really obliged to say "monarch" in place of "king" or "queen" unless it is in a quotation or a title? I doubt anyone would take that idea seriously, but it is what the guideline seems to recommend. What about "actress"? I can't stress enough that we should enforce modern standards with regard to gender-neutral language, but we also ought to recognise that those standards are not actually absolutist. Tricky, though, because if you give them an inch they'll take the piss. Formerip (talk) 23:00, 1 February 2015 (UTC)
    Former, the intention is that if you are writing about a specific person, the gendered term is fine. This is mainly discuss generic uses, if it's any king or queen, or if it's any firefighter. Oiyarbepsy (talk) 23:11, 1 February 2015 (UTC)
    That's not what they guidance says, though, and I doubt that it is what it means. I think the community's intention is that we should use gender-neutral language wherever it is normal and reasonable, including, for example, avoiding terms like "policeman", "Jewess", "lady doctor" and so on, even where they might refer to individuals. Formerip (talk) 00:19, 2 February 2015 (UTC)
    It says "This does not apply to ... wording about one-gender contexts". Usually a specific person has a single gender, so the context is obviously single-gender. WarKosign 11:29, 8 February 2015 (UTC)
  • I agree with the above, I do not see any reason why we need to add examples here. - Knowledgekid87 (talk) 00:24, 2 February 2015 (UTC)
  • The proposed examples are likely to distract from the most important part of the guideline: ...where this can be done with clarity and precision. Without additional context, there is no way to tell whether those choices would provide clarity and precision, or the opposite. Monty845 04:04, 2 February 2015 (UTC)
  • Oppose. On some occasions, the use of the generic "he" is more fluent than the gender-neutral "they" (which is what I would normally use). I agree that, in some contexts, it is now normal to avoid the generic "he" - especially in US English. However, I am not convinced that the requirement to avoid a generic "he" is universal enough to warrant a Wikipedia-wide ban, or whether it is instead something that is essentially a local English variant, based on expectations in that locations, and would therefore be allowed to vary from page to page. Bluap (talk) 14:04, 2 February 2015 (UTC)
  • Oppose per WP:CREEP, WP:NOTLAW and WP:COMMONNAME. Some examples which occur to me are beauty queen and fishwife. Instead of this proposal, can we outlaw bizarre neologisms such as xe, which I see people using? This is supposed to be the English language wikipedia and it's bad enough that we have national variations to deal with. Andrew D. (talk) 17:19, 2 February 2015 (UTC)
    In parts of the United States, teenagers have adopted yo as a gender neutral pronoun. How about we adopt that? Oiyarbepsy (talk) 04:27, 3 February 2015 (UTC)
    No gender-neutral pronoun (other than “it” or “they”) is common enough that its use here would not be confusing, and we would be justifiably accused of using made-up words. — (talk) 19:16, 3 February 2015 (UTC)
  • Oppose per my remarks at the MoS talk page – With rigidity, the MoS is useless. A straitjacket rule, in this case, is completely unworkable. This is especially true when the proposed examples, like "chairperson", are not supported by many RS. Usage of that term is extremely controversial. Sources such as The New York Times forbid it in their articles, and various parliamentarians are opposed to it on principle. In common usage, "chairman" is used for a variety of reasons. There is no reason that Wikipedia should proscribe a usage that is common, nor should it endorse a usage that is inherently controversial. The present wording does what it needs to do, per Monty845, and allows us the flexibility we need to make the MoS work. Usage of titles should be determined through talk page consensus and reliable sources. If someone consistently refers to themselves as an "actress", and if RS do so as well, there is no reason why we should forbid that usage. RGloucester 19:07, 2 February 2015 (UTC)
  • Comment which is probably best suited for this section. In addressing one of the specific examples above, chair/chairperson, there are cases where a woman has explicitly stated a preference for the term "chairman"; see for instance Esther Dyson. The problem I have is that the proposed wording makes no attempt to address these cases, and doing so will inevitably lead to even more verbiage and further convolute an overly complicated guideline on what is a rather insubstantial style point in English usage. The Blade of the Northern Lights (話して下さい) 01:44, 4 February 2015 (UTC)
  • Oppose - if gender issues still prevail in the 21st Century, the problem is bigger than modifying MOS on WP. An attempt to neutralize it here (aka hide it) is what I consider regression, not progression. We are who we are, know what I mean? AtsmeConsult 23:09, 4 February 2015 (UTC)
  • Oppose - I agree with "firefighter", but I don't like when people replace "man" with "person". Man is supposed to be gender neutral. Furthermore, whether you believe so or not, the word mankind is gender neutral. As such, I propose this proposal. Tharthandorf Aquanashi (talk) 22:47, 6 February 2015 (UTC)
    You mean, man should be at man (gender) with man re-directing to human?? Georgia guy (talk) 22:57, 6 February 2015 (UTC)
    I wasn't actually proposing that, but yes that would make sense. However, many would probably argue against in due to common use. Tharthandorf Aquanashi (talk) 23:10, 6 February 2015 (UTC)
  • oppose This is about acknowledging the sacred right to take offense, which I don't. People differ on how to solve the problem of a gendered language, not to mention various people who insist that someone else has to refer to them according to their made-up grammar. It's simply an invitation to edit war drama to put this clause in. Mangoe (talk) 23:30, 10 February 2015 (UTC)
  • Oppose. Too proscriptive. And the examples are poor in any case. Chairman is gender-neutral, except when the PC brigade get involved (see the current discussion at Talk:Chairman), and "fireman" is also perfectly acceptable in an historical context when there were no female firefighters (i.e. most of the history of firefighting). Revisionism is never a good thing. These things should always be considered on a case-by-case basis, not laid down in stone. -- Necrothesp (talk) 17:08, 19 February 2015 (UTC)
  • Oppose This RfC is a bit biased. I support gender-neutral language but not this proposal. There are lot of times when gender-neutral language should be used and lots of times when using gender-neutral language would requiring coining new terms, using unnatural language, and increasing confusion. I would prefer to see a proposal like this develop organically, with complaints raised about individual issues, those issues corrected with gender-neutral language, then over time a policy could be created with the collection of consensus statements which follow fixing real problems. I am not eager to make sweeping statements and generalizations. Off-wiki, I have experience drafting medical documents for the LGBT community and minority genders. I care about this issue, but resolving it is not easy, and there are not strong precedents for establishing best practices. Note that Gender-neutral language is a very poor article, and I would attribute this to the lack of public agreement in academia, public discussion, and what is published. Developing that article would be an excellent start to developing a background for best practices on Wikipedia. Blue Rasberry (talk) 00:28, 21 February 2015 (UTC)
    You say There are lot of times when gender-neutral language should be used and lots of times when using gender-neutral language would requiring coining new terms, using unnatural language, and increasing confusion. Any statement you know where the latter is true?? Please try to do an example where you feel very sure this is true. Georgia guy (talk) 00:36, 21 February 2015 (UTC)
Georgia guy I am very sure this is true in situations where biological sex is discussed, and have come into conflict in situations where people want to avoid discussing biological sex. In public health projects overseeing HIV prevention there is a concept named "Men who have sex with men" ("MSMs"). For about 20 years Trans women have objected to being targeted with health services for MSMs because they identify as women, and yet from a health practice perspective, many health tools and interventions which are appropriate for men work well on trans women but would not work well on persons who were assigned as female at birth. The trans community would like for the public health community to use gender neutral terms in public health outreach or to simply be called "women" along with persons assigned as female from birth, and this community makes requests and demands this often. I see no resolution to this confusion anytime soon. The conflict is that the health practice community would like to group MSMs and trans women, but trans women prefer to identify as women and not trans women, so calling trans women "MSMs" is offensive and calling them "trans women" is not appropriate outside a clinical setting either. Because of limited funding, it is very difficult to make clinics for trans women populations which are separate from gay male cases. Saying "MSMs and women" is the most common demand but then health care providers in these situations are often not ready to process women assigned as female at birth. In cases of medicine and sexuality, especially for people with minority gender or sexual identities, either using gendered terms or gender neutral terms may be more preferable depending on the situation and I would like to avoid making hard rules to keep flexibility for people to make the best choice. I expect that other exceptions will exist in any article which has special attention to sexuality or sexual health. Blue Rasberry (talk) 13:12, 23 February 2015 (UTC)


The RfC is, in my view, premature in this form and the text to be added needs working on. I agree with " avoid the generic he", which I think was always the intended meaning. As regards the other issues, some might think "chair/chairperson" inappropriate while agreeing with the general principle of gender-neutral language, so I would choose a different example. We should also avoid language that might be understood as advocating avoidance of the male term (prefer words such as . . . "firefighter" to "fireman") when actually referring to a person of known sex/social gender, for example "he worked as a fireman", "he was chairman of . . .", "Sandra Bullock is an American actress". I think it would also be useful to mention differences in meaning (e.g. "the first actress to . . ." may not the same person as "the first actor to . . ."). --Boson (talk) 22:22, 1 February 2015 (UTC)

But it is always the same as "the first female actor to..." Georgia guy (talk) 22:31, 1 February 2015 (UTC)
Indeed, and neither "female actor" nor "actress" are gender-neutral. The point is that we should avoid purportedly gender-neutral terms when they are in fact not gender-neutral. This includes especially the so-called "generic he", and it may include terms like "king" or "fireman" when used generically, i.e. in reference to a firefighter or monarch of either (or indeterminate) sex/social gender. I think the RfC in this form is premature, because the proposed text does not make this clear and therefore needs working on. --Boson (talk) 01:06, 2 February 2015 (UTC)
I would suggest that instead of
"For example, avoid the generic he and prefer words such as "chair"/"chairperson" or "firefighter" to "chairwoman" and "fireman."
the proposal should specify something like
"For example, when referring to persons of indeterminate social gender (i.e. who may be of of either, both, or unknown sex or social genders), avoid the use of he, him, etc. ("generic he") and generally avoid the use of generic terms that might be understood to imply a particular sex or social gender
The text still needs tweaking and should include examples where it is obvious that the noun or pronoun is being used "generically".
--Boson (talk) 01:11, 2 February 2015 (UTC)
I like it, Boson, but I don't think we need to say "social gender" or "sex." In this context, the general-use "gender" should be sufficient, if we even need that. Maybe something like "Avoid referring to subjects as he, him, etc. unless it has been established that they are male." It's shorter and it accounts for non-human subjects, like bees. It might also sidestep the whole chess-context problem, which is what raised this issue in the first place Darkfrog24 (talk) 01:43, 2 February 2015 (UTC)
To be clear, "actor" apparently implies someone of male gender, meaning that your proposed guidance says that we cannot use "actor". Instead, I think you should write "prefer usage of masculine-gendered terms over feminine-gendered terms", as that seems to be what you want to do. RGloucester 02:18, 2 February 2015 (UTC)
Actually, there's a growing feeling in the acting community that "actor" should be used as a gender-neutral term, so it seems that "actor" is becoming what "he" used to be. Darkfrog24 (talk) 04:47, 2 February 2015 (UTC)
Therein lies the fallacy of all of your advocacy here and elsewhere. "Gender-neutral" apparently has no fixed meaning. You can determine whatever you think is gender-neutral, and say "this is gender-neutral", despite the fact that it isn't by your own definition of the term. "He" has always had two meanings, one gender-neutral and one masculine. Apparently it is now "no good" because it is "sexist" and can only refer to things of male gender. Somehow, however, the same person says that the word "actor" is now "gender-neutral", despite being a case of the same thing: a word that has both a gender-neutral meaning and a masculine meaning. Therefore, by the logic you are applying to "he", using "actor" is "sexist". This is absolute absurdity, and has no basis in language. It only has basis in politics, and politics have no place in the language. I believe that everyone should disregard all polemics by Mr Frog. His twisting of reality is so absolutely mad that it must derive from some plane of existence that I'm not privy to, despite my own acute madness. RGloucester 05:59, 2 February 2015 (UTC)
RG, that's not a fallacy; that's English. It doesn't always follow fixed patterns. You can go look up the history of the word "actor" and see that it is currently undergoing a shift in meaning and usage. Actresses are slowly starting to say, "Call me an actor; 'actress' implies that my gender is more important than it is," and magazines and newspapers are altering their style guides to accommodate them. They are the ones choosing the gender-neutral term. Similarly, you can look up the generic he and see how it is also undergoing a shift, but it is much further along. Darkfrog24 (talk) 20:07, 2 February 2015 (UTC)
There is no shift. It is imaginary, and in your head, just as is this bizzare application of the term "gender-neutral" to mean anything that someone says is "gender-neutral" regardless of etymology. By that logic, I can say "actress" is gender-neutral, because I don't want to place an emphasis on the maleness of the "actors" (gasp) in question. Therefore, you, Mr Grant, are an actress. How do you plead? RGloucester 22:55, 2 February 2015 (UTC)
Etymology is irrelevant. What matters here is what people today imagine the words to mean. If a word choice—regardless of the entirety of the history of that word—causes a significant number of people to imagine that it’s offensively sexist, then we should avoid it; and if not, it’s acceptably gender-neutral. Also, your spelling of “bizarre” is bizarre. — (talk) 07:28, 3 February 2015 (UTC)

I feel newcomers to this conversation should be advised of this: This text was proposed because of confusion/disagreement over whether the MoS ALREADY tells Wikieditors not to use the generic he. So if you write "oppose," it would be helpful if you specified whether you're opposed because 1) you think the MoS's position against the generic he is already clear enough or 2) you think it should not ban the generic he, in which case you should probably suggest new text that explicitly allows it. Darkfrog24 (talk) 01:38, 2 February 2015 (UTC)

I agree with the spirit of the added text—avoid potential unintended sexism—but I also agree with some of the concerns posted by others here that it’s a bit too open to hypercorrection. If a less restrictive alternative can be proposed, one that allows for common sense without too much instruction creep, I’ll support that. — (talk) 07:22, 2 February 2015 (UTC)

Alternate proposal… how about:

Use gender-neutral language (for instance, avoid the generic he) where this can be done with clarity and precision. This does not apply to direct quotations or the titles of works (The Ascent of Man), which should not be altered, or to wording about one-gender contexts, such as an all-female school (When any student breaks that rule, she loses privileges).

The rest stays the same. — (talk) 13:12, 2 February 2015 (UTC)

I like it, but I'd put the "avoid the generic he" after the "clarity and precision" part. The order you've used implies "where ... precision" applies to avoiding the generic he rather than to using gender-neutral language:

Use gender-neutral language where this can be done with clarity and precision. (For example, avoid the generic he). This does not apply to direct quotations or the titles of works (The Ascent of Man), which should not be altered, or to wording about one-gender contexts, such as an all-female school (When any student breaks that rule, she loses privileges).

We could probably keep the "firefighter" example but from the comments above, "chair" is probably not best. Darkfrog24 (talk) 20:07, 2 February 2015 (UTC)

Yes, of course it applies to the given example of GNL, as it should to any example. Your version seems to imply that “avoid the generic he” is an example of where GNL can be used “with clarity and precision.” I disagree with this. Avoiding that use of the word is an example of GNL, but not necessarily an example of where it’s suitable. Consider the following:
  • You can eat whatever you want (even double chocolate fudge brownies and a huge slice of Oreo ice cream cake) as long as you don’t overeat.
  • You can eat whatever you want as long as you don’t overeat. For instance, eat double chocolate fudge brownies and a huge slice of Oreo ice cream cake.
In the first line, the example is restricted by the condition (as it should be). In the second, the example is ludicrously implied to satisfy the condition. — (talk) 23:21, 4 February 2015 (UTC)
It seems that both cases of confusion can be avoided easily:

Use gender-neutral language where this can be done with clarity and precision. Avoid the generic he. If a gender-neutral term is standard and widely understood, prefer it to its gendered counterpart. For example, prefer "firefighter" to "fireman." This does not apply to direct quotations or the titles of works (The Ascent of Man), which should not be altered, or to wording about one-gender contexts, such as an all-female school (When any student breaks that rule, she loses privileges).

No "for example," no problem. I've also reworked the firefighter example. Darkfrog24 (talk) 01:50, 5 February 2015 (UTC)
And if the generic “he” cannot be avoided while maintaining clarity and precision? It should not be outright banned; it should be discouraged, avoided when reasonable. That’s what the existing text says. Maybe I’ve just looked at this too much and I’m not taking the paragraph as a whole… anyone else have an opinion on this last version? I do like and agree with the rest of the modifications, though. — (talk)
That's why we're saying "avoid" instead of "don't use." Darkfrog24 (talk) 20:20, 6 February 2015 (UTC)
That sounds OK to me. --Boson (talk) 13:25, 8 February 2015 (UTC)
Now that I think of it, Anon174's concerns might be better addressed with "Avoid the generic he unless there is no clear and correct alternative" or something. That might not stop people from inserting it, but it would probably stop them from undoing other people's edits when they change it to plural or "he or she." Darkfrog24 (talk) 22:40, 8 February 2015 (UTC)

Use gender-neutral language where this can be done with clarity and precision. Avoid the generic he unless there is no clear and correct alternative. If a gender-neutral term is standard and widely understood, prefer it to its gendered counterpart; for example, prefer "firefighter" to "fireman." This does not apply to direct quotations or the titles of works (The Ascent of Man), which should not be altered, or to wording about one-gender contexts, such as an all-female school (When any student breaks that rule, she loses privileges).

I like it. — (talk) 07:16, 9 February 2015 (UTC)
Sounds good, but too specific. Generic "he" is a single word, there are many others to argue about. How about "man" used to mean "human" ? Is singular they recommended/acceptable/discouraged/forbidden ?WarKosign 13:20, 11 February 2015 (UTC)
"Gender-neutral language" in general covers the use of "man" to mean "human." Generally, this conversation started as a way of showing that the basics in the essay on GNL were endorsed by WP:MoS. Copying the whole essay would be impractical, and the generic he seems like a good example (though "chairman" has shown itself not to be). Got any thoughts?
The singular they has been up for discussion many times. It is currently neither endorsed nor banned. Darkfrog24 (talk) 01:42, 12 February 2015 (UTC)
The word "man" is gender neutral, and hence not proscribed by the present guidelines. RGloucester 06:20, 12 February 2015 (UTC)
Yo, check the date in your signature! It's not 1950 any more. Johnuniq (talk) 06:27, 12 February 2015 (UTC)
Those that too quickly declare propriety outmoded will suffer a fate of timeless decay. RGloucester 14:44, 12 February 2015 (UTC)
You’re silly. — (talk) 18:38, 12 February 2015 (UTC)

GNL in the MoS: Clarification regarding guidance on the generic he

We should probably get to the real issue before we change the text of the MoS. People opposing the new text here and at WT:MOS are split between "Don't change the text of the MoS because it is already perfectly clear that the MoS tells users to avoid the generic he" and "Don't change the text of the MoS because changing the MoS so that it tells users to avoid the generic he would be bad." (The "chairman" example was only ever here for balance.) The MoS, in its current form, leaves users divided regarding whether the generic he is already against guidance or not. Please answer with one of the following or equivalent (so long as you are clear about what you want to do and why):

Change the text to tell users to avoid the generic he. (A) This is merely a clarification of what the MoS already says. (B) This is a change in guidance.
Change the text to specifically allow the generic he. (C) This is merely a clarification of what the MoS already says. (D) This is a change in guidance.
Do not change the text. (E) The MoS does not tell users to avoid the generic he, and it shouldn't. (F) The MoS already tells users to avoid the generic he, and it should. (G) Other.

We can talk about examples like "chair" and "firefighter" too but the non-hypothetical problem concerns the generic he. 22:30, 8 February 2015 (UTC)

Responses (generic he)

Avoid (A) The MoS has banned the generic he for a long time, as indicated by its statement about gender-neutral language and its link to the essay on gender-neutral language, which mentions the generic he specifically. Because there is visible confusion about that, the text should be made clearer. I like the firefighter example, which was lifted from the same essay. Most dictionaries and style guides describe the generic he as sexist, tell writers not to use it, or both [7] [8] [9] [10] [11]. The MoS should follow sources. Darkfrog24 (talk) 22:30, 8 February 2015 (UTC)

Avoid A: Using gender-neutral language means avoiding the generic “he” (a word choice that is decidedly not gender-neutral). The MOS presently says, “Use gender-neutral language where this can be done with clarity and precision.” This means, among other things, we are to avoid the generic “he” where this can be done with clarity and precision. — (talk) 02:45, 9 February 2015 (UTC)

No change – "He" is a gender neutral pronoun, much like the word "man" is a gender neutral noun. RGloucester 03:10, 9 February 2015 (UTC)

So, reason E then? — (talk) 07:13, 9 February 2015 (UTC)
I shan't be forced to submit myself to the reasons provided by the oppressor. RGloucester 15:20, 9 February 2015 (UTC)
I’ll… take that as a very confusing yes. — (talk) 03:27, 10 February 2015 (UTC)
  • G - none of the above. We have no consensus on whether the generic "he" in neutral or not, and thus we can not write any firm policy statement about it. I would actually take this a step further... We should either change the entire section to note that there is disagreement about the necessity for gender neutrality, or simply cut the section entirely and say nothing about gender neutrality. Blueboar (talk) 05:01, 10 February 2015 (UTC)
    • Agreed—if there’s disagreement about something in the MOS, the MOS should say there’s disagreement. I do think the section belongs in there regardless, though. And the matter warrants further discussion outside of a polling context. — (talk) 05:19, 10 February 2015 (UTC)
It only looks like we have no consensus because of the way RG wrote the first of these two village pump RfC. Most of the "oppose" votes refer to the chair/chairman example and not to the generic he. Most of the participants in the conversation at WT:MoS were in agreement that the MoS already bans/disprefers/what-the-MoS-does the generic he and has for a long time. You said so yourself at one point. Removing the ban would be a change in policy.
As for consensus among sources, that is very clear: they are in agreement that the generic he is sexist and should not be used in modern contexts. Darkfrog24 (talk) 21:43, 10 February 2015 (UTC)
My view that there is no consensus is not based on this specific RFC alone. I question whether the community has ever had a true consensus on the issue of gender neutrality. If you look at the history of the section, it was first added in the wake of the great Bradley/Chelsey Manning debate... and there was a lot of POV pushing going on... on both sides of the debate. The section was did not have a proper consensus then, and it still does not have a proper consensus. Since it was first added (approximately a year ago), objections (or at least serious concerns) about it have been raised, and these have not been addressed. So... yes... what I am suggesting is that we change the policy to eliminate the "ban"... because the underlying rational behind the "ban" (that there is a need for gender neutrality in the first place) never had consensus to begin with. Blueboar (talk) 14:29, 11 February 2015 (UTC)
Why then was it allowed to stay at all, treated as if it had consensus behind it? It’s been my understanding that if there’s no consensus about whether a new addition should remain or be reverted, it’s ultimately reverted. Or was there consensus only at that point in time? — (talk) 19:21, 11 February 2015 (UTC)
While I disagree with Blueboar about whether the MoS should require GNL, I can answer your question, Anon174: It is usually hard to change the MoS if anyone's feelings or personal beliefs are involved, and lots of people have personal beliefs about gender and politically correct speech. Even if you can cite a hundred sources supporting your position, people have their opinions and don't like to change them. Let's assume for the sake of explanation that Blueboar is right and the passage on GNL got into the MoS by mistake (it wouldn't be the only time something like that has happened). Even then, if there's no consensus to make a change, then the section on GNL will stay in, regardless of why it got there in the first place because the rules prefer the status quo (which would not include the new text mentioning the generic he). Darkfrog24 (talk) 23:25, 12 February 2015 (UTC)
Wouldn’t the status quo be how it was before some new text got in by mistake? Otherwise, that just seems… broken, if rules can be dictated by the good timing of a bad edit. But I’m straying from the topic of GNL to a general question about consensus, I suppose (and I’m of the opinion that GNL does tend to be favored in WP). — (talk) 07:03, 13 February 2015 (UTC)
No. The status quo is how things are right before a new change is proposed (or boldly made and contested). This is an old change. Even if GNL got in there by mistake, it's been in there for years, so it's the status quo. I agree that this way of doing things could be improved upon, and if you hear about a discussion to change this part of how Wikipedia works, let me know. Darkfrog24 (talk) 00:34, 14 February 2015 (UTC)

NO CHANGE (G), we could use "he" to refer to a male, however, we can still avoid "he" when referring to a female person who, for example is a chairwoman. In that case we can use the title "chair", as opposed to chairwoman or chairman. — Preceding unsigned comment added by (talkcontribs) 22:02, 10 February 2015 (UTC) The MoS passage on GNL says "This does not apply to ... wording about one-gender contexts, such as an all-female school (When any student breaks that rule, she loses privileges)" and no one has expressed any wish to remove that sentence. In this way, the MoS already says to use "he" to refer to men. The proposal refers to whether the text of the MoS should be changed to specifically address the generic he (either expressly allowing it or expressly not allowing it). Does this satisfy your concerns? Darkfrog24 (talk) 22:09, 10 February 2015 (UTC)
I think it does satisfy my concerns. Thanks. (talk) 22:25, 10 February 2015 (UTC) I recommend giving this a read: Generic he. That’s the “he” we’re talking about, not the one used to refer to a given individual. The question is whether we should permit the use of “he” when the person (or the person’s gender) is unknown. — (talk) 08:55, 11 February 2015 (UTC)
The link you provided leads to a non-existent page, which is why it is red. Anyhow, in regards to the question, I would not recommend using the generic "he" when referring to on unknown person (or if the person's gender is unknown) because it still sounds like "he" is referring to a male. (talk) 17:09, 11 February 2015 (UTC)
Whoops, accidentally included formatting in the link name. Sorry, fixed that. And what you say is exactly the rationale for having the MOS discourage such usage. — (talk) 19:13, 11 February 2015 (UTC)
Yep. Anyway, If it is exhibiting a strong feeling, I would still be cool with allowing the generic pronoun such as "man" be used in quotes or sentences such as:
   "All men are created equal."
   "That's one small step for [a] man, one giant leap for mankind."
   "Man cannot live by bread alone."
Using the generic he is grammatically correct per se, according to Generic he, but it may be confusing to readers when used in the normal sense, although, I can't seem to think of any examples of how these three sentences would be using in the normal, ordinary sense. So, I would strongly recommend exercising some judgement on when to use the generic "he" or "man". Hopefully, I explained it clearly. (talk) 00:56, 12 February 2015 (UTC)
Actually I'm still a little confused about where you stand. Do you think we should change the MoS so that it allows the generic he, change it so that it doesn't allow the generic he or leave it in its current form (which people have been interpreting in opposite ways)? Darkfrog24 (talk) 23:25, 12 February 2015 (UTC)
@Darkfrog24: I think we should change it so that it doesn't allow the generic he, except under certain conditions, like a direct quote. (talk) 01:23, 19 February 2015 (UTC)
To avoid confusion, would you mind amending your initial NO CHANGE response here? (You can do so by <del>striking it out</del> and then <ins>adding your present position</ins>.) — (talk) 05:29, 19 February 2015 (UTC)
Sure thing, I struck it out and my present position is that we should change it so that it doesn't allow the generic he, except under certain conditions, like a direct quote. (talk) 16:23, 19 February 2015 (UTC)
I vote this too. "we should change it so that it doesn't allow the generic he, except under certain conditions, like a direct quote" I'd also like to add that I think that it applies to certain image and graphic use as well. EX: the representative scientists all look like men. And I may as well add this, I am currently involved in a discussion about the use of this non-gender neutral graph, and looking-for the best avenue to complain about it since it is used on several current articles and I'm hoping that it can be modified to conform to the MOS standard.2601:C:67C0:F8:35B5:3331:DAB7:A60E (talk) 04:31, 20 February 2015 (UTC) ADD link to Talk Page graph discussion 2601:C:67C0:F8:35B5:3331:DAB7:A60E (talk) 04:34, 20 February 2015 (UTC)
I agree with you after looking at the picture you presented. It shows that all the representative scientists look like men, which in my judgement would be an exception to this. (talk) 04:55, 24 February 2015 (UTC)
  • Avoid A: To me it is quite obvious that this was always the intended meaning but, since some editors appear to understand it differently, we should make it crystal clear. --Boson (talk) 16:56, 23 February 2015 (UTC)
  • Avoid A: This is basic modern English, already the norm in education, law, business, etc. I cannot think of an instance when "he" would be required where a person's gender is unknown. Anyone who insists on masculine gender language because that's the old default, or worse, gender-aware language that sprinkles in a few feminine pronouns for a semblance of gender sensitivity, needs to go back to the English garage for a language tuneup. - Wikidemon (talk) 09:13, 26 February 2015 (UTC)

cite foreign language

Is there any formal guidance for citing a forgein language in English Wikipedia? Particularly for citing Chinese which most of English can't read. As Jinyu Qin Society had been nominated for deletion due to having few English sources, how could editors avoid the potential nominatiomn for deletion when they write a Chinese article which has few or even no English sources, though they do have enough sources in its original language?--淺藍雪 22:02, 17 February 2015 (UTC)

English sources are preferable, but if they can not be found or do not address the subject fully, forein language sources are perfectly fine. They obviously need to be reliable.--Ymblanter (talk) 22:04, 17 February 2015 (UTC)
  • See Wikipedia:Verifiability#Non-English_sources for more guidance. --Jayron32 04:06, 18 February 2015 (UTC)
    • it says 'a translation into English should always accompany the quote', does this mean you need to provide both english and orginal title? anyone know a good example?--淺藍雪 20:57, 18 February 2015 (UTC)
      • The advice about translations is about literal quotations of foreign text in an article, not about the bibliographical details of a citation such as a work's title etc., if that's what you mean. However, providing a translation of a foreign title as part of a citation may also be a good idea, as a courtesy to the reader. Just put the English translation in square brackets after the actual title. Fut.Perf. 21:46, 18 February 2015 (UTC)
        • If you're using the various citation templates, like {{cite journal}}, they have parameters to hold a translated title. They also have |language= to indicate the original language of the source as well. Imzadi 1979  19:36, 19 February 2015 (UTC)
      • Also keep in mind machine translation, via Bablefish & Bing translator, will make the inclusion of a foreign language source useful. However (1) some languages I'd expect to see (e.g. Latin) are not supported, & (2) the quality of the translation varies greatly. (Using Bing translator, I've gotten within 80% of what I wanted with French -> English, but not better than 60% with German.) -- llywrch (talk) 16:56, 25 February 2015 (UTC)
  • I think that if more articles were taken from non-English wikipedias into the English one, you would see a significant increase in the prevalence of non-English sources. --User:Ceyockey (talk to me) 01:02, 19 February 2015 (UTC)

Encourage use of "watcher" in place of "stalker" on talk pages

This idea stems from a discussion at the harassment policy regarding the possibly offensive use of "stalk", "stalking", "stalker" when talking about people on Wikipedia. It was decided several years ago to mark the WP:STALK shortcut historical due to the potential for offending users, and since the change there has been a note there advising editors that it should not be used.

Many of you who have edited user talk pages in the past have seen the {{talk page stalker}} template used as a neutral indicator that a comment is not from the owner of the talk page but from someone else who watches the page. The template links to Wikipedia:Talk page stalker which explains the template's use, and there are several related templates and userboxes floating around the project for this purpose. Recently, User:NeilN created a new template {{talk page watcher}} to allow the use of a similar template without needing to use the terminology that some users find offensive (and others have stated they find confusing). That template has been nominated for deletiondiscussion and that seems to be resulting in a snowball keep, with several commenters saying they prefer the new template over the old. That indicates to me that there is consensus to adopt this change (stalker -> watcher) across the project, and I would like to test that here.

I propose that in the project-side context of an editor who participates in discussions on other users' talk pages ([formerly] a "talk page stalker"), "watcher" should replace or be preferred to "stalker" in any place it occurs on the project.

This proposal includes:

This proposal does not include changes to the existing {{talk page stalker}} template such as changing its wording or redirecting it to the new template - it is transcluded nearly 10,000 times and changes to it will break things. Some users will want to continue using those templates or won't know about this change - they should be discouraged but not forcibly prevented from using it.

Cheerfully submitted; Ivanvector (talk) 21:47, 25 February 2015 (UTC)

  • (watching) Support - NQ (talk) 22:45, 25 February 2015 (UTC)
  • Weak support. Providing that both terms can be used at editors discretion, as appears to be the case. However see my comment downthread suggesting Talk Page Helper Irondome (talk) 22:50, 25 February 2015 (UTC)
  • Support Seems perfectly sensible. Sam Walton (talk) 22:53, 25 February 2015 (UTC)
  • Oppose This is like trying to rename notability again. I don't see why we should get rid of this terminology, provided that a less potentially-offensive template is available for situations (newbies or otherwise) where it would be inappropriate - it was for this reason I !voted keep at the TfD. It's only a humour page, and changing this would detract from that. BethNaught (talk) 22:56, 25 February 2015 (UTC)
    • There's no "getting rid" of any terminology, just encouraging a less ambiguous usage. Sam Walton (talk) 23:15, 25 February 2015 (UTC)

Comment It was my understanding of the above that the essay (which is great) will still stand? After it does say "sometimes termed "watcher".." in the essay. Im hoping that can be left untouched, maybe a few tweaks to the banner headline? My vote depends on this and the level of "encouragement" to switch. I hope this is not PC related stuff.. Irondome (talk) 23:03, 25 February 2015 (UTC)

  • Oppose I dont have a problem with an alternate template if users want to use it, but it should point to Wikipedia:Talk page stalker rather than creating a parallel universe. The TPS page makes it clear about the use of the term and I see no reason to make any changes. MilborneOne (talk) 23:07, 25 February 2015 (UTC)
User:MilborneOne, the proposal would be to rename talk page stalker to talk page watcher. There would be no parallel universe, just the same one with a slightly different name. Oiyarbepsy (talk) 00:35, 26 February 2015 (UTC)
Happy to for watcher template to link to stalker but I dont see any reason to rename anything. MilborneOne (talk) 20:56, 26 February 2015 (UTC)
  • Ehhhhh... - Stalking is bad (m'kay?), but each way of fixing this I can see leaves something broken. The "other related changes that may be required" would have also been better left implied under WP:COMMONSENSE, since having it explicitly stated could be misconstrued as a borderline carte blanche. Ian.thomson (talk) 23:41, 25 February 2015 (UTC)
Allow me to explicitly state here that carte blanche was and is not my intent. I simply thought I would probably miss something if I tried to list every change that would be necessary. Of course common sense is implied. Sorry for the confusion. Ivanvector (talk) 02:11, 26 February 2015 (UTC)
  • Support {{talk page stalker}} can be misleading and confusing. Users could misinterpret that as offensive. (talk) 23:43, 25 February 2015 (UTC)
  • Oppose Wikipedia cant please everyone, "watcher" is too broad in meaning. - Knowledgekid87 (talk) 23:52, 25 February 2015 (UTC)
  • Regarding the essay (replying to several comments above): to be clear, the intent is to keep but modify Wikipedia:Talk page stalker by seriously downplaying the use of "talk page stalker" on that page, but not removing it completely because people are obviously used to it, and hopefully not changing the meaning of the essay. The idea is not to cluebat users into enforcing the change; regarding the "level of encouragement", the idea is limited to creating a sort of "new normal" by making changes to the essay. To that end I've created a draft of what it could look like; please have a look at User:Ivanvector/Talk page watcher. I think I've done a decent job of downplaying "stalker" while maintaining the jaguar analogy, and I think this fits in better with the theme of our other "wikifauna" pages (like WP:WikiGryphon, WP:WikiOgre, WP:WikiGnome, etc).
As for redirecting {{talk page watcher}}, if no changes are made to the essay then redirecting there defeats the purpose of eliminating the reference to "stalking" in the template. If there is no consensus to modify the essay, I would prefer if the watcher template redirected somewhere else, like Help:Watching pages, or a new essay for this purpose.
And regarding political correctness, yes this is a form of that. There are users here (new and established) who have experienced criminal stalking online and in real life, and who find the idea of people "stalking" their user spaces hostile and intimidating. We should be sensitive to that, and it's not difficult for us to be sensitive to that by making this change. There are other users who simply find "talk page stalking" confusing, and this also helps that. Ivanvector (talk) 02:08, 26 February 2015 (UTC)
  • As I recall, the "TPW" template was actually created at either my request, or the request of Durova; while she and I disagreed on many things, we both agreed that the "stalker" terminology was inappropriate, intimidating, and a few other descriptors that I'll leave out. Stalking is a serious thing, and concerns about personal safety and internet stalking have often been cited as reasons that women or people with a personal history of being stalked do not participate on Wikipedia. The use of the term "talk page stalker" is just one more example of the systemic biases found on this project. Risker (talk) 02:38, 26 February 2015 (UTC)
But one can choose to be a stalker if one wishes, is that correct? Irondome (talk) 02:56, 26 February 2015 (UTC)
Irondome, I don't know if you intended it that way, but that has to be one of the creepiest things anyone has ever said to me on Wikipedia. Why in heaven's name would I wish to be a stalker? I've just finished saying that stalking is a serious and potentially frightening thing. Risker (talk) 03:15, 26 February 2015 (UTC)
I meant the traditional usage of the term as is used on WP, obviously. Irondome (talk) 03:18, 26 February 2015 (UTC)
Thank you for proving my point. It's incredibly creepy to suggest to someone who points out the offensiveness of the term "stalker" that they could be a stalker if they wanted. Risker (talk) 03:53, 26 February 2015 (UTC)
I have proved nothing. I merely wished clarification that if some users wish to use the old WP terminology, they would be allowed to. I am beginning to be irritated by your usage of the term "creepy". This dialogue appears to be saying more about your mindset than mine, which is merely in the spirit of inquiry. Let us get this straight at this point so we can have a constructive discourse. Regards Irondome (talk) 04:02, 26 February 2015 (UTC)
That isn't what you asked, Irondome; you personalized the question to me. There are neutral third-person pronouns that are standard usage for questions that are not intended for a specific individual. As to language, it evolves. This project long ago deprecated the term "wikistalking" because of the very negative connotations attached to the term "stalking". Terms to describe black people that were commonly used and accepted for generations today would practically brand the speaker/writer as a racist. I think we should all be getting past that. Sorry you don't like the word creepy; I'm using fairly mild descriptors here, but if you'd like we could try "threatening" or "menacing" or "sinister". Risker (talk) 04:13, 26 February 2015 (UTC)
No I did not. This may be a transatlantic language issue. "You" in UK English often means "one", as in "so you can use an Oystercard at weekends" (forgive the inane example). It was not aimed at you specifically. Please grasp that.Irondome (talk) 04:21, 26 February 2015 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────@Irondome, Risker: I am not proposing changing the {{talk page stalker}} template. It is used frequently and has been used many times in the past; removing it or changing its wording would be needlessly disruptive and could make many old conversations lose their meanings. I would support eventually marking it historical along the lines of WP:STALK in the spirit of this proposal (but never deleting it), but I think that is very unlikely to gain consensus at this time, and should be a future discussion. So yes, you would be allowed to use it. Ivanvector (talk) 14:57, 26 February 2015 (UTC)

That's how I interpreted your proposal, Ivanvector; while I believe the usage should be deprecated, I don't think it is necessary to go through and eradicate the historic uses any more than we eradicated the use of the term 'wikistalker' those many years ago. The continued use of such templates and terminology will become progressively less socially acceptable, as is the norm for archaic language. Risker (talk) 15:21, 26 February 2015 (UTC)
@Risker: The TPW template was actually created by me a couple days ago based on Template_talk:Talk_page_stalker. I don't think there's any community consensus to stop using TPS entirely but if there was, it should be fairly easy to get a bot to subst all the occurrences of tps (keeping the original wording) and then deactivating the template. --NeilN talk to me 18:46, 26 February 2015 (UTC)
@NeilN:, this "Talk Page Watcher" template has been on my talk page since 2008. Risker (talk) 18:56, 26 February 2015 (UTC)
Ah, I thought you were referring to the {{tpw}} template. --NeilN talk to me 19:02, 26 February 2015 (UTC)
  • Support. Agree with Risker that "stalker" is likely to be needlessly inflammatory to a non-trivial subset of our readers / editors. In the real world, stalking is no joke, and we don't need to trivialize the real world problem by using the same terminology in a benign context. I fully support efforts to deemphasize the term "stalker" and emphasize other terminology such as "talk page watcher". If individuals want to continue to refer to "stalkers" / "stalking", then that is on them, but in terms of the community's documentation and recommended templates, we can strive to be more inclusive. Dragons flight (talk) 03:05, 26 February 2015 (UTC)
Do we have direct evidence that there is a direct correlation between the use of the term "stalking" on WP and editor recruitment and/or retention? Irondome (talk) 03:13, 26 February 2015 (UTC)
  • Oppose. Most users of reasonable intelligence should be able to see the joke in the old template. We should remove every bit of humour on this site just because some hypothetical person might misconstrue this VERY common use of the term (how often do people talk about FB stalking?). We can't and shouldn't try to please everyone and we can't help it if some people are so literal and thin-skinned they'll get offended. Sir William Matthew Flinders Petrie | Say Shalom! 7 Adar 5775 03:46, 26 February 2015 (UTC)
Umm. When people talk about Facebook stalking, they usually mean it in a very creepy way as in "I was Facebook stalking my ex-girlfriend" or "My ex-boyfriend has been stalking me all over Facebook". It may have been a joking term at one point, but the world has long since moved on and recognized the problems with internet stalking behaviour. Risker (talk) 03:53, 26 February 2015 (UTC)
Never heard it like that amongst New York, DC, or London, 20-somethings or teens. They always use it in the joking sense (which alway sounds weird to me and I never say it, but I understand what they're referring to). They talk about actual stalkers in a much different manner and unfortunately, many people I know have actual stalkers. Sir William Matthew Flinders Petrie | Say Shalom! 7 Adar 5775 15:10, 26 February 2015 (UTC)
What you say is true, Risker, but in the context of Wikipedia we have different terms, wikihounding, harassment and others, for that meaning. A "talk page stalker" isn't generally a stalker, and Wikipedians are aware of that. But this is why I support using either template, because of differing situations eg with newbies. BethNaught (talk) 15:29, 26 February 2015 (UTC)
BethNaught, the deprecation of the term "wikistalking" took place in 2007-08, specifically because it was a serious misuse of the term 'stalking'. One of the responses was for people who just really enjoy thumbing their noses at others to create the "talk page stalker" meme. It had little traction at first, but then people who didn't realise the history of having worked hard to normalize the definition of stalking on Wikipedia started seeing those cute little templates and thinking they were cool. And now Wikipedia has once again decontextualized a term that, to anyone outside of our little project, is pretty scary stuff. Stalking is not a good thing, and the same people who seem to proudly go around saying they're talk page stalkers would never want to associate themselves with other negative statements...for example, rapists, murderers, spousal abusers, revenge porn publishers... Risker (talk) 18:56, 26 February 2015 (UTC)
  • Support only the original proposal. Oppose any PC-deletion of {{talk page stalker}}. Briefly checking "What links here" for the template, it seems to be used most often between experienced editors, where such a misunderstanding about its intended meaning is very unlikely and the humour aspect should be clear enough. GermanJoe (talk) 05:37, 26 February 2015 (UTC)
  • Support in the name of clear communication, of saying what we mean using existing English. Users should not be required to learn alternate definitions of emotionally loaded words to function in this environment. Besides, the use of "stalker" to mean something innocuous makes light of a very serious issue. Some subjects are not suitable for wordplay. (I'm generally opposed to PC, but for me that doesn't mean a black-and-white rejection of all sensitivity to the effect of words. That's the proper domain of stand-up comics, not Wikipedia.) As for precisely what I'm supporting, my preference would be complete elimination, but I support any step in that direction. ―Mandruss  06:25, 26 February 2015 (UTC)
  • Support. The lede of our own article on Stalking says: "Stalking is unwanted or obsessive attention by an individual or group toward another person. Stalking behaviors are related to harassment and intimidation and may include following the victim in person or monitoring them. The word stalking is used, with some differing meanings, in psychology and psychiatry and also in some legal jurisdictions as a term for a criminal offense." If someone were to tell you in any other fora, "I'm stalking you", or were to tell another person that they were stalking you, this would be considered threatening and would be grounds to go to court and get a restraining order. If someone were to post on your Wikipedia talk page (either to you or in response to another editor there) that they were stalking you, you could go straight to court with a printout of the page and say, "see, your Honor, they admit to stalking me right there". We should avoid pushing our editors to use terminology that could potentially put them in legal jeopardy. bd2412 T 18:01, 26 February 2015 (UTC)
  • I'm sure there is some MeatballWiki explanation for this phenomena, but it seems that as Wikipedia grows it is losing its sense of humor in an attempt to please everyone (which is difficult given the realistic interpretation of that statement). Which makes sense, but is disappointing all the same. I'd oppose this change, but I fear that it will ultimately, whether in this instance or another, be changed. To be clear, if you are the victim of honest and genuine stalking, please contact the authorities. If you are the recipient of a TPS template on your talk page, please do not contact the authorities. Killiondude (talk) 18:10, 26 February 2015 (UTC)
  • Support - To say that one is "stalking" another is an overtly hostile description of an activity, one that does not really convey the benign sense of what "your page happens to be on my watchlist, so I'm commenting here" is meant by the use of this template. Tarc (talk) 18:11, 26 February 2015 (UTC)
  • Oppose - This comes across as a Liberal guilt kind of change. Users self-brand themselves as talk page stalkers, and the connotation being imposed on the term here simply does not apply. Keep both templates and allow users to choose what they will. - Floydian τ ¢ 19:01, 26 February 2015 (UTC)
This proposal is actually for keeping both templates, so users will still be able to choose either one as they wish. Ivanvector (talk) 19:52, 26 February 2015 (UTC)
  • Support Partly because the previous oppose makes no sense, but really because naming it 'talk page watcher' is perfectly fine, as that's what it is about and the rest of the opposition seems to be based on the poor reasoning, 'we have to do it this way because, we have done it this way' Alanscottwalker (talk) 19:26, 26 February 2015 (UTC)
  • Support Supposed to neutral aren't? Well "watcher" is quite plainly more neutral than "stalker". Leaky Caldron 20:00, 26 February 2015 (UTC)
  • Weak support My impression is that someone would describe him/herself as a "talk page stalker" to acknowledge the discomfort in a situation where a message would likely begin, "I hope you don't mind that I've been reading your talk page for some time now, but..." And when Wikipedia was a smaller place -- or at least hadn't suffered the chronic turnover it appears to experience in recent years -- & volunteers knew each other well enough to sense when someone might be joking, calling oneself a "talk page stalker" didn't have such a negative implication. (Sheesh, from a few threads I've read recently, there might be seriously creepy people amongst the established editors, & using the word "stalking" might be more accurate than some people may suspect.) Although I'm supporting the deprecation of the phrase "talk page stalker", I do so reluctantly because I'd prefer to not acknowledge that Wikipedia has changed in this way. -- llywrch (talk) 23:02, 26 February 2015 (UTC)
    • A good point. If we use "stalker" for this purpose, what word would we use for the real thing? And how confusing would that be? And it's true that madness exists in the world, even (especially?) here at good ole Wikipedia. ―Mandruss  00:10, 27 February 2015 (UTC)
  • Oppose plain and simple WP:BIKESHEDing and a rose by any other name is still a rose. We're talking about people who stalk talk pages, not people who stalk users which should be directly reported via WP:911. — {{U|Technical 13}} (etc) 00:16, 27 February 2015 (UTC)
  • Comment Please note that users are confused by the terminology regardless of the debate over the appropriateness of the word stalker: here and here for example. Sam Walton (talk) 00:23, 27 February 2015 (UTC)
  • Support People can say "talk page stalker" all they want—no human rights are being infringed by this proposal. It's great that so many people have not been touched by stalking in real life, and so have no idea how creepy the term has become in the last decade, but the fact is that stalking really is a problem. I would favor deleting the pointless {{tps}} and {{tpw}} templates because they do nothing except add confusion for new users (who are the only people who need to see what the templates display). A newbie posts on someone's talk, and the response starts with gobbledygook with a link that has nothing to do with what is on the newbie's mind—how is that helpful? However, if the templates are used, "watcher" is the preferred term because it has no RL baggage, and correlates nicely with the "watch" link at the top of every page. Johnuniq (talk) 01:18, 27 February 2015 (UTC)
  • Comment I would therefore propose the term Talk Page Helper. Watcher is "creepy" too. very Orwellian. It has connotations of mass-survelliance which are every bit as disturbing in the post-wikileaks era as stalker. I think helper is friendly, neutral, unambiguous and would cover all the above issues. We can create a suitable image for "helper" and it can add its place in the wikifauna. I would suggest a cartoon-like angelic figure. Something along those lines. Thoughts? Irondome (talk) 01:30, 27 February 2015 (UTC)
  • Support - Although {{tps}} fits my sense of humor, it's not a bad change, considering the millions of eyes viewing the project, it's not a stretch of the imagination that it could be frequently miss-interpreted. Mlpearc (open channel) 01:59, 27 February 2015 (UTC)
  • Support - If it were "watcher" now and we had an RfC to change it to "stalker", there would be 200 opposes. So, my twisted logic says support. Anna Frodesiak (talk) 02:13, 27 February 2015 (UTC)
  • Oppose as inconsequential. No need to make changes that have no functional effect. --Jayron32 02:24, 27 February 2015 (UTC)
  • Oppose. Aside from what Jayron says (with which I agree), you have the issue of watchlists: some people frequently participate at pages not on their watchlists (I often participate at WP:AN, but there isn't a single projectspace page on my watchlist, and I'm a frequent contributor at some users' talk pages, but aside from my own, I don't watch any userspace pages), and some people rarely or never participate at pages that are on their watchlists. If we want to be "encouraging a less ambiguous usage", we should use a term that isn't commonly used here already. If you want to rename the concept, use "lurker" or some form of it. Nyttend (talk) 12:41, 27 February 2015 (UTC)
  • Support deprecation of tps, but I like Nyttend's "lurker" suggestion better than "watcher". --SarekOfVulcan (talk) 14:35, 27 February 2015 (UTC)
I fear that "lurker" carries much of the same connotation as "stalker". What about Irondome's suggestion of "helper" as an alternative? Personally I prefer "watcher" because it ties in with existing wiki functionality (watchlists) as Johnuniq pointed out. Also, one can interject a one-off comment on a talk page they stumble across without it being on their watchlist. I often do. Ivanvector (talk) 16:08, 27 February 2015 (UTC)
  • suggest T P Follower Leaky Caldron 16:39, 27 February 2015 (UTC)
  • Follower is good. A la FB. Follower or helper both have more positive vibes. Irondome (talk) 16:55, 27 February 2015 (UTC)

Infobox salary

I have a quick question regarding content within an info box. When noting an individual's income or salary on a BLP info box, do we include the dollar amount cited in a reliable source even if it includes other expenses or reimbursements? Thanks! Meatsgains (talk) 03:37, 27 February 2015 (UTC)

Technical partial data

Both January 27 and February 4 only show partial data for pageviews. Both dates compiled only articles up to some point in the alphabet between Royce White and Tim Hardaway, Jr.. All articles after this point in the alphabet have no pageview data for these dates. Recall that December 31, 2013 stopped between TNZ and TO and was not compiled completely for several months thereafter.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 21:31, 5 February 2015 (UTC)

Currently, February 5 has compiled to somewhere between Emily Ratajkowski and Frank Underwood (House of Cards).--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 05:40, 6 February 2015 (UTC)
No Page view statistics at all are available for February 6, and Henrik's talkpage is pretty much deserted Ottawahitech (talk) 14:32, 7 February 2015 (UTC)
2/7 did almost none of the pageviews. It stopped somewhere between Aardvark and Anthony Davis (basketball).--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 09:07, 8 February 2015 (UTC)
It appears that the program follows the alphabet not only in the articles but also in the Wikipedias it serves. According to this posting the Arab Wikipedia's Page view statistics are still working while the English Wikipedia's are not. Ottawahitech (talk) 14:37, 9 February 2015 (UTC)
  • Still no Page view statistics ? Ottawahitech (talk) 14:29, 9 February 2015 (UTC)
Is the source data from Wikimedia complete? It's best to narrow down the offender. It'd be nice if the Foundation could follow through and actually make their own page view statistics in a readable format rather than relying on a website that frequently breaks. Killiondude (talk) 00:27, 10 February 2015 (UTC)
You may be thinking of WMF Labs "Wikiviewstats", which has been in this condition since last October: Noyster (talk), 16:41, 10 February 2015 (UTC)
The source data from [12] appears to be complete. Mr.Z-man 05:06, 11 February 2015 (UTC)

The following is a better summary of the problem dates. The following shows the last page I quickly found with seemingly full stats and the first page that I did not see stats for.

Jan 27: Royce White and Tim Hardaway, Jr.
Feb 4: Royce White and Tim Hardaway, Jr.
Feb 5: Emily Ratajkowski and Frank Underwood (House of Cards)
Feb 6: None (before Aardvark)
Feb 7: Aardvark and Anthony Davis (basketball)
Feb 8: None (before Aardvark)
Feb 9: Campbell's Soup Cans and Cloud Gate
Feb 10: None (before Aardvark)
Feb 12: None (before Aardvark)
Feb 13: None (before Aardvark)

I continue to assume the English WP pageview stats are compiled alphabetically and base the above information on that fact.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 06:42, 10 February 2015 (UTC)

In Polish Wikipedia stats are down from 2015-02-02. --Swd (talk) 07:47, 10 February 2015 (UTC)

  • Still no Page view statistics ? Ottawahitech (talk) 01:06, 11 February 2015 (UTC)
It's up again for 11 February now. While I saw a graph yesterday where only 6th, 8th and 10th February were missing, the graph for the same page today shows a gap from 5 thru 11 February... Does anyone know if the missing data will be restored? -- (talk) 21:29, 12 February 2015 (UTC) (PS ping @Jackson665: as you asked there :)

No data?

I've been checking both the English and Japanese Wikipedias, and essentially, data for February 4 and 5 is missing. What happened? Narutolovehinata5 tccsdnew 13:49, 6 February 2015 (UTC)

I use the service regularly for and I've noticed some lack of data on January, the 27th, but in the previous months it has been performing quite well. It did show some interruptions in the past, but not recently.--Alexmar983 (talk) 21:26, 10 February 2015 (UTC)
I reported this earlier after seeing Stand Up, Stand Up for Jesus apparently not have any views for the 27th despite being on DYK. But when I reported it, no-one appeared interested. I would like to know why there is no data and why WikiViewStats are down too. The C of E God Save the Queen! (talk) 09:54, 11 February 2015 (UTC)

Anyone interested?

In collaborating on a new, stable, pageview system? and wikiviewstats are both maintained by single users who haven't been active in months. I don't have the time or interest to do it all myself (plus, we obviously want to avoid having a single person running important systems like this), but I have some experience (and already-written code) from popularpages. So if 2 or 3 other people are interested, I'd also be in. Mr.Z-man 05:06, 11 February 2015 (UTC)

I'm not sure if this is still a plan, but last October, the WMF said that they were trying to build a new page view system: "Negrin told [the Signpost] that they are aware of the problem [with] and are currently working to replace the current apparatus with a "modern, scalable system," which will come out in a preliminary form next quarter." Now, my memory could be wrong and the WMF was referring to something else ... but that's one reason we have pings. TNegrin (WMF) Ed [talk] [majestic titan] 18:09, 11 February 2015 (UTC)
What about ? Anyway there could be a replacement needed, as @Henrik: seems to be on the leave? (Unfortunately, I am no programmer, even not when I log in ;) PS. says: "This is very much a beta service and may disappear or change at any time." :( -- (talk) 21:54, 12 February 2015 (UTC)

Working again?

Ha. Looks like it may be working again. Pkeets (talk) 02:35, 14 February 2015 (UTC)

All I'm getting is "Internal server error". Squinge (talk) 10:38, 14 February 2015 (UTC)
Still not working as far as I can see... Simon Burchell (talk) 17:47, 14 February 2015 (UTC)
I still see an empty gap between February 6 and February 11. Dustin (talk) 18:17, 14 February 2015 (UTC)
And there's been nothing since Feb 11 as far as I can see - not even blank entries now, just no update to the chart at all. Squinge (talk) 06:36, 15 February 2015 (UTC)

This is really making it hard to do quite a lot of things... Fix needed soon, and lost data recovered. Rcsprinter123 (lecture) @ 19:55, 15 February 2015 (UTC)

EN WP pageview stats are all caught up except for one date

Since I believe that the pageview statistics are done alphabetically, I have looked at the pageview stats for Zoo and believe that all the problematic February dates have been caught up and the only remaining date at issue is January 27, which cut off somewhere between Royce White and Tim Hardaway, Jr.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 06:21, 16 February 2015 (UTC)

Looking good to me too. I've checked a number of pages on my watchlist and they're all up to date with the exception of Jan 27. Squinge (talk) 10:54, 16 February 2015 (UTC)

Not updating

Now the 18th through 20th are undone. This is no longer updating pageviews daily.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 08:50, 21 February 2015 (UTC)

I know this is a recurring problem that has been happening for years. But we have not had stats since Feb 17: Main page stats. Any chance WMF will be hooking the articles up to a more reliable method? — Maile (talk) 13:11, 21 February 2015 (UTC)

See also Wikipedia_talk:Wikipedia_Signpost#Suggestion_for_an_item_in_the_Signpost_--_no_Page_view_statistics. Ottawahitech (talk) 15:58, 24 February 2015 (UTC)

===Cannot connect to server=== My browser cannot connect to the server Ottawahitech (talk) 17:11, 22 February 2015 (UTC)

Knowledge of personal pronoun preference data base

There is an interest in tracking progress toward gender equality by dynamically updating statistical measure of self-identified "gender pronoun usage preference" on user pages to confirm trend of progress to achieve gender parity. This is likely admin only access to technical user data. Does anyone know how easy/how difficult it would be to gather and then print out these statistics? LawrencePrincipe (talk) 21:16, 13 February 2015 (UTC)

@LawrencePrincipe: Actually, you can access it using the "gender" magic word like so: {{gender:username|he|she|unset}}
So if you enter {{gender:Philosopher|he|she|unset}}, you get he, indicating hat I have my preferences set to "he". I do the same thing to you and see that yours is "unset". – Philosopher Let us reason together. 00:14, 14 February 2015 (UTC)
@Philosopher: On a one-by-one basis that works, though the stats are needed system wide on a weekly and/or monthly basis. That is, out of the total number of new users per month, what ratio self-identified as female and what ratio self-identified as male system-wide. Can it be done system-wide for being dynamically updated? LawrencePrincipe (talk) 00:35, 14 February 2015 (UTC)
Listed at Wikipedia:Database reports/User preferences but out of date. --  Gadget850 talk 00:53, 14 February 2015 (UTC)
@Gadget850: Those stats are quite fine, but quite dated: "User preferences statistics; data as of 23:12, 19 June 2014 (UTC)." Is there a way to update them, or get a month-by-month graph? LawrencePrincipe (talk) 02:01, 14 February 2015 (UTC)
Looks like this was run on the old Toolserver. I don't know of a replacement. --  Gadget850 talk 02:23, 14 February 2015 (UTC)
Note that this data is very unlikely to be useful or meaningful. The preference is designed to be used for gendering language correctly (not an issue in English) and not for demographic tracking; most users will never set it. Andrew Gray (talk) 15:28, 14 February 2015 (UTC)
@Andrew Gray: The gender stats from the UN study from 2010 are the only ones currently is use and are dated. Although not optimal, looking at the "user preference choice of gender" offers a useful approximation. It is not optimal, but useful for gaining some insight into the current status of the gender stats. Are you familiar with the new Toolserver applications and data base access? LawrencePrincipe (talk) 16:02, 14 February 2015 (UTC)
FWIW, this is the WMF Analytics discussion from last year on whether it was likely to be useful data. Andrew Gray (talk) 19:51, 14 February 2015 (UTC)
Hi Andrew Gray; That conversation between Ryan Kaldari, Aaron, and Steven Walling at WMF Analytics was interesting on gender preference data being used in a sub-optimal way of getting gender stats updated from the old 2010 UN data. If anyone has their user id name, then I could ping them to try to find someone who knows the new Toolserver. The link just provided above here by Gadget850 was strongly on target with women editors estimated at 19%, which is actually quite close to the 2010 UN numbers. If anyone knows the new Toolserver well enough, or has the user id for any of the above (Ryan, Aaron, and Steve Walling) then I could ping them. LawrencePrincipe (talk) 20:46, 14 February 2015 (UTC)
I'm not sure what you mean by "knows the new toolserver", but if you have an idea of what the old SQL query was you can try it at quarry - no need for a toolserver/labs account. I would strongly stress that the 19% is probably as much random chance as meaningful data, though. Andrew Gray (talk) 20:56, 14 February 2015 (UTC)
Does someone know how to update this link: Wikipedia:Database reports/User preferences. LawrencePrincipe (talk) 21:22, 16 February 2015 (UTC)
@LawrencePrincipe: The code that generates this report is at Wikipedia:Database reports/User preferences/Configuration. Looks like it comes from the Toolserver era, so it's going to need adjustments, but you should be able to run the SQL queries at least without modifications on Quarry (mentioned above). Perhaps you can get MZMcBride (its author) to make it work. Matma Rex talk 12:46, 17 February 2015 (UTC)
@Matma Rex: MZMcB wrote that for the old toolserver, and what is needed to maintain stats now is if it can be updated/converted to the new toolserver to update the stats. Any way that this can be done? LawrencePrincipe (talk) 01:53, 18 February 2015 (UTC)

(un-indent) phabricator:T60196 is what's blocking us here. --MZMcBride (talk) 20:03, 19 February 2015 (UTC)

@MZMcBride:@Rich Farmbrough: That issue seems to have been addressed by @Rich who appears to be able to find a way to get the gender stats on a monthly basis (see section immediately below). The last update to comments on the phabricator link you just provide was from 14Dec which has not been updated since then. Any chance of getting the month-by-month gender preference stats for the last three or four monthly intervals? LawrencePrincipe (talk) 00:09, 20 February 2015 (UTC)

Section break for Wikimedia research stats

There was a user survey done by the WMF, the results of which have not been released yet. There is a paper which describes identifying users gender by name as a supplementary process (I forget which paper). There is also some work on gendered linguistic differences on Wikipedia, and the conclusion I took from that was that it is not valid to extrapolate gender tells from general Internet discourse to Wikipedia discourse without supporting evidence. I also analysed some small samples of text on a standard "gender tester" with poor results. However there is no reason that a full text analysis of all talk page contributions could not be done, and it might well lead to a model with good gender predictive power, since there is a valid training set consisting of the gender identified users. All the best: Rich Farmbrough11:46, 18 February 2015 (UTC).

@Rich Farmbrough: That paper you mention would be interesting to locate if you have any leads. The issue of using the new toolserver to count up the number of new accounts which self-identify as female seems to be difficult to accommodate, even though the old toolserver apps did this with ease. The research apps you describe above sound pretty advanced, though the simple counting of new accounts which self-identify as female would offer a first step if someone could figure out the new toolserver. LawrencePrincipe (talk) 15:18, 18 February 2015 (UTC)
The last 5000 new accounts (that have edited) were 9 male, 1 female, 4990 unset. All the best: Rich Farmbrough16:13, 18 February 2015 (UTC).
Thanks, Rich, that is important to keep in mind (also, specifying user gender is only possible since october 2011):
"However there is no reason that a full text analysis of all talk page contributions could not be done, and it might well lead to a model with good gender predictive power, since there is a valid training set consisting of the gender identified users." - Except that this would be freaking creepy! --Atlasowa (talk) 16:37, 18 February 2015 (UTC)
Declared: male = 502573, female=98369 , female = 16.40% of those with declared gender.
Admins: female=56, male= 600.
All the best: Rich Farmbrough17:04, 18 February 2015 (UTC).
@Rich Farmbrough:@Atlasowa: Those are remarkable gender stats, but what does 500,000 male editors refer to? The Economist newsweekly has stated here [[1]] that there is a total of 50,000 editors in 2007, which went down to 30,000 editors in 2014. What does your 502,573 number mean, and is it related to the 2011 date cited by @Atlasowa? Maybe there is a simple explanation. LawrencePrincipe (talk) 17:50, 18 February 2015 (UTC)
  1. ^ "The future of Wikipedia: WikiPeaks?". The Economist. March 1, 2014. Retrieved March 11, 2014. 
The vast majority of the 20,555,036 Wikipedia accounts have never edited (or have no edits visible in their contributions). There are several obvious reasons for these accounts, and some not so obvious:
  1. Someone sees some vandalism and creates an account, but it is fixed by the time they get there.
  2. Someone creates an account but finds editing too hard, changes their mind, gets distracted (ooh look a butterfly!)
  3. Accounts created to protect a name (e.g, User:Placeholder, and WP:DOPPELGÄNGER accounts) or to reserve a name
  4. Accounts who try to vandalise and give up because the edit filters won't let them
  5. Accounts that created an article which was later speedy deleted
  6. Accounts where the password was forgotten, or set wrongly
  7. Sleeper socks
and probably a few more.
And the other figures are based on "active editors" which has various definitions, usually in terms of X edits per month or year.
All the best: Rich Farmbrough18:49, 18 February 2015 (UTC).
LawrencePrincipe, the Economist refers not really to "total editors" but to "active editors" (Active Editors = Registered (and signed in) users who made 5 or more edits in a month), see english WP summary stats, 2007: ~50,000 active editors and 2014: ~30,000 active editors. Same trend on other big WP, german WP summary stats 2007: ~9,000 active editors and 2014: ~6,000 active editors. Total (ever) Registered users on enWP: 24,107,661, that makes 500,000 male editors a very small part. Same for admins: Out of 1,363 enWP Administrators, 56 are female and 600 male. --Atlasowa (talk) 19:28, 18 February 2015 (UTC)
@Rich Farmbrough: The comments all appear to be in agreement. The stats would be interesting to see for results for the last 10,000 editors and the last 15,000 editors. Are they all consistent at about 10% gender pronoun usage? @Atlasowa: The Economist article also states that non-English Wikipedia is stable at about 42,000 active editors, up or down 2000 for seasonal variation. The 'active' editor number appears to be a significant one for all the reasons that Rich has stated above. Can the stats and tools you provided be used as reliable data to be published from Wikimedia? LawrencePrincipe (talk) 21:41, 18 February 2015 (UTC)
The Quarry tools are there, and I might be able to make something better. (Well I am able, but I need to brush up my SQL.)
The 5k figure I can potentially get you the 10k and 15k figure. To replicate those figures, it is important to state the time by which the accounts needed to have edited to qualify. Probably simpler just to list the 15k accounts.
I do agree with Steve Walling, though, that the declared numbers are a poor proxy. For example GamerGate may have made females lees willing to self-identify (or it may not.. but it's a potential confounding factor.)
All the best: Rich Farmbrough23:36, 18 February 2015 (UTC).
@Rich Farmbrough: All those stats would be useful since at present there is no new data on gender stats since the 2010 UN study. If you say "it is important to state the time" for the 5k, 10k, 15k then it may be just as easy to double the time interval to indicate how many women registered (approx. 10k level), and the triple the time interval to approx. the 15k level, if that seems reasonable. The actual number for each time interval would tell the story. Regarding your other question about women "GamerGate" concerns, my understanding is that if women were given confidence that self-identifying gender would help them to better achieve gender parity, then they would have every incentive to do so. Historically, a chance to achieve goals is often a high incentive to participate. LawrencePrincipe (talk) 00:31, 19 February 2015 (UTC)
Absolutely, it's the case that Editathons based on improving coverage (achieving gender parity) on women's history, women's literature etc. are very successful in attracting participants (of both genders) I believe for this reason. However the motivation to edit is generally not related to gender parity, and those who are really passionate about this tend to think (perhaps rightly) that their time is best spent encouraging other women and girls to edit.
As far as the numbers go 5,000 editors is about 2 or 3 days worth. But I can take samples at monthly intervals, or some such. All the best: Rich Farmbrough00:52, 19 February 2015 (UTC).
Hi Rich, Agreement on all of the above. If the monthly stats are a convenient time interval then by all means it would be useful to see it, for a few monthly intervals if possible? You seem to have kept up with the editathons and likely know about the woman Admin education effort. It would be nice if the old gender 2010 data could be updated with some of this. LawrencePrincipe (talk) 01:16, 19 February 2015 (UTC)

I am not able to edit my user page

I am not able to edit my user page using my android mobile browser (Google Chrome). This error starts appearing from 2 days. The edit source icon in mobile version of wikipedia(A Pencil Logo), get merged to the notification icon on the top right corner of the page . I can give a screenshot of this. I am not able to understanding the kind of error happening to it, even though when I opening wikipedia on PC, it's all right. Please anyone solve this problem. Mobile Browser: Google Chrome 38.0.1847(Android) < br/> Link: Saurabh Chatterjee 2 (talk) 17:03, 18 February 2015 (UTC)

 — Preceding unsigned comment added by Saurabh Chatterjee 2 (talkcontribs) 16:58, 18 February 2015 (UTC) 
Hi, I can't reproduce this issue (anymore?), can you take a screenshot and upload it? --Florianschmidtwelzow (talk) 19:24, 18 February 2015 (UTC)
@Saurabh Chatterjee 2: Can you still reproduce the problem? :) --Florianschmidtwelzow (talk) 17:50, 23 February 2015 (UTC)

Extremely slow load speeds

For the past couple days Wikipedia has been very slow on loading, getting stuck on transferring data from I've cleared my cache/cookies, but even things on Wi-Fi experience these slow speeds. KyoufuNoDaiou (talk) 04:10, 20 February 2015 (UTC)

Please use your browser's developer tools ("Network") to see which specific files load how slowly. --AKlapper (WMF) (talk) 13:06, 20 February 2015 (UTC)
Today it's working at proper speeds. Should it happen again I will check and post again. Thanks! KyoufuNoDaiou (talk) 15:53, 20 February 2015 (UTC)
It's extremely slow again, not even loading. I had to use noscript to get here. This image took something like 2 minutes to load only after I opened it in a new tab. It seems to be anything coming from bits slows it down. Let me know if you need anything else, I appreciate the help. It's only bits as well. I can view the page source a couple seconds after loading the page, it's just that nothing displays.KyoufuNoDaiou (talk) 02:38, 21 February 2015 (UTC)
@KyoufuNoDaiou: I suggest using the command traceroute (or tracert to check which specific intermediate hosts between you and are slow. I'm not sure if it's related, but for the record, at Japanese Wikipedia some people (presumably all of which were connecting from Japan) simlarly reported slowness between February 14-18. Whym (talk) 03:12, 21 February 2015 (UTC)
It's working at a good speed again today. If it slows down again (hopefully not) and the reply time is coming from a Wikipedia server, I'll post again. Thanks!KyoufuNoDaiou (talk) 15:53, 21 February 2015 (UTC)
  • I've had extremely slow load speeds for wikipedia all week, but today it is even worse. It is only wikipedia that is affected no other websites, and regardless of where I am trying to acces it from.User:Maunus ·ʍaunus·snunɐw· 21:11, 22 February 2015 (UTC)
It's slow again for me as well. Most of the time traceroute gives good numbers (approx 55-85 ms) a couple times I got some higher ones (100-200 ms) but it still is slow.KyoufuNoDaiou (talk) 21:36, 22 February 2015 (UTC)
I just ran a Network test and some Javascript took ~88 seconds to download that and on another test a css took a while as well.KyoufuNoDaiou (talk) 21:52, 22 February 2015 (UTC)
It's been hit and miss for me all week, too. Using MonoBook. Smarkflea (talk) 23:00, 22 February 2015 (UTC)

I'll email ops, but while we're waiting, could you please post (or e-mail to User:Faidon Liambotis (WMF)) your general location or IP address? Whatamidoing (WMF) (talk) 01:43, 23 February 2015 (UTC)

Im in San Diego, CA. When I use another laptop I have normal load speeds though. User:Maunus ·ʍaunus·snunɐw· 05:55, 23 February 2015 (UTC)

I think these are all issues with AT&T in the US (and possibly focused on the west coast?), we've had a couple of more reports from there as well. I haven't been able to pinpoint where the issue lies exactly so far, I'm afraid. I did made a change just now but it was more of a guess — please do let me know if you continue to see issues or if they are magically fixed. I'll reach out to AT&T contacts in the meantime to report the issue and possibly get some insight. Thanks for your report and for your patience! Faidon Liambotis (WMF) (talk) 07:23, 23 February 2015 (UTC)

Ah, I've been getting this behavior too, and I'm on AT&T U-verse on a dynamic IP on the west coast (Mountain View, CA). My current traceroute to looks like this (I'm posting this for the route, not the times, and I have no timing issues at the moment anyway):
traceroute to (, 64 hops max, 52 byte packets
 1  homeportal (  0.949 ms  0.790 ms  0.740 ms
 2 (  19.612 ms  25.996 ms  19.302 ms
 3 (  27.317 ms  19.185 ms  19.794 ms
 4 (  20.220 ms (  20.219 ms  20.898 ms
 5 (  21.978 ms  23.541 ms  24.127 ms
 6 (  22.712 ms  23.026 ms  22.803 ms
 7 (  23.488 ms  22.586 ms  22.569 ms
 8 (  88.753 ms  93.651 ms  89.593 ms
 9 (  88.924 ms  94.450 ms  92.912 ms
10  * * *
This slowdown behavior seems to depend on the time of day, being the worst in mid to late afternoon local time. It's completely absent right now (11:30 PM local time), but unless your change fixed it, I would expect it to return around the same time tomorrow. --Colin Douglas Howell (talk) 07:34, 23 February 2015 (UTC)

We debugged this extensively with an AT&T engineer. They made some recommendations on which paths to use and which to avoid, as some of their paths are currently congested for various reasons. I've made some adjustments to our config to use a different carrier and it's very likely it may help. Please do let me know if you keep seeing slowdowns, esp. if you are an AT&T customer. Thanks! Faidon Liambotis (WMF) (talk) 18:16, 23 February 2015 (UTC)

I'm not an AT&T customer, but it uses their phone lines. No other site has been affected...Smarkflea (talk) 19:04, 23 February 2015 (UTC)
It's been working well the past couple days and today. Thanks for all your work!KyoufuNoDaiou (talk) 19:15, 25 February 2015 (UTC)

Page Curation toolbar went away?

Off and on for a few weeks now I've been working on trying to reduce the backlog at Special:NewPagesFeed (currently up to December 7th). I've found the page curation toolbar to be extremely helpful. Yesterday, it was gone. I figured I must have mucked something up in my preferences, so I played around with them and then it came back. I have not changed them at all since then, but today it's gone again. Does anyone know what's going on with that? I can't even mark a page as reviewed. ~ ONUnicorn(Talk|Contribs)problem solving 19:31, 20 February 2015 (UTC)

And now it's back again? But I didn't do anything. This is odd. ~ ONUnicorn(Talk|Contribs)problem solving 20:37, 20 February 2015 (UTC)
And now it's gone again. I don't get it. ~ ONUnicorn(Talk|Contribs)problem solving 18:39, 24 February 2015 (UTC)

The page $ already exists and cannot be overwritten

What's the message that says this? See the text inside the big red box in this screenshot if my meaning isn't clear. It's kind-of under discussion in the final section of Wikipedia talk:Requested moves right now, so I searched for the title (searching only Mediawiki: space pages), but all I could find was the related but different MediaWiki:Fileexists-forbidden. It's definitely not Mediawiki:Talkexists, because Wikipedia:Miscellany for deletion/MediaWiki:Talkexists notes that this message was deprecated several years ago. As far as I can tell, uselang=qqx doesn't work when you're at — after I moved a page, I changed the URL to, but all it gave me was the message for "you didn't specify a page to move". Nyttend (talk) 18:55, 22 February 2015 (UTC)

It's MediaWiki:movepage-page-exists. -- [[User:Edokter]] {{talk}} 19:29, 22 February 2015 (UTC)
See Wikipedia:Village pump (technical)/Archive 131#What interface page is used for the results after a successful undeletion? for tips another time. PrimeHunter (talk) 21:11, 22 February 2015 (UTC)
Edokter, thanks for the link! I created it by adding a second sentence and a pair of <big> tags to the Mediawiki page. This didn't work, however: the additional sentence displayed, of course, but when moving User:Salvidrim!/sandboxorig to User:Salvidrim!/sandboxtest and checking the "move talk page" box, I got <big><big>The page User talk:Salvidrim!/sandboxtest already exists and cannot be automatically overwritten. You must resolve the situation manually if you want to complete this pagemove.</big></big> I didn't realise that tags like <big></big> would display as text when used in a Mediawiki tag, rather than working. Any ideas on what to do? I was going to delete my version of MediaWiki:movepage-page-exists, but I suppose I ought to leave it up in case anyone else wants to try something, but feel free to request deletion at any point if you think that there's no more testing to be done. Nyttend (talk) 23:09, 22 February 2015 (UTC)
No all system messages are going through the sanitizer/parser to process HTML and wiki markup, so it is treated raw. Not much one can do here in terms of styling this message. I've deleted it. -- [[User:Edokter]] {{talk}} 23:29, 22 February 2015 (UTC)
Also, please don't use <big>; it is deprecated in HTML5. -- [[User:Edokter]] {{talk}} 23:31, 22 February 2015 (UTC)
Actually, it's obsolete in HTML 5, which is "stronger" than deprecated. --Redrose64 (talk) 23:36, 22 February 2015 (UTC)
I'll think about doing so once WikiMedia stops allowing me to use <center>...which'll never happen (ae. cruft is cruft is cruft and chalk it up to the age of the website). ResMar 01:43, 23 February 2015 (UTC)
@Resident Mario: I'm pretty sure center is converted by the parser to div style="margin:auto" /div. But... I could be wrong. --Izno (talk) 05:10, 23 February 2015 (UTC)
You are wrong, there are no parser conversions for obsolete elements or attributes at the moment (this change was reverted in 2012). Center is probably also a obsolete tag that the parser will never substitute. The reason is that it's effects are dependent on it's parents, which makes it difficult for the parser to replace it correctly. Instead, like bgcolor on tables, it will work for as long as browsers choose to support it and then simply stop working. I believe we recently got reports from the first browsers dropping support for some obsolete attributes, so that might be reason to re assess changes to the parser (I think Edokter actually was considering taking another look at that). Any change will likely first start with adding tracking categories or something similar, giving editors a way to assist and observe changes. —TheDJ (talkcontribs) 09:35, 23 February 2015 (UTC)
On the <table>...</table> <tr>...</tr> <th>...</th> <td>...</td> elements, the bgcolor= attribute was never a full part of the HTML spec. It was first described in HTML 4, but was marked as deprecated even then, hence browser vendors were never obliged to provide it; it is known that some browsers do not support this attribute, which is why we have bots going around altering them to style="background-color: ...". The <big>...</big> and <center>...</center> elements are different, in that both were part of the formal spec - both were added in HTML 3.2; center was marked as deprecated in HTML 4.01, but big was not; both are obsolete in HTML 5. If an element - or an element's attributes - were part of the formal spec for HTML 2.0, HTML 3.2 or HTML 4.01, browser vendors of the time will have included support for those elements or attributes (otherwise they wouldn't have been compliant), and since nobody is obliged to rewrite web pages to accord with the latest spec, there will be a lot of web pages out there which are pure HTML 3.2, so browser vendors are unlikely to drop support at any time soon. --Redrose64 (talk) 11:19, 23 February 2015 (UTC)
If all system messages are treated as raw, what about the big involved ones with lots of links and other stuff, like MediaWiki:Blockiptext? What if we added its use of NOTOC/NOEDITSECTION and turned the warning into a section header? Nyttend (talk) 02:53, 23 February 2015 (UTC)
Won't work. Not all system messages are treated raw; it depends on what part of the software or extension is actually using the messages. Phabricator is your best chance. -- [[User:Edokter]] {{talk}} 09:24, 23 February 2015 (UTC)

CSS 'nth-child' integration into long tables?

Example of what I mean
Lorum ipsum dolor sit consectetur
adipiscing Donec sed dolor maximus
maximus justo blandit ipsum Praesent eu
sollicitudin metus vel eleifend Sed et lorem
quis erat tempor viverra sed id augue
Phasellus lacus imperdiet sed tempor eget
dolor molestie Sed sollicitudin condimentum
sapien arcu sodales nibh id ultrices ex
...and ...forth...

I asked over at the help desk, but I haven't gotten much of a response—thought I'd try here. Basically, I was wondering if it's possible to use the CSS parameter nth-child() (as explained here: [13]) in tables to ease the coding of background colors or text features at a steady interval? Currently, I'd have to code |- style="background:#C0C0C0;" on every other row, even though I only want a gray background color on the even-numbered rows. Were I designing a table in a webpage, I could use nth-child() to set up this style from the beginning. Additionally, the parameter allows the designer to set up whatever intervals s/he wishes and to begin the intervals after a certain number of columns or rows. This would be greatly beneficial in extremely long tables where reading clarity is paramount. I think alternating row colors help the reader stay on course through detailed and lengthy data points. Is this possible? -- Veggies (talk) 04:48, 23 February 2015 (UTC)

Unfortunately nth child can only be used with a stylesheet on Wikipedia. Related stackoverflow exchange. --Izno (talk) 05:12, 23 February 2015 (UTC)
You could use {{Alternating rows table section}}, but really I think the syntax for that is uglier than just styling the tables yourself. Maybe a better template could be created that uses Lua?--Dudemanfellabra (talk) 06:36, 23 February 2015 (UTC)

The last of three discussions at MediaWiki talk:Common.css/Archive 15#New style for tables with alternating row colors. --  Gadget850 talk 17:34, 23 February 2015 (UTC)

I may well just add the following line of CSS (from the previous discussions, adding white stripes), just to give editors the option. We'll see how popular it gets. -- [[User:Edokter]] {{talk}} 17:51, 23 February 2015 (UTC)
.wikitable.zebra tr:nth-child(odd) {
    background-color: #fff;
Fwiw... we started the needed polling for facilitating the development of "something" along the same lines as mentioned above over on Wikisource more than a month ago. You can check out both the nth test-bed & the findings to date (even participate) starting HERE. -- George Orwell III (talk) 00:36, 24 February 2015 (UTC)

Edit API error

I have a script at User:Dudemanfellabra/NRISOnly.js that controls my bot, User:NationalRegisterBot. I run it ~weekly and it scours the lists on WP:NRHPPROGRESS to produce this list of all pages in the project, along with a bunch of other information that it dumps in various places. It takes about 3 hours for each run, and I've tried to run it twice today, both times failing at the very end when it tries to dump the information by editing subpages of the above-linked page. Since it takes so long to run, I haven't had time to poke around to figure out what's wrong with it. I haven't changed the code since the last bot run a week ago, so I'm wondering if anything has changed in the API since then? Is anyone else having problems? The editing is done through an AJAX call as follows:

        url: mw.util.wikiScript( 'api' ),
        type: 'POST',
        dataType: 'json',
        async: false,
        data: {
            format: 'json',
            action: 'edit',
            title: info.title,
            text: info.text,
            summary: info.summary,
            token: mw.user.tokens.get( 'editToken' ),
            bot: 'true'

where info is an object with the relevant information. Any ideas?--Dudemanfellabra (talk) 06:32, 23 February 2015 (UTC)

What error response is the API returning? Legoktm (talk) 07:41, 23 February 2015 (UTC)
See, that's the problem. I don't have the code set up to show me the error (dumb mistake on my part). It just says it encountered an error. (Side note: If I wanted to output the API error, how would I do so?) But it's never encountered one before, and like I said, it ran fine last week, so something has had to change somewhere besides the code. I was hoping someone with knowledge of a recent change would chime in, but it seems no one knows of anything. I'll look into it more if I can.--Dudemanfellabra (talk) 06:59, 24 February 2015 (UTC)

Unclosed div in Template:Start tab

At the end of Template:Start tab there's an unclosed <div style="padding: 1ex"> tag, and it's causing the sections on this page not to collapse on mobile view. (Compare this page with, e.g., ANI in mobile view.) This unclosed div has been there for a long time, so I think something in the mobile skin must have changed recently. There might be a bug report in that, if someone wants to look. On the premise that unclosed divs are usually bad news I tested what would happen if I removed it, but the result is that the tabs don't display properly. Can anyone see how to balance the tags while still getting everything to display correctly? — Mr. Stradivarius ♪ talk ♪ 12:37, 23 February 2015 (UTC)

The closing tags can be found in {{End tab}}. -- [[User:Edokter]] {{talk}} 12:49, 23 February 2015 (UTC)
That makes sense. In that case, it looks like the problem is that Template:Village pump page header isn't using {{end tab}} when it should be. I can't quite see how it can be made to fit in with the current code, though. — Mr. Stradivarius ♪ talk ♪ 14:10, 23 February 2015 (UTC)
That template is a mess, and it takes a bit of profiling to fix it. -- [[User:Edokter]] {{talk}} 15:46, 23 February 2015 (UTC)

Size of Wikipedia

Dear editors: I have been looking at some of the statistics about Wikipedia, and I find graphs about the number of edits, the number of articles, the number of active editors, etc. Is there also a graph that shows the growth over time of the combined size (maybe in gigabytes) of all articles? (not talk pages, etc.) This, to me, would be the best overall indicator of Wikipedia's growth, rather than the number of articles, since more articles created means more articles to be enlarged and updated.—Anne Delong (talk) 14:22, 23 February 2015 (UTC)

is this any help? - X201 (talk) 14:37, 23 February 2015 (UTC)
@X201: I have lots of questions on these graphs, but the main one is: how can I see statistics more recent than 2006? Just curious. Ottawahitech (talk) 14:55, 23 February 2015 (UTC)
Scroll your browser window from left to right. - X201 (talk) 15:04, 23 February 2015 (UTC)
@X201: Several of the charts stop at January 2010 - any idea why? GoingBatty (talk) 15:42, 23 February 2015 (UTC)

Download as PDF failing

This was reported on the HelpDesk. The download as PDF feature is failing on the Madoff investment scandal article, but works OK on other articles. The eror message is "Status: Rendering process died with non zero code: 1". any ideas? - X201 (talk) 14:46, 23 February 2015 (UTC)

Thanks for reporting this. The problem is tracked in phab:T74002. --AKlapper (WMF) (talk) 18:07, 23 February 2015 (UTC)
Apparently caused by statement [[File:CAHIERS NO 6.pdf|alt=WALL STREET JOURNAL REPORT|thumb]] (recursive PDF?) --Boson (talk) 18:15, 23 February 2015 (UTC)
PS: The first German one under phab:T74002 also appears to be caused by an embedded file, the statement being the German equivalent of [[File:EU financial transaction tax.svg|thumb|bla bla]]]] (can be reproduced using that statement).--Boson (talk) 18:37, 23 February 2015 (UTC)

Tech News: 2015-09

16:29, 23 February 2015 (UTC)

Issue with history link for Wikipedia:Redirects for discussion/Log/2015 February 4

For some reason, for the past couple of days, whenever I attempt to load the history page for Wikipedia:Redirects for discussion/Log/2015 February 4 on my device's browser, my browser freezes and crashes. Can this issue be replicated by someone else, and if it can be replicated, can it be fixed? Steel1943 (talk) 20:20, 23 February 2015 (UTC)

It works fine for me on Linux/Firefox 22. —EncMstr (talk) 21:30, 23 February 2015 (UTC)
Also me, Windows XP/Firefox 35.0.1 --Redrose64 (talk) 21:37, 23 February 2015 (UTC)
  • Loads fine here too; Win 8.1/IE 11.

    The only thing "odd" I can report about opening that history page was the re-appearance of the cite-banner announcing Steward Elections when I know I "dismissed it" already right around the time of the issue/changes concerning the Hide Fundraising gadget a couple of days ago. -- George Orwell III (talk) 00:46, 24 February 2015 (UTC)

Searching, dates, and bots

When you do a search on Wikipedia, under the search is a green date indicating when the page was last modified. This is a useful tool when searching discussion pages, as it enables you to search within a time frame. Unfortunately, bot edits update the last edited date, making it harder to brows by discussion date. Is there any way to make it so that bot edits do not trigger an update to the last edited date in search results? – Philosopher Let us reason together. 01:19, 24 February 2015 (UTC)

API request for listing per-user contributions

Is there an API or bulk-export version of Special:Contributions? —Steve Summit (talk) 03:17, 24 February 2015 (UTC)

mw:API:Usercontribs--Dudemanfellabra (talk) 07:02, 24 February 2015 (UTC)
Perfect, thanks! —Steve Summit (talk) 12:17, 24 February 2015 (UTC)

Importing a gadget

I tried to import Commons' TinEye gadget to my common.js page in this edit, but it isn't working. Any idea what I did wrong? – Philosopher Let us reason together. 04:50, 24 February 2015 (UTC)

You want, not, for starters. —Cryptic 05:01, 24 February 2015 (UTC)
That would be it. Thanks. – Philosopher Let us reason together. 21:30, 24 February 2015 (UTC)

Weird bug at Template:RFC

Please look at Template talk:Rfc#Formatting bug, where an IP has discovered a strange formatting bug. Oiyarbepsy (talk) 05:47, 24 February 2015 (UTC)

Please revert Special:Diff/648592168 if it doesn't solve the problem. –Be..anyone (talk) 06:28, 24 February 2015 (UTC)
It didn't. Per WP:TESTCASES, please use the template's sandbox for testing, don't do it on live templates; and per WP:MULTI, please discuss on the original thread, which is Template talk:Rfc#Formatting bug. --Redrose64 (talk) 10:29, 24 February 2015 (UTC)

May 2,014 cleanup tags

Notrees, Texas (got to love the name :-) is currently in the nonexistent Category:Articles with unsourced statements from May 2,014, along with two other articles. Why is it here, not in Category:Articles with unsourced statements from May 2014? The text string 014 appears only twice in the article: once in a citation (it was accessed last year) and once in the {{fact}} that's apparently to blame here, but the code appears flawless. Why would {{fact|date=May 2014}} (note the lack of a comma) put it in a 2,014 category? In another article from this category, Tangerine, Florida, the category gets added by this edit. As far as I can tell, the bot worked just normally and made no mistakes. Why is the comma added when it's not in the code? Nyttend (talk) 08:35, 24 February 2015 (UTC)

{{Infobox settlement}} expects the {{{population_total}}} to consist only of digits, and displays it using {{formatnum}}. This messes up the output of the {{fact}} tag. One possible fix is to move the tag to the {{{population_footnotes}}} field. -- John of Reading (talk) 09:18, 24 February 2015 (UTC)
Thanks! Fixed the other article, an airport, as well. I also reported this to Anomie, since it first appeared when the bot tagged it; without even looking at the page or the diffs, he identified the problem correctly. Surely this isn't the only nonexistent category with this problem: I assume that other months and other types of cleanup categories have been mangled this way (e.g. Category:Wikipedia articles needing clarification from September 2,014, although that's empty), but I don't know how to search for them without manually examining every page individually. Is there a way to get a list of all pages that are included in nonexistent categories with names including "2,001" through "2,015"? Perhaps a database dump? Nyttend (talk) 15:01, 24 February 2015 (UTC)
The downloadable XML dumps won't help with this. Someone with SQL skills might be able to run a query for you. -- John of Reading (talk) 15:23, 24 February 2015 (UTC)
A "fuzzy" search does work, search for "statements from 2,013"~1 and following years (2013 seems to be earliest year with this problem), see extended search help. But of course a more professional SQL query would be better in the long run. GermanJoe (talk) 16:14, 24 February 2015 (UTC)
PS: Searching for the shorter "from 2,013"~1 will catch all maintenance categories, that follow the "... from month year" convention. A few false positives sneak in, but the results appear to be (almost) complete. GermanJoe (talk) 17:09, 24 February 2015 (UTC)
Would it be easier to have a bot do it one at a time? I'm imagining that the bot creates a list by opening every subcategory of Category:Wikipedia maintenance categories sorted by month and expanding the name by adding "from MONTH Y,EAR". With this done, it simply checks every item on the list, and it logs any categories that have entries. There are currently 163 subcategories; with 15 possible years, and 12 possible months per year, this works out to 29,340 nonexistent categories that it would need to check. Reasonable or unreasonable? Nyttend (talk) 16:32, 24 February 2015 (UTC)
The easiest way is probably to just run a query like select distinct cl_to from categorylinks where cl_to like '%\_2,0__'; on Tool Labs. Doing that just now turned up the following:
So not that many categories to look at currently. I might look into writing a bot task to automatically fix the common cases, if someone wants to help by identifying any besides {{Infobox settlement|population total=}}. Anomie 19:02, 24 February 2015 (UTC)

Getting the URL for a PDF

Google has changed the way it's links worked, at least I don't recall them working this way in the past, and PDFs no longer point to the document but an intermediate google page with the URL encoded in it. I'm trying to cite the paper "DARPA Paves the Way for U.S. Efforts in Ballistic Missile Defense", which if you Google, will find the document but if you click on it will not reveal the URL. In this case the complete URL is listed in green, but in every other case it runs out of that area and has been mangled. Does anyone know a simple way to get the original URL from Google? Maury Markowitz (talk) 13:41, 24 February 2015 (UTC)

@Maury Markowitz: There's a little down-arrow symbol next to the green URL. Click that, go to the cached page, and the full original URL will be listed at the top. — Mr. Stradivarius ♪ talk ♪ 13:54, 24 February 2015 (UTC)
Perfect, thanks!. This also shows the article in my browser instead of download, which is an immediate improvement. Maury Markowitz (talk) 13:56, 24 February 2015 (UTC)
If you use Firefox: --NE2 19:42, 24 February 2015 (UTC)

!!!Fuck You!!! - search question

Why does typing a hash character # into the search box bring up !!!Fuck You!!! as one of the first results, while typing an exclamation mark ! – apparently the first character of that string – does not? Is this some sort of intentional Easter-egg feature? I don't mind, but ask because there was an email to OTRS about it. Justlettersandnumbers (talk) 19:20, 24 February 2015 (UTC)

Interesting, I vaguely recall some other unexpected result on commons, and when I try it here today I get a perfectly boring and correct "Number sign". Monobook, Chrome, almost no gadgets. –Be..anyone (talk) 19:35, 24 February 2015 (UTC)
My guess: since # is used for anchors, the search box ignores it and starts listing all articles. But if you type ! it uses some algorithm to determine which articles beginning with ! you're more likely to want. Note that !! gets you fucked in the seventh position. --NE2 19:40, 24 February 2015 (UTC)
Yes most likely, # is invalid to start page titles with so it will probably strip that character at some point and search for everything. While ! possibly does some ranking in the results starting with !. —TheDJ (talkcontribs) 19:44, 24 February 2015 (UTC)
'#' is one of Wikipedia:Naming conventions (technical restrictions)#Forbidden characters. The searchbox autocomplete for '#' produces the first 10 names at Special:Allpages. I guess this is a somewhat arbitrary consequence of an implementation detail and not a deliberate decision. I think Be..anyone made an actual search.[23] That gives me Number sign. PrimeHunter (talk) 20:23, 24 February 2015 (UTC)
Thanks to all – I should really have been able to work that out for myself. Justlettersandnumbers (talk) 21:54, 24 February 2015 (UTC)

2015 Hackathon in France

Is anyone planning to go to the Hackathon in Lyon, France (23–25 May 2015)? The WMF devs are looking for some volunteers to partner with. People with all kinds of skills (including language and design skills) are needed, and you might get a chance to work with some of the WMF's rockstar devs. If you're interested, please read the linked pages about how to volunteer. (You can e-mail me if you need help figuring out how the process works.) Whatamidoing (WMF) (talk) 01:06, 25 February 2015 (UTC)

Not sure where to look, so I'll be lazy and ask here. Have you left a similar question at fr:wp? fr:Special:Contributions/Whatamidoing (WMF) doesn't show me anything, but of course I know that someone else could have asked. Nyttend (talk) 01:18, 25 February 2015 (UTC)
This page is one of the central pages for reaching technically minded people from all over the world, which is why I chose it for the sole message I've posted. Also, these events seem to be, in practice, mostly English-speaking. But the information has been announced by other people/in other ways, too. Whatamidoing (WMF) (talk) 23:38, 26 February 2015 (UTC)

CAPTCHA behaviour is broken

Lately, whenever I try to save an edit that includes a new external link, I get a red error message saying "Incorrect or missing CAPTCHA". This is despite not having been prompted to enter one. When I go to the bottom of the page and enter the CAPTCHA that does now appear, everything works. However, the sequence of events, which always used to offer a CAPTCHA prompt on save, is now broken. (talk) 02:00, 25 February 2015 (UTC)

Which browser is this about? I assume you are not logged in when this happens? --AKlapper (WMF) (talk) 09:31, 25 February 2015 (UTC)
It happens for me in both Chrome 40 and IE 11 under Win 7 when not logged in. Are you not seeing it? (talk) 12:06, 25 February 2015 (UTC)
Anyone??? (talk) 12:04, 26 February 2015 (UTC)

Unlabeled star is meaningless to newcomers and many advanced editors

At the top of my page there is an unlabeled star. When I hover over it I get a message stating, "Add this page to your watchlist." Why doesn't it bear a label so editors will know what it is supposed to do? I know (now), but for a long time I didn't. While I'm at it, there is a label marked "TW." I am surmising that this is short for "Twinkle," but really I have no idea what Twinkle is. Why must we have such ingroup labels at the tops of our pages? Sincerely, GeorgeLouis (talk) 06:51, 25 February 2015 (UTC)

That star is part of the "Vector" skin (explicitly designed to be compact); it's not found in the Monobook skin - the word "watch" is. עוד מישהו Od Mishehu 08:17, 25 February 2015 (UTC)
Also, there's a tooltip displayed when hovering over the star, which describes its purpose. — Dsimic (talk | contribs) 08:22, 25 February 2015 (UTC)
I would say, what's wrong with the star, when you can hover over it to see what it does? And you must have enabled Twinkle for yourself if you see "TW" there. Twinkle is not enabled for all users, only those who choose to enable it. The "TW" abbreviation is used simply to save space, not as an intentional obfuscation measure. — This, that and the other (talk) 13:03, 25 February 2015 (UTC)
The star icon has become a browser standard: Firefox, IE and others use it for bookmarks. The watchlist icon was chosen as an analogue to bookmarks. --  Gadget850 talk 13:24, 25 February 2015 (UTC)
Chrome and IE use it so IMHO it makes sense for us too, As for Twinkle - It's easier and with the greatest respect I'd imagine 90% know what it is so not really seeing any need to change the star or even consider doing so. But that's just my 2¢. –Davey2010Talk 13:38, 25 February 2015 (UTC)
  • I know very well what they both mean, but I do agree if I didn't I would be upset when viewing from my mobile in desktop mode where I can't 'just hover' over either to see. I'm guessing if I was first editing from a tablet I'd be upset too since it is another touch device without hover. I'd suspect that it would be a good idea to include in our vector.css/js a way to determine if the user is on a touch device and 'use our words' instead of symbols. Just my 2cp on it, and I really don't care anyways except I was a little annoyed by the direction of this discussion. — {{U|Technical 13}} (etc) 13:43, 25 February 2015 (UTC)
  • Technical 13 - "little annoyed by the direction of this discussion" - Well I'm assuming it's me - I've read my comment 4 times and still see nothing wrong with it so could you explain what I've said that's ticked you off?.... –Davey2010Talk 14:08, 25 February 2015 (UTC)
  • For once I have to agree with T13 here. Every other function on the Wikipedia page is represented by words, not an icon (at least until you get into edit mode and use the RefToolbar). It's kind of jarring. Besides, mystery meat navigation is never a good thing. By default, I think that Mw-watch-icon.svgWatch and Mw-unwatch-icon.svgUnwatch would be better. --Ahecht (TALK
    ) 14:22, 25 February 2015 (UTC)

I think GeorgeLouis makes a really good point!

1) Watching articles really, really matters. Watching articles, looking at your watchlist is the engine of Wikipedia! If nobody watches articles, they degrade. Recent Changes patrol is not able to be our only quality control, and page watchers are regularly better qualified to assess the merits of an edit. I would even say that it is erroneous to quantify "user activity" or "editor attrition" by number of new user registrations, or by new users with +1 edits, but that "regular users" is the important metric: "users that watch articles". I don't know how to count those users, but for the trends we can take these old stats 2013/2014 about article numbers (in thousands=k) and number of "superuser" (phantasyname for user with >100 edits per month) and calculate the number of articles "to watch" per superuser (in thousands=k) :

wiki language k articles September 2014 k articles July 2013 user >100e/m (mean January–June 2013) user >100e/M (mean June–August 2014)[24] k articles /superuser July 2013 k articles /superuser September 2014
en english 4594 4270 3281 3056 1,3 1,5
de german 1752 1603 1023 846 1,6 2,1
fr french 1540 1402 785 720 1,8 2,1
ru russian 1143 1020 659 519 1,5 2,2
es spanish 1122 1027 499 488 2,1 2,3
it italian 1140 1044 436 361 2,4 3,2
ja japanese 924 864 344 330 2,5 2,8
zh chinese 784 703 281 305 2,5 2,6
pl polish 1062 976 257 215 3,8 4,9
nl dutch 1789 1672 242 203 6,9 8,8
pt portuguese 838 786 188 152 4,2 5,5
uk ukrain 523 451 140 142 3,2 3,7
sv swedish 1891 1158 124 105 9,3 18
he hebrew 161 148 114 116 1,3 1,4
hu hungarian 266 243 114 104 2,1 2,6
ko korean 287 243 99 94 2,5 3,1
cs czech 303 269 93 77 2,9 3,9
ar arabic 318 235 88 93 2,7 3,4
fi finnish 354 327 81 81 4 4,4
fa persian 420 310 75 71 4,1 5,9
ca catalan 436 405 70 65 5,8 6,7
no norwegian (Bokmål) 429 388 69 63 5,6 6,8
tr turkish 234 213 59 59 3,6 4
vi vietnamese 1108 796 50 51 15,9 21,7
bg bulgarian 165 149 47 31 3,2 5,3

You notice the wikis with lots of botgenerated articles, but this is not my point here: More articles over time and not more users over time = problem to watch articles and maintain quality. In July 2013 every "superuser" would have to watch 1300 articles, to have all articles watched (by all 3281 "superusers"). In August 2014 every "superuser" would have to watch 1500 articles, to have all articles watched (by all 3056 "superusers"). We need watchers!

2) There is another aspect, that may be a problem. New users attention could be diverted by the more prominent colourful notifications (introduced in 2013). And while the notifications are about me-me-me (my edits, my conversations, my thanks, my status, my reverts, ...), the watchlist is about the articles, about actual Wikipedia content. In the old days, there was only the watchlist and the users talkpage - now the notifications could distract contributors from that. I found some research about the introduction of notifications in 2013, which seems to support my concerns that the competition for user attention between the "me-me-me-notifications-bling-icon" vs. "static watchlist-link" has harmful effects on productivity: meta:Research:Notifications/Experiment_1#Summary: Our results suggest that the presence of Notifications effectively increases the amount of activity that new users will engage in (more edits, more edit sessions and more hours spent editing). However, the effect of Notifications on the productivity of new users is unclear. On average, users with Notifications were less likely to make productive contributions to articles, but in our experiment, a few highly productive newcomers made up some of the difference. Our results also show that newcomers with Notifications enabled are more burdensome. They made more edits that were reverted by others and they were more likely to be blocked.

3) I think showing the word "watch" (or not) is the kind of small change that you don't notice if you have clicked the watchstar dozends of times, but that can have a real impact for how new users use Wikipedia and how much they are "dragged in" by the watchlist.

4) I think we should do A/B testing to find out if there is an effect for new users. It would be a very small change, there can't be any harm and the test would be limited to a certain period. What do you think?

5) Another way to make people notice the watch-star could be to display the watch-star on the Hovercard (see beta-features Hovercard, really cool feature). --Atlasowa (talk) 17:52, 25 February 2015 (UTC)

@Atlasowa: Today, my watchlist passed 20,000. Will this help lower the minimum for other people? --Redrose64 (talk) 19:42, 25 February 2015 (UTC)
Ha, I like you :-D --Atlasowa (talk) 21:34, 25 February 2015 (UTC)
Redrose64: Just saw that you're no. 419 of Wikipedia:Database_reports/Most-watched users, you're royalty! I definitely think that people should stop watching Little Barrier Island (~4000 watchers, Wikipedia:Database_reports/Most-watched_pages), go watch a bird! (prefererably botgenerated and from Africa) --Atlasowa (talk) 21:51, 25 February 2015 (UTC)
It's out of date. I now have 208 watchers, according to page information. --Redrose64 (talk) 22:01, 25 February 2015 (UTC)
Thank you! Surely we could replace the star with "Watch" or "Unwatch," as the case may be?? 22:47, 25 February 2015 (UTC) — Preceding unsigned comment added by GeorgeLouis (talkcontribs)
Little Barrier Island is the result of pagemove vandalism (see WP:STOCKS); the Main Page got moved to Hauturu/Little Barrier Island some time back, so everyone watching the Main Page ended up with both pages on their watchlists. Probably a lot of the watchers are no longer active, since we don't currently have a ton of active editors who were active when the event happened. Nyttend (talk) 02:32, 26 February 2015 (UTC)
Interesting to see that nobody notices that the word "Watch" outside of the context of MediaWiki is probably less 'informing' and meaningful (so even more mystery meat) than the 'star' icon is to all people. If I remember correctly, that was confirmed by user testing in 2009 and actually led the Vector team to switch away from that word to a more common representation that people know from bookmarks etc. —TheDJ (talkcontribs) 13:27, 26 February 2015 (UTC)
[citation needed] :-) TheDJ: link? --Atlasowa (talk) 22:18, 26 February 2015 (UTC),_questions_and_answers#Where_did_the_watch_tab_go? Still looking for the data, though. --Atlasowa (talk) 17:39, 27 February 2015 (UTC)

Wow. Many old-timers only dimly remember our pre-WP days, which is why software is tested on the innocent. So, the whole concept of article watching, is what newbies don't get. Once that's understood, the question of star or word becomes a small one. And we've stumbled into a slightly related topic, the poor interface for mobile. That's one reason why I seldom use my Android phone for editing, and not often my iPad. The idea of an intermediate level of interface, showing as much as my real computer does but not relying on hover box or tooltip (the distinction makes little difference) is appealing but our clever and industrious software developers are already 'way behind the likes of Facebook or GMail in serving the various platforms. It seems a bit much to add to their load. Jim.henderson (talk) 13:49, 26 February 2015 (UTC)

We are getting into some serious and arcane in-groupishness here. How and where do I make an official request to replace the star with a word or (better) a phrase? GeorgeLouis (talk) 17:15, 26 February 2015 (UTC)
phab:. --Redrose64 (talk) 17:17, 26 February 2015 (UTC)

"looking at your watchlist is the engine of Wikipedia" I have over 8000 pages on my watchlist. It's not quite as useful as you might image. :-) Maury Markowitz (talk) 00:23, 27 February 2015 (UTC)

Maury Markowitz, I'm dead serious about "watchlists = the engine of Wikipedia". The individual watchlist is a small cog in the machine, but together watchlists are the engine. Because they feed editor attention. We can see the effect of watchlists in "editing burst" at articles. Even after bots: articles show up in watchlists and are checked and edited by other editors afterwards. Editing is contagious :-) --Atlasowa (talk) 18:14, 27 February 2015 (UTC)

mw:Mobile_Beta/Watchlist/Logging#Conclusions :

Account creation hooks like the watchlist star are an effective way to draw more new users to sign up
Over half (56%) of new users creating an account on mobile came directly from the watchlist star CTA. This number is an underestimate of users coming from the CTA, since we were not logging users who first visited the login link from the CTA and then tapped on Create account from the login page.
New users may not understand or value the watchlist star feature as much as existing Wikimedians
The vast majority of one-time watchlist star users were brand-new Wikimedians who had registered via mobile. However, the vast majority of users who tapped the star more than once were existing users who already had a Wikimedia account.
Very few users are unwatching pages from their watchlist view
Either most users are not finding their watchlist view, or the unwatch-from-watchlist feature is not useful for those who do find it.
Overall, the watchlist star hook + account creation has proven to be a very effective new account creation funnel, helping arrest the year-over-year decline of new account creations
Since the full deployment of account creation and watchlist star to the mobile web, new account creations have held steady at about 800 global registrations/400 English Wikipedia registrations per day. These additional account are pushing the hourly registration rates up to 2012 levels.

Maybe we should have:

  • Mw-watch-icon.svgWatch
  • Mw-unwatch-icon.svgUnwatch and above:
  • Watchlist icon.svgWatchlist

And when you click watch, the star starts *spinning* AND above the watchlist icon should *blink* or *glow*, so that you see these things are connected. --Atlasowa (talk) 17:53, 27 February 2015 (UTC)

Automatic capitalization of title-initial Unicode characters

Has the automatic capitalization of initial letters in titles been changed recently? ɱ is no longer autocapitalized to . Compare this to ɔ, which correctly becomes Ɔ. Gorobay (talk) 15:23, 25 February 2015 (UTC)

Examples, please. Your links are redirects to articles on the characters. --  Gadget850 talk 15:26, 25 February 2015 (UTC)
The capitalized form of ⟨ɱ⟩ is ⟨Ɱ⟩. Therefore, ɱ should be the same page as , but it is not. Similarly, redirects to Insular S, but its lowercase form () does not. Similarly, is an article, but its lowercase form does not exist. That means that some characters are not being capitalized properly. Gorobay (talk) 15:49, 25 February 2015 (UTC)
Look under the title of the target articles — go to ɔ and you correctly see (Redirected from Ɔ) (because it capitalises the letter), but for some weird reason, going to ɱ provides a message of (Redirected from ɱ). Or click the link, to examine the redirect directly; you'll see an uppercase Ɔ and a lowercase ɱ for the page titles. Nyttend (talk) 17:17, 25 February 2015 (UTC)
Couple of years back ɱ (talk · contribs) had a lot of trouble because the system suddenly started uppercasing their username to  (talk · contribs). I believe they couldn't edit their user page or access their contributions, and other things were not possible. --Redrose64 (talk) 17:21, 25 February 2015 (UTC)
It seems that the lowercase user was renamed to uppercase in early 2013, but the lowercase user still seems to exist with zero edits on other projects. Very confusing. --Stefan2 (talk) 17:26, 25 February 2015 (UTC)
Found it, Wikipedia:Village pump (technical)/Archive 105#Link in history says user does not exist. --Redrose64 (talk) 19:34, 25 February 2015 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Capitalization only works with character pairs encoded in Unicode 4.0. I guess some MediaWiki config file thinks it’s still 2003. However, Utf8Case.ser (the version in MediaWiki 1.25wmf17) maps ⟨ɱ⟩ to ⟨Ɱ⟩, so it should still work. What else controls capitalization? Gorobay (talk) 20:32, 25 February 2015 (UTC)

I tested this on my local test installation of the MediaWiki software and it works fine (the page title "ɱ" automatically transforms to "Ɱ"). There must be something wrong with the way WMF wikis in particular are configured. — This, that and the other (talk) 23:44, 25 February 2015 (UTC)
The function uc (which I assume is the right function) looks for PHP’s built-in mb_strtoupper before falling back to Utf8Case.ser. Wikipedia currently uses HHVM 3.3.1, which includes mb_strtoupper. HHVM 3.3.1 does not support the latest version of Unicode. What version of PHP or HHVM are you using? Gorobay (talk) 04:32, 26 February 2015 (UTC)
Gorobay, you can find a list of (most) version numbers at Special:Version. Whatamidoing (WMF) (talk) 23:47, 26 February 2015 (UTC)
Right, that’s how I knew Wikipedia uses HHVM 3.3.1. I was asking This, that and the other for specifics about their local test. Gorobay (talk) 02:20, 27 February 2015 (UTC)
I use Zend PHP version 5.5.15. Looks like we need to get someone to look at WMF's build of HHVM. I filed phab:T91056 to track the issue. — This, that and the other (talk) 11:22, 27 February 2015 (UTC)

Viewing KML data in Google Maps

It appears that links to - such as the one titled "Map all microformatted coordinates" in {{GeoGroup}} - will stop working soon. I've started a thread at Template talk:GeoGroup#Viewing KML data in Google Maps. --Redrose64 (talk) 19:55, 25 February 2015 (UTC)

PDF/book creator

For the past several days, every time I try to download and generate a PDF file for an article(s) I get a Wikimedia Foundation Error result. Also, every time I try to generate a pdf file with one column I get a Rendering failed result. When I switch to two columns there are no problems -- until recently, that is. As I said, I'm getting a Wiki'Foundation error all the time now. -- Gwillhickers (talk) 23:12, 25 February 2015 (UTC)

Is this the same as #Download as PDF failing above? --Redrose64 (talk) 23:21, 25 February 2015 (UTC)

Tables just changed (using monobook)

I use monobook, and the default cell height and padding seem to have changed. The font size of the text appears to be the same, but the cells are definitely bigger. Where could a change have been made that would affect this for me? -Niceguyedc Go Huskies! 01:59, 26 February 2015 (UTC)

It's the same for me on Vector. Also, the bullets on bulleted lists are smaller (like a middot) and appearing to be at the bottom of the line instead of the usual larger size centered vertically on the line. Imzadi 1979  02:25, 26 February 2015 (UTC)
OS and browser please? -- [[User:Edokter]] {{talk}} 10:21, 26 February 2015 (UTC)
The bullets are now SVG instead of PNG. There is one known issue where Webkit on iOS does not size the bullets correctly. Webkit bug report. -- [[User:Edokter]] {{talk}} 10:28, 26 February 2015 (UTC)
I'm using Safari version 8.0.3 on MacOS X Yosemite (10.10.2). Firefox (v. 14.0.1) does not have the bullet size issue, however the bullets are still slightly off center vertically, putting them slightly too low, but not as low as in Safari where the are at the bottom of the line. In Chrome (v. 40.0.2214.115), the appearance is the same as Firefox: right size but slightly too low on the line. Just for kicks, I also looked in Opera (v. 12.12 ), and it's the same as Chrome and Firefox. The bullets look the same in Safari on an iPad running iOS 8.1.3 as they do on Safari running on the desktop. Imzadi 1979  15:46, 26 February 2015 (UTC)

@Edokter: I'm using Windows 7 and Firefox 36. I don't actually notice anything different with the bullets, just the extra size of rows in tables. -Niceguyedc Go Huskies! 14:06, 26 February 2015 (UTC)

@Imzadi1979, Niceguyedc: The table cells for .wikitable have had their padding increased... doubled even. I found only this commit, but cannot find a accompanying task that discusses this change. (The bullets only affects Vector.) -- [[User:Edokter]] {{talk}} 14:43, 26 February 2015 (UTC)
Yep, the previous padding was pretty tight. You can see examples at testwiki:Wikitable padding. This change shouldn't have broken anything. Please provide links here or file Phabricator tasks if you see issues. --MZMcBride (talk) 15:50, 26 February 2015 (UTC)
While we are on this, where is the repository for shared.css? The catalog still links to SVN, and I can't find main on git. --  Gadget850 talk 16:02, 26 February 2015 (UTC)
[25] this? It's on mediawiki core repo. Glaisher (talk) 16:09, 26 February 2015 (UTC)
Thanks! Since I keep referring to it, created {{shared.css}}. --  Gadget850 talk 16:20, 26 February 2015 (UTC)
Is this a permanent change? I'm working with tables all the time on wikipedia and am quite upset by this change. Bigger tables don't even fot on a page anymore. Personally I think the tables harder to read and it looks untidy. Isn't there any way too make the table cells the size you want? Jahn1234567890 (talk) 00:45, 27 February 2015 (UTC)
@Edokter, MZMcBride: I also agree that the change should be reverted - Jahn1234567890's note on its untidy look is well take. It is also harder to follow visually, especially when zoomed in - as I have to because of vision difficulties - as the distance between the text and the lines is increased. Finally, vertical vs. horizontal whitespace is now unbalanced, as dmeonstrated in the small table at List of Governors of Iowa#Living former governors. – Philosopher Let us reason together. 01:48, 27 February 2015 (UTC)
Noted this through the notably wider infobox element, which contains a 6-column table. (see Uranium). Considerably widened. 1. Not a bad thing per se, except that relative image size now changed (i.e. it did not change absolutely), and there might be a guideline saying something about ideal infobox width ("33% body pagewidth max"?). The infobox now has fewer unforced line-wraps, but its whitespace is growing and growing. I hope this is within grand page-design philosophy. 2. Then I went to check a table that needs all 100% page width: {{Periodic table}} in Periodic table. No effect so OK, because it has cellpadding= set (without this, the wider padding is breaking bad, undesired & useless). This leads to these points: a) are there similar tables (using & needing 100% width) that are gravely affected this way, because they are without cellpadding set?, and b) if I remember correct, cellpadding= is deprecated. Though this depends on it. 3. Btw, is the padding in the infobox enlarged too (mostly visible with section headers)? Conclude: nothing broken so far for me, some questions left. -DePiep (talk) 08:14, 27 February 2015 (UTC)
{{Periodic table}} should not be affected because it's not using .wikitable, not because of the obsolete attributes being used. I did replace those attributes with proper CSS. -- [[User:Edokter]] {{talk}} 09:34, 27 February 2015 (UTC)
I get this. (Had to squeeze out some ws). -DePiep (talk) 10:45, 27 February 2015 (UTC)
What is this central point where deprecated code (like this) is listed? I only meet such statements off and on. -DePiep (talk) 20:28, 27 February 2015 (UTC)
Wikipedia:HTML5. SiBr4 (talk) 21:09, 27 February 2015 (UTC)
My biggest problem with the table change is that this affects every single table on wikipedia. I don't understand why it was changed in the first place. The previous table size was just fine. And if you found that padding too small you could adjust the width by yourself. Now you have no option at all. Jahn1234567890 (talk) 14:08, 27 February 2015 (UTC)
Yes. Why not make it 8px? -DePiep (talk) 20:28, 27 February 2015 (UTC)

Hi Jahn1234567890. You can trivially reduce wikitable padding in your personal user CSS. In general, I think the increased padding looks better. The cited example above (List of Governors of Iowa#Living former governors) looks good to me. --MZMcBride (talk) 20:47, 27 February 2015 (UTC)

Is there a central place where this whitespace philisophy is discussed? 'I think .. looks better' is not enough to me. -DePiep (talk) 20:52, 27 February 2015 (UTC)
I dunno about a central place. testwiki:Wikitable padding is where I did my testing. I don't think anything broke and there seems to be general consensus that the increased padding (0.3em 0.4em instead of 0.2em) is an improvement. There are quite a few studies that suggest that adding whitespace improves readability. Maybe that would be a better argument? --MZMcBride (talk) 20:58, 27 February 2015 (UTC)
I'm lost. "I dunno", "don't think anything broke", "there seems to be general consensus" (where, where, WHERE I repeat). If this is the way classes are set, why are we talking anyway? Who cares. (and let me note that you still did not address my specific points). Make it 8px, I say. -DePiep (talk) 21:04, 27 February 2015 (UTC)
@MZMcBride: For results tables like this Dave Marcis the change makes tables like this look really untidy. Personally I'm unhappy with this change because with results tables in general this change makes those tables unnecessary big. But how would reduce wikitable padding in my personal user CSS? I haven't worked with this before. Jahn1234567890 (talk) 21:28, 27 February 2015 (UTC)
Before I forget. Why was the table padding changed? It was just fine the way it was. I mean this change effects every wikitable on wikipedia. I think doubling the padding is a way to big change Jahn1234567890 (talk) 22:02, 27 February 2015 (UTC)

Cremation or burial?

Why can't I delete Cremation or burial?? When I choose delete it just reloads the page. I can delete other pages but not this one. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 07:28, 26 February 2015 (UTC)

Not quite sure. I just did and it worked fine. Something with your browser or personal Javascript maybe? Seraphimblade Talk to me 08:11, 26 February 2015 (UTC)
That's strange I deleted another page with no problem. I'll just put it down to sunspots as they get blamed for almost everything in the Arctic. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 08:19, 26 February 2015 (UTC)
I'm guessing it's a problem with '?' which usually indicates a query string in url's. MediaWiki encodes '?' in pagenames as %3F to avoid confusion but maybe your browser is still confused. Which browser? Does the same happen for Quo vadis? PrimeHunter (talk) 19:30, 26 February 2015 (UTC)
I was using Chrome Version 40.0.2214.115 on Ubuntu 14.04 but I just tried in Firefox 36.0 on the Quo vadis page and got the same result. This time I checked the url and noticed it was I'll have to try later on Windows. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 23:01, 26 February 2015 (UTC)
@CambridgeBayWeather: That really is odd, since I'm using Ubuntu 14.10 with Chromium 40.0.2214.111. Are you using Twinkle or any other scripts, or just the regular Mediawiki delete button? Seraphimblade Talk to me 01:22, 27 February 2015 (UTC)
It's indeed an issue with '?' but probably not in your browser. Your link doesn't work for me either. How do you reach that link and what is your skin? I'm in Vector and click the "More" tab and then "Delete". That gives me which works. Your url structure works on page names not containing '?', for example It may be a MediaWiki bug that a query part cannot be added to a url of form It also fails for as non-admins can test. The "View history" tab gives me which does work, but I think should also have worked, like works. MediaWiki apparently chokes on the %3F? combination where %3F is an encoded '?' ending the pagename, and '?' is the start of a query part. Or maybe there is some general url rule I'm unaware of which disallows '%3F?' in url's. PrimeHunter (talk) 01:49, 27 February 2015 (UTC)
The %3F? combination works on this wiki with an old MediaWiki version: says MediaWiki: 1.5.8. PrimeHunter (talk) 02:24, 27 February 2015 (UTC)
The problem is not restricted to '?' at the end of the pagename. should have produced the page history of ? Nycticebus linglom. PrimeHunter (talk) 02:56, 27 February 2015 (UTC)
User:PrimeHunter. To get the non working link I just followed the original Quo vadis? link you provided. I then clicked on the delete and it reloaded the page with the non working link. I'm using Vector as well. I notice you said that you clicked on the "More" tab and then "Delete". On the "More" I see the only option is "Purge". The option to delete is on the "Page" tab and says "Delete page". Also the works for me as well. I looked through my deletion log and found this, I did see at least one more with the ? at the end, and this with the ? in the middle. So at one time I was able to delete pages with the ? at the end. The other links on your 01:49 post all work the same for me as they did for you. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 03:19, 27 February 2015 (UTC)
The "Page" tab is not part of MediaWiki. It is made by "Add Page and User dropdown menus to the toolbar" at Special:Preferences#mw-prefsection-gadgets. The gadget is disabled by default. I have tried to enable it and get the same non-working url as you on the Page tab. The gadget uses MediaWiki:Gadget-dropdown-menus.js which uses MediaWiki:Gadget-dropdown-menus-vector.js for Vector users, but the bug is in MediaWiki and should be fixed there. Question marks in pagenames are rare and I'm not sure it's worth coding the gadget to work around the bug by using url's with /w/index.php?title= instead of /wiki/. PrimeHunter (talk) 03:33, 27 February 2015 (UTC)
OK that was it. I removed the gadget and was able to delete I found that with the gadget enabled it is possible to move the page and not leave a redirect. That deleted the ? page and then of course I was able to delete the page without the ?, Given that there are several things I like about the gadget and the very few times that the ? comes up I'll leave it enabled and use the move workaround. Thanks for all your help. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 03:48, 27 February 2015 (UTC)
Moves are made with a special page and not a query string, so the bug does not interfere. Protect and Purge on the Page tab are affected. It probably also affects several other scripts and tools. I'm not proficient with Phabricator. Can somebody see if it's there, and add it if not? PrimeHunter (talk) 04:18, 27 February 2015 (UTC)
I'm not seeing a problem with the Protect from the page tab. It worked fine yesterday. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 04:58, 27 February 2015 (UTC)
On a pagename with a question mark? The bug is only known to affect that. PrimeHunter (talk) 05:11, 27 February 2015 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────I can fix this for MediaWiki:Gadget-dropdown-menus-vector.js, but I do not maintain the non-vector version if that is what you are using. Because of the same bug all internal links involving a page name with a ? will not work, so it's worth fixing for the interim I think. MusikAnimal talk 06:23, 27 February 2015 (UTC)

Should be fixed now. Thanks for the report! MusikAnimal talk 07:05, 27 February 2015 (UTC)
This should be fixed in core though... -- [[User:Edokter]] {{talk}} 12:38, 27 February 2015 (UTC)
Thanks User:MusikAnimal that works now. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 16:18, 27 February 2015 (UTC)

New CSS in Firefox

Hi all; if anybody here uses Firefox, but has not yet upgraded from Firefox 35 to FF 36, please describe the appearance of the underline in this text. --Redrose64 (talk) 09:57, 26 February 2015 (UTC)

I'm still on 35, on Ubuntu. Here's what it looks like for me. — Mr. Stradivarius ♪ talk ♪ 10:07, 26 February 2015 (UTC)
Chrome 40 and FF 35; it is just a straight black underline. -- [[User:Edokter]] {{talk}} 10:10, 26 February 2015 (UTC)
Updated to FF 40 now... Spell checker. -- [[User:Edokter]] {{talk}} 10:19, 26 February 2015 (UTC)
Thanks, I thought as much: I upgraded from FF 35 to FF 36 overnight, and what I now see is a wavy red underline. This means that as from version 36, Firefox now implements CSS Text Decoration Module Level 3 but don't rely on it, since it's still a W3C Candidate Recommendation, not yet a W3C Recommendation. --Redrose64 (talk) 10:20, 26 February 2015 (UTC)
FF34 still doesn't show the text-decoration-color and text-decoration-style, consistent with the MDN compatibility table. (talk) 10:24, 26 February 2015 (UTC)
Also noteworthy: FF36 finally fixed their longstanding gradient bug. -- [[User:Edokter]] {{talk}} 10:30, 26 February 2015 (UTC)
Pale Moon 25.2.1 (Gecko/20150122, its the 64-bit non-chromified Firefox, highly recommended) still see the straight black underline. — Dispenser 16:30, 26 February 2015 (UTC)
Chrome 40.0.2214.115m (current version) and Opera 12.17 (also current) both show straight black. Chrome's Inspect element feature says "Unknown property name" for both text-decoration-color: and text-decoration-style:. So it looks like Firefox is ahead of the others for those properties. --Redrose64 (talk) 16:57, 26 February 2015 (UTC)
Note that Firefox has supported these properties since V6, but prefixed with -moz-. -- [[User:Edokter]] {{talk}} 17:32, 26 February 2015 (UTC)

Save button placement

I frequently find that after editing, in trying to hit the "save" button, I will inadvertently hit the adjoining link to CC-BY-SA-3.0 License. Can we somehow provide a little safe space around what is arguably the most important widget on Wikipedia? LeadSongDog come howl! 13:53, 26 February 2015 (UTC)

@LeadSongDog: What I did was to add
div#editpage-copywarn { display: none; }
to Special:MyPage/common.css. This hides the block of text from 'By clicking the "Save page" button' down to 'a hyperlink or URL is sufficient for CC BY-SA 3.0 attribution.' --Redrose64 (talk) 14:24, 26 February 2015 (UTC)
Most users probably have the links in MediaWiki:Wikimedia-copyrightwarning on the first line to the right of the buttons in the edit window. I don't think we should add spaces in the interface for everybody just to avoid that some users get a link in the vicinity of a button. PrimeHunter (talk) 15:18, 26 February 2015 (UTC)
That's why I suggested personal customisation. But MediaWiki:Wikimedia-copyrightwarning isn't to the right of the buttons, it's directly above, in both Vector and MonoBook. If LeadSongDog doesn't want to hide that block of text, they can increase the gap below it with a rule like
div#editpage-copywarn { margin-bottom: 2em; }
or perhaps
input#wpSave { margin-top: 2em; }
- again, put the chosen rule in Special:MyPage/common.css. --Redrose64 (talk) 15:30, 26 February 2015 (UTC)
Thank you for the suggestions on simplifying my life, but of course personal customization does nothing for the vast majority of users who are not logged in. Can we not simply use the same space presently above the copyright warning, but put it below it instead? The problem is particularly egregious when working in Safari on the iPad with fat fingers.... It probably runs afoul of some wp:accessibility principles too. LeadSongDog come howl! 16:11, 26 February 2015 (UTC)
The problem would only affect users working on 4:3 resolutions as far as I can tell, on 16:9 and 16:10 resolutions there is no link close to the save page button. Sam Walton (talk) 16:17, 26 February 2015 (UTC)
Perhaps, but 1024x768 is supposed to be our most basic viewport size. Looking at the WCAG, one finds that we've missed G178: Providing controls on the Web page that allow users to incrementally change the size of all text on the page up to 200 percent. Though that wouldn't be the ideal solution to this particular issue, it really should be addressed. More to the point, though, is G155: Providing a checkbox in addition to a submit button. We fall afoul of that (on every viewport size) simply by making the irrevocable agreement on "Save page" not require a dismiss checkbox. LeadSongDog come howl! 17:03, 26 February 2015 (UTC)
LeadSongDog, can you clarify your request? Do you want an extra blank line underneath the copyright notice, or do you want the copyright notice underneath the Save button?
Also, changing anything about the copyright statement requires approval from Legal, so we'd have to check with them before anything could be done. Whatamidoing (WMF) (talk) 00:01, 27 February 2015 (UTC)
Not suggesting any change to the notice, just looking for some space above the "Save page" button to separate it from the CC BY-SA 3.0 License link. If vertical space is an issue, reducing the gap below "Watch this page" or below the "Save page" would do it. LeadSongDog come howl! 01:20, 27 February 2015 (UTC)
I'm not a lawyer and don't work for WMF but I guess the legal concern is that By clicking the "Save page" button, you agree to... should be close to the "Save page" button so contributors are clearly warned of what they agree to. The text also starts above the button for me. Earlier I meant that the part containing the links is not near the Save button on my screen where the line wraps after the last link on "GFDL". On narrow screens/windows or with large fonts the line may wrap earlier and place a link near the Save button. PrimeHunter (talk) 02:40, 27 February 2015 (UTC)
Well that's the real argument for having a separate checkbox for "I understand" before enabling the save page button, but that's a rather larger change than 2 or 3 en of white space. LeadSongDog come howl! 03:10, 27 February 2015 (UTC)

Colors in vector skin?

Hello, I need some help please (Windows XP, FF 36, Vector skin). For some reason all colors within my Wikipedia windows are brighter and/or messed up. For example: WP:PR usually had a light green background color for me, but now is very light gray, almost white. The documentation box in template:cite web was light green, but is now very light blue. Project banners on talkpages have been turquiose / light greenish and are now bright yellow. The Wiki browser page as a whole "looks" brighter. Any idea, where to look for such settings or how to reset them to the "old" status? (I tried to reset brightness and contrast on my monitor and graphic settings, but with no success). GermanJoe (talk) 14:36, 26 February 2015 (UTC)

I have Win 8.1, FF36 and Vector. I see no changes. {{documentation}} still has the same light green/blue background.      --  Gadget850 talk 15:01, 26 February 2015 (UTC)
Thanks for checking, Gadget850. I did a complete color recalibration in my monitor setup and that somehow fixed the problem. I still don't know, how the settings got corrupted to begin with, but never mind - it's OK again :). GermanJoe (talk) 15:20, 26 February 2015 (UTC)
Did you upgrade graphics drivers (either manually or through Windows Update)? I had this problem about 6 years ago on XP with new NVidia drivers defaulting to some whacky color settings. --Ahecht (TALK
) 20:36, 26 February 2015 (UTC)
Only one minor non-graphical update yesterday (that I know of), but I'll check this more closely. Thanks for the tip. GermanJoe (talk) 04:39, 27 February 2015 (UTC)


Can somebody give me a link about this kind of patterns: %s%((.-)%) (example from Template:Title disambig text)? I would like to understand them and not ask questions "how to do that or that" :) --Edgars2007 (talk/contribs) 14:42, 26 February 2015 (UTC)

The template says {{#invoke:String|match|{{{1}}}|%s%((.-)%)||-1|ignore_errors=true}}. That means it uses the match function of Module:String. The documentation at Module:String#match has three links under "For information on constructing Lua patterns". PrimeHunter (talk) 15:06, 26 February 2015 (UTC)
So obvious. Thanks! --Edgars2007 (talk/contribs) 15:33, 26 February 2015 (UTC)
Sorry, I tweaked pattern in the template, and then protected it, as I noticed it was used in Template:Disambiguation which has more than 100,000 transclusions. Hopefully that was something along the lines of what you were looking to do... — Mr. Stradivarius ♪ talk ♪ 03:14, 27 February 2015 (UTC)

@Mr. Stradivarius: I'm assuming you didn't bother testing that one.

  • Original on "Foo (bar)": {{#invoke:String|match|Foo (bar)|%s%((.-)%)||-1|ignore_errors=true}} -> bar
  • Your version on "Foo (bar)": {{#invoke:String|match|Foo (bar)|^.*%s%((.-)%)||-1|ignore_errors=true}} ->

You broke it. Reverted. And for the record, the "-1" was already there to get the last match. Dragons flight (talk) 04:04, 27 February 2015 (UTC)

@Dragons flight: Oops. Sorry, yes, I should have tested that properly. Thanks for catching it. — Mr. Stradivarius ♪ talk ♪ 04:18, 27 February 2015 (UTC)
No biggie. Though, I did get a kick out of the fact you broke that template and then immediately protected the broken version. Dragons flight (talk) 04:28, 27 February 2015 (UTC)
Does that qualify for WP:STOCKS? I can see the caption now - "Mr. Stradivarius for the when-it's-broken-it-stays-broken award"... — Mr. Stradivarius ♪ talk ♪ 04:45, 27 February 2015 (UTC)
In case you are curious, the problem appears to be that the use of a match selection index (in this case, "-1") is incompatible with the use of the start anchor tag "^".
  • {{#invoke:String|match|Foo (bar)|^.*%s%((.-)%)|||ignore_errors=true}} -> bar
That's a pretty subtle thing to miss, but does show the value of double checking the result. Dragons flight (talk) 04:47, 27 February 2015 (UTC)

Is there a such parser function/magic word?

I'm not sure exactly where to ask this, so I thought this would be the best place: Is there a magic word/parser function that automatically detects the target of a redirect (and returns that value) if the page which the magic word/parser function is placed is a redirect? I'm just wondering since there's an edit I would like to perform on {{Db-redirnone}}, but I can only do it properly if that magic word/parser function exists. Steel1943 (talk) 20:56, 26 February 2015 (UTC)

I don't think so, unless H:MW is out of date. --Redrose64 (talk) 21:05, 26 February 2015 (UTC)
(edit conflict) No magic word AFAIK, though there is a Lua script that does that. SiBr4 (talk) 21:08, 26 February 2015 (UTC)
@SiBr4: Thanks for letting me know about that Lua module. However, I tested it out, and I cannot use it for my intended purpose since I cannot use the parser function {{{FULLPAGENAME}}} for the "redirect-page-name". I'm going to ask this on the module's talk page. Thanks again for finding this. Steel1943 (talk) 21:55, 26 February 2015 (UTC)
Never mind SiBr4 ... it work as I need it to (after a 2nd test). Thanks again! Steel1943 (talk) 21:59, 26 February 2015 (UTC)
Neither using the page the module is on as parameter nor using magic words fails by itself. However, placing any text above the redirect breaks the redirect, so the module returns the current page name. Therefore you'll need something else for the deletion template to work. SiBr4 (talk) 08:42, 27 February 2015 (UTC)

What is my mouseover telling me?

On Safari, when I hover over a inter-wiki link I see a pop-up that appears. The text in the popup is identical to the link text - it does not display either the URL or the "real" link below it. For instance, the link to Point Magu in one of my articles points to Naval Air Station Point Mugu, but this does not appear in the popup. Anyone know what this is and what it's for? Maury Markowitz (talk) 23:30, 26 February 2015 (UTC)

I suspect you are using wrong terminology. Please post a link to the article with your example, and say where on the article you see it. PrimeHunter (talk) 23:42, 26 February 2015 (UTC)
Maury Markowitz, are you using Vector (default) or Monobook as your Wikipedia skin? WhatamIdoing (talk) 00:12, 27 February 2015 (UTC)
I think monobook. The article is Nike Zeus, look for Point Magu. Maury Markowitz (talk) 00:14, 27 February 2015 (UTC)
When I just looked at the page LIM-49 Nike Zeus, and placed my mouse over Point Mugu, the pop-up worked (showing a redirect to Point Mugu, California and the first paragraph of that article). If you are you saying that the popup is just a text repeat of the text of the link, what may be happening is that the page hasn't completely loaded, or the server is busy; at least, that's when it happens to me from time to time. --Arxiloxos (talk) 00:25, 27 February 2015 (UTC)
The report is very confused. An interwiki link is a link to another wiki. This is apparently about a wikilink, i.e. a link to another English Wikipedia page. Nike Zeus is not an article, it is a redirect to LIM-49 Nike Zeus. The string "Point Magu" does not occur in LIM-49 Nike Zeus. The string "Point Mugu" occurs twice. Once without being linked and once as an unpiped link Point Mugu which redirects to Point Mugu, California and not to Naval Air Station Point Mugu. I guess this is what really happens for Maury: On the article LIM-49 Nike Zeus he hovers over "Point Mugu" in the "Testing" section and if he clicks it then he goes to Point Mugu, California, but the mouseover only says "Point Mugu". I guess Arxiloxos has enabled either "Navigation popups" at Special:Preferences#mw-prefsection-gadgets or "Hovercards" Special:Preferences#mw-prefsection-betafeatures, and Maury Markowitz has neither. If you have neither then you get the same as logged out users: A small box with the name of the link target and nothing else. The link in LIM-49 Nike Zeus says [[Point Mugu]] which renders as Point Mugu. The small box says "Point Mugu" exactly as it's supposed to. Point Mugu is a redirect to Point Mugu, California but the small box doesn't examine that. If it had been a piped link [[Point Mugu, California|Point Mugu]] which renders as Point Mugu, then the small box would have said "Point Mugu, California". PrimeHunter (talk) 00:58, 27 February 2015 (UTC)

Moving over a salted page (redux)

I'd like to revive this thread.

Summary: When an admin moves a page to a salted target, there is no warning that the page is salted. (I tested it myself and saw no warning.) I'm not sure if the target remains salted.

Case in point: [26], [27]

A warning box would have made User:Necrothesp aware of an old AfD. He then would likely have made others aware of that at the new AfD.

Can this be fixed? Bug report? Thoughts? Anna Frodesiak (talk) 01:09, 27 February 2015 (UTC)

To your q "I'm not sure if the target remains salted", no - because salt can only be applied to the title of a non-existent page; once a page is moved to that title, it's no longer the title of a non-existent page. --Redrose64 (talk) 11:08, 27 February 2015 (UTC)
Hi, Redrose64. I see. And if it is deleted again? Is the redlink then salted again for non-admins? Anna Frodesiak (talk) 21:51, 27 February 2015 (UTC)
No, it's not; and I've just confirmed it at User:Cryptic/test1 (edit | talk | history | links | watch | logs). —Cryptic 22:02, 27 February 2015 (UTC)
Thank you, Cryptic. So, how do we get this fixed. This is the second post about this, and it seems to be getting just as ignored as the first one. Anna Frodesiak (talk) 22:06, 27 February 2015 (UTC)
Posted at
Anna Frodesiak (talk) 22:34, 27 February 2015 (UTC)

Bullet points

Wp bullet issue.png

When you look at the bullet points in for instance this AFD Wikipedia:Articles for deletion/New Downs - Are they extremely tiny ?,
As you can see from the picture they're absolutely tiny for me so I'm not sure if something here's changed or it's something to do with my laptop/chrome settings?,
Thanks, –Davey2010Talk 03:33, 27 February 2015 (UTC)

They appear at the normal size for me. — Mr. Stradivarius ♪ talk ♪ 03:35, 27 February 2015 (UTC)
There is some discussion of this at the top of #Tables just changed (using monobook). – Philosopher Let us reason together. 03:40, 27 February 2015 (UTC)
Thanks Mr. Stradivarius,
Philosopher - It actually appears to be a Chrome issue I think ?, I tried IE and they're normal but when I try Chrome logged out it still seems tiny, The font settings are all normal, I'll wipe everything and see if that does the trick, –Davey2010Talk 03:46, 27 February 2015 (UTC)
Forgot to say I'm using Vector, Anyway nope all still the same, Well it looks like I partially have the Monobook issue...Just in Vector Face-grin.svg, Ah well thanks anyway ) –Davey2010Talk 04:44, 27 February 2015 (UTC)
It's a Webkit issue; Chrome fixed this last year (in Blink), so that should not be a problem (unless you have a really old Chrome version). -- [[User:Edokter]] {{talk}} 09:43, 27 February 2015 (UTC)
Hi Edokter - Nope I'm using the latest version as far as I know (34.0.1847.116), Thanks, –Davey2010Talk 17:35, 27 February 2015 (UTC)
Davey2010, that is old! The latest version is 40. -- [[User:Edokter]] {{talk}} 17:47, 27 February 2015 (UTC)
Yes, as I noted at #New CSS in Firefox above, Chrome 40.0.2214.115m is current version. --Redrose64 (talk) 17:51, 27 February 2015 (UTC)
Edokter Eh seriously?, I've been updating chrome the moment the 3 bars go green so how on earth could I have gone from using updated versions to old ?.....Unless without me knowing Chrome hasen't been updating at all for quite some time?, I really don't no!, Anyway thanks for solving the mystery ) –Davey2010Talk 18:13, 27 February 2015 (UTC)
By the looks of it my browser hasen't updated itself since April 2014 ..... Great!, Anyway thanks all for your help :) –Davey2010Talk 18:24, 27 February 2015 (UTC)

Linking to IPV6 user accounts

[[User|2602:304:b1ae:8970:2186:8b44:f7ad:ef34]] results in this 2602:304:b1ae:8970:2186:8b44:f7ad:ef34. The text is the IP, but the link goes to User. Oiyarbepsy (talk) 05:43, 27 February 2015 (UTC)

Yes, that's how piped links work. Did you mean {{user|2602:304:b1ae:8970:2186:8b44:f7ad:ef34}}, which produces 2602:304:b1ae:8970:2186:8b44:f7ad:ef34 (talk · contribs)? Regards, Orange Suede Sofa (talk) 05:48, 27 February 2015 (UTC)
Or perhaps you meant [[User:2602:304:b1ae:8970:2186:8b44:f7ad:ef34]]User:2602:304:b1ae:8970:2186:8b44:f7ad:ef34 - colon, not pipe. --Redrose64 (talk) 11:10, 27 February 2015 (UTC)
Doh, now I feel like an idiot. Oiyarbepsy (talk) 19:43, 27 February 2015 (UTC)

Template:Main - appearance (or lack thereof) on mobile browsers

It seems that {{main}} is hidden on mobiles, due to site CSS. I suggested personal CSS to unhide it, but apparently that doesn't work. Please discuss at Template talk:Main#Appearance (or lack thereof) on mobile browsers. --Redrose64 (talk) 16:11, 27 February 2015 (UTC)

More generally, all hatnotes (specifically, all elements with the hatnote CSS class) are hidden unless the display width is large enough. This means important navigation information is missing for mobile users who don't think to (or can't) rotate the display to a landscape configuration. Hairy Dude (talk) 16:26, 27 February 2015 (UTC)

username change, and now I can't log in!!!

I asked for a username change from EmeraldRS to Emerald-wiki. It says the change has been carried out but I can't log in with my old or new username. I get a message with the new username saying my account is being renamed or merged. Is there some step that got missed? Help! (talk) 17:35, 27 February 2015 (UTC)

The rename was an hour ago [28] and your account has nearly 1000 edits in total. Try again later. PrimeHunter (talk) 17:52, 27 February 2015 (UTC)

If subpages in mainspace are "disabled", why aren't they disabled?

Wikipedia:Subpages tells us that "in main namespace (article namespace) ... the subpage feature has been disabled in the English Wikipedia". So how could a page such as Barbara Borts/Temp get created? It's the second one of these I've come across in the last few days (editors apparently find it counter-intuitive to work on a draft in talkspace). Might it be an idea to actually disable mainspace subpages if people aren't supposed to make them? Or limit the capability to admins or something? Justlettersandnumbers (talk) 17:54, 27 February 2015 (UTC)

"disabled" does not mean that pagenames with '/' are impossible. It just means they are treated like any other mainspace pagename, and the features associated with subpages do not apply. For example, Barbara Borts/Temp has no automatically added link to Barbara Borts at the top. Compare to Talk:Barbara Borts/Temp which does have a link to Talk:Barbara Borts. The talk page is a subpage but the mainspace page is not. This is admittedly confusing. PrimeHunter (talk) 17:59, 27 February 2015 (UTC)
I don't know how common mistaken "subpages" in mainspace are but it would be possible in MediaWiki:Titleblacklist to limit creation of '/' in mainspace to admins. There are many valid reasons for '/' in article titles, like OS/2 and 9/11 Commission, so it would inconvenience many non-admins. PrimeHunter (talk) 18:08, 27 February 2015 (UTC)
Thanks for the reply. Yes, I see (and knew) that names with a slash are possible; I too am unsure how often the mistake is made, I just happen to have seen it twice in a short space (both times experienced editors rewriting copyvio pages). It may be better to live with that level of background noise. But what is easily fixed is the documentation: if subpages are not disabled, we shouldn't really be saying that they are. If what we actually mean is "mainspace pages containing a slash character do not become subpages; instead, the whole name is treated as the pagename", then that might be a better way of explaining it. Justlettersandnumbers (talk) 20:59, 27 February 2015 (UTC)
Go forth and update that documentation. --Izno (talk) 22:11, 27 February 2015 (UTC)
But they are disabled. Subpages are a feature which can be enabled or disabled in each namespace with mw:Manual:$wgNamespacesWithSubpages. It's called enable and disable in the MediaWiki documentation and those are the common and perfectly fine names for features which can, well, be enabled or disabled. It's used about hundreds of MediaWiki and Wikipedia features. Wikipedia:Subpages is not a technical help page but an editing guideline in project space. It starts: Except in main namespace (article namespace), where the subpage feature has been disabled in the English Wikipedia, subpages are pages separated with a "/" (a slash) from their 'parent' page.
Click "subpage feature" to learn more about the feature. That's how we work. A page may have some info about something and link to a page with more info. Wikipedia:Subpages#Slashes in article titles also explains that articles can have slashes in the title. PrimeHunter (talk) 23:41, 27 February 2015 (UTC)

Infobox subheader shift?

In Jacques Brel, my eye gets the impression that the infobox header (the colored bar with text 'Jacques Brel') is asymmetrical: lefthand whitespace looks like 3px, righthand ws 2px. I'm using Firefox 35 (not 36 yet) now. Possibly related: #Tables_just_changed_.28using_monobook.29. Is it just my eye, or is this real? -DePiep (talk) 20:49, 27 February 2015 (UTC)

Not sure, was the dress white/gold for you today or black/blue ? —TheDJ (talkcontribs) 21:33, 27 February 2015 (UTC)

In Jacques Brel, my eye gets the impression that the infobox header (the colored bar with text 'Jacques Brel') is asymmetrical: lefthand whitespace looks like 3px, righthand ws 2px. I'm using Firefox 35 (not 36 yet) now. Possibly related: #Tables_just_changed_.28using_monobook.29. Is it just my eye, or is this real? -DePiep (talk) 22:13, 27 February 2015 (UTC)

I can't login to Wikimedia

I tried nominating a Wikimedia user page for deletion due to WP:G11, however, I'm failing to login because everytime I refresh it never logs me in, instead it shows me the Central login message. How can I fix this? --ToonLucas22 (talk) 22:02, 27 February 2015 (UTC)

The Wikimedia Foundation runs a lot of wikis and some of them don't allow account creation or login without permission. Please post a link to the page you want deleted and the page where you try to log in. PrimeHunter (talk) 23:14, 27 February 2015 (UTC)
This page I want deleted. --ToonLucas22 (talk) 23:19, 27 February 2015 (UTC)
That's... weird. Special:CentralAuth/ToonLucas22 looks ok. Have you tried going directly to meta to log in (m:Special:UserLogin)?
(I've marked that page for deletion myself, and created it blank here. I'm sure we'll be seeing lots, lots more block and deleted-userpage evasion of this sort in the future.) —Cryptic 23:37, 27 February 2015 (UTC)
You didn't post the requested link to the page where you try to log in. The wiki of the user page is called meta or Meta-Wiki and not Wikimedia so I wonder whether it's another wiki you try to log in at. Please post the url of the login page. PrimeHunter (talk) 23:51, 27 February 2015 (UTC)
I try to log in to m:Special:UserLogin. --ToonLucas22 (talk) 00:11, 28 February 2015 (UTC)
OK, that's meta where your account was created in December and should work. Does Help:Logging in help? Note that browsers can have site-dependent settings. Can you log in at commons: which is also on PrimeHunter (talk) 00:26, 28 February 2015 (UTC)
Nope, I can't log in there either. I refresh, still gives me Central Login message. --ToonLucas22 (talk) 00:36, 28 February 2015 (UTC)
Try others at Wikipedia:Wikimedia sister projects#Sister projects and see if it's limited to Try another browser if you can. Look for site-dependent cookie and security settings in your browser. Or just drop the whole thing if you only need to edit Wikipedia. PrimeHunter (talk) 02:43, 28 February 2015 (UTC)

Print/Export as pdf does not render tables

I've seen some chatter in the archives about the failure to render infoboxes, but it seems to me that the problem is much more widespread than that. I have looked around and every WP article with tables that I have checked have had the tables excluded in the .pdf print/export version. That is to say, after looking around, I have yet to find ANY tables that are rendered in the .pdf generated by print/export. Yes, there are many articles without tables, nevertheless, many articles include critical information in the articles and the lack of tabular information renders (pun intended) the .pdf nearly worthless. This is a widespread problem that IMHO should be prioritized relatively high. Examples are easy to find:

Go to your own favorite corner of WP and if you find tables, you will find this bug. YBG (talk) 05:08, 28 February 2015 (UTC)

Known issue. See T87499 which was merged into T73808. -- George Orwell III (talk) 06:05, 28 February 2015 (UTC)
Great! Much appreciated. YBG (talk) 06:16, 28 February 2015 (UTC)


Revisiting past proposal – Viewdelete userright


There is no consensus to implement this proposal at this time. HiDrNick! 21:08, 20 February 2015 (UTC)

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

I know that this idea has been around since the proverbial dawn of time, and a past discussion from 2008 flatly rejected this kind of userright. Almost seven years have passed, yet the reasons for opposing at the time are every bit as relevant today as they've ever been (with the caveat that RfA has become much harder to pass, a reality that I consider irrelevant to the merits of this proposal). Nevertheless, I figured it might be worth another shot – with some modifications.

Speaking as a non-admin, there have been a number of instances where I’ve wanted to review deleted material for research purposes. For instance, one time I was thinking of creating a replacement article for this one, based largely around its negative counterpart (but with stricter inclusion criteria). This has since been done, so the point is moot. At the time however, I faced a conundrum. In order for me to assess whether that was a good idea, I needed to know what the page looked like beforehand so as to develop a better understanding of why it was deleted. Having the ability to view these pages myself would have been far more convenient than asking an administrator for assistance. This is just speaking for myself; I’m sure there are many editors who would use that ability responsibly were it granted to them, but are not interested in full adminship or would not pass an RfA due to a lack of relevant experience. Another example would be Carrite. In 2013, he was nominated for adminship by Dennis Brown on a temporary basis so he could have the ability to review evidence in the Richard Arthur Norton ArbCom case without the tedium of having to consult administrators in order to do so.

The foundation has come out in opposition to any sort of initiative that aims to increase access to deleted (and therefore, sensitive) material. I'd imagine that their strong reservations still stand today, perhaps even more so than at the time. This brings me to my next point, and the major alteration to the 2008 proposal: what I’m proposing is not a tool that would be given out at an administrator’s discretion to any old editor asking for it via WP:PERM. Viewdelete would be granted following a community discussion similar to RfA, wherein the basic question being asked is: “do I trust this user with the ability to view deleted content?” Or, to put it in another light: “will granting this particular user viewdelete cause the WMF legal issues, put anyone’s information at risk, open the flood gates to obvious abuse on their part, or make a mess for administrators to clean up?” After a lengthy discussion (say, 4-7 days, depending on what is agreed upon by the community), either an administrator or a bureaucrat (whoever is tasked with the granting of this tool) will assess the consensus and come to a decision. The threshold for granting viewdelete would therefore be quite high.

Additionally, the restrictions placed on the application of viewdelete would be stringent. In particular, it must not be used for the following purposes:

  • Restoring content after it has been speedily deleted per CSD
  • Restoring content that was deleted based on community consensus at any XfD page
  • Revealing sensitive information for any reason whatsoever, whether publicly or privately

Ideally, administrators would have the authority to automatically revoke viewdelete in the event that it has been misused. I've still not worked out all the fine details of its implementation, which is something I figured could be handled by the community were this to go forward.

I feel that my proposal addresses most of the opposing points that were raised in the RfC from seven years back. Viewdelete would not be a userright that is given out to just anyone, but to people who are sufficiently tenured and thoroughly vetted by the community. The only question that remains for me is whether or not the WMF would be open to this particular suggestion; does this proposal address the question of legality to a sufficient extent for it to be implemented? If the community and the WMF are willing to consider this idea as it is phrased, then I propose we put it to a test run lasting around three months or so. Specifically, we would be looking to see whether or not the workload for the WMF and the oversight team is significantly increased. As this would not be given to just anyone who asks for it, but only to editors deemed trustworthy enough by broad consensus, I do not feel that the exposure of sensitive information would be an issue.

Thoughts? Kurtis (talk) 16:37, 4 January 2015 (UTC)

  • I'm in favor of it, obviously, but it's hard to see too much traction for creation of such a specialized user right. Carrite (talk) 00:53, 5 January 2015 (UTC)
  • Strong Oppose for the same reasons this usually gets opposed: would create legal issues with minimal-bordering-on-zero benefit to offset them. Think of it this way: Viewdelete is the most "dangerous" of the admin tools, at least in the legal sense, as revealing libelous or personal deleted info can't simply be reversed the way a bad protection or block can be. Therefore, the threshold for granting that right would be just as high as RFA itself. Anyone interested in it should just go through RFA. Andrew Lenahan - Starblind 01:33, 5 January 2015 (UTC)
(edit conflict × 2) Why should a perfectly capable and trustworthy individual be forced to undergo a full RfA and all the garbage associated with it to be able to see deleted pages? Say I don't want to be able to protect a page, I don't want to be hassled by other editors asking me to undertake admin tasks, or I don't care about the block status of other users. Why can this not be an option? Dustin (talk) 01:45, 5 January 2015 (UTC)
For the same reason you can't access a police station's evidence room without being a cop, or a bank vault without being a banker: you want keys to the kingdom, you get the scrutiny that comes with them. Hell, if anything passing an RFA is a pretty low bar for the all-you-can-eat buffet of libel, copyvio, and weird details of highschoolers' sex lives that comes with it. Really it would make more sense for Viewdelete to be available not to every admin but admins who have an understanding of libel and intellectual property laws in the US. Andrew Lenahan - Starblind 02:18, 5 January 2015 (UTC)
Admins are supposed to be janitors, not cops. they certainly don't undergo the rigorous (albeit occasionally flawed) training, supervision and vetting of the latter. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:03, 12 January 2015 (UTC)
It is the most "dangerous" of the admin toolbox, yes, but it is also the one least likely to be abused in the hands of a responsible editor. "I want the ability to view deleted pages and revisions" is not going to fly at an RfA – period. If you're not expressing any interest in dispute resolution, XfD, or really anywhere you'd expect to find an administrator, then the community would see no point in granting the bit. Being an administrator requires more than just being responsible; it requires discretion (as in, good judgment). The only real discretion I would expect from viewdelete is the good sense not to be going around and revealing sensitive information. Remember, I did say that the threshold would be very high. Kurtis (talk) 02:20, 5 January 2015 (UTC)
"it is also the one least likely to be abused in the hands of a responsible editor" Kind of by definition, in the hands of a responsible editor no tool is likely to be abused. But for a deceitful editor, I would say it's the most likely to be abused - because unless you actually undelete the page, it's not logged anywhere. So if someone was giving deleted information out off-wiki, it would be nearly impossible to trace. RFA looks at competency because that's really all we can measure. We generally just assume trustworthiness. Unless someone is actually caught lying or something, I don't know how we could have a community discussion purely about the trustworthiness of an editor that's not just a grudge-airing and is more reliable than a coin toss. Mr.Z-man 04:11, 5 January 2015 (UTC)
I can definitely understand your concern about the possibility of gaming the system, and about the difficulty of passing such a process. I'm not suggesting that viewdelete should be easy to obtain. Really, such a system would not be much easier to game than the one that exists now, assuming someone really wants to get access to that kind of information. I see people opposed at RfA for all kinds of reasons that have nothing to do with competence or trust: in this RfA, for example, an editor who is clearly trustworthy was denied access to the tools because he did not demonstrate sufficient experience in administrative areas to sway a large enough portion of the commentators into supporting him. If someone with a similar tenure to his were to apply for viewdelete, I'd imagine that they would pass. Kurtis (talk) 05:09, 5 January 2015 (UTC)
  • (edit conflict) My short answer would be: 'If you want to view deleted pages, then you must run for adminship.' I appreciate the time you have taken to post the above suggestion but I'm fairly sure that the Foundation would not allow it. Perhaps Philippe (WMF) could chime in here. Secondary issues are that creating yet another user right would create more bureaucracy - it would almost certainly need an RfA style application (with all its issues) for the right (so again, why not apply for adminship?). I'm not personally aware that the demand for such a right is sufficiently compelling, particularly as all proposals for unbundling admin tools are perennial failures.
Finally, I reject the notion that RfA has become much harder to pass:
The RfA system has increased its level of maturity since the watershed year of 2007 prior to which the tools were handed out following RfAs of very low !voter participation. We now have a very high turnout at each RfA and even the revered 100+ 'Support' RfA are now perectly commonplace. That said, the !voters at RfA are still very much a transient pool of users, so in reality the criteria are set anew for each RfA depending on who turns out to !vote. By 2014 RfA was also no longer quite the humiliating process it was when I started WP:RFA2011 and Mr Wales supported tha initiative with his famous "horrible and broken process" statement. --Kudpung กุดผึ้ง (talk) 01:42, 5 January 2015 (UTC)
The most important part of my proposal is where I outlined the hypothetical process as being community-driven. This is not like being granted rollback rights; it's much more akin to adminship. As I've said above, an administrator is not only someone who has proven themselves trustworthy enough to be granted access to a certain degree of sensitive information, they must also demonstrate an ability to make tough judgment calls and a willingness to partake in maintenance work or dispute resolution. No one is going to be granted adminship just because they would like access to deleted revisions, even if they were trustworthy enough to have such permissions, as that would be a virtual waste. Kurtis (talk) 02:20, 5 January 2015 (UTC)

I think this a bad idea. If a view-deleted editor later decides to become an admin, they basically would have to go thru a second RfA. If you want to unbundle admin tools, a better approach would be a user right to place limited blocks and semi-protects. Oiyarbepsy (talk) 04:51, 5 January 2015 (UTC)

I think the researcher permission only applies to seeing the revision history, as opposed to the content itself. The whole point of this proposal is so that ordinary editors don't have to go to an administrator to view deleted pages. If they are deemed trustworthy enough, they can do so themselves. Kurtis (talk) 15:46, 5 January 2015 (UTC)
Correct, it is much like a RevDelete where only the text is deleted. — xaosflux Talk 19:37, 5 January 2015 (UTC)
  • I agree with the sentiment of unbundling viewdelete from the mop and bucket for purposes of article creation. Wbm1058 already made the excellent point of using REFUND for that purpose. I oppose the nomination's idea of an RfA-like process because RfA is probably too stringent. I don't think the flag should be given out by any single admin, either. Whatever the process, I'd recommend the permission be temporary and responsive to a specific request. "In order to write an article on X I'd like to see the deleted versions of Y and Z.". If the flag automatically hits sundown we can limit contempt for the permission. My question would be, how often does anyone really need to see a deleted version? Chris Troutman (talk) 20:24, 5 January 2015 (UTC)
  • Strong oppose per my concerns voiced at the debate at Commons. This is a solution in need of a problem. --Tom (LT) (talk) 22:35, 5 January 2015 (UTC)
    There is or might be a real problem in need of a simple solution: Some days ago I stumbled over two files on commons arriving there as thumbnail of what still was or used to be a decent image here. I think that license reviewers (folks with this right, a bot if that's all what it takes to figure out that 100KB on commons cannot match a deleted 1MB here) should have the right to review what exactly happened here years ago. –Be..anyone (talk) 07:51, 6 January 2015 (UTC)
  • I've read all this and I simply do not believe there is a real problem that needs solving here. As creating this user right would be a long and contentious process it does not seem worth the effort. Beeblebrox (talk) 23:33, 6 January 2015 (UTC)
  • Oppose per all the usual reasons. Let's just keep it as a package deal. -- œ 02:58, 7 January 2015 (UTC)

From what I can see, most of those in opposition appear to be sysops. Not to say sysops' opinions don't hold equal weight, but I think it would be best to do more discussing before going into all of that !vote stuff. Dustin (talk) 03:04, 7 January 2015 (UTC)

  • Oppose, IIRC the WMF has explicitly said that users must go through RfA or an equivalent process to get this, so there's really no point in having it separate. ansh666 05:58, 7 January 2015 (UTC)
  • Oppose as a solution in search of a problem. Stifle (talk) 14:04, 7 January 2015 (UTC)
    • This isn't personally directed at you Stifle, but I'm really beginning to hate this sentiment. It's used to rebut just about any proposal, and it says very little. Proposers spend a long while typing detailed descriptions of why a change might be beneficial, only to be dismissed with such a flippant and nearly meaningless sentiment as "solution in search of a problem". In this particular case, the proposer even outlined a very specific situation in which this restriction was a problem for him. Stifle, please don't feel personally obligated to reply to this, as like I said, this isn't directed at you as much as a general comment on the proliferation of proposals getting shot down on these grounds which boil down to "the status quo is just fine, change is scary and unnecessary". Gigs (talk) 17:09, 7 January 2015 (UTC)
  • Oppose - First, there have been successful single bit need RfAs in the past, so the current RfA process can be used in that case. And since RfA-esque community support is needed for the viewdelete right anyways I don't see the benefit of breaking it out as compared to say something like template editor. I disagree that RfA's have gotten harder having !voted in them over the years except for the edit count inflation they seem less contenious these days although fewer in number. I can see myself possibly supporting other bits being split off ( and have done so in the past ); but—especially given the requirements from legal—not viewdelete. PaleAqua (talk) 17:30, 8 January 2015 (UTC)
    • "there have been successful single bit need RfAs in the past" - When was the last? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:06, 12 January 2015 (UTC)
      • Most recent such request that I recall was [Wikipedia:Requests for adminship/Trappist the monk]], but I didn't comment in all the RfAs this last year so might have missed another. PaleAqua (talk) 22:50, 12 January 2015 (UTC)
  • Oppose - the {{cent}} headline for this discussion asks whether we should "grant highly trusted users with the ability to view deleted content through a consensus-driven process". WP:RFA is the "consensus-driven process" by which the community "grant[s] highly trusted users" with this ability. The Wikimedia Foundation have also stated that there are legal issues with this kind of change. I'd certainly be happy to vote support in an RfA that sought to have time limited access to deleted revisions and pages if I trust the user in question: if someone were to propose allowing bureaucrats more latitude to, say, close an RfA as "promoted for a temporary period of X months" rather than either promoting or not promoting, then the RfA process could accommodate this kind of request. The only reason I can see to have a non-RfA process to grant this right is so that there is less participation and consideration given to a request for the unbundled right rather than the full administrative toolset. I'm not comfortable with this user right being granted with less participation than an average RfA gets. None of that changes the fact that RfA does suck in a lot of ways. The answer to that is to try and find ways to fix RfA rather than short circuit the valuable democratic oversight function that RfA provides. —Tom Morris (talk) 16:04, 11 January 2015 (UTC)
I was actually thinking that "viewdelete" requests could take place on the same page as RfAs and RfBs. I wasn't intending to suggest that this be a process where scrutiny could be evaded. Kurtis (talk) 16:51, 11 January 2015 (UTC)
  • Oppose in three points. First, I don't really see how it would be useful to create a bureaucracy to give out view-delete rights. Going based on my own experience, I can only think of one deleted article in the nine years I have participated on Wikipedia that I have ever wanted to view post-deletion. And that was only because the result of the discussion was merge and delete, but the merge was botched and a citation was lost. How many times can any editor really say they've needed to access content from a deleted article? Is it really that many times to justify having this ability enabled indefinitely? I don't believe it is.
Secondly, I believe WP:Requests for undeletion and CAT:RESTORE provide perfectly valid options regarding deleted content (CAT:RESTORE is a list of admins who are willing to provide deleted content). If an editor believes they are justified in viewing deleted content, then it shouldn't be too difficult to justify that at WP:UND. And to that point, as I've been thinking about this issue, one question comes to mind: does an editor need access to deleted content urgently? As the title of the essay WP:NORUSH goes, "There is no deadline."
Lastly, and above all else, there is a legal dimension to this proposal. If a representative of the Foundation can no longer say to a client's lawyer that sensitive deleted content is only viewable by "trusted administrators," then the project appears to be weaker. No matter how much trust we can invest in these certain editors who would be approved for the view-delete right, they are still not administrators. I believe it is in the best interest of the project that those people with view-delete be administrators. --hmich176 17:52, 11 January 2015 (UTC)
  • Oppose. I gave my main thoughts in my earlier comment. Now that voting has begun, I'll just reiterate that Adminship is about trust and competency. If you give a user only one of the tools and not all three, is it because you only have 33% trust and s/he is only a third as intelligent as a full admin? Anyone who wants one tool should be clever and industrious enough to convince the community that s/he would be competent with all three. --Kudpung กุดผึ้ง (talk) 20:07, 12 January 2015 (UTC)
    • If we refuse to give a user the tools, that says something about our trust. But if the user specifically asks for only one, that says something about the user. Maybe it says he doesn't expect a successful request. Maybe it says he doesn't want to be hassled by requests to block people. Maybe it even says that he doesn't want French spy agencies to arrest him and demand that he delete the article on Radio station military Pierre-sur-High again. The other editor's choice doesn't say anything about my trust in that editor. WhatamIdoing (talk) 22:35, 14 January 2015 (UTC)
  • I support the unbundling of the viewdelete and undelete user rights in the circumstances that I outline below and also the creation of some new user rights that I outline below.
    • I am under the impression that unbundling the viewdelete and undelete user rights would be acceptable if the rights were granted by a process that is practically identical to RfA (ie a community !vote, conducted over several days, with the opportunity to pose questions to the candidate etc). I think this would allow the same level of scrutiny that presently takes place at RfA.
    • We might also consider implementing multiple levels of deletion to avoid the problem that some deleted material is considered sensitive. What I propose to call "deletion level 1" would be for articles that are deleted for legal reasons or are otherwise considered to be sensitive (eg articles deleted as copyvios or for WP:BLP issues). What I propose to call "deletion level 2" would be for articles that are deleted for harmless reasons (such as possibly an article about a person who died in the year 1800, or a book published in that year, that was deleted solely on grounds of notability, which contained substantial content verifiable with reliable sources, and not sensitive in any way). It seems to me that the viewdelete and undelete for such a hypothetical "deletion level 2" could be handed out more freely, possibly at PERM or perhaps even given to all logged in users. This would be useful in that we frequently make very bad mistakes about notability (because GNG is so subjective and the SNG are incomplete in their coverage) and certain aspects of WP:NOT, such as failing to transwiki content to sister projects or deleting articles which ought instead to be rewritten or merged per WP:PRESERVE, and so forth. (And some of our exclusionary criteria are questionable, and consensus can change, and we might from time to time abolish particular exclusionary criteria, necessiting review of possibly large numbers of deletions done under them).
    • WP:REFUND is an extremely inefficient means of reviewing or restoring large amounts of deleted content, because it uses two people to do the work of one person and requires discussion between them that may be unnecessary. It is therefore not a viable alternative.
    • Since anyone can remove a PROD for any reason, and removed PRODs cannot be restored, it is not clear why only an admin can undelete an article deleted as an expired PROD. WP:REFUND appears to be an innefficient process for doing this. James500 (talk) 15:44, 14 January 2015 (UTC)
I indented your points to make it clear at first glance that it's one full statement instead of multiple unsigned comments. ansh666 21:45, 18 January 2015 (UTC)
  • Oppose - this is maybe a bit stale but I'm adding comments here anyway. I think that viewdelete is a right best left with admins. It's not terribly difficult to get an admin to help with access to or review of deleted content when the situation is appropriate, and whether or not such a request is appropriate is a decision best judged by admins, in my opinion as a non-admin. If a proposal to unbundle the deletion rights nonetheless requires candidates to be subjected to a process identical (or reasonably similar) to RfA, then it's not better than just making them run the RfA gauntlet. And I do think that such an unbundling should require such a process. Ivanvector (talk) 20:27, 23 January 2015 (UTC)
  • Comment correct me if I'm wrong, but don't we already have a consensus driven process aimed at highly trusted users that lets them review deleted material? I think its called "RFA" or some thing like that, and its purposes is exactly this. Why then do we need two versions of the same process? TomStar81 (Talk) 12:37, 29 January 2015 (UTC)
  • Comment. The 30-day period that would be typical for an RfC will run tomorrow, but this isn't an RfC. I'm just commenting to note that I've read the discussion and don't think it needs a formal closure, but I'm open to other suggestions. - Dank (push to talk) 11:41, 1 February 2015 (UTC)
  • Oppose Since most deletions aren't urgent, I see no need for this. If it were unbundling the blocking right, I'd be more likely to be in favor, since that can be urgent, but unless the deletion is a G10, it can wait.--Jasper Deng (talk) 04:33, 5 February 2015 (UTC)
  • Not a comment on the proposal, but I believe Kurtis meant to link to Wikipedia:Requests for adminship/Carrite rather than Wikipedia:Requests for adminship/Dennis Brown. ekips39 04:36, 5 February 2015 (UTC)
  • Oppose for all he usual reasons (I've gotten tired of listing them...). This is the umpteenth viewdelee proposal we've had lately - can we give these a rest for another year or so now? – Philosopher Let us reason together. 18:55, 6 February 2015 (UTC)
  • Oppose, mainly for the reason outlined by Starblind Cas Liber (talk · contribs) 03:57, 11 February 2015 (UTC)
  • Note - the similar (though not the same) user-right package Researcher already exists. - jc37 11:40, 16 February 2015 (UTC)

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

Proposed user right: Vandal fighter

There has frequently been discussion about making some of the administrator tools available to a lot more editors, and User:Jackmcbarn presented a great idea at Wikipedia:Village pump (idea lab)/Archive 15#New "vandal stopper" user group. The proposed vandal fighter user right would have the following rights:

  • Blocks:
    • Can block unconfirmed accounts for a maximum of 48 hours
    • Can soft-block IP addresses for a maximum of 48 hours
    • Can unblock users blocked by other vandal fighters
    • Can NOT unblock users blocked by administrators
  • Page protection:
    • Can semi-protect a page for a maximum of 48 hours
    • Can Pending Changes 1 protect a page for a maximum of 48 hours
    • Can unprotect pages that were protected by other vandal fighters
    • Can NOT unprotect pages that were protected by administrators
  • Notes:
    • All vandal fighters would also be granted Pending Change reviewer status
    • All vandal fighter actions will be viewable on one or more special pages
    • An administrator can turn a vandal-fighter action into an administrator action, which would prevent other vandal-fighters from removing it.
  • Requirements:
    • Vandal fighter rights would be granted by administrators after requests at Wikipedia:Requests for permissions
    • Rights would only be granted to user who meet the requirements of both roll back and pending changes reviewer
    • Vandal fighter rights must only be used for obvious spam and vandalism. Anything else will be considered abuse of the tool and the right will be revoked.

I look forward to your comments. Oiyarbepsy (talk) 23:57, 21 January 2015 (UTC) Pinging editors at previous discussion: @Biblioworm:@LT910001:@TheGeneralUser:@TenOfAllTrades:@Technical 13:@Cenarium:@Scalhotrod:Oiyarbepsy (talk) 23:57, 21 January 2015 (UTC)

The very early votes are indicating that this might pass, but people have several questions and objections. In light of that, I have a request for the voters: if it's still looking like this might pass after a week or two, then please check back at the end of this RfC in case the closers need help in determining consensus on the various suggestions and objections. - Dank (push to talk) 23:22, 22 January 2015 (UTC)
We're at the one-week point; I'll leave some notes in a few minutes at WT:Village_pump_(proposals)#Vandal fighter RfC. - Dank (push to talk) 22:57, 28 January 2015 (UTC)
  • To those who believe that anyone who may be trusted with this could go through an RFA, I would like you to know this is not the case. There are many RC patrollers that deal with clear-cut vandals who may not have as much content creation experience (achievements like GAs and DYKs) to be a full admin, due to the complex role that admins play (in settling disputes, closing AfDs, managing user rights, editing site-wide javascript, and blocking long-term abusers whose edits may not be easily categorized as vandalism). Many RC patrollers and members of the CVU would love to help with stopping vandalism by blocking obvious, uncontroversial vandals after giving them four warnings, but unfortunately, they can only continue to revert until an admin acts on the AIV report, which in some cases can take a long time.[1] Sometimes, the vandals are only blocked hours later, when they are no longer active.[2] By creating a new user right that provides these RC patrollers with the ability to block non-autoconfirmed users, but only in clear-cut and uncontroversial cases of vandalism, we can significantly curb vandalism and allow admins to devote their time on more disputed cases and other administrative areas, without leaving room for abuse as the right is removed immediately if it is used on anyone who is not an obvious vandal. Tony Tan98 · talk 01:25, 1 February 2015 (UTC)

Support (vandal fighter)

Support - Best idea I've seen in awhile. Give me the right and I'll contribute a lot more to fighting vandalism, taking some of the load off admins. If I abuse it, take it away. Unless admins spend more time granting and revoking the right than they currently spend responding to vandalism, which seems very unlikely, it's a clear net gain. I would ask for some kind of vandal fighter summary page covering the necessary tools and procedures, with links to more detailed information (unless something like that already exists). ―Mandruss  00:11, 22 January 2015 (UTC)

  1. Support. As long as the right can be easily removed by an admin, I see no reason why we shouldn't have this right. --Biblioworm 00:18, 22 January 2015 (UTC)
    Support - I agree. this one just might go somewhere. Mlpearc (open channel) 00:53, 22 January 2015 (UTC)
    The opposes have swayed me. Mlpearc (open channel) 04:21, 5 February 2015 (UTC)
  2. Not incredibly into vandalism patrolling but can definitely see where this right would be useful, so I support it. --ceradon (talkcontribs) 01:05, 22 January 2015 (UTC)
    Support, provided that the restrictions of the tool are limited to the original specifications in this proposal. If anything else gets added to the function of this user right after this comment, assume that I'm neutral. Steel1943 (talk) 01:20, 22 January 2015 (UTC)
    Moving to "oppose" after giving this some thought. Steel1943 (talk) 16:35, 24 January 2015 (UTC)
  3. Support This is a great opportunity to both empower the editors confronting vandalism while relieving the need to push more editors through RfA, where XfD and content creation become required. Chris Troutman (talk) 02:05, 22 January 2015 (UTC)
  4. Support I'd much rather see accounts be indeffable, as I mention in the discussion section below, but we can always do that later. Jackmcbarn (talk) 03:50, 22 January 2015 (UTC)
  5. Support, but with one reservation: I'm opposed to calling it vandal fighter as that would seem to promote a battlefield mentality. How about vandal control, vandal abatement, or even vandal extermination. The proposal is good one though, and would streamline the normal process of reporting to AIV or RPP and sometimes waiting hours for action to be taken.- MrX 04:05, 22 January 2015 (UTC)
    Well, fighting vandals (especially the sockfarm-creating ones who come back to harass you) does sometimes feel like a battle, but I see your point. --Biblioworm 04:43, 22 January 2015 (UTC)
    • Also support changing maximum 48 hour block to maximum indef block to address some of the objections from opposers.- MrX 01:00, 24 January 2015 (UTC)
  6. Support - I know that (assuming I had these rights) I could all but stop reporting IPs at WP:AIV, would usually have better and easier damage control over the user accounts I'd still report there. I'd also probably not have to post at WP:RFPP again. Freeing up those pages would probably help take care of the backlog at WP:SPI (now if only we had some similar demi-adminship to help with that), and resolve issues at WP:ANI quicker. I suspect this would also help with the admin shortage while reducing the risk of abusive admins, as would-be admins would have a vandal-control record to show that they can at least be trusted with that (something that honestly probably better demonstrates admin ability than article creation). Ian.thomson (talk) 04:16, 22 January 2015 (UTC)
  7. Support but with some notes. I trust that Jackmcbarn wouldn't propose this sort of thing if he hadn't already determined that it were technically feasible, so I am not concerned about that. What I am concerned about is the automatic granting of other user rights which we already have processes for. I would prefer that granting of those rights were prerequisites for this one, since they are all related and those are better established, rather than potentially granting those more mature rights through what could turn out to be a back door. But I'm not terribly concerned about it - these are fairly weak user rights. I think the benefits outweigh the risks; I'm in to try it. Ivanvector (talk) 04:32, 22 January 2015 (UTC)
  8. Support. I think having this right would be a great idea, as blocking vandals could be faster- there will be no need to wait for the administrator- the vandal fighter can block the vandal immediately, without a report to AIV. This is one of the best ideas I have seen. pcfan500talk|my contribs 10:51, 22 January 2015 (UTC)
  9. Support - if given out carefully and sensibly, and if it can be easily removed by a full admin or community consensus. Quite frankly, the number of times I've had to report an obvious vandal to AIV, only for the request to sit there for hours - with the vandal still working their way through many articles - due to the lack of any administrators being active at that point is quite depressing. Sometimes this can also come from a topic area being poorly covered by admins, and thus they lack the understanding of what might be a fairly obvious piece of vandalism to someone with some experience in that topic (I can think of some examples of this as well.) Lukeno94 (tell Luke off here) 21:00, 22 January 2015 (UTC)
  10. Conditional support As I've said in opposing other admin bit split outs, I could see supporting blocking and think this could be useful. I do have a few restorations. The first is the 48 hour limitation. I'm opposed to any such split out that would just make more work for the admins and agree with a bunch of the concerns on it that have already been. While technically I suppose that makes my !vote an oppose at this time, I see enough disagreement that I'm hopefully that it will change. I also worry about the name but not enough to oppose on that. At the risk of bikeshed'ing how about something like "Wikipedia Watch" or "Sentries"? I'd also like to see some pretty strong removal guidelines in the event of abuse or even careless misuse, for example once someone that has gotten this user right loses through abuse or marked carelessness the only way for them to get similar rights in the future would be a full RfA. Since the right should be somewhat easier to get it needs to be balanced by being easier to strongly revoke. PaleAqua (talk) 23:12, 22 January 2015 (UTC)
  11. Support – There is so much rubbish lying around, and so few administrative hands to deal with it. We need some housekeepers to keep an eye on things, so that simple messes can be mopped up. Save administrative time for severe and complex problems. Such a distribution of power will greatly improve the encylopaedia. A right that is easy to give and take away for this purpose is exactly what we need. If a housekeeper fails to carry out his or her duties appropriately, sack him or her on the spot. RGloucester 01:09, 23 January 2015 (UTC)
  12. Support. Great idea, if an admin is going to be able to remove it. APerson (talk!) 06:45, 23 January 2015 (UTC)
  13. Support Nothing is more infuriating than giving a vandal the standard four warnings then making a report to AIV which goes unread for hours, all the while the vandal continues to vandalize articles. I think that this user right would be very useful as a stop gate measure since it would give trusted non-admins the ability to prevent further vandalism by a user until an actual admin can step in. Spirit of Eagle (talk) 07:05, 23 January 2015 (UTC)
    Support in principle. Some of the issues brought up below (standards for giving out the right, possibility of indeffing unregistered users, whether 48 hours of PC is useful, etc) can be ironed out later. I dislike seeing good proposals opposed on technicalities that really aren't important to the broad idea, and I think that broadly speaking this is a good idea. Sam Walton (talk) 11:01, 23 January 2015 (UTC) Withdrawing my support, I've been swayed by the oppose voters, but not quite enough to oppose. Sam Walton (talk) 23:06, 27 January 2015 (UTC)
  14. Support a perfectly reasonable suggestion that will undoubtedly be torpedoed by this community's utter inability to ever agree on a major change. Mellowed Fillmore (talk) 17:33, 23 January 2015 (UTC)
  15. Conditional support - Initially I was going to oppose, but all of my concerns could be put to bed with a trial; so, I support a trial rollout of this user right. However, it needs a different name, 'vandal fighter' is too combative — to the point it is likely to exacerbate vandal behaviour. I suggest "Moderator", as the proposed abilities roughly reflect what a moderator does in other places on the Internet, or "Sentry", per PaleAqua. Bellerophon talk to me 20:19, 23 January 2015 (UTC)
  16. Support This could help reduce some backlogs. Though indefinite block may be better than a 48 hour limit. Graeme Bartlett (talk) 22:56, 23 January 2015 (UTC)
  17. Let's give it a test run and see how it goes. Kurtis (talk) 00:50, 24 January 2015 (UTC)
  18. Support Know what, lets try it out. At the very least it would maybe speed up actions at WP:AIV and some other areas. LorTalk 07:40, 24 January 2015 (UTC)
  19. Support With maybe a few more restrictions (voting?) to make sure that these rights don't go to unknowledged/abusive editors. Avono (talk) 14:58, 24 January 2015 (UTC)
  20. Support as a measure that would give broader access to useful tools to editors for whom some form of review exists to determine that it would be useful for them to have the tools. Per Kurtis, above, we can always test this out for a limited time, and then evaluate the results to see if it is worth keeping. Cheers! bd2412 T 21:43, 24 January 2015 (UTC)
  21. Support. This would be useful for experienced recent changes patrollers without much in the way of content creation. I would also like to see the limit on block lengths and protection lengths removed, and the requirements tightened up. Perhaps users who have X many successful requests to AIV and RFPP, and no unsuccessful requests in the last Y months. — Mr. Stradivarius ♪ talk ♪ 13:31, 25 January 2015 (UTC)
  22. Partial support. To me, the most important part of this proposal is "Can semi-protect a page for a maximum of 48 hours". We have a problem with the length of the process to combat libellous additions to WP:BLP pages. Giving vetted users the right to protect pages that are early in a BLP war would give the full administrators time to examine the problem and decide what to do. Serpyllum (talk)
  23. Support. Should, however, need more than simply rollback+reviewer, as those are given extremely liberally. --L235 (talk) Ping when replying 19:16, 25 January 2015 (UTC)
  24. Support. My knee-jerk reaction is to oppose this out of fears of hat chasing and misuse. But after some reflect I decided that I trust our users to do this right thing. I think that every new user should be given a chance but once they have demonstrated that they won't play well with others they should be blocked. The blocking and the page protecting with stop large attacks on articles that happen from time to time and free up the administrators to do better things. --Adam in MO Talk 04:13, 26 January 2015 (UTC)
  25. Strong support under some conditions. (editor) It would be obvious for an editor to support. Though, since there is a template for other editors to join the discussion, here am I. As an editor, I experience every-day vandalism. It's tiring having to refer to a board to have actions enforced, some of them take awhile meanwhile the vandalism continues. This way, as a Vandal Fighter, the process would be a lot easier and less painful to watch. It will save admins' time, though monitoring would take a great deal of time as well. I agree on the Vandal Fighter board. If extra actions are to be enforced, admins will be there. Though, the process to grant the user rights have to be a lot more than that. As a user mentioned below, it is considered as junior administrators. Granting these user rights, considering the impact it could have, it should be more thorough and strict. Thorough and strict as in go through the user's history. Review if their requests (RPP, AIV, 3RR/EW, etc.) were done properly with valid arguments of their report. If they are randomly making requests, then someone grants the user rights, hell will break lose. I don't suggest a rough process such as admins to grant the rights, just a more thorough examination. I, for one, would be the first to apply. I struggle a lot with vandalism in my watchlist from those whom choose to ignore warnings. I, myself, am well aware of adminship. As an adminstrator for two wikia websites, it would be great to have admin minions, if you will, to help out and run this Wikipedia in order. Not every admin is available to respond to requests, or sever backlog will take time to clean out. I do agree with a statement a user has made. The user rights will be revoked once the user is no longer available. Say, two weeks? Also, I would suggest the admin reviewer who granted the user rights to monitor the user for 48-72 hours (then once after some time) to make sure no non-sense is occuring. Some could go in a spring of protections and blocks. Callmemirela (talk) 05:29, 26 January 2015 (UTC)
  26. Strong support (and possible snow close? Come on!) This would really help out, when we vandlal fighter find a vandal and have to wait, some times, up to an hour for a block while the user keeps vandalizing and we have to keep reverting. (tJosve05a (c) 17:32, 26 January 2015 (UTC)
  27. Support We need this, many users can't stop vandals easily with their own rights and we need to be able to block, this would put the vandal count down by a lot. ~HackedBotato Chat with meContribs 18:59, 26 January 2015 (UTC)
  28. Support badly needed, since there are only ~575 active admins, and fewer still in the vandal business, with 1000s of vandals a day. KonveyorBelt
  29. Support - I would never subject myself to the RfA process even if asked, but this would give much needed tools to editors like me who already have rollbacker and pending reviewer. Perhaps one requirement could be having rollbacker without any complaints for at least a year or two. VMS Mosaic (talk) 09:23, 27 January 2015 (UTC)
  30. Support - This is very useful for trusted RC patrollers and allows them to respond to vandalism quickly, without giving too much power to non-admins. It is especially useful in cases like this, where a user vandalized egg 174 times for half an hour, even though an AIV report was quickly filed. Tony Tan98 · talk 05:23, 28 January 2015 (UTC)
  31. Support - Sounds great! George Edward CTalkContributions 20:30, 28 January 2015 (UTC)
  32. Support In practice, while it may be subject to changes, the general concept appears to be sound. Dustin (talk) 01:33, 29 January 2015 (UTC)
  33. Strong support with some suggestions. I think that this is an incredibly good idea. AIV is a very tedious and sometimes frustrating process when sysops do not respond quickly. I strongly agree with the portion of the proposal which says that only rollbackers and pending changes reviewers should be granted use of the tool. It should only be given to highly trusted users, almost reaching admin level of trust. In light of that, I have a few suggestions. Like many have mentioned, I don't think that "vandal fighter" is a good name. It seems too warlike and doesn't give an specific description of its purpose. Possibly a simpler name like "blocking rights" or something like that? Second, I think there should be a minimum number of edits and time since joining Wikipedia to even be considered for this right. If not a strict policy, perhaps a general guideline that admins would usually follow when granting this. Third and finally, I think that more than one admin should check the applicant's contribs and qualifications before granting the use of this tool. It is a very delicate tool and I think that a second sysop should check the first's assessment in allowing access to this. However, I would still support this right even if my suggestions aren't incorporated into the tool. I hope it passes! BenLinus1214talk 03:35, 29 January 2015 (UTC)
  34. Support per Chris troutman YatharthROCK (talk) 02:46, 31 January 2015 (UTC)
  35. Support Although it should be hard to acquire, possibly like a (very) mini RFA process? RetΔrtist (разговор) 01:07, 1 February 2015 (UTC)
  36. Support - seems like a great balance of user rights to me. It would outline good potential admins early on. I would find the (even limited) page protection rights to be extremely helpful sometimes. Whether I would be comfortable with blocking right off the bat is another thing, however, but I would still undertake it eventually. Considering that I have created 0 articles (and don't see myself bothering to attempt to go through that mess any time in the near future), I have a higher chance of walking outside and getting struck both by lighting and a meteor within two minutes than I do passing an RfA. Command and Conquer Expert! speak to me... 09:33, 3 February 2015 (UTC)
  37. Support As someone who does mostly maintenance tasks on Wikipedia, this would be a very useful tool for fighting vandalism. Just yesterday I was trying to stop 3 different IP addresses vandalising a page for over an hour while waiting for someone to respond to an AIV report. Since AIV has proved ineffective, we clearly need more people dealing with this. As Cncmaster points out, many of us vandalism fighters wouldn't pass an RfA as we don't do much content creation. I would however suggest a higher threshold for giving the rights, such as experience with AIV reports, demonstrating they know when a block is appropriate instead of just reverting and warning. Jamietw (talk) 06:47, 5 February 2015 (UTC)
    @Jamietw: - Yes. Myself, I have never observed a direct correlation between the amount of content creation one does and the competency one demonstrates as an administrator. If there is some magical point that I have been missing for four years, I would really like to know what it is. Command and Conquer Expert! speak to me... 04:52, 6 February 2015 (UTC)
  38. Support I support this so long as this proposal fails. In addition, the name "vandal fighter" sounds pretty cool; good name choice, proposer. Tharthandorf Aquanashi (talk) 12:03, 5 February 2015 (UTC)
  39. Support Where do I sign up? As a Special:PendingChanges list patroller for the last year or so, I've advocated for this almost from the start of that effort. There is no single perfect solution to dealing with vandals and the majority of the opposition to this proposals seems to be based on this idea being "imperfect". Please, lets start with SOMETHING! --Scalhotrod (Talk) ☮ღ☺ 16:40, 6 February 2015 (UTC)
  40. Support I support a very limited block power (short duration, IP only), subject to regular review by administrators, and easy removal of the userright by administrators. Ideally a parallel page to WP:AIV would be set up where vandal fighters would be required to submit a user report before implementing a vandal fighter block, making it easy for administrators to monitor/approve/extend/overturn the blocks as necessary. --Ahecht (TALK
    ) 17:19, 6 February 2015 (UTC)
  41. Partial support in order to separate and distribute powers. I prefer PaleAqua's name suggestion "Sentries" however. --Mr. Guye (talk) 01:34, 7 February 2015 (UTC)
  42. Support Definitely support this measure, would love to be able to block persistent vandals who are obvious, blatant and unwilling to stop after multiple warnings. I think this would definitely help address some of the admin backlog too, since users with this right would be able to quickly quell persistent problem users. Melody Concertotalk 00:39, 9 February 2015 (UTC)
  43. Support If you can qualify for this you should be able to pass RfA, on that I agree. However RfA has become somewhat ridiculous lately. Gigs (talk) 17:38, 12 February 2015 (UTC)
  44. Strong Support If you qualify this is definitely a great idea! Iv'e been helping out at AIV and this is really needed. TheMagikCow (talk) 18:10, 15 February 2015 (UTC)
  45. Support but I would agree with shorter periods than the mentioned 48 hours. 12 hours block or semi-protection will spoil the fun of most vandals already. They ones that need more can be dealt with by admins. The Banner talk 12:23, 17 February 2015 (UTC)
  46. Conditional support This is a really conditional support. This is establishing yet another level of hierarchy, below the admins. Till now, it's mostly based on page protect and approving permission requests, but now, it's even more complicated. As someone working with CSD, I feel that there should be a delete usergroup too. But there isn't, well, not on enwiki, atleast. I feel this unbundling is good but it could also be for the worse. I think the nays will have it. But, although the reasons are swaying, I see no harm. --QEDKTC 18:20, 19 February 2015 (UTC)

Oppose (vandal fighter)

  1. Oppose. I understand the motivation here, but I don't think this solves a necessary problem. Even assuming that we need more people capable of blocking obviously disrupting IPs and throwaway accounts (and I'd like some hard data regarding backlog rates at, say, RPP or AIV on that issue), the sort of accounts and IPs that this is intended to target frequently necessitate longer than 48 hour blocks, which means this doesn't actually save administrators an action except in fairly narrow cases. Also, the ability to apply even temporary semi-protection is fairly significant, since it restricts access from good-faith IP editors as well; the implications of this might best be reserved for those who have demonstrated more community trust than needed for the current "vandal fighting" tools like rollback. But, perhaps most importantly, I don't think this is likely to be technically feasible. My understanding of the mechanics of the project holds that in order to create a (semi-)protection level that this right can interact with, without granting the ability to interact with that protection level in general, would require creation of a new protection level (mini-semi-protection, or something). Likewise, something similar would be needed to create blocks that can be issued and undone by this user right without permitting interaction with "real" blocks (if that is even deemed possible to implement, as there are not, so far I am aware, "block levels"). A marginal net gain for substantial software development cost is not something to get hopes up about being implemented. Squeamish Ossifrage (talk) 02:28, 22 January 2015 (UTC)
    For what it's worth, Jack McBarn and others seem pretty sure that this is technically possible and feasible. Oiyarbepsy (talk) 03:20, 22 January 2015 (UTC)
    It saves editors having to chase around vandals while an AIV reports sits there at 4 a.m. EST when most of the North American admins are asleep. It might not save an admin action but it stops disruption quicker. --NeilN talk to me 03:35, 22 January 2015 (UTC)
  2. Oppose. At the time this was proposed at the idea lab, I noted several problems. As well, there was a discussion at Wikipedia talk:Blocking policy#Duration of blocks that is illuminating.
    • Having a group that can block only IPs and non-autoconfirmed accounts creates (or exaggerates) a power disparity in any conflict involving new (or unregistered) editors and more established accounts.
    • Most blocks of IPs and non-autoconfirmed accounts are for periods of time much longer than 48 hours (as are most semiprotections). This leaves a trail of incomplete tasks that regular admins may or may not eventually clean up.
    • Blocking vandalism-only accounts for just a little while doesn't actually work very well. A significant fraction of them come back (days or weeks later) to make more of a mess. Some of them will be autoconfirmed at that point. Virtually none return to make positive contributions (it's far easier, and more sensible, for them to create a new, clean account).
    • We actually don't do a good job of blocking vandalism-only accounts. Issuing short-duration blocks means that even the vandals that we catch once will still get one or more chances to do damage after their blocks expire.
      In other words, this toolset is likely to encourage newbie-biting while failing to effectively deal with vandals. (It just creates double the effort for each administrative action—once from the baby admin/"vandal fighter", and then again from the real admin who has to review the situation and issue a block/protection of adequate duration.) Also, what's with the "vandal fighter" name? It reminds me of the early WP:Counter-Vandalism Unit and its paramilitary ranks, badges, and officious obnoxiousness. We're not fighting a war, we're writing an encyclopedia. TenOfAllTrades(talk) 03:50, 22 January 2015 (UTC)
  3. Oppose - At least until the requirements for granting are tightened up substantially. I didn't even have to dig through the history - looking at AIV and RFPP right now, I see bad reports (no vandalism since final warning, not enough vandalism to justify protection) by users with rollback and reviewer rights. Like the AFD stats tool used on RFA, I'd like to see something similar for AIV/RFPP to make sure that the people requesting the right actually know when it should be used. Simply knowing what vandalism is (basically the requirement for rollback/reviewer) does not indicate sufficient understanding of the block/protection policies. Mr.Z-man 05:00, 22 January 2015 (UTC)
  4. Oppose I must admit this is better than a lot of unbundling proposals I've seen, but I have a few issues with it:
    • Granting the ability to block anyone, ever should be a community decision, not a single admin decision (ironic, an unbundling proposal that would actually give admins more power)
    • My standard objection to most unbundling proposals: The admin tools form a kit. Giving only some of them to some users will mean they can only deal some of the problem. Deletion, blocking, and protection are all tools used by admins specifically to combat vandalism. If you don't have any one of them you will inevitably have to go find an actual admin to finish the job. Why have two users doing something that one admin could easily do in a matter of just a minute or two?
    • Applying PC protection to an article for 48 hours or less seems silly. In my opinion and I believe in practice, PC is generally more for long-term problems, semi is for short-term ones.
    • Most actual vandals get indef blocked. Having them automatically unblocked after two days gives them an easy way back, and then a real admin will have to deal with that, so what's the point?
    • Rollback and even PC reviewer are low-level content tools. Judging whether a using them responsibly is only one of many prequisites for more powerful tools, and all these tools, even with these time limits, can easily be abused if granted to users who aren't really ready for them.
    • And finally, I don't see any concrete evidence that this is something we actually need. Beeblebrox (talk) 23:49, 22 January 2015 (UTC)
      • "Granting the ability to block anyone, ever should be a community decision" - What? Users get blocked constantly without any community input at all. Oiyarbepsy (talk) 05:05, 23 January 2015 (UTC)
      Yes they do. By people who were granted the right to block through a community based process. Beeblebrox (talk) 06:31, 23 January 2015 (UTC)
  5. Oppose WP:RFA is thataway. If you feel like the community can trust you to block people, then go and ask them to let you do so. --Jayron32 01:08, 23 January 2015 (UTC)
    What do you suppose are the chances of me getting full admin rights so that I might better help fight vandalism? Absolute zero. Something like this, far from a shoo-in but a lot better chance than that. How much do I want full admin responsibilities? Not in the slightest. ―Mandruss  02:13, 23 January 2015 (UTC)
    Mandruss: based on what I saw while reviewing your request for rollback rights today, you have a much higher chance of passing RfA than absolute zero. You may not want to be an administrator, but I don't see why an RfA would be that contentious in your case. —Tom Morris (talk) 04:32, 24 January 2015 (UTC)
    It would be contentious because I've created exactly zero articles (despite the fact that the required skill sets are very different). It should be contentious because I'm eminently unprepared for that job. But I'm more than capable of handling this new right, and there are a lot more like me around. Anyone who opposes because of the potential for damage by abusers of the right, who says that downside is likely be greater than the upside, is making a very negative statement about the Wikipedia community over all. I'm not prepared to make that statement. I know Jimbo wouldn't. Adequate vetting is the answer to any such objections, and it could include elements that have not been used before, such as interviews and references. In other words, the evaluation for this right could be, and should be, somewhere between rollback and RfA. ―Mandruss  17:38, 24 January 2015 (UTC)
    So you admit you are "eminently unprepared" for the right to block people, and for that reason you are arguing for the right to block people to be given to you because you ask for it. That makes total sense. --Jayron32 02:51, 28 January 2015 (UTC)
    Sorry I wasn't clear. I meant (and thought I said) that I am unprepared for adminship in its entirety. We're talking about a small subset of that for this role, and what I don't already know I could easily pick up in a few hours (this goes to the "summary page" that I suggested in my !vote). And I would have enough sense to tread lightly at first. ―Mandruss  03:23, 28 January 2015 (UTC)
    There is no userright MORE contentious than the right to block people; arguably it is that right alone which requires RFA; arguing to lessen the restrictions on that one right probably is the lest likely to pass (not that any of them would pass). Protection and deletion can be undone without the social harm caused to editors because of their misapplication. A bad block can ruin a good editor for life. So, if you're looking for a tool to be unbundled from the admin package, you've probably picked the absolute worst one to argue for. --Jayron32 03:25, 29 January 2015 (UTC)
    • It would be contentious because I've created exactly zero articles (despite the fact that the required skill sets are very different). is exactly why I haven't run as well. — {{U|Technical 13}} (etc) 18:39, 24 January 2015 (UTC)
    • I've written some articles (I have a GA and two upcoming DYKs), and I would like to do more work with content, if I can find other topics that have good coverage in other sources (which is becoming increasingly difficult). While the role of content workers/creators is indisputably very important, I still don't understand those who think it is necessary to become an admin. After all, if all the anti-vandals left, the content creators would be on their knees begging them to come back, as they wouldn't have time to create any content if they were forced to constantly protect their articles. --Biblioworm 18:50, 24 January 2015 (UTC)
    I suspect admins, over all, have a very cynical view of the community because they see the worst of us on a daily basis, like cops. Dear admins, your view of reality is skewed. ―Mandruss  21:37, 24 January 2015 (UTC)
  6. Oppose, blocking is too contentious. Guy (Help!) 01:47, 23 January 2015 (UTC)
    @JzG: @Jayron32: The right to block people in general is contentious, but the block right in this proposal is limited to clear-cut, indisputable cases of "obvious spam and vandalism" after sufficient warning is given. It cannot be a block on a suspected sock or on an editor with potential malice, but must be one a user that any impartial editor would agree is a vandal. The "vandal fighter" right would be immediately removed if it is ever used beyond that scope. Thus, the right being discussed here is not equivalent to or as contentious as the block right that admins have. (Pinging others who this reply is also intended for: @Hobit:@RightCowLeftCoast:@-revi:@WilyD:@Philg88:) Tony Tan98 · talk 01:49, 1 February 2015 (UTC)
    The software does not recognize who is being blocked; it only allows someone to block or not block. While we tell people they cannot use the power for X, Y, or Z, they still have the technical ability to do so, which is the problem here, and why one must go through RFA. The software does not recognize the difference between contentious and uncontentious blocks, and a badly placed block by someone with an axe to grind does FAR more damage to Wikipedia than does a vandal who waits 5 extra minutes for an admin to respond to an AIV report. --Jayron32 01:54, 1 February 2015 (UTC)
    It is true that the software does not recognize this, but users (admins & non-admins) do. The vandal fighter right could be immediately removed by any admin if there is any usage beyond blocking obvious vandals (which could be reported by anyone), leaving no room for the abuser to "explain" or "justify" their actions. (The user they blocked is either an indisputably obvious vandal or not.) Any vandal fighter may undo the blocking actions of another vandal fighter as well, to minimize potential harm. Plus, vandal fighters would only be able to block users that are not autoconfirmed. Tony Tan98 · talk 02:15, 1 February 2015 (UTC)
    You can't put the toothpaste back in the tube here. The badly-placed block has done its damage that no unblock can later undo. The social injury from blocking someone who didn't deserve it is far more damaging, and cannot be undone, regardless of how soon they are unblocked, and whether or not the blocker get's their rights revoked. That's why we require RFA: the community needs to trust the person who gets the right to block enough to not screw it up. Because bad blocks are bad forever. --Jayron32 03:29, 5 February 2015 (UTC)
  7. Weak Oppose, I agree with JzG. Weak only because I don't deal with vandalism on a regular basis and I'm unsure how badly it's needed. Hobit (talk) 03:49, 23 January 2015 (UTC)
  8. Weak Oppose, per reason given by Jayron. The power to block is a huge power, one that I am even concerned that some Admins have power to use. If some editor were to be given that power, they should have to go through a RfA like process, stronger than the request for permissions preocess. Therefore, unless such a vetting process is created, I cannot support this proposal at this time.--RightCowLeftCoast (talk) 06:40, 23 January 2015 (UTC)
  9. Oppose What's the differences with sysop? It is too powerful (especially blocking). — Revi 07:27, 23 January 2015 (UTC)
  10. Oppose: Largely as per Beeblebrox's arguments above, but the last paragraph of TenOfAllTrades's contribution expresses something important about the potential negative consequences. AllyD (talk) 07:39, 23 January 2015 (UTC)
  11. Oppose - anybody trusted with this would pass RFA, so this is just more of the "RFA is difficult, so let's have two!" silliness. And, of course, labelling someone a "fighter" is just an open invitation to ignoring WP:NOT#BATTLEGROUND. WilyD 10:01, 23 January 2015 (UTC)
    • Not strictly true, if they have little content creating experience but are an experienced anti-vandal patroller, they stand no chance of passing an RfA. Lukeno94 (tell Luke off here) 13:27, 23 January 2015 (UTC)
  12. Oppose gamification of blocking and risk of even more drama and contention among established users (who are left to argue over and vet these blocks and their use/abuse) is too high. Alanscottwalker (talk) 14:03, 24 January 2015 (UTC)
  13. Oppose - As per Beeblebrox and TenOfAllTrades. Since the vandal-fighting powers of vandal-fighters would be limited, actual vandals would find ways to game the system and get a second chance. Robert McClenon (talk) 01:58, 24 January 2015 (UTC)
  14. Oppose - as it stands now. Reiterating what's said previously, the requirements are very weak. Both the userrights rollbacker and reviewer are the easy come, easy go userrights. IMO, much stricter requirements are needed. Elockid (Talk) 02:11, 24 January 2015 (UTC)
  15. Oppose - ansolutely 100% per Beeblebrox who has once again beaten me to a discussion , saving me from having to do the typing. And thanks also for the analogy by TenOfAllTrades and reminding us how I finally cleaned up the camp-fire and badges brigade activities at the after-school activities hut. More to come in the 'Comments' section below. --Kudpung กุดผึ้ง (talk) 07:26, 24 January 2015 (UTC)
  16. Oppose - we rightfully require a good deal of community scrutiny before providing an editor the responsibility of using the blocking et. al. tools. Anyone who's earned the trust of the community to be blocking other editors needs to be given the trust to do so effectively; we're short admin-time enough without adding the burden of having to vet "mini-admin" actions. NE Ent 13:48, 24 January 2015 (UTC)
  17. Oppose' Ability to block and unblock is a crucial part of admin tools. If anyone meets the required criteria for vandal fighter, I presume he'd most likely pass an RfA as well. In simple words: there ain't any need to create further complexities. EthicallyYours! 14:41, 24 January 2015 (UTC)
  18. Oppose The ability to block can be very damaging and should require that the editor is scrutinised by the community before being given the right - i.e. by RFA or equivalent. As noted by others, being able to block ips/new users only will be divisive, and will potentilly drive off editors who could be redeemed or have been caught in the backlash of a bad block.Nigel Ish (talk) 14:50, 24 January 2015 (UTC)
  19. Oppose, after giving this more thought. I can see this discouraging non-autoconfirmed good faith editors or "vandals-that-eventually-become-constructive" editors if they get a block on their record during the time they are not autoconfirmed. That clean block log is like a perfect score on a report card, and ruining that report, no matter what the circumstance, is something that should only be trusted in the hands of an administrator. Steel1943 (talk) 16:38, 24 January 2015 (UTC)
    Since vandal-fighter blocks would have to be different on some level in the software (to allow other vandal-fighters to undo them, but not sysop blocks, if nothing else), it could be possible to purge such blocks from the log if an admin does not endorse them, either after some period of time or upon request after the user has mended their ways. If an admin does endorse them, they would become sysop blocks and would remain in the log. Vandal-fighters would not need the power to permanently ruin the clean record you mention. Pathore (talk) 02:32, 28 January 2015 (UTC)
  20. Oppose per Beeblebrox - Being blocked can ruin your chances of becoming admin so it should be done carefully, Personally I think it's best we stick to RFA as that way there wouldn't be any wars nor blocks. –Davey2010Talk 21:04, 24 January 2015 (UTC)
  21. Oppose - Completely wrong headed. Officially - for any of the good, sensible reasons set out elsewhere in this section. Leaky Caldron 21:11, 24 January 2015 (UTC)
  22. Oppose: The main tools available to nonadmins are tools that (when used correctly) have no potential to be contentious. PC reviewing and rollback are for more effective frontline stoppage of obvious vandalism, not discretionary action. Blocking and protecting, tools that have the most potential to be incendiary, should only be performed by those who the community has determined have the tact and cluefulness to be able to do so, not those determined by Joe Admin who happened to be clearing the RFPERM backlog that day. The short-term nature of the actions doesn't mitigate the discretionary nature of the tools. Deadbeef 07:17, 25 January 2015 (UTC)
  23. Weak Oppose - I support such a right on paper. I feel that it's a decent idea. But WP:PERENNIAL sums up what I think. The people qualified for such tools should might as well just go for full adminship. Narutolovehinata5 tccsdnew 09:41, 25 January 2015 (UTC)
  24. Oppose Our biggest issue is retaining new editors relaxing the requirements and increasing the number of people who can do this through the creation of yet another subset of editor rights is fraught with danger of increasing the biting of new editors so with out some documented imminent disaster to avert I dont see a need Gnangarra 11:54, 25 January 2015 (UTC)
  25. not a good use of our time per above --Guerillero | My Talk 22:34, 25 January 2015 (UTC)
  26. Oppose Per Guy. If we're unbundling some admin rights, blocking should be the last one to be considered, not the first. BMK (talk) 22:41, 25 January 2015 (UTC)
  27. Oppose blocking, but would support unbundling a limited form of semi-protection. That's a lot less confrontational than blocking, and can solve an issue while leaving blocking to an admin. Courcelles 23:49, 25 January 2015 (UTC)
  28. Oppose, though i fully understand the purpose and motivation and, indeed, was immediately attracted towards supporting the proposal. There are, however, too many reasons that this is not good for the community/encyclopaedia for it to actually become reality (in no particular order):
    • Blocking is something that should only be done by people vetted by the community (RfA);
    • The suggested criteria for obtaining the right are laughably low;
    • A new user-right like this increases the opportunities for hat collecting;
    • New accounts already get bitten (not always, but sometimes) by vandal-fighters, and we don't need to do anything which makes that more likely and more permanent;
    • I'm not sure that this solves a problem currently requiring a solution ~ we already do a good job of vandalism control;
    • RfA already exists for those users who wish to help out in ways they cannot currently. Cheers, LindsayHello 04:27, 26 January 2015 (UTC)
  29. Oppose Blocking is highly contentious and I don't feel it should be in the hands of users who were screened and approved by a single administrator. It should be as said above, a community decision. Those who routinely look at WP:AIV, will tell you that a great portion of block requests are not appropriate and often come from editors with thousands of edits. Blocking is not a place where these types of mistakes can occur at such a high degree. Mkdwtalk 00:21, 27 January 2015 (UTC)
  30. Oppose In theory it seems okay... but anyone who can block and protect pages can cause substantial damage, regardless of the said limitations. I wouldn't want to issue that right to anyone without community input. If anything it'd have to work like obtaining the abusefilter right, where the request must stand for a full week to allow for anyone to object before granting the right. Then consider all the drama that's going to come with this. You're going to have unconfirmed users running to admins complaining of some vandal fighters misconduct. Meanwhile newcomers might get confused who they're supposed to talk to about blocking and page protection, or confuse vandal fighters for admins altogether... then you'll see vandal fighters responding to reports at AIV and RFPP... just seems like the added bureaucracy is going to do more harm than good. Getting admin attention shouldn't be that hard, and if it is, let's focus on trying to fix that rather than adding a whole new layer of complexity to this user unfriendly environment we work in. If something is very urgent and you're unable to get on-wiki admin attention, consider hopping on #wikipedia-en-help connect, type !admin and hit enter. Finally, from a technical standpoint, you're going to need a whole new MediaWiki extension for vandal fighter to work. Good luck with that. — MusikAnimal talk 22:36, 27 January 2015 (UTC)
    And +1 to all of TenOfAllTrades's points... especially the argument about incomplete tasks and temporarily blocking vandalism-only accounts. You'll end up with another admin backlog of cleaning up what the vandal fighters weren't able to do. — MusikAnimal talk 22:40, 27 January 2015 (UTC)
  31. Oppose as written The proposed "vandal fighter" is effectively a "junior admin" and assignment of such a "training mop" should not be at the mere whim of any sysop. We have RfA and we should use it for any kind of user right that gives power over other editors. I could support some kind of "rapid-response anti-vandalism" role if an actual need were shown, but I think that assigning such a right should still go through RfA. Pathore (talk) 02:18, 28 January 2015 (UTC)
    No complaint here, provided article creation is not a criterion. Article creation is not where my strength lies, and I'd have a serious problem with anyone claiming I don't contribute enough to the encylopedia to be worthy of this role. Hell, my application for the right demonstrates my desire to contribute even more. As for looking at AIV and RFPP contributions, fine, if that will help this pass. And I'll set about hunting down problems to appropriately report, so as to build up my numbers quicker. ―Mandruss  02:27, 28 January 2015 (UTC)
    That would be more-or-less the idea for a "junior admin (anti-vandal)" role. The problem is that I'm uncertain of where exactly the lines should be drawn, or if creating articles really is an important criteria that I'm just not seeing right now. In any case, specialized junior admins would probably end up expected to branch out, with "junior admin" status becoming a stepping-stone to "admin". I'm not sure if there is any good way to avoid that, or if it even should be avoided. Pathore (talk) 02:42, 28 January 2015 (UTC)
    If I'd be required to state that I'm aiming for eventual adminship, count me out. On other hand, when I fail to apply for admin after years of competent service as JA, you could fire me from JA. Move up or move out. ―Mandruss  05:39, 28 January 2015 (UTC)
    I didn't propose that. I said that it might end up drifting in that direction, and that I'm unsure how to prevent such a drift. Pathore (talk) 06:17, 28 January 2015 (UTC)
  32. Nobody should have power to block without passing an RFA. Townlake (talk) 03:29, 28 January 2015 (UTC)
  33. Unbundling the tools may be a good idea; unbundling the block button is not. wctaiwan (talk) 06:38, 28 January 2015 (UTC)
  34. Oppose. Allowing the block right without sufficient scrutiny (i.e. an RfA) is a bad idea.  Philg88 talk 07:32, 28 January 2015 (UTC)
  35. Oppose, anybody who can do these things should be an admin. Becoming an admin should be easier, and unbundling more rights does not make it easier to obtain the full rights (it might make it harder, as it might introduce an extra step that will soon be seen as necessary). To make becoming an admin easier, just go to WP:RFA and vote "support" a couple of times whenever RFA is nonempty. —Kusma (t·c) 17:03, 29 January 2015 (UTC)
  36. Oppose While I would trust some non-admin users to have these abilities, I don't believe that the proposal addresses the problem that it would duplicate work by necessitating reviews of vandal fighter blocks, requiring admins to check if longer protection is needed, and so on. We need more admins, not baby-admins which real admins have to constantly look after. BethNaught (talk) 17:40, 29 January 2015 (UTC)
  37. Oppose I don't see what this would accomplish. It looks like the main difference between this proposal and full adminship is 1. page deletion and 2. longer blocks. If you're granting this for vandal fighting, it would make sense to add page deletion too to help with speedy deletion of obvious vandalism; leaving only longer blocks for admins. At that point, adminship would become nothing more than a status symbol, which it shouldn't be at all. If you want those rights, what's wrong with RFA?~ ONUnicorn(Talk|Contribs)problem solving 21:26, 29 January 2015 (UTC)
  38. Oppose - There really isn't (or shouldn't be) a drastic dropoff in the level of competency required of someone with any sort of access to the block button, no matter if you're trusted to block new users for two days or old users forever. Anybody who could be trusted with this new right would stand a respectable chance of successfully running for regular adminship. I'm slightly less opposed to the protection side of this proposal, but I wouldn't consider that part of it workable either. --Bongwarrior (talk) 05:19, 30 January 2015 (UTC)
  39. Oppose if you want to block people, go to RFA and get the community's support. Tavix |  Talk  04:21, 31 January 2015 (UTC)
  40. Oppose, per Beeblebrox. Ironholds (talk) 04:50, 1 February 2015 (UTC)
  41. Oppose. The ability to block anyone for any amount of time (with "any" in the existential rather than universal sense) is too much without having gone through RFA. The mistreatment of anons and new users is what drives many potential editors away. -- King of ♠ 05:18, 1 February 2015 (UTC)
  42. Oppose - Great idea with a few tweaks, but it appears we can't tweak it. Therefore we should kill this ASAP so we can move on to the next try. (What is the minimum rest period between tries?) ―Mandruss  03:50, 5 February 2015 (UTC)
  43. Oppose - After further thought and some of the above comments, if you can be trusted with this flag you should be able to pass a RfA. Mlpearc (open channel) 04:28, 5 February 2015 (UTC)
  44. Weak Oppose. It's an excellent idea, and I'd very much like to see this pass, however instead of Vandal fighter rights would be granted by administrators after requests at Wikipedia:Requests for permissions and something less serious than RFA, but I do think there should instead be some sort of community discussion, per user, in a dedicated discussion subpage, instead of decided by another single individual for promotion. — Cirt (talk) 20:01, 5 February 2015 (UTC)
  45. Oppose - Yes, me, a vandal fighter, opposing this very idea. This simply is an example of Wikipedia:Perennial_proposals#Hierarchical_structures, and it doesn't exactly resolve all issues with anti-vandalism. For instance, as mentioned many times, even the most experienced of non-admins make bad WP:AIV reports. Giving such editors the power to block editors would result in a lot of unfair blocks over editing disputes (which AIV is not for yet people still go there to complain. I've seen it myself.). Secondly, if a vandal fighter blocked a vandalism-only account for 48 hours, they would need to go back and file a second report to ask an admin with full powers to extend the block to indefinite, as this is the general practice for vandalism-only accounts -- an indefinite block. This would be a lot more tedious and increase the workload of editors and administrators as they now have to hunt down vandal fighter blocks and extend them appropriately. It would be better to just report at AIV and monitor the user until an admin can drop the hammer and end the whole argument completely. Thirdly, if there is a page under attack, my advice is to get Huggle 2, which automatically updates, so just point it at the page that's under attack and revert malicious edits instantly until an administrator sees your RFPP request (which you should have filed, like any good editor should, ahem). Alternatively, if you are patrolling recent changes and you see an administrator editing (but not monitoring RFPP or AIV so they don't see your request) you can poke them on their talk page. I did that once during a spambot-attack on a page, which was dragging on a bit too long (but thanks to Huggle 2 it was very manageable). Poking an active administrator did the trick fairly well, and was faster than RFPP. It might not be the most practical idea, but it works to an extent. And fourthly, if you can be trusted to block an editor, protect a page, delete a page, and set pending changes protection, consider running for RFA. One of these days. --I am k6ka Talk to me! See what I have done 14:05, 6 February 2015 (UTC)
  46. Oppose Fundamentally because I believe anyone who I would trust to receive this ability I would also trust to be an admin. Alos the specific objections by TenOfAllTrades and Beeblebrox are persuasive. Davewild (talk) 17:09, 6 February 2015 (UTC)
  47. Oppose tl;dr, another level of bureaucracy, this wiki needs more workers, not more coppers...--Stemoc 01:42, 7 February 2015 (UTC)
  48. Oppose Partly because there is the problem of what IS vandalism? I'm more of a janitor than a cop, but I see quite a lot of "that's not vandalism, that's content dispute" at AIV. Content dispute can also become vandalism, but not always. Partly because I disagree strongly with the right to block for any length of time (meaning 'whatever length of time' is decided) being given out by any single admin. Per K6ka above, if you can be trusted with those rights, you can be trusted with a mop - and I don't think that a whole stack of articles created is a necessity for that. Working with the existing content of articles is just as good to my mind. That's somewhat irrelevant here, anyway. Otherwise, per Beeblebrox et al. Peridon (talk) 19:54, 7 February 2015 (UTC)
  49. Strong Oppose We actually don't need such user right as we have ClueBot NG, Huggle, STiki, and other tools that can fight vandalism. Users could manually revert vandalism by simply clicking Edit on an article or you could just use Twinkle to revert vandalism and unambiguous promotion or advertising.
    Admins could block users indef for vandalism or promotion as well. Also, what if you want to participate in AFD's or make constructive edits as I did on Crips? That would be abusing the vandal fighter right and bureaucrats could revoke it, so why revoke a simple right just for making constructive edits if they flag it as abusing it? That would be downright obnoxious, wouldn't it?Snowager (talk) 03:06, 9 February 2015 (UTC)
    I think you're misunderstanding the proposal a little. It doesn't mean that people with the right would be prohibited from doing anything but anti-vandal work, just they could only use blocking and protection for that. They wouldn't be allowed to block users for things like edit warring. Mr.Z-man 15:20, 9 February 2015 (UTC)
  50. Oppose The ends do not justify the means. It would only be helpful for a handful of cases, and has potential to be abused in content disputes. Acebulf (talk) 18:49, 14 February 2015 (UTC)
  51. Oppose Nominate for adminship anyone who signs up for this right. We need more of those and the level of trust would be virtually the same. --RacerX11 Talk to meStalk me 18:29, 15 February 2015 (UTC)
  52. Oppose It makes no sense to issue only a short temp block to a blatant vandalism-only account, especially in cases where the account name is clearly abusive. Furthermore, access to the blocking tool is a contentious matter, and inappropriate blocks clearly have the potential to cause emotional damage to good faith contributors. Therefore, the decision to hand out the blocking tool to a particular user is one that must be made by the entire community. --SoCalSuperEagle (talk) 19:26, 15 February 2015 (UTC)
  53. Strong oppose - anything with "vandal or "fighter" in the name. (see: WP:BATTLEGROUND). And 48 hours is way too long. For this, maybe 12 hours at most, and really leaning towards 1 hour at most. As for unbundling, while I agree that those who moderate discussions and the like may have a different toolset than those who may choose to "police" the wiki. (see WP:MOD.) I think that if you're going to have the ability to block someone, you should have all the tools available to make informed decisions. And I will oppose giving the ability to unconditionally block to anyone who cannot also view deleted for that same reason. This is why I proposed the split of the toolpackage in the other direction. - jc37 12:09, 16 February 2015 (UTC)
  54. Strongest oppose: The ability to block or protect should only be given to highly trusted users. If a editor is trusted enough to be granted vandal fighter rights, then that editor should be trusted enough to become an admin. Erroneous blocks or blocks intended to give the blocking editor an advantage (say, in an edit war) can lead to a would-be precious editor leaving the project. Erroneous protections prevent IP editors and unconfirmed editors from legitimately making edits for little reason. Also, this adds complication to the user access level structure. If this user (privilege) is implemented, it should have stricter requirements (my suggestions are below):
    1. 1 year on Wikipedia.
    2. 2,500 mainspace edits.
    3. No recent cases of biting, incivility, or personal attacking.
    4. But overall, no. Esquivalience t 02:46, 18 February 2015 (UTC)
  55. Oppose Unpacking the admin tools is a WP:PEREN that the community repeatedly opposes. What we need is more candidates for admin, not admin-lite. Anyone with some experience who wants to run for admin, drop me a line and I'll try to help you through the process. But not this way. --Dweller (talk) 10:58, 19 February 2015 (UTC)
  56. God forbid no! Just another attempt by people who haven't a hope in hell of passing RFA to get some special tools and status to lord it over lesser users. Wikipedia should not be a MMPORG and any attempts to make that worse should be burned with fire.... Spartaz Humbug! 14:38, 19 February 2015 (UTC)
  57. Oppose, users wishing to obtain these rights should go through the regular RFA process. Nakon 21:03, 19 February 2015 (UTC)
  1. Oppose, I must admit, I laugh a bit... I've been fighting Vandalism and Spam on more than 500 Wikis globally as Global sysops, out of thousand and thousand of reverts and hundreds of deletion afaik I only block 2-8 users. Seems useless when you can report them to Stewards (global case) or local admin(local case), and English Wikipedia admin are always here to help (we have too many Admin IMO), just report them to Administrator and it will be solved accordingly. PS : If this proposal uses User:Esquivalience Idea of criteria, I might think about supporting this.--AldNonUcallin?☎ 05:09, 22 February 2015 (UTC)

Discussion (vandal fighter)

@Oiyarbepsy: In my original idea, vandal stoppers could indefinitely block users who are registered but not autoconfirmed, so that admins wouldn't have to reblock all vandalism-only accounts. Was this change on your part intentional? Jackmcbarn (talk) 00:51, 22 January 2015 (UTC)
@Jackmcbarn:It was not. I misunderstood. I'll can revise if you like, but I like the 48 hour idea better. That way, admins are only necessary for those who come back after their 48, which I suspect is a small minority. Oiyarbepsy (talk) 00:58, 22 January 2015 (UTC)
@Oiyarbepsy: I would like that to be revised. While it's true that admins would only be necessary for those that returned with the limit, they wouldn't be necessary at all without the limit. Jackmcbarn (talk) 01:01, 22 January 2015 (UTC)
If this passes, and after being in place for a month or two, we can change it. Best to start out kind of conservative. Oiyarbepsy (talk) 03:19, 22 January 2015 (UTC)
@Oiyarbepsy: I note that a lot of oppose reasons mention that vandalism-only accounts would get unblocked after 48 hours, which would be bad. Would you consider changing it now to alleviate some of them? Jackmcbarn (talk) 01:24, 23 January 2015 (UTC)
@Jackmcbarn:I'm gonna be honest, I don't think changing that would alleviate anything. The opposers who mentioned that had it as one small item in a laundry list, and I frankly think that change would change anyone's mind. Also, I'm not entirely comfortable to let non-admins block users essentially forever, and it's certainly better for vandals to come back with their original account rather than sock puppets. Finally, enough votes have been made that changing it now would generate a lot of confusion of what exactly people are supporting or opposing. Oiyarbepsy (talk) 05:08, 23 January 2015 (UTC)
  • (edit conflict) Comment/question: Could someone explain to me how this proposal's function would be technically possible? I mean, from what I understand, there is a drop-down menu that administrators can use to select how long an editor is blocked for, and as far as I know about this, that cannot be adjusted for a special new user right. (However, I bet improbably wrong, and there's probably some way to edit a page in the "MediaWiki" namespace to allow only certain timeframes to this user right.) So ... can this be done? Steel1943 (talk) 01:03, 22 January 2015 (UTC)
    @Steel1943: This will require software changes to implement, which I plan to start work on once this proposal is closed (assuming it passes). Jackmcbarn (talk) 01:05, 22 January 2015 (UTC)
  • @Jackmcbarn: That's what I suspected. It's possible. I was, more or less, wondering since if the only option to make the software allow non-admins the option to block other users would give the non-admin access to the "indefinite block" option, then this would seem more like a tool-unbundling request (and I think that enough of the admin toolset is unbundled already.) Steel1943 (talk) 01:12, 22 January 2015 (UTC)
  • Jackmcbarn, please add me as a gerrit reviewer and CC me on the Phab ticket when you're working on this. Thanks. — {{U|Technical 13}} (etc) 01:25, 22 January 2015 (UTC)

Just to be clear, I don't interpret this as meaning the right-holder would be expected to spend most of their time fighting vandalism. I would simply use it to save myself and admins some time, while cutting off the offender sooner, when I run across a vandal while in the usual course of editing business. If that's not the intention, I would still support but wouldn't apply for the right. ―Mandruss  01:34, 22 January 2015 (UTC)

That's the intention. Jackmcbarn (talk) 01:39, 22 January 2015 (UTC)

Given that the bars for rollback and PC reviewer aren't that high, I'd like to consider more stringent qualifications, like a demonstrated track record at AIV & RFPP to the granting admin's satisfaction. It would require a little bit more due diligence but given the level of access I think that's OK. I also think the name is a little too bombastic; my first thought was "patroller" but that's already used elsewhere. Regards, Orange Suede Sofa (talk) 01:58, 22 January 2015 (UTC)

That would probably count me out. I've hit AIV once (appropriately) and RFPP once (appropriately). Not much of a track record. But I would still be a very good vandal fighter and I certainly know the difference between a clear vandal and a disruptive editor. ―Mandruss  02:08, 22 January 2015 (UTC)

Right now there are two AIV boards - one for humans and one for bots. Can a third be added that would contain entries that would automatically be added when a vandal stopper blocks someone? Admins could review this board and lengthen blocks if necessary or remove these rights if an incorrect block was made. --NeilN talk to me 03:41, 22 January 2015 (UTC)

There will be something like that. Jackmcbarn (talk) 03:44, 22 January 2015 (UTC)

Why not give them full blocking ability, only to be used on vandal accounts. Just like roll back can onlt be used in certain situations. Any abuse or use out of scope can be dealt with by removal of the right. It would be much easier to implement and understand. Sincerely, Taketa (talk) 03:55, 22 January 2015 (UTC)

FWIW, I intend to be one of the closers. Similar discussions happen roughly once a year, and I can't detect a pattern; every discussion has had different voters and closers. The most common question for closers is whether we're going to settle it by vote-count or by weight of the arguments ... I can't speak for anyone else, but the best I can tell, most closers approach it the same way. We don't want to take away people's right to speak up and be counted, so if there are a bunch of votes in either direction, that side is going to get the nod ... unless there's a credible argument that people are voting multiple times or being canvassed, but so far, that's never been even a factor. If it's not clear from the numbers which way to go, then we look hard at the arguments ... not with the intention of nullifying votes, but with the intention of listening to what the voters are really asking for. We can't assume that any "no" vote to a new user-right implies that voter wants to see Wikipedia go over a cliff, nor can we assume that a "yes" vote means the voter wants the new user-right to stay in play even if it's not working out. Here's some free advice to both sides: make your case. Present some data. Present some good arguments. Some Wikipedians are kind of dug-in on these issues, but many aren't, and most will listen to you if you listen to them and make your case. One last thing: please check back at the 30-day point or whenever the RfC has run ... if it's not clear which way the RfC is going to go, it would really help if we (the closers) could ask the voters to clarify what you meant or what kind of compromise you'd be willing to settle for. - Dank (push to talk) 04:39, 22 January 2015 (UTC)

Suggest that we have clear rules for removing this access such as with other advanced permissions, including for inactivity or for any actions that lead to a block. — xaosflux Talk 04:30, 22 January 2015 (UTC)

Strongly agree here. We should remove for inactivity for the same reason as for admins with the option of giving it back when they return. I think most under-a-cloud type removals ( wheel warring, abuse, careless use that causes too much work, etc. ) should remove the ability to get this right back except for getting the equivalent powers by passing an RfA and becoming an admin. PaleAqua (talk) 01:59, 23 January 2015 (UTC)

Without commenting on the substance of this package, can we please lose FIGHTER from the name. Fighting terminology is not very helpful or welcoming. Patrollers, Blockers, Fixers, Minions, .. open to any other suggestions.. but nothing aggressive please. -- zzuuzz (talk) 12:33, 22 January 2015 (UTC)

Antivandal ―Mandruss  12:42, 22 January 2015 (UTC)
That's what I was thinking. It sounds more professional than most of the other ones. --Biblioworm 13:09, 22 January 2015 (UTC)
How about sergeant-at-arms? Personally I don't like the word "vandal" in the name any more than I like the word "fighter" - it just sounds deliberately confrontational. Ivanvector (talk) 16:55, 22 January 2015 (UTC)
Another closer note: even if the vote is 100 to 5 to to approve "vandal fighters", that doesn't mean it's not possible to call them anything else ... it's reasonably clear that people are supporting the creation of a role, and not necessarily every detail of the proposal. That's another reason it would be helpful for people to stick around at the end of the RfC, to work these things out, if needed. - Dank (push to talk) 20:44, 22 January 2015 (UTC)

I have no opinion about the current specific proposal as advanced for the purpose stated, but just want to comment that this is just the most recent attempt to create a user group holding a subset of the rights currently held by administrators. The proposal has, in the past, most frequently been advanced a form of trial period or apprenticeship as one of the various methods advanced to fix or replace the RFA process. Something like it was also advanced as a means of controlling incivility at disputatious article talk pages. The community has, up until now, never supported these ideas. While I express no opinion about the current proposal for its stated purposes, I support it as a form of creating "junior administrators" for the purpose of working around the current RFA system. Because my support is not for the stated purpose of this proposal, however, I do not feel that it should be considered in evaluating consensus on this proposal unless the "junior administrator" purpose is substantially advanced as a reason for this user right change in addition to its current stated purpose. Regards, TransporterMan (TALK) 15:27, 22 January 2015 (UTC)

In the user-rights RfCs, closers have been asked to comb through all the comments to see if there are people who actually supported or opposed but didn't record a vote in the proper section. I'd appreciate it if you could talk a little more about what you'd like to see happen with this proposal; I can't quite tell if you're supporting, even though you say "support". - Dank (push to talk) 16:07, 22 January 2015 (UTC)
  • "Anti-vandal patroller" could be a decent alternative if people have issues with the name (zzuuzz alluded to it in their comment above). I don't think there are many sensible names for this type of userright that don't include "vandal" somewhere; as cool as sergeant-at-arms may sound, or something like Keeper of the Peace, they aren't the most self-explanatory things (although that being said, nor is autoconfirmed!) Lukeno94 (tell Luke off here) 21:06, 22 January 2015 (UTC)
  • I have to agree on the name. While it is an accurate description of what the package would be for, it seems overly confrontational. Beeblebrox (talk) 00:47, 23 January 2015 (UTC)
  • I like the idea of referring to the proposed user right as a "Housekeeper" right. That's exactly what they'll do. They'll keep the house, and clean-up simple messes on a day-to-day basis. RGloucester 01:06, 23 January 2015 (UTC)
  • Something vague like sentry could work. But as has been mentioned, the choice of name is really a separate issue and shouldn't bear on one's !vote, and it could easily be a separate discussion. As we all know, getting hung up on details is what kills far too many proposals. For purposes of this discussion we could say rightX or something and get on to more important questions. Any takers? ―Mandruss  01:14, 23 January 2015 (UTC)
Changing the proposal to a "right X" for the time being seems appropriate, allowing it to be resolved later. I really am fond of the cleaning analogy. It is meaningful without being antagonistic. RGloucester 01:16, 23 January 2015 (UTC)
I didn't mean to have implied that I would not support based on the name. I support the proposal, full stop. You can change the name to "bloodthirsty vandal-murdering gravyweasel" and I'll still support it on principle. (but please don't) Ivanvector (talk) 20:10, 23 January 2015 (UTC)
  • Question Would the user have to have rollbacker and pc reviewer already, or simply meet those requirements? KonveyorBelt 01:27, 23 January 2015 (UTC)
Since no one is rushing to answer this, I'll offer my take. It says, Rights would only be granted to user who meet the requirements of both roll back and pending changes reviewer. I'm taking that literally. If rollbacker and pc reviewer were prerequisite rights, I assume they would have said that instead. The writer seems articulate enough. FWIW,―Mandruss  08:02, 23 January 2015 (UTC)
  • Questions. This would obviously need software changes, so do any developers here know how likely it would be to get the resources to do it, and would such software development require the WMF's approval? Squinge (talk) 09:14, 23 January 2015 (UTC)
    • User:Jackmcbarn has already offered to do it. I think we can implement new user rights named rblock and rprotect (as in "restricted" block and protect) that allow users with this right to block and protect only within a specific timeframe defined in a wg variable. Zhaofeng Li [talk... contribs...] 09:21, 23 January 2015 (UTC)
      • OK, thanks! Squinge (talk) 09:54, 23 January 2015 (UTC)

Comment – I hate to say it, but it isn't fair that the majority of you are sysops who may look at it differently because you had to go through RfA. This isn't really fair. You all act in good faith, but it really is bad to see the lack of user distribution between admin and non-admin users on the oppose vs support. Some of you bring up legitimate concerns, yes, but some of you don't. Dustin (talk) 03:50, 23 January 2015 (UTC)

How is it not fair for us to oppose something? You can say some of us are wrong, or don't make good points but that doesn't make it "unfair".
I would suggest that you consider the fact that admins who got their tools post-2007 managed to make it through a very difficult process that, despite it's flaws, is designed to weed out those who do not have suitable levels of policy knowledge or the wrong attitude to be going around blocking other users. And even then, we still sometimes fail and the wrong person gets the tools. To shortcut that process so severely so that all anyone has to do is find one sympathetic/gullible admin and -bam- they have half the tools themselves and can cause all kinds of trouble with them is frankly a frightening prospect.
Vandal fighting is important and I think most admins really appreciate the work that is done by non-admin users in detecting and reporting vandals, but without a real test of their judgement and ability to keep their cool, such as RFA, we should not be granting powerful tools like blocking and page protection, which prevent users from editing. We get enough complaints about these things when they are done by qualified admins. Letting anyone with a few good AIV reports just start hammering away would be a serious mistake, and would not ease the workload of current admins. In fact it might make it significantly worse with unblock and unprotection requests getting jammed due to a few trigger happy pseudo admins. Beeblebrox (talk) 06:47, 23 January 2015 (UTC)
can cause all kinds of trouble with them - Yes - for all of about an hour, until their right is revoked. Either permanently, or for a very long time. Sorry, but I'm calling hyperbole and alarmism. I can easily produce five or six experienced, respected editors to attest to my integrity and ability to keep my cool. Just say the word. This process should be about fairly and objectively weighing potential benefits against potential costs, not zeroing in on potential costs and blowing them way out of proportion. ―Mandruss  07:34, 23 January 2015 (UTC)
Blatant abuse isn't really the main problem (IMO). The biggest problem I can foresee with the proposal as-is is misuse due to inexperience/overzealousness. I'm sure any admin who regularly handles AIV or RFPP can attest to the number of non-actionable reports. At AIV: the worst case is users making low-quality, but good faith edits reported as a vandal. At RFPP it's usually just people requesting semi-protection on a page that's only been vandalized twice in the last month, or only vandalized by 1 user. Improper blocks can easily drive away potential new contributors and overuse of semiprotection goes against one of our core principles - that anyone can edit. I think there's a lot of value to the current system in which most vandalism blocks and page protections are independently reviewed before they're done. Reverting a couple extra vandalism edits because a report sat on AIV for an hour is easy. Convincing a good-faith user to give WP another chance after he's mistakenly blocked as a vandal isn't. Mr.Z-man 14:15, 23 January 2015 (UTC)
But anyone can post at AIV or RFPP. Do you even have to be registered? Obviously the admin is going to spend 15 minutes or so looking the candidate over before granting the right, checking out their history, maybe even engaging them in a brief interview or asking for references. I can't imagine enough bad ones getting through that to offset the benefit of the good ones. If they did, we simply raise the bar a little. No reason to oppose here. Nothing like this will be perfect out of the gate. ―Mandruss  15:07, 23 January 2015 (UTC)
As I said in my comment further up in this section, without even having to look through the history, I found rejected reports at both pages by (different) users who had both rollback and reviewer. You're assuming that admins will do a thorough job, but that's not what the current proposal says they have to do. It says it will be given to people who meet the requirements for rollback and reviewer, which have fairly low standards. Mr.Z-man 15:39, 23 January 2015 (UTC)
Fair enough. @Oiyarbepsy: Any problem with adding something about vetting? ―Mandruss  15:45, 23 January 2015 (UTC)
I wrote some fairly detailed suggested text for the above (see page history if curious), then decided it would start us down a path of neverending quibbling over details. Could we simply say something like, Reviewing administrator will vet the applicant and may reject, details to be established separately? ―Mandruss  17:07, 23 January 2015 (UTC)
On the other hand, it was running into semi-protection that finally convinced me to make an account. Pathore (talk) 05:50, 25 January 2015 (UTC)
  • I realize it is kind of late for this, but considering the requirements to be added to this group seems to be the biggest stumbling block, I would support removing the criteria all together and see if there is consensus to create such a group with details about acquiring the right to be determined upon completion of this RfC as successful in determining that such a group that can do these things is needed first. — {{U|Technical 13}} (etc) 02:18, 24 January 2015 (UTC)
Seems this could also work well with obvious UPOL violations. Mlpearc (open channel) 05:22, 24 January 2015 (UTC)
  • Comment (I've placed my oppose vote in the voting section above). Some of the supporters make some good arguments but the two main objections I have are 1)The hat collecting, and 2) the fact that rather than reduce admin workload, it will increase it. Any admin who has worked the WP:PERM pages, expecially Beeblebrox and I who have held the fort there for years, will be aware of the extent of hat collecting, and grabbing these rights as trophies, and like many admins in fact, once they've got thier bit they tinker with it for a while then leave their new toy aside. If such a right gets created and if it's up to admins to accord it at PERM, there will literally be a stampede for it. If such a right must be subjected to an RfA style debate, then the cadidates should be sufficiently competent to stand a good chance for the mop. Such a right would simply keep the admins on their toes checking on its use, much in the same way that I patrol the patrolers at NPP who ironically for such an important task, need no qualifications whatsover - and it shows. I don't go to AIV much but when I do I linger there to clear up the backlog and I'm frankly staggered by the number of totally incompetent listings - are those from the 'vandal fighters' the supporters want turned into mini admins? --Kudpung กุดผึ้ง (talk) 08:33, 24 January 2015 (UTC)
  • Comment. Many in the oppose section complain that this would increase admin workload. (There seems to be blue highlights scattered everywhere in that section; it could just be coincidence, but it might be something else. [Just kidding; we need some humor around here.]) If that is really the case, why is it that the introduction of the template editor right didn't have the same effect? TE and the proposed antivandal right are similar; both unbundle very potent admin tools. For example, a template editor could ruin the appearance of many pages with a single edit, but when that does happen, an admin can simply remove the right immediately. Not to mention that TE has a strict granting standard. So, TE pretty much disproves the argument that people will "stampede" for the right, create a monumental amount of admin work, and create chaos. --Biblioworm 17:19, 24 January 2015 (UTC)
    • The differences between this and template editor, to me at least, are:
      1. TE requires a demonstration of competence through experience with template editing and work on sandbox versions of protected templates. The proposal here requires only that they meet the requirements for rollback and reviewer, which are often given to people with only a few hundred edits and a couple months of editing experience. That these are insufficient requirements should be plainly obvious. Looking at the last few days of rejected requests for SP/PC in Wikipedia:Requests for page protection/Rolling archive, 13 out of 23 requestors had rollback and/or reviewer.
      2. We don't encourage template editors to make bold, unilateral edits to protected templates. The only edits we tell people to make without discussion are fixes to broken markup and edits that don't actually affect the output. So in practice, most edits to protected templates are still discussed in advance. That's kind of the opposite of the intention here, which is to bypass the pre-action independent review at AIV and RFPP.
      3. No one is going to give up on Wikipedia because they saw a broken template in an article, they might if they're mistakenly blocked as a vandal.
    • Mr.Z-man 20:07, 24 January 2015 (UTC)
      • Why, then, don't we get rid of the rollback right and restrict CSD/PROD/AfD tagging to users who have gone through an approval process? If you're new, having your good-faith edit reverted and your article put up for deletion can be very hurtful, but we have generally low standards for rollback and none at all for NPP. If we tried to institute more strict requirements for any of the things I just mentioned, it would be swiftly rejected by the community. The point here is that there are many things that a regular user can do that can drive away new editors. --Biblioworm 20:35, 24 January 2015 (UTC)
        • Yes, there obviously are things that anyone can do to drive away new users, but that doesn't mean we should ignore that as a concern and give them more ways to do it. You don't need special rights to out someone, should we give everyone checkuser too? If you assume every vandal gets 4 warnings before they're blocked, there are 5 times as many vandalism edits to revert than there are vandals to block (probably more when you consider that many stop before they're blocked and many get more than 4 warnings), so we need a lot more people with the ability to revert than we need with the ability to block. And of the 3 main admin tools, page protection is the least used – RFPP usually gets less than 50 requests in a day. Editing protected templates isn't done very frequently, but TE still solved an actual problem in that the vast majority of admins don't actually have the technical knowledge to review edit requests to templates and modules. Don't get me wrong, I'm not fundamentally opposed to unbundling these tools, but absent a demonstrated problem to solve or a proposed process that won't result in users with 1 month of editing experience being granted the ability to block users, there's no way I can support this. "Backlogs" aren't really a serious problem because backlogs are relative. CAT:CSD is considered backlogged when it has more than 50 requests, WP:AIV is considered backlogged when it has more than 5. Mr.Z-man 21:20, 24 January 2015 (UTC)

@Mr.Z-man: The proposal here requires only that they meet the requirements for rollback and reviewer It doesn't seem particularly fair to keep making that argument when I have proposed a solution to it (see "vetting", above) and the proposal is still pending a response. I'll ping Oiyarbepsy again. ―Mandruss  22:13, 24 January 2015 (UTC)

MandrussI read it again, and I don't understand what your proposed solution even is, aside from the word vetting. Vetting by who and when and what exactly is being vetted? Oiyarbepsy (talk) 02:59, 25 January 2015 (UTC)
@Oiyarbepsy: Sorry if I wasn't clear. Several opposers have cited as one reason the fact that the bar is no higher than that for rollback and reviewer. That seemed like a reasonable concern to me, and I proposed that the reviewing admin perform vetting of the applicant, to a greater extent than they do for rollback and reviewer. I initially proposed some specifics, here, and then decided that specifics would only bog down this discussion and a consensus on them could be reached later. So I proposed a more general statement to be added to this RfC, which is above. If you think something more specific is needed, that's fine, but I feel that some response to the concern is needed. ―Mandruss  03:13, 25 January 2015 (UTC) Note that I have now added something about specifics below, per Mr.Z-man's suggestion.―Mandruss  08:01, 25 January 2015 (UTC)
How is it "unfair"? Lots of people have suggested tweaks to the proposal - letting blocks be indef, changing the name, doing a trial period - but until they're incorporated into this proposal or a new one, I can't just pretend that the issue has been solved when the proposal hasn't incorporated the solution. I even tried to clarify my comment by saying "the proposal here" to specify that it only applies to this proposal. But I would disagree with having a proposal with no specifics. How would that even work? Say we agree to create the new group, but can never come to a consensus on standards - then what? Would people who are opposed to the group in general be forbidden from participating in the discussion for standards? Mr.Z-man 04:48, 25 January 2015 (UTC)
Points taken. Ok then, I think the main specific points should be:
  • Interview - The admin could discern a lot about the applicant's suitability for the right by asking them some questions. Some of this goes on at Requests for permissions, but it's ad hoc and not a formal part of the process. It could be done on the applicant's user talk page.
  • References - Require at least three references. This could be done in either of two ways. The applicant could provide at least three usernames, and the admin could contact each reference on their talk page. Or, the applicant could ask each reference to post a statement with the request for permission. The main thing here is that the admin should weigh not only what the references say, but also who they are. An applicant who provides three quality references from experienced and respected users should stand a far higher chance of passing vetting than one who provides six references from yearlings, some of whom have some behavior issues of their own.
  • History - The admin who reviewed me for rollback apparently took a fairly thorough look at my history, judging by some of the things he noticed. I don't know how common that is for rollback, but it should be done for every request for rightX (my code word for the right proposed in this RfC). A block within the previous year could be an automatic disqualification. There are tons of ways this could be tuned and refined.
It's inconceivable to me that enough bad apples could get through this to make this right a net negative. If a person is going to use the right to make trouble, that should show up in the history review alone, never mind the interview and references. I hope this helps. ―Mandruss  06:20, 25 January 2015 (UTC)
Enough bad apples used to get through RfA in pre-2007 times, Mandruss, and some still do in spite of our screwing the bar as high as we dare. --Kudpung กุดผึ้ง (talk) 11:26, 25 January 2015 (UTC)
Unless it's done "live" via IRC or Skype, an interview is useless. It's basically an open-book test. People can take hours looking up the "right answer" to questions. All that does is filter out the people who are so clueless they don't even know where to look up the answers. References aren't really any better. No one ever writes a bad reference for someone. At worst they might refuse, but no one will see the refusals, just the positive references from the people who agreed to do it. Looking at history is really the only practical way and is basically what I suggested in my oppose comment. RFA uses an "AFD stats" tool to determine how many AFD !votes a candidate has made and what % were actually in line with the outcome of the debate. If the latter number is too low, it suggests their interpretation of WP:N and WP:NOT aren't in line with what the community expects. If we decided to implement this proposal, I'd like to see similar tools for AIV and RFPP - how many reports have they made and what % are acted upon. If we wanted to get really quantitative, we could establish minimum numbers for both, combined with "general experience" criteria like for Template Editor (1 year+1000 edits, no recent blocks). Looking at a random sample of their rollbacks and PC reviews would also be useful. Leaving too much up to individual discretion is a recipe for inconsistency and standards creep (either getting stricter or more relaxed). Mr.Z-man 16:22, 25 January 2015 (UTC)
  • Comment: Comparing Template Editor with Rollback & Reviewer makes a very poor analogy. TE is not a 'power right' - it does not give an editor power over another editor, it just confirms a level of technical competency like getting a driver's licence or a PPL. Rights that give power over users' edits and/or behaviour are magnets to the hat collectors, brownie point seekers, and the power hungry for whom the Wikipedia backroom is just another MMORPG. At the fear of repeating myself, those of us (sorry only admins) who have worked the WP:PERM pages are only too aware of all this.
CSD/PROD/AfD tagging most certainly should be restricted to users who have gone through an approval process, and the fact that NPP doesn't need a right is evidenced by the poor understanding of deletion, the biting of newbs, and the picking of low hanging fruit at the New Page Feed leaving us with a 31,000 backlog. Ironically, WP:AFC - a far less important process - has a bar of 500e/90d that has proven time and time again to be far too low although I proposed it myself in GF knowing that the community would reject a higher one.
To those who are evoking Wikipedia:TINC, all I can say is that such groups exist only among non-admins, namely either those who are sysop wannabes, or those who are so resentful that they will never be given the mop, do all they can to disrupt our processes and bring the very encyclopedia they 'so love' to contribute to into disrepute both on-Wiki and in other places. We certainly don't want to create easier-to-obtain minor rights that will give them a tool to vent their spleen. --Kudpung กุดผึ้ง (talk) 03:46, 25 January 2015 (UTC)
I'll say two things again, in the diminishing hope that someone is actually considering what is being said here. How much spleen can be vented before the right gets revoked? And why are you looking only at the downside? ―Mandruss  04:01, 25 January 2015 (UTC)
I looked at the 'upsides', Mandruss, and if I thought the idea were a net positive I would be up there in the 'support' section. I'm not. But I haven't suggested that this proposal was made in bad faith, nor criticised anyone's rights to express themselves. --Kudpung กุดผึ้ง (talk) 11:34, 25 January 2015 (UTC)
Ok. Well I've contributed about all I can to this, if I've contributed anything, so I'll just lurk from here on out. May the best side win. ―Mandruss  11:56, 25 January 2015 (UTC)
Although I certainly respect your opinions, Kudpung, we will obviously disagree on some points. First of all, it's really difficult to overlook the pessimistic tone of your comments concerning non-admins and "newbs". They always seem to assume that the newbies are clueless, cause trouble, and need to be restricted and monitored, while non-admins are portrayed as power-hungry hat collectors who are dedicated to making war and troubling the noble admins. (I'm certainly not suggesting that admins are not noble, but I think people know what I'm trying to say.) Also, the reference to TINC was intended to be a joke, and I clearly marked it as such. (Aside from dragging me to ANI and passing some sanction which says, "Biblioworm is hereby forbidden to use humor and must forever be a serious stone-face", I suppose that people will have to learn how to live with my general light-heated attitude. ;)) In any case, I generally like to think that I'm a fairly well-respected editor who isn't on anyone's "dislike" list, so I'm not going to blow it by getting into some argument over something so minor in the larger scheme of things. --Biblioworm 05:42, 25 January 2015 (UTC)
Of course my comments sound pessimistic, Biblioworm. After six years of campaigning to improve NPP, improve RfA, improve the image of adminship, and four years of seeing life from the perspective of a busy admin, it's clear that I have accumulated a different outlook from that of the non admins. Rather than 'pessimistic' however, I would have preferred my line of thinking to be labeled as 'pragmatic'. --Kudpung กุดผึ้ง (talk) 11:13, 25 January 2015 (UTC)
  • I've been thinking a bit about this proposal a put together my thoughts on an alternate version in my sandbox that attempts to at least address some of the opposes and concerns raised. ( FWIW I have zero interest in getting this right myself, similar to how I offered input for the proposal for TE but did not seek/want that right. ) Thoughts? PaleAqua (talk) 08:03, 25 January 2015 (UTC)
    Updated the above link to a version with tweaks made by @Technical 13:. PaleAqua (talk) 23:21, 25 January 2015 (UTC)

Comment: Hello, just thought I should let you guys know that since October 2012, the blocking feature is part of the rollback "package" of user rights at the Portuguese Wikipedia, where I'm also a regular editor. It allows non-admins to block anonymous or non-confirmed accounts for up to 24 hours following cases of "light or destructive vandalism" - equivalent to the examples listed at Wikipedia:Blocking policy#Disruption. Of course I realize that this proposal is aiming much higher, and that both versions of Wikipedia behave quite differently, but because apparently this feature has not caused any significant problem over there, it might be a hint that the proposed changes would work around here. Don't take my comment as a support, though. Victão Lopes Fala! 05:32, 29 January 2015 (UTC)

  • Is this another solution looking for a problem? Stifle (talk) 10:39, 4 February 2015 (UTC)

Comment: I think that the proposed requirements for being considered for the user right should be more strict than just needing to "meet the requirements of both roll back and pending changes reviewer". I'll state the obvious: I see this proposed user right (as most probably do) as one that should be granted to highly trusted editors who have a very established editing and vandal fighting history. Having both the 'rollback' and the 'pending changes reviewer' user rights should be required before your account is even given a second look by a granting admin. Users who apply should have a long and established record demonstrating their proper use of the 'rollback' and the 'pending changes reviewer' user rights; simply being eligible to be granted those rights is not enough. The user should also have a long and established history of warning users, reporting proper cases to WP:AIV, requesting page protection, and maintaining civility towards others. The account should also have a clean block log. ~Oshwah~ (talk) (contribs) 02:43, 7 February 2015 (UTC)

I'm with you up until the last requirement. A block at any time in the past should not be a permanent scarlet letter that stays with you for life. I think better wording would be "The user should also have a long and established history (since their last block, if applicable) of warning users, reporting proper cases to WP:AIV, requesting page protection, and maintaining civility towards others." If someone made a mistake, especially as a new user, that shouldn't be held against them if they've been a positive contributor since then. --Ahecht (TALK
) 03:08, 7 February 2015 (UTC)
I agree. What I should have said was: "The account's most recent block (if any) should be longer than one year ago, and it should be clear that the user has positively learned from their block(s) (through their contributions)". I redacted the statement; it's worded too explicitly. ~Oshwah~ (talk) (contribs) 03:55, 7 February 2015 (UTC)
You guys do realize you've now gotten to tthe point where the requirements are nearly the same as those expected at RFA, don't you? This is why this proposal is failing to gain consensus in the first place, I thought that was obvious a week ago... Beeblebrox (talk) 19:19, 8 February 2015 (UTC)

Section break 1 - Discussion (vandal fighter)

Since blocking seems to be the most contentious thing here, what are oppose voter's thoughts on making a userright which can only protect pages per the above conditions? Sam Walton (talk) 18:31, 26 January 2015 (UTC)

I think with blocking, it's workable with some changes to the criteria for granting. With only protection, I would oppose it regardless. There is very little need for protection compared to blocking. WP:RFPP only sees (on average) around 2 requests per hour and a significant fraction of those are declined. And with only the one ability, I'd worry about people misusing protection in situations where blocking would be better. Mr.Z-man 22:48, 26 January 2015 (UTC)
  • @Samwalton9: Get rid of the blocking bit of this request, and my "oppose" would become a "support". Steel1943 (talk) 23:27, 26 January 2015 (UTC)
  • I would recommend a three month trial period for it to be determined if it's privileges will be used positively and in compliance with policy or not.--Nadirali نادرالی (talk) 22:01, 26 January 2015 (UTC)
  • I wold also still oppose it if it was just protection. The admin tools are a package. You aren't going to be effective at doing anti-vandal admin work unless you have the whole thing. Let's take attack pages as an example. When an admin sees one they have options. they can delete it, protect it from being recreated, and block the user who created it. They can do any combination of those things as appropriate. This userright would only allow protection, so they could do... what... to stop the vandal? Go find an admin looks like about it. I would also be concerned that protection would be overused since the option to block wouldn't be there. Protection is not actually something we want to do if we can help it, but if it's the only tool you have it's the only one you'll use. Beeblebrox (talk) 22:58, 26 January 2015 (UTC)
  • I would switch to oppose if it was just protection. What about this userright would empower a user to stop vandals if all they can do is chase a vandal around and lock down pages they hit? That's no better than chasing them around with the revert button. Ivanvector (talk) 23:43, 26 January 2015 (UTC)
  • I would likely switch to oppose as well. I see the risk of misuse for protection to actually be higher than blocking. PaleAqua (talk) 23:50, 26 January 2015 (UTC)
  • Again, like AIV, RFPP is a place I rarely go to but when I do I linger to clear out what is there. And like AIV, I'm dismayed at the number of frivolous requests. No, and as per Beeblebrox, if pp were the only tool available to counter-vandalism agents it would almost certainly be over used. --Kudpung กุดผึ้ง (talk) 15:45, 27 January 2015 (UTC)
  • WP:AIV clearly demonstrates that a substantial portion of experienced editors request blocks that are unwarranted. It's a clear track record this system would not work and be overused and improperly implemented. I would like to add that I am not against the theoretical application of this feature (if used properly). I simply don't see any indication it would work as theorized as directly indicated in how editors, experienced and inexperienced, already misuse the request for block noticeboards. Mkdwtalk 19:53, 27 January 2015 (UTC)

What displeases you users from this idea? The lack of examination/consideration (Rfa)? If so, how about we propose a mini Rfa for this user right? Callmemirela (talk)

Callmemirela If you were to read the entire topic I think you would find that that aspect has been covered in depth and you will find your answer there. --Kudpung กุดผึ้ง (talk) 02:07, 14 February 2015 (UTC)

Bots (vandal fighter)

Another interesting component that hasn't been touched on in this discussion here that just occurred to me, what about bot accounts. Certainly no-one can deny that one of our best anti-vandal contributors is Cluebot, so I'm wondering if such a new user-right is created, should there be bots that are allowed to have it and make use of it which would certainly be beneficial to the encyclopedia by stopping potential vandals quickly and allowing admins to check through the list at their leisure to confirm or increase the problematic ones. Just food for thought, and I think it is worth discussing. — {{U|Technical 13}} (etc) 16:30, 24 January 2015 (UTC)

  • I'm not at all comfortable with allowing bots to decide when to block users or protect pages, so I would oppose this idea. Beeblebrox (talk) 16:33, 24 January 2015 (UTC)
    • I'm expecting there are many who feel the same, which is why I felt it needed to be discussed. If the OP decided to not remove the above requirements (as I suggested would be a good idea) for another RfC to iron that out exactly, then those above requirements would allow for bots if there was no subsection discussion on the matter. I could try to make a case for allowing bots to do this, but will hold off at this time. — {{U|Technical 13}} (etc) 16:56, 24 January 2015 (UTC)

Bots? Are you crazy? Did I actually need to specify that bots can't block, since it seems really obvious that they shouldn't. Has block-bot ever been approved? I seriously doubt it. Oiyarbepsy (talk) 03:02, 25 January 2015 (UTC)

Yes, we have bot-blocking, but under very strict guidelines (c.f. User:ProcseeBot) - there would need to be a strong community consensus established to allow anything like that, the operator would need to qualify for the permissions first, then the community would need to decide it is a task that should be done, finally WP:BAG would need to review the operations -- a steep hill to climb. — xaosflux Talk 03:09, 25 January 2015 (UTC)
And ProcseeBot blocks based on purely technical reasons. Vandal and spam blocks require human judgement. Oiyarbepsy (talk) 03:15, 25 January 2015 (UTC)
There was AntiAbuseBot (talk · contribs). Elockid (Talk) 03:19, 25 January 2015 (UTC)
Looks like that's been off for about four years. If it was actually possible to make a bot so good at assessing vandalism that it could block users, ClueBot would already be doing it. Blocking users based on article editing requires human judgement. Period. Beeblebrox (talk) 23:03, 26 January 2015 (UTC)

Why this is needed

  • I would just like to note that this tends to happen a lot. A prolific vandal targets a page, and then non-admins are forced to play the revert game as they wait for a ban or page protection to occur. I think that the tool set would be useful in situations like this. Spirit of Eagle (talk) 06:16, 27 January 2015 (UTC)
    • Except in that case, the wait was due to a delay in requesting protection. The first vandalism edit was at 3:58, but it wasn't reported to RFPP until 6:11, then it only took 7 minutes for an admin to respond. Mr.Z-man 20:24, 27 January 2015 (UTC)
Bam. Beeblebrox (talk) 20:32, 27 January 2015 (UTC)
Yes, but "Bam" is not always what happens. As much as I wish it were different, the response time is usually not that quick. I've sat down in the morning to review the Special:PendingChanges list to see articles (often BLP and especially on the weekends) that have gone 16-24 hours without review. --Scalhotrod (Talk) ☮ღ☺ 17:09, 10 February 2015 (UTC)
What does blocking and protection have to do with pending changes review? --Bongwarrior (talk) 17:59, 10 February 2015 (UTC)
Bongwarrior, that's how much of the IP vandalism is identified, at least from my perspective. It's not unusual to spot one or more IPs vandalizing across several articles. Here are a couple examples from just the last hour [29][30]. Same 2 articles are vandalized. Patrol the Pending Changes list and this stuff sticks out like a sore thumb. --Scalhotrod (Talk) ☮ღ☺ 18:11, 10 February 2015 (UTC)
And yet during this time the IP editor was able to vandalize 4 more times. Between me reporting the user at 6:07 and the user being blocked at 6:16, the user was able to vandalize 8 more times. If I had had the vandal fighter tool, the vandal would not have been able to vandalize at all after 6:07. I fail to understand why giving a user carte blanche range to vandalize for 10 minutes is a desirable outcome, and the vandal fighter tool still seems like a net positive user right. Spirit of Eagle (talk) 21:09, 27 January 2015 (UTC)
Because the power to block users is rightly reserved for persons who have been specifically appointed to that task by the broader community. Nobody gives carte blanche to vandals, but we also don't want to be handing out the most dangerous and controversial admin tool willy-nilly so that anyone who sees one edit they don't like can shoot first and find a real admin later. You don't like not being able to deal with it, run for adminship. We do need more admins. Beeblebrox (talk) 21:18, 27 January 2015 (UTC)
The problem is that users interested solely in vandalism fighting are unlikely to ever pass an RfA because they don't have enough content editing, article creation, WP:GA/WP:FA, AfD, etc. experience. They are also likely to fail due to the "Diversity" clause of WP:RFAADVICE. --Ahecht (TALK
) 17:21, 10 February 2015 (UTC)
Cases like this represent a small fraction of semiprotection uses. In most cases, there are only a few vandalism edits in a day, often hours apart. The real problem is that a significant fraction of RFPP requests are declined (15-20%, looking at the last few days in the archive) and a lot of these declined requests are made by people with rollback and reviewer. People also frequently request long-term or indefinite protection when only a week or so is necessary. So for every case where we stop a vandal from making a few more edits, we'd also be protecting a page that doesn't need it. Protection is one of the most sparingly used admin tools, and for good reason. "Anyone can edit" is one of our core principles, so restricting that is kind of a big deal. Mr.Z-man 21:53, 27 January 2015 (UTC)
Mr.Z-man, please spend a week or even just a few days reviewing the Special:PendingChanges list and see if your viewpoint doesn't change. BLP vandalism is CONSTANT and especially bad when the person is part of the current news cycle. Chris Christie, Bill Belichick, Kris Jenner, and various soccer/futbol players and wrestlers are perpetual targets of attack by overzealous fans or vitriol spewing haters. --Scalhotrod (Talk) ☮ღ☺ 17:15, 10 February 2015 (UTC)
I'm not sure what your point is. If they have Pending Changes, then vandalism is much less significant of a problem since almost no one will ever see it. What problem are you describing that this proposal is supposed to solve? We already give out reviewer rights liberally. I don't deny that vandalism and BLP vandalism exists. What I don't see is a justification to give out blocking and protection rights as easy as we give out rollback. Mr.Z-man 18:00, 10 February 2015 (UTC)
Mr.Z-man, then we seem to be discussing different points. I'm simply advocating for the right to be created/granted. As for how its done, I commented below that maybe we need an "RfA Light" that isn't so daunting or vitriolic as the regular RfA process. I am in no way in favor of assigning this right in "wholesale fashion" like Rollback or others are. But support should be given to those that want to contribute their time and efforts to prevent vandalism. --Scalhotrod (Talk) ☮ღ☺ 18:18, 10 February 2015 (UTC)
The problem with this reasoning is that a spree vandal (and that vandal has been persistent since at least the New Year) would only have to plan slightly ahead and make sock puppets a few days in advance. Each sock would then become autoconfirmed (and thus immune to vandal fighter efforts) on its 10th edit. Maybe we do need some kind of "junior admin" with less power and a lower bar to pass RfA, but that should still be assigned by some kind of RfA, not handed out by any sysop. Pathore (talk) 01:38, 28 January 2015 (UTC)
Thinking through this some more, I'm starting to see the many problems that will occur if we give this right away like we do with rollback and pending change review. However, I still think that there are many non-admins who could be trusted to use this right well. I would support requiring that this right be granted through an abridged RFA process. This would greatly would largely prevent the abuse of this right and would still address the concerns I've listed above. Spirit of Eagle (talk) 02:41, 28 January 2015 (UTC)
As far as that particular vandal goes, either long-term semi-protection or an abuse filter will likely be needed. That vandal has already waited patiently for semi-protection to expire the first time and this is the second incident. The WP:DUCK vandalism all seems to come from the same ISP, varying between mobile and a wired service in a particular (large) city. It was amusingly sophomoric once. Edit warring to keep it there is not amusing at all. Pathore (talk) 02:02, 28 January 2015 (UTC)
  • How about this case, where the vandal vandalized egg 174 times for half an hour? The vandal was blocked more than half an hour after the AIV report. I am not saying that this case alone is sufficient justification, but it does show that the AIV notice board in its present form may not be efficient enough. Tony Tan98 · talk 01:12, 29 January 2015 (UTC)
  • What about this user whom created edit warring since December? The user was able to transform into two other different IPs (one, two) whilst the vandalism continued. And they still do. How about this user whom caused edit warring over a stupid edit. They vandalized two pages and a talk page. The user never got the block they deserved. The user converted into different IPs (one, two, three). They continue to vandalize the pages. Callmemirela (talk) 01:43, 3 February 2015 (UTC)
    • I'm not trying to pick on you specifically, but this is one of the biggest problems I've been seeing in AIV reports lately. "Vandalism" is not just a catch-all term for disruptive editing. Edit warring and NPOV violations, except in the most extreme cases, are not vandalism, should not be reported to AIV, and would not be in the scope of this proposed user right. As an admin uninvolved with the topic, edits like this look like a content dispute. So if I see it at AIV I'm either going to spend a ton of time researching it (because the 1 sentence of context in the report likely just called it vandalism) while cases like Tony Tan's sit waiting for action or I'm just going to ignore it or refer the reporter elsewhere. (In this case it looks like you made the correct choice and reported it to WP:ANEW, but if you had this right, protecting the page or blocking the users yourself would be inappropriate for multiple reasons). Mr.Z-man 05:54, 3 February 2015 (UTC)
      • Mr. I understand you're coming from, and I am well aware of AIV, but as admin you have the right to block the user. No administrator did so. They have caused edit warring (both IPs I mentioned) for a long time, and I only got page protections as results. Once the protection is lifted, the edit warring resumes again. And again, I was stuck with page protections. It was not exactly content dispute. The DWTS vandalism was unsourced and faked by a fan. They vandalized the talk page with the same thing over and over again. As an admin, they should had seen the pattern. A protection was not enough. As for the The Fosters vandalism, it was maybe content dispute. But the user continued. It contained no factual evidence that it was not a hate group or it was not following guidelines. This is why this is why this user right is needed. A block of 24 hours maybe would had sufficed for the users to understand. Both users failed and ignored to understand the warnings on their talk pages including their reverts. As an admin, I expected a block to halt the their continued pattern. They continued before, and they will resume once the protection is lifted. They were disrupting Wikipedia, without even consulting others. One did, but it was trolling with the same thing. This is why this user right is needed. It's been two months it has been going on. What are you waiting for exactly? Though, it should only be given to trusted users and a mini-Rfa. (I don't plan on continuing arguing about the edit warring caused by the IP users). Callmemirela (talk) 02:42, 4 February 2015 (UTC)
So, because you disagreed with an administrative decision you should be granted the right to just block as you see fit? This is an excellent argument against this idea. Beeblebrox (talk) 03:03, 4 February 2015 (UTC)
  • Vandal fighter rights must only be used for obvious spam and vandalism.
  • As for the The Fosters vandalism, it was maybe content dispute. [...] This is why this is why this user right is needed.
I must agree, you're not helping the case for the right. Anything that smells remotely like content dispute is not "obvious spam or vandalism". ―Mandruss  03:35, 4 February 2015 (UTC)
  • Mandruss I am presuming when you mean "I must agree, you're not helping the case for the right.", it is pointed toward that I am not helping my support. I would like to explain myself. I never said that I wanted the user right because I didn't agree with an admin. I included the edit warring as an example which turned into a repetitive pattern of continued vandalism. I was merely explaining of what I experience(d) for every-day edits on my watchlist. I know my intentions may be off the grid because of my previous comment to Mr. Z. I want to be granted the user rights, because I want to stop vandalism. If you read through my history for Jack & Jack and Shawn Mendes, I encounter every-day vandalism from fans, stating themselves as dating the celebrities or adding falsified content and so on. For that, I would use the Vandal Fighter user rights. As for the others, I would continue to do what I do, but I expect an admin to stop the edit warring, because it's been going on for long and no matter what warnings or messages are placed, nobody seems to listen. I apologize if my intentions, if I had the user rights, were unbalanced and pointed to the wrong direction. I was merely explaining what I think should had been done, but then again I am not admin, and as a user, seeing this almost everyday, is extremely frustrating. I'm pretty sure you've been there before. Why I believe the user rights should be granted to users through mini-RFAs remains the same. Not all admins are available, and the continued vandalism goes on. Not every RPP, AIV, 3RR/EW, etc. are answered right away. I admit that this user right is another big job to take on, which is why I suggested the granted admin to review the user for some period time until they deem them correct and the history will show their actions. Callmemirela (talk) 04:31, 4 February 2015 (UTC)
It's true that WP:Vandalism defines the word broadly, listing 21 different types of vandalism. But I don't see any that appear to cover "adding falsified content". To me, that falls under content dispute, and, if the user fails to adhere to the correct process for resolving the disagreement (article talk consensus), disruptive editing. Neither of which fall under the scope of this right. Also the right is not to be used to "stop edit-warring". Edit-warring is disruptive and time-wasting, but this right is not for stopping everything that is disruptive and time-wasting. Per Wikipedia:Vandalism#Disruptive editing or stubbornness, Edit warring is not vandalism and should not be dealt with as such.Mandruss  04:45, 4 February 2015 (UTC)
Mandruss, falsified content as in what I stated before that: fans stating stuff and whatnot which falls under Hoaxing vandalism. As for the IP addresses, I stand corrected. Yes, it is disruptive editing. Though, to me, the vandalism page's first sentence, and in my cases, explains that it compromises the integrity of Wikipedia. Disruptive editing should be considered as such, but it is not. I stand corrected. I will now refer myself to the DRN for them. But I stand on the other pages I mentioned previously for falsified content which does link to this user right. Callmemirela (talk) 05:11, 4 February 2015 (UTC)
Well it's clear that an editor with thousands of edits can be confused about the scope of this right. You have stood corrected twice. If you already had the right, you would have inappropriately blocked multiple users. We could develop a competence test, but that could be too easily gamed. I'm beginning to think we should narrow the scope, at least at first, to include only two basic kinds of vandalism: (1) repeatedly inserting pure garbage characters (and failing to respond to "edit test" warnings), and (2) adding clear racial slurs and hate speech. That would address a large part of the problem while simplifying things enough to make misunderstanding of the scope very unlikely. If that worked out well, we could then consider adding other types of vandalism, one at a time. The vandal fighter "summary page" that I suggested in my !vote would show the current scope, and all vandal fighters would be expected to watch that page for updates. ―Mandruss  05:37, 4 February 2015 (UTC)
Mandruss Yes, I can agree. After almost two years on Wikipedia, the rules are still in your mind, but not refreshed. I suppose I could blame myself for that. As for your suggestion, I concur. It is best we give this user right a try before going full on with it. We could try with something rather simple then go more complex if the first try is successful. I mean, in all honesty, opposing is useless if we've never given these rights a chance. We can't judge before trying, no? Callmemirela (talk) 03:15, 5 February 2015 (UTC)
Correct. Wikipedia needs to be willing to take some risk if there is to be any real progress. The most successful companies understand this. ―Mandruss  03:19, 5 February 2015 (UTC)
I think that "racial slurs and hate speech" is too vague and subject to wikilawyering. "Insertion of inappropriate profanity from this list: <words>" would be much clearer, while still including the common types of blatant "shock word" vandalism. What words should count as "shock words" is a topic for another discussion. Pathore (talk) 01:16, 6 February 2015 (UTC)
One of the worst examples of hate speech I've come across made reference to burning Jews. No profanity or shock words there, but the hate was off the scale and the person needed to be stopped in a hurry. ―Mandruss  06:32, 6 February 2015 (UTC)
If the idea is to dip our collective toes in the water by starting vandal fighters off with a restricted scope, the more clear we can make that scope, the better off we will be. Shock words aren't something a bot could police, because Wikipedia is not censored, and I'd imagine that all of the English shock words do have legitimate use somewhere on Wikipedia. Even a burning synagogue has a place on the English Wikipedia. That said, I'm sure that vandal found a very inappropriate place for his remarks, but we have ANI and AIV for that type of blatant incivility. Knowing how controversial a vandal fighter role will be, even as this sort of "trial balloon", is it not best that we propose the trial balloon with the clearest lines possible? Pathore (talk) 03:32, 7 February 2015 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────I couldn't really disagree more with this approach. I think if we don't trust someone to tell the difference between blatant vandalism and an edit war, they should't even have rollback, let alone the ability to block or protect pages. This shouldn't be given out to just everyone who asks for it, it should be like template editor or file mover - only given to people with substantial anti-vandal experience and a demonstrated need. I don't think that widely giving out the ability to block will ever be acceptable to a sufficient chunk of the community, regardless of how restricted it is. And since it's impractical to have software restrictions on the reason for a block, now we're back to every block having to be manually reviewed by an admin, which is going to mean even less support. Mr.Z-man 05:22, 7 February 2015 (UTC)

  • This latest permutation of the proposal may be the worst one yet. People who are posting hate speech and extreme profanity need to be dealt with by a real admin who can issue indefinite blocks, delete pages and revisions containing hate speech, and revoke talk page access. These are some of the worst vandals and they need a firm hand, not the slap on the wrist that would be all these psudo-admin could deliver. Beeblebrox (talk) 19:25, 8 February 2015 (UTC)
    Agree with Beeblebrox. Aren't the hate speech vandals usually long-term abusive sockmasters anyway? Pathore (talk) 01:24, 9 February 2015 (UTC)
  • I can understand why several of you feel so strongly about this. So if this is the case, then what about some sort of "RfA Light" process to be granted this proposed right? RfA is so daunting and has made so many people fearful or just flat out responsibility adverse, that something needs to change. But I don't realistically see a fundamental change at RfA any time soon. We're losing good editors AND Admins[31] faster than we can gain them.
  • Maybe the answer is that a limited number of Senior Admins have the power to grant this right and can review each case in more detail. Effectively accomplishing the purpose of an "RfA Light" process. --Scalhotrod (Talk) ☮ღ☺ 17:25, 10 February 2015 (UTC)
I'd like to point out that the "Senior Admins" you suggest sound a lot like our current bureaucrats.
Earlier I suggested sending vandal fighter applications through RfA and trusting that the community would recognize a lower bar for granting it. There really is no consensus here, neither for nor against, and the community is about evenly split. I'm still somewhat on the fence about this, but the "handed out by any sysop" part is why my vote is an oppose for this iteration of the proposal. Pathore (talk) 22:06, 10 February 2015 (UTC)
An "RFA light" with closings by Bureaucrats based on consensus actually sounds like a great idea. Tony Tan98 · talk 03:47, 11 February 2015 (UTC)
Well, the WP:RFA page lists the applications for Admins and Bureaucrats (RfX), I don't know what the technical considerations are for this, but if the desire for this right to go through RfA is so adamant, then perhaps a 3rd section could be added. A "RfVR" (Vandal Reverter) section could address the processing of these requests. That way we can have a formal process, tracking, and an archive. --Scalhotrod (Talk) ☮ღ☺ 19:07, 11 February 2015 (UTC)

A Different Approach

Honestly all these arguments seem to be structured around one person having this power. A better approach may be to have multiple people in a certain group vote on that power. Therefore it seems to be more balanced as it is a voting system. Example:

  • User A nominates Suspicious Person A to be blocked.
  • Other users in that group contribute to the discussion with Support and Oppose etc.
  • Users vote on whether Suspicious Person A should be punished or not
  • Users then decide on the severity of their punishment

Not sure how this would be implemented, just putting this thought out there.

asdfawesomegreen (talk) 02:31, 12 February 2015 (UTC)

I think you just described how WP:ANI is supposed to work. Pathore (talk) 03:22, 12 February 2015 (UTC)
Actually, let me be more specific.
  • User A must be in that special group alone or the "Judge Group".
  • Other users meaning "Judge Group" who decide whether they are guilty and vote/abstain.
  • The users in the group are sharing the power as in after they select some choices within a certain time limit, it goes into effect.
  • Judge Group User A votes a ban
  • Judge Group User B votes no ban etc.
The person would then be banned by a somehow implemented poll or by a neutral user/administrator overseeing the group
I hope this clears up any confusion asdfawesomegreen (talk) 03:38, 12 February 2015 (UTC)
If the admins are the "Judge Group" you suggest, then you are more-or-less describing WP:ANI as I understand it. The major difference being that ANI is open to anyone. Blocks, bans, etc. are handed out based on consensus at ANI.
The "shared power" concept you advance would be completely useless in this proposal, since the whole point of this proposal is to stop vandals faster than we currently can. Since blatant vandalism-only accounts get indef blocked as soon as an admin finds them, the only way we can make that first block hit the vandal faster is to have more people looking and able to block a new vandal. The proposed steps are (1) vandal vandalizes, (2) vandal fighter blocks vandal for up to 48 hours, (3) admin reviews block within 48 hours and indef blocks vandal, thus, no more vandalism from that vandal. Our current process is more like (1) vandal vandalizes, (2) someone doing anti-vandalism patrol notices and makes a report at WP:AIV, (3) admin at AIV sees report and indef blocks vandal. The reason for the proposal is that a new vandal can sometimes do quite a bit of vandalism between steps (2) and (3) of our current process. Pathore (talk) 05:53, 12 February 2015 (UTC)

NPP review structure

In light of the pre-speedy deletion tag failing to gain consensus, I propose we change NPP to allow a reviewer to take an article under their wing, to be exclusively their review project. AFC allows a user to mark an article as under review, this is effectively what I'm proposing.


  • Would not interfere with those who don't adopt the system as it will be optional.
  • Allows more careful investigation before tags are placed
  • Moves NPP in the direction of more experienced reviewers
  • Could latter be expanded into article categorization for custom review scripts(like AFC)

Example tag:


Don't fear change people. Unit388 (talk) 02:57, 8 February 2015 (UTC)

  • Has there been an issue with the NPP process that this is intended to address? Praemonitus (talk) 03:44, 8 February 2015 (UTC)
  • Echoing an issue raised in the discussion of the previous proposed template, what is the need for this? We already have planned changes to the CSD templates to prevent tagging of a new and active article waiting on needed support in the software. This looks to me like creeping bureaucracy. Further, take an article under their wing, to be exclusively their review project(emphasis mine) sounds like a proposal to weaken WP:OWN. Unless, I've misunderstood something here, my position on this proposal is "No... just.... no". Pathore (talk) 06:40, 8 February 2015 (UTC)
  • Oppose This looks unnecessary. If a reviewer is talking with (not just 'to') the author (meaningfully) about improvement, and there are signs of this getting through, the article should be given leeway by other patrollers and admins. If the reviewer is really serious about reworking things, they can userfy it and work with the author on it, or if it needs very little work, just don't tag it and do get on with it. But there is no exclusivity involved. Or again, just put a note on the talk page to say that things are being sorted. Admins SHOULD check the talk page before deleting, and if they don't, can simply restore it when they go to delete the talk page. I could see the use of this template possibly being abused or misused. Peridon (talk) 13:25, 8 February 2015 (UTC)
    Thanks for your note. I've responded on my talk page. -User:Peridon

+1. Supporting Peridon's 'oppose' arguments. --User:Ceyockey (talk to me) 06:12, 12 February 2015 (UTC)

It should be noted that Unit388 is selectively canvassing editors for support on the above two proposals. Resolute 19:36, 8 February 2015 (UTC)

  • Oppose Clearly a knee-jerk reaction to the discussion above, seems to violate WP:OWN and is something a user can do if they wish without needing any tags or new, needless processes. Beeblebrox (talk) 19:42, 8 February 2015 (UTC)
  • Oppose - A case has not been made for the need or utility of such a template. I would strongly urge the proposer to learn more about Wikipedia and NPP before proposing any more such templates.- MrX 19:48, 8 February 2015 (UTC)
  • Neutral - I don't see the harm in this. My only concern is the language "to be exclusively their review project" (emphasis added) - this violates WP:OWN. No page on Wikipedia is exclusively anybody's. However, I think that the effect of this proposal is already covered nicely by {{Under construction}}, and I don't see the point in duplicating it. And I especially don't want to see AfDs with oppose comments like "You can't delete this article on my basement web business! It's tagged as under review!" and I'm worried that this opens that door. Ivanvector (talk) 15:38, 9 February 2015 (UTC)
  • Oppose, solution looking for a problem I think. Stifle (talk) 11:50, 16 February 2015 (UTC)
  • Oppose in concord with the other 'opppose' rationales, and various discussions on the proposer's talk page. --Kudpung กุดผึ้ง (talk) 21:04, 25 February 2015 (UTC)

Delete "autochecked" usergroup

The autochecked usergroup has no use since its unique permission, 'autoreview', is possessed by all autoconfirmed users, and in order to be effectively autoreviewed, 'autoconfirmed' is checked too. Due to the way FlaggedRevs is written and for compatibilities with other configs, it is not possible to make it into a potentially useful group as was thought originally. Therefore, I suggest to simply delete it. Cenarium (talk) 09:18, 12 February 2015 (UTC)

  • Oppose as Wikipedia:Autochecked users tells us that it is required for WP:ORANGELOCK pages. Since there are pages using that level of protection, and There is only a consensus for implementation if and only if an rfc concerning criteria for its use gains community-wide consensus first. (PC/RfC 2013), there is consensus for proposals 1 and 2 and 7 to be used as criteria, but only if PC2 is implemented in the future.(PC/RfC 2014) then it is improper to delete this usergroup there certainly is potential and we just need to put the pieces together in the 2015 proposal and see if there is consensus to establish PC2 using the wording in proposals 1, 2, and 7. — {{U|Technical 13}} (etc) 17:11, 12 February 2015 (UTC)
    • @Technical 13: I have written the documentation on autochecked you cite, and as it seems unclear I rewrote it. I had exactly the plan you mention in mind for this group until I started delving into FlaggedRevs code to help in developing deferred changes, and passive reviewing, and it's clear that "autoreview" cannot be used for this purpose since all autoconfirmed users must have it. Cenarium (talk) 19:12, 12 February 2015 (UTC)
      • I'll need to dig in to the technicalities of how PC2 works on another day when I'm not in class, but I'm fairly certain it can be done. Then we can have a discussion on how it works and if the community still wants to have the ability to flag people to bypass all PC without just giving them PC reviewer which might be another topic all together. Where was the discussion to create this usergroup, that might be useful to help understand some of the background. Thanks. — {{U|Technical 13}} (etc) 19:32, 12 February 2015 (UTC)
        • There was no discussion, it's bundled with FlaggedRevs and should have been unset from the start. If we want to allow autoreview on PC2 without review, then we need to create another userright for it, e.g. "super-autoreview", but "autoreview" cannot be used. Cenarium (talk) 19:47, 12 February 2015 (UTC)
  • oppose The current limited "IAR" use of PC2 is actually a good thing, it's acting as a very limited trial that will inform any future discussions on the use of PC2. (i.e. the wiki won't crumble if we use it in limited cases). I'd say the future prospects for PC2 are good at this point and we shouldn't mess with its technical basis right now. Gigs (talk) 17:50, 12 February 2015 (UTC)
    • @Gigs: As noted above, it's technically impossible to use this group for the purpose you mention. Cenarium (talk) 19:12, 12 February 2015 (UTC)
      • Nothing is technically impossible, you just haven't figured out how to make it work yet. — {{U|Technical 13}} (etc) 19:32, 12 February 2015 (UTC)
        • It's technically impossible to use the 'autoreview' userright for this purpose due to the way FlaggedRevs is written now, and this cannot be modified in any way that would satisfy developers, I'm pretty sure of that. 'autoreview' is the first check made, and all others follow, bypassing this check would cause issues with other configs, or it would require a hack, when the alternative of using another userright check for it is preferable. Cenarium (talk) 19:47, 12 February 2015 (UTC)
          • Does it hurt anything to leave it, even if it is buggy? Gigs (talk) 19:51, 12 February 2015 (UTC)
            • Yes, it does, it confuses people, and they can see it from plenty of places where this confusion can't get cleared up. For example at Special:ListGroupRights, the description 'Have one's own revisions automatically marked as "accepted"' can be true or false depending on whether the group also has 'autoconfirmed' or not. It's the third group at Special:ListUsers, it wastes people's time. Cenarium (talk) 20:01, 12 February 2015 (UTC)
              • "People" is very broad---readers never see this, and I'd gamble that a large variety of editors never venture in to those special pages. — xaosflux Talk 20:12, 12 February 2015 (UTC)
                • The page gets hundreds of page views each month. We can't know how many see the usergroup and its misleading name and description, but it's probably much more than that, a thousand a month at least, and those who don't click can't get cleared up about the purpose of the group. Cenarium (talk) 10:09, 13 February 2015 (UTC)
  • Support It's completely useless. @Technical 13, Gigs: Even if we were to allow PC2 at some point, the group as it stands now would still be useless, since there'd be no way to allow its members to review pages that autoconfirmed users couldn't do. (Yes, we can change this, but we can also bring the group back if we ever want PC2.) Jackmcbarn (talk) 12:51, 13 February 2015 (UTC)
    • Seems like unnecessary BIKESHEDing to me. I don't approve of that, but if the rest of the community insists it be red instead of blue, I won't put up too much of a fuss about it. I think too much user time is being wasted on this group to remove it just so we can add it back later, and I won't be specifically watching... — {{U|Technical 13}} (etc) 15:52, 13 February 2015 (UTC)
      • It's very little time compared to the cumulated time wasted by the hundreds of users seeing this page every month, and those who don't click it and get confused about it. And again it wouldn't be a matter of adding it back, it cannot work as is, we'd need other userrights, and we might as well use WP:Autopatrolled. I honestly thought it would be uncontroversial, especially when all is needed is to change two lines in the config. Cenarium (talk) 12:34, 15 February 2015 (UTC)
  • I guess I support this, but this useless "autoreview"/"autochecked" group should not be getting created by FlaggedRevs in the first place. Although Hungarian Wikipedia made this request on a local-wiki basis in phab:T74055, I think it would make more sense to see why this group is getting created, and to get rid of it (or at least make it optional) in the FlaggedRevs code. It's clearly something we don't need here. — This, that and the other (talk) 13:17, 16 February 2015 (UTC)
  • Fix: Remove the "autoreview" right from the group. Create a new right which does grant the ability to be automatically reviewed, and assign that right to this group. Technology is plastic. I don't see any satisfactory explanation of why this is impossible beyond "we haven't written it yet." --NYKevin 23:27, 17 February 2015 (UTC)
  • Support. If mcbarn says it's completely useless, that's good enough for me. Currently there are 0 autochecked users; so this group seems pretty pointless. What the heck's the difference between an autoconfirmed and an autochecked user? Per "bikeshed", I'm not bothering to take the time to understand what this exactly is, but just noting that WP:CD led me to this bike shed. Wbm1058 (talk) 18:47, 19 February 2015 (UTC)
  • Support, this group is technically unnecessary. Nakon 04:06, 21 February 2015 (UTC)
  • Support per nom. Looks like the group is pretty much useless. APerson (talk!) 02:08, 27 February 2015 (UTC)

Proposed change to unsigned templates

Right now if you place an {{subst:unsigned}} template (and its many sibling templates), you get something like this:

Here's my comment blah blah blah. — Preceding unsigned comment added by Example (talkcontribs) 00:00, 12 February 2015‎

I suggest changing it to this:

Here's my comment blah blah blah. Example (talk) 00:00, 12 February 2015‎

This is all about good faith. Everyone forgets the tildes sometimes, so why should there be a permanent record of a routine ordinary goof? Such a scarlet letter is not good faith. The link on the word unsigned is not vitally important. The signing bots will post on user's talk pages if they forget several times, and experienced Wikipedians will tell new users this too. The worst that happens without it would be that the sign-bots sign a few more posts, which isn't a problem. Oiyarbepsy (talk) 03:00, 13 February 2015 (UTC)

Generally we don't want to change things on talk pages, even if we're "correcting" mistakes (such as leaving out a signature), in such a way that is misleading as to who it was that made the change. The unsigned template specifies that the previous comment was unsigned so that it easy to see which part of the comment was written by the original poster and which part was added later. --Preceding signed comment added by Ahecht (TALK
) 03:40, 13 February 2015 (UTC)
Well, you could place a small note stating Signed by Someone'sBot Oiyarbepsy (talk) 05:45, 13 February 2015 (UTC)
  • It's kind of funny to me that {{Unsigned}} violates the typical form defined in Wikipedia:Talk page guidelines#unsigned of —[[User|''USERNAME'']] ''TIMESTAMP OF EDIT'' (UTC) yet is encouraged to be used despite the fact it is a template that appears to me and a few others at least to indicate bad faith. What I find even more hilarious is that the following section, Wikipedia:Talk page guidelines#sigclean it is indicated that attempts to fake a signature may be edited in a way that changes the signature to the standard form with correct information (—{{subst:User}} TIMESTAMP OF EDIT (UTC)) or some even simpler variant. So, why not just dump all of the unsigned templates and make it easy by just one template for all situations? — {{U|Technical 13}} (etc) 04:06, 13 February 2015 (UTC)

I am not sure I follow the logic here, and I have studied some.

  1. User X forgot to sign their post.
  2. Therefore, user X is evil. QED.

Please enlighten me. Keφr 19:22, 13 February 2015 (UTC)

I see no badge of shame here; that seems to be a gloss added by the reading of the linked word "unsigned" as having an accusatory effect. I read it as a simple, neutral statement of fact which serves the dual functions of informing the user of the need to sign while also sending them to an information page to learn about signing, and by context making it clear the post is not by the user (an important clarification to the user and everyone else). I'm sure gobs of users have learned about signing as a result of this template. The timestamp is not left out of the template (see its documentation). The fact that the timestamp is not usually included is just a function of the bot that places unsigned being too dumb to be sure which revision in the history is the correct one right? If that complexity could be added to the bot, I'd support that, but I don't see a need for a change to the template.--Fuhghettaboutit (talk) 19:38, 13 February 2015 (UTC)
  • I also find it puzzling why anyone would perceive a simple mistake being corrected as implying an assumption of bad faith. Beeblebrox (talk) 20:46, 13 February 2015 (UTC)

We could use a variant on User:Oiyarbepsy's proposal:

Here's my comment blah blah blah. p.p. Example (talk) 00:00, 12 February 2015‎

which is closer to usual sigs, but makes the action clear and retains the link to Wikipedia:Signatures. (See Per procurationem.) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:28, 13 February 2015 (UTC)

I'd rather we use a note that we don't need to explain to everybody. P.p. is obscure, even for a Latin abbreviation. Thus my suggestion, signed by user or signed by another editor if not specified. Oiyarbepsy (talk) 00:33, 14 February 2015 (UTC)
In case you didn't notice, my suggestion not only includes a link, but also abbreviation markup (try hovering your mouse pointer over "P.p"*; or view the source HTML code). And "P.p." is the correct annotation to use in such a case. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:23, 15 February 2015 (UTC)
I like this idea. Obscure or no, it takes up very little space. Although "p.p." is obscure, Wikipedia is hypertext, and it would be a link to Wikipedia:Signatures, where the Latin abbreviation could be explained. Pathore (talk) 03:51, 14 February 2015 (UTC)
Like Pathore, I like the p.p. with mouseover and link. It is concise and indicates exactly what was done rather than delving into why it was done. However, might be better to have:

Here's my comment blah blah blah. --xyzq p.p. Example (talk) 00:00, 12 February 2015‎

The template could take the form of {{subst:ppsign|Example}}, where ~~~~ was added by the code in order to deter spoofing (i.e. user:qwerty using the template instead of user:xyzq but attributing it to user:xyqz). --User:Ceyockey (talk to me) 12:35, 16 February 2015 (UTC)

This change would affect all unsigned templates currently in use unsubsted and would therefore change many archive pages etc. Also, this proposal amounts to autosigning, so new users won't learn how to sign properly. Then, once they get above the signing bot's edit threshold of 800 edits, they'll wonder why their signatures don't show up any more. Also, as I have previously said, the template as it stands is not a sign of bad faith. Any reasonable person will understand that people make mistakes -- including experienced users -- and won't hold it against newbies. Per Kephir, I just don't comprehend it. BethNaught (talk) 08:15, 14 February 2015 (UTC)

The signature bots all put a notice on user talk pages if a user repeatedly fails to sign, so they will know. Oiyarbepsy (talk) 09:00, 14 February 2015 (UTC)
Changing archived pages in this manner would do no harm; and there is plenty of precedent for changing templates which are unsubst on such pages. We already use Autosigning. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:19, 15 February 2015 (UTC)
In my experience the few users who are actually bothered by this just go back and add their signature. I don't see any tangible benefit to this idea, frankly the whole thing seems petty and unimportant. Beeblebrox (talk) 23:13, 15 February 2015 (UTC)

Lower case type for all internationally recognised terrorist and criminal organisations, and convicted criminals.


Points made, no need to pile on. – Philosopher Let us reason together. 21:52, 17 February 2015 (UTC)

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

re - etc

Don't use capital letters for these psychopaths - it only serves to boost their status.

islamic state; they are not islamic, they are not a state.

They are not even muslims.



Call them daiish – apparently they don't like it and it is used as a derogatory term in some parts of the Middle East. Though even this is just another acronym of islamic state.

Only use lower case type for all internationally recognised terrorist and criminal organisations, and convicted criminals.

Please pass this to your policy making people asap

PWWJ — Preceding unsigned comment added by P W W Jones (talkcontribs) 21:28, 15 February 2015‎

Wikipedia merely summarizes mainstream academic and journalistic sources and uses the terms they use. Capitalization is not intended as any sort of glorification. Ian.thomson (talk) 21:49, 15 February 2015 (UTC)
We use what the reliable sources use. They capitalize, we capitalize. If you think this change should be made, go talk the reliable sources into changing how they refer to these organizations/people and then we will follow suit. -- GB fan 21:50, 15 February 2015 (UTC)
English has rules for using capital letters. Proper names in English are capitalized; see MOS:NAMECAPS. Further, "ISIS" and "ISIL" are also acronyms; see MOS:CAPSACRS. Pathore (talk) 22:08, 15 February 2015 (UTC)

I would like to add, regardless of what the sources add, Wikipedia goes by the rules of standard English. If the sources fail to use this, then they fail to be reliable sources.--Nadirali نادرالی (talk) 01:05, 16 February 2015 (UTC)

Indeed, until daiysh becomes the accepted name in English language reliable sources, we can't use it. As nice as it would be and as many editors would agree with you, certain rules are in place and must be followed, with only a certain amount of room for bending. Sir William Matthew Flinders Petrie | Say Shalom! 26 Shevat 5775 22:23, 15 February 2015 (UTC)
  • Per all the above, as much as we might personally dislike a group or person, we do not and should not deliberately insult them either. This would create a very slippery slope that is best avoided. Beeblebrox (talk) 23:10, 15 February 2015 (UTC)
Welllllll, you could insult the them in every-day life, in social media, and everywhere else as is only right given that they are khawarij, but it mustn't get into the editing process here, of course. One productive thing you could do is to be vigilant on Daiysh-related articles for POV-pushing edits as there are some supporters of this group that like to help out their 'cause' and turn Wikipedia into another battleground. There's tons of people watching those articles already, but it never hurts to have an extra set of eyes. Just be civil about it as you are better than them. Sir William Matthew Flinders Petrie | Say Shalom! 26 Shevat 5775 23:55, 15 February 2015 (UTC)
I suppose the real question is who defines which entities are the terrorists. A few terrified Iraqi civilians might like to put george w. bush at the top of that list, even if he calls what he is doing "shock and awe" instead of "terrorism". Furthermore, if one looks at the manner in which anti-terrorist legislation is being abused in the United Kingdom, the supposed terrorists are anyone from Icesave to the Guardian newspaper. K7L (talk) 22:14, 16 February 2015 (UTC)
In terms of editing Wikipedia, the reliable sources as always. Sir William Matthew Flinders Petrie | Say Shalom! 28 Shevat 5775 04:56, 17 February 2015 (UTC)

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

Should tagged recent changes be shown as unpatrolled ?

Tags added by the edit filter or, when implemented, by bots can be very helpful to track down certain type of vandalism, other inappropriate changes, or wikitext mistakes and visual editor bugs, among other things. Tags are listed at Special:Tags and recent changes can be filtered by tag. However, it is difficult to know when an edit has been checked - one needs to load page history and check manually when not the latest. This is inefficient, but could be improved using the native patrolling feature of mediawiki. For users with permission to patrol (at the moment, autoconfirmed users), a red exclamation mark would be visible next to unpatrolled tagged changes, and when clicking the diff a [mark this revision as patrolled] button would be visible. When patrolled, the red exclamation mark would disappear. Rollback also patrols automatically the reverted edits. Recent changes can be filtered by unpatrolled edits, so with this, we could very easily see which edits have been dealt with, and which still need checking. We could have a list of ignored tags (for example visual editor, HHVM, etc), which don't need to be shown as unpatrolled. It can be implemented without much difficulty, so is this something that we want ? Cenarium (talk) 12:45, 16 February 2015 (UTC)

As a follow up to this prior discussion on showing pages expanded from redirects at Special:NewPages. As pointed out there it would be difficult to do so, but if those are tagged by a bot, then they will be able to show up unpatrolled at Special:RecentChanges, and they can be patrolled there this way. Cenarium (talk) 18:58, 16 February 2015 (UTC)

Should Wikipedia use HTTPS by default for all readers?

Should Wikipedia redirect all readers (logged in or not) to the secure version of the site by default to help protect readers' privacy? Wikipedia currently supports it, but by default visitors are directed to the HTTP version of the site. Making HTTPS the default setting would prevent governments, internet service providers, and hackers from snooping on visitors' traffic and seeing what a reader is reading. Many major websites, including Google, have already implemented this a long time ago. This would have little effect on the viewing/editting experience, and according to Jimbo, it wouldn't be a difficult change to implement.[1] Tony Tan98 · talk 20:33, 16 February 2015 (UTC)


Clarification: This proposal is not asking the community to make a "final decision" about the implementation of this change itself. Instead, it is asking whether the community thinks that the WMF should consider a change from the current HTTP-default mode. Tony Tan98 · talk 19:47, 21 February 2015 (UTC)

No. Privacy is very important for me, but money (paying 20€ for 5GB bandwidth monthly) beats it. Besides all those wannabe-secure protocols turned out to be insecure snake oil in hindsight. Users should be free to skip this overhead if they don't want it, same idea as "web fonts" and other cruft best handled by Noscript, Adblockers, or /etc/hosts. –Be..anyone (talk) 02:39, 17 February 2015 (UTC)
Not if it can be avoided. An encrypted page is more difficult to cache, so ISP's can't just serve up a local copy and must go back to the WP servers each time. K7L (talk) 02:49, 17 February 2015 (UTC)
  • It's so necessary that I use the browser extension HTTPS Everywhere from the EFF which forces an encrypted end-to-end connection if the servers have the capability, which Wikipedia has. Every connection I make here is encrypted and I had forgotten that the default is plain HTTP. - Becksguy (talk) 05:55, 17 February 2015 (UTC)
If this is simple to implement, as apparently Jimbo said, then I strongly support this, for the reasons given by the OP. In response to Be..anyone, people would have a way to turn it off (create account, set prefs to HTTP) but I believe this change would bring more benefit to privacy-concerned readers who don't know how to or can't install add-ons to enforce HTTPS, than disadvantage to ones who don't want HTTPS for some reason. BethNaught (talk) 08:12, 17 February 2015 (UTC)
That becomes impossible. If https is blocked (as is likely in some countries), there is no way to create an account and change it to http. They have to get to the site. While Western nations think of this as an increase in privacy, people in totalitarian nations will find it's a reduction of access. --DHeyward (talk) 02:44, 20 February 2015 (UTC)
I understand what you are saying, but I think it would be an increase of access. If a nation is totalitarian enough to block HTTPS, then it would be at least also filtering HTTP traffic by keywords. If the country is filtering instead of blocking the entire site, it means that while the nation does not want certain articles to be read, it doesn't want to block WP entirely because of the academic articles. By moving to HTTPS by default, it is actually more likely that the government would want to unblock HTTPS than to block off WP entirely because every country has researchers and students that need access to good information, which WP has. China currently has one of the most restrictive firewalls, (besides the countries that completely block off the internet), yet it allows https connections to Wikipedia. It is not just a privacy issue; HTTPS prevents selective filtering and tampering of the site. Tony Tan98 · talk 03:09, 20 February 2015 (UTC)
No, I don't think it does. If they control the DNS table, network routes, firewalls, etc, they can do MITM intercepts and https gives a false sense of security. Does wikipedia have enough 3rd party trust certification (and does China allow it?). Nokia did this with their browser and proxies and stored the HTTPS requests as clear text on their proxies and played MITM for requests because they could. Once you start to layer on the necessary privacy features, it will limit what works for individual users. http will always work if https is compromised or blocked and should be the default. https is fictional security without 3rd part, trusted certificates. --DHeyward (talk) 04:33, 20 February 2015 (UTC)
Yes, they control DNS, network routes, and firewalls, but not certificates. This means that any interception will trigger a browser warning. Even if they do control certificate authorities, they would not use it for the purpose of censorship as it would leave undeniable evidence and lead to the revocation of CAs (Certificate Authoritys) under their control. In the case of China, even though they own the CNNIC CA, which is trusted in most browsers, they don't use it because if they illegally issued a false certificate, they will leave evidence (in the form of a saved .crt file) and their CA will be revoked. Thus, in HTTPS they cannot selectively filter content on a website that they do not control because they will not be able to decrypt the traffic or manipulate it without triggering warnings in browsers.
About the "3rd party trust certification," HTTPS uses the public key infrastructure, which is based on certificates issued by trusted authorities. These authorities issue certificates for websites after they verify that the requester is the actual operator of the website. Because Wikipedia currently supports HTTPS, it already has a valid certificate issued by GlobalSign. These certificate authorities are currently used in China for online banking, so they are definitely allowed. By the way, you may find this informational video to be useful. Thanks, Tony Tan98 · talk 04:52, 20 February 2015 (UTC)
I don't consider censorship to be the main issue. It's snooping. Say a suspected dissident accesses Wikipedia through https; they think it's end to end encryption but with control of the network, firewall, DNS and CA - the dissident is really talking to a government computer that issues a certificate and that government computer (or more likely a hop or two away across a DMZ firewall) is establishing the TLS with WP. WP has no way to verify the request inside the firewall isn't valid (the same way they only see my ISP's IP address, not my local network IP). Dissidents computer has altered DNS table for wikipedia so it thinks it's actually talking to WP and gets a valid TLS certificate from China's CA - if NSA can do it without network control (which they do), China will have no problem. Now all his requests are visible to the government, yet he thinks it's secure. Which is the larger concern? I'd rather they think all requests are visible then a false sense of security that https is "secure". Censorship is not the problem, it's targetting of individuals that they are suspicious of. Wholesale certificate spoofs won't happen but it will most definitely happen to high value targets. --DHeyward (talk) 04:38, 21 February 2015 (UTC)
Where does China get a valid certificate for from? CNNIC? When word of that gets out, all browsers will promptly restrict CNNIC certificates to .cn domains if they don't remove CNNIC entirely. This is an attack that only works until it is discovered, then CNNIC's credibility goes to nothing and they will lose the ability to ever do it again. Remember DigiNotar? That's what happens when CAs get caught issuing bogus certificates. Pathore (talk) 05:03, 21 February 2015 (UTC)

I left a note on Jimmy Wales' talk page about this, since we're quoting his ideas in the first place. BethNaught (talk) 08:19, 17 February 2015 (UTC)

If I recall correctly, there were issues where some censor organisations block the wikimedia sites over https, but not over http. What's the status on that? Martijn Hoekstra (talk) 11:38, 17 February 2015 (UTC)
@Martijn Hoekstra:Yes, China used to block HTTPS connections to WP, but it doesn't do that any more. See here. Tony Tan98 · talk 13:45, 17 February 2015 (UTC)
Well, that's something. How about the others, i.e. Iran, Burma, Emirates, others? Martijn Hoekstra (talk) 13:53, 17 February 2015 (UTC)
I was thinking about that too. There isn't a lot of information. Censorship of Wikipedia mentions HTTPS only when discussing China, and a Google search for "wikipedia https censor" doesn't return much. If anything, defaulting to HTTPS should only discourage censors. Tony Tan98 · talk 14:27, 17 February 2015 (UTC)
Keep both available. Defer to WMF on default. I think it's clear that we should preserve the ability of users to access pages in either HTTP or HTTPS according to personal preference, for a number of reasons above. As for which page is the default, this is one of those rare cases where I'd actually prefer to kick this up to the experts rather than attempting a community decision. There are so many quantitative decisions - how much bandwidth, how much potential censorship, how much surveillance, how likely it is that Heartbleed was replaced long before it was made public, how much load on the servers... we need someone who genuinely knows what he or she is doing to make that sort of judgment call. Wnt (talk) 16:45, 17 February 2015 (UTC)
I have a very strong preference for HTTPS as the default worldwide. But I also agree with Wnt that there are many many complex variables and careful study is needed.--Jimbo Wales (talk) 17:30, 17 February 2015 (UTC)

Question: How would this even work? If I put in the location bar, most browsers will assume HTTP. If we wanted to change the "default" to HTTPS, we'd need to redirect. But if we redirected, HTTP would no longer be available, which according to Wnt and Jimbo is a Bad Thing. Can someone clarify the technical implementation for me? --NYKevin 00:00, 18 February 2015 (UTC)

For readers, there are any number of options. For example, one might make redirect to https, but not change other entry points. Or one might redirect to https whenever someone first enters Wikipedia with an outsider referer specified (e.g. all links from Google trigger https). Or when someone enters the http site, we might provide them with a dismissable popup box asking if they want to move to https and then remember that choice with a cookie. Lots of things are possible, some more reasonable than others. I agree with the above users that a decision like this is really more of an issue for the WMF to try and judge whether https is an appropriate option for most readers, and how to implement that if so. Dragons flight (talk) 00:30, 18 February 2015 (UTC)
I don't think that Jimbo said it would be a bad thing if HTTP was no longer available, but I agree that we should allow choice. I also agree that the WMF should be making the final decision, but do you (the community) agree that the WMF should consider a change from the current (HTTP-default) mode? Tony Tan98 · talk 02:07, 18 February 2015 (UTC)

Oppose Initial access should be the widest and most available protocol. That's http. I'd rather have a user start with http and debug https rather than having trying to figure out why their http request failed during a redirect to https. We have no way of knowing what access is available from an ISP or a particular platform. If a government decided to shutdown https traffic to Wikipedia, I don't think it's WP's place to lock that country out or make them debug why it doesn't work. Keep it simple and http the default. --DHeyward (talk) 02:38, 20 February 2015 (UTC)

While that used to be the case in China, the situation has changed there. There is currently no evidence of any government in the world blocking HTTPS access to Wikipedia while allowing HTTP access, but there is evidence that some governments are filtering keywords in HTTP requests. Thanks, Tony Tan98 · talk 03:15, 20 February 2015 (UTC)
They don't have to if they control DNS, firewalls and certificates. https and http are the same in that case. --DHeyward (talk) 04:33, 20 February 2015 (UTC)
They are not the same. Please see my reply in our other conversation closer to the top in this section. Thanks. Tony Tan98 · talk 04:52, 20 February 2015 (UTC)

Oppose Misconfigured or old proxies tend to interfere with HTTP websocket traffic they don’t understand, but those same proxies will just forward on the encrypted HTTPS traffic. And, what about all the extra load on the servers? The CPU load has been known to increase when we switch to SSL and now only a few people use SSL, imagine if everyone was to use it all of a sudden. --QEDKTC 08:26, 20 February 2015 (UTC)

HTTPS used to cause a lot of extra load on the server many years ago, but now technology (both software and hardware) has improved and the difference is negligible. According to Adam Langley, a Google Security Engineer, "SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead" when Gmail switched to HTTPS default. This website offers more information about TLS performance. If properly implemented with SPDY and HTTP/2, it may even be faster than plain old HTTP. Moreover, the WMF would be the final judge on whether something can be implemented anyways, right? Tony Tan98 · talk 14:11, 20 February 2015 (UTC)
Yes, you're right, thanks for pointing it out. Most CPUs now can handle 1500 handshakes/second/core or more. But, then, as it happened with StackExchange sites, switching to active/active load balancers (costs money) because sometimes SSL fails to utilise multiple physical cores. Encryption makes caching an load balancing much harder. This might result in a huge performance penalty. But connection setup is really a show stopper for most applications. On low bandwidth, high packet loss, high latency connections (mobile device in the countryside) the additional round trips required by TLS might render something slow into something unusable. And, as recently, uncovered some computers could have been hijacked already, as the recent Superfish incident has shown. Just another generic man-in-the middle attack, where the self-signed certificate allows the software to decrypt secure requests. I'm not citing this as a reason for oppose, just noting something that happened. And also, if people want to enable https when available, they have the HTTPS Everywhere extension. But in the end, it's WMF's call. --QEDKTC 15:49, 20 February 2015 (UTC)
  • Oppose this has made access for me difficult in the past in some countries and if we want to expand our users this is probably not the way to do it. --Tom (LT) (talk) 00:18, 21 February 2015 (UTC)
  • Agree after HTTP/2 is implemented and proven stable on English Wikipedia server for users in USA. • SbmeirowTalk • 04:51, 21 February 2015 (UTC)
  • Strongly Support Let me list some reasons here:
    1. When security is concerned, allowing both HTTP and HTTPS is not ideal. Since we use HTTP by default for anonymous visitors, if you use Google to search something, you will find that all Wikipedia links are HTTP. The problem is that even if you are a registered user, when you click a Wikipedia link on Google, your browser sends its first request in clear text, so your ISP, government, and any man-in-the-middle still know which articles you have viewed. Even worse, an active man-in-the-middle can modify the server's response so that you never receive the 301 redirect to HTTPS, and most people don't realize the difference. This is especially true for mobile browsers, some of which omit the protocol and lack a lock icon. This is why redirecting HTTP to HTTPS is not so secure. By enabling HTTPS by default for everyone ensures that search engines index HTTPS links.
    2. What we also should do is to enable HTTP Strict Transport Security (HSTS). When browsers receive this header, all future requests to Wikipedia are automatically sent over HTTPS, and users cannot ignore certificate errors. Ideally, we should include Wikipedia in Chrome's HSTS preload list (which is also used by IE, Firefox, and Safari), so that the user's first time visit is secured. But note that whenever Wikipedia is preloaded on the HSTS list, there will be no options for anyone to disable HTTPS on Wikipedia.
    3. Google promotes HTTPS. Websites that use HTTPS get a higher ranking. (HTTPS as a ranking signal)
    4. After we adopt HTTP/2, using HTTPS will be faster than HTTP and this will be especially true for users with high latency. Please have a look at My test showed that "SPDY is 56% faster than HTTP". (HTTP/2 is based on SPDY.) Although HTTP/2 standard supports plaintext, at least Firefox will never support plaintext HTTP/2.
    5. China no longer blocks https://*, but does block https://* and I would really appreciate it if Wikimedia Foundation can change the DNS record of to an IP address which is not blocked in China.
    6. Among Alexa Top 10, Google, Facebook, YouTube, Yahoo, and Twitter require HTTPS on their homepages. If they can require HTTPS, why couldn't we?
    7. W3C and Internet Architecture Board officially encourage websites to use HTTPS by default:

    The IAB urges protocol designers to design for confidential operation by default. We strongly encourage developers to include encryption in their implementations, and to make them encrypted by default. We similarly encourage network and service operators to deploy encryption where it is not yet deployed, and we urge firewall policy administrators to permit encrypted traffic. (IAB Statement on Internet Confidentiality)

    The Web platform should be designed to actively prefer secure communication — typically, by encouraging use of "https://" URLs instead of "http://" ones (although exceptions like "localhost" do exist). [emphasis in the original] (Securing the Web)

    Chmarkine (talk) 10:29, 21 February 2015 (UTC)
  • Oppose Make it opt-in instead, and redirect only when a cookie is found (set by clicking a banner promoting secure access). This is more conservative in my opinion. Zhaofeng Li [talk... contribs...] 11:13, 21 February 2015 (UTC)
    @Zhaofeng Li: But the problem is that MITM can remove the cookie if it is not secure. This does prevent passive MITM, but it doesn't work if an active MITM is present. Chmarkine (talk) 11:32, 21 February 2015 (UTC)
    If unfortunately the final consensus is to make HTTPS opt-in, I hope we implement it with HSTS (i.e. introducing Extension:HSTS, authored by User:Seb35). Chmarkine (talk) 11:42, 21 February 2015 (UTC)
    Browser usually provide some visual hints when the page is transmitted over a secure connection (a green padlock besides the address bar, for example), and users can easily notice if a crypto downgrade attack is being used against them. The HSTS idea looks good to me, but do note that users won't be able to turn it off easily in case they want the insecure version back. Zhaofeng Li [talk... contribs...] 11:52, 21 February 2015 (UTC)
    Yes. The indicator is actually obvious, but I worry many users just don't look at it. A research in 2006 concluded "participants who received no training in browser security features did not notice the extended validation indicator and did not outperform the control group." I hope users nowadays are more educated in web security, but I still believe websites should provide best security by default to most users. Chmarkine (talk) 12:11, 21 February 2015 (UTC)
  • Oppose Unfortunately, I'm not seeing how this proposal actually benefits Wikipedia's mission. Instead, the rational used to justify it is to get around ISPs'/countries' filters that block content they find objectionable. However, I don't believe that it is Wikipedia's place to find bypasses around these filters in the first place. —Farix (t | c) 15:12, 21 February 2015 (UTC)
That is not the only rationale of this proposal. Governments in most countries (including the USA) are now known to be monitoring internet traffic and putting them in large databases. This means that the articles that each reader reads are likely to be logged. Not only does HTTPS make large-scale snooping very difficult, it also prevents ISPs from monitoring what any given user has read or searched for on Wikipedia, protecting readers' privacy. This is one of the primary reasons that Google switched to HTTPS default for all searches. Tony Tan98 · talk 16:14, 21 February 2015 (UTC)
I don't believe switching to https will do anything to protect people from spying much less prevent them from being logged. Besides, this falls into the realm of WikiMedia Foundation's Privacy Policy and something that rest solely on the Foundation to decided. This is not something that should be up for discussion among Wikipedia editors. —Farix (t | c) 18:31, 21 February 2015 (UTC)
@TheFarix: As I stated above, the reasons for using HTTPS include: 1) preventing man-in-the-middle attacks, 2) improving performance (when HTTP/2 is used), 3) getting higher rankings on Google, 4) IAB and W3C encouraging using HTTPS. Using HTTPS on Wikipedia is just like using HTTPS on online banking websites, because "it has become apparent that nearly all activity on the Web can be considered sensitive, since it now plays such a central role in everyday life" (Securing the Web). Chmarkine (talk) 18:36, 21 February 2015 (UTC)
@TheFarix: It is a well established fact that HTTPS encryption protects people from spying and traffic logging. It is not a matter of opinion or belief. When a user visits a HTTPS secured website, the ISP can only see the domain name of the server, not the actual contents that the user is sending and receiving. In the case of Wikipedia, this means that the ISP will only know that the user is using Wikipedia, but it cannot tell what articles are being read and what terms are being searched for. The protection that HTTPS offers is described in detail in the articles HTTPS and Transport Layer Security, and elsewhere on the internet as well. I also recommend that you read the earlier questions, answers, and comments in this section about HTTPS.
I do agree that the WMF should make the final decision about whether to implement something like this. What this proposal is asking is whether the community thinks that the WMF should consider a change from the current HTTP-default mode. Thanks, Tony Tan98 · talk 19:34, 21 February 2015 (UTC)
Our purpose is to grant all of humanity access to the sum of human knowledge. If people are being prevented from viewing Wikipedia because of mass surveillance and censorship (regardless of source), then we have a problem that is interfering with our purpose. I honestly do not see the point of writing Wikipedia articles if the people who need the articles' information the most are being prevented from reading them, and feel that any proposal that gives more people access to Wikipedia's content is a good proposal. Spirit of Eagle (talk) 04:07, 25 February 2015 (UTC)
  • I've been supporting and advocating this move far a very long time now. There's no reason why internet traffic in general should not be encrypted (welcome to 2015, performance is not an issue anymore). And readers' privacy is only one part of the reason. The other is integrity of the data (website) delivered to the client (reader). Only an encrypted connection ensures that the data is not tampered with on it's way to the reader (as, for instance, here). --bender235 (talk) 21:59, 21 February 2015 (UTC)

Oppose, I'm sorry, I thought wikipedia was for the world and not just the first world countries? not everyone has fast internet speed, we may be in 2015 but internet wise, most countries are still in the 90's ..I ONLY edited on dial-up with my previous account (and not by choice) and because then Wikimedia didn't force people onto https, i was able to edit faster, https as mentioned above is pathetic in caching information, especially scripts which will make the wiki much slower for anyone with low internet speed, I'm on HSDPA and i can barely get a speed on 20kbps on the wiki. There is an OPTION to enable https on Preferences, I urge people who want "safety" to enable that and those that care for performance over security, like me would prefer to stay on, this is an ORGANIZATION, not some underground hacking/torrenting site that needs to be secured from the governments..This is WIKIPEDIA, not WIKILEAKS...All governments spy on people, that doesn't mean we live in fear all our lives..its not like we exchange private information or illegal stuff on Wikipedia that we need to "secure" ourselves from the government.......are we?--Stemoc 23:23, 21 February 2015 (UTC)

Browsers do cache content over HTTPS. The "2015" mention in bender235's comment was mostly referring to servers and their configurations, not the Internet connection. (You will see that if you click on his link.) Moreover, even though first-world governments are not as concerning, as you mentioned, Wikipedia is for the world, and there are governments in this world that restrict access to the web and filter content on Wikipedia. Not every government in the world is benevolent, and while it is not the primary objective, enabling HTTPS by default can certainly help protect readers and give them better access to information. Of course, like mentioned above, making it default does not mean there will be no way to opt-out. For your specific editing needs, you will still have the option of using HTTP by changing your account settings. Tony Tan98 · talk 00:05, 22 February 2015 (UTC)
@Stemoc: Totally understandable. But the good news is that only after a few months, you do not have to make the choice between security and performance. With HTTP/2 over TLS, you can enjoy both high speed and security. HTTP/2 over TLS is even faster than HTTP in most cases, in terms of load time and bandwidth. ([32][33] [34]) Since some browsers refuse to implement plaintext HTTP/2, we have to enable TLS in order to use HTTP/2. Chmarkine (talk) 01:54, 22 February 2015 (UTC)
High speed and security? I tried https a while back, net speed rarely went past 10kbps (thats as worse as dial-up) ..i don't care for security, our government does not care what people post on wikipedia and it definitely does not cache scripts well, reloading the same scripts over and over again everytime you try to make a simple edit or refresh the page is tiring, especially if they take a while to load...btw, anyone that wants to look up information on wikipedia even on countries where its restricted will always find a way to do so (proxies etc), we do not make it hard for everyone else because just a handful are missing out and as mentioned above, I prefer an opt-in option to an opt-out one..I'm just tired of WMF making stupid decision and then enforcing them and regarding the opt-out option, thats absurd Tony, HTTPS should be an OPT-IN option, not an OPT-OUT option and definitely NOT the ONLY OPTION.--Stemoc 02:27, 22 February 2015 (UTC)
Please check out this image, you can definitely forget the idea that everybody living in some kind of "first" world area can afford Internet connections that do not suck. Just in case adding an oppose, because I forgot that near the begin of this thread. € 0,02 by Be..anyone (talk) 02:38, 22 February 2015 (UTC)
@Stemoc: I never say https is fast today. I mean https will be faster than http after we adopt http/2, which will be available later this year. I know you don't care about security, but http/2 is faster than http. Why do you still hate it? Chmarkine (talk) 03:03, 22 February 2015 (UTC)
@Stemoc: Are you able to use Google search through your slow internet connection? Tony Tan98 · talk 03:14, 22 February 2015 (UTC)
Ofcourse i can use Google search, the shitty speed is only limited to wikimedia wikis which gets even worse on https, my net is slow but bearable but then i'm on Wikimedia more than I google so i do not see the reasoning (even then it takes forever to do google "image" search) per Be---anyone, it seems that slow connection is a problem in first world countries too so I really don't see a reason to "force" https on everyone..I think people who are supporting this idea are definitely NOT on slow connection or else they would understand how hard it is to browse, let alone edit wikipedia--Stemoc 04:40, 22 February 2015 (UTC)
Google uses HTTPS by default. You said that you are able to use Google search (over HTTPS) normally on your slow internet connection. Thus, HTTPS is not the issue that is slowing down your access to Wikipedia. Moreover, editors with accounts will have the option to disable HTTPS if they wish to do so. Also, I spend half of my time in China, and I know what it feels like to use a slow internet connection. Tony Tan98 · talk 05:06, 22 February 2015 (UTC)
when did i say it did?, I said it makes it worse as and also i generally use Google DNS so google will run faster either i like it or not and also there is a stupid bug on wikimedia created by csteipp which no one wants to fix which automatically FORCES users into https if they edit any page by mistake on https, the only way to get out of it is to clear all your cookies from *wikimedia/*wikibooks/*wiktionary and the 4 other domains and clear all centralauth cookies and log in and they go to all wikis and try logging in... I'm a file mover on commons which means if i fix a file name, my account automatically goes to all the wikis the image is on to replace the file but if i get logged out of a wiki because of this bug, it ignore that wiki which means the file remains unchanged..first they added the "forceHTTPS" cookie without asking for user opinions and now this....I'm part of the SWMT which means on some days i edit over 20 wikis and sometimes more, this flaw is not helping...https may be ok for those who edit only ONE wiki like most of those here, but its a PITA for users like can't revert vandalism on a smaller wikis if you have to wait 30-45 seconds for all the effing scripts (js/css) to load...--Stemoc 06:58, 22 February 2015 (UTC)
  • Support - I totally agree. In the pre Snowden era, this probably would have been opposed as unnecessary and/or burdensome, although it's now absolutely necessary (per Google, Snowden, and many others) and it's barely burdensome, if at all. Yes there is censorship. But the chilling effect of surveillance has a negative impact on our mission. There are many places in the world in which asking questions about religion, sexuality, women’s rights, abuse, among others, or editing forbidden Wiki articles, can result in actions taken against them by their families, community, employers, or the state (judicial and extra-judicial). Wikipedia is an invaluable resource for information, but not for those that are afraid to access it because big brother or others are looking over their shoulder. - Becksguy (talk) 04:01, 22 February 2015 (UTC)
  • Oppose for viewing, Support for logging in and editing. Restricting HTTP access to Wikipedia's public content doesn't provide any real security gain, and it makes caching harder. It's also likely to break some older devices, such as the Kindle with free Wikipedia access. However, editing actions and logging in should be secured. John Nagle (talk) 07:55, 22 February 2015 (UTC)
  • Comment Shall we move the discussion to meta, since this is a Wikimedia-wide issue affecting all communities? Zhaofeng Li [talk... contribs...] 01:11, 24 February 2015 (UTC)
Doesn't really matter as one of the devs mentioned on IRC a few days ago that we will be moving to https (either we like it or not) ..--Stemoc 01:26, 24 February 2015 (UTC)
  • Support Everyone should be able to read Wikipedia articles without having to fear government surveillance or censorship. If people who need Wikipedia's information are prevented from getting it because of mass surveillance or censorship, then our purpose of granting people access to the sum of human knowledge is under attack and needs to be protected. Even if this RFC does not pass, I think that we should do a better job of informing readers about HTTPS, and make it easier to switch in. Spirit of Eagle (talk) 01:44, 24 February 2015 (UTC)
  • Strongly support per Becksguy, at all times. In addition, with attacks that rely on starting with an unencrypted channel, there's more and more reason to start off encrypted to begin with. I question concerns of users who are talking about bandwidth use, as well; I'd like to see some actual numbers showing TLS overhead versus average article sizes before I'd give those comments any credence. // coldacid (talk|contrib) 03:35, 25 February 2015 (UTC)
    Chmarkine explains it even better, above. Even HSTS can be defeated by a man in the middle if you start with unencrypted communication. Default to HTTPS, the sooner the better. // coldacid (talk|contrib) 03:39, 25 February 2015 (UTC)
  • Perspective Please don't pretend this is for site security. If we cared about site security, we'd have a password policy. I'm also kind of baffled by this hypothetical use case of someone who has to fear people eavesdropping their Wikipedia reading habits, but is ignorant of the use of HTTPS. Where does this end? Remove public editing histories? A one-way hash for editor names? The whole concept of a Wiki is open and public. Not secure and secret. Gigs (talk) 16:57, 25 February 2015 (UTC)
No straw men please - you know very well that those things aren't going to happen. For one thing it would violate the license terms, and editors can be pseudonymous anyway if they choose. You're right that this wiki is public, but that only covers overt participation, not reading, where people would have a legitimate expectation of privacy.
Also, I don't think (generally) people are saying this move is for site security, it's for the readers' security. BethNaught (talk) 17:07, 25 February 2015 (UTC)
Please actually read the above proposal, Gigs. It is (mainly) not intended for site security, but for the security & privacy of readers. No one is proposing to make this wiki secretive; it is and always will be open and public. I genuinely hope that you were actually confused and not trying to make a straw man argument. Tony Tan98 · talk 17:45, 25 February 2015 (UTC)
This is also another reason to either block editing via Tor or at least include a big "you are not as anonymous as you think" message on the edit pages served to Tor exits: an attacker able to observe your network traffic can trivially correlate bursts of activity with Wikipedia's public edit histories. Edits look different from reading: reading a page is a large response to a small request, while editing is a large response to a large request. If we really want to take the paranoid approach, we should modify the software to include random bits of other articles (as comments) in every page sent over HTTPS. Currently, an attacker might be able to guess what articles are being read by looking at the sizes of the responses from the servers. Pathore (talk) 22:45, 25 February 2015 (UTC)
@Pathore: While what you are saying (traffic analysis) is certainly theoretically possible, it is currently not an easy task for even a government to use for mass snooping. It is not "trivial." Moreover, Wikipedia does not allow edits from Tor unless the user logs in and has IP block exemption.
The main purpose of this proposal is to prevent mass snooping (and censorship) of readers by upgrading to the HTTPS protocol by default, which is what many other websites such as Google have started to do years ago. As a side benefit, HTTPS also ensures the integrity of data being transferred, so that a user can be certain that the page from Wikipedia has not been tampered with (censored or inserted with ads) while in transit.
We are not trying to take the "paranoid approach" and there is currently no need to "include random bits of other articles." Given the sheer number of articles we have and the current state of technology, it should be very difficult (currently) for someone to use traffic analysis to correlate encrypted traffic to specific articles that are being read. However, because it is trivially easy to sniff unencrypted traffic using tools such as Wireshark, I strong believe that we should enable HTTPS encryption by default for all readers. Since you have not yet stated it, may I ask for your opinion on this proposal? Tony Tan98 · talk 01:49, 26 February 2015 (UTC)
Correlating public edit histories to network activity is trivial, especially over a longer period of time, and identifies the network location behind an account, fingering an editor.
Identifying pages based on their size is neither trivial nor particularly accurate, but should be a concern if we are really worried about our readers' privacy, given the poor standards of "evidence" associated with mass snooping fishing expeditions. Exactly how accurate such an attack would be depends on the distribution of page sizes given links. (A snoop can guess that users tend to follow links from the page that they are reading; this means that if pages A and B are the same size, but A links to C and B links to D, which are different sizes, a snoop could guess that a user was more likely on A or B, based on a subsequent request that appears to be either C or D. This game of Guess Who? scales, although I don't know exactly how well.)
If I understand correctly, HTTP/2 allows the server to send the client extra resources that have not (yet) been requested. We could use this to return a number of random extra articles (that the client will cache) with each request, further enhancing reader privacy. Even looking at someone's cache wouldn't tell you what articles they were reading, since the server stuffed extras in there at every opportunity. Exactly how to choose those extra items is a good question.
I'm currently unsure of my position on this proposal. On one hand, Jimbo has promised to push Wikipedia towards HTTPS in response to privacy-violating politicians and I don't want to take whatever leverage Jimbo may have for human rights away by pushing that change regardless. On the other hand, the article you cite is from almost three years ago; perhaps the situation has changed and it is now necessary for the community to stand behind making good on its founder's promise. Has this come to pass? Do we need to stand behind Jimbo making good on his promise? Pathore (talk) 03:06, 26 February 2015 (UTC)

Request for Comment

There is a request for comment at Wikipedia_talk:Autopatrolled#Request_for_Comment:_Including_AFC_acceptance, asking for opinions and comments on whether the bar should be shifted for granting the autopatrolled user right. Please make all comments, questions or ideas there.- McMatter (talk)/(contrib) 20:41, 16 February 2015 (UTC)

Suggested improvement for accessibility by editors

I am a relatively new editor and have found the WP 'back of house' to be particularly non-user friendly. I know that I have jumped in at the deep-end, taking on a rather daunting task rather than easing in more progressively and that this has accentuated some of the difficulties I have experienced. I think; however, that my experiences serve to highlight some problematic areas.

I had thought to raise this in a project area but these appear to be inactive so, here goes. I think there are three things that could be done relatively simply that would make all of the 'back of house' content much more accessible for all editors, but particularly new editors.

  1. Create a servants entrance. By this, I mean, a 'back of house' home page accessible from every page, possibly just for logged in users but that is a policy decision. It could either be across the top, where the log in/log out and associated options are or it could be with the options on the left of screen under the Wiki globe. These are just suggestions.
  2. A back of house search box. This would be similar to the MOS specific search box but would cover all of the 'back of house'. This could be located on the log in/log out line at the top of page and be active/visible when logged in. A back of house search box could be confusing if generally seen.
  3. Create a more intuitive way to identify and access material from the 'back of house'. In practice, this is likely to be incorporated into the 'servant's entrance'. Books have (at least) two main ways available for tabulating the information within: a table of contents and an index. The former would be like an hierarchical guide - basically lists of policies, guidelines, essay, templates etc in alphabetical order. The latter would provide functional or conceptual groupings such as all articles about referencing, arranged around key words or concepts and sub-groupings. Furthermore, it may/should be possible to annotate entries to provide context and improve accessibility even more.

My ideas are not contingent on restricting access to only logged in users. I have very little idea about how to approach the actual nuts-and-bolts of such a 'project' but I perceive that a lot of the functionality is readily adaptable from what exists. Cinderella157 (talk) 10:13, 17 February 2015 (UTC)

@Redrose64, to clarify my restaurant metaphor of 'back of house', I mean all of the documents and pages that aren't in what others have called, the main space, article space or the encyclopedic area. I would include in the back of house things like: policy, guidelines, essays, template user guides, tutorials etc. Cinderella157 (talk) 23:34, 17 February 2015 (UTC)
Well, the first thing I'm seeing investigating this post is that our project space has no contents page. WP:HOME leads to an inactive Wikiproject, WP:Portal is about portals, WP:Main is about the main page and WP:Content redirects to a portal. Even if we did agree to add the link Cinderella suggests, we have no page to link to. I think the best place to link to for such an idea is Wikipedia:Five pillars, which has a lot of links to our key policy and guideline pages. Oiyarbepsy (talk) 21:20, 17 February 2015 (UTC)
My proposal is in 3 parts with the suggestion that servants'entrance or user home be a portal from which users can more easily navigate around WPs back of house. It can also have otherthings too but I would see this as its primary function. Cinderella157 (talk) 23:34, 17 February 2015 (UTC)
Are you aware of the Category:Wikipedia directories and its contents, like Wikipedia:List of policies and Wikipedia:Glossary? Similarly, Special:SpecialPages shows many special pages and Special:AllMessages shows all of the Wikipedia interface messages. – Philosopher Let us reason together. 21:46, 17 February 2015 (UTC)
Thanks, I was aware of one of these pages. My proposal is about how one becomes aware of these pages. Furthermore, my proposal is about being more inclusive (all of the back of house) than what any of these individual pages are. Cinderella157 (talk) 00:23, 18 February 2015 (UTC)
  • I could see creating a portal to do this, and i think if anyone wanted to they could just create it. Beeblebrox (talk) 23:30, 17 February 2015 (UTC)
Not certain if you mean by that , that no special permission is needed or if you mean that anybody has the capacity to undertake the task? Part of the reason for addressing this here is the limitation of my own capacity to perform the task (the know-how). Also, for it to be effective, the door would need to be somewhere visible (as I have discussed/suggested). I perceived that placing the door would probably require some sort of permission or special access. Cinderella157 (talk) 00:41, 18 February 2015 (UTC)
I think what Cinderella157 is saying is that we should have an (optional) secondary Main Page for editors where the most commonly used special pages are organized into categories. It should have links to the Village Pump, the Policies, the Noticeboards, and Project Pages, so that all are within easy reach of a new editor. The reason Cinderella is asking for someone with permissions is that such a page should be created by an experienced user, and once created, it should be easily accessible to all logged-in users, such as through a link on top next to the "log out" link. Tony Tan98 · talk 02:18, 18 February 2015 (UTC)
This is pretty close - especially the second bit: "The reason I am asking ...". Yes, "an (optional) secondary Main Page". It is designed for all editors but would be particularly helpful for new editors. I am thinking of some 'quick links' but I am also thinking of something encompassing all of the wiki pages (not in the article space). I am visualising both a table of contents, based on a hierarchy of page types, and an index, which is conceptual and may include pages (as links) appearing multiple times because they relate to multiple 'concepts'. The indexing would use multiple levels to hone in on specific concepts within broader concepts. I would envisage this possibly working off info boxes that can be expanded. This would then make it possible to see the 'full' range of available information (pages) without actually leaving the page. I would describe this a being more 'visual'. Links have their uses and their limitations. You need take a guess on which is is the best and then you might follow multiple links (crumbs) before you realise it it is a dead-end trail and you have to backtrack. By seeing a fuller range of options, you increase the likelihood of finding the correct path more quickly or even getting to the correct page more directly because of the multi-level index structure. Cinderella157 (talk) 03:58, 18 February 2015 (UTC)

For everyone saying we need a 'Portal'... We already have one, it's even linked from the sidebar. We could probably take better care of it though :) —TheDJ (talkcontribs) 10:16, 18 February 2015 (UTC)

OK, so we have the portal and it does do some of those things. You had to drill down one level before you started getting 'how to' info and flit off the page. There is something like an index but not a table of contents that I could see. There is also the search feature I raised. Cinderella157 (talk) 21:58, 18 February 2015 (UTC)
It is possible to search the other namespaces if you go to the actual search page (and not the quick search bar), but you raise a valid point that all of this "under the hood" stuff is somewhat hidden from regular view. In a way this is intentional, we have generally had a de facto policy of keeping admin stuff somewhat separate from the general reader's experience (i.e. links from articles to project pages are discouraged and only used infrequently). Gigs (talk) 17:02, 25 February 2015 (UTC)

Transclusion of to-do lists on WikiProject tags

There is a proposal at Wikipedia talk:WikiProject Council#Proposal: Disallow transcluded to-do lists. Please comment there. PrimeHunter (talk) 23:51, 18 February 2015 (UTC)

Last chance for a while

From what I've seen in past years, right now is probably the last chance for a while that we might be able to pass some proposal that will lead to some eventual reduction of the growing admin-work backlogs. We've had three or four recent votes that people probably won't be willing to repeat anytime soon (see here and following, here, here, and maybe here). I'd like to hear evidence either way about what admin-related work is or isn't getting done these days, particularly the work that concerns bad actors (spammers, vandals, socks, etc.), and any proposals anyone wants to make on how to tackle the problem. I'll consider adding any promising proposals to WP:CENT but not to the RfC list, for now, because I don't think it would be smart to string this out 30 days. For recent discussion on the backlogs, see the backlogs mentioned by Risker, here, and search for "backlog" in most of the recent WP:AN archives, for instance here, here, here and here. For an explanation of why it's happening, this chart from the discussion in November (one of the links above) may be helpful:

2008 2009 2010 2011 2012 2013 2014 (projected)
Active admins 943 870 766 744 674 633 570
Admin promotions 201 121 78 52 28 34 21
Admin attrition (actual, not net) 263 194 182 74 98 75 85
- Dank (push to talk) 23:59, 18 February 2015 (UTC)
P.S. The first line of the chart measures the number of admins remaining who had made something like 30 edits or more over the previous two months. The second line is the total gained that year through RfA, and the third line is the total lost that year. 2014 figures were estimates. - Dank (push to talk) 01:52, 19 February 2015 (UTC)
  • I haven't payed too much attention to the whole RfA thing, but my impression is that it has become much harder to get admin tools now than in the past. If I put in a RfA now, my request would probably be summarily rejected. However, if I did so a few years ago, I wouldn't have had a problem. That was because admin tools were only denied to editors who didn't have enough experience on Wikipedia, lacked an understanding of Wikipedia's core policies, or had a history of behavior problems. Unless an editor has demonstrated that they cannot be trusted with the admin tools, becoming an admin should be a forgone conclusion, much like access to tools like AWB, rollback, or reviewer privileges. —Farix (t | c) 13:27, 19 February 2015 (UTC)
    • Totally agree. My impression is that RfA is now about how many FAs you've shepherded. What that has to do with fighting vandalism and implementing the consensus of AfD's has never been satisfactorily explained. --Trovatore (talk) 21:31, 19 February 2015 (UTC)
      • I was just looking at the two current RfAs, almost every question has nothing to do with trust and are irrelevant for something that should be "no big deal". The whole process is arcane and full of drama, which does nothing but turn people off from even going through the process. Simply eliminate the meaningless question/answer ordeal, allow a short time for other editors to review the nominee, then automatically promote the nominee unless the review presents reasons that the nominee cannot be trusted with the admin tools. —Farix (t | c) 22:33, 19 February 2015 (UTC)
  • In my opinion, there's only one way to fix this problem: make it easier to become an admin. Why is it that the community has all these unreasonable expectations? For the record, here are some notorious examples:
    • Deletion: Often, voters will oppose a candidate based on the fact that they have just a few blue links in their log, or that the article wasn't deleted under the criteria that it was CSDd under. Or, with AfD, the two most common complaints is that the candidate hasn't voted in some arbitrary number of AfDs, or that too many of their votes didn't match with the final result. As much as I wish I could be perfect, I'm not, and neither is anyone else. So, people will make mistakes in CSD. Not to mention the fact that an article sometimes can be reasonably deleted under more than one criteria. For instance, a NPPer might see an article about a company as falling under A7, while the deleting admin deletes it as G11. However, if the article is promotional and doesn't explain the subject's notability at the same time, both the NPPer and the admin were right. However, some voters, in what sometimes seems like a desperation to find any reason to oppose someone, will use that as a reason to oppose without even knowing the full context behind it. Or, in AfD, how does an individual's votes and/or lack of meeting an arbitrary level of participation interfere with their ability to properly judge consensus? What's even more ridiculous is that some will oppose for lack of contribution in an area, in this case AfD, even when the candidate has little to no interest in participating in AfD!
    • Content. This has to be one of the most controversial (and common) oppose reasons. Some voters have high content expectation, expecting the candidate to have created at least one, two, or more GAs, and sometimes even an FA. While I do think that some content experience is beneficial, it still has no direct relation to the groundskeeping work that admins usually do. (For example, will we forbid a person from becoming a groundskeeper unless they've grown prize-winning grass?) Even more ironically, when a prolific content creator takes a stab at RfA, some will oppose on the basis that the person has done too much content work and needs to do more maintenance things!
  • So, the conclusion? To pass an RfA, it's pretty safe to say that if you want a chance of passing, you had better be very well-rounded, never or hardly ever made a mistake, and and never have made a controversial comment or two. Its really time for us to go back to the WP:NOBIGDEAL philosophy. Sometimes, I'm tempted to support candidates who would have easily passed a few years ago but now fail under NOTNOW just to show that its not a big deal... --Biblioworm 00:54, 20 February 2015 (UTC)
  • I actually think that RFA, while no doubt irksome, is actually easier to pass than a few years back. About the historical proportions of nominations succeed in fact. The real problem is that so few nominations are made, presumably because willing candidates are lacking. There were 408 promotions in 2007 with 512 failing, so 920 in all; only 22 promotions in in 2014, but there were only 40 unsuccessful nominations (ok, more than I expected) so only 62 noms all year, about a month's worth in the old days. In 2013 34 succeeded, 40 not - 74 in total. Johnbod (talk) 04:57, 22 February 2015 (UTC)
  • The other problem is many of the successful RfAs yield inactive admins. If you created a bunch of a GAs/FAs you've got great chances for passing an RfA, but that doesn't mean you'll be willing to help with the backlogs. Meanwhile we have users like Solarra that would have been backlog-clearing machines (there's other good reasons to oppose that RfA, but she like any other admin would do most learning on the job). If you ask me, if we really want to get more admins, I think it's up to the 'crats to become more lenient – looking for qualities in areas that admins actually use their tools, and try to lessen the weight of opposition based on lack of experience in not-so-adminy areas. MusikAnimal talk 03:41, 23 February 2015 (UTC)
  • I suggest an admin apprenticeship/mentoring system, along with a lower bar for entry and a probationary period. ―Mandruss  03:49, 23 February 2015 (UTC)
  • Suggesting changes to RfA thing's for sure, if you manage to push through something they'll give you a goddamned medal, well-deserved. ResMar 16:54, 23 February 2015 (UTC)

Somaly Mam, character assasination of an anti-sex slavery advocate

Wikipedia:Village pump (proposals) is for the discussion of proposals to Wikipedia's policies and guidelines. It is not a place to discuss article content or disputes with other editors. —Farix (t | c) 14:44, 19 February 2015 (UTC)
Please continue discussion at Wikipedia:Biographies of living persons/Noticeboard/Archive217#Somaly Mam Oiyarbepsy (talk) 15:33, 19 February 2015 (UTC)

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

Somaly Mam is a former child prostitute from Cambodia. Until 2013 she was heralded internationally as a heroine and advocate, saving thousands of children. Then there was a Newsweek article The Holy Saint (and Sinner) of Sex Trafficking claiming to find holes in her original story [35]. For a normal politician such articles are part of the cut and thrust, but Somaly Mam quietly resigned from all her positions, she said to protect the organisation she founded from ongoing attention. Marie Claire magazine published a piece Somaly Mam's Story: "I didn't lie" , strongly challenging the evidence provided by Newsweek. [36]. The US State Department reports, sex trafficking and underage prostitution is rife across Cambodia. Believe what you like about the details, it is highly unlikely that Somaly Mam's original story is a total and/or proven fabrication.

Nevertheless, the wikipedia article on Somaly Mam is strongly biased against Somaly Mam. It's conclusions are far more definitive and condemning than Newsweek, saying "sex trafficking and abuse claims were disproved" and "she pretended to be a nurse". It provides details of a internal report which sofar has not been publicly disclosed. Her success in advocacy is underplayed. Each section of this article is entirely biased against Somaly Mam. Marie Claire is mentioned, but not the independent investigation that alleged Newsweek undertook poor journalistic practices and false claims.

Although it is possible that editors are following Newsweek's lead, is there is a chance that sex tourists who visit Cambodia go on to edit this page? Yes, we deal with biases and lobbying everyday, but pedophilia is not just an opinion. It's not about one person's reputation. Pedophilia networks use the internet to lure children and hide their tracks. Wikipedia cannot be used as part of this. Not only should the article be cleaned up, we should follow the edits of those who put the page in this state. There may be other damage being done. How can we afford to not check this out? (talk) 08:12, 19 February 2015 (UTC)

The above comments were removed by Mlperarc with the incorrect justification that these are not good faith edits. No changes have been made to any article, so the removal has nothing to do with good faith editing. It reflect very poorly on Wikipedia if this issue was to be prevented from being discussed on its talk pages. (talk) 11:33, 19 February 2015 (UTC)
The above comment was again removed. This time it was by GB_fan. The reason to delete this comment was that it was not about policies or procedures. Yet, the comment above clearly states Wikipedia should not be used to assist pedophilia networks. While the risk is small, it should be considered. But now, twice this comment has been deleted. These two editors have not simply made a comment, but actually took steps to prevent the issue from being discussed! Now there are two policy problems to consider. I'm surprised, but if editors think they can just "wish this away" or real off technicalities, then consider that this only generates suspicion. (talk) 12:49, 19 February 2015 (UTC)
This comment was removed for a third time. This time is was by De728631. This is the most unusual edit-war on a Talk page one can imagine, but fortunately a record is kept of it. I should retain the hatting reason which is This page is to discuss proposals to change Wikipedia policies and procedures. It is not the place to discuss an individual article. You should raise your concerns on the article's talk page, Talk:Somaly Mam. -- GB fan 11:47, 19 February 2015 (UTC)}}. Nevertheless, in the above comment, nobody has been accused of anything, nobody has been insulted, and the issue is a global concern. Yet three editors have not merely commented, but actually prevented this item from being discussed. (talk) 13:27, 19 February 2015 (UTC)
You really should accuse the right person, User:GB did absolutely nothing to this discussion. I, User:GB fan, hatted the discussion, not deleted or removed it. This is the wrong place to discuss an individual article and your concerns about it. The proper place to discuss it is on the article's talk page. Since you are concerned about problems because she is a living person, another place to discuss it is on the biographies of living persons noticeboard. -- GB fan 13:41, 19 February 2015 (UTC)
OK, GB was a honest typo. The advice about biographies of living persons is good. The reason I chose this space to make comment, is because I'm asking whether sex tourists or pedophiles can take advantage of Wikipedia, as per my third paragraph. I'm not against Mam being criticized proportionately, but whether it is really is a warning to children or women they won't be believed, or showing they will be attacked. This must be one of the risks of an open system. (talk) 14:02, 19 February 2015 (UTC)
Since this is a page to discuss proposals, what are you proposing? Also in regards to your comment about edit warring, you do realize there is only one person who is edit warring here, YOU. Three people have tried to explain this is not the proper place to discuss this and you are edit warring to keep the discussion here. -- GB fan 14:16, 19 February 2015 (UTC)
Sex-trafficking is an issue that depends on silencing and bullying. It depends on children and young people not being believed. Obviously just from this comment, the first proposal would be to have a policy of against silence. Sex-slavery is a more important issue than fitting into Wikipedia's general procedures. If we agree that child sex slavery is wrong, then articles about victims of sex slavery (and Mam was rescued as a minor according to one NGO) may need special oversight. I am drawing attention to the broader issue here. What about victims of other types of abuse? Time is on my side, and I have not checked every related article yet. All that's being asking for is some comments from people with experience using Wikipedia. (talk) 14:51, 19 February 2015 (UTC)
This discussion is not at all closed, and you can discuss it. This action is highly controversial. (talk) 14:53, 19 February 2015 (UTC)
Wikipedia:Village pump (proposals) is not a venue to discuss "important issues". It is a venue to discuss new proposals or changes to Wikipedia's policies and guidelines. This discussion you want is about neither. Now knock it off before an admin blocks you for disruptive behavior. —Farix (t | c) 15:00, 19 February 2015 (UTC)

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

Editnotice for new users editing their user page

A very, very common issue on enwiki is that new users use their userpage to draft articles. No matter what the nature of the article, it won't take much before someone comes along and tags it as WP:U5 or WP:G11, when it would be considered perfectly acceptable in a sandbox or in the draftspace. You also have Special:AbuseFilter/466 and Special:AbuseFilter/499 that bear many false positives because of this issue. Furthermore, userpages are indexed by search engines. This means if the author abandons the draft, you'll still have other new users coming to edit it years later, thinking it's an actual article. So, I'm proposing we use an editnotice to show a friendly message telling new users what a user page is for and where articles should normally be drafted. We can utilize parser functions to ensure the notice is only shown for new users editing their own user page. It is my understanding that we should not worry about performance. Thoughts? MusikAnimal talk 17:45, 20 February 2015 (UTC)

I think if it can be properly implemented, it is a good idea. Many new users do indeed get confused about how WP works, and an editnotice like this definitely helps alleviate that problem. Tony Tan98 · talk 20:14, 20 February 2015 (UTC)
This is, I think, a good idea. AN Edit notice certainly tells editors what kind of page they're editing and what precautions or advisories should be taken into consideration when editing a page. (talk) 20:35, 20 February 2015 (UTC)
This is a good idea. Once this is done, we also need this on WikiCommons, where lots of articles are created on the Gallery-space, in addition to the Userpages. Rehman 11:13, 21 February 2015 (UTC)
I do not thinks there is a parser function that can get the date when the account was registered. Ruslik_Zero 20:16, 21 February 2015 (UTC)
@Ruslik0: I belive you are right. We could still use some magic words to determine if they are creating the page, as opposed to just editing it, and show the notice then. Hopefully that will still be somewhat effective, and shouldn't bother the more experienced users. MusikAnimal talk 18:19, 22 February 2015 (UTC)
{{PAGEID}} returns a blank string on a page that does not exist and a number for a page that does exist. I think that might allow us display a message only if the page does not exist. Chillum 18:26, 22 February 2015 (UTC)

I have created User:MusikAnimal/userpagenotice which is a draft of what I think the editnotice should say. Please feel free to edit it. The idea here is to keep it as brief as possible and avoid all the complicated policy stuff. The boldened "userspace draft" link is the one we want them to click on. I was considering even including the "create userspace draft" form in the editnotice, like the one seen at Help:Userspace draft. However I believe if they type anything in the userpage edit box, then try to create a userspace draft using the form and submit it, their browser will prompt them about leaving the page with unsaved changes. That might lead the to hit save, which is probably not what they want to do. So maybe the form is best left out.

Thanks to all of you for your input and help! MusikAnimal talk 03:00, 23 February 2015 (UTC)

I've tweaked the wording slightly and changed the appearance; it now uses {{ombox}}. I think that the "Please create a userspace draft" message stands out better now. Pathore (talk) 08:32, 23 February 2015 (UTC)

@MusikAnimal: I think I had that same problem about the browser prompting me about unsaved changes even though I think I already saved them. I think that should be taken into consideration. (talk) 20:09, 23 February 2015 (UTC)

Just as an update, I have been trying to make this work on testwiki with no luck as of yet. The {{currentuser}} template here on wiki just uses the magic word {{REVISIONUSER}} which only works when substituted, and in the case of the editnotice it just returns a blank string. Does anyone know of a way to reliable grab the current user's username? MusikAnimal talk 05:29, 26 February 2015 (UTC) Pinging Chillum, Ruslik0 MusikAnimal talk 05:32, 26 February 2015 (UTC)

I don't believe it is possible to get the current user's name in an editnotice. As Chillum mentions, one could detect whether or not a page is being newly created, but I think that is the limit of the current tools. Dragons flight (talk) 06:36, 26 February 2015 (UTC)
Well rats. This issue is ongoing, and a real problem. Everyday we have G11/U5'd pages showing up, most of the time created in good-faith. Is there anything you can think of Dragons flight? An edit filter doesn't seem like a good idea, as we could only show that after they attempt to edit, not beforehand. I guess we could use JavaScript, which after rigorous testing we could enable by default for enwiki. MusikAnimal talk 16:10, 26 February 2015 (UTC)
Installing mw:Extension:MyVariables would introduce a new magic word that shows the current user's name, if anyone's interested in that. I've seen it on other wikis and it seems to work pretty well; the javascript version is slower to load. ekips39 (talk) 17:12, 26 February 2015 (UTC)
I wish. I'm not going to count on anything that requires WMF involvement. I think the JS solution might be okay... I can make a tiny script that will check if editing your own userpage, then pull in the markup for the edit notice via AJAX from a different file and insert it in the DOM. Because most of the time we aren't editing our own userpage so we don't need to download the entire script and associated markup. The AJAX call should be very quick as it won't be much content. These users spend a good moment editing their user page anyway, at least plenty of time for the JS to do it's thing. MusikAnimal talk 17:29, 26 February 2015 (UTC)
Why do we need the username at all? After my edit, the message has two {{ombox}}es, one explaining the purpose of user pages and one suggesting the creation of a userspace draft. I propose that the top box be always visible and the second only appear when creating a user page -- any user page. Pathore (talk) 22:24, 26 February 2015 (UTC)
Maybe, the issue is they will see the notice when creating their main userpage, then click the link to create a userspace draft, and see the same notice. We can make the proposed script even smaller by having it work off of the global edit notice, showing it only when needed. Now we're talking a small, maybe 3 or 4 line script that would allow me to even restrict it to new users. MusikAnimal talk 03:05, 27 February 2015 (UTC)
Why not display the message only if {{PAGENAME}} and {{SUBPAGENAME}} match, as they will on top-level pages only? Something like: {{#ifeq:{{PAGENAME}}|{{SUBPAGENAME}}|{{User:MusikAnimal/userpagenotice}}}} except of course transcluding a message from mainspace. Pathore (talk) 04:34, 27 February 2015 (UTC)
I've added the appropriate markup to the draft message. Pathore (talk) 04:44, 27 February 2015 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────Thank you! I've added the PAGEID check to ensure it only shows when creating the page. I've tested this on testwiki with testwiki:Template:Userpagenotice and testwiki:MediaWiki:Editnotice-2 and it appears to work. Try creating/editing user pages there. I'm happy with this approach if everyone else is.

I've only one last concern – if the user follows the links to create their userspace draft, which is in fact what we want, it will add {{userspace draft}} to the top with a button to submit the article for review. This in theory is good, but AfC is perpetually backlogged (though surprisingly low right now!), and we may end up with a surge of new submissions from users thinking they're actually publishing it to the mainspace – or simply don't know that it may take weeks before their article gets looked at. So, I was wondering if we should include a link to move the page as well, like User:MusikAnimal/Userspace draft move. The link would bring you to Special:MovePage with the fields filled in. Thoughts on that? Again feel free to edit User:MusikAnimal/Userspace draft move, I actually couldn't get the "move" link to work. MusikAnimal talk 06:03, 27 February 2015 (UTC)

The "move page" link works now (when the template is transcluded--it's intentionally broken when viewed directly) which leaves the question of how the "userspace draft move" template gets onto the page. I've also made the slight tweak to the userpage notice that I suggested earlier: The top box will always appear, while the suggestion for a userspace draft only appears if the page doesn't exist. Pathore (talk) 01:44, 28 February 2015 (UTC)

Splitting up the MfD

It has often occurred to me that discussing the deletion of project pages requires to be a more intensive process than discussing user pages. The large number of pages being listed at the MfD are user pages, as a result of which project pages get lost in the mix and don't get adequate attention. Also, while proposing the deletion of abandoned user pages and stale drafts can be a simple process which are closed without too much of discussion, the same is not true for pages in the Wikipedia:, Help: and certain other namespaces. Deleting, or acting upon these pages in other ways, should ideally require community-wide consensus. As of now, there is no centralised place discussing the scope of project pages; any such discussion is carried out on their talk pages which obviously are not watched by many users. In this light, I propose splitting up the MfD into multiple components.

  • Project pages for discussion: This should include pages in the Wikipedia:, Help:, MediaWiki:, and Module: namespaces. Pages in these namespaces require more discussion before deletion, and this page can also be a forum for centralised discussions regarding help and policy documentation, and attempts to discuss the scope and imrove the quality of help pages. This is especially feasible because the quantity of project pages nominated for deletion is fairly low. This can also provide a boost to currently inactive WikiProject Manual of Style. As with the AfD and MfD currently, each entry should have a separate page.
  • User pages and drafts for deletion: As with the CfD and RfD, entries should not have a separate page. If deemed necessary, two different sections may be provided for listing pages in the two namespaces. Alternatively, we may have a Drafts for deletion for listing both pages in the Draft: namespace as well as userspace drafts. (In this case, user pages that are not drafts can be listed at MfD. If it is unclear as to whether a user page is a draft or not, it can still be posted here as reviewers at DfD would be competent enough to handle them.)
  • Miscellany for deletion: This page should be retained for discusing deletion of pages in other namespaces, such as Portal:, Book:, TimedText: and Topic:. (As per this requested move, calling this page Miscellany for Discussion is not necessary.)

Please be free to suggest variations to this proposal. SD0001 (talk) 06:46, 22 February 2015 (UTC)

I see this as a lot of confusion for not much benefit. And when project pages do get nominated for deletion, they get plenty of attention, thanks to the big fat "we might delete this" message on top. Oiyarbepsy (talk) 08:41, 23 February 2015 (UTC)
I do not think this would make things any more confusing. These new pages are just like the existing AfD, RfD, CfD and TfD. Where is the confusion? Well, those banners are good enough. The problem arises when the pages are not popular enough. SD0001 (talk) 18:23, 24 February 2015 (UTC)
I suppose I could support splitting off the user space ones (due to the newish guidelines on drafts, etc. increasing the workload there), and leaving the rest at MFD. But make it ...for discussion. - jc37 08:50, 23 February 2015 (UTC)
But I don't think we would ever need to discuss user pages and drafts. Minimalistic discussion (such as whether a draft should be deleted or submitted to WikiProject Abandoned Drafts) can be carried or on the deletion page itself. SD0001 (talk) 18:23, 24 February 2015 (UTC)
Seeing as neither modules nor MediaWiki: pages are really project pages, I'm not sure about the "PfD" grouping. I think it would make a lot more sense if Lua modules were covered by the existing WP:TFD. I agree that only splitting out "UfD" would already help solve the described problem. SiBr4 (talk) 21:39, 23 February 2015 (UTC)
Covering modules at the existing TfD is a good idea. But I don't see any fault in including the MediaWiki: pages along with the project pages. SD0001 (talk) 18:23, 24 February 2015 (UTC)
I don't think project pages need to be separated out from MfD; as Oiyarbepsy said they get lots of attention anyway. I can see the benefit of splitting out user pages and drafts to a different process though, possibly managed by WikiProject Articles for Creation. But they have some serious backlog problems right now; best to wait for their input. Ivanvector (talk) 21:48, 23 February 2015 (UTC)
  • I think these should be grouped by subject matter rather than namespace. I may support creation of a draft for deletion page, for drafts and more generally pages whose predominant content is intended as forming (part of) an article, whether in Draft, User or Talk namespaces. TimedText, which are basically subtitles, should go to WP:FFD since this is multimedia-related. Module and mediawiki pages should go to WP:TFD since these are transcluded content, interfaces or technical-related. Topic is kind of like talk and can remain at MfD. The rest can be divided in two subject matters : project and help pages on one hand (concerning the project itself and its inner workings), and portals and books on the other hand (mainly about showcasing content). That being said, the volume for both of those twos if insufficient to justify a split, so they should stay together at MfD. Judging from the January 2015 archive, it's even debatable if we need a separate draft for deletion page since they form most of nominations and if these get removed, MfD would only get a few nominations per week. So at this time, I'd suggest only making the move of TimedText to FFD and Module/MediaWiki to TFD. Cenarium (talk) 00:35, 25 February 2015 (UTC)
    • I agree with the proposal to cover modules and MediaWiki pages at TfD and TimedText at FFD. But at the same time, I feel that WP:Project pages for discussion provides some unique benefits. It provides a much-needed forum to discuss improvements to multiple project pages at once, mergers etc. SD0001 (talk) 14:05, 25 February 2015 (UTC)
  • I don't like this idea. It looks like something that would almost certainly increase administrative backlogs with little to no tangible benefit. Beeblebrox (talk) 17:58, 27 February 2015 (UTC)
    • Could you specify as to which parts of the proposal you oppose? SD0001 (talk) 18:57, 27 February 2015 (UTC)


I would absolutely put Modules with Templates, since they are templates, just templates programmed with a different language. I would also put MediaWiki: interface pages with templates, since they are also "back-of-the-house" code and just make more logical sense to be with other code than with userpages, etc. – Philosopher Let us reason together. 23:53, 24 February 2015 (UTC)
  • I agree, per my above comment.  Cenarium (talk) 00:37, 25 February 2015 (UTC)
  • Support, as per my comment made above. SD0001 (talk) 14:05, 25 February 2015 (UTC)
  • It makes sense to keep computer code separate from content meant for humans. I don't think very many modules or MediaWiki pages are being discussed at MfD, so I'm not sure it matters, much. Note that changing the venue for modules has been discussed at TfD, before. I left a note at WT:TFD about this discussion. —PC-XT+ 14:44, 25 February 2015 (UTC)
    • Modules have been MfD'd just 7 times. Out of these, while four were deleted as per CSD criteria, two (this and this) did not see any comments at all. Doesn't this show that MfD is unfit for modules? SD0001 (talk) 19:48, 25 February 2015 (UTC)
      • No, it shows that optimizing how modules are deleted would be a waste of time. Please describe the actual problem before proposing a solution. More pages means more confusion. Johnuniq (talk) 00:31, 26 February 2015 (UTC)
        • The problem is this: As demonstrated, in particular by this listing, deletion discussions of modules at the MfD fails to attract the relevant audience which might be available at the TfD. I agree that is not a major problem because modules are rarely nominated, but I see strong reasoning in Philosopher's comment that modules are templates and thereby support the proposal. SD0001 (talk) 17:27, 26 February 2015 (UTC)
          • That's a fair comment but people scan MfD and would be quick to raise the issue somewhere if a deletion proposal looked like it needed specialist attention, and modules that are needed can always be undeleted. The problem with TfD is that it has too much noise and drama (plus there are too many purists who would edit war to ensure it is renamed "WP:Templates and modules for discussion" or worse). While the example you linked looks bad, those familiar with the situation know that the nominator is one of a very small number of experts whose judgment can be relied on, and there is no reason to comment about an unused and pointless module. Johnuniq (talk) 01:54, 27 February 2015 (UTC)
            • The "noise and drama" at TfD is hardly relevant to the question of whether templates should be split between fora based on the coding language. I would further note many "modules" and "templates" are built together as one unit, so discussing them in different venues is quite odd. – Philosopher Let us reason together. 02:13, 27 February 2015 (UTC)
            • There is certainly no question of an edit war occurring over the page name since the page is move-protected, and will always be. If anybody wants to rename the page, they can begin an RfC. The question of the page name is not relevant to this discussion. Besides, I cannot agree with your observation that there was "no reason to comment about an unused and pointlless template" simply because the nominator was trustworthy. Wikipedia's deletion policy requires consensus for pages to be deleted. If any person with the expertise to tell if the page was pointless had seen the nomination, they could have added a simple "Delete, per nom" there. SD0001 (talk) 18:48, 27 February 2015 (UTC)

AfD Automatic Notification

Under Articles for Deletion policy there is the ambiguous procedure for notifying interested people, limited by the terms of WP:CANVASS, placing the burden on the nominating editor, who already has skin in the game, a declared POV to advocate. I would like to propose this process be automated. Also, in order to generate comment from people knowledgeable about the subject, if any wikiprojects are identified with subject of the article, those projects should similarly be notified.

  • Proposal 1: We should request a BOT to be designed to automatically send out a neutral, generic message to every individual who has edited the article in question.
""NAME OF ARTICLE" which you have previously edited, has been nominated for deletion. You are invited to comment at "LINK TO DISCUSSION."
  • Proposal 2: We should request a BOT to be designed to automatically send out a neutral, generic message to the talk page of every wikiproject associated with the article in question.
""NAME OF ARTICLE" which might be associated with this wikiproject, has been nominated for deletion. You are invited to comment at "LINK TO DISCUSSION."

Automating this process eliminates potential bias or canvassing, deliberate or unintentional in any notifications. At the same time, it is reasonable to assume it will improve the discussion of each AfD by notifying people interested in the subject. This process should be carried over to other "for deletion" or euphemistically "for discussion" situations. Trackinfo (talk) 19:46, 23 February 2015 (UTC)

Interesting idea. On the first proposal, I suggest restricting such a bot to notifying users who have made some number of non-minor edits to a page, to eliminate noise for users who do frequent wikignomish work across many pages, and/or an opt-out feature. As for the second, it's not always obvious where to post messages for Wikiprojects but many have their own watchlists which automatically notify participants when pages are tagged for deletion anyway, so might be moot. Ivanvector (talk) 21:45, 23 February 2015 (UTC)
I don't know the technical capabilities of a BOT to filter out wikignomish work. Certainly a good goal if it can be done. On the other hand, an interested party might only make a spelling correction if the article is already accurate or they have nothing to add, so edit size might not be a decent factor. And certainly eliminating messages to BOTs would make sense. As for the automated watch lists; I've never seen such a message in any of the wikiprojsects I am involved in. Maybe there needs to be better instruction on how to do that to the various wikiprojsects. Conversely, a few years ago when the great BLP crackdown was going on, I had to find literally thousands of articles to add sources to, manually. We also had a serial copyvio editor in our midst that caused a lot of content to be wiped out. I'm not confident I found all of the articles with issues and cannot identify what reason caused the deletion of significant articles I have discovered missing in later years. Young articles, subject to the most likely attack, might not even be identified as part of a wikiproject's domain. Perhaps there should be a manual process for editors in the AfD debate to issue the BOTs attention. My goal with the suggestion is to neutralize the potential of POV oriented canvassing by automating the process and using neutral language. Trackinfo (talk) 23:05, 23 February 2015 (UTC)
One such project watchlist I'm familiar with is Wikipedia:WikiProject Business/Accounting task force/Article alerts - that page is updated regularly by AAlertBot, and I watch it so that changes show up in my watchlist. This one is not particularly active, unfortunately. I don't think it would be too much of a stretch for a similar bot to put a notice on a user's talk page instead of adding it to the project article alerts, and then you'd have individual notifications about XfDs, but I don't know. Ivanvector (talk) 06:12, 25 February 2015 (UTC)
Please no to spam.
If you want to notify people, how about this:
1.) the AfD is nominated as a subpage of the article in question (instead of being a subpage of WP:AFD) 2,) have the title of any page nominated for XFD, show in the watchlist as red. 3.) have the system automatically add the related xfd to my watchlist. and 4.) and of course have a preferences option to "opt out".
The above will greatly improve notification, help better foster consensus and also help out with more than a bit of the bureaucracy.
To implement would require a bit of software update (shouldn't be too difficult, especially if the subpage name is standardised.) and to update a few templates and bots which currently point to AfD. - jc37 23:29, 23 February 2015 (UTC)
If an editor were actively watching the article, one might assume they would notice the activity. I also like the red highlighting of an article under AfD because once that initial post has been made there is frequently a flurry of minor activity (its like it attracts flies) on an article that might mask the significance of what is happening. Of course, not everybody clicks to watch every article they edit (I certainly don't), or even necessarily monitors their watchlist with any regularity. For the concept of SPAM, don't most of our bots already come with an "opt out" function? That would be a reasonable option to include; for users with large talk volume, or for those who deliberately do not care. In those kinds of situations, perhaps there should be (or already is) a wholesale means to say "No BOTs" to all BOT communication. Trackinfo (talk) 01:11, 24 February 2015 (UTC)
I like Jc37's idea, but would further suggest that all editors of an article of <10 non-"bot" and non-"minor" editors and <100 non-bot edits should be notified along the lines of Trackinfo's suggestion. – Philosopher Let us reason together. 00:43, 24 February 2015 (UTC)
As far as your #2, you might want to have a look at User:Anomie/linkclassifier. It is a script you can enable to highlight various links different ways, including pages which are tagged for deletion/discussion. Ivanvector (talk) 01:03, 24 February 2015 (UTC)
Ivanvector, thanks for your suggestion. Your comment seems to have cut off conversation as if it is a solution. It certainly is a good suggestion for those who are committed wikipedians to help monitor their mass of interests. That is not the primary issue here. If everybody watched everything, we would have no issue. But people don't always, particularly less experienced editors. And noticing an AfD is occurring can get masked by extraneous edits to the article in question. Manual notification can be regarded as canvassing, which is why I am proposing an automated system of notification, so it is fair, universal and absent of a POV. Trackinfo (talk) 23:06, 24 February 2015 (UTC)
My comment wasn't intended to cut off the conversation, just letting you know about a relevant tool - it literally does exactly part 2 of what jc37 suggested, except that the links are violet instead of red, unless you change the default configuration. It's not exactly to the point of your original proposal, but sometimes that happens here. Ivanvector (talk) 06:03, 25 February 2015 (UTC)

What about notifying the user of every edit thad added or removed more than 1,000 characters? Oiyarbepsy (talk) 05:00, 25 February 2015 (UTC)

What about letting users decide their own notification threshold? For example, lowercase sigmabot III and several others have user-level configuration through talk page tags. Ivanvector (talk) 06:17, 25 February 2015 (UTC)
For seasoned editors who can find these settings, and are likely to have high volume talk pages, I think these proposals are appropriate. For the vast majority of editors, one talk message is not that bothersome. We get automated messages for certain kinds of typos or formatting errors already. AfD and the other deletion proposals, involve the entire life of an article. Its a little more serious. If 1,000 characters are deleted, there is a history to go back to, to replace the missing content. Out of the pages I watch, I don't think two days go by without some idiot wiping out an entire article somewhere. A couple of clicks and its restored. With an deleted article, its entire content is gone, deliberately, by authority. The history is gone (except to admins). And it has a black mark against it, a consensus decision against getting restored. So if the article is deserving of being removed, shouldn't that important consensus decision include people who know about the subject? Those would be the ones who felt it important enough of a subject to review and add or delete content. Trackinfo (talk) 08:53, 25 February 2015 (UTC)
There have been related discussions regarding TfD. Somehow making nominations extra visible on the watchlist or using WP:Notifications may be other options, but they would require changes to the software. —PC-XT+ 14:52, 25 February 2015 (UTC) Here's a link: Wikipedia talk:Templates for discussion/Archive 14#Make notifying significant editors of deletion mandatory. There are other related discussions, but they are complicated by the facts that templates affect multiple pages, and merger discussions also happen at TfD. A few examples: Wikipedia talk:Templates for discussion#Query regarding the use of Twinkle for TfD.2FTfMs, Wikipedia:Village pump (proposals)/Archive 118#Better watch list options and Wikipedia:Village pump (policy)/Archive 117#Changing templates —PC-XT+ 15:22, 25 February 2015 (UTC) 15:41, 25 February 2015 (UTC)

Edit-history comparison made easier

Now when I want to compare edits that are not recent, I have to scroll back up after marking the two versions. Some-times this is a long scroll. Couldn't we have the 'Compare these two versions' tab along the left side in a way that we can simply click on it with-out having to scroll up? Kdammers (talk) 13:22, 24 February 2015 (UTC)

Any such change has two costs. There is a development cost, and a less tangible cost in terms of increased screen clutter for every user, whether they use the feature or not. Weighing total cost against the small benefit for a relatively few users, I can't see it. I'd suggest living with "some-times this is a long scroll". ―Mandruss  13:44, 24 February 2015 (UTC)
You may have a home key which jumps to the top in your browser. PrimeHunter (talk) 14:06, 24 February 2015 (UTC)
LiveDiffLink script screenshot
Try User:Equazcion/LiveDiffLink.js. --Fauzan✆ talk✉ mail 09:28, 25 February 2015 (UTC)
Thank you, User:Fauzan! --Atlasowa (talk) 19:30, 25 February 2015 (UTC)
I can't speak to development costs, but I don't see it as particularly cluttering. Also "a relatively few users" - I don't know, and I doubt you know, if the number who would benefit is few or not. Kdammers (talk) 12:00, 25 February 2015 (UTC)
The problem of clutter can be overcome by having it as an opt-in gadget. SD0001 (talk) 12:24, 26 February 2015 (UTC)
Also, a single row of radio buttons would be preferable, I do not understand the logic behind having two, one for older and one for newer revision. This will also reduce clutter while saving time. --Fauzan✆ talk✉ mail 14:45, 26 February 2015 (UTC)
There are two columns of radio buttons for technical reasons--that page is an HTML form, and only one radio button in a group may be selected. Since comparing revisions requires selecting an old revision and a new revision, two button groups are required. Pathore (talk) 22:20, 26 February 2015 (UTC)
That was silly. May be can we have two complete sets of radio buttons? --Fauzan✆ talk✉ mail 02:36, 27 February 2015 (UTC)
I'm unsure what you're saying--the page does have two complete sets. Inconsistent choices are hidden by JavaScript after one side is selected. Disable JavaScript and two complete sets of radio buttons are there. The server will even generate a "backwards" diff if you select a "later" revision that is earlier in time. Pathore (talk) 02:46, 27 February 2015 (UTC)
Page Histor rows screenshot.jpg
In the image, if I have to select the marked edits, first I have to bring the right side radio button selection to the newer marked revision, then bring the left side radio button selection to the older marked revision. If instead, each revision had two radio buttons regardless of the fact that the revision is in the selected range or not, I would have just brought the left radio slection to the newer marked revision. --Fauzan✆ talk✉ mail 06:45, 27 February 2015 (UTC)
Support as opt-in gadget - while I agree that the clutter may be a problem for people, it seems that User:Equazcion/LiveDiffLink.js would probably be a very good idea for enough users to justify making it generally available. עוד מישהו Od Mishehu 13:56, 26 February 2015 (UTC)

Replacement of indef blocking/banning with maximum five years period of block/ban

Indef blocking/banning looks like the death penalty on wikipedia. I know there are procedures to appeal and ways to have clean start, but I still think that indef blocking/banning is unnecessary radical and extreme measurement. Even in case of most blatant vandals, after substantial time period has passed, say five years, the circumstances in terms of wikipedia editing should be much different. I think that by limiting period of ban or block to maximum 5 years most wikipedia editors who were indef banned or blocked would return to constructive editing without having to go to tiresome and sometimes unfair procedures like appeals. This could significantly increase the number of editors of wikipedia. Thoughts?--Antidiskriminator (talk) 14:44, 27 February 2015 (UTC)

I'm not sure I understand what an indefinite block is. To me, indefinfite means not defined, you appear to be saying that it is defined and defined as permament.--Ykraps (talk) 15:11, 27 February 2015 (UTC)
Sorry. I should have said only indef banning. --Antidiskriminator (talk) 15:20, 27 February 2015 (UTC)
A block locks a user out so they are unable to edit whereas a ban relies on the user's acceptance of his/her punishment to prevent editing. Although a block could be used to enforce a ban of course. Are we discussing WP:Banning policy, WP:Blocking policy or something else?--Ykraps (talk) 15:49, 27 February 2015 (UTC)
Any indef restriction connected with behavior of wikipedian does not make much sense. What could possibly be the reason to ban somebody for more than 50 years? --Antidiskriminator (talk) 17:03, 27 February 2015 (UTC)
Oppose: There's no problem that this appears to solve that WP:CLEANSTART doesn't already address.—Kww(talk) 15:13, 27 February 2015 (UTC)
Its less complicated process which does not request using another account and does not recommend to completely avoid old topic areas after a clean start. --Antidiskriminator (talk) 15:20, 27 February 2015 (UTC)
  • Very strong oppose - proposed in good faith I'm sure, but a ban and indefinite block is our sanction of last resort for a reason. It's reserved for people who have been a grave detriment to the project, whose past involvement has been so disruptive that the community has determined there is no hope for them, and has had to force them to leave to avoid further disruption. People who have been sanctioned in this way should absolutely be required to jump through hoops and prove competency before we let them back in. Automatic unblocking of such people is almost guaranteed to cause future disruption. Also, WP:CLEANSTART is not for users who have been banned or indefinitely blocked - you are looking for WP:STANDARDOFFER which applies to anyone who has been sanctioned this way (and applies generally after six months, not five years). Ivanvector (talk) 15:51, 27 February 2015 (UTC)
  • Obvious oppose. I can easily think of several people who were banned more than five years ago and are still just as disruptive as they were then, and I can also think of people for whom an actual infinite (not indefinite) ban – lifelong, with no possibility of appeal ever – is the only appropriate measure. Fut.Perf. 16:18, 27 February 2015 (UTC)
    • Everybody can change and everybody deserve a chance to appeal. If you think five years is not enough, what about .... 10 or 15 years? Do you think 10 or 15 years would be enough long period for wikipedia sanctions to became meaningless? --Antidiskriminator (talk) 17:03, 27 February 2015 (UTC)
      • "...everybody deserve a chance to appeal." Yes, we already have that although some appeals don't have a hope in hell of succeeding. --NeilN talk to me 17:33, 27 February 2015 (UTC)
  • Oppose I think this further complicates things. Most vandals are going to forget they even had an account after five years, or the password used for it. Serious users who get indef'd or banned can take the standard offer. And what about those blocked for legal reasons? We don't want them back, ever. MusikAnimal talk 16:20, 27 February 2015 (UTC)
  • Oppose Extreme action calls for extreme measures. So long as an indefinite block/ban can be appealed, we should keep this remedy in the toolkit for the particularly egregious disruptors. However, any unappealable block/ban should be limited by time. // coldacid (talk|contrib) 17:27, 27 February 2015 (UTC)
  • Oppose "could significantly increase the number of editors of wikipedia" is far too optimistic, misses the word "productive" and I'm very skeptical the potential gains would outweigh these disruptive editors coming back through an automated process. --NeilN talk to me 17:39, 27 February 2015 (UTC)
  • Oppose The availability of a not defined duration is crucial when it is not clear how long the block should be. Short of the worst of offenders we have the standard offer available, even that requires the user to be pro-active as opposed to simply expiring the block. Chillum 17:46, 27 February 2015 (UTC)
  • pile-on oppose Indefininte blocking is not a "death sentence" that's just ridiculous hyperbole. Speaking as a former WP:BASC member who dealt with appeals from some people who have been blocked for longer than five years I find it impossible to understate how potentially disruptive this idea would be. Some people just don't belong here. Period. For the rest it actually isn't that hard to get unblocked if you aren't a troll or a person who is incapable of learning from your mistakes. Beeblebrox (talk) 17:53, 27 February 2015 (UTC)
  • Aw hell naw (or, Snow oppose) - I WP:AGF in the proposal, and get that some immature users could do with just a long (but not indefinite) block to either encourage them to come back when they've grown up, or at least discourage just a little them from socking -- but -- and I'm gonna say it bluntly (and for the sake of WP:NPA I am not applying it to anyone in particular) -- there are some crazy-ass motherfuckers on the internet, and some of them try to push their crazy on our site. Five years is not going to fix intense dedication to the idiotic belief that vampiric Jewish Reptilians used the Illuminati-controlled Freemasons to stage the September 11 attacks to put an atheist-Muslim-Christian born in Kenya in the white house to give ISIL a boost. I've helped get several users perma-blocked/banned who were the second coming of Jesus. There are a number of users I've dealt with who are convinced that their magical beliefs are more reliable than a million scholars if that user wants to say that Quetzalcoatl is really Osiris, Nephalim king of Atlantis. I've got a copy of a (revdelled) letter someone spammed on the site to the US Supreme Court to accuse them of treason for the IRS not accepting his college application.
It would be a waste of our time and energy to have to reban/reblock every five years every single user who tries to taint the site with their earnest but still idiotic dedication to Alchemy, the Ancient astronaut hypothesis, Astrology, Ayurveda, Christian Identity, Dominion Theology, Esoteric Nazism, Feng Shui, Fomenko's New Chronology, Hindutva, Nuwaubianism, the Sovereign citizen movement, Scientology, Young Earth Creationism, or other stuff that even Time Cube guy shakes his head at. Ian.thomson (talk) 18:33, 27 February 2015 (UTC)
My point was exactly based on AGF. I don't know the statistics, but I suppose there are at least 10,000 editors who are indef banned for something they did on wikipedia more than few years ago. I guess that sometimes at least 10% of them would like to return to constructively edit but don't want to bother with appeal or clean start processes. That is at least 1,000 experienced constructive editors. Yes, there might be certain percent of those who would again be disruptive, but I believe after some years has passed, vast majority of them most probably matured enough not to repeat the same mistakes. Those who did not should be easy to recognize and sanction. At least they could be put under some sort of probation?--Antidiskriminator (talk) 20:06, 27 February 2015 (UTC)
That "certain percentage" is probably the vast majority.—Kww(talk) 20:33, 27 February 2015 (UTC)
WP:AGF is not a suicide pact. If some kid who made a bunch of mistakes some years ago comes back under a WP:clean start, I'll totally look the other way if they have grown up and want to help the site. But there are still wayyy too many indeffed editors can only be described as "fucking insane" and will not change for the better.
Have you ever had someone who sincerely believes you are an important figure in the Illuminati wikihound you to post how their bizarre numerology proves you're going to hell, with implications that they'd like to help you get there? Have you ever had someone who sincerely believes they are the second coming of Jesus spam their judgements of how many times you'll be reincarnated as a cow for arguing with them? Have you ever had wanna-be professors continually insult your intelligence for reverting their unsourced theories just once? Have you ever had to help catch a notorious (as in, we've got an article on them) criminal in their attempts to use Wikipedia to further their schemes? Have you ever been wikihounded by someone insisting you need to buy Scientology courses before you can revert their unsourced edits? Have you had to track down someone who truly believes Deus Ex is an otherwise non-fiction work placed in the future to disguise it as fiction? I have.
I'm all for redemption, but even if they completely turn their lives around, the persons behind those edits do not deserve anything like a second chance. The new persons, if they truly are new people, can get new accounts. Ian.thomson (talk) 23:50, 27 February 2015 (UTC)
Oppose This proposal seems to be based on a misunderstanding of the literal meaning of the word "indefinite". The length of an indefinite block is entirely up to the blocked editor. I've seen cases where such blocks were lifted within hours - it simply requires that the editor sincerely undertakes not to repeat the offending behaviour. This proposal will force a genuinely remorseful offender to be blocked for far longer than necessary. Blocks are a protective measure, not punishment. An indefinite block is often the only effective way to deal with actual nutters - releasing all the loonies every five years is simply inviting a never-ending stream of damage to the project. Roger (Dodger67) (talk) 20:49, 27 February 2015 (UTC)

Idea lab

Is showing the date of cleanup tags really necessary?

Why is it so necessary that the date of an added cleanup template be displayed on the articles? I think these should be removed and only work behind the scenes. Back when Wikipedia was new, it may have made a little sense, but today I see articles using Template:Multiple issues showing dates as far back at 2007, and it is very off-putting. It makes us look lazy and was obviously not helpful in drawing people in to clean up the problem. Sure, adding the date better-sorts the template into categories, but if an article requires cleanup, should it really be announced on the page that it still has not been done after so many years? Thoughts? — CobraWiki ( jabber | stuff ) 08:48, 6 February 2015 (UTC)

I agree with the thrust of your proposal. It is useful for an editor to know how long the tag has been in place. If I see a tag dating back to the dawn of Wikipedia then my starting position is to check whether it should just be removed because the issue has been addressed. One common scenario I see is that multiple editors have made small changes and collectively dealt with the original issue but none has presumably reviewed the whole article or felt confident enough to remove the tag. So the date is useful to me. Is it useful to the reader to have the date? Not at all and does indeed make us look lazy. QuiteUnusual (talk) 09:37, 6 February 2015 (UTC)
I like the dates, even for the cleanup tags. Letting people, especially editors, know when the article was tagged is helpful in a number of ways, not the least of which is knowing how to proceed from there -- check the edit history since then, check who added the tag, check and see if they posted anything on Talk around that time, check why they added it, check to see what the state of the article was when the tag was added and what its state is now, etc. In terms of "it makes us look lazy" (or bad) (1) if Wikipedia cared about looking bad it would not let IPs edit, and do many other things differently; I think the date on a tag is very low on the list of how and why Wikipedia looks bad (2) if a random outsider thinks it looks bad, they can always do some cleaning themselves. As it is, nowadays the cleanup tag cannot be added without filling in what exactly needs cleaning up (if I'm not mistaken), so that at least has solved some of the problem right there. Some articles have really old tags because they are so seldom visited. Softlavender (talk) 10:00, 6 February 2015 (UTC)
One man's "it makes us look lazy" is another man's "it gives readers a window into how much attention a particular article receives". Wikipedia tends to be pretty highly trusted among online resources—sometimes much more so than it should be. (Frankly, the earned reputation of our high-popularity, high-traffic, closely-watched, well-maintained articles is probably giving our less-maintained, rougher-edged long tail an undeserved boost.) I actually think it's a good thing to conspicuously remind readers, where appropriate, that some (many!) Wikipedia articles are very much works-in-progress.
Above, QuiteUnusual suggests that it is "common" for issues underlying an older maintenance tag to be remedied without the tag being removed, and that this might unfairly taint a particular article's reputation. Is that actually generally true, or is it just because the articles that QuiteUnusual (or any other editor) are most likely to see are the ones being more-actively maintained? In other words, if we look at the issue from the other end – examining where the tags are distributed, rather than by considering articles with active editors – by using the dated maintenance categories, what do we find? I looked at the first few entries in Category:Articles lacking sources from October 2006, and all the ones I checked are still lacking sources. The articles listed in Category:Orphaned articles from May 2008 still seem to be orphans. Editors should, perhaps, be encouraged to be a bit bolder in removing no-longer-needed maintenance tags, but I have yet to see convincing evidence that more than a small fraction of these tags deal with resolved issues.
That said, if someone with a bit (or a lot) more know-how than I were to create a bot or script to pick out articles with a lot of 'old' tags that had also received a substantial number of edits in the interim as 'priority' candidates for screening and re-evaluation, it's possible it could be a useful tool. TenOfAllTrades(talk) 17:01, 6 February 2015 (UTC)
I like the dates on the cleanup tags in part because often a very-old cleanup tag indicates issues that just don't exist any more - and if a reader notices the old date, he can re-assess whether it still applies. – Philosopher Let us reason together. 18:57, 6 February 2015 (UTC)
I feel there's a lot of value to readers to knowing how long a tag has been in place. I agree that many do get resolved incrementally without the tag ever being removed (the same is true for stub tags, my pet annoyance) - but that's something for us to resolve by patrolling older tags, rather than remove the information completely. Andrew Gray (talk) 19:15, 6 February 2015 (UTC)
  • As well as having the dates there for potential reviewers/editors who might want to fix the articles, I think it's useful for readers to see the tag dates too. Rather than trying to avoid looking lazy, we should be as open as we can in saying "Be careful, this could be a bad article and it's been that way for a long time". The reliability of Wikipedia's good articles is very very good, but the reliability of bad ones is horrid, and that's a common cause of valid criticism of the project. Being open about the bad stuff is a sign of honesty and is a step in helping address that criticism. We should not try to cover it up. Squinge (talk) 11:28, 8 February 2015 (UTC)
  • If most people don't think that the date is helpful to logged-out users, then I believe that it could be set to show only to logged-in users. Personally, I want tags to change their content after a year (or three), to say "If you believe that this tag is outdated, please remove it." WhatamIdoing (talk) 21:01, 12 February 2015 (UTC)
  • Now that is a good idea. there's also a sub-set of tags (such as the "questionable notability" tags) that should probably disappear completely after a set amount of time. – Philosopher Let us reason together. 00:03, 14 February 2015 (UTC)
That last bit is an interesting proposal. I might go with something more along the lines of "If the issues this tag refers to have been resolved, please remove it." (Heck, it might be worthwhile to have that sort of reminder on all maintenance tags.) I would be hesitant to use wording like "outdated" that might implicitly suggest tags should simply expire, even if the underlying issue hasn't been fixed.
I'm reluctant to encourage hiding tags from non-logged-in readers (i.e. nearly everyone who reads a Wikipedia article). At best, the maintenance tags provide specific cautions that a reader should bear in mind about the content of a particular article. And even at worst, a really old maintenance tag flags that an article probably doesn't receive very much attention. TenOfAllTrades(talk) 02:49, 14 February 2015 (UTC)
I agree that tags (and dates) should not be hidden from readers, as they're the ones who most need to be made aware of problems with articles. I also agree that the word "outdated" is not the one to use. Squinge (talk) 10:29, 14 February 2015 (UTC)

Quick Vote

For discussion pages, I think there should be a quick poll at the top to see the general opinion - eg. Do you think ()? Yes, No, Other This would help especially with issues such as mergers and biased sections, as well as the beta area of Wikipedia where it could be used to see the general consensus in a new feature. Awesomeshreyo (talk) 19:20, 9 February 2015 (UTC)

Hm... often, polls are easier but not better. Decisions on Wikipedia are not made on straight votes, but by consensus, and consensus is reached through negotiation and consideration of each side's arguments. While polling can facilitate discussion, a quick poll option for general use could increase the risk of canvassing, might give editors the wrong impression (majority/head count v. strength of arguments), and may be divisive. The argumentum ad populum is a dangerous one. A "quick" vote in particular sounds like something that goes against Wikipedia policy - we're not a democracy - and could lead to polarization. -- (talk) 03:41, 10 February 2015 (UTC)
Quick polls are not and should not ever used for things such as mergers, moves, etc. That must be done publicly, with site-wide viewership, via the standard official procedures. And for other matters, as in all things, consensus and debate is not a !vote -- consensus is arrived at via policy-based dialogue and discussion. If discussion stalls, then the next steps in dispute resolution are used -- third opinion, public RfC, etc. Lastly, "the general opinion" is not going to be reached by a random few people who happen to see and participate in a so-called "Quick Vote" -- Wikipedia is so sparsely populated these days (so many editors leave), and so few editors have any given article on their watch lists, that any attempt at a "Quick Vote" on most articles is going to result in a tiny few responses not indicative of general policies, opinions, and guidelines. Softlavender (talk) 04:13, 10 February 2015 (UTC)

User:Awesomeshreyo, there are some article talk pages that have FAQs addressing questions that are asked over and over again. This can be seen at Talk:Waterboarding or Talk:0.999.... If you think there is another article talk page that can benefit from that, raise it at that talk page. Oiyarbepsy (talk) 18:09, 14 February 2015 (UTC)

Interactive Multimedia Elements

I used to really enjoy the Encarta multimedia encyclopedia (90s). It made exploring and learning new things much more fun and facilitated learning new things in a really good way. For instance there was a page with musical instruments on and you could hover or click each one to get it to play the sound of that instrument. Or you could have the globe and spin around it to find the continents, countries and cities (combine with Google earth?). You could also do 3d tours of capital cities (combine with Google street view?) Wikipedia is really missing this kind of fun and interactivity. Even the pictures are usually dull and sometimes restricted to one picture per article. If you click on the maps often all the borders and place-names are removed so you can't even zoom in on it or get a larger view.

There is just one catch I can think of: Power consumption and server load. If the whole world was using interactive features then it could actually increase global power consumption considerably and I'm not for that so adding features would have to be done sensitively and realistically. Nibinaear (talk) 12:28, 12 February 2015 (UTC)

There was a proposal to allow scripting on articles which enables the development of interactive elements. However, since those scripts are run on the readers' computers, security should be considered. Zhaofeng Li [talk... contribs...] 12:42, 13 February 2015 (UTC)

Ideas for when users die in real life

I spotted this news story about Facebook. I don't think we have any options, other than offering a sympathetic ear to the requests of family members. It would be a relatively simple thing to include somewhere a low or high tech option for users to indicate what they'd like to happen to their userspace when they eventually die. --Dweller (talk) 17:05, 12 February 2015 (UTC)

See Wikipedia:Deceased Wikipedians/Guidelines. PrimeHunter (talk) 17:10, 12 February 2015 (UTC)
Thanks, helpful. I don't see any discussion there of my suggestion. --Dweller (talk) 09:12, 13 February 2015 (UTC)
But you know how to use talk pages. That seems like the right place to discuss it. PrimeHunter (talk) 12:54, 13 February 2015 (UTC)
Ah, now I'm with you. OK, will do. Cheers. --Dweller (talk) 13:04, 13 February 2015 (UTC)

" BOT"?

This must be a silly idea (because I cannot imagine someone else would NOT have proposed it by now). Ok, still: Why not have a bot archive all newly added refs on website (if not already done by this website already) and automatically add a link in the corresponding WP article's reference using the "wayback machine". This would be a tremendous plus for all editors encountering WP:link rots. (talk) 08:50, 15 February 2015 (UTC)

Have a look at this: Wikipedia:Using WebCite Oiyarbepsy (talk) 03:22, 16 February 2015 (UTC)
Thanks. I know this website (i am a registered editor - user:SSZ.) You can do the same at now. The point was automation (i.e. no need to go to the website each and every time, save and archive the reference on WP - for economy articles which I often edit, it is a CUMBERSOME task.) May be this new feature could be optionally available for WP users? (with a check-box in the preference section.) (talk) 08:14, 16 February 2015 (UTC)
Comment on the archive bot notion in general -- I think that there should be a pair of sister-bots: one which checks to see if an external link is archived at and/or webcite and a second which invokes the archiving if the first finds that it is not present. There are problems with serial archiving of 404 warnings sometimes; queries against some sites return a soft-404, i.e. wrapped in the target website's domain site. Unfortunate that these pages do not tell browsers/bots "here be a hard 404, but we are softening it for humans." --User:Ceyockey (talk to me) 12:46, 16 February 2015 (UTC)

Also, Mediawiki is currently working on an automated citing service for WP:Visual editor, called Citoid. It will allow you to enter a DOI, ISBN, URL or other identifier and the software will fill in all the details. There is currently a request to add auto-archiving to this new software. However, it's at a very early stage. Oiyarbepsy (talk) 15:31, 16 February 2015 (UTC)

Automated submission of links to archiving sites drives up the cost for the site and may be against the ToS for that site. Furthermore, this has been suggested in the past (see RotlinkBot and debates of usefullness) with at best mixed results. I believe the last time this was brought up, the community's will was for WMF to develop a storage solution that was a DoA pidgin at the foundation's steps. Hasteur (talk) 15:47, 16 February 2015 (UTC)

I think the issue of traffic between WP and servers should be made separate from the discussion regarding the usefulness of the bot itself. WP could have an arrangement with to pay for storage capacity (all queries would be handled from a WP permanent IP address where the bot would be located). ..and NSA could donate one of its "old"* servers to for free. (*which are still two generations ahead of all commercially available servers :) — Preceding unsigned comment added by (talk) 09:56, 17 February 2015 (UTC)
NSA... Oh, come on. Not again... Zhaofeng Li [talk... contribs...] 10:44, 17 February 2015 (UTC)
 :) — Preceding unsigned comment added by (talk) 11:51, 17 February 2015 (UTC)

My second "silly" idea of the night?

Why not have a "boot camp" for new editors (to be made mandatory may be?) Objective: get new WP editors become familiar with WP guidelines and policies SO AS THEY DON'T TAKE THINGS PERSONALLY AND LEARN THE PROCESS OF WP EDITING AT THE SAME TIME. MAKING THE PROCESS *FUN*. The big plus is that ego is removed while training since there is no convictions and no personal confrontation about it (since new WP editors would be required to edit WP:sandbox articles) and it would help a great deal editors IMHO (new and old editors* alike, sometimes). *e.g. This could be used as an alternative to blocking someone. This could even be handled by a BOT on the other side (simulating other editors and a reference to WP guidelines and procedures being explained or tested as an example) through predetermined algorithms. (talk) 08:59, 15 February 2015 (UTC)

We have The Wikipedia Adventure which is what you are looking for, except that it's completely optional. We shouldn't force new editors to take the blue pill and edit in "the Matrix" before they can do anything meaningful. Zhaofeng Li [talk... contribs...] 09:24, 15 February 2015 (UTC)
Great! This should be advertised More IMO. Also it should be made mandatory for some editors who have skills and good intentions but lack skills relating to other editors' edits. Also I would like to add that this project you refer to should be more detailed. Also Explanations regarding the TOOLS, avenues and procedures should be given (for dispute resolution, so as to refer people to the specific tasks they need to work on.) MY 2 cents as always! — Preceding unsigned comment added by (talk) 09:34, 15 February 2015 (UTC)

Mapping categories to page sections

So, right now we have a task of automatically mapping wikipedia pages to different topics. E.g. pages about politics goes to politics, pages about computer games goes to entertainment and so on. This is done by first mapping our topic structure to top-level wikipedia categories. Then if some category is assigned to page, we select topic associated with some super-category of it. Sometimes this mapping is ambiguous: one page could be assigned to multiple topics.

So we decided to build a system that assigns a subset of page categories to each section on the page (and then rerun our mapping tool on section level).

Do you think it is a good idea to assign categories to sections? For well-developed pages it works great, but for the most of them it is either really hard to do or doesn't make sense.

Can you think of the practical applications of this idea (other than our task)? Like, for example, we can suggest to improve sections that doesn't relate to page categories (or add a new category), or even suggest to write more about a category that is not represented on the page at all (or just briefly described in the first paragraph).

Does it make sense? — YNechaev (talk) 18:56, 16 February 2015 (UTC)

General opinion on physically restricting access to the New Pages Feed

(Note: This discussion was moved from Wikipedia:Village_pump_(miscellaneous)#General_opinion_on_physically_restricting_access_to_the_New_Pages_Feed per a suggestion at the beginning of the discussion. --Biblioworm 20:33, 18 February 2015 (UTC))

As of late, there have been plans by Jim Carter to start an RfC concerning physically restricting access to the the New Pages Feed. He has even started a JavaScript file that could perform that function. I have personally made it clear that I would oppose such a proposal, but that's not the point of this thread. I'm curious to see what the general community's opinion about this is before the formal RfC, should it go live sometime in the near future. I think it would be good to have a more public discussion about this. Thanks, --Biblioworm 01:57, 11 February 2015 (UTC)

  • Biblioworm, first thing I'll note is that this should have been at WP:VPI instead of here. Second, while I strongly oppose using user generated JavaScript to restrict access to an extension written and maintained by the Foundation, I would support a proposal to encourage newer users to obtain more experience before reviewing pages at NPP using whatever tools the Foundation finds appropriate. I'm even willing to contribute my time to work directly on the extension PHP/JS code to make appropriate changes so that wikis can customize their experience as to what requirements are set if any at all. Since the changes I'm willing to make to the extension are not enwp specific, the only question here will be whether or not enwp wants to participate and take advantage of the additional control. — {{U|Technical 13}} (etc) 02:36, 11 February 2015 (UTC)
    • I thought that the idea lab was for developing ideas; not for general discussion about things. --Biblioworm 02:48, 11 February 2015 (UTC)
      • This is a general discussion about an idea before it becomes a proposal. Not a big deal I suppose. The extension that hosts the code that I intend to work on is MW:Extension:PageTriage if anyone else is interested. — {{U|Technical 13}} (etc) 02:52, 11 February 2015 (UTC)
  • I don't like the idea of making the new pages feed invisible to all but some people. One of the advantages of Wikipedia over traditional encyclopedias is its transparency - that the history of drafts and revisions of articles is available to all readers, as is the discussion over how to present information. I think it's potentially useful to persons who might be non-editors to be able to see recent changes and new pages. Also, as someone whose first edits to Wikipedia involved pointing out a page that clearly needed to go (although at the time I didn't know how to go about doing it), I think having these pages available for viewing tells potential editors that their help is needed. ~ ONUnicorn(Talk|Contribs)problem solving 20:24, 11 February 2015 (UTC)

I see no reason to block anyone from seeing the new pages feed. I don't even see a reason to restrict access to the curation toolbar. The potential damage from misuse is pretty much nil. Oiyarbepsy (talk) 23:38, 11 February 2015 (UTC)

I strongly oppose to restrict users from accessing the New Pages Feed. --NaBUru38 (talk) 13:55, 14 February 2015 (UTC)
  • Per the above comments, this seems like a solution seeking a problem. Even if there was a problem, though, this is the wrong solution as basic features of Wikipedia need to be available to all editors. – Philosopher Let us reason together. 19:02, 20 February 2015 (UTC)
  • Oppose. I can see there are problems with incompetent new page patrol and that it needs to be addressed, but actually preventing the non-elite from even seeing the list of new pages is anathema to the egalitarian founding principles of Wikipedia - there are perfectly valid reasons for readers to want to see what is being newly created, and they should not be prevented from doing so. Squinge (talk) 19:15, 20 February 2015 (UTC)

Link to specific content in article (with highlighting)

There is currently a proposal on Phabricator to add a new feature to MediaWiki where one could link to a specific part of an article's content. When someone visits this special link, they would be scrolled down to the relevant part of the content and possibly, the specific portion would be highlighted.

Before we get started with work on this, we wanted to know if this would be useful at all or whether it would help in any way. Comments? — Preceding unsigned comment added by Vghaisas (talkcontribs) 19:04, 19 February 2015 (UTC)

I don't think this would be significantly useful, as we already can create links to any kind of section header, footnote anchor, etc. If a section is too long for such a link to be useful, it's a sign that the section should be split, not that a new kind of link is needed. It would actually be unhelpful, I'm sorry to say, because it creates yet another feature for new users to have to learn, making Wikipedia editing appear even more complicated than it already is. – Philosopher Let us reason together. 18:59, 20 February 2015 (UTC)

The proposed feature isn't really meant for editors. It's a feature that will let readers link to arbitrary portions of the content. So it won't add any complexity to the work of editors.

However, I do agree with the other objection you raised. Sections shouldn't be so long that parts of them need to be linked to. However, how many pages match that objective? If there are still enough pages whose sections are long, would it not help readers to be able to link to specific portions of the content? — Preceding unsigned comment added by Vghaisas (talkcontribs) 19:04, 19 February 2015 (UTC)

"will let readers link to" - and creating a link is an article is editing. The use of these links in articles will be inevitable (unless prohibited by a filter) and would complicate the code, confusing new editors.
As for the section length, Wikipedia is not finished. That we don't yet meet an ideal doesn't mean that we should create a tool, but that we should strive to meet the ideal. – Philosopher Let us reason together. 00:37, 24 February 2015 (UTC)
I'm not sure we're on the same page here. The feature I'm talking about will provide an interface to let a random reader of Wikipedia select an arbitrary portion of the content of an article and generate a link to that selected content. To give a crude example, I could choose to link to the words "Predominantly nocturnal" in the second paragraph of European Wildcat , which could result in a link like (completely random example) When someone visits that link, they will be scrolled down to that section and the two words will be highlighted. This will not involve making any changes to wiki markup.
Were you, though, referring to the fact that then links like would be used in articles for inter-article linking? — Vghaisas (talk) 12:35, 25 February 2015 (UTC)
You mean something like the way Google does it with books, like this? Squinge (talk) 13:22, 25 February 2015 (UTC)
Yes, exactly. Thank you for that example. Something similar to that. Vghaisas (talk) 13:28, 25 February 2015 (UTC)
@Vghaisas: Yes, hat was exactly my concern. – Philosopher Let us reason together. 00:26, 27 February 2015 (UTC)
Philosopher: So, your opinion is that the availability of such links will lead to an extra complication in editing of articles and hence, is not a good idea? — Vghaisas (talk) 02:33, 27 February 2015 (UTC)
Yes, that is my primary concern. If there was some compelling reason that we needed such links, it could overcome it, but as I noted above, section headers are more than sufficient for linking to specific areas of the content - our sections are significantly shorter than most Google Books! and should never be so long that it's hard to find specific content within them - so there is no such need. – Philosopher Let us reason together. 02:39, 27 February 2015 (UTC)

Vghaisas, what would happen to your link when someone removes those words from the article? Text changes more often than section headings. Or what happens when someone adds multiple copies of those words, and I meant to highlight the third instance? WhatamIdoing (talk) 00:36, 27 February 2015 (UTC)

WhatamIdoing: The example I gave of ?specific=p2w2 was very random. The challenge is developing a method that can account for changes in text, possibly by using identifiers that do not depend on how many times the words appear in the article. In addition, if the given text gets deleted, there is the option of looking at the history of pages. The basic question is, is it a good enough idea to try and attempt this at all or is there something which makes it too bad an idea to even give it a try. — Vghaisas (talk) 02:33, 27 February 2015 (UTC)
Interesting idea. Definitely more of a reader-focused feature. Not an easy problem. Throwing anchors everywhere in the wikitext is not really an option.
I think direct-linking-to-Wikipedia-sentence is interesting for Wikipedia readers: "Fact checking to resolve disagreements" is one of our biggest use cases. :-) Giving a direct link to the Wikipedia sentence and say "See i told you so" and "Wikipedia agrees with ME, see" or "You were right, according to the Wikipedia article" etc. The Wikipedia mobile app for android wants to experiment with a feature "Tweet a fact" (Example tweet), which turns the highlighted sentence in a picture (afaics). A bit, ehm, indirect for linking... I'd be interested how this sentence-level-linking could be done differently! :-) --Atlasowa (talk) 13:50, 27 February 2015 (UTC)
Major Wikipedia use case: Fact checking to resolve disagreements!
Mark Wikipedia text in android app and "Tweet a fact" (Example tweet)

International idea: sign of the existing discussion on interwiki box

After comparing different Wikipedians of discussion pages of articles I suggest to somehow to do notice-sign on to the interwiki box. This means that, for example, if you know some topic well, then you can easily see that on the other language Wikipedia has also discussion page of the same topic. Some drafts can be seen here: File:Discussion sign on iw box --Bioneer1 (talk) 08:16, 20 February 2015 (UTC)

Brainless importing from Word with citations from EndNote or other reference software

Fantasy probably, but I'd love to draft text in MS word or my antique wordperfect, with embedded citations from my reference software (EndNote) and then be able to import the text, with some behind the scenes formatting of all the references.

The advantages to this are so obvious (to me anyway) that I'm surprised this has not already happened.

Thoughts? NewsAndEventsGuy (talk) 19:15, 20 February 2015 (UTC)

Show branching tree of articles and sub-articles in graphic form

Is there a way to map the branching tree of big topics? For example, Climate and Global warming are top articles on those subjects, with lots of sub levels and subsublevels. Text based outlines are nice, but can we show the branching tree in a picture also? NewsAndEventsGuy (talk) 19:19, 20 February 2015 (UTC)

There is {{category tree}} - example on the doc page, or try it in your sandbox. It might not be exactly what you're looking for. Ivanvector (talk) 01:12, 24 February 2015 (UTC)
That is the vcat tool (formerly known as Catgraph), which shows the category structure. See vcat:Global warming. And compare to the german equivalent vcat:Globale Erwärmung (German WP has a more stringent categorization).
Other possibility is showing wikilinks. See for example Hope this helps, @NewsAndEventsGuy --Atlasowa (talk) 20:36, 27 February 2015 (UTC)

Wikipedia Code

I remember when I had just joined Wikipedia a little over a year ago. I remember feeling really confused and wondering where I should look for information on policy, guidelines, and rules. I have spent the last year learning about these policies, guidelines, and rules, yet I am still learning new policies every day. Part of this is because there is no central collection of policies guidelines, and rules.

My proposal is to start the equivalent of the US Code and United States Reports for the English Wikipedia and if successful for the Wikimedia community at large. The Wikipedia Code (as I am calling it) shall follow the following guidelines:

  1. Policies, guidelines, and rules contained in the code shall have reached consensus or for other reasons be enforceable.
  2. Notable discussions shall be included to give context and usage to policies, guidelines, and rules. However, when consensus has not been reached in a discussion that shall be made clear.
  3. Notable decisions by committees on cases shall be included to give context.

What do you think? StudiesWorld (talk) 19:59, 20 February 2015 (UTC)

The problem is that we don't have a "code" as is understood in government. All of our pages have exceptions, and all can be ignored if it clearly improves the encyclopedia. That said, provide more history and background to our policies and guidelines is a good idea. Oiyarbepsy (talk) 20:04, 20 February 2015 (UTC)
A list of everything would be, quite frankly, impossible, though Category:Wikipedia policies and guidelines tries. A full list would also be impossible to ever read - for that matter, it may just be impossible to read the entire Manual of Style! There are useful summaries at Wikipedia:List of policies and guidelines and the Wikipedia:Simplified ruleset. The useful templates {{Wikipedia principles}}, {{Wikipedia policies and guidelines}}, and {{Policy list}} are on both of those pages as well, and serve as a useful index. Do any of these serve the purpose you want, or is there something particular that is still missing? – Philosopher Let us reason together. 22:17, 20 February 2015 (UTC)
@Oiyarbepsy: By "code" I mean solely in the sense of an organized structure. It would also include explanatory text to take in to account the exceptions and notices explaining how rules can be ignored.
@Philosopher: I understand what you are saying but this would aim to be an all inclusive guide. Also, it would not be intended to be read in full but as a resource and reference.
Would you like me to make a draft in my userspace and move this discussion there? StudiesWorld (talk) 22:52, 20 February 2015 (UTC)
If you like. @StudiesWorld: - just be sure to ping me again when it's done! Face-smile.svg – Philosopher Let us reason together. 01:34, 21 February 2015 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── In case you hadn't seen it, Cinderella157 brought up something similar (but not, I think, the same) at WP:VPR#Suggested improvement for accessibility by editors. – Philosopher Let us reason together. 01:38, 21 February 2015 (UTC)

@Philosopher: I skimmed through Cinderella157's proposal and I noticed the community portal. I think that if this idea ever comes about it should be integrated with the community portal. Also, I will try and throw together a draft over the next few days. StudiesWorld (talk) 11:07, 21 February 2015 (UTC)
UPDATE: I started the Wikipedia Code at User:StudiesWorld/Wikipedia Code. StudiesWorld (talk) 11:57, 21 February 2015 (UTC)
I am sympathetic to this problem—I remember spending a lot of time immediately after I joined simply reading help and Wikipedia pages and getting attenuated to the sheer mass of all of the policies. However I suggest you formalize some sort of list for discussion before putting it for comment, and then look for refinements from there. ResMar 04:18, 23 February 2015 (UTC)
@Resident Mario: I am working on a example to use in further discussion. StudiesWorld (talk) 11:43, 24 February 2015 (UTC)

Contesting a CSD

Of all the CSDs I've seen contested the number of times I've seen it done right is a fairly low percentage, even for reasonably experienced editors. I think we need clearer, simpler and less error-prone text offered to the editors contesting CSDs. Bazj (talk) 22:07, 20 February 2015 (UTC)

Editors exempt from 3RR

I closed the 3RRN discussion; nothing else to discuss here--Ymblanter (talk) 22:05, 21 February 2015 (UTC)

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

Given the way this 3RR report is (not) being dealt with, what would y'all think about creating a category of "editor exempt from the 3RR rule"? If we're going to do it in practice, perhaps we should make it a matter of explicit designation. Nomoskedasticity (talk) 18:38, 21 February 2015 (UTC)

Forum shop much? 3rr is clear in showing that BLP articles and reverts may be exempt from the bright line rule.User:Maunus ·ʍaunus·snunɐw· 18:58, 21 February 2015 (UTC)

Interjection: @Maunus. Please could you explain what your edit means! Links to what you are talking about would be great. Using English rather than WikiLanguage jargon would be better. Thank-you __DrChrissy (talk) 19:20, 21 February 2015 (UTC)

@DrChrissy:"Forum shop" means to go to a different forum to gain support for ones viewpoint when consensus is against one in the first forum. That is what Nomoskedacity is doing, since several editors in the edit warring discussion had already told them that Collects edits were not problematic because they were essentially protecting a special kind of article, namely a BLP. BLP means "biography of living persons", and to avoid defamation of living people BLP articles are specially protected, so that removing problematic content from BLP articles is specifically not covered by the 3rr rule, which is what 5 other editors were telling Nomoskedacity in the discussion. 3rr means "three revert rule" which stipulates that an editor may never make more than three reverts on the same article within a 24 hour period - unless they are reverting simple vandalism or protecting a BLP article. So all in all Nomoskedacity's suggestion that User:Collect is somehow exempt from the rules is ill-founded.User:Maunus ·ʍaunus·snunɐw· 22:04, 21 February 2015 (UTC)
They might be. But it depends on whether there's a reasonable argument to that effect, as against a mere assertion. Nomoskedasticity (talk) 19:00, 21 February 2015 (UTC)
See WP:POINT. Don't make silly edits or suggestions in the hope of getting support or attention for something else. PrimeHunter (talk) 21:58, 21 February 2015 (UTC)

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

Bot to find potential RfA candidates

Over the last few years, the number of candidates for RfA has been in decline. There are many reasons for this, not all of which we can do anything about. One thing we can do to get more candidates, however, is to ask more people if they want to run. Some people are proactive about wanting to run for adminship, but others are more reluctant and need some persuasion. I myself only ran for adminship after Worm That Turned nominated me, probably about a year and 10,000 edits after I should have.

There are a few seasoned RfA nominators out there willing to hunt for potential candidates, but it is an imprecise science at best. For my part, my thought process usually goes something like, "Hey, I've seen you around before, and you seem to know what you're talking about; why don't I see if you'd be a good RfA candidate?" That happens quite a lot, but I usually only get round to looking at that editor's edits if a) I have a reasonable amount of time to spare at that moment, and b) I'm not doing in the middle of doing some other wiki-task. And if I do get round to looking at that user's edits, then I might find they have a recent block, or a userbox that says "I will never be an admin, ever." And even if a preliminary check indicates that they would be a good candidate, when I actually ask them if they want to run, it happens quite often that I get the reply "no", or "not yet".

I propose that we take the guesswork out of this process, by creating a bot that check's users' contributions to try and gauge if they are ready for adminship. For example, we could say that a user is a potential admin candidate if they a) have at least 10,000 edits, b) no blocks within the last six months, c) have 50 AfD comments... The exact criteria can be worked out later. Then if the bot thinks that a user is a good potential candidate, then it could leave a message on that user's talk page asking them if they would be interested in running for adminship. This message would only be delivered once for any user, once they satisfy the criteria. The bot would keep a record of users that had already received notices, so that no-one would get any duplicate messages. With just this talk page message, users might think about running for RfA where they wouldn't have before, and people watching their talk page might well chime in with messages of encouragement.

Also, this bot could update a website on Tool Labs that kept track of all the possible admin candidates. So users could indicate whether they want to run on or not on that website, and then users looking for potential RfA candidates could just check the website for eligible users that indicate that they want to run. For nominators, this would be a vast improvement over the current hit-or-miss approach to finding candidates.

I envisioned this system as being most useful for up-and-coming editors that might not have thought about running for adminship otherwise. For established non-admin editors, it may be a good idea to place further limits on who gets asked, to avoid thousands of editors getting talk page messages on the bot's first run. We obviously aren't going to be able to deal with thousands of concurrent RfAs, so we shouldn't be asking thousands of users concurrently if they should run.

Would people be interested in an idea like this? I'd love to hear your thoughts. — Mr. Stradivarius ♪ talk ♪ 11:50, 25 February 2015 (UTC)

As long as we aren't giving the potential candidates false hope, I like the idea - perhaps they should be pointed to somewhere they can request a nomination? Hard criteria is by no means any sort of guarantee of a pass, but it's certainly a good place to start. WormTT(talk) 12:06, 25 February 2015 (UTC)
I'm going to have a think about how best to notify the users about RfA, but at the very least a bot which generates a list of candidates who pass the typical admin threshold sounds like a great idea. Sam Walton (talk) 12:32, 25 February 2015 (UTC)
  • Comment Could a bot be programmed to ignore blocks such as the current candidate at AfD has in his history? (Unblocked within the minute with the comment 'ooops', to be exact.) I haven't nominated anyone yet because of a distaste for digging in stats, and because someone else usually nominates them before I get around to asking. This could be useful, if it can show a wide spread of editing rather than 10,000 edits made up of small edits solely to articles about beauty queens, the history of Jammu, and glass frogs. On the other hand, quite a few of the high contributors on the list of such aren't exactly the sort you would want as admins for assorted reasons (but quite of few of those are currently blocked or banned, or keeping a low profile). Would the bot be able to spot (thought there for a new game - Spot the Bot) the cantankarous sods that never get blocked, but turn up everywhere to disrupt with their PoV? Peridon (talk) 14:49, 25 February 2015 (UTC)
    Bots could be programmed to ignore blocks that lasted less than, say, a couple of hours, yes. On the other hand, I'm afraid that bots are very bad at spotting cantankerous sods. :) It's possible that we could build in some kind of human-run cantankerous-sod-spotting system into the website, but we'd have to think very carefully about how that would work. — Mr. Stradivarius ♪ talk ♪ 15:02, 25 February 2015 (UTC)
    I think it would easily be the case that the bot generates a "here's some possibly, by numbers alone, good candidates" list, which would then require investigation from users looking to nominate who could pass their judgement as to whether any given editor is a cantankerous sod or not. Sam Walton (talk) 17:22, 25 February 2015 (UTC)
    Darn, now I'm disappointed that WP:CANTANKEROUSSOD doesn't exist... ansh666 02:25, 26 February 2015 (UTC)
  • Comment - Good idea, but I think it would be best if the bot compiled a list of potential candidates for further vetting by prospective nominators, but did not notify the candidates directly, per WP:BEANS. Some people who meet whatever criteria are set would not make good admins, and I feel like that particular pool of unsuitable candidates would be the ones most likely to ignore the WP:RFA Guide and lead to unnecessary drama. Ivanvector (talk) 16:11, 25 February 2015 (UTC)
  • Neat idea. I'd say to keep the criteria pretty minimal. Don't require that the editors worked in certain areas, for example. The bot shouldn't disqualify a vandal-fighter due to lack of featured articles, nor an article writer for an absence of speedy delete noms. I'd say a one-year and 5,000 edit criteria, with removal from the list for certain red flags (such as blocks, frequently declined speedy deletes, excessive activity at admin's noticeboard, a more than one accusation at sockpuppet investigations, etc). And I agree that the bot should only generate a list for humans to review. The bot could also list the non-ideal editors and state what tripped its red-flag detector. Oiyarbepsy (talk) 19:33, 25 February 2015 (UTC)
  • For those who don't remember, Scottywong had an Admin Score Tool to calculate an editor's readiness for RfA. See User:Scottywong/Admin scoring tool results for an example of the results as of 4 March 2013. Unfortunately, with the migration to WMFlabs, many of the inputs for that tool can no longer be accessed and so the results of the calculations don't have the desired meaning now. But this approach could be updated and used as a model if someone is interested. --Arxiloxos (talk) 19:57, 25 February 2015 (UTC)
    I'm going to place a comment here to emphasize that this has been done but no one moved/maintained the tool for Labs. (I happen to be listed there too as of that date—I have a big gaping hole in my contributions from a recent wikibreak but have been returning slowly to editingpontificating here.) --Izno (talk) 22:29, 25 February 2015 (UTC)
  • I emphatically applaud Mr. Stradivarius for thinking outside the box here. This idea certainly has the potential to be useful, however I agree with Ivanvector that it wouldn't be ideal for the bot to notify prospective candidates directly. Perhaps a table of prospective candidate could be compiled. Nominators could survey the table and approach candidates they deemed to be qualified. If the candidate declined the offer, a note could be made of this on the table. (In other words, this would be very similar to the admin score table above.) Mellowed Fillmore (talk) 21:07, 25 February 2015 (UTC)
  • If this bot was created, there'd need to be a thing you could put on your user page to exclude you from being considered if you don't have any interest in being an admin. Reyk YO! 21:12, 25 February 2015 (UTC)
  • I agree with everyone else who has said this is a good idea; but have the bot make a chart or list for others to peruse. ~ ONUnicorn(Talk|Contribs)problem solving 21:44, 25 February 2015 (UTC)
  • I have no objection to such a bot as long as it is exclusion compliant and I can opt out if I so choose (for example if I'll be on wikibreak (like I kind of am now)). — {{U|Technical 13}} (etc) 22:26, 25 February 2015 (UTC)
  • As others have said, simply creating a list for human review would be best. Also, although I agree candidates shouldn't be excluded for not performing a certain activity, such as AIV or FAs, I think there should be something - so, perhaps, 6000 edits, 1 year tenure, no significant blocks, as well 50 AfDs or 100 AIV reports or 1 FA - just an example. BethNaught (talk) 22:38, 25 February 2015 (UTC)
  • Can the bot also look at the user's number of recent edits and account age, as well as anti-vandalism, new page patrol, etc., then put them in a table for human nominators to review? I will support such a scheme, but not a bot nominating candidates directly. Epic Genius (talk) 23:00, 25 February 2015 (UTC)
@Epicgenius: To be clear, that isn't the proposal, the bot would only leave a message suggesting they might think about running. BethNaught (talk) 23:02, 25 February 2015 (UTC)
@BethNaught: Sorry, I may be a bit confused about what this bot should do. This function can be run using another bot that documents all these things. (Also, this other bot should document the number of blocks that the candidate has, complaints about the candidate, SPIs, etc. Epic Genius (talk) 23:05, 25 February 2015 (UTC)
  • Strong oppose: Oh the devilish tangles created by the well intentioned. Everyone thinks this is a good idea. Look down the road. People will be referring to it saying candidate so-and-so wasn't picked up by the bot. This will codify a nightmare; the perennial proposal of prerequisites to adminship, which only just recently went up in flames. The well intentioned here tried to draw a connection between a potentially good candidate and AfD. Guess what? I recall a study that showed the more someone participated in AfD the less likely they were to succeed at RfA. Here's the reality; you don't need a bot to tell you who is likely a good candidate. If you're obsessed with finding high edit count people who aren't admins see Wikipedia:List of Wikipedians by number of edits. It's nicely marked to tell you who is already an admin. More importantly, people who are experienced enough and potentially ready to be administrators already know about RfA and don't need to be told. This bot isn't going to increase the number of candidates at RfA, much less good candidates. --Hammersoft (talk) 23:23, 25 February 2015 (UTC)
    People could still run if they weren't picked up by the bot, so the criteria wouldn't be official. I can see the problem with unofficial criteria becoming perceived as official criteria, though. How about instead of a simple yes-or-no decision, we have the bot generate a score, like Scotty Wong's admin score tool does, and just make a list of every editor with their score? Also, I have tried finding admin candidates from Wikipedia:List of Wikipedians by number of edits, and there are a number of drawbacks with it. The biggest one is that you have no idea if someone has looked at that person's edits before, or whether they are actually interested in running for RfA. That can lead to a lot of wasted effort. And as for saying "you don't need a bot to tell you who is likely a good candidate", you should try it some time. :) If you are the kind of person that doesn't like to rely on just gut feeling, there are quite a few things that you need to check when you review a candidate (see my checklist, for example). Quite a few of those checks could be automated to some degree, which would save nominators time. — Mr. Stradivarius ♪ talk ♪ 00:50, 26 February 2015 (UTC)
    In the UK, an educational test called SATS was introduced to see how well kids of certain ages were achieving. Great idea. But... Parents quickly regarded it as an exam to be passed. And the teachers proceeded to teach the kids TO pass it, even though there wasn't a pass/fail standard as such built in. Regardless of the intention of assessing both the progress of the kids AND the success rate of the teachers, it became a source of stress to kids and teachers alike. Why am I telling you this? Because I reckon, like Hammersoft, that this list of potential candidates WILL become a list of those who fit the pattern and only those will get !voted for. The intentions are great. But a hell of a lot of safeguards need to be built in to avoid having a SATS disaster and a load of cloned candidates. Like the cloned MPs that the UK has at present. Peridon (talk) 17:53, 26 February 2015 (UTC)
  • Just adding my thoughts. Overall I like the idea, very much. However, as other people have indicated, I seem to think it'd be better if the bot were to compile a list of possible candidates for OTHER nominators to peruse. This will be a more realistic determination on a candidate's suitability, and is less likely to instil false confidence/hope. Also, one must not get drawn into making the bot have high targets in specific areas of contribution. Whilst people may have their criteria, each candidate will always be stronger or weaker in certain areas than others. Orphan Wiki 23:41, 25 February 2015 (UTC)
  • Neutral, having a bot might be going a bit too far, but we do need to have a good admin score tool up and running. This one is missing some things (because of blah blah blah, aka a bunch of technical jargon-filled reason) and I brought that up once before about getting it fixed, but nothing ever happened. Let's get the tool fixed first. --AmaryllisGardener talk 03:06, 26 February 2015 (UTC)
  • Comment I don't think the problem is a technical one, so using a technical solution seems counterintuitive for me. All too often, the problem isn't locating them, it is convincing them to run for a variety of reasons. RFA itself is infrequently quoted as the reason, the hassles of simply being an admin is the biggest concern, and a valid one. The Editor of the Week program at WP:WER has found us 4 or 5 people who are now admin in a very short period of time, and the nominations are by any and everyone, then vetted by volunteers at WER. Perhaps more programs like this would be helpful, as they engage the entire community to find quality contributors. Dennis Brown - 08:41, 27 February 2015 (UTC)
  • Strong support I think this is a great idea. For all we know there are dozens of potential admin candidates out there who might be interested in running if they are told they can. The bot would just find the account, the RFA process remains the same so there is no problem there. I'd love to see this implemented. §FreeRangeFrogcroak 18:11, 27 February 2015 (UTC)
  • Hmm? If the issue is letting people know they can run for adminship, then spam all accounts with a notice that adminship is available to those who pass RfA, and give them a pointer to relevant documents. We don't need a bot. --Hammersoft (talk) 18:41, 27 February 2015 (UTC)
  • Nowhere does the proposal say the bot will be posting anything to any talk pages. I assume it will generate a report that can be actioned by nominators as needed. §FreeRangeFrogcroak 19:44, 27 February 2015 (UTC)
  • Yes it does, it says "Then if the bot thinks that a user is a good potential candidate, then it could leave a message on that user's talk page asking them if they would be interested in running for adminship." --AmaryllisGardener talk 19:50, 27 February 2015 (UTC)
  • This is the idea lab, and the automatic bot notifications was just that. A lot of users have rejected that idea, preferring the bot create a list instead. Oiyarbepsy (talk) 21:22, 27 February 2015 (UTC)

Would this bot be too complicated?

Reading the above, one issue is that this bot would be very complex, which is concerning. We would need a top-notch code writer to make this happen, and the potential for errors would be high. Oiyarbepsy (talk) 19:34, 25 February 2015 (UTC)

I don't think it would be too complex; check if the user has made over some number of edits, if they are not blocked, if they have made so many AfD votes, if they have been active for the past 6-12 months, etc. I'm no bot coder and obviously we'd put some more parameters in but I can't imagine that's hard to search for. Sam Walton (talk) 20:06, 25 February 2015 (UTC)
We've already had something like this: the adminscore tool. It's not working anymore - it can't access most of the things it checks for - but it would probably be a good starting point. However, I don't think a bot would solve all our problems; it should only be used to identify potential potential candidates, then checked by hand and taken with a couple bushels of salt (I remember when adminscore was still working it had several editors who the community would never have approved among its top scores). Also, feature creep would be something to be careful of - start adding in every single possible factor and then yes it would eventually become too complicated to the point of uselessness. ansh666 02:21, 26 February 2015 (UTC)
Next time I should read the entire thing before commenting...oops. ansh666 02:22, 26 February 2015 (UTC)

List or notification

So should such a bot directly ask users to run for adminship, or should it produce a list with humans given the job of asking? Oiyarbepsy (talk) 21:22, 27 February 2015 (UTC)


Hello everyone!

I'd like to share something I've been hacking on in the past few days. It's a simple tool for exploring articles with unsourced statements, currently hosted at The full code can be found at I mostly built this to explore a few technologies I wasn't too familiar with, but I hope it could be useful to the community: it seems to me that adding citations where they're needed could be a good entry point for new editors, so I tried to make that a little easier. There's lots of room for improvement, of course, but I would love to hear any feedback you might have, and I'm definitely willing to work on making this better suited for real-world usage if the idea is any good.

Thanks, and apologies if this is the wrong place to share this. -- Surlycyborg (talk) 22:36, 26 February 2015 (UTC)

This is pretty cool. One thing that would be useful to implement is stopping the tool flagging lead sections when there are other sections in the article. Lead sections don't need to be referenced if the information is sourced elsewhere in the article but the site showed me a number of sentences from article's leads. Sam Walton (talk) 23:30, 26 February 2015 (UTC)
Thanks for the suggestion! If I understand it correctly, it looks like citation needed templates should generally be removed from lead sections, right? If that's the case, then perhaps we do want to flag them, except the site could suggest removing the templates instead of adding a reference? I've filed an issue on the project so I don't forget about this. – surlycyborg (talk) 13:19, 27 February 2015 (UTC)


Wikipedia and game theory

How can the game theory be applied to model wikiedits to articles and wikidialogues in talk pages?-- (talk) 11:03, 13 February 2015 (UTC)

Not so easily: it's probably impossible to define utility functions for the English Wikipedia, the Wikimedia Foundation, and individual editors. Martijn Hoekstra (talk) 11:56, 13 February 2015 (UTC)
Not an expert - but just pondering, it seems to me 'its complicated' and you would get some partial insights and some aspects fit but not have a complete capture or simple model. For example, the terminology of game theory might be applied to say it's a cooperative game with transparency and history and sequential moves. Or might consider that some articles fit to the Philosophy use in being development of a shard knowledge, while more controversial ones look to be a Prisoners dilemma with 3 rounds known in advance. Not sure where you're wanting to go with it all anyway. Markbassett (talk) 04:48, 17 February 2015 (UTC)
Partial insights are fine and welcomed. An interesting situation to model re cooperativity or its opposite is to estimate probabilistically the time needed by a main user assisted by another to remove a misquotation of a source which is kept in an article by 3-5 other non-cooperative editors who oppose to the elimination of the misquotation by various spurious reasons.-- (talk) 11:28, 18 February 2015 (UTC)
The biggest application is first mover advantage and second mover advantage. This plays out in WP:3RR, and WP:Wheel war among other things, even though we all know about it and explicitly allow WP:GAMEing to be considered on its merits. All the best: Rich Farmbrough17:07, 23 February 2015 (UTC).


Note that Luigi Arienti has died acording to italian wikipedia. Thank you. — Preceding unsigned comment added by (talk) 14:42, 20 February 2015 (UTC)

Hi IP. This note should go on Talk:Luigi Arienti. However the Italian Wikipedia article has no sources that verify his death. --NeilN talk to me 14:56, 20 February 2015 (UTC)

RfC the Streisand Effect and Charlie Hebdo

Opinions of neutral uninvolved eds eagerly sought on this important topic at Talk:Streisand_effect#RfC:_Is_the_Streisand_Effect_defined_by_usage.3F_Should_wp_include_Charlie_Hebdo.3F

Hopefully, once folk actually read and engage with the proposed material and reasons for its inclusion, the problem should be easily resolved. Meanwhile, an unusual combination of circumstances resulted in me looking quite trollish, so some uninvested perspective would be very welcome.

Plus I suspect there could be lessons to be learnt here re declining numbers of wp editors. GreenPeasAndPotatoes (talk) 07:23, 21 February 2015 (UTC)


I am trying to find out about Pichincha, Ecuador. According to, there are over twenty universities there. Yet,

Pichincha,_Ecuador is a tiny article about Guayaquil.

When I go to Pichincha Province, I get a page with no mention of such a city or town and with dead links Google maps shows it as a small locale just outside of Quito.

Kdammers (talk) 10:59, 21 February 2015 (UTC)

@Kdammers: Have you tried Wikipedia:Reference desk? They often answer questions of the form "I am trying to find out about ...". --Redrose64 (talk) 19:25, 21 February 2015 (UTC)
The article Pichincha,_Ecuador had been vandalised, but it does appear to be a small place. However the list of universities linked to above appears to be organised by province, and Pichincha Province includes the capital city of Quito and very likely does have a large number of universities.-gadfium 22:08, 21 February 2015 (UTC)

Wikilinks going to wrong targets for years

I just found out that the article American craft had credited a book written by Michael Monroe as a source. Now the link Michael Monroe goes to a Finnish rock/punk musician, real name Matti Fagerholm, who is best known by his artist name Michael Monroe. I very seriously doubt he would ever have written a book about American craft, that must have been some American writer whose real name is Michael Monroe.

The thing is, the article American craft had been this way ever since it was created, for almost nine years. Right at the beginning, or any time since, its original author could have actually clicked the wikilink and seen that he/she had the wrong Michael Monroe. But no, he/she did not, and neither did anyone else.

I finally removed the wikilink from the author's name. I would have done it sooner, but I didn't know the article American craft existed. I only found it by using the "What links here" tool for Michael Monroe.

I myself often click on every not completely obvious blue wikilink in articles I have created, or that appear in edits I have made, just to be sure I have got the right targets. Not immediately, but usually within weeks or months. I don't just leave them entirely unchecked for almost a decade.

Why can't people be more accurate in checking their wikilinks? JIP | Talk 20:39, 23 February 2015 (UTC)

We see this issue time and time again with disambiguation links. People seem to make links without thinking about the possibility that there could be anyone else in the world with a fairly common combination of first name and last name. There also seems to be a sense that if a human name is linked in an article, it must be linked - even if the article is on a small high school and the name is that of the gym teacher. Perhaps this craft writer is notable, and should have an article, in which case we might disambiguate "Michael Monroe", and at least it will be easier to tell that there are bad links going to the page. I do think that it would be great if we had some kind of helpful hints coming from the system itself that would let an editor know that a link was fishy before they saved the edit. bd2412 T 22:01, 23 February 2015 (UTC)
@JIP: My guess is that the user in question was an unpaid (and probably untrained) volunteer just starting to understand how Wikipedia works. Everyone makes mistakes. Unfortunately, the user doesn't seem to be active anymore for you to ask. Thank you for fixing the article.
I like to go hunting for incorrect links, such as Prince, Cream, and Pink when the user meant Prince (musician), Cream (band) and Pink (singer). Maybe this would be an area where you could contribute too. Happy editing! GoingBatty (talk) 22:22, 23 February 2015 (UTC)

how to add geocoordinate data


I can't figure out how to add geocoordinate data. I have lat=45.8104911, long=13.4287543, but when I try to fill in a template copied from another article I get error messages. Thanks, EChastain (talk) 21:29, 23 February 2015 (UTC)

@EChastain: The method for adding coordinates varies, mainly according to whether or not an infobox is used on the article, and what kind of infobox it is. So, which article do you wish these coordinates adding to? --Redrose64 (talk) 21:34, 23 February 2015 (UTC)
@Redrose64: to Torre (river), thanks, EChastain (talk) 21:53, 23 February 2015 (UTC)
That article uses {{Infobox River}}, and the documentation for that shows that two pairs of coordinates may be used: if your coordinates are those of the river's origin (which may be a source or confluence), use |origin_lat_d=45.8105 |origin_long_d=13.4287 but if they are the river's mouth (which again may be a confluence), use |mouth_lat_d=45.8105 |mouth_long_d=13.4287 --Redrose64 (talk) 22:00, 23 February 2015 (UTC)
@EChastain: I forgot to mention: don't use as many as seven places of decimals, that works out to about one centimetre - I'd use four places (ten metres), see WP:OPCOORD. --Redrose64 (talk) 22:06, 23 February 2015 (UTC)
I have replied at Wikipedia:Help desk#how to add geocoordinate data. Please only post a question in one place. PrimeHunter (talk) 22:19, 23 February 2015 (UTC)
Thanks so much. That's exactly what I wanted to know. EChastain (talk) 22:23, 23 February 2015 (UTC)

Can anyone get this to work?

The workaround described here with getting un watermarked images from a certain site [ex. [37] ]. I can't seem to get this to work there something I'm doing wrong, or have browser updates since then made it impossible to do? Connormah (talk) 08:24, 24 February 2015 (UTC)

New talk page watcher template created

Most editors who participate on user talk pages have seen (talk page stalker) used to preface comments. Based on concerns listed at Template talk:Talk page stalker I've created a new Template:Talk page watcher which produces (talk page watcher). Please comment if you wish. --NeilN talk to me 15:46, 24 February 2015 (UTC)

Wiki Loves Africa: last hours to vote


The c:Commons:Wiki Loves Africa photographic contest is reaching its end and the jury has decided the first three winners: c:Wiki Loves Africa 2014/Winners

We wish to add a fourth prize that will be voted by the community. A selection of 20 images (the best of the selection by jury, from n°4 till n°23) is proposed here : c:Wiki Loves Africa 2014/Community Prize Selection. Please cast your vote ! (only one vote per person please) Anthere (talk)

Vote for Wikipedia in the DoGooder Awards

I received the following e-mail (lightly redacted):

We run the DoGooder Awards, which honor the best nonprofit videos each year. We do this with YouTube and something called the Nonprofit Technology Network, which is basically an association of nonprofit technologists. The purpose of the awards is to educate the broader public about important work that the nonprofit community does, and to showcase videos which will inspire other causes to invest to tell their own stories.
Wikimedia did a video about 2014 accomplishments on Wikipedia that's a finalist in the awards. The video has the hashtag, #Edit2014
A judging panel chooses the finalists among hundreds of entries. The winner among the 4 finalists are chosen by public voting. Voting opened this week.
My question to you... Is there a good way to let the Wikipedia community know about this? I don't know what level of interest there would be, but I think the video honors the people working on the platform and given the reach of Wikipedia, it would be really nice to see it get broader reach.
I know that Wikimedia has put something on their social channels, but it seemed not really to reach folks. The video has 19 votes right now.
Here's the link:

Get to voting! —Justin (koavf)TCM 20:40, 26 February 2015 (UTC)

@Koavf: Have you considered Wikipedia:Wikipedia Signpost/Newsroom/Suggestions? GoingBatty (talk) 03:40, 27 February 2015 (UTC)
@GoingBatty: Definitely and I recommended that to the person who originally sent me the e-mail but Signpost won't be published in time for the vote. —Justin (koavf)TCM 04:15, 27 February 2015 (UTC)
  • It just published. Like, just. If you'd mentioned this to the editor in chief, it could have been inserted. — Crisco 1492 (talk) 05:33, 27 February 2015 (UTC)

A young and old person kissing

This is a rush request for a kind editor to take a staged photo to help save Wikipedia a ton of resources.

It would put an end to two months, approaching 20k words, and many hours of observer reads, over a disputed lead image at Age disparity in sexual relationships. (It is gone now, but in the last stable version, so will return. It is a picture of a marriage -- not ideal.)

Image needed: Ideal would be a man and woman, very obvious age difference, waist up, (fake) kissing, clothes on of course, holding hands (they show age well) visible at shoulder level, so the focus of the image would be heads and hands.

Please, anyone with a camera and willing, appropriate people in the room, take the photo and upload it here.

Many thanks,

Anna Frodesiak (talk) 02:33, 27 February 2015 (UTC)

Only on Wikipedia is the opportunity presented to be the face of age disparity in sexual relationships. Chillum 03:44, 27 February 2015 (UTC)
Well, how about Cranach: [38] (FYI all I did was put "young and old in art" in google images just now - less than two seconds) Alanscottwalker (talk) 16:28, 27 February 2015 (UTC)

Cranach is a good start. commons:Category:The unlikely couples by Lucas Cranach (I) --Atlasowa (talk) 19:00, 27 February 2015 (UTC)

Forget what i wrote. Talk:Age_disparity_in_sexual_relationships#Possible_illustration etc. OMG. --Atlasowa (talk) 19:07, 27 February 2015 (UTC)

The Core Contest

is being run again in March - see Wikipedia:The Core Contest for details. Cas Liber (talk · contribs) 11:20, 27 February 2015 (UTC)

Adding diacritical marks

What is going on with all the changes being made in articles (and their titles) by adding accents and tildes to proper names? Wikipedia guidelines are pretty clear on this. See Wikipedia:Naming_conventions_(use_English)#Modified_letters. It is very annoying to me as a copy editor to see these mistakes in spelling: I am always impelled to dive in and correct them, and that is just a waste of time. In some instances I have had to ask an administrator for help in renaming (moving) an entire page to one with the correct spelling. I hope the people reading this can find a solution to this (apparent) wave of name changes. Thank you. GeorgeLouis (talk) 18:14, 27 February 2015 (UTC)

@GeorgeLouis: You don't give examples, but judging by your contribs, in which I find this thread and this edit, your most recent concern is with Richard Alarcón. This was moved to its current title in June 2006, and hasn't moved since. --Redrose64 (talk) 18:57, 27 February 2015 (UTC)

Moriscos not of Arab descent, but Iberian instead?

I have made an RfC [39] at the talk page [40] of the Morisco article.

Should the last paragraph in the "Expulsion" section of the article state as accomplished fact that Moriscos were mostly not descendants of Arab settlers, but overwhelmingly the descendants of native Iberians who converted to Islam?

A couple of editors insist that this statement be left as it is: "Contrary to popular belief, the Moriscos were for the most part not descendants of Arab settlers, but instead were overwhelmingly the descendants of Muladis, native Iberians who converted to Islam under Muslim rule, and were as ethnically Iberian as the Christians who expelled them." The only supporting source given is a documentary on the British Channel 4. They allow qualifying information to be appended, but revert any attempt to rephrase the declarative statement so that it doesn't represent this as an objective fact, as the article's history will show. Carlstak (talk) 05:21, 28 February 2015 (UTC)