Wikipedia:Village pump (proposals)/Archive 60

On the question of appropriateness, I agree with MBelgrano: as long as the comparison is not original, but has been done by reliable sources, then I don't see how

WP:NOT#INDISCRIMINATE would apply. On the question of utility, I agree with Tisane: a single well-organized comparison article can provide more information in a more accessible format than multiple separate lists. -- Black Falcon ^(talk

) 17:52, 24 March 2010 (UTC)

Hello all, I've just posted the proposal above. I know it's one of the "perennial proposals", but comments there would nonetheless be appreciated. Thanks!

) 02:49, 9 March 2010 (UTC)

Comments moved to Wikipedia talk:Administrator inactivity - discussion should continue there. –xenotalk 16:52, 25 March 2010 (UTC)
The following discussion has been closed. Please do not modify it.
Strong oppose. And this will solve what problem? People take wikibreaks. You want to penalize someone for returning? You want to set up new bureaucratic procedures for a non-problem? alteripse (talk) 19:53, 9 March 2010 (UTC) That idea is really stupid. We prefer to have admins for life. That's a much better idea. Angryapathy (talk) 19:58, 9 March 2010 (UTC) Please note that the proposal has nothing to do with the issue of "admins for life". It is about temporary removal of the sysop tools due to inactivity, to be reinstated without question upon an admin's return. -- Black Falcon (talk) 20:01, 9 March 2010 (UTC) It seems a good idea, unfortunately phrased. The start does indeed seem to tut-tut over admins who don't pull their weight, and one has to read through this to realize that the proposal is actually about something else. I'm still not sure that there is any problem, but I'm willing to believe that there is one, or the potential for one. If so (and even if not), then there's nothing obviously wrong with removing a user's admin bit if its later restoration can be automatic. Admin for life, eh? No chance of a reduction for good behavior? -- Hoary (talk) 16:19, 10 March 2010 (UTC) As I have stated on similar proposals, this idea institutes unecessary new policies and creates new workloads to solve a problem that has not been demonstrated to exist, ie. a solution in search of a problem. New rules and processes for their own sake do not an efficient Wikipedia make; WP:CREEP is relevant here. I cannot support this sort of proposal. Shereth 16:47, 10 March 2010 (UTC) Support I believe this is a necessary step to minimize the problem of compromised admin accounts. If the bureaucrat unchecking proposal passes, we wouldnt even need to bother the stewards (which I think would be a good thing, as theyre pretty busy as it is). —Soap— 15:58, 13 March 2010 (UTC) And how often have we had compromised admin accounts that occurred after long inactivity? Judging from WP:AN/I it is a rare occurrence. Are you aware of any count or record? The whole community should be answering proposals like this with WE NEED CONTENT IMPROVEMENT, NOT MORE ADMINISTRATIVE PROCEDURES! Can I propose that editors must make 50 constructive, non-trivial article improvements to earn the right to engage in a single administrative discussion? I will adhere to that myself. alteripse (talk) 11:51, 15 March 2010 (UTC Support Since admins have the power to edit site-wide JS (and other system messages), a compromised admin account is valuable to hackers. Since Wikipedia is an extremely high-trafficked website, such a compromise has the potential to infect thousands of readers with malware (the security of web browsers and their plugins is far from perfect, with new exploits announced daily). Blocking the compromised account after the fact would not stop the malware infections. Reducing the number of admin accounts to only those who really need admin access is one way to lower the risk of a compromise. I'm actually surprised that AFAIK, the MediaWiki:Common.js file hasn't been exploited by the cybercriminals. Yet. PleaseStand (talk) 02:33, 20 March 2010 (UTC) The proposal of course does absolutely nothing to resolve that security issue. All someone would have to do is hijack the account after desysopping, make an edit to ask for the tools back, then its like they got the admin account directly, or they can just hijack it after 89 days; so this lowers the risk by about 0%. Additionally, the only real way to hijack an account that's been inactive for months would be a brute force attack on the password. Active accounts are much more vulnerable; vandals have even gotten admin accounts "legitimately" by creating an account, making a few thousand good edits, then running for RFA. Mr.Z-man 04:25, 20 March 2010 (UTC) Either way, any admin account with a keylogged password, active or inactive, can be used to compromise the site. In particular, would an inactive admin even notice that his account is compromised (not necessarily even an active admin)? I have posted a new proposal below specifically addressing the security risk of the immense amount of technical power granted to admins. PleaseStand (talk) 13:48, 20 March 2010 (UTC) How do you use a keylogger to capture someone's password if they never log in (since they've been inactive for months)? It would only take a few minutes and a single edit to add some script to the sitewide JS, I doubt an active user would notice immediately and even if they did, they wouldn't be able to notice until after the edit was made. Mr.Z-man 16:54, 20 March 2010 (UTC) There have been instances (Very rare instances) where an admin account (which in this case has been inactive) has been compromised by someone guessing the password (See User:RickK event). That aside this is a rare and extreme event requiring considerable patince by someone and could just as easily happened to an active admin account (Which has also supposeofly occured with some admins). At any rate in all cases this has been dealt with the current systems in place and damage has been minimized. Basically its more a matter of password security through watching out for malware or behavioural patterns in your edits that can identify your pws. That in itself i think is sperate from inactivity of accounts and more to do with the security of an individuals password and their computing habits (active or not). Just some stray thoughst on thisOttawa4ever (talk) 18:03, 20 March 2010 (UTC) Oppose. All admins are aware of the possible security issues with their own accounts. In fact, it's on the Administrators' reading list. "...Privileged editors are required to use strong passwords and are informed that the developers will occasionally try to crack their passwords and disable those that can be cracked." This alone should be all the security that is needed. Compromised admin accounts do not seem to be a common problem at all, looking over ANI. If it ain't broke, don't fix it. I trust all the admins here to have complete security over their accounts. The issue of keylogging has been brought up and discussed above. (You can't log what is not typed in.) Also, in my experience at least, almost all malicious activity, regardless of where it comes from, is quickly caught and dealt with. All events are logged, and there is an undo button for everything. Any person who is aware of which admin accounts may be inactive and what can be done with them will surely be aware of how easily their actions can be undone. It is far more likely that any unauthorized use would come from an admin leaving their account logged in somewhere, at a library for example, or in a college dorm room/workplace where a disgruntled colleague may be able to access. There really are few reasons to try and hack an admin account anyway. There is no secret information to be gained, no money to be wired to a Swiss bank account, no claim to fame as long as we deny recognition... All this policy will do (in my opinion) is add unnecessary bureaucracy to prevent a very rare occurrence. Admins may feel like they cannot take a break, lest they get "demoted" or "punished" by having their tools removed. Even if it is not considered punishment per policy, it may feel like that to the admin that has this happen to them. Not to mention the fact that the proposed policy states: "If, after a period of one week, the inactive administrator has not made any edits or logged actions, or has not in some other way acknowledged receipt of the notices given in step 1, the user who left the notices may make a request at m:Steward requests/Permissions for the removal of the administrator's sysop flag." So, any "inactive" admin just has to log in for 5 minutes a week and block a vandal at ANV or semi-protect one page at RPP. If this were a common occurrence, I would agree with the proposal. As of right now, it is simply unneeded. Avicennasis @ 11:31, 21 March 2010 (UTC) Oppose I agree with Avicennasis. I feel like I would be spitting his words back out if I launched into a lengthy explanation. Don't think this is needed right now, Airplaneman talk 16:35, 21 March 2010 (UTC) Comment. I should point out that this exact policy is listed at perennial proposals, which is a list of things that are frequently proposed on Wikipedia, and have been rejected by the community several times in the past. Also see Wikipedia:Requests for adminship/desysop poll. Like I said, if the admin has passed a RfA and gained the community's trust, then that tust should remain; (mis)use or (ab)use of tools is one thing - (non)use of tools is quite another. Also, the propsed policy would need drastic re-writting if it were to become actual policy. In the example listed about, it is far too easy for an "inactive" admin to violate the spirit of the policy, while not violating the letter of the policy. As is, there are too many loopholes. Also, the policy seems to be based off of users taking action, rather than a standard or automatic process. This would easily allow for for "targeted" de-sysop request; an admin who regularly blocks 3RR editors, for example, may get a warning (and following de-sysop) much sooner that an admin who helps at DRV. Even though an admin can easily request their rights back, this allows for users to make admins "jump though hoops" on their return to get those rights back. Avicennasis @ 20:36, 21 March 2010 (UTC) Strong oppose. It is the responsibility of any user Administrator or not to make sure their account is used only by themselves. Just because a user has not been active for some time does not mean that their account will be compromised that is a separate issue entirely. Administrators are picked in a process that is not taken lightly judging from reading some of the RfA past succeeded and failed archives. I believe then the process that a user has gone through to become an administrator should allow them and only them (unless they are abusing their powers) decide when they are no longer able to be administrators anymore. Now perhaps if there was a way to temporary "disable" a administrator's account if he is inactive for a long period of time...by say ..having to resend an auto confirm email to the email they used to sign up..or some such manner. that could be an option. I would suggest somthing temporary if needed that the user himself can reactivate...or something. But... otherwise you would have to open up a whole new can of worms to figure out ...ok how long does the user have to not be active to be diasbled from being an administrator? How active do they have to be? I don't think it is our job to police administrators in that fashion as long as they are doing what they should be doing without abusing power i think they should be active for as long as they see fit. They earned it. Evenios (talk) 07:32, 22 March 2010 (UTC) Strong Oppose - What I don't understand is this; how does it hurt to have inactive administrators? Honestly, these are the "most trusted" members of the community. Why should their tools be removed from them? Opposing per this and above reasons. Ajraddatz (Talk) 16:40, 25 March 2010 (UTC)

Implementation of bureaucrat removal of admin and crat flags

I moved this to talk ) 01:28, 22 March 2010 (UTC)

Following from the two discussions on giving bureaucrats the technical ability to remove admin and bureaucrat flags, in February 2009 and then January 2010, and the more recent discussion on implementation; a clear conclusion is that a concrete policy governing bureaucrats' use of this tool is desired. Accordingly, there is now a policy proposal at Wikipedia:Administrators#Bureaucrat removal, which mandates bureaucrats to remove rights only in the uncontroversial instances. Please come and share any thoughts on the proposal at the associated discussion. Happy‑melon 12:34, 18 March 2010 (UTC)

This is already being discussed (and opposed) above. Ajraddatz (Talk) 16:45, 25 March 2010 (UTC)

Do the same (and I do assume they do)foundations areas as above

Since I'm an age where we didnt have computers in school like they do now Im not as sure if this applies to all schools or not- wouldnt a soft block on schools also block the teacher's access, so teachers cant edit either? Do we want to block teachers? And why block all students? Shouldnt we be encouraging students to edit responsibly? Imagine how much better Wikipedia could become if we actively encouraged school teachers to have their students to real research in order to edit the article on their hometown, or on some history subject they are studying, or something like that. Tiny towns and hamlets and villages that are currently stubs could turn into great articles with multi-paragraph long sections on history, geography, transportation, education, architecture, etc. Instead of blocking schools maybe have Wikipedia actively reach out to teachers and offer support on our policies so they can be aware of our editing style and have a course plan established for this type of student project. Plus it allows us the opportunity to have at least one of those students turn into a regular editor because he/she decides to go on (and of course we might have some vandals as well, but I think that the good outweighs the bad).Camelbinky (talk) 00:10, 23 March 2010 (UTC)

This was not written with Teachers in mind, ( my mistake for not clarifying this) and of course we should encourage all young minds to excel, and contribute. But in the real editing world where do 80% of vandalism come from ?

MESSAGE

00:30, 23 March 2010 (UTC)

Why not instead put more effort into working with schools to help get younger people to edit responsibly. That always seems better to me than a autoblock policy. Ajraddatz (Talk) 16:58, 25 March 2010 (UTC)

Oppose blanket preemptive blocks. –xeno^talk 13:18, 23 March 2010 (UTC)

Oppose How can someone be pre-emptively blocked and in the same way be encouraged at improving their editing? Sorry but I have to oppose this proposal. Ottawa4ever (talk) 15:46, 23 March 2010 (UTC)

If I take the URL of a page and put it into an RSS feedreader, I get the RecentChanges feed. Now, no one (except bots) in their right mind would want to subscribe to our RC feed (The RC feed is only useful on sites like usability:, which have an edit every two days). Instead, subscribint to a page on Wikipedia should subscribe to the page history. The change is a small one:

<!--Change this in the <head> of the HTML for User_talk:Manishearth (example)-->
<link rel="alternate" type="application/rss+xml" title="Wikipedia RSS Feed" href="/w/index.php?title=Special:RecentChanges&feed=rss">
<link rel="alternate" type="application/atom+xml" title="Wikipedia Atom Feed" href="/w/index.php?title=Special:RecentChanges&feed=atom">
<!-- to this (present in User_talk:Manishearth?action=history): -->
<link rel="alternate" type="application/rss+xml" title="User talk:Manishearth RSS Feed" href="/w/index.php?title=User_talk:Manishearth&amp;feed=rss&amp;action=history">
<link rel="alternate" type="application/atom+xml" title="User talk:Manishearth Atom Feed" href="/w/index.php?title=User_talk:Manishearth&amp;feed=atom&amp;action=history">

Comments? ManishEarth^{Talk • Stalk} 04:54, 25 March 2010 (UTC)

That's the global site feed and should rightly be available from every page. Just because it's not helpful on enwiki doesn't make it any less helpful on the majority of other MediaWiki installations. If you goto the history page, you get the links for the feeds for an article. I *believe* there's an open bug requesting the feeds be available when action=view (I'm too lazy to go searching for it at the moment). Also, RSS is going away on the next scap, we're only serving Atom now (by default). ^

^{[omg plz]}

 13:04, 25 March 2010 (UTC)

Couldn't we disable it on enwiki? I'm not sure if its possible to modify stuff in the <head> of a page through js... ManishEarth^{Talk • Stalk} 15:14, 25 March 2010 (UTC)

I propose that the WP: namespace be creation protected. I came across

I do not see anything unique. It was just G11. Ruslik_Zero 10:48, 22 March 2010 (UTC)

No it wasn't.

Roger Guerin already exists. Looks like the user just got confused. ManishEarth^{Talk • Stalk}

11:34, 22 March 2010 (UTC)

It was an obvious spam (And more to come ...). Ruslik_Zero 14:21, 22 March 2010 (UTC)

So even new essays would require admin assistance in order to be posted in WP namespace? And new proposals as well? That could have a chilling effect on metapedian speech, especially efforts at Wikipedia reform, which is an

talk

) 10:52, 22 March 2010 (UTC)

Ooh good point about essays. I forgot about them. ManishEarth^{Talk • Stalk} 11:34, 22 March 2010 (UTC)

And archivebots such as MiszaBot and ClueBot III should get the admin bit, solely to make the archive pages? (X! · talk)  · @540  ·  11:56, 22 March 2010 (UTC)

Allow bots. Anyways, I've changed the proposal, see below. ManishEarth^{Talk • Stalk} 12:47, 22 March 2010 (UTC)

Oppose. Users can already put spam in their user spaces. So would we need to creation protect those as well? Plus, the protection would need to have one exception for each of the deletion discussion processes, which do not currently use the Wikipedia talk namespace. PleaseStand ^(talk) 11:11, 22 March 2010 (UTC)

Well, the code could be changed to apply only for new top-level pages (pages which aren't subpages/are subpages without parents) ManishEarth^{Talk • Stalk} 11:34, 22 March 2010 (UTC)

Well, we should atleast sweep the namespace for once, and have a tool which monitors all non-subpage new pages, which people should check on every now and then, maybe via RSS (Any devs?) ManishEarth^{Talk • Stalk} 11:34, 22 March 2010 (UTC)

I think the problem is rare enough that you can tag pages as you see them. No point in preventing people needlessly. Aiken ♫ 13:58, 22 March 2010 (UTC)

Yes. Thats why I've changed the proposal to just "scan the WP namespace for unwanted articles" using a tool which filters out subpages. Another tool should generate an rss page of new WP pages which aren't subpages. ManishEarth^{Talk • Stalk} 15:16, 22 March 2010 (UTC)

If someone wants to make such a tool, they're free to do so. You don't even need to file a BRFA for a read-only tool. I don't think it would be an especially good use of Wikimedia's paid developers' time though, if that's what you're suggesting. Mr.Z-man 16:45, 22 March 2010 (UTC)

Not paid devs. Toolserver ones.

I did an analysis of the namespace and it seems it's one big unstructured and uncategorized mess: User:Svick/Wikipedia namespace. Svick (talk) 17:53, 23 March 2010 (UTC)

We need to MfD those AfDs... I thought that they were deleted after a month or so of being an archived ManishEarth^{Talk • Stalk} 03:36, 25 March 2010 (UTC)

If you are interested in cleaning up the Wikipedia namespace, check for example Wikipedia:Database reports/Orphaned single-author project pages or Wikipedia:Database reports/Orphaned article deletion discussions; for other interesting reports see Wikipedia:Database reports. Cenarium (talk) 18:53, 23 March 2010 (UTC)

Editprotecting?

Atleast editprotect the WP: pages from IPs (maybe autoconfirmed, too)

WP:VAND gets vandalised every day (so does the talk page, but we can't help that) Most people filter out WP: pages when RCpatrolling, which is evident through the fact that this edit wasn't reverted until I saw it in my watchlist (Yes, its only an 8 minute difference, but after 8 minutes, you can consider the edit permanent). ManishEarth^{Talk • Stalk}

03:00, 24 March 2010 (UTC)

What?

WP:VAND has been semiprotected since 2007, and AFACT has been vandalized only twice since January. The talk page isn't protected, but gets vandalized only about 5 times per month. Neither are even close to "every day." Mr.Z-man

03:19, 24 March 2010 (UTC)

Really? I must be mixing up the talk pages with the actual page. But I'm quite sure that there's a lot of vandalism there, just right now there was a heated debate going on, so the vandalism was buried. Many times my watchlist has a reverted edit in it. Anyways, what's the need of letting IPs edit WP: pages. WT: is OK, but even I don't edit WP: pages except the pumps and the sandbox. All WP: pages should be IP protected except discussion pages and the sandbox. ManishEarth^{Talk • Stalk} 03:51, 24 March 2010 (UTC)

Why must we protect the entire namespace, and not just the articles infected? I r confused. Ajraddatz (Talk) 16:51, 25 March 2010 (UTC)

Be cause RCpatrollers and Huggle users by default filter out the WP: pages. Scenario: A vandal receives a message telling him to stop vandalizing. There are links to policy pages there. He follows a link, and sees the "edit" tab. He thinks "Wow! I can edit this", and he edits it. The edit goes unnoticed, except by watchers of the page (And most policy pages aren't watched by people...The ones which are watched are for the discussion pages). This is exhibited by my example above of WP:Rogerguerin. ManishEarth^{Talk • Stalk} 02:51, 26 March 2010 (UTC)

If someone has to vandalize something, I would rather it be something in the WP: namespace or userspace than an article (i.e. something that matters). Note that you cannot watch just a discussion page. When you watch a page, you watch the page itself and its corresponding talk page (or vice versa). Mr.Z-man 03:04, 26 March 2010 (UTC)

Thats what I meant. The only policy pages watched are those with active discussions. ManishEarth^{Talk • Stalk} 12:37, 26 March 2010 (UTC)

I'd like a mechanism for adding a secondary title to articles that could be optionally listed in categories. For many types of articles, for example legal cases (Smith v. Jones), technical standards (ANSI Z535) and so on, the title tells you nothing about the subject. A short subtitle added using a tag similar to the default sort tag would make the category listings more intelligible. The reader should be able to toggle the subtitles on and off as they saw fit to deal with over-full categories.--agr (talk) 00:01, 25 March 2010 (UTC)

Can you explain how you contemplate this would work a little more completely? I think I know what you mean in a vague way, but I'm not at all sure I know what you mean. What I got is that for "Smith v. Jones" say, the subtitle would be something like U.S. legal case, or even more detail like U.S. legal case, abortion rights and that subtitle would only appear in the category listing and would not be visible in the article except when viewing the code, possibly taking the form of a second parameter in default sort such as {{DEFAULTSORT:Life of Brian|Monty Python comedy film}}. Is that anything like what you mean?--Fuhghettaboutit (talk) 04:59, 25 March 2010 (UTC)

Interesting idea - could certainly make category listings less cryptic. But if the text is only visible in category listings, maintenance on low-visibility pages would be a nightmare - god only knows what vandalism could stay there for how long. Rd232 ^talk 12:13, 25 March 2010 (UTC)

I envision pithy, non-controversial subtitles that would aid a reader in deciding whether to click on the article link, like Fuhghettaboutit's Life of Brian example. They shouldn't merely duplicate category names. So for Gideon v. Wainwright the subtitle might read "State courts must provide indigent defendants with counsel." The fact that it was a US Supreme Court ruling could be left out of the subtitle on the theory that the reader is most likely to encounter it in a category of US Supreme Court rulings. ANSI Z535 might be subtitled "Standards for safety markings." I was thinking about their utility category listings, but the subtitle could also appear in smaller print under or next to the article title, as a user option perhaps. That would deal with the maintenance problem. Software resources permitting, subtitles could also be shown in link mouse-overs and spoken by assistive readers on request when a link is encountered. We might disallow them for living persons at first to avoid creating new BLP issues. Using a second parameter in DEFAULTSORT:Life or creating a new tag seems to me an implementation judgement call.--agr (talk) 17:29, 25 March 2010 (UTC)

Sounds more like a keyword or keyphrase rather then a subtitle. ---— Gadget850 (Ed) ^talk 17:42, 25 March 2010 (UTC)

Popups show you the lead of an article, this accomplishes most of what you're aiming for. Fences&Windows 23:34, 25 March 2010 (UTC)

It's a nice tool—I wasn't aware of it before—but it don't give readers a guide to opaque category listings like Category:ANSI standards or Category:United States Supreme Court cases of the Rehnquist Court. Also it requires a user to have an account, so it's not available to the vast majority of our readers.--agr (talk) 03:21, 26 March 2010 (UTC)

I'll keep this as technically low as possible, so apologies in advance to anybody who thinks I'm giving too much background info about this proposal.

The WikiMedia API is the piece of the software that allows automated browsing and editing (e.g. for bots, tools, helper scripts, etc.). The API was designed to be accessible by JavaScript, a scripting language that runs inside webpages. However, since the time of the development of the MediaWiki API, browser manufacturers have placed increasingly greater restrictions on the abililty of JavaScript running on one page on the internet to communicate with other pages elsewhere on the internet. This was to protect internet users from malicious uses of JavaScript. Unfortunately, it also meant that access to non-malicious uses, such as the WikiMedia API, were restricted also.

Last year,

• Enable JavaScript running on the toolserver.org to browse, log in and edit pages.

Such scripts were previously able to do this for all browsers and, if you have a browser older than a few months, still can.

For us to do this would require a code change to the api.php file on the Wikipedia servers:

header("Access-Control-Allow-Origin: http://toolserver.org");
header("Access-Control-Allow-Credentials: true");

I have described two other approaches we could take on

• Enable JavaScript running on any website to browse, log in and edit pages.
• Enable JavaScript running on any website to browse and edit pages - but only JavaScript running on the toolserver.org to log in.

The first of these is how the API was originally designed to run (and, my conservative proposal side, my preferred approach). The second is the restricted manner in which it was possible to access the API until the last few updates to the major web browsers.

These changes, particularly the "conservative" proposal, don't constitute an increased security risk since malicious users can still trivially bypass the restrictions on cross-domain JavaScript should they wish to do so. Rather they lift the restrictions placed on ordinary users, allow JavaScript-based tools to continue to function as normal and mean that script writers don't have to resort to work-arounds that are of benefit to noone.

They do not affect other technologies that use the MediaWiki API, such as PHP or C# applications, or JavaScript that is run on from en.wikipedia.org. Tools written using other technologies continue to have full access to the API (as do malicious users of JavaScript). --RA (

This is already implemented for the API. See bugzilla:19907. Though I think it might not yet be deployed, and if it is, toolserver probably isn't included in the whitelist yet. See also bugzilla:20298. —TheDJ (talk • contribs) 20:33, 25 March 2010 (UTC)

LOL! I could have saved myself a lot of typing if I had checked the SVN! The implementation is real nice too. Here's r62546 and we are running

r64051

. So it looks like it is deployed and ready to go.

The question then is, are we in consensus to add '*.toolserver.org' to the wgCrossSiteAJAXdomains array in includes/DefaultSettings.php (if its not done already)? If so, who can do that? --RA (

talk

) 22:46, 25 March 2010 (UTC)

I don't think anyone would object, though perhaps it might be a good idea to limit to stable.toolserver.org at first. Any such requests should be filed at bugzilla: under Wikimedia site requests. —TheDJ (talk • contribs) 22:54, 25 March 2010 (UTC)

You are an oracle of knowledge, DJ. It looks like the stable.toolserver.org is no more. (Follow any link in this Google search). I'll open a request for all of toolserver and see how it goes. --RA (

talk

) 23:45, 25 March 2010 (UTC)

Request submitted. Thanks for your help. --RA (

talk

) 00:05, 26 March 2010 (UTC)

Update: Tim Starling says no for reasons of account security. I suggested to set Access-Control-Allow-Credentials to false, but I guess it ain't gonna happen. --RA (

talk

) 11:08, 26 March 2010 (UTC)

I propose to delete all vandalism-only accounts which are more than a year old without any activity. The deletion should free up the user name for account creation. All of the users edits must have been reverted, and the edit and its revert should also be removed from the database so the new user can start with a clean slate. I'm not sure if this is possible, but it seemed like a good idea... Comments? ManishEarth^{Talk • Stalk} 13:13, 22 March 2010 (UTC)

The edits will not be removed from the database, but the username could be renamed to "Renamed user xxxx". –xeno^talk 13:15, 22 March 2010 (UTC)

• Oppose—names are not running out, really, and renaming old vandal accounts would cause difficulties in tracking sockpuppets etc. (eg User:France a) ╟─TreasuryTag►estoppel─╢ 13:19, 22 March 2010 (UTC)

This is already done occasionally through WP:USURP, but I can't see the benefit of doing it for every account. Besides, if its done by bot/automated it would also release thousands of offensive user names and to do by hand would take years. --Jac16888^Talk 13:20, 22 March 2010 (UTC)

Indeed - most vandals don't use desirable names anyway. –xeno^talk 13:22, 22 March 2010 (UTC)

• Oppose because I don't know what real benefit this will serve. If someone desires a name that a vandal had, they can usurp it. Aiken ♫ 13:56, 22 March 2010 (UTC)
• Oppose Fundamentally I see the point that there are user names that would be desirable that are taken up by inactive accounts that are a few years old. In addition, for a new comer it might be a bit difficult to undertsand the whole usurp thing (though once you know about it its simple) However, I think this isnt the best idea mostly due to what was mentioned above about tracking socks. Alot of vandals Ive seen return with simillar account names longer than a year and its easier to keep a long term abuse record with the previous existing accounts. They could also in theory just re-create their blocked account and continue to harass individuals (an extreme) but nether the less a reason which i oppose the general rule. I think the usurp process is just fine in order to get an account name thats inactive orr only used for that single purpose. Though its a good issue and point that you bring up. Ottawa4ever (talk) 15:14, 22 March 2010 (UTC)

• Strong Oppose Per Ottawa4ever (talk · contribs). Immunize (talk) 15:23, 22 March 2010 (UTC)
• Not possible Our copyright licenses requires attribution of all edits—yes even edits that are the written equivalent of fart noises at the back of the auditorium. Even if the opposes above were all supports it would not matter: We cannot do this. You'll note that the threshold requirements of username usurpation is that the target username have "no edits or significant log entries"; same reason.--Fuhghettaboutit (talk) 23:30, 22 March 2010 (UTC)
  • I fear this is a bit overstated. If the user has no edits that actually form part of the encyclopedia, there is no legal impediment to renaming or deleting the account. Even if the user did have a vanishingly small number of edits, there would be no serious legal impediment, though there might be a policy and practice issue. Newyorkbrad (talk) 23:57, 22 March 2010 (UTC)
    • Even if it were true of those who just added pure vandalism to articles, how would we ever separate out the numerous vandalism only accounts who made a few good edits as a false flag or even edited for a few days to get autoconfirmed before launching into their rampages.--Fuhghettaboutit (talk) 02:30, 23 March 2010 (UTC)
      • Just because we don't like the vandalism and get rid of it (rollback/undoing/os'ing) doesn't mean its not part of the encyclopedia.... if the user makes a edit and its available in the article history it is my understanding that we must attribute them.
        Talk Page · Contribs
        ) 12:33, 23 March 2010 (UTC)
        • Even if this were true, attribution is still available even if the account is renamed. Just follow the breadcrumbs. Bureaucrats will and have been vacating vandalism-only accounts for usurp requests as not GFDL(and now cc-by-sa)-significant. –xeno^talk 13:20, 23 March 2010 (UTC)
        • If its rolled back or deleted, that's exactly what it means. All we need to give credit to are the people who actually contributed something to the current version of the page. Our attribution requirements are still based on copyright law, and I don't think you can claim copyright on something that you didn't contribute to. Mr.Z-man 14:07, 23 March 2010 (UTC)

Alternative idea: What about deletion of accounts that have never made a single action other than the account creation entry and is N days/months/years old? If they've made no edits or other work to attribute, we hardly have to retain the creation log for licensing. I don't really have any strong opinions either way, but it would address the issue of "freeing up usernames" without the licensing issues. ^

And if the user logs in, and uses the Special:Preferences to modify the interface, would we be able to know? It would be wrong to prevent those users from using their preferred skin, having all times in histories/logs be according to their time zone, etc. עוד מישהו Od Mishehu 05:31, 25 March 2010 (UTC)

Then exclude people who've set preferences as well. My point remains the same. ^

^{[omg plz]}

 01:17, 26 March 2010 (UTC)

I would support this for accounts over 1000 days old. –xeno^talk 01:21, 26 March 2010 (UTC)

This takes care of the licensing issue entirely. I'm still not seeing a good reason to do this though. I have no objection, just not sure it has much utility. Under this version, any account we delete would have been usurpable. So we are preemptively freeing up the names, and some who might not have discovered or bothered with usurpation will be able to sign up without ever realizing the name they choose was once taken. Is that such a boon that we need bother? I'm actually asking.--Fuhghettaboutit (talk) 02:32, 26 March 2010 (UTC)

I agree, I see no reason to do this. In addition, I can't see how it could be done. As far as I know there is no way currently for any person to remove an account all together, with perhaps the exception of developers. Sure, they can be renamed to User:Usurped 666 or hidden from view, but the account is still there, this isn't going to change anytime soon. Or does this alternative suggestion involve moving old accounts to something different aka usurp. If so, who'se going to do it? Do you want the few crats we have to go through the hundreds of thousands of unused accounts we have, renaming them all to User:Unused 1, 2, 3 etc, all on the offchance some newbie wants the name, which considering the relatively low number of requests at Usurp isn't that common? Or should a bot should do it? Which would mean giving a bot a crat flag, something never done before afaik, and considering the masses of debate before we started giving bots sysop flags, its not likely to happen anytime soon? --Jac16888^Talk 02:45, 26 March 2010 (UTC)

I was saying to have a developer run the "removedUnusedAccounts" script, which physically deletes unused accounts from the database. Right now the script doesn't take preferences into account like I suggested (it will ignore based on user_touched, which is more greedy, iirc). Right now the command would be php removeUnusedAccounts.php --delete --ignore-groups=sysop,bureaucrat --ignore-touched=1000. ^

^{[omg plz]}

 17:16, 26 March 2010 (UTC)

Unused accounts could be alternative accounts (usually declared on user or talk pages), doppelgänger accounts (not necessarily declared), or

snigbrook (talk

) 20:14, 26 March 2010 (UTC)

There is a proposal for an amendment of the protection policy to allow preemptive protection of BLPs at risk (currently, the policy states that protection should not be used as a pre-emptive measure). Cenarium (talk) 19:00, 23 March 2010 (UTC)

I oppose. Dg-reg-fd-1971 (talk) 15:42, 25 March 2010 (UTC)

Please comment on the linked page, this is jut an announcement. Thank you, Cenarium (talk) 13:45, 26 March 2010 (UTC)

What is a jut? Dg-reg-fd-1971 (talk) 21:09, 26 March 2010 (UTC)

"Googleable: (adv) describing someone or something that can be retrieved directly via a search using the Google internet search engine. Google is a multinational public cloud computing and Internet search technologies corporation."

e.g. Question "I hear that you're on google" Answer " Yes, I'm googleable, aren't you?"

—Preceding unsigned comment added by 204.40.1.129 (talk) 19:32, 26 March 2010 (UTC)

• snigbrook (talk
  ) 19:49, 26 March 2010 (UTC)

I was thinking that we can use better-looking icons (at least these look better to me) for user warnings. Below, I have placed my proposals. Please edit the appropriate subsection below, depending upon your position. -- IRP ☎ 14:59, 9 March 2010 (UTC)

Icon Replacements

→

→

→ [I am not sure what to replace this with]

→

Support

1. I support the change to the first icon (looks friendlier IMO) but not the rest. --Yair rand (talk) 22:28, 9 March 2010 (UTC)
2. They do stand out more, which might prevent a vandal from not reading the messages...ManishEarth^{Talk • Stalk} 01:44, 10 March 2010 (UTC)

Neutral

1. I fear change. –xeno^talk 20:23, 9 March 2010 (UTC)
2. When comparing the two sets, Crystal Clear and Nuvola it's hard to decide. There's good icons in both, we should use some from each. -- œ^™ 08:51, 10 March 2010 (UTC)
3. I have no particular opinion on the first two suggested changes. As for the third and fourth, there should be no icon. In the spirit of "PDFTT", such messages should look boring, in order not to provide any satisfaction for attention-seeking nitwits. -- Hoary (talk) 16:23, 10 March 2010 (UTC) ... very slightly rephrased, and moved from "oppose" to "neutral" -- Hoary (talk) 03:01, 11 March 2010 (UTC)
4. eh... if we're going to go to the trouble of changing icons, let's at least make a real improvement. the new icons are marginally better, at best. --Ludwigs2 15:45, 11 March 2010 (UTC)
5. There is a point to improving them, but this change is cosmetic. We need the icons to show the escalation of importance in a specific and transparent manner. So I am positively and conspicuously neutral on this change Fiddle Faddle (talk) 15:51, 11 March 2010 (UTC)
6. There should be no "wrong" icons to use; I've used custom warning templates in the past and I think that variation within reason should be permitted. So long as the user understands the message and it is neither too weak nor too strong, I don't the icons should matter. —Soap— 17:47, 13 March 2010 (UTC)
7. Rather trivial, and I do not think the new images are any better or worse than the old ones. As Soap mentioned, if a user doesn't like the generic templates, custom ones are always an option. Airplaneman ^talk 17:54, 21 March 2010 (UTC)
8. I dunno, I kinda like the old ones... Ajraddatz (Talk) 16:43, 25 March 2010 (UTC)

Oppose

1. What's the point of changing anything? In what way are your proposals better than the current set? You've not explained this very well... ╟─TreasuryTag►cabinet─╢ 16:33, 9 March 2010 (UTC)

   In my view, they look more appealing to the eye. They draw more attention. -- IRP ☎ 18:49, 9 March 2010 (UTC)

2. The initial icons are clearer than the proposed replacements, if not as shiny. :/ {{Nihiltres|talk|edits|⚡}} 17:07, 9 March 2010 (UTC) (iPod edit)

   To me, the proposed replacements look better. -- IRP ☎ 18:49, 9 March 2010 (UTC)

   Well, to us, they don't... ╟─TreasuryTag►ballotbox─╢ 19:21, 9 March 2010 (UTC)

3. I like the existing ones, the replacements are blurry. Fences&Windows 20:19, 9 March 2010 (UTC)
4. The second icon, especially, is harder to view. Also, I'm not sure the new set would scale well. —C.Fred (talk) 20:32, 9 March 2010 (UTC)
5. A resounding meh. Concur about blurriness. --Cybercobra (talk) 20:36, 9 March 2010 (UTC)
6. I'm all for change, even just for the sake of looking cooler, but the proposed replacements don't really seem like an improvement. Equazcion ^(talk) 21:23, 9 Mar 2010 (UTC)
7. Looks like a step backwards to me. – ukexpat (talk) 21:58, 9 March 2010 (UTC)
8. (edit conflict) Agree, don't see the new icons as that much of an improvement. Mo ainm~Talk 21:59, 9 March 2010 (UTC)
9. We should be removing the icons entirely. --Carnildo (talk) 22:49, 9 March 2010 (UTC)
10. Bad idea. The icons catch the eye of a vandal and he actually reads the stuff. Actually it would be better to replace the icons with some faces, like smiling, then sad, then angry, then furious. THat will sum up the message pictorally.
11. The suggested alternatives are not an improvement IMHO. Mjroots (talk) 09:40, 10 March 2010 (UTC)
12. No way - big waste of time and I prefer the old ones. Kayau Voting IS evil 09:53, 10 March 2010 (UTC)
13. The original icons are directly face on and easy to see, where as the suggested replacements seem to be angled and have light effects/blurs on them making them a tad harder to see, as well as the blue/white and yellow/brownish colour schemes seem to clash on the information and exclamation signs respectively (See:
    Talk Page · Contribs
    ) 09:57, 11 March 2010 (UTC)
14. Proposed icons are not significantly better than the current ones. The 3D effects are a bit kitsch, and makes them less clear. However I like the idea of the middle strenght warning (triangle sign) being yellow instead of red. Elekhh (talk) 00:56, 12 March 2010 (UTC)

    In that case, why not use ? --Yair rand (talk) 01:15, 12 March 2010 (UTC)

    Yes, I would support this one. --Elekhh (talk) 05:51, 27 March 2010 (UTC)

15. I oppose the replacement of the current icons with the proposed icons, as it feel (to me) like a massive step backwards. I agree that the proposed icons are blurry, and (to me)look far worse than the current ones. Immunize (talk) 17:36, 13 March 2010 (UTC)
16. Yeah, I actually just wanted to use this :D I strongly oppose, whatsoever. --JokerXtreme (talk) 23:39, 13 March 2010 (UTC)
17. Picking the equivalent icon in a nearly-equivalent icon set is not enough change to bother. Ikluft (talk) 12:32, 14 March 2010 (UTC)
18. Hate those 3D effects. —TheDJ (talk • contribs) 13:19, 14 March 2010 (UTC)
19. I don't like the new graphics, and why fix what's not broken? SchuminWeb (Talk) 23:52, 15 March 2010 (UTC)
20. Contrast is better on the current ones. Mr.Z-man 23:56, 15 March 2010 (UTC)
21. Above reasons (contrast, not face-on, no improvement, etc.), plus there is no proposed, matching replacement for File:Stop hand nuvola.svg, the icon most commonly used in vandalism warnings. PleaseStand ^(talk) 13:51, 20 March 2010 (UTC)
22. Not enough difference between current and proposed sets, proposed set is friendlier looking, which will probably be counterproductive when warning vandals. RadManCF ☢ open frequency 17:41, 20 March 2010 (UTC)
23. I just believe that a strong degree of directness in the warnings is required to halt the damage being done and it shouldnt be made more graphically 'spiffy' they are fairly direct the way they are. I do however like the first warning change. Just not the subsequent ones. Ottawa4ever (talk) 17:53, 20 March 2010 (UTC)
24. To me it seems the current icons serve just fine. I dont see any major need for changes at this time. Evenios (talk) 07:35, 22 March 2010 (UTC)

Hello,

Was just "moving" a page and it occurred to me that a more accurate name for the function would be "rename". What are people's opinions on this? Aiken ♫ 15:36, 13 March 2010 (UTC)

Technically the Mediawiki software "moves" the page, leaving a redirect behind in the old location. Well, kind of. I have a genuine "don't care either way" over this. It's just a bit of software, after all. Fiddle Faddle (talk) 15:49, 13 March 2010 (UTC)

Technically schmechnically... there's a case that "rename" might be clearer to newbies. This might be an issue for the Usability Initiative guys to look into. Rd232 ^talk 22:00, 13 March 2010 (UTC)

We have a Usability Initiative? Wow, does that mean we'll throw Mediawiki software away? Fiddle Faddle (talk) 22:36, 13 March 2010 (UTC)

I doubt it, but you could ask them: usability.wikimedia.org. Rd232 ^talk 23:56, 14 March 2010 (UTC)

Already told them about the renaming idea: usability:Talk:Main_Page#Suggestion_from_Pump:_.22Move.22_-.3E_.22Rename.22 --Cybercobra (talk) 00:04, 15 March 2010 (UTC)

We don't want newbies to move pages. Do you want another

Willy on wheels? Newbies don't need to move pages. They can request a move if they want to. They will discover the "move" button sooner or later and find out what it means (No, they won't do any damage, as they will see MediaWiki:Movepagetext

at the top of the page before they move).

If you still want to go ahead with this, ask an admin to change the text here to "rename". ManishEarth^{Talk • Stalk} 03:43, 15 March 2010 (UTC)

Reply to Fiddle Faddle (User:Timtrent): The Usability initiative is just making the interface look better, it still uses MW. Basically, the "Try Beta" link next to your username/talkpage/prefs/contribs at the top of the page (the personal portlet) takes you to beta mode, which has a sleeker interface and a better edit box (If you don't wanna try beta, but are curious what it looks like, The Usability wiki has the same interface as beta. Or you can just enter and exit beta at your will).ManishEarth^{Talk • Stalk} 03:24, 15 March 2010 (UTC)

Don't see why not. "Rename" sounds better, IMO. Airplaneman ^talk 19:15, 18 March 2010 (UTC)

But "Requested renames" doesn't flow off the tongue like "Requested moves". –xeno^talk 19:19, 18 March 2010 (UTC)

True. I think I'll stay neutral for the time being. Airplaneman ^talk 19:55, 18 March 2010 (UTC)

I also support the idea of renaming move to rename. Immunize (talk) 19:18, 18 March 2010 (UTC)

"Move" makes more sense to me, especially with things like

userfying, where a page is moved to one namespace to another place, with different rules, etc. I wouldn't really care either way or the other, but they aren't complete synonyms in my mind. —Akrabbim^talk

19:20, 18 March 2010 (UTC)

I'm not a big fan of this. It's come up often and as much as "rename" does make some sense, neither word is really completely technically accurate, and I'd rather go with the one that gives newbies some pause before clicking. I don't think newbies should be encouraged to do it before they're fully aware of what happens, and needs to happen, when a page is renamed/moved (ie. the ramifications). Equazcion ^(talk) 19:25, 18 Mar 2010 (UTC)

Reconsidering myself, mainly because "move" seems better than "rename" when referring to moves across namespaces. "Rename" really is not the best way of talking about these moves. And, why fix something that is not broken in the beginning. Immunize (talk) 19:32, 18 March 2010 (UTC)

I wonder whether changing the "move" function to "rename" might encourage what we know now as page move vandalism, as the function will be more obvious to casual users. For example, imagine a Green Bay Packers fan reading the article on Brad Childress. He sees the rename tab, and decides to rename the article to "Brad Childress that !@#$%#@@#$" It would definitely be worth remembering

FYI, fr.wikipedia uses the term "rename", see fr:Special:Log/move. I believe this term to be easier understandable, but it really doesn't always accurately describe what's happening. Another reason not to do this change would be that we couldn't rename Special:MovePage/Foo. I wouldn't mind a change to "rename", this might make it easier to understand for some people and I don't think that this will give much more vandalism, but I don't think that the term "move" is so bad that we immediately need to change it. After all, I understood what it meant quite well when I was still a wiki newbie. --The Evil IP address (talk) 13:00, 27 March 2010 (UTC)

I am proposing that we treat IP addresses and registered vandalism only accounts equally-that is, we indefinitely block all vandalism only IP's, just as we indefinitely block all (or at least most) vandalism-only accounts, as I feel that our current method of dealing with IP vandals (giving a very short block initially) discourages registration and increases vandalism. [[User:Immunize|Immunize]] ([[User talk:Immunize#top|talk]]) (talk) 22:53, 25 March 2010 (UTC)

• Strong oppose - Just because an IP is vandalism-only now doesn't mean it won't one day net a constructive contributor. –xeno^talk 23:04, 25 March 2010 (UTC)
• Oppose: IPs are dynamic, so if you indefinitely block an IP, it may only take a couple of weeks for the user of that IP to rotate to a new one, at which point you now have a redundant block; that may at some point end up blocking a potentially constructive user. Spitfire^Tally-ho! 23:07, 25 March 2010 (UTC)

If they are really that constructive, I would expect to see them create and account. Immunize (talk) 23:22, 25 March 2010 (UTC)

I take it you haven't read the study that showed significant amounts of content is/was contributed by IP editors? --Cybercobra (talk) 23:28, 25 March 2010 (UTC)

So you would then suggest we leave account creation enabled - so a steady flow of vandalism-only accounts can be created from the IP? –xeno^talk 23:31, 25 March 2010 (UTC)

• Oppose IPs do not necessarily belong to one person; accounts do. No point in banning an IP if it causes collateral damage. And, by the way, there are plenty of very constructive editors who don't create an account. Aiken ♫ 23:26, 25 March 2010 (UTC)

For example, a large number of disruptive edits could have been prevented if User talk:203.38.60.32 had received a indefinite block initially. Immunize (talk) 23:29, 25 March 2010 (UTC)

Possibly. But that's just one IP. Your suggestion is that every IP that ever got blocked for vandalizing should be blocked indef, which is a bad idea. Aiken ♫ 23:47, 25 March 2010 (UTC)

• Oppose - Our current method of dealing with IPs is because almost every IP that edits the site is either dynamic or shared. If its dynamic, it might have a new user in days or weeks. If its shared, it might have a new user in minutes or hours. Blocking them for longer will just lead to collateral damage. Mr.Z-man 00:03, 26 March 2010 (UTC)
• Oppose. Looking at the contrib history of an IP who is currently vandalizing, I often see a series of productive edits made in the past. --NeilN ^{talk to me} 14:07, 26 March 2010 (UTC)

Only if the IP adress makes vandal or incompetent edits. Dg-reg-fd-1971 (talk) 20:57, 26 March 2010 (UTC)

Huh? I don't understand the point you're trying to make. --NeilN ^{talk to me} 15:12, 27 March 2010 (UTC)

I don't either. Immunize (talk) 18:10, 27 March 2010 (UTC)

• Oppose IP's rotate, like mine. If a vandal edits from my IP rotation range and is blocked, I won't be able to login (without propogating the block). Even softblocking is bad because the IP rotates. Fixed IPs are also transacted continuously (When the person moves, etc.). We can't indef block IPs. ManishEarth^{Talk • Stalk} 01:33, 27 March 2010 (UTC)
• Oppose unless it can be proven the IP in question is static. HalfShadow 18:12, 27 March 2010 (UTC)

Is there any way to prove an IP is static? Immunize (talk) 18:21, 27 March 2010 (UTC)

Doubt it. I edit from what can be considered a "static IP" but it still changes about once a year. --NeilN ^{talk to me} 18:28, 27 March 2010 (UTC)

Nonstatic (rotate-every few hours) IPs have a status "ALLOCATED PORTABLE", like [[1]] ManishEarth^{Talk • Stalk} 02:25, 28 March 2010 (UTC)

• Oppose it is reasonable to assume that an account belongs to an individual, but you can't make the same assumption of an IP. Even if an IP is static that doesn't mean that every future editor from that network or household will behave the same as the vandal who provoked the block. ϢereSpielChequers 18:27, 27 March 2010 (UTC)

It has not been used since April 2009, is there still a point in it ? Otherwise, we should mark it as historical. Cenarium (talk) 01:16, 27 March 2010 (UTC)

It appears to me that it's completely redundant to Wikipedia:Perennial proposals. So long as there's a pointer to the more active page, I think we can mark it historical. — Gavia immer (talk) 01:23, 27 March 2010 (UTC)

Persistent proposals, if I recall correctly, is a dumping ground for threads-that-never-end on a pump. It appears we don't have any now (obligatory <high five>).

Perennial proposals is slightly different. –xeno^talk 02:17, 27 March 2010 (UTC)

There are a few threads which stay for quite some time, like NOTNEWS at the top. In practice they remain on VPR. Hence it seems they're no need for /persistent. Cenarium (talk) 02:25, 27 March 2010 (UTC)

What do you mean by "not used"? Have you confused "not edited" with "not read"? WhatamIdoing (talk) 04:32, 29 March 2010 (UTC)

• I created "persistent proposals" as a place where proposals could go that actually have consensus, but that aren't likely to be implemented soon due to developer time constraints, so that consensus proposals aren't lost to auto-archiving. This was in the midst of the development of global login, which seemed to be taking forever and put any other development on hold. Looking at the page now it seems to have been misunderstood and misused. The closures with vote counts seem entirely inappropriate for what the page is supposed to be. Maybe the instructions at the top could use some tweaking; or maybe no one's even reading them. I'll bow to whatever the consensus is, if people the think the page should be retired, reworked, or whatever. Equazcion ^(talk) 04:41, 29 Mar 2010 (UTC)

I have an idea for a bot that could potentially simplify communication on Wikipedia. Before I potentially waste my time coding it now, I have posted a specification so that the Wikipedia community can offer input on the proposal. Is it a good idea or not, and how can it be improved on? Please respond on the talk page. PleaseStand ^(talk) 06:02, 29 March 2010 (UTC)

I am continuing discussion this ANI thread, as it was archived prematurely, and wasn't the correct place for the discussion anyway. When AbuseFilter was introduced months ago, consensus was achieved for enabling it without the block option. Since then, there has been a proposal to enable it, citing multiple cases where it would be beneficial. I initially opposed this, as there are non-admins who have access to the tool, and that would allow them to block without having to pass RfA. Having done more research, I have determined two different options.

1. The first option is the previously proposed one: allow blocking for everyone who has the abuse filter editor right, including non-admins.
2. The second is only allowing admins to create/edit filters that do not block users.

Most people who commented in the previous thread were in support of this proposal, but there wasn't enough to garner consensus, nor was option #2 raised. As such, I'm asking you all: What do others think about this proposal?

• Support option 2 - (X! · talk)  · @319  ·  06:39, 21 March 2010 (UTC)
• Support option 1, neutral on option 2 - To avoid any potential
  There is no room for error. --Shirik (Questions or Comments?
  ) 06:45, 21 March 2010 (UTC)
  • Comment as a side note, I think option #2 is meant to say "that block users" not "that do not block users" --Shirik (Questions or Comments?) 06:46, 21 March 2010 (UTC)
    • Fixed, thank you. (X! · talk)  · @325  ·  06:48, 21 March 2010 (UTC)

There should be some sort of system in place for reviewing, identifying and dealing with incorrect blocks. Regardless of how hard we try, sooner or later an innocent user will be blocked. There needs to be something in place to make sure that this is identified and fixed as quickly as possible. --Chris 06:52, 21 March 2010 (UTC)

A valid point. It would be trivial for me (or anyone) to write a bot that monitors blocks and reports them in, say, an IRC channel for review. As far as I know we aren't talking about any high-rate block filters right now. The only one we've even considered is 278 which has only had 58 hits in about 3 months. The reason for the block is not because of high rate of blocks needed, but rather to stop the detected user before they find a way around the filter. Reviewing every individual block should be trivial. --Shirik (Questions or Comments?) 07:08, 21 March 2010 (UTC)

I wish I could remember which one, but at one point there was a +sysop bot that could block users, but would always then immediately post a stock unblock request on their talk page to make sure human eyes would, at some point in the process, review the automated decision. Such blocks could and probably should be mentioned somewhere with a real-time emphasis, too (you mentioned IRC). Many people viewed this as an essential component of the system, and rightly so.

With that in mind, I'd think that any blocking filter should be capable of leaving a talk page message for the blocked user (which, for our policy purposes, would more than likely be a block template and one of the above-mentioned stock unblock requests for human review). – Luna Santin (talk) 01:42, 23 March 2010 (UTC)

• oppose both-- as a general rule, allowing for very rare exceptions. We admins need work to keep us from getting lazy! More seriously, there will very very rarely be a situation so utterly unequivocal that a human being should not look at it. There is enough of a tendency for a admin to fall into a bot-like mode, especially when dealing with a large number of problems in a row, but there always remains some degree of human non-AI functioning that will be on alert for special cases. That's what humans do best--what bots to best, is carefully without error or sleepiness check everything systematically following fixed rules to make a list for the humans to look at--humans, being human, tend to slip up on things like that. But there will be exceptions. Wallflowers is quite possibly one of them. I think the individual exceptions should get wide notice, and be proposed not just on the edit filter page, but on a highly watched admin board before individually implementing. This will keep this to where we really need it. Many of us who approved the edit filter project at the first did so on the condition that this function would never be implemented--I do not think it would have got the necessary initial approval otherwise. With experience, I've learned to trust it more than I thought I would. So I admit it's worth considering--something I had not thought I would ever admit--and I'm willing to go case by case, since we do have here an appropriate one to start with. DGG ( talk ) 07:11, 21 March 2010 (UTC)
• Comment when I supported the idea at ANI I had not realized that it would require new functionality to be enabled on the edit filter system or that any non-admins had been given access to the filters. These make this a bigger deal than I had thought. However, I still feel that in certain cases when a filter has been successfully deployed without false positives it may be appropriate. My preference would be that any flipping of the block functionality on a specific filter only take place after a specific discussion has determined consensus for it. I'm not sure where the best place to have such discussions might be; maybe
  WP:AN with a notice at Wikipedia talk:Edit filter? Thus I'm not actually too far from DGG though we are coming at it from different angles. On the other hand, if no consensus for enabling blocking functionality is forthcoming, could the filter be rigged to make an automatic report to ANI or otherwise flag accounts as needing rapid administrative scrutiny? Eluchil404 (talk
  ) 07:33, 21 March 2010 (UTC)
• Oppose Both (as general rule per DGG) I would likely support rare exceptions but in general I'd say no and have to agree with DGG. I am hesitant of blocking bots too except for specific exceptions like proxies etc (and I think this falls under the same category as a bot for these types of things). I think editfilters reporting to things like AIV could be a great option if possible (or a bot reading and reporting to the page) but I just see to many opportunities for false positives and generally want a human hand involved in a block (and not just looking over them later, they will invariably miss some). James (T|C) 07:38, 21 March 2010 (UTC)

I believe we already have a bot for that. Perhaps it's underused? –MuZemike 16:21, 21 March 2010 (UTC)

• Support if consensus acquired for each filter, just like adminbots. Sole Soul (talk) 07:45, 21 March 2010 (UTC)
• Oppose both Sounds too dangerous and risky, it would be possible to put in a rule that would totally lock up the Wikipedia by blocking anyone who tried to to anything. Just the sort of prank for April fools day. Graeme Bartlett (talk) 10:49, 22 March 2010 (UTC)

(edit conflict) Since two three have said "oppose in general, but potentially support approved, announced exceptions" so far, I'd like to raise a potential flaw with this and a proposed resolution. The problem is, regardless of our policies on exactly how this is enacted, if we want even a single filter to be able to perform a block, then we need to gain consensus for the configuration change. So, I propose option three:

Option 3. Enable abuse filter blocking configuration. No individual, admin or otherwise, is to enable a filter to perform blocks without first announcing the filter on

I believe this addresses the concerns while focusing on the technical problem itself. --Shirik (Questions or Comments?) 07:47, 21 March 2010 (UTC)

In this case any change to a blocking filter must be approved by consensus too—unworkable, in my opinion. Ruslik_Zero 09:55, 21 March 2010 (UTC)

• oppose mostly per the above (false positives). Providing theres 100% garantee of avoiding this in any option, I am opposed to any mechanism that automatically blocks. I think a human hand as said above is essential like at AIV. Thats just my thought on this the way i interpretted it. Though it is worth thinking about Ottawa4ever (talk) 15:05, 21 March 2010 (UTC)
• Oppose pretty much per the other opposers. I think humans would do a better job. I like the idea of the edit filters somehow notifying admins of potential blocks, though. I think an "editfilter reported" section would be a nice addition to AIV. Airplaneman ^talk 16:25, 21 March 2010 (UTC)
• I think a good idea would be to have the edit filter trigger an AIV report (if this is at all possible). This would be a similar approach to how Cluebot treats vandalism. An admin would be able to look over the report and then pull the trigger. ThemFromSpace 16:42, 21 March 2010 (UTC)
• Oppose It would be impractical and the risk of false positives too high. There is a bot, User:Mr.Z-bot, which reports to AIV users hitting the specified filters (I had proposed this bot because we need to identify and block immediately users matching certain filters, but filters with blocking would be unwieldy and a bot allows more customization, for example those in vandalism are reported after several matches, 10 I think). If you think certain filters should be added, it can be done by admins. Cenarium (talk) 19:13, 21 March 2010 (UTC)
• Oppose - At this point, I think it would be counterproductive. For every blocking filter, we might need to maintain 2 versions: the blocking one designed for minimization of false positives and a non-blocking one to catch the stuff the blocking one misses. One of the main benefits of the abuse filter is that its easily adaptable. If changes to blocking filters require a discussion, then it loses that benefit. Mr.Z-man 21:31, 21 March 2010 (UTC)
• Oppose due to the risk of false positives. There's a person on the other end, and getting blocked by a bot by mistake should be avoided at all costs. Aiken ♫ 14:02, 22 March 2010 (UTC)
• Oppose automated blocking. SilkTork *^YES! 18:35, 23 March 2010 (UTC)
• Oppose If existing processes for blocking vandals get saturated, maybe. Not now. Ray^Talk 19:10, 23 March 2010 (UTC)
• String support for option 3 - and have a bot actively monitor all such blocks to bring them to further human review (an unblock request such as {{unblock-bot}} is probably the best). עוד מישהו Od Mishehu 05:23, 25 March 2010 (UTC)
• Oppose All No . . just no, there's a non trivial *hand-waiving statistic* false-positives, so now we're wanting to add users wrongly getting blocked into the mix? Q ^{T C} 05:27, 25 March 2010 (UTC)
• Oppose Both - Per opositions above, which basically sum up my thoughts on the matter. Ajraddatz (Talk) 16:49, 25 March 2010 (UTC)
• Oppose entire proposal — as noted by Aiken, unintentional blocking is a significant enough problem that blocking should never be done except by a human who has been approved by community consensus to have that ability. Nice idea, but I can't imagine how the filter could have as small a chance of errors as a human can. Nyttend (talk) 04:02, 31 March 2010 (UTC)
• Oppose - Currently there seems to be no lack of capacity to handle blocks trough
  WP:AIAV. I would have no objection if that could be done. Excirial ^{(Contact me,Contribs}
  ) 15:42, 31 March 2010 (UTC)

Hi, i constantly bump into files like this File:Nobslogo.png that suffer from source link rot, commons has a partial solution in the form of flickr review where administrators check the source and marked it as verified so even if the link goes dead or the license changes there is still the admin review that proves it was ok at some point. I propose the creation of a policy and process say "Media source review", so the files don't end-up in source limbo.--IngerAlHaosului (talk) 15:21, 30 March 2010 (UTC)

Why not give the ability to users to delete their own test pages or whatever, without having to ask admins to do that? --JokerXtreme (talk) 11:56, 23 March 2010 (UTC)

This is covered in

move practically any page in the project to their userspace. If they are then allowed to delete that article, the combination of these two abilities is equivalent to the ability to delete any page. --Allen3 ^talk

12:15, 23 March 2010 (UTC)

How about restricting the ability to move in userspace for non-admins? Hm, I see there's also the ownership thing. Well, anyway, I can live without it. --JokerXtreme (talk) 12:47, 23 March 2010 (UTC)

On a technical level, we should ask first if this is technically feasible at all. As far as I know, each tipe of user has a defined set of user rights of things that can or can't be done, but those rights apply everywhere, beyond namespaces, which are actually a convention we use to keep some order, but without any actual effect on the technical level. Is there any example of an action that is or isn't available for a certain type of user at a certain namespaces and not others?

talk

) 13:17, 23 March 2010 (UTC)

The solution is to let users delete pages which they are the sole author of. Why they would want to do that, rather than just abandoning unwanted pages (perhaps in a conveniently out-of-the-way location, e.g. moved to a subpage of User:Joeblow/Sandbox), I don't know, unless the user posted personal information and now wants to expunge it. To be consistent, we should either let users delete pages they are the sole authors of, or else not honor their requests to have such pages deleted. The current policy doesn't really make much logical sense.

What Tisane proposes would work nicely, if it can be done. --JokerXtreme (talk) 15:04, 23 March 2010 (UTC)

It would have to be restricted to pages that the user is the sole author of, and had never been outside their own userspace. Otherwise it could be abused to do things like revoke good-faith article contributions without review. — Gavia immer (talk) 15:32, 23 March 2010 (UTC)

Why would anyone do that? --JokerXtreme (talk) 15:34, 23 March 2010 (UTC)

Editors do do that sort of thing, if they get in a spat with someone, or they disagree with the idea that

WP:OWN applies to themselves as well as others, and they try to withdraw contributions that they made in accordance with Wikipedia's license. We shouldn't allow that to be done unilaterally. — Gavia immer (talk

) 15:51, 23 March 2010 (UTC)

There's not much of a problem with the current system. I can U1 a page and it'll be deleted in a day. Js subpages have to be moved first and then U1'd. Plus this proposal will let users delete their talk pages, to wipe their slate cleanManishEarth^{Talk • Stalk} 15:43, 23 March 2010 (UTC)

{{

CAT:CSD even though the template rendering is broken. — Gavia immer (talk

) 15:51, 23 March 2010 (UTC)

Wow. ManishEarth^{Talk • Stalk} 02:57, 24 March 2010 (UTC)

• I believe the programming effort needed to ensure that the ability was not abused would outweigh the negligible time saved on teh part of admins patrolling the u1 category. Not to mention we're now having non-admins with admin actions in their log summaries for potential added confusion. Perhaps a db-u1 bot could be written on the 7seriesBot's framework. –xeno^talk 18:10, 23 March 2010 (UTC)

I understand that it may just be negligible in the amount of time it saves janitors, oops I mean admins; but how about the fact that it gives the average editor the ability to do things him/herself and feel better about being able to do things without templates and having others do things for them. Are admins that worried about the normal editor that they cant trust them? We're all just a bunch of misfits and potential trouble makers and vandals if we dont aspire to become an admin has been the growing vibe from the admin community towards this perennial proposal, discussions to which I was a party of at least twice. I know most admins are great individuals, unfortunately as a group you tend to be quite arrogant and sure its just a handful of bad apples, but allowing us mere lil guys to have this gesture and symbol of controlling our own destiny would go a long way to creating some good will. And I know this isnt just me, there's been LOTS of comments in many different places from regular editors not liking how admins have tried to make themselves a class separate from us, we are ALL equal, show us that you believe the same.Camelbinky (talk) 23:40, 23 March 2010 (UTC)

Well, Mediawiki is open source, write the code, and the sysadmins will consider enabling it. Prodego ^talk 23:44, 23 March 2010 (UTC)

Or to put it another way: Seriously, write up the software or propose it at Bugzilla. The granularity of rights you request doesn't exist in the current software, so far as I can tell. If you have a solution that can be committed to the software build, let's have a look. If it's a suggestion, well, build a little more support until some dev or other writes it. Those are the only realistic options I can think of. Franamax (talk) 02:50, 24 March 2010 (UTC)

Rephrase: MediaWiki is open source, write the code, try to find a developer willing to commit it (I for one will not), and then you can get a sysadmin to enable it. ^

^{[omg plz]}

 10:26, 24 March 2010 (UTC)

I think that in most cases, deletions of pages with only one author will be unopposed. However, these deletions will appear on watchlists, so that will attract the notice of anyone who cared enough to watch the page. If someone has an objection to deletion, he can request that an admin undelete it; or perhaps we would even allow for non-sysops to undelete pages deleted by non-sysops. And of course, if a user is in bad standing, he will probably be blocked from deleting his own pages. The fact that bots are always making edits to pages will probably create a de facto time limit on deletion of one's own pages. See also my remarks at Bug 14325, though, about how

There's a fairly easy way to do this, we just need a continuously running admin bot that does certain types of non-contentious u1 and G7 deletions. It is indeed a perennial, but in my view that's because with appropriate safeguards, it is such a good idea. The last big discussion that I'm aware of was at Wikipedia_talk:Criteria_for_speedy_deletion/Archive_36#possible_botting_of_speedy_deletes. I think we were able to identify tests such as the article not having been moved that resolved all the concerns about misuse, the only outstanding issue was concern by some that a bot to do a few thousand speedy deletions a year would user more development time than it would save admin resource. However as the number of active admins continues to decline we need to do this sort of automation, and this topic gets raised so often in so many different forums that I think there would be an additional benefit in that we'd no longer need to keep debating it. ϢereSpielChequers 06:35, 25 March 2010 (UTC)

User:7SeriesBOT seems to be chugging along nicely, so there's certainly a precedent for a bot carrying out uncontroversial deletions and at least some framework in place. –xeno^talk 23:06, 25 March 2010 (UTC)

I guess a bot could do the job, yes. I think this move would be a good "investment". The development would be done once, but the benefits would be...erm...perennial :) --JokerXtreme (talk) 08:15, 26 March 2010 (UTC)

I added the request to add this type of task to

BWilkins ←track

) 14:00, 27 March 2010 (UTC)

Strong Support I strongly support the idea of an autoconfirmed user having the ability to delete pages within his own userspace, as it does not impact the status of the encyclopedia, and it would simplify the process of userspace deletion. Immunize (talk) 15:32, 27 March 2010 (UTC)

I would oppose the proposal if all users, not just autoconfirmed users, would be able to delete their userspace, as I feel there is a potential for abuse. Immunize (talk) 17:00, 29 March 2010 (UTC)

The discussion is here:

Wikipedia:BRFA#7SeriesBOT_2. Maybe we should archive this? --JokerXtreme (talk

) 15:22, 1 April 2010 (UTC)

• There are many articles written in a few languages but not others. If I search, for example, for the Israeli folk singer Ruhama Raz in English Wikipedia no articles show up - only a red linked reference in another article. However such a page exists in Hebrew Wikipedia. I think it would be a useful Wikipedia tool to be able to know such a page exists when searching in English. It could appear in the search results and be generated by users of the respective Wikipedia that contains the written article. Does this seem like a good and feasible idea? I don't know anything about the technical aspects of such an endeavor. Has it been tried? THEMlCK (talk) 03:11, 1 April 2010 (UTC)
• Falling back to searching Wikipedias in other languages would be useful sometimes. --Cybercobra (talk) 05:20, 1 April 2010 (UTC)
• Just to play devil's advocate, I'd say for a good 99.9% of searchers, an article on Ruhama Raz in Hebrew would be completely useless. I don't think your idea is technically feasible; interwiki links are updated manually (either by editors or by bots) and do not always have the exact same name across multiple languages. For example, Earth is also Земя, Země, Γη, כדור הארץ, An Domhan, Планета Земја, Ziemia, Земля, Daigdig, โลก, and Terre (and that's just a small sampling). I don't think there's a decent way for the search system to know what to look for on other language editions (yes, sometimes articles on people will have the same name across multiple languages, but that's not a guaranteed case; can you tell me who Μπαράκ Ομπάμα or ジョージ・ワシントン are without checking those links?). EVula // talk // ☯ // 15:42, 1 April 2010 (UTC)
  • Μπαράκ Ομπάμα is Modern Greek for "(M)barak O(m)bama": clear. ジョージ・ワシントン|ジョージ・ワシントン in Japanese kana is "ziyŏ̄zi・washinton". Anthony Appleyard (talk) 22:15, 1 April 2010 (UTC)
    • ...you may have missed my point, but good job in identifying those two Presidents. :) EVula // talk // ☯ // 14:47, 2 April 2010 (UTC)
• I think that with the automatic translating resources available on the web, ie. google translator, any article, even in a foreign language, is more useful than no article at all. Also in terms of the problems of associating a foreign language page with the relevent english search term, I think it would probably have to be done manually through some type of method that allows people to tag certain search terms with foreign language links. It seems like it may be too complicated to do, but I still think it would be fairly useful.THEMlCK (talk) 03:13, 2 April 2010 (UTC)

Another potencial problem are the false positives, terms written the same way in different languages but with different meanings in each one. Consider for example

As long as it's implemented as a fallback only, that shouldn't be a big problem. --Cybercobra (talk) 02:38, 5 April 2010 (UTC)

Wikimedia Commons has media related to Village pump (proposals)/Archive 60.

Hello. I would like your comments and thoughts. I find that the little "Wikimedia at Commons" box very easily overlooked, even if one is looking for further images. The vast majority of non-Wikipedians don't know what Wikicommons is, and have no idea that clicking that box will lead to further images. Galleries are often replaced with this box, and the images are never seen. Probably hundreds of thousands of visitors a day come to an article seeking images, see what is displayed, and go away thinking that is all there is.

Wouldn't it be better to have a wee graphic image within that box indicating more pictures? After all, that is exactly what the eye is searching for. Anna Frodesiak (talk) 00:10, 31 March 2010 (UTC)

Agree. The idea is to convey information not to show off a pretty logo.

Dmcq (talk

) 08:18, 31 March 2010 (UTC)

Have to agree that there needs to be some improvement here to draw people to explore further and to be obvious what the link is for. Keith D (talk) 10:07, 31 March 2010 (UTC)

What about replacing "media" with "images and other media"? Let's face it, only a very tiny part of Commons are sounds or videos.

talk

) 16:04, 31 March 2010 (UTC)

Support switching "media" with "images and other media". --Yair rand (talk) 21:23, 1 April 2010 (UTC)

Nice but most commons categories have only images, and no other media. Some have other media and no images. Some bot must regularly verify presence of images and other media, drilling down into commons subcategories, and update appearance of the template.

NVO (talk

) 10:13, 8 April 2010 (UTC)

Maybe there could be some way to pull a couple of random images from the relevant category and make small thumbnails in the Commons box. That would increase visual impact a lot. Rd232 ^talk 17:37, 31 March 2010 (UTC)

Maybe something like the external image icon as in Fish trap. Anna Frodesiak (talk) 23:17, 2 April 2010 (UTC)

Support switching media to images and other media. Pretty obvious, just easier to read and understand. Ajraddatz (Talk) 00:49, 9 April 2010 (UTC)

With those templates, we should have

talk

) 02:22, 9 April 2010 (UTC)

• I think we need some policy guidelines on when articles should use "is" in the lead and when they should use "was". For example former TV shows use is, even if the show no longer produces new episodes, because it still is a TV show. Obviously past events should use was, because the event is over. But what about other things such as
  chat
  17:49, 6 April 2010 (UTC)
• A lot depends on context of that lede sentence. You are right that certain things will always "be" (is) something even if it is no longer made; an old TV show "is" still a tv show; that property did not change. On the other hand, the property of some things do change, such as people that pass away, "John Smith was an actor..who passed away in 2010", since there is no way for that person to be an actor ever again. The Ford Mustange example can be read two ways. The car "is" still the original pony car (that property can't change), but "was" manufactured by Ford (that property can).

So the easy way to say this is to consider how you are defining that topic in relationship to a property.

• If that property can never be taken away from that topic, then that topic "is" that property
• If the property depends on some time factor otherwise (death, no longer manufactured), then use "is" if it is currently true, otherwise "was" if it wasn't.

Note that one also needs to consider that a property may not yet be set; I don't have a good example but take a video game that has been stated to be in development but yet to be released; it "is" an upcoming video game. But if that game gets canceled, then the language changes to "was" a planned video game. But when you consider "upcoming" and "planned" as properties that are not permanent, these fall into the second point above.

Note this also means "is" and "was" can be mixed and matched in the lede sentence if both types of aspects are critical there. --MASEM (t) 18:05, 6 April 2010 (UTC)

• This is the first time I've used VP, so is this something we can write an editing guideline on, so users use the right lead word?
  chat
  18:10, 6 April 2010 (UTC)
• ""an old TV show "is" still a tv show": not with some old UK TV shows where no videotape or other recording survives: see
  Lost episode and Category:Lost BBC episodes. Anthony Appleyard (talk
  ) 05:28, 7 April 2010 (UTC)

It is kinda dumb that sysops can be blocked by other sysops from editing but not from unblocking themselves. The only purpose that could serve, that I can think of, would be stopping an out-of-control adminbot. I think we should allow bureaucrats to both promote and demote admins, and enable

talk

) 11:49, 26 March 2010 (UTC)

Under what circumstances do you see it as appropriate that an admin promotes another editor to admin? (This isn't sarcastic or rhetorical, I'm seriously trying to see where you're coming from.)--Cube lurker (talk) 12:20, 26 March 2010 (UTC)

Background reading: T17810 and discussion on EmergencyDeSysop. Happy‑melon 12:38, 26 March 2010 (UTC)

I understand the block/emergency de-sysop concept. (Not a bad idea except you'd be desysoped for using it.) It's the part on Sysops being able to give users the Sysop flag that i'm having trouble coming up with an example of when it'd be a good idea.--Cube lurker (talk) 12:47, 26 March 2010 (UTC)

• Oppose the first two points (admins&rollbackers being able to self-replicate) as opening the door to potential mass-organizated disruption. –xeno^talk 13:21, 26 March 2010 (UTC)

Yeah, EmergencyDeSysop, as currently written, unnecessarily requires the sysop who uses it to surrender his bit. It would be better to modify it per my suggestion: Give each sysop one credit, which he can "spend" to desysop another admin. A bureaucrat can later give him another credit (presumably after determining that the desysoping was justified) for future use, but no sysop can ever have more than one credit at any given time.

In reference to the common arguments against prohibiting sysops from unblocking themselves: It is unlikely that a situation would arise in which a wiki's sole sysop blocks himself and then can't unblock himself, because usually in that situation the sole sysop is also the site owner and therefore a bureaucrat. But it could happen if the site owner goes AWOL and there is only one other sysop. Therefore, sysops should simply not be allowed to block themselves.

I have actually seen the situation of two dueling sysops with no one else to intervene. I am a sysop on a small wiki with only three sysops, one of whom is the site owner and sole bureaucrat. The site owner has been AWOL for months now; who knows if/when he's coming back, but evidently he's paying the bills. Anyway, the other sysop, who is kinda young and impulsive and zealous about certain religious/scientific subject matters that were under dispute, went around deleting a bunch of articles, threatening unjustified bans, etc. I reverted everything and he eventually admitted he was in the wrong, and things settled down to normal. I'm not sure how things would have gone if a "nuclear option" like EmergencyDeSysop had been in place. Perhaps each of us would have gotten itchy trigger fingers and been inclined to launch a preemptive desysoping strike on the other, since potential would have existed to disarm the other from retaliating. Then again, he probably shouldn't be an admin; he's never really used his powers except abusively. So maybe the itchy trigger finger thing isn't so bad, as long as the good admin shoots first.

You have to apply a bit of

• Oppose Its easy to become a rollbacker, so you can't tell if a rollbacker will go bad. And anyways, We have ~63 'crats, which is more than enough for making admins. I for one, don't see why we need so many crats. We have very few RfA's which can be taken care of by 10 crats. Bot status management requires a few tech savvy ones (we don' have that many botrequests), and also around 10 to handle username changes. So we have more than enough people who can make admins. As for the rollbacker stuff, I strongly oppose it. The entire point of the usergroup hierarchy is that higher users can check the lower users. ManishEarth^{Talk • Stalk} 05:25, 27 March 2010 (UTC)

  There are 36 crats, not 63. Happy‑melon 14:40, 27 March 2010 (UTC)

Is it really that easy to become a rolbacker? Immunize (talk) 14:11, 27 March 2010 (UTC)

Its a hell of a lot easier than becoming a 'crat. All a user needs to do is have some experience with vandalism and show they are sensible and most admins will grant it--Jac16888^Talk 15:01, 27 March 2010 (UTC)

• There's nothing about this proposal that sounds like a good idea to me. Sorry. EVula // talk // ☯ // 16:11, 30 March 2010 (UTC)

• Support I disagree. I feel it would be reasonable for rollbackers and sysops to be able to grant other users the same rights that they have. Immunize (talk) 18:40, 3 April 2010 (UTC)
• Oppose. One person with bad intent uses a good hand sock to become an admin and then uses it to make a few more admin accounts. Probably during a time when it's late in the evening in the US and early in the morning in Europe. Those newly-sysopped accounts become meatpuppets that sysop more accounts. This would become a problem in a hurry.
  WP:BEANS, of course. Useight (talk
  ) 20:20, 3 April 2010 (UTC)
• Oppose - The only reason given is circular logic (people should be able to do it because they should be able to do it). Mr.Z-man 21:55, 3 April 2010 (UTC)
• Oppose - I'm sorry, but allowing rollbackers to assign the rollback flag? You just lost my support with that. Ajraddatz (Talk) 00:39, 9 April 2010 (UTC)
• Oppose - Ive got a bad feeling about this one. Its not that hard to get rollback rights to begin with, imagine the damage that could be caused by one bad seed. Worse imagine the damage caused by a rogue sysop making multiple disruptive editors sysop. I see both proposals causing alot of trouble. Sorry but I have to oppose this, but thanks for bringing up the thought, its still worth while to brainstorm wasy to improve the system. Ottawa4ever (talk) 10:54, 9 April 2010 (UTC)

If this system was put into effect, I feel we would need to more carefully select rollbackers and admins, because yes, there is some risk for abuse, though at this time I feel it is fairly small. Another option that could possibly decrease abuse of this system would be to not allow rollbackers and admins to grant other users these rights until they themselves have had the rights for at least 90 days. Immunize (talk) 14:20, 9 April 2010 (UTC)

Or we could just not do it at all, since no one has yet provided a logical reason why we should do this. Mr.Z-man 14:26, 9 April 2010 (UTC)

I know we're typically not supposed to close discussions on the pump, but in this case we should have closed it on Apr 3. The new comments from today (while entirely in good faith) are simply extending the amount of time this unsuitable proposal stays on the pump. –xeno^talk 14:52, 9 April 2010 (UTC)

So yopu feel this proposdal is completely unsuitable, and has no place on Wikipedia? Immunize (talk) 17:06, 10 April 2010

I think that at this time, it's not necessary (in the case of rollbackers, a solution in search of problem, and admins, an unsuitable solution to something not everyone agrees is a problem) and clearly has not been well-received. It is a wasted effort to attempt to tweak a proposal that has been so handily rejected. –xeno^talk 16:25, 12 April 2010

I was thinking if we looked at Good Edits vs Bad Edits made by different User groups we would be able to see where most of the vandalism is being made, which in turn will allow us to find a solution to reducing it. Finding the cause helps to eliminate the problem is the saying we need to use otherwise Wikipedia will soon be a trash-heap or a Junkyard.
.

I don't think sorting by user group is going to give much useful information. There really shouldn't be any vandalism from groups that have to be manually granted (which is most of them). User group doesn't give you much information about things like motive for vandalism (bored schoolkid, determined troll, etc.) or type of vandalism (childish vandalism, subtle vandalism, attacks on users, etc.). Looking at the user group is like looking at car accidents by type of vehicle. If you're an insurance company, it might help you determine rates, but if you want to actually reduce accidents, knowing whether the driver was in a sedan or a truck is less useful than knowing the location of the accident or whether the driver was distracted by something. I really can't see more than 3 possible conclusions from user group vs. vandalism rate data: 1) Everything is fine. 2) We need to ban IPs from editing. 3) We need more data. Mr.Z-man 17:03, 6 April 2010 (UTC)

So is there anything else we could do to collect more helpful data on this issue? Rd232 ^talk 21:21, 6 April 2010 (UTC)

I suppose one step would be to start a campaign to get people to not just revert but also flag vandalism revisions, and aggregate those bad revisions into a database table. A metadata field could be added to keep track of revisions flagged as vandalism. We could populate it partly by editors doing the flagging manually. And we can also looking at edit histories for, e.g.,

talk

) 06:28, 10 April 2010 (UTC)

Let me say first of all that I edit wikipedia because I feel an obligation to contribute to the extremely worthy goal of creating a universal, free content compendium of knowledge. I also enjoy the sense of satisfaction that I feel when I know that my contribution to pages like Presidency of Jimmy Carter, Henry Clay, and Supreme Court of the United States, among others, will help me and my fellow students look for information. I imagine that as we enter the 1970s in my US History Class, many of my students will use the references I have provided. That is why I edit wikipedia. However, I, and many like me, whether they're job applicants, other students at many different levels, and so forth, who are required to show that they are the kind of civic minded person who cares about improving their community, are totally unable to point to the good work they do improving wikipedia as examples of this service. Also, I think that alot of serious editors would appreciate commemoration for their services.

My proposal:

• Some mechanism for verifying the amount of hours someone has spent improving wikipedia. (I'm required to do this for local civic organizations and my schools honor society, but I'm aware that it's a fairly common practice.) Of course, ensuring that the contribution are helpful is a must. I think that it is far more helpful to be a wikipedian, whose editing can benefit hundreds of others in one day than it is to be part of the "safety patrol" at local football games that accomplishes nothing. Yet one task allows me community service hours and the other doesn't.
• Some title to commemorate service. I will say that the above conversation and its theme is one with which I agree: this website is at its best when it maximizes editor equality. We should not have ranks that put some editors over others, dissuading some from participating and driving others to work for the irrelevant distinctions rather than the good of this project and the promotion of it's goal of enriching human knowledge. Therefore, these titles should in no way, shape, or form enhance the ability of an editor to do anything on wikipedia. Still, if I could call myself a "senior editor" or "distinguished contributor" on my college/job applications, that would help. I would also feel thanked for my contributions. I think many admin hopefuls are admin hopefuls simply because they want some kind of commemoration for their service. We could base these titles on some simple algorithm, like overall edits, overall content added, overall activity, and so forth.
• We should have a "thank you bot" that automatically places awards, barnstars, or something like that, on the talk pages of users when ever they do something good, which we could calculate with an algorithm. (Congratulation on your 1000th page edit or something)

In conclusion, I edit because I think that it's a good way to serve my community. I will continue to edit for that reason. However, I would appreciate being thanked for my contributions and having some way of showing organizations looking for public service that I serve my community in one of the best ways possible: I edit wikipedia.

Thanks. In.Lumine.Tuo.Videbimus.Lumen (talk) 17:22, 11 April 2010 (UTC)

I have thought of this as well, but counting how many hours spent on here is an extremely flawed way to calculate value of contributions. There are just too many variables. I personally would have been able to submit thousands (yikes!) of community service hours to my school. Try taking a look at

WP:EDITCOUNTITIS). Remember, it's quality of contributions, not quantity. Regards, Airplaneman ✈

18:50, 11 April 2010 (UTC)

It would be good to have something to show for our work here. I'd separate your proposal into two parts, one for recognition for the sake of recognition, and one for proof that can be shown on job/organization applications. The latter is what I'm more intrigued by. The former is really already handled by barnstars etc, and I don't think a bot or the like is really necessary. It would be nice to have something to show a potential employer or the like for time, effort, and skill demonstrated in editing here. Contributing to any other publication the way many of us do here would usually be resumé material. I'm not sure how that could be accomplished in any objective and verifiable way though. Maybe

DYK credits? Or maybe a "committee" could be established, that an editor or group of editors wanting to establish credit for improving an article could appeal to? Equazcion ^(talk)

19:18, 11 Apr 2010 (UTC)

I think that if you were to try to put your Wikipedia editing on a résumé, you'd need to have some kind of "real-world" sounding title. "Senior Editor" was mentioned above; something to that effect. If I put Wikipedia Bureaucrat on mine, I don't think that'd be real impressive, but Wikipedia System Operator sounds like it has more weight. Although I must add that I'm not a big fan of the proposal. I already see a myriad of editors plastering the top of their userpage with icons representing the GAs, FAs, and DYKs they've made. Seems kind of pretentious to me, especially if we start adding official titles. Useight (talk) 19:26, 11 April 2010 (UTC)

I find it strange that the originator of this proposal actually uses the word "compendium", since that actually is the name of a "rival" of Wikipedia which actually does have pretty much what this editor is proposing... is this a coincidence or is this proposal specifically designed to make Wikipedia have something similar to Compendium? As I understand Compendium has specific titles and requires you to provide proof of your identity and any education, degrees, etc that can lend itself to being used for future references. I'm not saying we should automatically reject proposals because a competitor already has this idea, I applaud the idea of taking good ideas from competitors and appropriating them for ourselves so as to crush them easier (and so does Bill Gates). Perhaps someone with more knowledge of Compendium could illuminate how they work and see what would be good for us to copy and what wouldnt be.Camelbinky (talk) 19:56, 11 April 2010 (UTC)

I was wrong, the competitor is actually called Citizendium, not Compendium. I apologize! But they do have a similar system to what is being proposed, perhaps we could learn something from them.Camelbinky (talk) 01:07, 12 April 2010 (UTC)

Hi! I suggest that, when clicking the tab "new section" or "+" to add a message to a talk page, if the user has not signed the message, that the four tildes are automatically added to the end of the message. Anna Lincoln 10:46, 13 April 2010 (UTC)

User:SineBot already does this, except when you're an experienced editor. ManishEarth^{Talk • Stalk} 17:00, 13 April 2010 (UTC)

Plus it would be of limited use if it only works with the new section button, and LiquidThreads is going to do this anyway. -- Nx / talk 17:05, 13 April 2010 (UTC)

A concern which once in a while pops at

The use of underscores actually displayed in articles in very rare, anyway: I searched for _ using my browser's Find feature in the last four days'

I'd like to see some more data over-and-above "10 random articles" before supporting this. –xeno^talk 14:59, 12 April 2010 (UTC)

The use of   is relatively rare in articles too, mind you. Wouldn't this just serve to make the raw wikitext marginally more confusing for a fairly limited benefit?

talk

| 15:03, 12 April 2010 (UTC)

There are eleven   in Today's Featured Article alone, more than thirty in yesterday's, more than thirty in last Saturday's, and twenty-seven in last Friday's. (And do you really mean that 2_+_2_=_4 is more confusing than 2 + 2 = 4 or was that a typo? Consider that not everyone is familiar with HTML entities; the former is easier to input, too.) ― ___A._di_M. (formerly Army1987) 15:24, 12 April 2010 (UTC)

To be honest, I think they're about equally odd to a novice user - they're both characters that don't do what they immediately seem to - so that wouldn't change much. However, it would produce a marginal extra bit of confusion for everyone who already knows how to use wikitext - it's worth considering this before implementing any such change.

I'm quite surprised as to the usage figures for FAs, though I suppose I should have expected a higher use rate when we're looking at fancier articles. I'd previously done a quick check using special:random, and after two dozen articles still hadn't found any using nbsp; I wonder if the absolute number of articles this affects is very low, but those articles are quite concentrated?

talk

| 15:57, 12 April 2010 (UTC)

To a good first approximation, everyone who knows about the existence of the non-breaking space is "familiar with HTML entities". Because it would be defining something brand-new, the underscore idea would be marginally more confusing. Ntsimp (talk) 16:04, 12 April 2010 (UTC)

A while ago the same discussion took place with conclusion that ,, (a double comma) would be the best choice to represent a non-breaking space in the edit window. It is more similar to the several other double-characters for special wiki items and more unlikely to be happen naturally. A very detailed proposal was worked out, still available at User:Noetica/ActionMOSVP/StableWholeProposal including gathering of opinions, which can be found in User:Noetica/ActionMOSVP/Archive2. It did not happen. −Woodstone (talk) 16:33, 12 April 2010 (UTC)

Agreed. I don't think I'd support a single underscore as a wikimarkup for a non-breaking space. A double comma, or even double underscore would be more appropriate.—NMajdan•talk 17:19, 12 April 2010 (UTC)

Isn't there a template which automatically applies non-breaking spaces to any text wrapped inside the template? -- Black Falcon ^(talk) 17:58, 12 April 2010 (UTC)

Not quite, but there is {{nowrap}} which is used sometimes, especially in scientific articles. However, it takes eleven keystrokes, as against six for a simple &nbsp;, so it is only used for fairly long chunks of text or stuff containing thinspaces. Physchim62 (talk) 18:03, 12 April 2010 (UTC)

That's the one I had in mind. Thanks, -- Black Falcon ^(talk) 18:15, 12 April 2010 (UTC)

Non-breaking spaces are, in principle, allowed in page titles (they are prohibited only by our title blacklist, not by MediaWiki). Where, in this proposed system, should [[Foo_bar]] lead? What is the expected meaning of Foo__NOTOC__bar? The underscore is a highly unsuitable character for this function. Happy‑melon 18:24, 12 April 2010 (UTC)

What I think [[Foo_bar]] should do is basically the same as what {{nowrap|[[Foo bar]]}} does now: make the same link as before, and display as a space rather than as an underscore, but prevent line breaks within the link. This would be especially useful when linking personal names, as it is bad typographic style to allow line breaks between the first name and middle initial but currently too much hassle to prevent. —David Eppstein (talk) 18:52, 12 April 2010 (UTC)

What about [[Talk:Foo_bar#use of __NOINDEX__]]?? Or [[Template talk:Foo#Deprecate some_parameter parameter]]?? [[Talk:Foo#Discussion about links to www.some_website.com]]? The latter two are problematic mainly because a header ==Deprecate some_parameter parameter== will no longer be successfully linked to by a section link which copies the same wikitext, which is unhelpful. Happy‑melon 19:04, 12 April 2010 (UTC)

I had in mind the same as Eppstein about what [[Foo_bar]] should do. (BTW, someone on WT:MOS pointed out that unpiped [[Foo bar]] also goes to

Foo bar.) Anyway, the magic words are something I had not thought about, but also ,, would work for me. (BTW, TeX uses ~, but that character is too widely used (e.g. to mean "approximately") so doing that here wouldn't be worth the trouble.) ― ___

A._di_M. (formerly Army1987) 19:32, 12 April 2010 (UTC)

I like the concept. I suspect most editors do not use non-breaking spaces as often as

WP:MOS recommends (e.g., in measurements), partly because the &nbsp; entity is a bit cumbersome, and {{nowrap}} even more so. As to implementation: we already have the convention where underscores represent spaces in file names. As to the relatively few cases when an underscore per se is desired, could we use doubled underscores in the markup? - J. Johnson (JJ) (talk

) 20:42, 12 April 2010 (UTC)

Oh please can we have something like this? Please please please. We desperately need better markup for hard spaces. Ozob (talk) 02:36, 13 April 2010 (UTC)

I'm for this in the form of double underscores interpreted as non-breaking spaces (and single underscores interpreted as bare underscores). Double underscores aren't used for anything in normal prose, so they will stand out properly as markup. However, we had better make certain that they are interpreted as a literal double underscore in <code> tags, because double underscores are quite common in encyclopedic code listings. — Gavia immer (talk) 03:00, 13 April 2010 (UTC)

In LaTeX they use the tilde for this (~). Considering how rarely this character is used in articles (except for URLs) this seems viable. Dcoetzee 07:45, 13 April 2010 (UTC)

We quite often have people writing things like "there's ~30 cases of this" in non-article space, mind you. And the system would get horribly confused if you wanted three of them in a row ;-)

talk

| 08:49, 13 April 2010 (UTC)

The Citron beta (Beta version 3--At the moment we're on Babaco) changes the editor box into an iframe, and collapses templlates, among other things. It could be proposed to collapse nbsps at usability:Talk:Prototype. ManishEarth^{Talk • Stalk} 17:06, 13 April 2010 (UTC)

• Why not just use {{
  s}}? –xeno^talk
  17:06, 13 April 2010 (UTC)

The {{

s}} template adds spaces, which is not the same as marking a space as "non-breaking". As to the tilde ('~'), it has an ordinary usage that I suspect is almost as common as exclamation marks. Not a good idea to mess with that. Of the proposals made so far, I'd say the underscore, or double-underscore, are best. Alternately, could some completely different character be used? Something that could be "composed" on the keyboard? It would need to be non-blank, so it would be visible in the markup, but would be converted like any other markup. - J. Johnson (JJ) (talk

) 20:59, 13 April 2010 (UTC)

It adds non-breaking spaces... –xeno^talk 21:01, 13 April 2010 (UTC)

The problem with {{s}} or {{nowrap}} or whatever is that they are no easier to type than &nbsp; and they clutter the source text just as much. The underscore is easy to type and occurs very rarely in actual running text (except in certain situations, like code examples, for which there needs to be a rather easy way to get a real underscore; <code> or <nowiki> is probably easy enough). It has the added bonus that it looks enough like a space so that it doesn't interfere with reading the source text, while looking distinct enough that it won't be confused for a normal space. There's a reason TeX reserves a single uncommon character (the tilde) for non-breaking spaces—such "ties" occur quite often in properly typeset text, so it needs to be easy to type. My !vote goes to the single underscore. —Bkell (talk) 21:40, 13 April 2010 (UTC)

I agree with Happy-Melon that the underscore is an unsuitable character for this. I looked at 10 random pages and 6 of them used underscores. In particular, they're used rather frequently in the description parameter for Template:Coord (things like {{coord|51.01234|-1.56789|type:landmark_region:GB}}. I doubt there's any single character that appears on a standard English keyboard that isn't used in at least a small percentage of pages. Mr.Z-man 22:06, 13 April 2010 (UTC)

But the underscore in a {{coord}} parameter need not be substituted, because it doesn't show up in the article text, so that's not a problem. —Bkell (talk) 03:50, 14 April 2010 (UTC)

It will, however, break anything that uses that information, like the geohack system. [2] is not the same as [3]. And there are still the issues that Happy-melon noted above. Mr.Z-man 05:09, 14 April 2010 (UTC)

No, it doesn't have to break these things. That's what I'm saying. Why wouldn't we just leave those as underscores? The only underscores that would be replaced by non-breaking spaces are those that would otherwise show up as underscores in the article text. Other underscores, such as those in URLs, magic words, template parameters, etc., don't need to be replaced and shouldn't be. This isn't a proposal for an indiscriminate replacement of all underscores in the page source with non-breaking spaces. —Bkell (talk) 11:47, 15 April 2010 (UTC)

So then you wouldn't be able to use it in things like infoboxes and references? You're just trading off one downside for more. That fixes most of the conflicts, but now the behavior is totally inconsistent with the rest of wikitext. Mr.Z-man 12:17, 15 April 2010 (UTC)

Yes, actually implementing this would require some thought, and I don't know the internals of MediaWiki, but I still think it can be done. The underscore–to–non-breaking–space conversion doesn't have to be done before template expansion; it could be done after. So underscores get passed to templates as is. If the template expands the parameter somewhere where it will show up in the article text, it gets converted to a nonbreaking space; otherwise it stays as an underscore. I don't think the complexity of this is an insuperable problem, though maybe MediaWiki's architecture would make such an idea very difficult to implement without a major structural change. I don't know. —Bkell (talk) 23:05, 15 April 2010 (UTC)

@Mr.Z-man: For sufficiently large values of "small percentage of pages", there's ` (U+0060 GRAVE ACCENT). ― ___A._di_M. (formerly Army1987) 12:42, 14 April 2010 (UTC)

How is this discussion not over yet? &nbsp; has two outstanding advantages the other suggestions don't - it's googlable, and it doesn't look like a mistake (as ,, does). And googling a strange-looking thing like that is a first response for many unfamiliar with it - much more plausible than hunting down whatever help page tells you an underscore or {s} is a non-breaking space. Let's just leave well alone on this one. Rd232 ^talk 22:23, 13 April 2010 (UTC)

{{s}} is just one character fewer than  . Doesn't look like a breakthrough to me. ― ___A._di_M. (formerly Army1987) 12:42, 14 April 2010 (UTC)

It's actually {{

s|1}}, so... =\ –xeno^talk

12:46, 14 April 2010 (UTC)

The point is the confusingness of nbsp, and the template s is easier to understand (Newbies will hafta learn what templates are sooner or later). ManishEarth^{Talk • Stalk} 12:03, 16 April 2010 (UTC)

What do you mean "its googlable"? Google doesn't return the wiki-syntax, it returns the actual article page with the rendered text, so double-underscore or double-comma or whatever is decided wouldn't show up when Googled. For the record, I'm for double-comma. Since underscore is too common, double-underscore is already in use by MediaWiki.—NMajdan•talk 14:17, 14 April 2010 (UTC)

That's precisely my point. Google &nbsp; and you will quickly figure out what it is. Googling punctuation with special meaning for Wikipedia? Not so much. Rd232 ^talk 14:21, 14 April 2010 (UTC)

Wikipedia already has special meanings for '', ''', ~~~~, [[, {{, and other strange combinations of symbols, and yet no one complains that they aren't Googleable. If we used "Googleability" as a criterion for syntax, we would be using straight HTML and typing <a href="http://en.wikipedia.org/wiki/Article">Article</a> instead of [[Article]]. Adding something for non-breaking spaces will be no worse than all the rest of the strange wiki-syntax we use. There are help pages for these things, if people can't figure them out for themselves. Somehow I learned how to use it all. —Bkell (talk) 11:58, 15 April 2010 (UTC)

It's not the same, because basic wiki syntax appears on every page. You either cope with it on sight (comparing the wikitext with the final page), or go and look for help. nbsp; is different both because it's rare (in articles; less so in templates) and because it's harder to guess what exactly it does. Rd232 ^talk 12:10, 15 April 2010 (UTC)

This would be far from the most exotic behaviour of the MediaWiki parser, or even the most exotic piece of wikimarkup. I don't think it's fair to assert this issue to be the absolute showstopper you present it as. Happy‑melon 12:35, 15 April 2010 (UTC)

It's just one of the issues. There's also a substantial element of "it ain't really broke". The "cluttering" issue only really applies to fairly complex templates, and changing this isn't going to make much difference in terms of making them easier to edit. Introducing a change, however, is a very substantial cost in itself. That said, out of the alternative suggestions I could most live with __ for a non-breaking space generally, plus changing the parser such that a single _ is treated as an nbsp within a wikilink. Rd232 ^talk 13:05, 15 April 2010 (UTC)

The whole reason &nbsp; is rare is because it's so awkward to put in. That's the problem we're trying to address. It should be a lot more common than it is; see

WP:MOS#Non-breaking spaces. —Bkell (talk

) 23:05, 15 April 2010 (UTC)

I suppose that's an argument. Do we have some examples of where we would use it in articles if it was easier? Rd232 ^talk 12:55, 16 April 2010 (UTC)

Sure. Yesterday I chose three random articles and put in non-breaking spaces where they should go: [4] [5] [6]. Note that Dimethylheptylpyran had quite a few non-breaking spaces already. —Bkell (talk) 14:36, 16 April 2010 (UTC)

Um, I don't think these changes are really necessary [7]. We're designing for web, not print, and these days people are used to lines breaking wherever. So I'd say this sort of addition of nbsp;s into body text is neither really necessary, nor, really (because of making it hard to read) a good idea. I'd reserve it for cases where it affects formatting more substantively than preventing line breaks between word(/data) pairs in article body text (templates are different). I think I'd say the same even with _ or __ instead of nbsp;. Rd232 ^talk 14:47, 16 April 2010 (UTC)

"We're designing for web, not print…" That's a little short-sighted, don't you think? Don't forget

proper usage of dashes or any of many other points in the Manual of Style. This isn't an extremely pressing issue, but it is a detail that would be nice to have addressed. —Bkell (talk

) 16:08, 16 April 2010 (UTC)

Using hard spaces as much as your examples will make it hard to read even if it's just a single underscore. People are not used to that, it looks funny, and it will be a constant battle with people "fixing" it. I don't think it's worth the cost. Dashes are different because bot/AWB fixing of those (and many other MoS issues) doesn't confuse anyone. Stick to templates and maybe wikilinks and concrete cases where it's actually necessary, but not routinely as you suggest. Wikitext is often too much like programming anyway, but at least until now the main body text has generally been OK (barring overuse of cite templates - urgh); sprinkle nonbreaking space commands around in the main copy as you suggest, and we lose even that, making it even harder for people to get started editing. Rd232 ^talk 16:42, 16 April 2010 (UTC)

A clarification seems needed here. I doubt if "using hard spaces" per se makes for hard reading. More the reverse: the whole point of good typography – and this is just as relevant on a screen as on paper – is to make the reading clearer. (E.g., keeping measurements together with the units of measurment.) I think what you mean is that the current markup for non-breaking spaces ("&nbsp;") makes for hard reading of the source text. Which is why we are having this discussion – to see if there might be a cleaner, simpler way of implementing non-breaking spaces. - J. Johnson (JJ) (talk) 20:52, 16 April 2010 (UTC)

Just to say that we desperately need a shortcut for the ugly duckling six-character entity. The reason it is not much used is because it is so arduous to key in. It is the kind of clutter that puts newbies off and makes editing no easier ever for experienced users; replacing it with a single- or double-character entity would be ideal and easy for newbies to learn. Tony (talk) 07:30, 17 April 2010 (UTC)

One easy way for newbies (and anyone else entering text directly in the edit window) is to add nbsp to the list of special characters; all you have to do it click on it. However! For many of us being able to prepare text off-line is not just preferred but obligatory, so there is still need for some kind of markup code. Also, the non-breaking spaces really need to be visible for editing existing text. But this could be a special symbol, or glyph. Even if it is not one of the standard "keys", that's okay for me, as I don't mind using the Compose key, and the newbies can pick it off of the list. - J. Johnson (JJ) (talk) 20:52, 17 April 2010 (UTC)

Announcement of the first stages of a project to peer-review, improve and translate medical and biology articles. This project aims to transfer high-quality articles from the English Wikipedia to other Wikipedias that are written in languages used in developing world. Tim Vickers (talk) 17:40, 16 April 2010 (UTC)

This is a notification of a discussion where by see also are replaced with transcluded cores Wikipedia_talk:Manual_of_Style#Trial_of_.22core.22_conceptGnevin (talk) 15:19, 17 April 2010 (UTC)

... should exist. Better yet, a way to add myself to ONLY THE TALK PAGES. Or a way to transclude the changes to those talk pages into one page. The idea is to permit the wikiprojects to better supervise what's going on in their articles. JD Caselaw (talk) 18:34, 17 April 2010 (UTC)

You have a list? Paste them into:

WP:OWN. Jack Merridew

18:41, 17 April 2010 (UTC)

(edit conflict) A number of WikiProjects have bot-created lists of articles of interest to them, and it is possible to monitor changes to those pages using Special:RelatedChanges. If the list contains only talk pages of articles, then (if I'm not mistaken) only changes to those will be shown. -- Black Falcon ^(talk) 18:47, 17 April 2010 (UTC)

Black Falcon, thanks for the helpful response. I am not aware that it's possible to watchlist a talk-page without watchlisting the corresponding article itself. If it is possible, then my proposal is solved.

WP:OWN. I think most people agree that it would be a good thing if wikiprojects could be more closely associated with the articles within their... ummm ... area of interest. JD Caselaw (talk

) 19:00, 17 April 2010 (UTC)

Actually, I was slightly mistaken: Special:RelatedChanges monitors both articles and talk pages, but it is possible to filter the results by namespace. See e.g., Wikipedia:WikiProject Africa/Watchlist (page size is > 250 KB) and Special:RelatedChanges/Wikipedia:WikiProject Africa/Watchlist (and filtered to show only the Talk namespace). -- Black Falcon ^(talk) 19:16, 17 April 2010 (UTC)

If the project has a category into which all tagged pages are added (which is down to MAIN_CAT in the banner template - see {{WPBannerMeta}}), then you can use RecentChangesLinked on that category to track talk page recent changes for all the wikiproject's talk pages (it's the talk pages in that category). Example. Rd232 ^talk 19:53, 17 April 2010 (UTC)