Jump to content

Wikipedia:Village pump (proposals)/Archive 119

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

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

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 [1]. 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. [2]. 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? 104.237.54.139 (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. 180.150.134.149 (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. 180.150.134.149 (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. 180.150.134.149 (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. 180.150.134.149 (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. 180.150.134.149 (talk) 14:51, 19 February 2015 (UTC)
This discussion is not at all closed, and you can discuss it. This action is highly controversial. 180.150.134.149 (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.

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 (talk • contribs) 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
PAGE) 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|USERNAME}} 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}} (e • t • c) 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)

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)

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)

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

NO ACTION
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 - http://en.wikipedia.org/wiki/Islamic_State_of_Iraq_and_the_Levant 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.

isil

isis

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 (talk • contribs) 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.

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 though...one 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)

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)

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)
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 (talk • contribs) 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)

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.

Benefits:

  • 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:

{{User:Unit388/draft-review|Unit388}}

Don't fear change people. Unit388 (talk) 02:57, 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)

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

SNOW CLOSED
(non-admin closure) Consensus is against reducing maximum blocking time from indef to 5 years. --Fauzan✆ talk✉ mail 09:26, 28 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.

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)
  • 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)
Oppose - Per Dodger67 and others, consult an English dictionary. I'll take an indeff over a 5-year sentence any day. Conditions are favorable for snow. ―Mandruss ☎ 08:25, 28 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.

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)
  • First off, this is a perrenial proposal, in fact here is it's entry at WP:PEREN:

===All authors must be notified of deletion===

  • Proposal: The first creator, or everybody who has contributed to an article, must be warned on their talk page of a deletion debate of that article.
  • Reasons for previous rejection: Excessive bureaucracy; people are expected to keep pages important to them on their watchlist. The "first creator" is meaningless for many articles, as this person may have long since left or made few contributions; "everybody" can number several hundred people, including those who have made trivial edits to the article and aren't concerned whether or not it's deleted. Regardless, editors are encouraged to notify the original author or the main contributors of an article when their article is nominated for deletion, as it is considered courteous; this is strictly optional. This puts less requirements for a deletion proposal than for a Featured Article review, for which all main contributors must be notified.
I for one do not wish to be notified when some artilcle i made on trivial edit to seven years ago is put up for deletion. If it's something I care about, it's already on my watchlist. this would be needless WP:CREEP that would just annoy people. If people actually want this the bot or whatever that does it shoudl absolutely operate strictly on an opt-in only basis. Beeblebrox (talk) 21:14, 28 February 2015 (UTC)

Delete "autochecked" usergroup

There is a clear consensus for this proposal. Mdann52 (talk · contribs) has filed a Phabricator request at Phab:T91934. Cunard (talk) 00:16, 3 April 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.

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}} (e • t • c) 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}} (e • t • c) 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}} (e • t • c) 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 and 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}} (e • t • c) 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)
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.


User Right: CSD Patroller

This would be a new right that allows experienced users with this right to delete pages with a CSD tag on them and to remove that CSD tag after a successful appeal. They would only be able to delete content that they have not tagged. CSD guidelines are very clear cut and do not need an admin knowledge to delete pages. This will not affect XFD.
This right would be granted at WP:RFR and I suggest that the minimum requirements are:

  • 3000 Edits
  • Good History
  • Knowledge of all CSD guidelines
  • Knowledge of what is and isn't vandalism.

If there is any doubt, the patroller should lave that case for an administrator to do. This right will greatly take the pressure of admins working in the CSD area. All deletions will be available for an administrator to undo. However, this situation shouldn;t happen regularly as all users should be trusted and knowledgeable. TheMagikCow (talk) 13:21, 28 February 2015 (UTC)

Support (CSD patroller)

  1. Support TheMagikCow (talk) 17:52, 28 February 2015 (UTC)
  2. Support, subject to this being technically feasible. I believe it should not require an administrator level of trust and judgement to make speedy deletion calls. WP:CSD are meant to be for pages which are so clearly inappropriate that discussion is a waste of time - there should never be a case where a speedy deletion is controversial. I imagine the level of qualification being similar to the bar for SPI clerks, perhaps with a similar training process. Ivanvector (talk) 15:36, 28 February 2015 (UTC)
  3. Support- but it must exclude A7 which is quite a vague guideline. It would also help if requests for this right required a week of discussion before approval or denial. I have always thought the way we do adminship with instant access to all tools is odd actually, considering most admins stick to doing one or two thing (some never leave AfD, or like hanging out at SPI) but this will def help reduce a few backlogs. EoRdE6(Come Talk to Me!) 15:46, 5 March 2015 (UTC)

Oppose (CSD patroller)

  1. Strong oppose Speedy deletion is not as clear-cut as everyone makes it sound. What is "unambiguous advertising"? What is a "claim of significance"? This takes good judgement before hitting the delete button. Also, since speedy deletion leaves so little record and involves so few people, this is the absolute last thing we should be giving to non-admins. I'd rather see such a user right for deletion discussions, where there is a lot of witnesses and a record of what happens. Read Wikipedia:Why I Hate Speedy Deleters before saying speedy deletion needs less oversight. Oiyarbepsy (talk) 17:21, 28 February 2015 (UTC)
  2. Oppose Incorect CSD taggings happen all day long, many of them by people who would easily qualify for this user right. It is also inadvisable to grant the right to delete to persons who would not have the ability to view deleted material. The WMF will not allow anyone to viewe deleted material unless they have gone through RFA or a similar community vetting process. Therefore there would be no way for them to review their own decisions. This could dramatically increase administrative backlog without any real benefit. CSD is not chronically backlogged, we don't need this, what we need is more actual admins. Beeblebrox (talk) 17:54, 28 February 2015 (UTC)
  3. Oppose Having worked with G11/A7 deletions, there are a high amount of borderline taggings that may or may not actually meet the criteria. I would not trust leaving this up to anyone with a high edit count. Users wishing to delete pages should go through the standard RFA process. Nakon 17:57, 28 February 2015 (UTC)
  4. Oppose Speedy deletion is an area as much sensitive as XFDs, if not more so, since there is much less opportunity for meaningful outside review of each deletion. Just saying that speedy deletions should be uncontroversial doesn't make it so. Speedies are rightly contested, denied or overturned on a regular basis. And since when did speedy deletion stop being an issue at RFA ?  Cenarium (talk) 18:17, 28 February 2015 (UTC)
  5. Oppose we get an awful lot of inaccurate speedy deletion tags, even from quite experienced editors, and most speedy deletions have little if any oversight. Hut 8.5 19:01, 28 February 2015 (UTC)
  6. Nope. No chronic backlog, so no need for more button-pushers. Recipe for newbie-biting. TenOfAllTrades(talk) 19:55, 28 February 2015 (UTC)
  7. Oppose: Despite the fact that a great amount of re-bundling of tools-sets needs to be done, this (while in good faith) does not seem to be a productive way to go about it. First, it's not technically feasible. Second, giving the delete right to users requires a nomination and voting style vetting system (similar to, but not necessarily RfX). Third, I can't see the number of people (and whom those people might be) requesting this usergroup having a greater positive result on the project overall than a negative one. — {{U|Technical 13}} (e • t • c) 20:31, 28 February 2015 (UTC)
  8. Oppose - Someone deletes a page + Admin disagrees and restores it = Disagreements and arguements and probably edit warring! - Basically It's more trouble than it's worth. –Davey2010Talk 20:58, 28 February 2015 (UTC)
  9. Oppose for the same reasons as the proposed "vandal fighter" user right. This could be very dangerous if put in the wrong hands, and adds more unnecessary bureaucracy. Critically inappropriate pages (BLP concerns, copyright, etc) are already deleted very swiftly, the rest may require near admin-knowledge of policy to decide on such a powerful action as deletion. — MusikAnimal talk 01:32, 1 March 2015 (UTC)
  10. Oppose Doesn't seem like it has been fully thought through. --Cgt (talk) 13:15, 1 March 2015 (UTC)
  11. Oppose - per most of the above. When I first saw this in my watchlist, I actually thought it was going to be a proposal to create a new user group that would restrict CSD tagging to experienced users. Mr.Z-man 17:59, 1 March 2015 (UTC)
  12. Oppose As to giving them the right to remove CSD tags, they have that already. Everyone not the article creator, or banned/blocked, has that right. (Equally, everyone also has the right to put them back...) If 'restoring' is meant by that, that would involve viewing deleted material. A lot of CSD is obvious - quite a lot isn't. They couldn't be allowed to delete under G4 for a start, as that requires the ability to view deleted pages. I too wondered about the right to tag being discussed - but then thought on. How could would-be patrollers get experience in order to be allowed to given the right to patrol? I've also wondered how they assess the trainee chefs in the preparation of fugu - how do the assessors know there's no poison in there? But CSD isn't like fugu. Death at CSD isn't the same as death in a restaurant. Articles are restorable. But who is going to check on the deleted articles? Who is going to assess the trainee patrollers and assign this right? I wouldn't trust it to individual admins, not even me... And if it goes to discussion, you're at RfA as near as dammit. It can't be an automatic right like auto-confirmed. Peridon (talk) 10:08, 4 March 2015 (UTC)
  13. Oppose The community has consistently rejected the idea of unpacking the admin tools. If anyone is considering becoming an admin, contact me for help. --Dweller (talk) 12:50, 4 March 2015 (UTC)
  14. Oppose. As I also said in the "vandal right" proposal, these rights are administrator rights that only a few very trusted users would be able to use, and would require nominations and !voting similar to an RfA or to License reviewer on Commons. This will cause too much unneeded work. Epic Genius (talk) 17:16, 4 March 2015 (UTC)
  15. Oppose I would support something like this if the admin toolset could be unbundled, and I think it would be good to do so (a vastly simplified RFA process would be one benefit), but that would require a lot of consensus and development work (and WMF funding) that will probably never happen. So unfortunately this is a non-starter. §FreeRangeFrogcroak 07:32, 5 March 2015 (UTC)

Discussion (CSD patroller)

  • I'd be fine with this, given that CSD are (in theory) black-and-white criteria. It should be clear whether pages meet the criteria or not, or CSD should be declined and they should go through some other process, thus it shouldn't take an admin to make these calls. I have some questions:
  1. Is it technically possible to implement a userright which has delete rights only for pages that are tagged a certain way?
  2. Would CSD Patrollers be able to view deleted content? Either only content they have access to delete, or all deleted content? How about oversighted content?
Yes I believe that it is possible.
No they would not be able to view deleted content or or oversighted content. TheMagikCow (talk) 14:08, 28 February 2015 (UTC)

Also just a comment: CSD Patrollers should only delete content which other users have tagged (no unilateral deletion) and of course there should be a log of all actions done by users with this userright. Ivanvector (talk) 13:55, 28 February 2015 (UTC)

Yes see above. TheMagikCow (talk) 14:08, 28 February 2015 (UTC)
  • I'd rather have such a "trusted" candidate go through RFA. The requirements you have stated above are more or less what a candidate a few years ago would need to have to run for RFA. In the long run, this is going to drastically increase the bar at RFA. ("You are only qualified for the CSD Patroller bit. Come back in a few months" kind of arguments.) If you trust someone, give them the sysop bit, I can't imagine "half trusted" and "fully trusted" users. --Fauzan✆ talk✉ mail 14:04, 28 February 2015 (UTC)
I do not think that this would raise that bar as many users that do RFA would have this right and users with less that 5000 edits rarely pass. nTheMagikCow (talk) 14:21, 28 February 2015 (UTC)
You are right about 5000 edits, but I think more people should run for RFA. This right would create an extra box to tick on the way, and is going to push RFA further out of reach than it's already now. Again, trusted users should get the complete thing. Deleting and blocking many times are enforced together, and a half done work will actually increase the workload on the admins. --Fauzan✆ talk✉ mail 14:45, 28 February 2015 (UTC)

This is just going to be voted down because of the admin standard for blocking and page deleting, but I would consider it useful. The only thing that I can see going wrong with it is if somebody deliberately goes rogue and decides to apply a tag on a sock account/IP and then be able to delete any page...Presidents, Dictators, media pages, etc. They only need to be quick too, so I don't think that would work. Tutelary (talk) 14:53, 28 February 2015 (UTC)

I believe that this will be accepted because the CSD criteria are clear cut. — Preceding unsigned comment added by TheMagikCow (talk • contribs) 14:57, 28 February 2015‎ (UTC)
Take a look at the talk page, Wikipedia talk:Criteria for speedy deletion and its archives. You will soon notice that CSD criteria are not as 'clear cut' as you think.  Cenarium (talk) 17:46, 1 March 2015 (UTC)
  • I can't imagine a scenario where the community would support a single admin being able to grant other users the ability to delete anything. I also think it is crazy to have the ability to delete but no the ability to view or restore deleted material. So every time one of these half-assed, not-vetted-by-the-community admins make a mistake, a real admin will have to come and clean upo after them. The idea that mistakes would be very rare is laughably ridiculous. Beeblebrox (talk) 18:02, 28 February 2015 (UTC)
The RFA criteria are very broad and some editors are very experienced but only in one topic TheMagikCow (talk) 18:11, 28 February 2015 (UTC)
I'm having trouble seeing how this response is a rebuttal to my remarks. I wold add that lately we seem to be deluged with proposals based on the idea that if you're good at one thing you should automatically be entitled to advanced permissions to do other things. It doesn't (and shouldn't) work like that. You should be able to show you would be good 'at the thing you are applying for. Look at me. I've been an admin since 2009. I've been on the oversight team since 2010. I was an arbitrator last year. And yet I was roundly rejected by the community when I put myself forward at WP:RFB. And they were right. I'm not suited for that job.. As a former arb I could have checkuser rights by default but I don't because I'm not very interested in technical tasks and therefore I don't think I'm well suited for that job either. Deletion is an administrative job. If you want to do it, run for adminship. CSD isn't really backlogged most of the time, it can wait a week while you run. Beeblebrox (talk) 21:27, 28 February 2015 (UTC)
  • Responding to a days-old comment: of course the speedy criteria are clear-cut; if not, they need to be revised, as there is no consensus for speedy deletion in questionable cases. The whole point of CSD is that very little judgement is required to determine pages need to be deleted. "Unambiguous advertising" means "Hey guys! Check out the website for my cool company AwesomeCo! (link)" - nobody would consider this acceptable. However, "AwesomeCo, established in 2014, is the seventh-largest[self-ref] provider of graphic design services in Cambridge, Nebraska. <Official website template>" - very very likely to be deleted through a discussion (how many graphic design firms would there be in a town of 1,063?) however it is not unambiguous advertising, and makes a credible claim of significance (the claim doesn't have to be one that meets WP:N, it just has to be claimed), so no editor should conclude that G11 or A7 deletion are appropriate. This proposal is obviously not going to pass, but if we're casting too wide a net for speedy deletion and applying it to cases that are not clear, we should address that. Ivanvector (talk) 15:57, 5 March 2015 (UTC)

Inspire Campaign: Improving diversity, improving content

This March, we’re organizing an Inspire Campaign to encourage and support new ideas for improving gender diversity on Wikimedia projects. Less than 20% of Wikimedia contributors are women, and many important topics are still missing in our content. We invite all Wikimedians to participate. If you have an idea that could help address this problem, please get involved today! The campaign runs until March 31.

All proposals are welcome - research projects, technical solutions, community organizing and outreach initiatives, or something completely new! Funding is available from the Wikimedia Foundation for projects that need financial support. Constructive, positive feedback on ideas is appreciated, and collaboration is encouraged - your skills and experience may help bring someone else’s project to life. Join us at the Inspire Campaign and help this project better represent the world’s knowledge! MediaWiki message delivery (talk) 19:22, 5 March 2015 (UTC)

Message sent by User:PEarley (WMF)@metawiki using the list at http://meta.wikimedia.org/w/index.php?title=User:PEarley_(WMF)/Inspire_Mass_Message_Manual/en&oldid=11468682

Automated welcome messages

Wikipedia has Category:Wikipedians in the Welcoming Committee and Category:Welcome templates. Those Wikipedians and those templates provide a useful service. I propose that Wikipedia also have automated welcome messages which appear on a user talk page immediately after a new account is registered. The registration process can end with a brief message directing the registrant to the welcome message by means of a link. The brief message might be "You have a welcome message on your talk page." The welcome message can have a set of useful links. After a predetermined number of edits, another message can appear on the user talk page, politely reminding the editor about those useful links.
—Wavelength (talk) 03:15, 1 March 2015 (UTC)

New editors should be greeted by humans. These humans should tailor their messages to the new editor's activities. A huge number of Wikipedia accounts never make an edit, and shouldn't get a welcome until they do. Oiyarbepsy (talk) 03:18, 1 March 2015 (UTC)
In that case, the first welcome message can appear immediately after the first edit. (Even if an account has never been used for editing, it still might be used for keeping a watchlist. Who can say how many accounts are or have been used only for keeping a watchlist? A welcome message might motivate editing.)
—Wavelength (talk) 06:05, 1 March 2015 (UTC)
Yeah, as per Oiyarbepsy I can't support this. I don't even get the point of the reminder message, either; generally if someone needs to be reminded of the stuff that appears in welcome templates, it's a warning sign of the editor's behaviour. // coldacid (talk|contrib) 05:06, 1 March 2015 (UTC)
  • Oppose - I know this is gonna sound dumb But IMHO it feels better to receive one from an actual person as opposed to a robot, They have automated welcomes on Commons and it feels odd compared to here, Good suggestion tho. –Davey2010Talk 05:30, 1 March 2015 (UTC)
  • Oppose - A significant number of newly registered accounts account for a significant amount of plain old vandalsim, attack, hoax, and general nonsense pages. The last thing we want is to welcome them and thank them for their edits (or the onles they ight be about to make) until we have a very good idea that their presence here is going to be constructive. Anyway, this discussion is an old perennial theme. The system is already sufficiently abused by users who have nothing better to do than racking up their edit counts by patrolling the new registrations and slapping welcomes on them. --Kudpung กุดผึ้ง (talk) 09:37, 1 March 2015 (UTC)
  • Comment - as Kudpung mentioned, this is a perennial proposal - see Wikipedia:Perennial proposals#Use a bot to welcome new users. DH85868993 (talk) 10:14, 1 March 2015 (UTC)
  • Support
    1. A welcome by a human is still a canned template, at least mine was. The only difference is in the username, and a new user is probably unable to determine that "Hi, I'm Civvix72" is coming from a human and "Hi, I'm WelcomeBot" is not.
    2. In any case, I've used websites from banks to newspapers to forums, and I've never needed an immediate welcome from a human to feel comfortable using the site. What I needed what easily accessible information about how to use it.
    3. I have no problem with welcoming someone before we know whether they are a vandal or a constructive user. I fail to see how pointing the vandal to information about how to participate increases the likelihood that they will vandalize. In some cases, and who knows how many, the welcome template may convert the potential vandal to a decent editor. If thanking them prematurely is an issue, fine. Don't thank them prematurely.
    4. I continue to reject the perennial proposal argument. The community is continuously being remade as people depart and join, and it's both illogical and unwise to assume that its judgment will not change over time. If one can point to a recent discussion, with a fair level of participation and resulting in a consensus, that's one thing; a list of things that can never be reconsidered because they have been tagged as "perennial" is quite another. ―Mandruss ☎ 10:40, 1 March 2015 (UTC)
Mandruss, a welcome by a human doesn't have to be a canned template, and it can be your canned template. Frequent welcomers, in my view, should be writing their own personal welcome messages from scratch that reflect their personality, unless they're a jerk. Oiyarbepsy (talk) 19:52, 3 March 2015 (UTC)
Thanx for the clarification. I wasn't sure on that point and almost omitted it. Points 2, 3, and 4 stand, and I think they're enough. ―Mandruss ☎ 13:33, 4 March 2015 (UTC)
Well, it sounds like your arguments might be better addressed by some kind of edit notice that appears for new users rather than a talk page message. Or, maybe an echo notification after 4 or 5 edits that points to five pillars or something. Oiyarbepsy (talk) 08:08, 5 March 2015 (UTC)
  • Comment I have a lot of thoughts and feelings on this. First, we have HostBot run by JMorgan. This bot posts welcome messages automatically with invitations to the Teahouse. The bot posts these invitations on behalf of a list of members (I'm on said list) so that new users can either go to the Teahouse, ask for help on the bot's talk page, or ask for help on a specific user's talk page. I think this is a great method, and I'm not sure I would want a new WelcomeBot competing with that. WP:ACC has also in the past had an automatic welcoming bot (opt-in by the account creators and currently offline for I'm unsure what reason). We'd have to get more details about that from @Stwalkerster and DeltaQuad: as I'm not sure quit who is in charge of it. Due to the fact that the ACC bot has been off-line, I created User:Technical 13/Scripts/ACC WikiLove to make it easy for me to pick the right welcome message to post on the talk page of a new user I created through that process. As a way to improve new user's getting welcomed on DDOwiki (A wiki dedicated to Dungeons and Dragons Online that I'm the top editor and steward of), I created http://ddowiki.com/page/MediaWiki:Welcomecreation that uses http://ddowiki.com/page/MediaWiki:Welcomecreation/preload in which new human user's post the welcome message to their own talk page as their first edit. This improves the chances that new human users will properly get a welcome message that gives a few details and points here or there so they can find help if they need it. I'm not going to say I flat out oppose the creation of WelcomeBot, but it would have to be very carefully coded to not interfere with current practices. — {{U|Technical 13}} (e • t • c) 14:17, 1 March 2015 (UTC)
    • It's horribly broken, since we never copied across a dependent library from the toolserver, and I've never found it particularly high on my list of things to fix, especially since the last two accounts it ran under only got the bot flag under a grandfathering clause. My intent was to rewrite it to use user's actual accounts to make the edit at some point, instead of faking their signature with a bot edit. Anyway, it's currently dead and somewhere near the bottom of a LONG list of things to fix. [stwalkerster|talk] 23:16, 1 March 2015 (UTC)
  • Oppose Per Kudpung. This would create lots of needless pages without fixing any actual problems. Beeblebrox (talk) 02:12, 2 March 2015 (UTC)
  • Oppose Probably politically incorrect to say this, but there ARE users I wouldn't want to waste time and space in welcoming. Spambots, very unorginally (deliberate spelling - if you don't get it ask me quietly) named and other obvious socks, User:Wikipediaisrunbyshitheads and similar (and worse...) people who are fairly obviously not here for any useful purpose, and so on. I've been welcomed automatically on other Wikipedias, and I can't say it did a lot for me. I never even got welcomed here, at least I can't remember one and didn't find one in my talk page history when I looked once, and it hasn't put me off here. Peridon (talk) 13:15, 4 March 2015 (UTC)
A well known sockpuppeteer who often uses Unorginal with a number as a name Peridon (talk) 14:05, 4 March 2015 (UTC)
Thank you. ―Mandruss ☎ 14:17, 4 March 2015 (UTC)

Replicate Wikibooks' Template:HoverImage in Wikipedia

Wikipedia needs an easy-to-use template equivalent to the HoverImage template in Wikibooks, for relatively non-technical Wikipedia and Commons users like me:

b:Template:HoverImage

The Commons library is becoming vast and Wikipedia's use of pictures continues to increase. A picture is worth a thousand words, and a well-done hoverable picture is worth even more.

-- WikiPedant (talk) 04:47, 2 March 2015 (UTC)

(NOTE: Posted before I discovered the "Requested Templates" page, and now posted there as well.)

wikibooks:Template:HoverImage has existed for five years but wikibooks:Special:WhatLinksHere/Template:HoverImage only shows a few uses. Wikipedia:Manual of Style/Accessibility#Text says: Do not use techniques that require interaction to provide information, such as tooltips or any other "hover" text. Abbreviations are exempt from these requirements, so the {{abbr}} template may be used to indicate the long form of a word. PrimeHunter (talk) 06:21, 2 March 2015 (UTC)
Hello PrimeHunter: (1) This is a slick template, but I'm not sure how many Wikibooks users would know about or be looking for this capability. As with all good things it would be unwise to use the template excessively, but I think it could at times come in very handy here in the big wiki. I already have the images ready for one specific usage. Just need the template. (2) In response to the quotation from the Manual of Style: That passage refers specifically to mouseover of text, and I agree that you should not have to put the cursor on text to get the full text. But HoverImage is not for text -- it is for images, where it can be used to valuable effect. -- WikiPedant (talk) 23:45, 2 March 2015 (UTC)

Ah, that b:Template:HoverImage functionality is similar to Help:Gadget-ImageAnnotator (This is an experimental installation of this feature for evaluation purposes. Users interested in trying out this feature can enable it, for the time being, by user script) ... See also info at commons:Help:Gadget-ImageAnnotator. --Atlasowa (talk) 12:28, 6 March 2015 (UTC)

Display of edit count and user rights in mobile diffs

Anybody who has edited through Wikipedia's mobile view would have noticed the way mobile diffs are displayed. I'm not aware if a similar proposal was made earlier or not.

  1. The editor's edit count is shown prominently at the bottom, encouraging editcountitis.
  2. Also displayed prominently are the user rights held by the editor. This promotes WP:Hat collecting. Those who edit mostly through mobile would be encouraged to collect user rights as they rightfully understand that these are prominently visible to other mobile editors.

In my view, the viewing of the edit count and user rights should be discontinued and replaced with quick links to talk page and contribs. It is not difficult to understand the motivations which might have led the devs to work it out that way. They must have felt that mobile editors won't be serious and thus showing them the edit count was a way of egging them on to continue making edits. That still doesn't justify the viewing of user rights, though. SD0001 (talk) 13:05, 2 March 2015 (UTC)

  1. Support as proposer. SD0001 (talk) 13:05, 2 March 2015 (UTC)
  2. Oppose I'll repeat my counter-argument, seeing what permissions a user has can be useful as you know you can come to them for help (e.g. a file mover or an admin). Editcountitus can be a good thing as it encourages editing, which we want, regardless of the motive. Finally, this software is shared with all wikis, so I don't know how happy WMF will be to have the devs make an exception just for enwiki. — MusikAnimal talk 18:04, 2 March 2015 (UTC)
  3. Neutral - I'm neither for nor against this as a matter of policy, but I think it would be better if user experience was consistent. Whether that means "consistent on all platforms when viewing en-wiki" or "consistent on this platform across all wikis" I'm not exactly sure. Ivanvector (talk) 23:30, 2 March 2015 (UTC)

Discussion (Mobile edit counts)

  1. The editor's edit count is shown prominently at the bottom, encouraging editcountitis.
  2. Also displayed prominently are the user rights held by the editor. This promotes WP:Hat collecting.

[citation needed]. --Izno (talk) 16:33, 2 March 2015 (UTC)

You can see it for yourself by clicking on the 'Mobile view' button at the bottom of the page, going to the page history and viewimg a diff. Anyway, I have added a screenshot of a Jimbo Wales edit that clearly proves this. SD0001 (talk) 16:57, 2 March 2015 (UTC)
Which only proves that that information is displayed, not that it causes either editcountitis or hat collecting in mobile editors. Please supply a source for those two currently unsupported universal assertions. --Izno (talk) 17:53, 2 March 2015 (UTC)

The counter argument: What permissions a user has can be useful as you know you can come to them for help, for instance a file mover or more prominently an admin. Editcountitus is not necessarily a bad thing. It can encourage more editing, which you could argue leads to recklessness, but in general more editing is encouraged regardless of the motive. — MusikAnimal talk 18:00, 2 March 2015 (UTC)

MusikAnimal raises a good point. Editcountitis could be useful motivation. But it would be beneficial to make links to talk page easier to access. Tony Tan98 · talk 21:39, 2 March 2015 (UTC)

I agree with MusikAnimal and Tony Tan. They make great points. Users would be able to know their user rights by viewing them. Sam.gov (talk) 22:21, 2 March 2015 (UTC)

  • Have you tried editing on mobile ? It's so frustrating, if you ask me a little editcountis won't hurt... Anyway, i'd rather see WMF keeping to experiment with this. We could however ask them to do a bit more design research, metrics and reporting to the community on conclusions drawn from that, as MMV and VE have been doing the past half year. Regardless, I don't trust our in crowd to make decisions for the 'out' crowd in the manner as above. The WMF is slow and has made many mistakes in the past, but I trust them more then I trust ourselves to improve workflows for the long term. We are an overly invested bunch, we have the ideals of hippies, with terrible design skills, worse programming skills, the memory of a fish in a bowl, the patience of a 3 year old and the attention span of a young adult. We should not be the doctor, we are the freaking patient. —TheDJ (talk • contribs) 22:27, 2 March 2015 (UTC)
Comments not relevant to the proposal collapsed
::@TheDJ: I can't even remember editing on mobile. If I did, it was very rare, and they way differences/changes are displayed is confusing to me. It should say differences and prevs are displayed in "so and so" color. I might experiment on the mobile platform myself and draw my conclusions from there. Sam.gov (talk) 20:46, 4 March 2015 (UTC)
@TheDJ: I'm Still experimenting with the mobile web platform. But after comparing some changes and compared the desktop with the mobile web platform, I can tell you that the stuff highlighted in green denotes the changed version as it currently exists compared to the previous stuff highlighted in red. Sam.gov (talk) 23:01, 6 March 2015 (UTC)
What's the confusion? Wikitext highlighted in green is the added text. Wikitext highlighted in red is the removed text. But these are hardly relevant to this discussion. SD0001 (talk) 11:03, 7 March 2015 (UTC)

A new WikiScanner that uses a database of publicly available IP addresses of military/secret service/government/corporate facilities

There's been WikiScanner before but apparently it shut down for some reason and the successor WikiWatchdog only shows edits for user-specified IP-addresses.

I think it would be time for a new WikiScanner - or an extension of WikiWatchdog to make use of publicly available IP-addresses of various relevant institutions/organizations.

And additionally it might be useful if one could truly subscribe to various of these IP-ranges to have them in a single stream/watchlist.

If this suggestion is only viable as an improvement to WikiWatchdog I'd like to know if there is a way to contact the developers on Wikipedia.

--Fixuture (talk) 18:54, 8 March 2015 (UTC)

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. Sam.gov (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. Sam.gov (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)
Excellent! I support always showing the top box, it will be a good ongoing reminder to the user of what the base userpage is for. Thank you for the help. I lied and actually have one last concern, that's whether we should update Template:Userspace draft or create a new one for the purposes of this editnotice. I can only guess there won't be much for objections on updating the existing one, but I've asked for input on the talk page. — MusikAnimal talk 01:52, 1 March 2015 (UTC)
I don't see the entire planned workflow here. I know we can put the userpagenotice in an edit notice, but I don't see how the "Userspace draft move" gets put into the draft they write. I've also restored and improved the BEANS defusal I had put in earlier--the move link does not work when the template is viewed directly, but does work when the template is transcluded. (I've put a demo in the sandbox--the link is correct there.) Pathore (talk) 02:36, 1 March 2015 (UTC)
The workflow is (1) user goes to create a draft on their userpage (2) notices the editnotice, and clicks the link bringing them to Help:Userspace draft (3) uses the form to create the draft. So the latter is what puts Template:Userspace draft in place. As for the "move" link, I've given it more thought and perhaps it's best we wait and see if the added load on AfC will be a problem. One could argue the link should still be added just so that new users know it is an option, and to prevent copy-and-paste moves, but for the purposes of this editnotice I think we can move forward without it. A separate template also seems less than ideal, so ditching that idea. So... I am ready to move forward this barring any objections. This seems to be uncontroversial, and should have a noticeable impact on where new users put their drafts. Filter 499 is hidden from public view but I and other edit filter managers will hopefully be able to attest to the efficacy of this editnotice. We may later look into putting the draft creation form (as seen at Help:Userspace draft) into the editnotice itself, but let's so how we do without it first. — MusikAnimal talk 02:47, 1 March 2015 (UTC)
In my understanding, the main issue with copy-and-paste moves is that the history (which provides attribution) does not get transferred. But userspace drafts would be expected to only have one author, who would also be the person doing the copy-and-paste move, so attribution is maintained in this case. On the other hand, the sudden appearance of a compete page in mainspace is one of the warning signs for a copyvio, so a copy-and-paste move could lead to newbie-biting. How about a link to WP:MOVE instead of "two-clicks-to-mainspace"? Pathore (talk) 03:08, 1 March 2015 (UTC)
The drafts, despite being in the userspace, are often worked on collaboratively. You could argue either way, but the inclusion of the move link was more about lessening the load on the AfC team, but I've decided we should wait and see if that's really going to be a problem. Submitting to AfC will ensure a user-friendly process and is indeed less bitey than what the new page patrollers will throw at them, so if think in general AfC is preferred. If we want to discuss including the move link for other means we should discuss on the template talk page. — MusikAnimal talk 16:55, 1 March 2015 (UTC)

Ok, we have one more problem (I keep saying that, so maybe not the only one). I realized the copy "this is your userpage" will be inaccurate when editing someone else's userpage. I would imagine the user could figure that much out, but perhaps it's better to reword with something like "this is Example's userpage". I've made this change at the template's new home at at {{base userpage editnotice}}. How does that sound? — MusikAnimal talk 17:36, 1 March 2015 (UTC)

You're right, but using third-person pronouns in English opens a can of worms from the perpetually-oppressed crowd. I've tweaked it a bit more to honor the "he edits Wikipedia/she edits Wikipedia/(unspecified)" switch in Preferences. Singular they is dubiously encyclopedic (which isn't that big of a problem in userspace) and grammatically plural (which could give the wrong idea about WP:ROLE, suggesting that an account may reflect multiple users). This latter issue is a problem, since it could be wikilawyered into a misrepresentation of policy.
Following every reliable style guide I've ever seen, I've put in "himself/herself/himself" (generic he) which is standard English. I suspect that this will open a can of worms; perhaps simply deleting the entire phrase that requires a reflexive pronoun (reducing that sentence to "This is Example's user page.") might be a good idea. It would be possible to make this deletion apply only in the "(unspecified)" case. Pathore (talk) 01:08, 3 March 2015 (UTC)
Agree with you on almost all counts. Most people don't specify their gender, so I can foresee the "himself" becoming a problem, despite it being standard English. Going off of WP:UP, what if we had it say "This is Example's userpage, which is for limited autobiographical and personal content"? — MusikAnimal talk 17:48, 3 March 2015 (UTC)
Quoting policy sounds like a good idea. We'll have to see how well it works in practice. Pathore (talk) 23:34, 3 March 2015 (UTC)

Implemented

 Done Editnotice is live and {{base userpage editnotice}} fully protected due to high visibility. I'll keep an eye on the relevant edit filters to see what kind of difference the editnotice makes. Thanks for all of your help. — MusikAnimal talk 16:09, 4 March 2015 (UTC)

One last detail: you've forgotten to mark the template with WP:REDLOCK. Pathore (talk) 22:36, 4 March 2015 (UTC)

Started some documentation at Wikipedia:Editnotice#User and user talk. --  Gadget850 talk 10:47, 5 March 2015 (UTC)

I'm not sure if this has been mention because this thread is quite long to read but we really should direct users to create drafts in the Draft: namespace as is preferred for drafts to allow collaborative editing and prevent multiple drafts of the same subject. Most AfC reviewers including mmyself move drafts to the draft namespace before I do anything else with them. EoRdE6(Come Talk to Me!) 16:22, 5 March 2015 (UTC)

I'm okay with this, especially if the AfC team is in favour of it. However we need to somehow make it work with a form, like the one you see at Help:Userspace draft. The idea is make things simple and easy to understand, to persuade against misusing the user page. Perhaps create the help page Help:Draft to be the draft-space equivalent of Help:Userspace draft. — MusikAnimal talk 17:00, 5 March 2015 (UTC)
To further clarify, the users who are targeted by this editnotice usually already have the content they want to put in, and are ready to hit save, and are not swayed by notices that the subject need to be notable, have good sources, etc. That being said something like the article wizard may be too much, and they'll just continue on with the userpage. Personally I think the article wizard could be dumbed down a bit anyway, but that's for a different discussion. Do you think the aforementioned Help:Draft approach will suffice? — MusikAnimal talk 17:06, 5 March 2015 (UTC)
@MusikAnimal: Is this supposed to appear on all userpages? I've noticed it has appeared on mine with a glitch and a bunch of random numbers and curly brackets. "{{#ifeq:1354143||" has appeared. EoRdE6(Come Talk to Me!) 19:29, 5 March 2015 (UTC)
I believe MSGJ was justifiably trying to move some logic to another template but apparently it broke in the process. Probably a missing curly brace or something? Moving forward, while the crazy Template:Editnotices/Namespace thing isn't set up on testwiki, you could accurately simulate the scenario with the combination of testwiki:Template:Userpagenotice, testwiki:MediaWiki:Editnotice-2 and another template or two. — MusikAnimal talk 19:58, 5 March 2015 (UTC)
I think I know exactly why the refactoring broke--there are two conditions in that template, one which supresses display of the entire template and one which only controls the "make a userspace draft" message. The refactoring attempt removed the end markers for both of the conditions, but only removed the first condition. I've fixed it in the template's sandbox, if MSGJ wants to give it another try. Pathore (talk) 22:33, 5 March 2015 (UTC)

Could an id be added so that it can be hidden ? Thanks,  Cenarium (talk) 22:00, 5 March 2015 (UTC)

@Cenarium: I just wrapped it in a div with id editnotice-base-userpage since apparently there's no support for an id parameter on {{ombox}} and {{message box}} (even though it says there is for the latter). — MusikAnimal talk 22:19, 5 March 2015 (UTC)
Is div better than a span? (I've enquired at Module talk:Message box about using an id with ombox.) — Martin (MSGJ · talk) 10:23, 6 March 2015 (UTC)
@MSGJ: From a web-development standpoint, I'd say a div is better as it is for block elements (on it's own line), where span is for inline elements. — MusikAnimal talk 16:49, 6 March 2015 (UTC)
@MSGJ: The current version actually produces broken HTML--two elements are assigned the same ID but IDs are required to be unique throughout a document. This edit should be reverted. Pathore (talk) 23:09, 6 March 2015 (UTC)

The editnotice even shows up on User:Sandbox, which makes it misleading as the sandbox is NOT meant for "limited autobiographical and personal content." Any way to hide it from that specific page? SD0001 (talk) 10:21, 6 March 2015 (UTC)

Could do, but why are we using User:Sandbox rather than Wikipedia:Sandbox? — Martin (MSGJ · talk) 10:24, 6 March 2015 (UTC)
Well, it is used by unregistered users to test out the VisualEditor. SD0001 (talk) 11:59, 6 March 2015 (UTC)

Alternative (Userpage Editnotice)

When creating a new user page, there are now 3 message boxes which appear. These could be a little overwhelming, and perhaps new users will not read them all.

  1. Wikipedia does not have a user page with this exact title. In general, this page should be created and edited by User:xyz produced by Template:No article text
  2. Hello and welcome to Wikipedia! This is xyz's user page, which is a place for limited autobiographical and personal content. created as a result of this discussion. Perhaps this one can be suppressed when the user page does not exist?
  3. If you want to draft an article, please create a userspace draft instead of creating it here. created as a result of this discussion. Could this be combined with the first message somehow?

What do people think? — Martin (MSGJ · talk) 12:37, 6 March 2015 (UTC)

Well, for starters, I had no idea #1 was a manageable part of the interface (is there anything admins can't do?) We need to merge both #2 and #3 in with it, and adjust copy accordingly. We're using magic words and parser functions to ensure messages are only shown on the base userpage, sounds like that logic already exist in {{no article text}}. As for #2, it was decided that we'd always show it, just sort of as an ongoing reminder of what userpages are for. It can easily be shown only when creating the userpage as we do with #3. Finally, any experienced user can hide these messages by adding #editnotice-base-userpage { display:none !important} to their common.css. — MusikAnimal talk 16:14, 6 March 2015 (UTC)
I say combine #1 and #2 and have it read something like "Hello and welcome to Wikipedia! This is Example's user page, which is a place for limited autobiographical and personal content.
In general, this page should be created and edited by User:Example." I don't think we need to say how to edit, they will likely figure that out if they have found the Edit button, but that's my opinion.
It seems logical to always show the combined #1-#2 message when editing a base userpage, based on my own observations. You have userpages that are semi-autobiographical, the user abandons the project, and years later you'll have IPs or new users editing it thinking it's an article (presumably found the page through a search engine since user pages are indexed). — MusikAnimal talk 16:25, 6 March 2015 (UTC)
Template:No article text is transcluded by MediaWiki:Noarticletext, which is the interface message displayed when creating a page. Moving message #3 to Template:No article text would probably be a good idea. Message #2 can either remain an edit notice as a reminder of the proper use of user pages or be discarded in its entirety. Combining #1 and #2 could be appropriate for creating a user page, but telling experienced users "Hello and welcome to Wikipedia!" every time they edit their user pages sounds a little silly to me, so I propose reducing #2 to "This is ... personal content." Pathore (talk) 23:28, 6 March 2015 (UTC)

A concrete alternative proposal (userpage editnotice)

The messages displayed (from Template:No article text) when creating a base user page should be:

  1. Hello and welcome to Wikipedia! Wikipedia does not have a user page with this exact title. In general, this page should be created and edited by User:xyz and is a place for limited autobiographical and personal content. as a system-type fmbox.
  2. If you want to draft an article, please create a userspace draft instead of creating it here. as a content-type ombox.

The message displayed (from an edit notice transcluding Template:Base userpage editnotice) when subsequently editing a base user page should be:

  1. This is Example's user page, which is a place for limited autobiographical and personal content. as a notice-type ombox.

I propose "content" rather than "warning" because I see article-on-user-page as more of a content issue than a "STOP IMMEDIATELY!" type of issue. I propose {{ombox}} rather than {{fmbox}} because I think omboxes look better and are more intended for this use. In the case of creating a page, having our current message as an fmbox and the "userspace draft" notice as an ombox should help the latter to stand out. Pathore (talk) 23:48, 6 March 2015 (UTC)

I don;t want to sound dumb, but can I regular old editor remove these bloody things or nah? I already have a nice editnotice and this along with the PP note makes it messy. I notice MusikAnimal doesn't have it on his UP, but that could be a special admin thing or the full protect notice taking over... Anyone know? Thanks in advance! EoRdE6(Come Talk to Me!) 04:21, 7 March 2015 (UTC)
The new messages are being added as a namespace notice. Those are not displayed when viewing the source of a protected page. I've looked at the code and I think wrapping the transclusion of {{base userpage editnotice}} in Template:Editnotices/Namespace/User with #ifexist to make {{#ifexist:{{PAGENAME}}/Editnotice||{{base userpage editnotice}}}} should prevent the new editnotice from being shown if a page editnotice is defined.
Looking at this a bit more, I suspect that making this a namespace editnotice was probably a bad idea, and I have made an edit in the {{editnotice load}} sandbox proposing integrating this there. Pathore (talk) 06:26, 7 March 2015 (UTC)

If possible, I think the editnotice should not be displayed while editing the user pages of others. This solves many problems at once: (i) we would be able to user the original wording - "your", which is better, (ii) we won't see it while editing User:Sandbox, User:Example and other such pages, and (iii) no one will see it while trying to create the user page of an inexistent user. SD0001 (talk) 13:45, 7 March 2015 (UTC)

At one time, we had that capability, but the particular use of {{REVISIONUSER}} that it relied on was determined to be a bug. Template:Editnotice load still has the "ownuserpage" logic, but it doesn't do anything now. Pathore (talk) 01:18, 8 March 2015 (UTC)

@MusikAnimal: The top part of the editnotice poses more problems than it solves.

  1. New users have been proven to be poor at understanding instructions. The overly brief wording can easily lead to misunderstandings. They might fall under the impression that they are supposed to provide some amount of autobiographical information.
  2. Only autobiographical and personal content? Is the user page not a place where one exhibits their contributions, keeps a list of articles they have created, or are working on?
  3. The decision that the top part of the editnotice would be visible to all users appears to have been taken between MusikAnimal and another editor. This is unacceptable; you need to have community consensus. There are many experienced editors who may not be knowing or willing to use the CSS to exclude themselves from seeing it. Also, we offer considerable leeway when it comes to user pages. If someone wants to give away excess of personal information, we don't have to stop them. SD0001 (talk) 13:45, 7 March 2015 (UTC)

I'm in favour of all the aforementioned. SD0001, I have removed the top part. I agree it is not well suited in it's current form, and also the copy clearly needs to be tweaked to be more accurate. We probably don't need to say what can be on the userpage, but more so what can't, as that's the entire reason behind the edit notice to begin with. That is, to prevent misuse of the userpage as a place for drafting articles, which happens far too often.

So for now, let's leave {{base userpage editnotice}} without the top part, and brainstorm combining Pathore's proposed changes with some better copy – bearing in mind the intent behind the editnotice. I will point out however that brevity is sort of the idea here, if the message is too long they won't read it. Thanks — MusikAnimal talk 19:47, 9 March 2015 (UTC)

Now that I've seen more of how editnotices are set up on Wikipedia, I'm unsure if an editnotice is really the right way to do this at all. We currently have a bit of logic in {{base userpage editnotice}} to ensure that the "userspace draft" text only appears when creating a page, but I now think that we should put the message in {{No article text}} instead, since that entire template is only used when creating a page. The {{base userpage editnotice}} can then be reused as a default user page editnotice that can be overridden per-user by creating User:Example/Editnotice. This latter detail is my proposed change to {{editnotice load}}. Thoughts? Pathore (talk) 20:44, 9 March 2015 (UTC)

Display a list with the titles of articles that were deleted unless there is something illegal with their title

Proposal: Display a list with the titles of articles that were deleted unless there is something illegal with their title.

And also their previous titles, because you know, a person can change the title and then delete the article.

This is to improve transparency and could help people to ask undeleting articles because they know the articles existed.

You know, the important organizations that have much money could decide that deletion is a good way to get rid of inconvenient material for them. How could they do it? Creating a new article that doesn't have the inconvenient material and then deleting the old article, both with the same or similar titles. This proposal is a way of putting the power in normal people. Abcdudtc (talk) 08:08, 28 February 2015 (UTC)

Special:Log/delete. Anyone can read the deletion log, always could. Knock yourself out. Of course we delete hundreds of articles per day, so I'm not sure how practical it is to go through it. A list of all titles ever deleted would run over a million. Dragons flight (talk) 08:23, 28 February 2015 (UTC)
That's good but it says "Below is a list of recent deletions and restorations.". It seems that "recent" means since December 2004, well, that's not bad, but it would be better to have that information for all time. Abcdudtc (talk) 08:45, 28 February 2015 (UTC) And also it doesn't show the previous titles of the article, a person can change the title and then delete the article. Abcdudtc (talk) 08:51, 28 February 2015 (UTC) One more thing: How can you search in the Deletion Log for the articles that begin with some word or that contain some word inside the title? Abcdudtc (talk) 08:59, 28 February 2015 (UTC)
@Abcdudtc:Go to the link provided, and use the search options that appear above the list. Your log might be set to show oldest deletions first for some reason, but this can be fixed in the options above. Oiyarbepsy (talk) 17:33, 28 February 2015 (UTC)
I saw Special:Log/delete. Can you search for all deleted articles that have a word in their title, for example, the word "Drug" like in "Drug X" or "Natural drugs"? I mean like this: Wildcard_character#Computing. Abcdudtc (talk) 13:06, 1 March 2015 (UTC)
Pages can only be deleted by administrators who should follow Wikipedia:Deletion policy. Administrators can see a list of deleted pagenames at Special:Undelete. They can choose a prefix and get an alphabetical list of names starting with that prefix. Administrators can also see the contents of deleted pages (including the page history) and decide whether to undelete them. PrimeHunter (talk) 17:48, 28 February 2015 (UTC)
And anticipating a possible follow-up proposal, see Wikipedia:Perennial proposals#Deleted pages should be visible. PrimeHunter (talk) 17:51, 28 February 2015 (UTC)
I read that Wikipedia:Perennial proposals#Deleted pages should be visible but this is different, this is to display ONLY the title and the previous titles that article had. Its contents will remain not be visible by anyone, as it is now. Abcdudtc (talk) 13:20, 1 March 2015 (UTC)
There should be some way to combine Special:Log/delete and Special:Log/move, unless pages that are subsequently deleted are removed from the move log. Pathore (talk) 01:16, 3 March 2015 (UTC)
But I imagine that neither Special:Log/delete nor Special:Log/move allow you to search for all deleted/moved articles that have a word in their title, for example, the word "Drug" like in "Drug X" or "Natural drugs"? I mean like this: Wildcard_character#Computing. Am I right? Should we submit a request about this for a software change in Phabricator? Abcdudtc (talk) 13:11, 5 March 2015 (UTC)
Yes, the basic log interface doesn't support wildcard searches, so you would need to know what you are looking for. However, the entire log is available for download [3] (select the Wikipedia project of choice, and then the "logging" file), so you can do your own searches using whatever software you want. Yes, the interface might be improved, but I wouldn't expect such a request to draw much attention from developers any time soon. Dragons flight (talk) 23:49, 6 March 2015 (UTC)

What we could use is an external tool (similar to https://tools.wmflabs.org/grep/?lang=en&wiki=wikipedia&ns=0 ), just for log searches. עוד מישהו Od Mishehu 07:50, 11 March 2015 (UTC)

Initially disable 'save page' button on edit

While the consensus is against the exclusion of the 'save page' button by default and on an opt-out basis, there is clear consensus that the button be disabled or removed until the page is previewed, if (and only if) this is implemented on an opt-in basis, in the form of a user preference, gadget or user script. SD0001 (talk) 20:56, 21 March 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 have corrected messages where I couldn't believe someone had (unwittingly) made a destructive change, but didn't correct it. I think by forcing an editor to preview page first would get rid of a lot of stupid errors (which mostly comprise insertion of <ref></ref> pair(s). A further refinement would be to keep 'save' disabled until preview returns error-free. (This might require additional coding somewhere to pass an error flag.) -- Unbuttered parsnip (talk) mytime= Tue 10:43, wikitime= 02:43, 3 March 2015 (UTC)

  • Oppose Errors can easily be fixed by any other editor. Disabling "save" until a preview doesn't produce a markup error is even more BITEey and discouraging to new editors who may not be familiar with wikimarkup. Pathore (talk) 02:52, 3 March 2015 (UTC)
  • Comment It would entirely depend on how this was implemented. I've been on other wikis that do this, and personally think it is a great idea if done right. On the other hand if done wrong it simply provides another hurdle for people with difficulties editing and those on mobile/tablets/touch devices. — {{U|Technical 13}} (e • t • c) 12:56, 3 March 2015 (UTC)
  • Strong Oppose Would obstruct and slow down thousands of good edits for the benefit of occasionally preventing the odd mistake. Besides, who's going to force these editors to look at the preview properly? --Dweller (talk) 13:01, 3 March 2015 (UTC)
  • Oppose this specific implementation - provides another hoop for new users to jump through; contrary to "anyone can edit". Perhaps instead of this, code similar to ClueBot could check non-confirmed editors' submissions when clicking save and determine if there are issues which would benefit from directing to a preview instead. My gut says this would add a lot of server load but I really don't know what I'm talking about here. Ivanvector (talk) 16:47, 3 March 2015 (UTC)
  • Oppose I have seen this implemented on other wikis. It is annoying and gets in the way, people still manage to break things. Mistakes are easy to fix. Chillum 16:53, 3 March 2015 (UTC)
  • Oppose for all users, but if some people think this would help them maybe someone could write a script for it. KonveyorBelt 17:33, 3 March 2015 (UTC)
  • Oppose for everyone - Admittingly this does sound a good idea but If I had to preview every single edit first I would slowly lose the will to live.... In all i'd say this would be more bad than good but that's my 2¢ on it. –Davey2010Talk 17:54, 3 March 2015 (UTC)
  • Oppose as a requirement, or even as a default that can be turned off, as too much of an impediment to editors who don't need it, but I wouldn't at all mind seeing this as a widget that can be turned on just like the "hey, you didn't leave an edit summary" widget. (Or maybe it already exists and I don't know it.) — TransporterMan (TALK) 15:43, 4 March 2015 (UTC)
    Yes it exists, check "Prompt me when entering a blank edit summary" in Special:Preferences#mw-prefsection-editing --Fauzan✆ talk✉ mail 12:33, 5 March 2015 (UTC)
    • That wasn't what TIM asked for, he wants a "Require preview before save" option, he knows the "Prompt me when entering a blank edit summary" option already exists. — {{U|Technical 13}} (e • t • c) 16:18, 5 March 2015 (UTC)
  • Support as user preference - If a user knows they're error-prone, they could check a box in preferences that wouldn't let them save until after preview. However, this check box should be default off. Oiyarbepsy (talk) 20:39, 6 March 2015 (UTC)
  • Support as user preference with "off" as the default. I'd use it! Bishonen | talk 13:51, 7 March 2015 (UTC).
  • Support as user preference per above, it would stop me from arrogantly ignoring the fact that one should always preview (especially before a.m. coffee) and typing "perference" and "perview" like I almost did just now. We have this for edit summaries and I have it "on" all the time. For me, since the reminder would be annoying, it would encourage good editing habits, i.e. "preview before you save". Valfontis (talk) 20:31, 7 March 2015 (UTC)
  • Oppose, this would be BITE-y and can be added as a gadget should any editor wish to use it. Nakon 04:54, 8 March 2015 (UTC)
  • Oppose People would just ignore the preview and click save without checking it anyway. Also, it would be terribly annoying. --Cgt (talk) 18:49, 8 March 2015 (UTC)
  • Support as opt-in preference - we can't force users to actually stop and look at the preview; it would interfere with automated and semi-automated tasks which handle editing; slow down editing even if it's unnecessary (such as a revert, or removing a CfD tag); and be very BITEy. עוד מישהו Od Mishehu 10:37, 10 March 2015 (UTC)
  • Support as opt-in preference It would slow down more experienced editors or editors making small or simple changes. However, allowing editors to opt into it, like with the edit summary notification, would help any editors that want to be sure they remember to preview before posting. It might be a better idea to have it as an opt-in notification than opt-in disable save before preview since there is no need to preview a small change on a big page and some potential users could be turned away by that. PhantomTech (talk) 05:34, 11 March 2015 (UTC)
  • Support as opt-in preference This could be helpful. Tony Tan98 · talk 09:28, 11 March 2015 (UTC)
  • Support strictly opt-in. I know I personally would not use it, and it would definitely be bitey to newcomers and save only a small amount of time correcting errors, though I do see a number of experienced editors say that they'd use it themselves so I'd be fine with it allowed strictly opt-in. --L235 (t / c / ping in reply) 19:53, 11 March 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.

Messages presented to unregistered users

I was wondering whether the banner message that is given to unregistered users when they go to an edit page might be beefed up perhaps with a recommendation or a stated preference that editors work from accounts.

here is the current message:

You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to a user name, among other benefits.

I have just added a reference to this text at Wikipedia:User access levels#Unregistered users which is also accessed through the shortcut WP:IP. I was wondering if it would be appropriate to present this in the form in which it is presented to "unregistered users" with the beige background and the key image.

Also, is "unregistered user" the most appropriate description? Some users may be registered but, either by intent or otherwise, they may have failed to log in. GregKaye 09:48, 11 March 2015 (UTC)

The current message is:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to a username, among other benefits.
I updated that UAL page to include the actual message (so if it changes the page is still current). Not exactly sure what you want to change, is it just what we "Call" IP users? They are also sometimes referred to as "IP Users" (where some users don't really now what this means) and "anonymous users" (although this actually makes them much LESS anonymous). — xaosflux Talk 17:16, 11 March 2015 (UTC)
I thik that "anonymous users" is probably th best - at the time, the user is being anonymous. Yes, his/her IP address is being recorded, but very few IPs are privately owned in the long term. עוד מישהו Od Mishehu 20:43, 11 March 2015 (UTC)
Calling IP users anonymous could lead to a false sense of security. Like xaosflux said, IP users are less anonymous than ones who use accounts if for no other reason than IPs can be geolocated. Making users think IPs are more anonymous could discourage people from using accounts. I don't see a problem with calling IP users unregistered, even if they are just not logged in, they will understand what it means. If anything, you could just say they are "editing as an unregistered user" which, if they're not logged in, is true. PhantomTech (talk) 20:58, 11 March 2015 (UTC)

Thank you all esp: xaosflux. could a text be added such as "... and other editors may appreciate working with you by a name and not a number." Alternatively a search available username facility may add emphasis. Are there any other rationales that might be presented to show arguments for logging in. GregKaye 12:02, 12 March 2015 (UTC)

@GregKaye: We can change it to most anything, please propose any changes at: MediaWiki_talk:Anoneditwarning using {{Edit protected}}. — xaosflux Talk 16:49, 12 March 2015 (UTC)

2015 CheckUser and Oversight appointments: Final chance to comment on candidates

The Arbitration Committee is seeking to appoint additional users to the CheckUser and Oversight teams, and the community comments phase of the process is approaching conclusion.

Interested parties are invited to review the appointments page containing the nomination statements supplied by the candidates and their answers to a few standard questions. Community members may also pose additional questions and submit comments about the candidates on the individual nomination subpages or privately via email to arbcom-en-c@lists.wikimedia.org.

Those who have not commented yet, are encouraged to do so over the next few days.

Following the consultation phase, the committee will take into account the answers provided by the candidates to the questions and the comments offered by the community (both publicly and privately) along with all other relevant factors before making a final decision regarding appointments.

The consultation phase is scheduled to end 23:59, 18 March (UTC), and the appointments are scheduled to be announced by 31 March 2015.

For the Arbitration Committee, Courcelles (talk) 07:26, 13 March 2015 (UTC)

Venue?

Already asked at Wikipedia talk:In the news but I didn't realise that was a low-traffic page when I posted.

Is this the correct venue to put forward a proposal that would affect articles appearing in the ITN section of the main page, but only whilst they appear in ITN? Mjroots (talk) 08:56, 12 March 2015 (UTC)

Just ask the question, rather than the metaquestion of where you should ask the question. Asking the metaquestion wastes time. If it were the wrong venue, people would tell you. You didn't actually ask the question you wanted to ask at WT:ITN either, which is probably why no one was interested in answering it. Put forth the actual proposal (here, there, anywhere) and see if people are interested. But the question of where to ask a question isn't going to generate as much interest as the actual question itself. --Jayron32 13:05, 16 March 2015 (UTC)
@Jayron32: OK, will do. I suppose here is as good a place as anywhere. Mjroots (talk) 20:39, 16 March 2015 (UTC)

2015 CheckUser and Oversight appointments: Invitation to comment on candidates

The Arbitration Committee is seeking to appoint additional users to the CheckUser and Oversight teams, and is now seeking comments from the community regarding the candidates who have volunteered for this role.

Interested parties are invited to review the appointments page containing the nomination statements supplied by the candidates and their answers to a few standard questions. Community members may also pose additional questions and submit comments about the candidates on the individual nomination pages or privately via email to arbcom-en-c@lists.wikimedia.org.

Following the consultation phase, the committee will take into account the answers provided by the candidates to the questions and the comments offered by the community (both publicly and privately) along with all other relevant factors before making a final decision regarding appointments.

The consultation phase is scheduled to end 23:59, 18 March 2015 (UTC), and the appointments are scheduled to be announced by 31 March 2015.

For the Arbitration Committee, Courcelles (talk) 06:25, 4 March 2015 (UTC)

Discuss this
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_119&oldid=1142561032"