Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

New ideas and proposals are discussed here. Before submitting:

• Check if your proposal is already taken care of at Perennial proposals.
• Proposed software changes should be filed at Bugzilla. Editors here can help you with this.
• Proposed policy changes belong at Wikipedia:Village pump (policy).
• Proposed new wikis belong at m:Proposals for new projects.

« Archives, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216

Watched counter

The proposal in this box is shelved/withdrawn until the proposal in the next sub-section is resolved. (May be worth reading for background on that proposal, though)
The following discussion has been closed. Please do not modify it.
Wikipedia:PEREN#Create_a_counter_of_people_watching_a_page There are more good editors than vandals. Even if making the counter visible and the 'unwatched pages' page public resulted in massive abuse, editors would quickly remedy the problem by adding unwatched pages to their watchlist. Can an admin tell us how many pages there are on the unwatched list? Reasons for doing this, or why the 'vandalism' objection is invalid: Good editors would overwhelm vandals. Displaying "<5" for 0-4 would make this useless for vandals.[1] If there are still vandal concerns, an adminbot could be set up to ask recently-active editors to "adopt" articles. This would allow editors to find pages that needed "adoption". This would relieve the admins who are taking care of the unwatched list. What other reasons were given against this proposal? It might help if the PEREN page linked to the discussions. Without knowing what was said, the reasoning sounds like "the vandals would make this impossible", which is often a poor objection. –MT 03:50, 19 April 2009 (UTC) The list of unwatched pages is limited to 1000 entries, sorted alphabetically. It is rare that it extends beyond the letter A. Every time it is refreshed, there are a number of editors who dutifully watch hundreds of pages from it, yet every time it is refreshed with a new list. It really is like emptying the Atlantic with a teacup. I think the problem is hugely more widespread than you anticipate. Happy‑melon 09:36, 19 April 2009 (UTC) Not that they don't need watching, but how many of the first 1000 are redirects? Mark Hurd (talk) 11:26, 19 April 2009 (UTC) Given that points 1 and 2 would address the vandal problem, doesn't what you're saying just give us all the more reason to support this proposal based on points 4 and 5? –MT 13:51, 19 April 2009 (UTC) Another possibly 'simple' short-term solution is to provide another special page that lists unwatched pages by order of most recent edit and that can also still be limited to the first 1000. If that overlaps between runs, we'd be clearing the backlog from the more 'important' first. Otherwise we're no worse off. Mark Hurd (talk) 00:12, 20 April 2009 (UTC) Great idea. This would not only eliminate vandalism worries, but would also be extremely useful. This feature is a frequent request, is useful and informative, and aside from vandalism I don't think there are objections. We have the following options: Modify wgAllowPageInfo to display "<5 watchers" Change the list to order by last-edited rather than alphabetical, reduce displayed entries to 100, allow all to see it Change the list to order by least watched, then last-edited, reduce to 100, rename it to "least watched articles", allow all. I would support going directly to 3, but we can do a more gradual roll-out by implementing 1 and 3 (I think these are trivial changes, but perhaps a dev could comment) and then removing 1 when the list starts to shrink. Were there any lurking objections? –MT 00:53, 20 April 2009 (UTC) In the flagged protection and patrolled revisions trial implementation, special:Unreviewedpages, which lists pages that have never been patrolled, will indicate the number of active users watching the page. It's only accessible to reviewers. Cenarium (talk) 01:00, 20 April 2009 (UTC) This seems like its a lot more trouble than its worth. If you really want to help with vandalism, just get rollback and download huggle. I disagree that "Good editors would overwhelm vandals." really deals with the vandalism problem. This sounds like how wars used be fought, where each army would just stand in a line and shoot at the other one, and the bigger one would usually win. It worked, but not particularly well. Saying that fewer than 5 people watch a page still makes it nicer target for vandals, it just doesn't narrow it down quite as much. Since the people watching it might have left the project ages ago, it could still have 3-5 watchers but effectively be 0. Mr.Z-man 01:02, 20 April 2009 (UTC) Countervandalism activity is more than just RC patrol. Somebody needs to watchlist articles to catch the vandalism that the RC patrollers miss -- the majority of my vandalism reverts take place hours to days after the fact. --Carnildo (talk) 01:19, 20 April 2009 (UTC) I wouldn't like vandalism patrol, but I would like to make things much easier for editors and much more demoralizing for vandals. Your objection seems against the weakest part of the proposal. The implementation of #3 is a trivial change to an SQL "ORDER BY". The strongest part is editors being able to adopt unwatched pages. This is strengthened by the possibility of a "least watched last edited" page. Vandalism already targets unwatched pages (just click random and mess up an obscure article), this proposal would allow editors to target this already-vulnerable class of pages. –MT 08:07, 20 April 2009 (UTC) When your database contains several million rows, changes are rarely "trivial." The code for Unwatchedpages doesn't count the number of people watching the page at all right now nor does it use an explicit order, so you would need to add the "ORDER BY" and would also need a "GROUP BY." The other issue is that the list is only updated once every week or so. Given that we get about 11,000 edits per hour on around 6000 distinct pages, "most recently edited" might as well be random as it would be out of date within a few minutes. Based on a quick and dirty estimate using the number of pages in the list right now and how far it gets alphabetically, I would estimate that there's easily 60,000 unwatched pages. At 100 at a time, with updates once a week, it'll take 11 years just to work through all the pages with 0 people watching them, ignoring all the ones that are added in that time. Mr.Z-man 18:41, 21 April 2009 (UTC) I didn't and don't endorse a broken version of a recently-edited page. Given that wgAllowPageInfo doesn't use a field in the page table, I agree that it isn't trivial. It would require adding a field and index to the page table (cf. page_random, page_len, page_touched) that kept track of watchers. What sort of disruption would the addition of this field cause? Consider where unnoticed vandalism mostly occurs. The proposal would put into view these pages (which are highly vulnerable, seldom altered, and recently altered). This would allow editors to have a central place to patrol for vandalism (see Wikipedia_talk:Special:UnwatchedPages#Purpose. It would also allow editors to find pages to watch. There's a great reason Jimbo requested the unwatched pages, and given that that method is too overwhelming, there remains a great reason to implement recent least-watched pages. –MT 23:39, 21 April 2009 (UTC) Adding new tables to the database is relatively simple. Altering existing ones is generally avoided. I believe it requires stopping replication on, altering, then re-enabling each slave server one by one, then switching the master to update that. After updating all the databases, a script would have to be run to populate the new field. The page table on enwiki currently has 16,575,280 rows, and grows constantly. I've no idea how big the watchlist table is. If this is done, it might make such a special page possible (and able to be updated dynamically). The index would also probably have to be on page_latest as well if you want to be able to sort by most recently edited. Mr.Z-man 00:08, 22 April 2009 (UTC) Not forgetting, of course, that while the database master is being updated, the whole wiki goes read-only (unless they do something wierd like setting one of the slaves to be a temporary master, which could work I guess). This is the schema update script, yes? Happy‑melon 17:05, 24 April 2009 (UTC) \ Ah, pages isn't indexed by date. How does recent changes work then? (schema, large image). Perhaps it would be more appropriate to add this sort of field there. This would also involve adding a field, but might be less dramatic. The field would list the number of people watching the page at the time the edit was made, and could be used to generate our desired list. –MT 02:40, 22 April 2009 (UTC) Since RecentChanges would otherwise need to read from about five different tables every time it was requested, it actually stores all its data in its own separate table. Every new elegible edit or action puts a copy of its log into the recentchanges table as well as whichever permanent table it uses, and ever hundredth edit calls a function to clean out rows from the table that are older than the limit (currently 30 days). Happy‑melon 17:08, 24 April 2009 (UTC) Perhaps I should amend the proposal.–MT 19:38, 25 April 2009 (UTC)

A recent changes page for unwatched articles

Vandalism is a problem on all pages, but it is a much larger problem on pages that, on average, have fewer or zero people watching them. One solution to this problem is Wikipedia_talk:Special:UnwatchedPages, which was requested by Jimbo, is accessible only to admins, is updated infrequently, and is therefore very difficult to 'clean out'. Another solution, advocated here, is to modify the recent-changes table in MediaWiki to grab the watcher-count from the watchlist table. We would then be able to create a "recent changes in unwatched articles" page. This page would let editors catch vandalism that would usually have gone unnoticed for long periods of time. It would also encourage editors to expand their watch-lists, and urge editors to contribute to fringe/stub articles that are seeing some recent activity. It would also allow us to finally address one of the WP:PERENs. To get this proposal off the ground, we would need:

1. Interest from editors. Other potential benefits. Perhaps a straw-poll.
2. Critical comments, including reasons why this might not be as useful as stated.
3. Solid estimates of cost - can this be done without locking the site? How long would it be read-only for?
4. Input from a developer. Should one be contacted to check feasibility?

Comments addressing any of these four points are especially welcome. –M^T 19:38, 25 April 2009 (UTC)

Now this is an interesting, and probably feasible, idea. Technically, it could probably be done without a schema-change, and it could be useful to do so; the code in FlaggedRevs, for instance, uses the fact that it has to do a database lookup to be more clever in what it shows: it only 'counts' users who have logged in in the past 60 days, for instance, which is pretty neat. If the servers can take the strain, having that feature available on Recent Changes would be very useful, and avoids the issue of pages apparently being watched because they're on the watchlists of users who last logged in three years ago. Performance-wise, having a rc_watched column in the recentchanges table would massively reduce database load when viewing RecentChanges. Or we could define a few more types in the rc_type field (only ~3 actions defined out of a possible 16 million!), and avoid an explicit schema change, but the devs might find that a bit hackish (I remember there being hiccups over the RevDeleted bitfields). On the other hand, that field then has to be populated on every action.

Procedurally, it sounds like a godsend. Unwatched articles are only dangerous if they're edited; unwatched but untouched articles are no harm to anyone. Happy‑melon 14:39, 27 April 2009 (UTC)

I think 7 days would be the best last-login time, unless someone can give a better figure. Given the rate of revisions vs the rate of access, and the many other fields in recent changes, I don't think that this would do too much damage to performance. And the benefits, as you say, are a godsend. Should we get dev feedback, or try to get a few more comments? –M^T 02:36, 28 April 2009 (UTC)

I guess it should be the latter... –M^T 04:28, 5 May 2009 (UTC)

How might the column increase performance?   M  20:37, 13 May 2009 (UTC)

I have to agree that this is an interesting proposal. During my vandalism patrols i cross infrequently visited articles every now and then which blatant vandalism on them for periods up to (And in some cases over!) a year. While I encounter them irregularly it won't automatically mean there are not a lot of pages vandalised this way - they simply don't show up on anti-vandalism tools often. I also see possibilities for using this page for new page patrol as pages listed might very well be missed non notable or vandalism pages that slipped into forgetfullness.

On a more critical note: How would these articles be patrolled? I can imagine that this category will end up having at least 100.000 articles in them. Even if they are only infrequently edited it will still mean a lot of edits in a day - and how will double / triple / n* checks of the same page be prevented? Likewise, not every actively edited article has to be on a watchlist. Also, some active editors have massive watchlist from new page patrols (I had to remove 600 entries from three weeks patrolling). How can we prevent pages from going unnoticed due to unclean watchlists? Might it be better to filter on pages that have not been edited in say, two months? Excirial ^{(Contact me,Contribs)} 19:51, 15 May 2009 (UTC)

Another way to look at it is as filtering out all 'watched' pages from recent changes - if someone's watching, you don't need to. So right away we're preventing many multi-checks. Overflowing watchlists are a problem, but this new page will catch further edits to infrequently-edited articles. So if you can't track every page on your watchlist, then you shouldn't, and now you wouldn't have to. The other problems you bring up - inevitable double checks, thousands of edits per day - are ones we already face. This proposal can't solve them, but it does reduce them.   M  22:13, 15 May 2009 (UTC)

You could just use variables, like

"Recent Changes on Village pump (proposals): Aervanath, on 07/7/2009"

But it would be a good idea for rollback

Would there be some way of combining it with the recent "whitelist" list of autreviewers? That is, for there to be a list of recent changes to unwatched pages excluding those pages where the last change is by an autoreviewer? That way it would be easy to look for vandalism without checking pages where someone else has already reverted vandalism. That might well solve some of Excirial's concerns about multiple checks of the same recent edit. Grutness...wha? 02:09, 23 June 2009 (UTC)

The list would essentially be a filtered version of the current recent-changes list, so if this idea is possible there, then it is possible with this list. I don't think that this should be handled by the server itself, though I do think that it should expose the autoreviewer or admin status of the last editor, so that scripts could use that information to do what you describe.    M   21:57, 2 July 2009 (UTC)

Recent unwatched changes straw poll

The proposal is to create a recent changes page for unwatched articles to prevent vandalism by modifying the recent-changes table in MediaWiki. (I'd really prefer not to see this one archived, since it would open up several useful features. It would permit Watched counters. A now-ignored bugfix in the watchlist code and the addition of a 'checked' watchlist row would then let you patrol your own watchlist. Adding a public-watchlist preference would then give us a passive form of Flagged revisions.) Though this is a software feature request, support from editors would help.

• Support. –M^T 04:28, 5 May 2009 (UTC)
• Support. -- John Broughton (♫♫) 18:24, 9 May 2009 (UTC)
• Support sounds good to me. It does provide a route for vandals to find unwatched articles, but I think the benefits outweigh that. Rd232 ^talk 18:34, 9 May 2009 (UTC)
  • While technically true, any such vandalism would land the vandal with a kick to the pants, since their edit would float to the very top of this slow-moving list. –M^T 19:46, 10 May 2009 (UTC)
• Support. Mark Hurd (talk) 15:05, 10 May 2009 (UTC)
• Comment - Just file a bug. If its a good idea and technically feasible, someone will do it. The existence of a straw poll will likely have no effect. Mr.Z-man 15:26, 10 May 2009 (UTC)
  • Isn't a bug with a supportive straw poll more likely to be implemented soon than the same bug without? Rd232 ^talk 19:35, 10 May 2009 (UTC)
  • When people voice their support for a proposal, others become more inclined to try to see it implemented. This may include filing a bug report, searching documentation, speaking with devs directly, changing the relevant code, and submitting a patch. "Well, someone else will get to it eventually" is not the approach that we should take at this page. Even if the devs were entirely blind to community requests, your support would nevertheless encourage other editors (like me) to try to see this implemented. –M^T 19:46, 10 May 2009 (UTC)
    • With this specific proposal, it may, but only because the schema change would need approval from Brion. With the amount of work required to do this, I doubt a little straw poll is going to have a significant effect on any developer's motivation. Mr.Z-man 18:58, 13 May 2009 (UTC)
      • Then let's hope that it grows to become a much bigger straw poll :) as this might demonstrate a need for better tracking of unwatched pages   M  20:29, 13 May 2009 (UTC)
• Support - I really like this idea. I know from personal experience that non-obvious vandalism on poorly watched pages can go undetected... I have a couple such pages on my watch list & when I took a month off, I cam back to find some vandalism on one of them that had been sitting for 2+ weeks. --ThaddeusB (talk) 18:34, 13 May 2009 (UTC)
• Support - Great idea. Kevin Baas^talk 20:34, 13 May 2009 (UTC)
• Strong support: The admins can't do this alone. I love the idea. Dendodge _T\^C 20:38, 13 May 2009 (UTC)
• Bug 18790 has been created. Suggesting improvements (or establishing that there is a clear need for this) here is what will help with implementation, though voting at bugzilla in addition to here should help make it more noticed. At bugzilla, only 55 wp enhancements have 10+ votes, 19 have 20+, and 8 have 30+, out of over 1300. Registration is easy, and the vote link is at the bottom-right of the bug page, under 'related actions'. (Please use this feature to vote instead of leaving a comment at bugzilla, as comments are relayed to mailinglists).   M  22:31, 13 May 2009 (UTC)
• Support - Makes a lot of sense and fills a great need. J04n(talk page) 09:58, 22 May 2009 (UTC)
• Support - If this can be done without overloading the system, then by all means please do. (Every little bit helps in targeting vandalism.) --Ckatz^chat_spy 17:18, 26 May 2009 (UTC)
• Support per above proposal --unsigned by Assasin Joe
• Support per all the other comments that I read. This would be very useful to find vandalism in more hidden pages. –Drilnoth (T • C • L) 17:02, 27 May 2009 (UTC)
• Support – Wow, this is a really good idea. As long as it can be configured in software, I think it would be very useful. American Eagle (talk) 06:36, 31 May 2009 (UTC)
• Support If implementable, it's an ingenious solution to the problem of vandalism to unwatched pages. --Cybercobra (talk) 08:52, 31 May 2009 (UTC)
• Support only for admin, oppose otherwise - It would be simple enough for a vandal to watch a page, and then it would fall off of everyone's radar. That would turn a good thing into a very bad one. ▫ JohnnyMrNinja 06:57, 5 June 2009 (UTC)
  • Restricting the page to admins is one solution, but I don't think that there's a problem. We would count only autoconfirmed watchers active in the past 7 (or 60) days, and the implementation would also give us recent-changes for pages with 1 watcher, or under 5 watchers, and so on. The sort of coordinated vandalism to 'get around' this is rather visible and is more difficult to deal with if we keep the pages admin-only.    M   01:14, 6 June 2009 (UTC)
    • Isn't that going to be a gigantic strain on the servers? Right now, our watchlists are the biggest strain (right?), so wouldn't a watchlist that watches thousands of pages that are selected from every page on EN based on a series of checks on each page and every user that watches any pages at all... Wouldn't that slow our WP down to the barest crawl? Even if the list of articles matching the criteria were only updated every other day or so, a watchlist that big is a massive beast. Of course you could limit the number of pages that show up, but it would still check the entire list for the 100 most recent changes (right?). I'm certainly no expert on how Mediawiki works, so maybe I'm wrong. Limiting it to admins is a better solution, I would think, if even that is feasible. If it's between having an even-more unstable connection to WM projects or having the fact that Franklin Township, Wright County, Minnesota is referred to as a "gaylord" for two weeks, I'm okay with the latter. But, again, maybe I'm mistaken about the strain. ▫ JohnnyMrNinja 09:12, 10 June 2009 (UTC)
      • No - actually, it might speed things up. The proposal is not to put every unwatched page onto a global watchlist, but to record the watcher count in the recent changes table. This is extremely fast compared to a global watchlis, and is fast in general (see Bug 18790). If the page causes people to reduce their overburdened watchlists (which it should), it may actually increase performance.    M   00:27, 11 June 2009 (UTC)
        • If that's the case then it could be workable, and it is a good idea. With the inclusion requirements you've specified, the list would actually pick up far more pages than the regular unwatched pages list. But I must stress that launching it for everybody is a bad idea, because if something goes wrong and it is deactivated, we will have provided a complete list of un-and-hardly-watched pages, and then removed our ability to protect them. I am not a fan of segregating access normally, but I still feel that it should only be accessed by admin (maybe rollbackers?) until such time that it shown to not contain bugs and we decide we're going to keep it permanently. The only thing you need to be Autoconfirmed is to not have been blocked yet. ▫ JohnnyMrNinja 02:25, 11 June 2009 (UTC)
          • Right, it wouldn't be the same, though this means it would pick up more unwatched pages and not false positives. It wouldn't be a complete list, since it would only record edits made in that short period of time (no doubt those articles would be gobbled up into watchlists by our editors). I do think that these points deserve attention, but it might be early to decide how we want to deploy the feature.    M   18:29, 16 June 2009 (UTC)
            • A few comments. This almost certainly won't speed anything up. Watchlists are not the biggest strain and the slow part of watchlist generation is generating the HTML, not the 1 database query to get the list. You're calculating something that's not currently calculated and not removing anything else. You say in one comment that people would "reduce their overburdened watchlists" then in another that pages would be "gobbled up into watchlists by our editors." That can only affect performance in one way. The question is just will the extra calculation on every edit be fast enough to be usable. Blocking a user does not remove the autconfirm right. A blocked, autoconfirmed user could still do anything that requires autoconfirmed, as long as it doesn't also require editing rights. Even if they're blocked before becoming autoconfirmed, their account doesn't stop aging, and most blocked users can still edit their talk page; so they could even become autoconfirmed while blocked. Mr.Z-man 20:36, 16 June 2009 (UTC)
              • A reduction in the size of watchlists and perhaps the need to check them might reduce some of the burden. It's not important whether it will or not, just that it definitely won't bog down the server. In the long term, this will allow editors to reduce their watchlists. In the short term, editors will tend to add these articles to their lists until they see that it's unnecessary. If something went wrong, which is entirely unlikely, we'd have no problems watching the small list of recent unwatched articles. Dedicated vandals will always get through to some extent, but checking for autoconfirmed is something cheap, relatively accurate, and effective for the majority of cases.    M   00:23, 22 June 2009 (UTC)
                • Restricting it to autoconfirmed would be trivially simple to bypass. Vandals wouldn't even need to create new sleeper accounts to see the list, they could just use existing, blocked ones. If you're not concerned with dedicated vandals, then it shouldn't be restricted at all, as only dedicated vandals would likely even take the time to check such a list. Mr.Z-man 03:28, 22 June 2009 (UTC)
                  • Misunderstanding, I think. It's safe to let everyone see it; I think the concern was a vandal registering 5 accounts, watchlisting many articles, and then vandalizing them. Autoconfirmed would be for whether the editors are counted as watchers, which makes this strategy not worth the effort.    M   08:11, 26 June 2009 (UTC)
• Support the unwatched list it too big to do anything useful with by admins. Perhaps proven vandal fighters would get blocks of these unwatched pages to add to their watchlists. Talk to me if you are interested in this idea. The article names could be emailed to those who want to change them to watched articles. Graeme Bartlett (talk) 02:16, 6 June 2009 (UTC)
• Support Sounds like a good idea. Dream Focus 09:35, 6 June 2009 (UTC)
• Support Graeme two posts up says it well. Casliber (talk · contribs) 05:29, 25 June 2009 (UTC)
• Yep, definitely a good idea. –Juliancolton | ^Talk 22:07, 2 July 2009 (UTC)
• Support Very useful idea. It will increase the efficiency of the list. In my opinion, I would not mind if I had a list of pages to watch on top of my current list. It is all going for the same cause in the end anyways. -- Dspradau → talk  14:45, 6 July 2009 (UTC)

Admins able to block while blocked?

I just came off a short block (violated 3RR, wasn't paying attention), during which I explored what an admin can do while blocked. Not to my surprise, I couldn't protect or delete pages, but I found myself able to block users and unblock myself (neither of which I did, mind you :-). What possible benefit is there of admins being able to do this while blocked? I'd like to see the block/unblock feature disabled during a block, partially because it would prevent someone like me from having the annoying little temptation to unblock myself and be vindictive by blocking the guy who blocked me, but more significantly because it doesn't do anything to stop someone who really doesn't care about the rules. If blocking suspended all the tools rather than leaving this — in my mind, the most powerful of all the tools — we'd not need to worry as much about rogue admins. Keep in mind that case a year or two ago when the guy hacked an admin's account, blocked Jimbo and several other people, deleted the main page, and vandalised tons of pages — he was blocked several times, but simply unblocked himself and kept on going until somebody called a bureaucrat to do an emergency desysopping. If my proposal were accepted, someone else would have had to unblock Jimbo, but the hacker would have done far less damage overall. Nyttend (talk) 02:29, 24 June 2009 (UTC)

We've had a few cases of admin accounts being compromised or even admins going bat shit crazy and blocking a bunch of people, including other admins. In such cases, the blocked admins should be able to unblock themselves. Imagine the mess that would happen if someone decided to block all other admins and they couldn't unblock themselves. --Ron Ritzman (talk) 03:38, 24 June 2009 (UTC)

Unless all active admins were blocked, this wouldn't be as big of a problem; and if all were, somehow, couldn't we then call in the bureaucrats or someone else? Perhaps make it so that bureaucrats etc. (including Jimbo) would be able to unblock themselves, but not admins? If we got into the emergency of which you speak, surely it wouldn't be that hard (although somewhat tedious, admissably) to go through all the admins and unblock them; and I expect that it would be far more likely that the rogue would get caught before blocking all of the others. Nyttend (talk) 06:19, 24 June 2009 (UTC)

Minor point but I take it you mean when the stewards came in to desysop not bureacrat as the bureaucrats don't have that power. Davewild (talk) 18:28, 24 June 2009 (UTC)

I don't think it at all likely that a rogue could block all 915 active admins without being spotted, Ritzman. ╟─TreasuryTag►co-prince─╢ 18:51, 24 June 2009 (UTC)

Why not? I think with a user script it is possible to block at least 10 per second. So it will take only 1.5 minutes. Ruslik_Zero 19:18, 24 June 2009 (UTC)

Thanks for the tips :P ╟─TreasuryTag►stannary parliament─╢ 19:21, 24 June 2009 (UTC)

There is also this. Ruslik_Zero 19:26, 24 June 2009 (UTC)

• Admins need to be able to unblock themselves just in case they fail hard like this noob did: [2]. –xeno^talk 19:25, 24 June 2009 (UTC)

<_< PeterSymonds (talk) 23:20, 24 June 2009 (UTC)

• • (Semi-serious) Should noobs really be admins? Would it really have been so bad for that admin to have to ask another admin (or buro, whatever) to unblock them? --Cybercobra (talk) 19:40, 24 June 2009 (UTC)
    • Some kind of a virtual walk to Canossa you mean? :-D SoWhy 19:54, 24 June 2009 (UTC)
    • It's not just noobs. --Floquenbeam (talk) 20:06, 24 June 2009 (UTC)
      • Don't forget my personal favorite. J.delanoy^gabs_adds 23:29, 24 June 2009 (UTC)
        • Win. –Juliancolton | ^Talk 23:33, 24 June 2009 (UTC)

The ability of admins to self-unblock is considered an important safety value to prevent a rogue from blocking everyone else and taking over. On enwiki this is unlikely given the large size of the admin corps, but many other projects have 25 admins or fewer and so a coup is far more possible, so Mediawiki is designed to allow such self-unblocks. This was discussed some years ago. I suppose one could add a Mediawiki configuration to allow this to be disabled in communities like en, but no dev was interested in doing that the last time it was discussed. Dragons flight (talk) 23:32, 24 June 2009 (UTC)

• The thing is, I would think that having administrators not being able to unblock themselves would be safer for Wikipedia. Though this seems paradoxical, think of what would happen currently if an administrator were to go rogue and block all active admins with a script. Even if someone were to just block him, nothing really would change; you would still need a steward to perform the desysopping (I think I remember that a sockpuppet admin account once deleted the Main Page while there were no stewards around because of Wikimania). However, if they couldn't unblock themselves, all someone would have to do is block them, and the whole issue would be solved while a steward came around. However, this whole discussion is rather academic, and I see no reason to waste developer time on this issue. As Werdna said when I brought this up months and months ago (at Wikipedia:Village_pump_(proposals)/Archive_40#mw:Extension:EmergencyDeSysop), "...[a]nd for what? A minute or two of saved admin time every few months/years. This is, of course, an excellent example of a systemic focus on the dramatic things like rogue administrators. In reality, there are very few rogue administrators on Wikipedia who would warrant an emergency desysop in sub-minute timing, these events being the sorts of things that happen once or twice a year, at maximum. More time is probably spent creating this proposal than will be spent on fixing up vandalism by 'rogue administrators' over the next year or two...Honestly, we need to deal with real content problems – not dramatic things like rogue administrators." NW (Talk) 00:07, 25 June 2009 (UTC)
  • I agree with Werdna. This is an example of a focus on a dramatic thing, that hasn't yet occurred to my knowledge on any Foundation wiki, rather than on real problems that occur every day. Uncle G (talk) 12:22, 30 June 2009 (UTC)
• On small wikis coups generally occur, in my experience, not by sysops blocking one another but by one person gaming the system to get almost all other administrators de-sysopped through the usual channels. The system is surprisingly easy to game, it turns out. Uncle G (talk) 12:22, 30 June 2009 (UTC)
• If an admin is blocked for say 3RR and they decide to unblock themselves then the safety valve would be desysoping them. Or if they're compromised and blocked it's likely they'd be desysoped anyhow and thus wouldn't be able to unblock. Thus there's no reason to make a big deal out of this. Nja²⁴⁷ 09:35, 5 July 2009 (UTC)

Articles for Deletion needs more automation

The AfD process is still very manual, requiring at least three manual edits per AfD. The "prod" process and the Wikipedia:Requested moves process are now semi-automated - there, one template on the page of interest does the job. All the appropriate list pages are updated automatically.

I'd suggest using the Wikipedia:Requested moves machinery for Wikipedia:Articles for Deletion. One template on the page starts the process, and everything else is updated by a 'bot. This will make the process much simpler for users. --John Nagle (talk) 19:25, 26 June 2009 (UTC)

• I see that we are playing tag here. The bot for RM came from RFC, and the 7 days at RM from AFD. 199.125.109.124 (talk) 20:06, 26 June 2009 (UTC)

• Well, there won't be any way to get around the fact that at least two edits have to be made - one to tag the article in question and one to create and start the actual page. Automating the listing on the actual AfD log wouldn't be too terribly hard to implement at all and I would happily support an effort to do just that. Shereth 21:53, 26 June 2009 (UTC)
• Twinkle helps very much for creating AfDs. Is there any way the programming behind that could be implemented on Wikipedia? On the other hand, a big "delete this page" button on the top of every page such as what Twinkle produces will encourage misuse of AfDs from editors unfamiliar with the process. Another question would be, can we have a template which, when used, automatically creates a page on Wikipedia? This could have some issues with cleanup since if a user removes the tag and gets reverted, another AfD page would be created. Perhaps a parameter could be added onto the tag, such as {{afd|2}} which specifies a specific page to be created? I'm still not sure if that could work out though. I can imagine scenarios where AfD pages are created on top of one another or out of order if due care isn't given to watch out for those situations. In the end, it seems best to manually create the afd page and tag the article seperatly, unless one chooses to use a script like Twinkle.ThemFromSpace 22:19, 26 June 2009 (UTC)
  • When one adds {{afd1}} to an article, there's a hyperlink right on the notice that one can follow to create the per-article sub-page. Uncle G (talk) 11:59, 30 June 2009 (UTC)
• There's a reason that AFD isn't a simple drive-by tagging process. In years gone by, vandals used to enjoy trying to tie us in knots with our own processes with drive-by AFD taggings. The hurdle for a nomination to be complete is deliberately not low and is deliberately higher than a simple drive-by tagging. (A comparison to Proposed Deletion is an ill-chosen one, moreover. Proposed Deletion is intentionally different to AFD.) Moreover: Only one of the three edits adds anything to a list page. The edit to the per-article sub-page includes the nominator's rationale for nomination, which of course cannot be automated. We took to rolling back incomplete AFD nominations by drive-by taggers where no sub-page was created and no rationale given (on a page or in an edit summary), in light of the vandalism.

  On the converse, DumbBOT does a good job of rescuing incomplete nominations that have nomination rationales, but that aren't listed on per-day sub-pages. There's really nothing to do here that isn't already being done. In part, this is because this is a perennial proposal, that has come up before (on the talk pages of the templates as well as at Wikipedia talk:Articles for deletion), along with editors pointing out the past experiences that we have had with abuse by vandals when the hurdle is made too low, either by 'bots or by the actions of well-intentioned editors completing incomplete nominations where only a tag was applied. Uncle G (talk) 11:59, 30 June 2009 (UTC)

Pronunciation to foreign place infoboxes

Apologies if this has been posted in the wrong place, but regularly, when I visit an article on a foreign (I mean non-English-speaking country) town or city &c., I look for the native pronunciation of the place concerned. As a simple example, Paris has as its first sentence "Paris (Template:Pron-en or /ˈpɛrəs/ in English; [paʁi]^ⓘ in French) is the capital of France and the country's largest city." But the majority of places do not have such a sentence in the lead. Although it may be a rather tedious process, would it be out of the question to introduce native pronunciations to infoboxes of place articles, with the pronunciations underneath the place name, maybe in a smaller font size so as not to look too conspicuous? 79.71.5.38 (talk) 19:48, 28 June 2009 (UTC)

You probably need to discuss this on some infobox template talk pages. ---— Gadget850 (Ed) ^talk 19:26, 29 June 2009 (UTC)

That's an interesting idea; I've got to get going, right now, but I'll see if I can find an appropriate talk page later, if no one has by then. – Luna Santin (talk) 23:58, 30 June 2009 (UTC)

Cross-posted to Wikipedia talk:WikiProject Infoboxes#Pronunciation field in infoboxes?. – Luna Santin (talk) 21:07, 1 July 2009 (UTC)

Userspace redirect

I propose that a namespace be implemented specifically for userspace redirects. There's currently no policy that forbids redirecting pseudo-namespace to user pages but it's certainly enforced as a policy. To deal with this, I propose setting up U:/UT: redirects as allowable shortcuts for user pages. U: to the user page and UT: to the user talk page. I don't know if this requires anything special other than saying "these are OK" somewhere such as wp:csd#r2 or Wikipedia:Pseudo-namespace or if something has to be done on the backend software wise but this is my proposal. - ALLST✰R▼^echo _{wuz here} 20:41, 28 June 2009 (UTC)

What good reason is there for anyone to need a redirect to their userspace? "I want one" and "It makes my sig shorter" are IMO not good reasons. Anomie⚔ 22:40, 28 June 2009 (UTC)

Obviously the same reason we have redirects to everything else: shortcut. - ALLST✰R▼^echo _{wuz here} 07:37, 29 June 2009 (UTC)

You just said "A good reason for having a shortcut is because it's a shortcut". That tautology doesn't actually answer the question: Why is such a shortcut necessary? Anomie⚔ 12:26, 29 June 2009 (UTC)

I don't think that this is a good idea at all. WP:DRAMA and Wikipedia:Drama used to redirect to different pages, and then when WP: became a proper redirect namespace, it caused problems. What would happen if people essentially got to choose a "second username" (or more than one) for themselves (I could be U:TAG)... chaos. ╟─TreasuryTag►ballotbox─╢ 07:40, 29 June 2009 (UTC)

WP:CSD#R2 forbids redirects from mainspace (so, from all pseudo-namespaces) to the user namespace, and has always. When I became an admin, userspace was the only explicitly forbidden target, and this policy has always been enforced. I see no need to change it, and if your username is too long, you can try to change it at WP:CHU. Kusma (talk) 08:51, 29 June 2009 (UTC)

• I wouldn't mind a proper WP: style alias being created for User talk: (UT:) but User: seems unnecessary (removing three characters). Anyhow, I've previously suggested to ASE that he register User:ASE, seems like a nice short redirect and good doppelganger because people call him that anyway. –xeno^talk 17:42, 29 June 2009 (UTC)
• Doesn't seem to be a worthwhile change, to be honest. Stifle (talk) 13:13, 30 June 2009 (UTC)
• From a technical perspective, setting up of a proper namespace alias, like WP and WT are now, is a doddle. Regards U/UT, there is a precedent in the sense that on de.wp, BD can be used instead of the rather long (and longer that on en) "Benutzer Diskussion". - Jarry1250 ^{[ humourous – discuss ]} 15:41, 30 June 2009 (UTC)
• U and UT would be cool. Less typing as a good thing should not be underestimated. - Peregrine Fisher (talk) (contribs) 00:13, 1 July 2009 (UTC)
• Yeah, since we've already got User: and User talk:, I see no reason why there shouldn't be a related pseudo-namespace such as U: and UT:. - ALLST✰R▼^echo _{wuz here} 07:28, 2 July 2009 (UTC)
• I can vaguely see the argument of shortcutting "User talk:" with "UT:". It's shorter and linked to a fair bit. That said, I really can't see the need for a shortcut. Sure, it's a few extra characters to type but is it really that difficult? It seems to be more of a personal request than something that will improve Wikipedia. In some ways I'm saying IDONTLIKEIT, but I feel the proposal is purely based on the fact that ILIKEIT. Greg Tyler ^{(t • c)} 10:41, 2 July 2009 (UTC)
• Do I understand this right? I've a fairly long user name (Rannpháirtí anaithnid). Right now to link to my talk page I have to link to User_talk:Rannpháirtí anaithnid. What you are proposing is that I could like to it by UT:Rannpháirtí anaithnid. Or are you saying that I could have a shortcut like UT:RA? In the first case, I don't really see the point. For the sake of seven letters there really is no great advantage to it - how often do you find yourself typing this out so what is the great need? Besides the fact that there is already the {{U}} and {{UT}} templates that do practically the same thing. In the latter case, I think that that would be a really bad idea. I could see a land run for "vanity" user names. And gods know what would happen to after a user deceased or apparantly stopped editing - would we have squatters and ownership wars over user name redirects? --rannṗáirtí anaiṫnid (coṁrá) 17:51, 5 July 2009 (UTC)
• If this is about just having U: as a shortcut for typing User: and UT: as a shortcut for typing User talk:, then it sounds okay to me. I see some minimal utility. (Minimal, yes, but minimal != none.) • Since we're here: I also think T: as an alias for Talk: would be useful in the same way. Yah, we're only saving a few keystrokes, but over time it adds up. • If this is about actual shortcuts, e.g., U:DH redirecting to User:DragonHawk, then no. No way. As Rannpháirtí anaithnid said, it will just mean people fighting over shortcuts. We don't need the drama, or the confusion if they change in the future. —DragonHawk (talk|hist) 21:44, 6 July 2009 (UTC)

Maps could be much better

For some time, I've been thinking that the maps in Wikipedia could and should be much better. Good technology exists but we're still using "ancient" technology. Instead of a static picture we should have dynamic maps that users can pan and zoom. Inside the maps we should have links from geographical names to articles.

Today, when Honduras was in the news I looked up WP's Honduras article. Then I wondered what were its neighboring countries. The text has the names of neighbors but the map does not. The first map is a very small scale map that shows country boundaries but does not name them. Later in the article there is another small scale topographical map. If clicked, you can finally see the names of neighboring countries. Then I wondered what were the other countries of Central America. By clicking around in text I eventually found what I was looking for but my curiousity kept creating other questions that good mapping technology could have made faster and easier.

If we used mapping technology such as MapQuest, Google, etc. use, then in the Honduras article, I could have expanded the first map in the Honduras article, zoomed in, panned around, and could have quickly seen the names of other countries. With good technology, I could click on the map and go to the WP article about a country, city, river, etc.

While I was navigating around via typing into the search box, and clicking from one link to another to another to another, one of the maps I saw (this one) showed part of the Mississippi river with a tributary heading toward Washington, DC. I wondered what river that was. With good technology, I could have zoomed and panned until the name showed up. Instead I typed Mississippi River into the search box, where there weren't any good maps, but at least the text eventually let me find the answer (Ohio River) to my curiousity.

Good mapping technology would be a great improvement to the WP experience. (And yes, I know that in a few places, I can click a geographical icon to get to a modern mapping site, but that is not well integrated into WP, and does not allow clicking from a map back to a WP article.) Sbowers3 (talk) 18:49, 29 June 2009 (UTC)

But are any of them free? ♫ Melodia Chaconne ♫ (talk) 20:07, 29 June 2009 (UTC)

It's a nice idea, but ultimately one that I think surpasses the scope of this project. At best we can provide links to Google Maps, but based on the current limitations of the project we just have to make do with static maps. Shereth 20:11, 29 June 2009 (UTC)

Indeed. I'm not too big on the technical side of things, but that sounds like quite a load on the servers, and difficult to work into the mediawiki software. Perhaps the technical pump would be a better place to query? Ironholds (talk) 08:28, 30 June 2009 (UTC)

Support for Open Street Maps is current mid-range development goal. Dragons flight (talk) 08:41, 30 June 2009 (UTC)

See Meta:OpenStreetMap for more information. --seav (talk) 05:52, 1 July 2009 (UTC)

A very honourable vision. One I imainge everyone would support. Thanks, Dragons flight/Seav for the link to OpenStreetMap. Excellent idea. --rannṗáirtí anaiṫnid (coṁrá) 18:12, 5 July 2009 (UTC)

"Remember me for __ days"

On the login screen, I want it to "remember me" for only 2 weeks at a time. I'd be curious to see if we can add a drop-down list of some sort to allow people to choose the amount of time they'd like "remember me" to remember them. Would this be possible? iMatthew ^talk at  01:02, 1 July 2009 (UTC)

It's possible, but the devs are going to want to see some good reasons before they think about implementing it. Algebraist 01:10, 1 July 2009 (UTC)

Well, I often use computers that are not my regular one. I want it to remember me for the time that I'm using it (5 days for example when I stay at my parent's house next week). I want to check "remember me" but that's for 30 days, and I only want it to remember me for 5 days. iMatthew ^talk at  01:21, 1 July 2009 (UTC)

Why not just log out when you've finished using the computer? Algebraist 01:26, 1 July 2009 (UTC)

New category for promotional articles

I recently had an observation about Category:Wikipedia articles needing style editing. All articles tagged with {{Advert}} are being lumped there with many other "style" issues, such as {{essay-like}}, {{colloquial}}, {{textbook}}, etc. These "advert" articles are potential spam—and from my experience, often much worse than "not-perfect" articles that need tone editing. There is a difference between prose/style issues, and articles which may need heavy whacking or sometimes speedy deletion.

For this reason, I'm proposing that a new category be created for the {{advert}} tag, such as "Category:Wikipedia articles that are possibly promotional". Spam is a problem, and this would separate Wikipedia's scum from style issues of lesser-importance.

Objections, thoughts? Thanks, Jamie^☆S93 01:30, 1 July 2009 (UTC)

Don't know if "scum" is the best term, but it's a sound idea. Possibly Category:Articles with a promotional tone (hidden, of course). ▫ JohnnyMrNinja 05:41, 1 July 2009 (UTC)

Yes, something like that. :-) I'm not usually one to put labels on articles, but those {{advert}} pages are sometimes kind of bad, and it may help to distinguish them. Jamie^☆S93 14:59, 1 July 2009 (UTC)

There's probably a few other templates that would use this new category as well: {{Newsrelease}}, etc. I like Category:Articles with a promotional tone (the 2nd suggestion) because it assumes the article is valid, but the tone needs to be edited, vs. saying the article is suspected to be inherently promotional (and possibly could never be un-promotional) - the domain of {{db-spam}}.Cander0000 (talk) 11:46, 5 July 2009 (UTC)

Move all Wikipedia: namespace pages in (disambiguation) format to /subpage format

I think this was brought up for the VP earlier, but I'd like to bring it up for all of EN. I think we should take full advantage of our software by moving all Wikipedia: namespace pages with (disambiguators) (pretty sure that's a real word) to /subpages. I mean to change pages like Wikipedia:Naming conventions (long lists) to Wikipedia:Naming conventions/Long lists. The benefit of the subpage is the backlink created at the top, a more consistent search criteria, and a clear hierarchy/grouping of policy pages. Article space is not hierarchical, but often times WP space is (notice the text of the template on the Manual of Style). I am well aware that "it ain't broke" and it is a "solution looking for a problem" (BTW, so was the laser), so please actually consider it before responding. The annoyance of actually moving the pages will be slight, and the appearance will IMO be more attractive and organic to an online encyclopedia. It's a shame and a waste to leave subpages for user "secret pages" and template documentation (and, of course, WP:AN/I). ▫ JohnnyMrNinja 05:12, 1 July 2009 (UTC)

By using disambiguators, we're matching our naming conventions for articles, which I don't think is a particularly bad thing. You already mention the "it ain't broke" argument, but really, that's what it comes down to. Your arguments aren't particularly compelling (the "search criteria" bit is a total non-issue, since it doesn't affect how one searches for anything in either direction). *shrug* I wouldn't be upset if it happened, but I just don't feel that passionate about it one way or the other. :) EVula // talk // ☯ // 21:05, 1 July 2009 (UTC)

My search comment was rather half-formed; they do affect the search when using a prefix: search, like in the box at the top of this page, although the two options (when properly titled) are very similar for this. This was more of a comment of support for subpages in general. The ethnic and religious conflicts is a great example of a page that has benefited form being moved to a subpage of WP:AN (from an unrelated title), with much increased traffic because of the clear association, which also falls under the same search parameters as WP:AN and WP:AN/I.

You mention that we would be using a different convention for WP page than article pages. This is a very good point. The use of parenthesis down-plays a word. There is no game called Conan (2007 video game), it is a game called Conan that we have disambiguated. Conan/2007 video game would be improper, putting undue weight on the made-up qualifier. Wikipedia-namespace pages are totally different. These pages are 100% self-referential. Wikipedia:Manual of Style (biographies) is called Wikipedia:Manual of Style (biographies). There is no reason to down-play the thing that makes a WP page unique, and that particular page would sit better at Wikipedia:Manual of Style/Biographies. ▫ JohnnyMrNinja 04:32, 2 July 2009 (UTC)

How is that going to work where the disambiguation page itself is not located at the primary topic, and other pages naturally located on the disambiguation page do not have disambiguators - e.g. George Washington (disambiguation) and George Washington University, which is certainly ambiguous, but is the official name of the institution, making it inappropriate to locate it at "George Washington (University)" for example. bd2412 T 04:43, 2 July 2009 (UTC)

There is no need to move most of the pages in that format. Keep in mind that I am only talking about project pages here, not articles. I don't think that WP:Administrators' noticeboard should be a subpage of WP:Administrators even though they start with the same word. Some articles with different titles would do well as subpages, but those should really be handled on a case-by-case basis. For now I am only talking about pages that actually have disambiguators. If you are talking about articles, I think that subpages for articles are a very bad idea. ▫ JohnnyMrNinja 13:25, 2 July 2009 (UTC)

I agree with JohnnyMrNinja - This page, for example, isn't a disambiguated page from Village pump, it's a subpage of it. George Washington (disambiguation) isn't a subpage of George Washington. עוד מישהו Od Mishehu 07:11, 2 July 2009 (UTC)

It looks like some small consensus is forming, but it certainly isn't formed yet. I'll ask around for some more opinions. ▫ JohnnyMrNinja 02:16, 7 July 2009 (UTC)

This seems reasonable for things like the VP, MOS, naming conventions, etc. It really makes more sense then the current setup, IMO, and some pages like Project:Reference desk already use subpages. –Drilnoth (T • C • L) 02:28, 7 July 2009 (UTC)

I also think this seems reasonable, but I don't think it's that urgent. I won't object if people start doing this. As long as the same shortcuts we're all familiar with redirect to the same guidelines they've always pointed to, it really doesn't matter to me.--Aervanath (talk) 03:29, 7 July 2009 (UTC)

Thanks for clearing up the section title. It was not my intention to imply any urgency in applying any consensus. I wanted people to respond before this dropped off the page. :) ▫ JohnnyMrNinja 03:34, 7 July 2009 (UTC)

Designate a place (colored box?) on discussion pages for hyperlinks to relevant, encyclopedic, public-domain sources

Last night I spent a few hours pasting public-domain sources into talk pages. To get people's attention, I created a section entitled "encyclopedic, public domain source(s)! Please assimilate!", and listed the hyperlinks there. E.g., Talk:Economy of Israel Talk:Au pair Talk:Estuary. (My next step is to make a single list of the 100 pages I've done this to, for wide circulation.)

My proposal is that we sanction this practice on one of the Guidelines pages, so that more people get involved in creating such lists: "Discussion pages may include a list of relevant, encyclopedic, public-domain hyperlinks in a permanent, designated, box, which should then be linked to on a separate outside page." Is this something you guys think would be useful? Agradman ^talk/_contribs 17:58, 1 July 2009 (UTC)

WP:Avoid instruction creep. Just do it, and if people complain discuss it. IIRC, when this sort of proposal has been made in the past people have suggested just putting it in {{todo}} or the like, if for some reason a normal talk page section isn't good enough (most articles' talk pages are seldom if ever archived, so it's not like the talk page section is all that likely to disappear). Anomie⚔ 18:20, 1 July 2009 (UTC)

Creating a box for that is an excellent idea, so I went ahead and created {{Refideas}}. It has a wider use... in addition to listing things like PD resources, other references which may be useful in the future can be included. –Drilnoth (T • C • L) 20:09, 1 July 2009 (UTC)

oooh, that's classy. Here are a few suggestions:

1) Somehow, it should draw attention to Public Domain sources, because they can be adapted with a minimum effort.

2) Wikipedia will improve even quicker if there were a list of "pages containing non-integrated PD sources", where people could go to mindlessly integrate PD content. (e.g. it took me 20 minutes last night to create "House Minority Leader", which was previously a redirect to a list of party leaders, using a government research report.) That's one reason why I, personally, would prefer the template to focus on PD sources -- such a list will be generated from the pages it's on. (Otherwise, the box will just be moving things from "external links" to the talk page, which is somewhat useful but less so.)Agradman ^talk/_contribs 20:21, 1 July 2009 (UTC)

Hmm... I see your reasoning. I need to log off for awhile but will add this to the template later today in a way that makes both of these possible. –Drilnoth (T • C • L) 20:28, 1 July 2009 (UTC)

 Done. See the documentation for details. –Drilnoth (T • C • L) 21:57, 1 July 2009 (UTC)

Wow I'm stunned. Not only have you done beautiful work, but you did it really quickly, and you made my idea feel welcome. I'll wait until we hear feedback from a few other editors before I start slapping this on pages, but in the meantime, I'm going barnstar shopping. Agradman ^talk/_contribs 22:16, 1 July 2009 (UTC)

Thanks. :) Anyway, I think it would be safe to just start using the template... mentioning it in a guideline or policy would need a good bit of consensus, but using the template seems to make more sense then just making new sections on talk pages, so why not? –Drilnoth (T • C • L) 22:35, 1 July 2009 (UTC)

(outdent) Agree with Drilnoth; finding reliable sources is already a laudable goal, and I highly doubt that anyone will object to you providing sources for them, since that saves them the work of going out and finding them. Be bold!--Aervanath (talk) 03:41, 7 July 2009 (UTC)

Bots fixing redirects in navboxes

When a navbox contains a redirected link, it is displayed in purple when you are on the page it redirects to, as opposed to bold, black text (not linked) if it had been a direct link. It seems to me that the task of fixing these redirected links in the navboxes to point to the page itself (by piping it) is something that a bot could be able to do. So if such a bot task doesn't already exist, I make a proposal about it. Iceblock (talk) 18:31, 1 July 2009 (UTC)

I'm neutral on this, since I have a userscript that highlights self-redirects anyway. Bringing it here first is a good idea, as such a bot needs a strong community consensus before being approved. Anomie⚔ 02:08, 2 July 2009 (UTC)

I'd really like to see this bot. This is one of the exceptions at WP:R2D that should be fixed, as it causes confusing self-linking-redirects. –Drilnoth (T • C • L) 02:15, 2 July 2009 (UTC)

usage of pagination + limit on size of pages

This is a suggestion for improvement. It would be good to impose or recommend some limit on the size or length of Wikipedia pages. For mobile users, big pages are problematic. Long articles have to be paginated. Thanks for considering this post. Louenas

Our current guidelines are at WP:SIZE. You can discuss potential changes on the talk page. Algebraist 20:59, 1 July 2009 (UTC)

Three (instead of four) template warnings for users before reporting

Based on my brief vandal-hunting experience I think that the current warning system issues one too many warnings to users before blocks are issued. Once a user gets a L-3 or an L-4 warning for vandalism for instance, that user's (normally a vandal) next target is usually the warner's talk page or user page in the form of userpage vandalism. More often than not, this delays the process in processing persistent vandals for blocking as they normally must receive four warnings for a block. I would propose lowering the number of warnings before sending to an admin-related venue (such as WP:AIV) from four to three along with slight adjustments in the wordings of the templates to accomodate that change. Any thoughts? MuZemike 23:02, 1 July 2009 (UTC)

Counting warnings is simple, but I can't say that I'm personally a fan of it as a primary heuristic for blocking. For quite a long time, now, I've held firmly to the belief that warnings are intended to bridge the gap between our need to assume good faith and our need to protect the project; we can allow users some time to experiment, to get accustomed to our rules and customs, sometimes even to act out negatively and learn the error of their ways, but sometimes (typically with vandals) it becomes clear that the user is intent on egregiously violating good faith to the maximum extent they can think to manage. Once that's clear -- sometimes that takes a few warnings, in rare cases like pattern harassment it's clear from the first edit -- I say block away. – Luna Santin (talk) 23:42, 1 July 2009 (UTC)

Per Luna Santin's comment, there's never been an obligation to give a certain specific number of warnings prior to issuing a block. Not four, not three — in egregious cases, not even one. We use common sense. I don't spend much (any) time at WP:AIV, but I certainly hope that they're not insisting on four warnings before blocking obvious vandals. The reason why we have four different warning templates is to allow us to 'tune' the warning message to the circumstances, not to compel vandal fighters to issue all four warnings. TenOfAllTrades(talk) 23:55, 1 July 2009 (UTC)

It is true, the degrees of warning are to deal with the different situations. Warnings are not required, just often the best way to go. Some admins at AIV will remove reports that don't have a full set of warnings, but AIV does things its own way. Chillum 23:56, 1 July 2009 (UTC)

¶ I don't think I've ever used one of those templates, because either

1. (as with the nearly-identical IP attacks on Michael Bloomberg last month), there just didn't seem to be any point, other than procedural, to issuing such warnings, or
2. when a warning was warranted, I preferred to wrap it into a general explanation of why I'm reverting something. The official authoritative style of the templates succeeds sometimes in scaring away malefactors, but just as often provokes a defiant rebelliousness that simply escalates the situation and wastes lots of time and heartache.

In a couple of cases of spamming, it seemed worth taking half an hour to compose an explanation of why a newcomer's well-intended contributions didn't fit Wikipedia. This stopped the edit war without the need for administrative action, and left us with someone who was well-intentioned towards Wikipedia instead of hostile. [Half an hour is a lot of wiki-time (especially for those working from a library or Internet café), but almost as much time would have been spent in posting warnings notifying administrators, arguing cases, stopping sock-puppets, etc.] See User talk:69.132.178.111 and User talk:Shakescene#Thank you. —— Shakescene (talk) 00:37, 2 July 2009 (UTC)

Of course, one doesn't necessarily need to go through lvl1, lvl2, lvl3, lvl4 and lvl4im warnings. It depends on the nature of the vandalism and the editors' edit history and block history. General experimenting of the "can I really do this" type as a first edit warrents a lvl 1 warning. If a first edit is adding a string of obscenities or similar I tend to issue a lvl 3 warning (yes, a bit harsh, but better to stamp it out early). Those with lots of previous blocks are likely to get a lvl4 or lvl4im warning. Further vandalism is then reported at WP:AIV for admin action. Mjroots (talk) 06:08, 2 July 2009 (UTC)

IMO the templates are useless because their wording is wimpish and inflexible. I use my own "template" which I paste in, with changes as needed:

==Vandalism warning==

[(diff) This edit] to [[(page)]] was [[wp:vandalism|vandalism]] - stop it or you will be blocked. --~~~~

Then whether I report it depends on the vandal's previous record as shown by his / her Talk page and contribs, and by the severity of the incident I'm dealing with. If I report, I may summarise the Talk page and link to contribs. --Philcha (talk) 06:20, 2 July 2009 (UTC)

"wimpish" is a good description for the spirit of our "esteemed vandal" templates. Perhaps they need an optional paramenter "testosterone=yes"? :) --dab (𒁳) 06:36, 2 July 2009 (UTC)

Proposing a re-design of the editing toolbar

Hi folks! Okay, before I begin, I understand this is going to be potentially controversial, as the current design has stood for many years now. But what I would like to do — bear with me here — is propose that we alter (purely in aesthetic terms) the way those handy buttons above every edit window look. Currently, I feel they are not pretty at all; a sort of throwback to the Netscape era, and it seems odd to me they've existed in their current form as long as they have. Many of them were designed at different times (possibly by different people?) and so have a real mish-mash of graphical styles.

Apart from their (admittedly highly subjective) ugliness, many of images are a little confusing given what they are meant to represent. The bold and italic buttons make sense, sure, but what's with the 'small' button?! The gallery button does not at all suggest a selection of pictures (the same could be said for the quote button), and mine only ever be a guess as to what that trumpet is supposed to be signalling (that button brings up videos..?). What's the big 'A' for? In my opinion, the best buttons are those that give their function in words on the button. The <ref> button is marvellous, and I wonder, why can't the rest be designed in its image? Thus, I am proposing that the following re-design be considered:

Proposed redesign of editing buttons (with current above, for contrast)

In my example above, if you look closely, you can see that the buttons in my proposal are of the exact same height and in the exact same order as the buttons before (so that hopefully should lessen the impact on the various scripts users use to alter their positions and whatnot). They also use the Wikipedia standard colour palette in their borders and individual backgrounds, and so sit more comfortably in the website design. They are also wider, as I feel it seems silly to have them all shoved together in the corner, when there's even room to spare with my design on non-widescreen computer screens. This gives more room-per-button to explain what they do, and makes it easier for the pointer to meet with its desired destination.

I understand we might need to convince the developers to help if this were to be implemented, and that is always a hurdle. And before you all hurriedly say, I know that a quick mouse-over will elucidate each button's function, but why should we have to work to suss out the interface? It makes sense, given our utter reliance on new people being attracted to edit, that this encyclopaedia be as user-friendly as possible. Anxietycello (talk) 02:22, 2 July 2009 (UTC)

There's a new editing toolbar option that was just enabled for testing, see the "Enable enhanced editing toolbar" option in preferences. Mr.Z-man 02:47, 2 July 2009 (UTC)

Oh, darnit. It's really quite good... Hmph. Anxietycello (talk) 02:53, 2 July 2009 (UTC)

I see some improvements, but it's really not quite intuitive enough for me. Examples are subscript, superscript, redirect, footnote. Anything that makes it clear that the wikilink button won't underline has to be counted a vast improvement. —— Shakescene (talk) 04:47, 2 July 2009 (UTC)

Can I ask, where was the editing toolbar that's now being previewed discussed? And when is it likely to be rolled out for all users? Anxietycello (talk) 19:38, 2 July 2009 (UTC)

Someone donated $890k to improve the editing interface, so the WMF made it so. It's already rolled out, but you have to opt in. It is still experimental software, so not available to IPs yet. As for feedback, go to [3]. MER-C 03:42, 3 July 2009 (UTC)

• I'm all for a facelift of the toolbar, but not one where it's larger in size. I'd like a few mockups to choose from to be honest. Also don't forget about the additional buttons some of us use, eg the "cite" button, etc. Nja²⁴⁷ 09:29, 5 July 2009 (UTC)

Do not delete before the New Pages Patrol has reviewed an article

Proposal: This is a request to allow the New Pages Patrol (NPP) to review an article before it is deleted and/or moved without a disambiguation. This means that the page cannot be marked as patrolled, and stays in the system for much longer, requiring a longer wait for articles that need to be reviewed. --Gosox5555 (talk) 12:48, 2 July 2009 (UTC)

Can't the problems be addressed by technical improvements to the patrolling feature? Deleted pages obviously don't need to be reviewed any more, so it's pretty pointless to mark them as patrolled. Kusma (talk) 13:10, 2 July 2009 (UTC)

NPP is just regular editors and admins. There's no real difference between the page being reviewed by someone on the list and someone who isn't. Mr.Z-man 14:20, 2 July 2009 (UTC)

Wouldn't the easiest thing to do just to be changing the software so deletion automatically counts as patrolling? I think it's safe to call a deleted page patrolled no matter what. Changing the patrolling software itself would probably be a lot more hassle. JohnnyMrNinja 19:31, 2 July 2009 (UTC)

Its all the same software. Whether or not a page is patrolled only means anything on Special:Newpages, and its removed from there once its deleted. Mr.Z-man 19:51, 2 July 2009 (UTC)

I thought the point was that these pages aren't being removed from the list? ▫ JohnnyMrNinja 19:54, 2 July 2009 (UTC)

They aren’t removed until they are clicked as reviewed on the pages. Most of the time these pages are just moved, not deleted.--Gosox5555 (talk) 21:23, 2 July 2009 (UTC)

A deleted page cannot be marked as patrolled because there's nothing to patrol. The "patrolled" status is only recorded in the recentchanges table (which is what newpages uses). When a page is patrolled, the page itself is not patrolled, just the recentchanges entry for the page creation. Mr.Z-man 00:38, 3 July 2009 (UTC)

Maybe my wording was confusing. I'm not saying that they should. If there was a way to mark a page as patrolled from Special:NewPages, that would solve my problem. Or if you didn't have to be coming directly from Special:NewPages to click the button. Is this possible? Gosox5555 (talk) 14:24, 3 July 2009 (UTC)

Even an admin on NPP should probably tag for CSD (except in obvious circumstances which I will not go into here) and allow another admin to carry out the article's deletion. The same goes for any other user, regardless of user rights. That's my take. MuZemike 07:22, 3 July 2009 (UTC)

Why is that necessary? NPPatrollers tag the article with a CSD tag and an admin reviews it later. An admin has the technical ability to delete it straight away. If an admin is pretty sure and not certain, tagging for a second review is fine, but to enforce a rule that all admins tag articles they patrol is a bit pointless in my opinion. PeterSymonds (talk) 07:43, 3 July 2009 (UTC)

MuZemike: you might want to gain consensus to change CSD then. "The criteria for speedy deletion specify the limited cases in which administrators may, at their discretion, bypass deletion discussion and immediately delete Wikipedia pages or media."

Gosox5555: I don't see any real benefit from this, and plenty of drawbacks. Stifle (talk) 08:12, 3 July 2009 (UTC)

(edit conflict) That's what I was getting at the clearly blatant stuff (such as copyvios, attack pages, or most things under the "G" criteria). I think I was more referring to the other CSD criteria, such as A7, R3, stuff that may possibly be more debatable. You're right that it would not be anything enforceable, as that's how the nature of CSD is. However, I think that the role of "CSD tagger" should not be intertwined with "CSD deleter"; that is, you're simply CSD tagging or you're simply CSD deleting without overlap (the WP:ADMIN policy is clear in that you obviously cannot do both to the same article). That's what I hope I mean, MuZemike 08:16, 3 July 2009 (UTC)

That is, not in close proximitity or in which the admin may be involved, of course. MuZemike 08:18, 3 July 2009 (UTC)

(ec)Well, on the limited occasions when I get to do NPP any more, I delete pages straight away when I'm clear that they are CSD-eligible, and tag them if I'm not all that sure. I don't tag a page and then delete it, but only because it'd be a waste of time. Stifle (talk) 08:19, 3 July 2009 (UTC)

And indeed, I don't (or try not to) do speedy deletions in the (limited) areas where I could be considered impartial. Stifle (talk) 08:20, 3 July 2009 (UTC)

To veer back on topic, I don't think NPP should be able to patrol before a deletion occurs, as many articles fall through the cracks anyway. Furthermore, many users to tag NewPages for CSD also use Twinkle which automatically patrols the page right there. Assuming good faith, the tagger has already effectively patrolled that article. I cannot see what else that would need to be done besides go on regular editing/improvement of the article should the CSD be made in error which does happen occasionally. MuZemike 08:24, 3 July 2009 (UTC)

The proposal doesn't even make much sense. Anyone can do NPP (though only autoconfirmed users can mark pages as patrolled). If the page is deleted, then that means someone reviewed it. Who cares if they've self-identified as a new page patroller? Mr.Z-man 16:14, 3 July 2009 (UTC)

Agree with Mr.Z-man. Do you think members of NPP are granted some magic power that makes them more qualified than the original tagger and the deleting admin to judge the merits of the page? – iridescent 16:28, 3 July 2009 (UTC)

The problem, again, is that the pages cannot be marked as "patrolled" on the recent changes table once they have been deleted. So every person at NPP sees an article to be patrolled, clicks on it, can't find it, and figures out that it's already gone. It is a very small waste of time, but if you consider how many people do NPP, and how many new articles are speedied, it amounts to a fair chunk. This is time they are wasting not catching other problem articles. The only quick fix I can think of would be JS. Does twinkle automatically mark any page as patrolled that is tagged for CSD, or only if that person is doing NPP? Also, would it be possible to write a script that would mark a page as patrolled on the recent changes table when the admin deleted it? ▫ JohnnyMrNinja 19:59, 3 July 2009 (UTC)

No, that's not a problem, all entries a page (except log entries) are deleted from the recentchanges table when the page is deleted.

Change search message, please

If you search for a term that is not the title of an article (as in this), you get that remarkably chirpy message Create the page "Paradiso girls" on this wiki!. In bold. With an exclamation point. Phrased as a command. All this, despite the fact that the article has been deleted seven times and is create-protected. Can someone tone down the message to something more like There is no article by that name. Look over the search results below, and if you feel our coverage is inadequate, consider creating an article about the search term .—Kww(talk) 04:05, 3 July 2009 (UTC)

MediaWiki:Searchmenu-new is the relevant page. Algebraist 04:09, 3 July 2009 (UTC)

• Changed to "You may create the page "[name]", but consider checking the search results below to see whether it is already covered." Stifle (talk) 08:16, 3 July 2009 (UTC)

I was going to say that given the number of deleted articles, that message which was there before seemed too encouraging to newcomers.Vchimpanzee · talk · contributions · 17:11, 3 July 2009 (UTC)

Well caught, I've thought about this before but never thought about actually trying to get something done about it. Dougweller (talk) 17:56, 3 July 2009 (UTC)

External Links and "nofollow"

Instead of adding the rel="nofollow" attribut value to every external link, you could add a timestamp for every external link that is placed in an article and if its timestamp is older than one year, you remove the nofollow attribut value. Every time a link is removed the timestamp is refreshed. This avoids spam and supports external sites we trust.

I'm not sure how viable that is, but it'd need to go to bugzilla:. Stifle (talk) 08:17, 3 July 2009 (UTC)

It won't be a big challenge to realize. bugzilla: One of the wikimedia foundation staff advised me by email, to publish this feature (its not a bug) here. Marc 11:37, 3 July 2009 (UTC)

Why would this be a good idea? The purpose of wikipedia is not to "support external sites we trust", it's to create a free encyclopedia free from the influence of self-motivated parties, which includes SEOs and spammers. We don't need to give them the hope that, if they spam a sufficiently obscure and insignificant page with their links, they might last long enough to be registered by google. That's asking for trouble. Happy‑melon 13:34, 3 July 2009 (UTC)

• Strong Oppose - Unclear benefit with obvious encouragement of even more bad behaviour by those who would use WP as an SEO and promotional opportunity. Delicious carbuncle (talk) 13:39, 3 July 2009 (UTC)
• Oppose as having no valid justification that conforms with Wikipedia's goals and because it would increase amount of stealth spam added. DreamGuy (talk) 14:42, 3 July 2009 (UTC)
• Oppose per Happy-melon. This would have the effect of generating large amounts of spam on minor-topic pages. It would also be apt to break if there is page- or section-blanking vandalism at any point during the year, substantial article revision, article merges/redirects, or conversions to summary style. This feature would only work 'properly' on pages which were both heavily-watched and seldom edited. That's a pretty small pool of articles. (It might work on Featured Articles, but I don't really want to impose link evaluation and endorsement as another criterion for the FA reviewers.) TenOfAllTrades(talk) 15:28, 3 July 2009 (UTC)
• Definite oppose. We're not here as a service to PageRank. A proposal with no merits whatsoever and plenty of glaring drawbacks. – iridescent 16:30, 3 July 2009 (UTC)
• Oppose - Plenty of drawbacks and minimal, if any, benefit to Wikipedia. Mr.Z-man 16:45, 3 July 2009 (UTC)
• Sounds great, but won't happen now. Eventually Google will start ignoring our nofollows, and the we'll have to deal with it. --Apoc2400 (talk) 10:34, 5 July 2009 (UTC)

  Google has nothing to gain from ignoring our nofollows. They are search engine, their commercial viability comes from selling all that advertising. What's the point in SEOs paying for all those pay-per-click sponsored listings when they can just spam Wikipedia with links and jump straight to the top of the listings anyway? Google hates SEOs and spammers as much as we do. Happy‑melon 11:03, 5 July 2009 (UTC)

  Google also need to provide good search results, or they wont have any viewers and no ad impressions to sell. Web pages linked from Wikipedia are probably in general quite good. I think Wikipedia should work with Google and other search providers to help them get the best use of Wikipedia. Something like the original idea here. --Apoc2400 (talk) 13:59, 5 July 2009 (UTC)

  Some years ago, Google explicitly encouraged WMF to adopt rel=nofollow. Dragons flight (talk) 18:11, 6 July 2009 (UTC)

• Oppose Insufficient reward for risk required. MBisanz ^talk 18:18, 6 July 2009 (UTC)

Clicking on contribution history should lead to section

If a person posted on a help desk or village pump, you can imagine how hard it is to get back to the specific section where the post was. Where the section is in the user's contribution history, the section name should be blue so you can click on it and go right to the section.Vchimpanzee · talk · contributions · 17:09, 3 July 2009 (UTC)

You already can do that. Click on the → symbol at the beginning of the edit summary. --Floquenbeam (talk) 17:12, 3 July 2009 (UTC)

Thanks. I didn't know that.Vchimpanzee · talk · contributions · 18:22, 3 July 2009 (UTC)

I only just found out from this (after 15 months on Wikipedia) that you can do the same thing in watchlists and histories. I didn't realize (or had perhaps forgotten) that the arrow is a link rather than just punctuation. But as with the mysterious "cur" and "prev", this is something that perhaps one editor in ten or twenty or fifty understands. I'm sure if I'd read, digested and remembered the dozens of help pages that are offered, I could have learned much sooner, but like most people I haven't had the inclination or patience to do so. So I wonder what the solution is? —— Shakescene (talk) 18:29, 5 July 2009 (UTC)

Language articles

Hi all - just been looking at Tajik language, and wonder whether it might be worth adding a block of identical text to each article on a language. Often you get a feel for how a language appears from a simple block of text. If we could come up with a standard short paragraph in English and add it in both English and the subject language to each article, it might be worthwhile. (Of course, that raises the question "what would the paragraph be?"...) Grutness...wha? 01:41, 5 July 2009 (UTC)

Believe it or not, the "lord's prayer" is commonly used for this purpose, see examples. — CharlotteWebb 02:44, 5 July 2009 (UTC)

I wondered about that, but thought it might be inappropriate to use a religious text (I can imagine the speakers of some Middle Eastern languages might object to the use of the Lord's prayer, for instance). Perhaps something like the preamble to the United Nations Charter might be more neutral. Grutness...wha? 01:35, 6 July 2009 (UTC)

Definite Support: for the reasons listed above, this would be extremely useful. Asdfhgjgiewiuweroiuwer (talk) 09:34, 5 July 2009 (UTC)

Add Uploader to the list of rights admins can assign

bugzilla:19535

Wikipedia:Uploaders is a rarely used usergroup that only ever had one member since its inception in November 2008. Nevertheless, I had to flag down a steward to remove the right from the now inactive user it was created for. Lar suggested that it be added into the list of rights grantable/retractable by admins. At the very least, bureaucrats should be able to assign and remove it. This is a precursor to a bugzilla (that I hope someone else will file) to ensure consensus exists for this. –xeno^talk 02:55, 5 July 2009 (UTC)

• Support (since I suggested it be made such a right on my talk) The uses of this right are fairly limited, since it's a way to jumpstart autoconfirmed status, but having to find a steward to add it and then again to remove it make it even less useful. As for filing a Bugzilla , it's not that scary, but I'll either mentor Xeno on it or do it myself (or laze, and someone else will :) ... my usual strategy ) if this meets with sufficient approval. Hopefully this is fairly low controversy... ++Lar: t/c 03:08, 5 July 2009 (UTC)

  Oh, I'm sure I could figure it out. I'm just quite lazy, as well. It might be a good idea to discuss whether adding "edit semi protected pages" to this user group and make it into a true "autoconfirmed starter kit" is a good idea - to make it slightly more useful and less rarely used. –xeno^talk 03:13, 5 July 2009 (UTC)

  I've split this into a subsection below: #add edit-semi as a feature to "Uploader"?. There seems to be consensus at least to add "Uploader" as-is to the rights grantable/retractable by admins, so I'll file a bugzilla shortly unless someone else does/already has. –xeno^talk 15:12, 5 July 2009 (UTC)  Done bugzilla:19535 –xeno^talk 17:58, 5 July 2009 (UTC)

• Comment From the linked page, Normally when a user signs up they have to wait four days and make ten edits before they become autoconfirmed. Autoconfirmed users have the ability to edit semi-protected pages and upload files. So it seems anyone with a registered account gets this automatically after 4 days and 10 edits. So what's being asked here beyond just leaving it alone and registered accounts auto-getting it after the said 4 days/10 edits? - ALLST✰R▼^echo _{wuz here} 03:25, 5 July 2009 (UTC)

  The main proposal is to give the ability to assign the right to admins. The secondary proposal, as an aside, is whether we should add the ability to edit semi protected pages in there. As to why we didn't just tell the person to wait four days and make ten dummy edits - you got me. However, I think with the edit-semi added in there, the right would be more useful. I have, at least once, lowered semi on a page so a brand new user could edit it. Instead, I could've just granted him the right for the first four days. –xeno^talk 03:28, 5 July 2009 (UTC)

But why do admins need the ability to assign the right to upload/edit semi-protected pages, if the user automatically gets that right anyway after 4 days/10 edits? Shouldn't this be more about giving the admins the right to remove these features from users who are abusing them (copyvios, etc.)? - ALLST✰R▼^echo _{wuz here} 03:35, 5 July 2009 (UTC)

The right exists, it should be grantable by admin staff, be it an admin, or a bureaucrat. Stewards are supposed to be for-emergencies-only. Luckily Lar has a few hats so I knew he could use his en.wiki admin hat to come to the conclusion it was reasonable to remove it from the one user who held it, and his global steward hat to actually do it. But it was sub-optimal. Just to be clear: this won't change the way admins can act on users who are autoconfirmed, and we won't be able to remove an autoconfirm'd users' ability to upload files. It is just about giving us the ability to grant and retract the "Uploader" userright (which becomes redundant and useless once someone has autoconfirmed). –xeno^talk 03:39, 5 July 2009 (UTC)

@Allstarecho: Brion created this right last year, in order to circumvent the delay for a given user to be able to upload (for good reason, as I understand it). If this sort of circumvention would be useful in the general case, then having stewards required to grant it and remove it, reduces its usefulness. I can think of situations where time is of the essence... someone from a museum, ad agency, PR outfit, charity, etc., contacts us, hot to make content contributions, (perhaps of something urgent) and then has to wait 4 days. It would be useful for an admin to be able to evaluate the request and enable them right then. As it stands now, the difference is that it requires a steward. This ISN'T about taking the uploader right away, it's about who can grant it. ++Lar: t/c 03:32, 5 July 2009 (UTC)

@Xeno: I don't favor that. ++Lar: t/c 03:32, 5 July 2009 (UTC)Let me clarify this a bit... I think the idea is not bad (your example of enabling a particular user instead of "dropping the fence" on an article, is a good one) but I'd rather stay focused on who can grant the existing right, as it's constituted, and consider changing it separately. We seem to have a problem with focus of the request as it is. ++Lar: t/c 03:55, 5 July 2009 (UTC)

So basically circumventing the 4 day/10 edits rule which I'm sure was put in place for a good reason as well, no? - ALLST✰R▼^echo _{wuz here} 03:35, 5 July 2009 (UTC)

Correct. Circumventing a rule when in the considered judgment of (someone) it makes sense to do so. The rule is circumventable now. If you think it shouldn't be, go talk to Brion. We're talking about who (someone) should be. Right now it's me and other stewards, which is cool by me but I figured why just stewards. ++Lar: t/c 03:46, 5 July 2009 (UTC)

And further, if an admin were to grant this userright they would be reasonably expected to look over the user's uploads and ensure they met image policy. –xeno^talk 03:48, 5 July 2009 (UTC)

Exactly. It's on the admin's head to make sure it was used wisely. ++Lar: t/c 03:55, 5 July 2009 (UTC)

I'm not married to the idea of adding edit-semi in there, but I figured I would throw it out there. –xeno^talk 03:39, 5 July 2009 (UTC)

• I can't really think of a situation where I would want to assign this right. Obviously that means I'm not terribly creative, because a situation assuredly exists, but I'm straining. I guess if I knew the human behind the account name and they had some file they needed to upload. But apart from that I'm straining to see the purpose. I mean, the feature itself isn't unwise or deleterious. Just not terribly necessary. But that isn't a resounding vote of opposition, more of a comment. Protonk (talk) 04:51, 5 July 2009 (UTC)

  Allowing users who have emailed permissions to OTRS to upload rather than doing it for them springs to mind. BJ^Talk 06:22, 5 July 2009 (UTC)

They couldn't just wait the 4 days/10 edits? - ALLST✰R▼^echo _{wuz here} 06:26, 5 July 2009 (UTC)

I'm wondering how many times this needs to be explained to you. The right exists now. I can go create a brand new account, and grant it this right... right this very second. But xeno can't. That's because he's not a steward. This discussion is about broadening who can grant the right. It is NOT whether the right should exist or not, or whether waiting 4 days is an acceptable alternative. Please address your concerns to why admins should not be able to grant this right (given that stewards can). Thanks. ++Lar: t/c 16:22, 5 July 2009 (UTC)

If somebody is willing to release an image they own the rights to in order to improve one of our articles, but otherwise has no interest in making content adjustments, it seems rather odd to tell them that they cannot add the image or that they must jump through hoops by waiting 4 days/changing content 10 times before they can contribute their image. That said, I doubt I'll ever add this usergroup but that doesn't mean having the ability would be a bad thing. --auburnpilot talk 14:10, 5 July 2009 (UTC)

• Support uploader though semi-edit unneeded: It's (ie the uploader flag) useless otherwise. The requests could be made as they are now at requests for userrights and evaluated on a per need basis, just as rollback, IP block exemptions and other admin assignable rights are currently done. The fact that they can wait 4 days changes nothing when there's a legit need to do something earlier and I don't really see the issue since it will require admin discretion on whether to assign it or not, and as is the flag is useless (ie practically no one can assign or remove it). Abuse may well happen on occasion, but that's why we have close to 2,000 admins and many vigilant volunteers to spot it and report it to the proper noticeboard for blocks to be issued and/or removal of the flag. Nja²⁴⁷ 08:36, 5 July 2009 (UTC)
• Usecase: new bots. Very often a BRFA is filed for an interesting new task, discussion occurs, a trial is approved... and then the process stalls for four days because the bot operator registered a new account. 'uploader' will always be a temporary flag: it would be granted in these circumstances, and then replaced with the full bot flag when the bot is approved. Ditto for admins creating alternate accounts for use on holiday or whatever, and various other situations like this where the account is new, but the owner is trusted. As such, the permission should (to be of maximum use) exactly duplicate the functionality of 'autoconfirmed', and it should definitely be assignable (and removable once it has been superceded by the autoconfirmed autopromote ticker) by admins. It is a much less volatile group of permissions than groups like 'rollbacker' and 'ipblock-exempt', which admins are already trusted with. Happy‑melon 11:13, 5 July 2009 (UTC)
• Support for the purpose of bots, announced socks, things like that. I can't see the need to give this out to genuinely new users very often at all, but it would be nice to be able to bypass the formalities with a new account, but an old user. J Milburn (talk) 11:27, 5 July 2009 (UTC)
• Support, seems highly useful. Stifle (talk) 13:41, 5 July 2009 (UTC)
• Comment. An ideal solution would be to have an option to "force autoconfirmation" of a particular account. If it is not possible, than the creation of 'confirmed' usergroup with exactly the same userrights as 'autoconfirmed' would suffice. The last idea has already been discussed before. The 'uploader' is group is quite useless. Ruslik_Zero 15:02, 5 July 2009 (UTC)

  The below subsection seeks to expand "Uploader" (to the point where a rename might be useful, but that's extra grunt work) to include edit-semi. The other rights in autoconfirmed aren't really "first four-day critical" and would also make the right much more attractive to vandals and in turn force us to be stricter with granting the right. –xeno^talk 15:07, 5 July 2009 (UTC)

  I read this discussion and as I understand removing 'autoconfirmed' group from '$wgImplicitGroups' will allow (for instance) administrators to assign this group manually to accounts that do not satisfy autoconfirmation conditions (but not to remove it from accounts that do). Ruslik_Zero 15:37, 5 July 2009 (UTC)

  Yes, and giving a new user full autoconfirmed will allow a vandal to immediately go on a page-move vandalism spree. On the balance, I would rather grant the "autoconfirmed-lite" offered up by the below. –xeno^talk 15:40, 5 July 2009 (UTC)

  One would hope that we trust administrators with more judgement than to flag a vandal account. We're not talking about granting this to every man and his dog, here. Happy‑melon 15:50, 5 July 2009 (UTC)

  It would still increase the number of bad-faith requests we would have to deal with, and admins aren't immune to social engineering. I could see the value in doing it this way if we didn't already have a minimalist userright to tag it onto. –xeno^talk 16:34, 5 July 2009 (UTC)

  So for a budding pagemove vandal, option 1 is to convince an administrator that they are a bot account, a legitimate sock, or some other account owned by an already-trusted user, which we'd probably expect to be confirmed with cross-editing, or that they are an eager-beaver contributor whose uploads are going to be so amazing that everyone is going to be watching; while option 2 is to wait four days and make ten dummy edits? I know which option I would choose. Happy‑melon 17:11, 5 July 2009 (UTC)

  If you want to make an alternate proposal that would allow us to do away with the Uploader userright altogether by allowing admins to grant autoconfirmed, I'll support it - I just think it will be far easier to attain consensus to give us the ability to grant the expanded "Uploader" (at which point it should probably be renamed). –xeno^talk 18:01, 5 July 2009 (UTC)

• Support uploader. This comes up at the help desk occasionally. A new user has created an article and wants to upload an image for use in it but is stymied. By visiting the article we can easily determine whether granting the right is a good idea in the particular circumstance, and can question the user right there as to whether their image is free, and if not, whether it qualifies as fair use. Because of the immediacy of granting the right, whereas most users are left swimming even after they make their 4 days/10 edits threshold, if a user uploads shortly thereafter we can follow the upload, fix the FUR, etc. This type of natural follow-up is unlikely to be done after we've told them to wait four more days.--Fuhghettaboutit (talk) 16:55, 5 July 2009 (UTC)
• Support Seems like a good idea, and no one really seems to be against it (don't see why anyone would), so why not? hmwithτ 17:18, 5 July 2009 (UTC)
• Support, provided the right is removed once a user reaches auto-confirmed status. Nakon 17:35, 5 July 2009 (UTC)
• Support Yes it will be rarely needed, but right now the WP:BURO involved with assigning it makes it totally unhelpful whereas this small change would simply make it an obscure yet helpful feature, sort of like the global blocking whitelist and the flood flag at meta. MBisanz ^talk 18:05, 5 July 2009 (UTC)
• commentOne obvious use would be when an admin is teaching a new user in meatspace how to edit wikipedia.Genisock2 (talk) 18:24, 5 July 2009 (UTC)
• I think we should instead spend our effort into allowing users to be set as autoconfirmed by admins, rather than assigning individual rights from the autoconfirmed group. I oppose this proposal for that reason. See the subsection below - it has already started. Soon we'll be having polls on a regular basis to add random rights to the uploader group. Just allow admins to set a user as autoconfirmed. No need for individual rights. - Rjd0060 (talk) 18:27, 5 July 2009 (UTC)

  While that would be ideal, the rights remaining in autoconfirmed would be usable only in the minority of scenarios (saving books to user pages, anyone?), with the exception of the move right, which was the reason the autoconfirmed group was created in the first place. Titoxd^{(?!? - cool stuff)} 21:43, 5 July 2009 (UTC)

  I still see no reason to break up random rights when there is an alternate solution. - Rjd0060 (talk) 13:45, 6 July 2009 (UTC)

  The alternate solution gives the brand new user the right that the autoconfirm delay was specifically tailored for, namely, the ability to move pages. Brand new users rarely need to move pages and if they do, they can ping an administrator (or any autoconfirmed user) to do the move directly, or make a request at Wikipedia:RM#Requesting uncontroversial moves rather than applying for "force" autoconfirmed. –xeno^talk 13:55, 6 July 2009 (UTC)

  Indeed. However, that same argument works for the uploader rights too. Brand new users rarely need to upload files. I'm still in the thought that we should be able to set the autoconfirmed group (which I'd prefer) or make no changes and all users will need to wait to become autoconfirmed themselves. - Rjd0060 (talk) 14:01, 6 July 2009 (UTC)

  Just because it's rare doesn't mean it doesn't have occasional value. If you really want the ability to assign autoconfirmed, please propose it and I will support. –xeno^talk 14:08, 6 July 2009 (UTC)

• Support per MBisanz. –Juliancolton | ^Talk 18:36, 5 July 2009 (UTC)
• Support, it is a potentially-useful feature that already exists, but whose implementation obstructs its use. Titoxd^{(?!? - cool stuff)} 21:43, 5 July 2009 (UTC)
• Strong oppose – the current time-base and edit-threshold for becoming autoconfirmed were carefully set, after much discussion, and I see no reason why users should be able to leapfrog that probationary period. Patience (new users waiting to be able to upload etc.) has always worked in the past. ╟─TreasuryTag►consulate─╢ 21:48, 5 July 2009 (UTC)

• The right already exists. I can, as a steward, go give it to you right now (not that it would have any meaning to do so since you're already autoconfirmed, but I could), and then take it away again (not that taking it away would change by one iota what you can do). So your opposition is misplaced, you need to instead explain why you think stewards should be the only users to be able to grant it. Alternatively, you could start a different proposal to say you want the Uploaders group to go away entirely, but that isn't this proposal. Hope that helps, this seems to be a somewhat confusing point. ++Lar: t/c 23:15, 5 July 2009 (UTC)

• Given that it was created by a sysadmin for use by one account (and I know that was the case) I would assume that they just forgot to clean up after the user was done with the rights. There never was discussion to see if we even wanted or needed an uploader group. Yeah, stewards can assign it. So? They won't assign it so I don't really understand why that matters. - Rjd0060 (talk) 13:45, 6 July 2009 (UTC)

• Eh? I'm a steward... your argument doesn't follow. Unless a clear proposal comes down the pike and gains consensus (that this right is never to be assigned), any new user who turns up on my talk page and asks for the right, along with a good reason why, will get it from me. ++Lar: t/c 14:29, 6 July 2009 (UTC)

• I don't think that would be appropriate for a number of reasons and policies that you as a steward are expected to follow. But that is unrelated to this discussion so I won't elaborate. - Rjd0060 (talk) 17:48, 6 July 2009 (UTC)

• This is pretty much exactly why I proposed admins be able to assign this; because Lar, wearing his global steward hat, isn't supposed to be granting rights without direction from an en.wiki admin. Which of course, he is as well. So while he's "judge, jury, and executioner", it would be nice for him to just wear the one hat when granting or revoking this right. Of course, you want the right to go away altogether, but I still don't think that opposing this proposal is really a constructive way to go about that. –xeno^talk 18:24, 6 July 2009 (UTC)

• FWIW, opposing a minor proposal because you'd rather a major one doesn't make any sense to me. Baby steps. –xeno^talk 13:59, 6 July 2009 (UTC)

• Wasted time? Not only our time, but that of the system administrators who surely have better things to do than fulfill requests from the English Wikipedia who can't make up their mind. But thanks for the feedback. - Rjd0060 (talk) 14:03, 6 July 2009 (UTC)

• I'm told both of these sister proposals are very simple fixes. And other than your procedural oppose, and one from someone who apparently didn't read the several good reasons presented to issue this (both as-is and expanded) right, our mind is made up. –xeno^talk 14:39, 6 July 2009 (UTC)

• Support any way we can manually let people contribute before they are autoconfirmed. Chillum 14:03, 6 July 2009 (UTC)
• Oppose: You want to use an uploader group as a hack for an autoconfirmed group? I'd much rather see this hastily-implemented group removed altogether and possibly replaced at a future date with a proper solution for bypassing autoconfirmed status (essentially what Rjd0060 said above). --MZMcBride (talk) 14:43, 6 July 2009 (UTC)

  This seems to belong in the below section... That being said, would you still oppose if it was renamed "semiconfirmed" (or something)? Because it seems like "a solution for bypassing autoconfirmed status" by any other name would still smell as sweet. –xeno^talk 14:48, 6 July 2009 (UTC)

  Rollbacker, account creator, autopatroller, now uploader... they're all different ways of creating a trusted user group. If that's what you want, make that. (Though I'll note that this idea of a trusted user group is likely politically infeasible, which is why people resort to hacks like this.) These single-right user groups are getting ridiculous. --MZMcBride (talk) 15:06, 6 July 2009 (UTC)

• Oppose - if anything, the uploader group should be removed. Free images should be uploaded to commons, which doesn't have the autoconfirm restriction on uploads (primarily for this reason IIRC). So the only use case for this would be a new bot or a new user who already has non-free image experience from somewhere else, who has a pressing need to upload non-free images, both of which seem like kind of a stretch. Mr.Z-man 15:27, 6 July 2009 (UTC)

  ...and what of expanding and renaming it per the below? (I agree as it stands, it's close to useless) –xeno^talk 15:42, 6 July 2009 (UTC)

add edit-semi as a feature to "Uploader"?

Somewhat related previous discussion: Wikipedia:Village pump (proposals)/Archive 38#Allowing administrators to grant autoconfirmed status

So we can be sure what people are supporting. I also support adding edit-semi to "Uploader".

Potential uses: newly created bots approved for trial¹, legitimate socks², jump-starting a verified good-faith IP's new account onto a semi-protected page (i.e. to avoid having to lower semi)³, allowing brand new temporary accounts to bypass edit filters if large-scale cleanup projects are tripping good faith IPs up (think algae)⁴, ...

It would make it a much more useful usergroup, assignable at admin discretion for reasons to be determined at WT:PERM, to "jumpstart" autoconfirmed and removed after the autoconfirmed period ends. –xeno^talk 14:54, 5 July 2009 (UTC) potential uses added at 15:29, 5 July 2009 (UTC)

• Support, providing this is given only to "new" users who aren't actually new- there's no reason to wait before bots and legitimate socks can edit semi-protected articles. J Milburn (talk) 15:04, 5 July 2009 (UTC)
• Neutral; I don't see a compelling need for it, but there's nothing especially bad about it either. Stifle (talk) 15:06, 5 July 2009 (UTC)
• Support a useful tool that has very minimal associated risks. Much less of a big deal than some of the other flags admins are already entrusted to assign. Happy‑melon 15:53, 5 July 2009 (UTC)
• On reflection I support this. It's the right slice of rights to be able to grant temporarily. ++Lar: t/c 16:17, 5 July 2009 (UTC)
• Support Seems like a good idea to me. hmwithτ 17:19, 5 July 2009 (UTC)
• Since it seems to be coming out in favour, I've made note of this proposal in bugzilla:19535 filed for the above proposal with a caveat to check back for objections. –xeno^talk 17:58, 5 July 2009 (UTC)
• Oppose - for the same reason I opposed the uploader group all together. See here. - Rjd0060 (talk) 18:28, 5 July 2009 (UTC)
• Support, as this is effectively bypassing autoconfirmed, as I wrote above. Titoxd^{(?!? - cool stuff)} 21:43, 5 July 2009 (UTC)
• Strong oppose – the current time-base and edit-threshold for becoming autoconfirmed were carefully set, after much discussion, and I see no reason why users should be able to leapfrog that probationary period. Patience (new users waiting to be able to edit semi-protected pages etc.) has always worked in the past. ╟─TreasuryTag►consulate─╢ 21:48, 5 July 2009 (UTC)

  There's four good reasons listed above. –xeno^talk 02:13, 6 July 2009 (UTC)

  If an admin sees a productive user who is not auto-confirmed, then the admin can help the user be more productive and the encyclopedia grows. If a users fucks around with the exception, then they can be blocked and have the exception removed. I see no good reason put forth to no do this. I don't think the threshold was carefully set either, it may have been carefully set at first but it has not changed in years. Chillum 14:12, 6 July 2009 (UTC)

• Support very good idea. — Jake Wartenberg 00:20, 6 July 2009 (UTC)
• Support any way we can manually let people contribute before they are autoconfirmed. Chillum 14:03, 6 July 2009 (UTC)
• Oppose: Listen to Rjd. Stop the spread of bad hacks. --MZMcBride (talk) 14:46, 6 July 2009 (UTC)

  I have read the code that handles this stuff. It is actually very elegant. What do you mean by bad hack? Chillum 14:54, 6 July 2009 (UTC)

  If it's a "trusted user" group, call it that. But right now it's an "uploader" group with the purpose of bypassing the upload restrictions. Manipulating the software like this is a bad hack. --MZMcBride (talk) 15:06, 6 July 2009 (UTC)

  The autoconfirmed and upload userrights are explicitly granted to administrators so they can, in principle, perform these actions without the implicit 'autoconfirmed' group. Is this also a "bac hack"?? The whole permissions system was designed to allow a many-many mapping between permissions and groups, so that rights could be bundled up and parcelled out any which way. While I agree that the group is improperly named, that doesn't magically transform an entirely correct use of the software - to create a group with particular permissions that can be assigned to users - into a horrible hack. I also agree that the option to manually grant and revoke the implicit 'autoconfirmed' group is preferable. Once again (I remember you taking exactly the same stance with the edit-lead JS), just because a better solution could, at some distant and indeterminate point, be realised doesn't mean we should not make any movement to implement an intermediate solution. Happy‑melon 15:37, 6 July 2009 (UTC)

  Your logic is flawed. By allowing hacks to be implemented and used in place of proper solutions, all incentive to implement a proper solution is lost. Necessity is the mother of invention, as the saying goes. You're suggesting we use a bad hack to (seemingly) remove the necessity. When local bureaucrats can create (and modify) custom user groups and adding new groups doesn't require sysadmin intervention, and when there's a coherent proposal for a "trusted user" user group, I'll gladly support. Until then, I'm not going to settle for half-baked half-measures. Sorry. --MZMcBride (talk) 19:59, 6 July 2009 (UTC)

  This is not a hack, this is how the software was designed to work. This feature is already available with the regular software, this is about if we should use it. Chillum 22:34, 6 July 2009 (UTC)

• Oppose - the use case for this, while better than having "upload" alone, is still pretty questionable. For bots, if the bot account is created at the same time as the BRFA, chances are 4 days will pass before it starts a trial and unless its only going to be editing semi-protected pages, the odds of it needing to edit one in its first 10 edits are pretty small (only about 0.1% of all pages are semiprotected). For legitimate socks, people can just wait; just saying "legitimate socks" doesn't make it a use case - why would brand new legitimate socks need to edit semiprotected pages? The good-faith IP's new account is really the only use case that's somewhat sensible but it happens so infrequently, I really don't think it justifies it. For allowing new accounts to bypass some abuse filters, the abuse filter should be fixed or disabled so that it doesn't block edits that aren't bad. Either way, the filter would still need a temporary edit, to either exempt individual users, or exempt the group. We shouldn't set all the filters to ignore people in the temporary group as it would just be adding extra conditions that would have no effect 99.99% of the time. Additionally, the implementation is poor. Uploading files has even less use than editing semiprotected pages, so tacking this onto the "uploader" group is just silly (since it has nothing at all to do with uploading files). Mr.Z-man 15:54, 6 July 2009 (UTC)

  If this were carried, I would suggest a rename to "semiconfirmed" or something. –xeno^talk 15:57, 6 July 2009 (UTC)

• Oppose. I've read the stated rationales for this and I'm not convinced. FWIW, you cannot set an account to 'autoconfirmed' in any way, there's simply no part of the software that allows it. All of the groups based on autopromotion are this way. You would have to make a normal user group and give it the appropriate rights similar to how autoconfirmed is set up. ^demon^{[omg plz]} 18:39, 6 July 2009 (UTC)

That's what I assumed would have to be done. Thanks for the info. - Rjd0060 (talk) 19:02, 6 July 2009 (UTC)

Rebooting Wikiproject Spotlight

The Spotlight was a simple project where users choose an article for collaboration and work on its improvement in realtime via IRC on #wikipedia-spotlight. The project seized however a while ago and after a discussion on IRC we were thinking starting collaboration via the Spotlight again. If anyone's interested just login to #wikipedia-spotlight and where we will choose the next article to work on.--Diaa abdelmoneim (talk) 17:18, 5 July 2009 (UTC)

In the spirit of WP:BOLD, we have decided to try it; the channel is now active, and we are working on Marco Polo.

Please help - join the IRC channel.  Chzz  ►  15:05, 6 July 2009 (UTC)

Fix to "Pixelization"

I made those Engrish words a redirect to Pixelization: Mosaic censoring and Censoring mosaics.

Can someone fix the words "mosaic censoring" and "censoring mosaics" in some articles to "pixelization", "pixelized" or whatever? -- JSH-alive ^{talk • cont • mail} 10:03, 6 July 2009 (UTC)