Wikipedia:Village pump (proposals)/Archive 119

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)

• I also find it puzzling why anyone would perceive a simple mistake being corrected as implying an assumption of bad faith.
  talk
  ) 20:46, 13 February 2015 (UTC)

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

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

which is closer to usual sigs, but makes the action clear and retains the link to

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.

talk

) 23:13, 15 February 2015 (UTC)

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)

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)

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

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

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)

• All right, pinging participants of the previous discussion about pages expanded from redirects. @Swpb, Technical 13, Oiyarbepsy, MusikAnimal, This, that and the other, Nyttend, and James500:@Ironholds, Andrew Davidson, PaleAqua, Od Mishehu, DGG, BethNaught, and WhatamIdoing: Does this look like an acceptable implementation for this idea ? If a bot or edit filter tags these edits, they'll be patrollable from recent changes simply by filtering for the tag 'unredirects'. Cenarium (talk) 21:14, 20 February 2015 (UTC)
• Sounds good, but I'll leave this one to smarter people than me. Oiyarbepsy (talk) 22:24, 20 February 2015 (UTC)
• I'm not sure it would be a sufficient solution to this problem, but it would certainly be a good start. I can not immediately think of any downside,so if it's easy enough to do, let's try it. DGG ( talk ) 23:48, 20 February 2015 (UTC)
• I'd prefer for these 'unredirects' to appear on Special:NewPages and Special:NewPagesFeed, but having them highlighted on Special:RecentChanges would be a step in the right direction. I'm agnostic regarding the method of implementation. —Swpb^talk 13:46, 23 February 2015 (UTC)
  • I don't think it would be possible (or, at any rate, feasible in a way that could satisfy mediawiki interoperability standards) to have them at Special:NewPages. But at least they could be patrolled. Cenarium (talk) 21:01, 23 February 2015 (UTC)

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:Content redirects to a portal. Even if we did agree to add the link Cinderella suggests, we have no page to link to. I think the best place to link to for such an idea is Wikipedia:Five pillars, which has a lot of links to our key policy and guideline pages. Oiyarbepsy (talk

) 21:20, 17 February 2015 (UTC)

My proposal is in 3 parts with the suggestion that servants'entrance or user home be a portal from which users can more easily navigate around WPs back of house. It can also have otherthings too but I would see this as its primary function. Cinderella157 (talk) 23:34, 17 February 2015 (UTC)

Are you aware of the Category:Wikipedia directories and its contents, like Wikipedia:List of policies and Wikipedia:Glossary? Similarly, Special:SpecialPages shows many special pages and Special:AllMessages shows all of the Wikipedia interface messages. – Philosopher ^{Let us reason together.} 21:46, 17 February 2015 (UTC)

Thanks, I was aware of one of these pages. My proposal is about how one becomes aware of these pages. Furthermore, my proposal is about being more inclusive (all of the back of house) than what any of these individual pages are. Cinderella157 (talk) 00:23, 18 February 2015 (UTC)

• I could see creating a
  talk
  ) 23:30, 17 February 2015 (UTC)

Not certain if you mean by that , that no special permission is needed or if you mean that anybody has the capacity to undertake the task? Part of the reason for addressing this here is the limitation of my own capacity to perform the task (the know-how). Also, for it to be effective, the door would need to be somewhere visible (as I have discussed/suggested). I perceived that placing the door would probably require some sort of permission or special access. Cinderella157 (talk) 00:41, 18 February 2015 (UTC)

I think what Cinderella157 is saying is that we should have an (optional) secondary Main Page for editors where the most commonly used special pages are organized into categories. It should have links to the Village Pump, the Policies, the Noticeboards, and Project Pages, so that all are within easy reach of a new editor. The reason Cinderella is asking for someone with permissions is that such a page should be created by an experienced user, and once created, it should be easily accessible to all logged-in users, such as through a link on top next to the "log out" link.

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)

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

Article Under Review Recently created articles may be patrolled in order to maintain standards. This article is currently being review by Unit388 (talk) Tag placed at: 02:57

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

• Has there been an issue with the NPP process that this is intended to address? Praemonitus (talk) 03:44, 8 February 2015 (UTC)

• Echoing an issue raised in the discussion of the previous proposed template, what is the need for this? We already have planned changes to the CSD templates to prevent tagging of a new and active article waiting on needed support in the software. This looks to me like
  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
  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)

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)

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)

Under Articles for Deletion policy there is the ambiguous procedure for

• 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

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)

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

talk

) 21:14, 28 February 2015 (UTC)

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

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

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.
   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. –Davey2010^Talk 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. §FreeRangeFrog^croak 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)

• The part about being allowed to remove a CSD tag is moot because everybody (except an article's creator) is already allowed to do that. —Largo Plazo (talk) 17:55, 28 February 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.
  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

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

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

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. –Davey2010^Talk 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
  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.
  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)

• Oppose While the majority of my welcome messages are standard, a significant percentage are chosen because they address a particular issue (e.g., sources, copyrights, NPOV, image use). These welcomes are a lot more useful to some new editors. --NeilN ^{talk to me} 16:17, 4 March 2015 (UTC)
• Oppose they do this on Commons actually C:Special:Contributions/Wikimedia_Commons_Welcome and it's useless. It just leaves this super generic welcome box which could be found on any old welcome page. But because of the multi-lingualism over there it is useful. The idea of the welcoming is the new user can then ask the welcomer any question they may have. EoRdE6^{(Come Talk to Me!)} 15:52, 5 March 2015 (UTC)
• Oppose No one seems to have drawn attention to one aspect of welcoming that is often forgotten. Almost all welcome templates include a line that says "If you have any questions or need help, ask me on my talk page". So how is any user going to ask questions to a bot? SD0001 (talk) 10:29, 6 March 2015 (UTC)

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)

Anybody who has edited through Wikipedia's mobile view would have noticed the way mobile

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.

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)

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)

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

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

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

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

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.

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

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)

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)

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

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:

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)

@

Edit protected}}. — xaosflux ^Talk

16:49, 12 March 2015 (UTC)

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

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)

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