Wikipedia:Village pump (proposals)/Archive 37

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

Village pump (proposals) archive  

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

---

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

Force edit summaries

To help work out what editors are doing, and find editing patterns, I propose a new technical implementation that only allows submission of edits with an edit summary. Dendodge|Talk^Contribs 12:27, 18 October 2008 (UTC)

Wikipedia:Perennial proposals#Automatically prompt for missing edit summary. Anomie⚔ 13:23, 18 October 2008 (UTC)

I support with all my heart. But, how do you get people to write more than "edited"/"cleaned up"/etc. continuously as edit summaries? Aditya^{(talk • contribs)} 10:15, 23 October 2008 (UTC)

Study Guides

I would like to see “study guides” made available. In their simplest form a specialized wiki page would list existing articles in a logically-progressive order. For example, a study guide to physics would begin listing articles on simple machines, basic math, etc, and progress through Newton’s laws, optics, electricity, etc. and eventually cover a typical high school physics curriculum. It would then go on through calculus and college level topics and finally branch out into many specialty fields.

The goal is to provide a roughly linear path a student could follow through existing Wikipedia articles to attain proficiency in a chosen field. A secondary goal is to provide Wikipedia editors insight into the completeness of the available articles.

A more complete study guide would link existing articles with narrative text placing each into useful context.

Because the study guides themselves are wiki pages, they would continue to grow and improve as do the content pages. --Lbeaumont (talk) 00:00, 22 October 2008 (UTC)

Our sister project, Wikiversity is set up to handle material like that. ·:· Will Beback ·:· 00:16, 22 October 2008 (UTC)

And in a short-index form, see Portal:Contents/Lists of basic topics for a still-developing handful. -- Quiddity (talk) 18:50, 23 October 2008 (UTC)

The ability to block vs. "no big deal"

• Please read the entire proposal before commenting.

(Discussion moved from WT:RFA.) - jc37 23:39, 11 October 2008 (UTC)

(I have been working on a more lengthy proposal (with all the whys and wherefores), but since I will presume that most active on this page have seen the discussions over the last several years, I suppose I can offer this in light of the above discussions with less copy/pasting : )

As noted recently in the "view undeleted" discussion, there are tools which can be a "big deal", and which shouldn't be given out as if they are "no big deal".

That said, I think we have an environment in which most admin actions can be "undone", and in which we (hopefully) don't promote those with a lack of discernment to adminship.

(For example, we have WP:DRV for deletions, and WP:RPP for protections. Though for blocking, it's spread through the sub-pages of WP:AN, and elsewhere.)

However, probably the most controversial ability of an admin is the ability to block another user.

And most of the cries of "admin abuse" occur (accurately or inaccurately) in relation to the ability to block/unblock.

Also, there is the issue that the "block log" of a user seems to be quite a bit more of a "big deal" than a page log. Especially since these logs are typically not edited. (While noting that additional logs may be placed to help clarify.)

If there is anything that should be "unbundled" from the administrator group of user-rights, it's the block-related user-rights. (For purposes of discussion, let’s call this the "blocker" package.)

Imagine how many times that we hear: "They're great editors, but their use of tools when blocking/unblocking..."

Consider if it was possible for Arbcom to suspend the block-related abilities from an admin, while allowing the rest of their abilities to remain. Everyone, including the encyclopedia itself, would benefit.

And consider those individuals who've lost adminship in the past merely due to usage of block-related tools, but was considered to be trusted to use the other admin tools. That person might be more easily able to re-attain adminship by merely not requesting the additional block-related user-right package.

And imagine those wiki-gnomish editors who feel that adminship is just too much of a "third-rail" for their ability to edit? So another benefit is that that more Wiki-editors may come out from lurking.

This also may be of interest to those proposing "provisional" or "trial" adminship. One could request adminship without requesting the ability to block/unblock. And later, request the "blocker" user-rights.

This wouldn't require any additional bureaucracy. Simply add a line to each RfA: "I am also requesting the 'blocker' user-rights" or "I am not requesting the 'blocker' user-rights at this time". (or some such).

Oh, and as an added bonus, it also should help decrease the contention at RfA somewhat.

So anyway, those are just some of the many reasons to suggest this.

And one final thing:

Since all the people who currently have these tools went through an RfA in which those commenting presumed that they would have these tools, if these user-rights are unbundled from adminship:

All users who currently have the "administrator package" of user-rights, would immediately be given the "blocker" package.

This should also help prevent opposition from those who might be concerned that their current "abilities" would be changed in any way.

Here are the user-rights that I think should be placed in a new user-group called "blocker":

• Block a user from sending email (blockemail)
• Block other users from editing (block)
• Bypass IP blocks, auto-blocks and range blocks (ipblock-exempt)
• Bypass automatic blocks of proxies (proxyunbannable)
• Disable global blocks locally (globalblock-whitelist)
• Can add groups:IP block exemptions
• Can remove groups:IP block exemptions

What does that leave in the adminship package? A lot. (See Special:ListGroupRights.) Most of which involve the ability to review/edit almost anything content-related (save oversight), and the ability to help editors to contribute (such as account creator).

I welcome your thoughts. - jc37 03:58, 11 October 2008 (UTC)

Clarification

(Copied from a post below)

I'm going to try to re-explain, based on the confusion below (and elsewhere).

The proposal is to split the single package of user-rights that admins receive from one package to being grouped in two packages.

The process for bestowing those rights need not change whatsoever.

That includes RfA, or whatever other process bestows user-rights.

I've listed the reasons why this would be useful several times already, but to summarise, it's to provide options for those who might wish to contribute more to wikipedia, but do not wish what some see as the "burden" of having the block-related user-rights.

We should allow for that option.

And a reminder: If this proposal is implemented, current admins would not lose the right to block. This is merely modifying the package user-rights in the software, not modifying any user-rights that admins already have. And the "blocker" group would be granted by bureaucrats on en:Wikipedia, just as these rights always haves been.

And to make it clear: this proposal is not about giving non-admins the ability to block!

So adminship, and the RfA process would not change, but the following options (among others) would be possible:

• Candidates could request to not receive the "blocker" package upon requesting adminship. (For whatever their personal reasons are.)
• Individual admins may decide to not want the blocker tools, and could request them removed.
• Arbcom would have the option of removing the blocker tools from an otherwise trustworthy contributor.

This is just about providing options.

As someone said below, Let's free the wikignomes. - 12:02, 13 October 2008 (UTC)

Discussion

Heh, you didn't have to double space every line. RockManQ ^(talk) 04:26, 11 October 2008 (UTC)

You're saying that this "blocker" package would be requested through RfA, correct? RockManQ ^(talk) 04:30, 11 October 2008 (UTC)

Yes. The idea is for this unbundling to cause the least amount of "change" as possible. So those who currently have the abilities should still have them, and the location where they are currently requested (albeit currently as part of a larger package) would still be the place/process to request them. - jc37 04:51, 11 October 2008 (UTC)

I think this is probably not a great idea. Blocks can be very controversial, and the ability to remove someone (temporarily or permanently) from the community should be decided on the basis of community trust. Protects, on the other hand (as I said above), are much more trivial in terms of controversy and ease of undo. Prince of Canada ^{t | c} 06:56, 11 October 2008 (UTC)

This proposal doesn't change that. To gain this package, one would still have to go through RfA. - jc37 06:59, 11 October 2008 (UTC)

• Definitely!. Free the Wiki-gnomes. I suspect there are lots of people out there who would be happy to use the non-block-related admin tools to help clean up, but have no particular desire for the intensity of the current RFA process or the strife of blocking. --Alecmconroy (talk) 07:00, 11 October 2008 (UTC)

• I'd support this if it included room for more categories, like a "deleter" (some one who could delete pages) or something. RockManQ ^(talk) 15:48, 11 October 2008 (UTC)

I do think though that that "RfA time" for this proposal would have to drop. The current time used would simply be to long for how many proposals we get. RockManQ ^(talk) 15:52, 11 October 2008 (UTC)

• Hmm, I'm glad I read this thoroughly. Every other admin-right-unbundle suggestion I've seen so far has been, in my view, a way of massively increasing bureaucracy and confusion for minimal return. This one, however, I like. It makes a lot of sense, as you're correct that "blocking" is by far the most controversial tool most admins have. An admin without a block button still has a lot of useful extra tools. ~ mazca ^t|c 00:08, 12 October 2008 (UTC)

(ec)Difficult issue. Essentially it involves splitting not only responsibility, which here is given on trust, but also accountability to the community. Admins are given the mop on the basis of being able to exercise judgement in a number of dimensions. I feel that to dilute that would not only create an unnecessary layer of bureaucracy (in more than one way; consider the effect on WP:AN and WP:ANI- would we need yet more pages for such limited reviews?); additionally, there would undoubtedly arise conflicts due to this separation of functions. The ability to delete pages is perhaps the least contentious here, but again, understanding of policy is paramount and I perceive little difference between the judgement required for that, and the exercise of discretion in blocking. If we would trust some editors to properly assess a CSD, arguably we should also trust them to know when, and for how long, a vandal should be blocked. Accordingly, i remain to be convinced. --Rodhullandemu 00:13, 12 October 2008 (UTC)

Unfortunately that's been shown to not be the case (per quite a few arbcom cases). Some people apparently have issues when it comes to interaction with other editors; while having less of an issue with discernment of content. In some cases, at least, these seem to be separate skillsets.

And I don't believe any new pages will be required, though obviously the community could decide to create/deprecate pages per consensus. - jc37 00:19, 12 October 2008 (UTC)

I take your points on board, but I see this as a classic case of mission creep; although it appears to have some merits in principle, functionally I foresee it creating more problems than it ought to solve. For one thing, what happens when a suitably-permitted editor incorrectly applies CSD; what is the venue for review? For another, I don't see a rich hierarchy of permissions being productive in the long term, because it will inevitably lead to elitism (or perceptions of it) in some form or another, and corresponding tensions between layers of the hierarchy. And that hierarchy is made more likely to follow, by the "why not?" argument. --Rodhullandemu 00:39, 12 October 2008 (UTC)

WP:DRV?

Based upon your comment, I'm starting to wonder if you're understanding the proposal. (For example, all other admin tools would still be part of the admin package.) I'd be happy to clarify on any point. - jc37 00:48, 12 October 2008 (UTC)

I know that WP:DRV applies to CSDs; however, my experience is that it's rarely used for that because most CSDs are created by new editors who do not understand about notability. However, it's late for me now and I will maybe address this when some other editors have pitched in. --Rodhullandemu 00:56, 12 October 2008 (UTC)

I don't like this. I think block+delete+protect - all the "action" admin tools - should be given out either all or nothing. When all you have is a hammer, everything looks like a nail. If I can't trust someone with the ability to block, I won't trust them with the other admin rights either; actions don't exist in a vacuum. Mr.Z-man 01:07, 12 October 2008 (UTC)

I suppose that the quick response is: Then why don't admins have checkuser then? Same with Oversight, and several other individual user-rights. If it's all-or-nothing, then it should be "all", right? But it's not. The level of "trust" varies based upon the task, the access, and the associated responsibility. And as blocking is quite different than "review/edit content" (the majority of admin tools), why should it not be offered "in addition"? Bureaucratship is. Just because this package was comprised of certain things in the past, doesn't mean that what it comprises can't be altered i nthe present. (Indeed, several things have been added to it recently.) Again, No current admin will lose a single user-right solely based upon implementation of this proposal.

Please also read a few of the responses below, as they also may address your thoughts and concerns. - jc37 05:05, 12 October 2008 (UTC)

Well, I put block/delete/protect on one level of trust, checkuser/oversight is another level altogether. I'm well aware it can be altered. I just don't see the point. If I trust someone to delete pages and protect pages, I would trust them to block users, and vice-versa. I think many people put far too much emphasis on blocks, this proposal would only further this "blocks as a massive freakin' deal" mentality that some people have if we have admins that we don't trust with the block button. Bureaucratship is offered separately because of lack of a need for 1000 bureacrats and the potential for massive damage from abuse. The same is not true of the block right. (Though at least one wiki does give admin+crat together). - Mr.Z-man 06:53, 12 October 2008 (UTC)

As I mentioned to someone below, that's a valid opinion, I suppose.

But I really wonder how much of this is merely because it's entrenched in people's brains that these go together simply because they have in the past. Blocking and deleting are two entirely different things. Just because they happen to be part of a "package" doesn't mean that they must stay part of the package. (And if in doubt, check out the recent debate at meta about global admins. Most everyone seemed to like the idea of global blocking, but there were those who didn't want to trust such people with content access to individual projects.) I'm not requesting this in a vaccuum. There are quite a few applications for this beyond merely the en:Wikipedia.

Honestly, this is merely a technical feature proposal in how these would be grouped. The community would still be right there deciding how they were bestowed.

As you note with that other project, the community can decide to bestow whatever.

All I'm suggesting is for the way that the package is grouped in the software be changed. It honestly need not affect anything for an individual project. (And in hindsight, perhaps this should have been a bugzilla request.) - jc37 07:07, 12 October 2008 (UTC)

Well, the way I see it, there are some people who see blocks as some terrible thing, an admin blocking someone is like a country using chemical weapons in a war. To them, having a block in their log is as bad as having a felony conviction in their criminal record. Now with this proposal, we would have admins - trusted users - who we don't trust with the ability to block. How is that going to look? The fact is that admins are supposed to be trusted users. If we can't trust someone with the ability to block, are they really all that trusted?

The other reason for my oppose stems from usage. When deciding whether to protect a page, either from vandalism or edit warring, there's almost always 2 options: protect the page or block the vandals/edit warriors. An admin without the ability to block now only has one option.

The sysop group is supposed to be just a group with extra rights for cleanup and maintenance that would pose a security risk if given to everyone. While changing this here is something that could be discussed, I see no reason to change the software default. Remember that Wikimedia is not the only user of MediaWiki. Mr.Z-man 17:18, 12 October 2008 (UTC)

I agree with the first point, people do feel that way, hence why the blocking tool can be rather contentious at times.

And right now we have "trusted users" who we don't trust with the ability to block. As I mentioned before, just because you or I may group our "trust" broadly, doesn't mean everyone does. And again, this is subjective. It's as diverse as those editors who "trust" to give out their name online, and those who don't. Both groups have those who "trust" admins, but yet they don't trust them with certain information. Because information can lead to ability, which can lead to abuse. So people "trust" differently on giving out potential abilities. Again, if all types of trust were related, there wouldn't need to be packages of user-rights. Anyone could do anything.

"When deciding whether to protect a page, either from vandalism or edit warring, there's almost always 2 options: protect the page or block the vandals/edit warriors. An admin without the ability to block now only has one option." - That's dispute resolution. And the presumption is that if an admin chooses to not request the tools, they're likely not going to get involved in editor disputes for the same reasons. No, they wouldn't necessarily be restricted, but let me quote from a recent arbcom case:

• "Administrators should bear in mind that at this stage in the evolution of Wikipedia, they have hundreds of colleagues. Therefore, if an administrator finds that he or she cannot adhere to site policies and remain civil (even toward users exhibiting problematic behavior) while addressing a given issue, then the administrator should bring the issue to a noticeboard or refer it to another administrator to address, rather than potentially compound the problem by poor conduct of his or her own."

And that obviously applies to anyone who doesn't have the ability to block. If in need, find help. So your concern is moot. Just because a single admin may not choose to have the ability to block, doesn't mean that there are not options available.

"The sysop group is supposed to be just a group with extra rights for cleanup and maintenance that would pose a security risk if given to everyone." - This is just an aside, but it's kind of a stretch to call WP:BLOCK - "cleanup and maintenance". (And it being a "security risk" to the content of Wikipedia seem misapplied.)

Though that aside, in looking at the current set of tools, besides the blocker tools, most of the rest are essentially: "edit/review anything content related (except oversight), and assist other editors to contribute (such as account creator)". One can do those things and simply not need the ability to block.

The ability to block is to prevent further disruption of the encyclopedia due to the actions of an editor. That's policing the system, not administrating the content of the system. And there is simply no reason (except that it's been like that to this point), that admins need to be in a role of policing editor actions. Consider that technically, anyone can revert, and in a sense we all police other editors' actions. Why is the ability to block something that must be applied in a particular package of user-rights called "admin"?

There is no reason. It just has been.

And now there are editors whom we would trust with the tools who don't want the ability to block. And will refuse to run for adminship due to that. Do we deny ourselves the benefits of their contributions simply because: "But it's always been that way".

If that was true, why do non-admins receive rollback? (Ignoring the process of how it's given.)

So all I'm suggesting is to allow for editors to request a package that has all the tools of adminship except the blocking package.

If it enables us to get even one more editor to become an admin, it would be worth it.

And in the meantime, all those who are admins whould still have the ability. All those requesting could still request the ability.

This is about simply providing an option.

But to do it, the admin package would have to be split. So all we do is split the blocking tools to a separate package. It's simply a software thing. Technically on each wiki nothing would necessarily change.

So for example if a certain wiki decided that they want all admins to have all the tools, including blocking, then the bureaucrats there simply add sysop and blocker.

Why shouldn't individual wikis have this option? Consider wikia or anyone else using this software. Why would offering another package option be a bad thing? I would think it would make things more adaptable for them?

And to make it clear, the "other package option" that I'm talking about is the current admin package minus the blocking tools. (While having the blocking tools as an additional package.)

If you feel I am misunderstanding you, please clarify. - jc37 09:22, 13 October 2008 (UTC)

The "cleanup and maintenance ... security risk" bit was more in response to changing the software defaults than changing it just here - if other wikis want to do this, they are free to do so already; the software is not entirely designed around Wikipedia.

I really don't see accountcreator/rollbacker/ipblockexempt as "trusted users" in the same sense as admins. Those 3 groups are trusted with one specific thing by one or 2 admins. Its not even comparable to the community trust we require for admins. We give out rollbacker because there is a huge need for it. Granted, with scripts like Twinkle people could go without rollback, but we have so many rollbackers now, I don't think it can even be considered an admin right anymore - we have more rollbackers than admins.

I don't think the ability to ask for help makes my argument moot. We give admins the tools so they don't have to ask for help for routine admin tasks.

"And now there are editors whom we would trust with the tools who don't want the ability to block. And will refuse to run for adminship due to that." I personally find that opinion a possible sign of several attitude issues, none of which I'd like to see in an admin, or any sort of trusted user. They may be selfish, not willing to help the project simply because they "don't want" the ability to block - its like choosing a gas-guzzling SUV over a smaller fuel-efficient car for the sole reason that you don't like the backseat cup holders in the small car, despite the fact that you have no intention of using them. It could also be a sign that they lack self-control, that they think they would go wild with the block button - and I'm supposed to trust this person with the other buttons? Mr.Z-man 23:10, 14 October 2008 (UTC)

• "...the software is not entirely designed around Wikipedia." - So you're saying that the admin package as it currently exists does not exist as a package anywhere but en.Wikipedia? That wasn't my understanding, but a clarification would be welcome.
• "I don't think the ability to ask for help makes my argument moot. We give admins the tools so they don't have to ask for help for routine admin tasks." - We give editors tools so that they can help with routine tasks. So it shouldn't matter if one admin has the block user-right and another doesn't, and more than it should matter if one editor has check-user and another one doesn't. It's rather simple to request help. And why should we presume bad faith?
• "They may be selfish, not willing to help the project simply because they "don't want" the ability to block..." - So is someone "selfish" because they don't want the ability to change usernames? So is someone selfish because they don't want the ability to rollback edits? Just because they want to help in specific ways, which may not fit your personal opinion of how they should help? These are still people who are interested in helping contribute with most of the other tools. Let's not baldly call contributors who merely want to help with the encyclopedia: "selfish".
• "It could also be a sign that they lack self-control, that they think they would go wild with the block button..." - or perhaps it could be that having the blocking tools may create a "social stigma" for the editor, which may be more of a hindrance than help when it comes to contributing. Let's not forget that while this is an encyclopedia, this is a community of editors, and being able to collaborate effectively is important. And there are editors who feel that having the tools may interfere with them being able to collaborate as effectively, or even similarly to how they may without such tools.

Why is it so important that an admin be required to be involved in WP:DR? Why can't we allow for admin wikignome contributors? - jc37 14:05, 16 October 2008 (UTC)

• Yes, the sysop package is defined in the software, but it can be modified for one site without changing the software default, like we added the ability for admins to grant rollback and ipblock-exempt.
• Where am I presuming bad faith? Its just a matter of trust levels.
• So is someone selfish because they don't want the ability to rollback edits? - If they want to help as an admin and refuse to do so because they don't want rollback, yes. No one is going to force them to use rollback. They don't have to use tools that they don't want to. Happy-melon illustrates this very well below. Can you imagine someone refusing to make more than 9 edits on an account because they don't want the ability to move pages? Its just silly. Its choosing an illogical personal feeling over helping the project. In my book, that's selfish.
• having the blocking tools may create a "social stigma" - Again, this is that "blocking as a huge freakin' deal" mentality that this proposal is only going to encourage. If people see the ability block as something to fear, we shouldn't encourage them to continue thinking that by designing a new adminship system around it. We should work to convince them that it isn't a huge deal. Treat the condition, not the symptoms.
• Where did I say admins should be involved in WP:DR? I haven't done anything close to DR work in more than a year, many of my deletions are wiki-gnomish. I certainly don't consider myself a bad admin. Mr.Z-man 16:27, 22 October 2008 (UTC)

• I wasn't asking whether it could be modified on a single Wiki. I would presume that (since it's open source) anyone could modify the software for their particular wiki. AFAIK, the admin package (the application of "Adminship" to a single username) on every Wikimedia wiki is the same. Are you saying that this is incorrect?

• Several of your comments above seem to indicate "bad faith" to me. The overall suggestion that someone may choose to not wish to have certain tools may indicate an "attitude problem" is a real problem for me. That's like saying that everyone must want to grow up to be a bureacrat or checkuser someday. I honestly think that such an "attitude" presumes bad faith of those who may simply want to help, but not in every area. From what I understand, the use of checkuser is logged. Technically, is there any reason to not give every admin that ability, and merely suggest that they not use it until they are "confirmed" but arbocom (or whatever the "appropriate process" is). And if there are admins who might say that they don't want the tools. Would you suggest that they have an "attitude problem"? If anything, the idea of suggesting that not wanting certain tools is an "attitude problem" would seem to me more of an indication of a perception of the "big freaking deal", than merely suggesting that some admins may simply not want to have "extra" tools, because they have a preference as to how they prefer to contribute to the project. I'm attempting to look at being more inclusive of accepting contributors at the level they wish to contribute, while it seems to me that the opposing view is being disinclusive, and honestly overly controlling, for no more pupose than IWANTITTHATWAY.

• "Its choosing an illogical personal feeling over helping the project" - Actually, technically, one could say that those opposing are doing the same thing, since others with perhaps a different perspective than yours might suggest that not implementing this may be a hindrance to contribution efforts. And this discussion has somewhat clearly turned into a debate over the "perceptions" of adminship and the tools thereof.

• "If people see the ability block as something to fear..." - That's not it. It's not being afraid of the ability to block (AFAIK). It's that those who can block may be treated differently from those who can. And if you disagree, then consider going to a party. If one or more of those present are police officers, do you think that may affect the social climate or dynamic of the party? Even if they are "off-duty" and just there to enjoy the party? And if you don't like the allegory of admins to police, consider that technically we're all police here, it's just that admins have the ability to directly "send a person to jail" (remove the individual from the group environment/society). Does everyone act or feel that way? No, of course not. But there are those who do (on both sides). And the only way we're ever going to "make it better" is to attempt to find some "common ground". And honestly, most of what I'm seeing in this discussion is fear. Fear that non-admins might get the ability to block (which isn't this proposal). Fear that certain admins may lose the ability to block (which isn't this proposal). Fear that this may lessen the scrutiny of adminship (which isn't this proposal either). Indeed, even if a candidate said they weren't interested in the ability to block, they would still have several abilities that the community (as noted by several in the discussion here) considers worth a high amount of scrutiny. So it's not that there would be any fewer questions, just merely that the questions would not include the question of blocking, and perhaps be more focused on the other concerns. The ability to delete and to view deleted information is a potent ability, as noted recently. I don't think that any less scrutiny is going to occur.

• "Where did I say admins should be involved in WP:DR?" - The ability to block is one of the facets of Wikipedia:Dispute resolution. It's used to prevent disruption of the encyclopedia by actions of an individual user. Vandalism may be defined as a "dispute" between the editor and the rest of the community. The ability to block effectively makes anyone who has it a "bouncer" for the community. Determining (individually or by consensus) who needs to leave, and even who may come back. And not having that ability doesn't make an individual any less of a "janitor", they just need not be involved in the tasks of being a community "bouncer". - jc37 22:37, 24 October 2008 (UTC)

• Suppose a user is granted adminship without blocking enabled, then the user will have to go through another RFA to be granted blocker rights. This will still add bureaucracy. I also saw many opposes due to "delete-happy", et al, though in general opposes are more tangential. Why not adding the "deleter" rights, then the "protector" rights at this point. If I don't trust a user to block, then I won't trust the user for deleting, viewing deleted, or protecting either. And in general, I won't trust the user for adminship. Unbundling could allow to game the RFA system, I think. Inversely, I don't think I would "fear" a wiki-gnome with the ban-hammer. There are also cases where protection of a page isn't appropriate, but blocks would be: this could cause an undesired preference for the former. There are also concrete points to consider: it will likely confuse uninformed users and create difficulties in the user rights system. Cenarium ^Talk 01:19, 12 October 2008 (UTC)

  This isn't about whether we'd trust a wikignome with these user-rights, it's about the Wiki-gnome being interested in stepping up to help, when currently many have said that the "third rail" that goes along with even just having the blocking tools, just isn't worth it in order to help with the content aspects of what being an admin entails.

  And yes, if someone were to go through RfA but just for adminship and not the blocking tools, and decide later that they want the blocking tools, they would go through another RfA. But first, RfA isn't over-run. (I can't remember the last time we had more than a dozen simultaneously.) Indeed if you read the talk page, they're always talking about how there are constant backlogs, and how there is a pressing need for more admins. Well removing block/unblock to a different usergroup would actually remove a stumbling block for most editors. (Nearly every editor that I've nominated for adminship had to be convinced over a period of months. Most say it's not worth the accusations and hassle.)

  Well, most of those accusations (and concerns) go away when one does not have the blocking tools.

  So this is about enablement. Enabling more editors to be comfortable with the idea of becoming admins. To allow other options for adminship based on want or need, and even to give arbcomm another "tool". They would be able to remove the ability to block from editors who say they don't have the "temperment" for that sort of interaction, but for whatever reason don't have the self-control when it comes to personal interaction to refrain from using the tool. But on the converse, when it comes to deletion and page protection those same editors may be exemplary.

  Why should we not allow for greater development of our resources? If this helps even slightly to open the door for more editors to be confortable with adminship, then let's do it.

  A case of: Nothing to lose, and much to gain.

  But if you feel I'm missing something, please feel free to clarify.

  And remember that all current admins would retain the ability to block. (As I noted above.) This would only affect those who decide to not request the blocking tools.

  And I would presume that there would be no confusion in the user-rights system. Due to recent changes in how user-rights are given out (rollback, for example), this should be able to be implemented fairly easily. - jc37 05:05, 12 October 2008 (UTC)

• Blocking is not a big deal; most of the relevant information is provided in the request at AIV or on the admin noticeboard - the admin just runs up the "evidence" against knowledge of WP policy, and makes the decision. I do a lot of that... well, no I don't because 95-98% of blocking decisions are so obvious as to be no brainers (the job that was written for me), and I have to weigh my decision in less than once every ten requests. On the other hand, I do not participate in closing XfD's - since the nuances and judgements are so much finer. Do I consign an article to the bin because the references are difficult to decipher, or require a understanding of the premise to evaluate the arguments? Blocking is easy, and a good editor will usually accept a mistake made on their account as regards a couple of hours not being able to edit as against their painstakingly researched article being deleted because the sysop is incapable of evaluating the discussion.
• In short, the admin criteria is still trust - and that includes the recognition by the sysop that their area of expertise lays in some areas and not others, and not to go trampling where finer footwork usually yields better results than by simply jumping in. LessHeard vanU (talk) 01:51, 12 October 2008 (UTC)

  I think it's great that this is easy for you.

  However, the same may not be true of everyone.

  People are different, and have different talents, skillsets, etc. And, as we've seen at several situations or dispute resolution (including WP:RECALL, and WP:ARBCOM) there are more than a few individuals who are great admins, except when it comes to the blocking tool.

  While it may be effortless for you, interaction with people is different than interaction with content. We should accept that and work that into our expectations. Accept what people may have to offer, not force them to be great at everything before we can trust them with certain things.

  The thing I'm most concerned with this proposal is that I really believe that this is something that most people would support if they understood it, but I'm concerned that in this climate of everyone wanting to unravel tools and hand them out like candy, that this proposal may be misunderstood. - jc37 05:05, 12 October 2008 (UTC)

• Oppose, as I oppose every proposal which considers handing out administrator userrights to non-administrators. It is, and I think it should remain, an all or nothing package. If I trust a user to block somebody, I will trust them to protect pages, delete pages, and do everything else an administrator can do. If I don't trust a user with one of the userrights, I don't trust them with any. Users want to block somebody → RFA is that way. - Rjd0060 (talk) 03:20, 12 October 2008 (UTC)

  I'm sorry, but you misunderstand. This is not about giving the block ability to non-admins!

  This is about the ability to add/remove the block/unblock-related user-rights without having to add/remove the entire sysop package.

  There still would be an RfA, which still would be determined by a bureaucrat.

  But this allows for greater flexibility , while hopefully helping to reduce the zomg drama.

  And "trust" is incredibly subjective. We trust in certain amounts for certain things in certain ways. If there wasn't a different skillset and trust level involved for different user-rights, we wouldn't have bureaucrats, checkusers, oversight, etc. - jc37 05:05, 12 October 2008 (UTC)

Again, oppose. - Rjd0060 (talk) 13:46, 12 October 2008 (UTC)

• Oppose - per Rjd0060 and Mr.Z Man. From both a techinical and practical view here, splitting up the rights does not make sense, as the admin package is determined by trust. If a user can't be trusted with block, how should they be trusted with delete, protect (and unprotect), etc? Xclamation point 04:15, 12 October 2008 (UTC)

  Actually, the admin package has been determined by whatever has been tossed into it by the developers. (For various reasons, including community requests.) It's bestowing the user-right package called "sysop" (which has changed several times even this year), that is determined by trust.

  Please take a moment to read my comments above. I think you may be misunderstanding the intent of this proposal. - jc37 05:05, 12 October 2008 (UTC)

• As I read it, currently every admin gets a sysop package and if any portion is abused they lose it all. My take on that as an IP user is that there are plenty of ways to contribute to WP without either the sysop package or the "user" package, so losing the entire sysop package is definitely no big deal. I do think though that many blocks are too long and too frequently administered, and that the policies should be more realistic. For example, an automatic min 31 hour block is really not necessary, because usually you are dealing with a kid on the school library computer who is playing during study period and a 1 hour block would have exactly the same effect as 31 hours. I would strongly discourage a separate rfa-2 to get a separate set of sysop tools. Though yanking one tool that was misused is gentler than yanking the whole toolbox, that isn't what is done to editors who get blocked - they don't get one tool taken away when they get blocked, they get all their tools taken away. So to summarize, the problem isn't how to deal with admins who abuse their tools, the problem is how the tools should be used to begin with. 199.125.109.104 (talk) 05:50, 12 October 2008 (UTC)

  While I suppose that's a valid opinion, I disagree. And the side benefit of piecemeal removal is just that, a side benefit. I am more interested in opening adminship up to those who keep saying that they don't want the drama. When most of the "drama" merely involves the blocking tools.

  And that's just one of many benefits. What I find great about this is that there are so many other dynamic benefits to this. And the only negative that I see is: "If I trust them with one tool, then I trust them with all. And if I don't trust them with one tool, then I don't trust them with any" - Which is valid of itself, I suppose, but then if you feel that way, make that clear when commenting in an RfA (regardless of whether they would be asking for admin and blocker, or admin without blocker). This proposal doesn't remove that right of opposition.

  And also, when an admin loses sysop tools, they don't have all their user-rights removed, only those which happen to currently be part of the admin package. - jc37 06:06, 12 October 2008 (UTC)

• Oppose. If a person does not deserve a block button, can he be trusted with a delete hacksaw? I'd place the delete rights above blocks. NVO (talk) 06:17, 12 October 2008 (UTC)

  Then this proposal wouldn't affect your opinion, since the buck would stop at deletion, before even discussing access to blocking. This is merely about the package. The process stays the same. - jc37 06:55, 12 October 2008 (UTC)

• Oppose. In the same vein as what NVO is saying, in my time as admin I've never had one of my blocks questioned by the community but have had my fair share of deletion reviews. I think deletion is more open to abuse/misjudgment and can have a strong negative impact on the project (blocking just causes AN/I threads that nobody outside of the core editors care about). BJ^Talk 06:38, 12 October 2008 (UTC)

  And in the same vein as I said to NVO, this is about the way the items are grouped as a package. AFAICT, your opinion affects whether someone would initially gain adminship. So it's moot in relation to this proposal. - jc37 06:55, 12 October 2008 (UTC)

  I feel like it taking away a cop's taser and leaving his gun. If deletion requires more trust that blocking, why remove one without the other? BJ^Talk 07:14, 12 October 2008 (UTC)

  This proposal does not propose to "take away" anything. Not one single user-right.

  It's merely splitting the block-related tools to a separate group. All current admins would still have those tools, and all new admins can request all the same tools that are requested at an RfA. No change.

  It's merely a change in the packaging. - jc37 07:18, 12 October 2008 (UTC)

  I understand that but for newly promoted admins or those that lose their blocker bit are left with the ability to delete, which I feel requires more trust and judgement. Implementing this would have the function of lowering the bar of RfA and/or allowing admins that have abused blocking in the past to remain admins, which I gather is the entire point of the proposal. Simply, I believe that those that can not be trusted to block users should not be trusted to delete articles. BJ^Talk 07:30, 12 October 2008 (UTC)

  Fair points, let me take this in parts:

  • "Implementing this would have the function of lowering the bar of RfA..." - Not lowering the bar, but removing one point of contention during the RfA discussion. In other words, if the candidate is not requesting the blocking tools, then that's one less thing that the commenters will have to concern themselves with, and can focus on discussing the rest. Those who have concerns about someone having the delete power will still have the same ability to voice those concerns.
  • "...and/or allowing admins that have abused blocking in the past to remain admins..." Only if that's what arbcom (or whomever) decides. That's an "option", it's not necessarily what will happen, but merely something that would be more possible than the way things are currently coded.
  • "...which I gather is the entire point of the proposal." - No, actually. The entire point is to try to reduce contention. That, and I honestly feel that this has the potential to open quite a few doors that are currently only barely ajar. That this would give arbcom an extra choice in closures would seem to be a benefit, though only one benefit among several others (many of which I've listed on this page). - jc37 08:16, 12 October 2008 (UTC)

• Oppose - While most complaints about admin abuse are over blocks, this doesn't mean that most incidents of admin abuse are blocks. Several blocked users got blocked as a result of their reaction to what seems to them to be an unjustified deletion. Deletion seems to me to be a sensitive area no less than blocking is. עוד מישהו Od Mishehu 06:46, 12 October 2008 (UTC)

  Ok, I just had my Charlie Brown ARRRGH moment. I'm better now.

  Everyone seems to be getting lost in the details of the "benefits", and not understanding that this won't change much of anything.

  I may have miscounted, but I believe that there are currently 36 user-rights assigned to adminship (per Special:ListGroupRights). If this proposal goes through, every current admin would have: 36 user-rights.

  No change. This is merely splitting off some into a separate group for the potential adaptability.

  It provides options, not requirements. - jc37 06:55, 12 October 2008 (UTC)

• Strong Support Blocking is about the most controversial aspect of adminship and one of the reasons why I would never set myself up for an RfA. However I do a lot of recent and new page patrolling and have seen CSDs go unanswered sometimes for days. And these are very obvious need-to-be-deleted pages. Thus I believe wiki-gnomes, at least, should have the ability to delete pages. Bstone (talk) 14:33, 12 October 2008 (UTC)

  So that we can lower standards for RFA without block, and then have a multitude of delete-happy administrators ? I have seen dozens of wholly inappropriate speedy nominations, administrators have to decline them repeatedly and even so, hundreds of pages are restored due to hurry speedy, but most are forgotten. This would worsen the situation, and would be more damageable to Wikipedia in the long term. Cenarium ^Talk 14:50, 12 October 2008 (UTC)

  Reducing contention is not equal to lowering standards. In this case, one has nothing to do with the other.

  In what way do you think that any editor's personal standards for trusting someone to delete pages would change? - jc37 15:06, 12 October 2008 (UTC)

  It won't change it. But overall, it will present adminship -block as a not so big deal, while it is. Though it will depend on the area the admin will work in, performing blocks is not the only source of contention for admins, as seen in recent Arbcom cases (Palin for example) and ANI discussions. If a user wishes to avoid controversial and contentious situations, then adminship is not the way. While it is true that most deletions (and most blocks) are really non-controversial, the current system works well enough. Cenarium ^Talk 15:54, 12 October 2008 (UTC)

  "But overall, it will present adminship -block as a not so big deal..." - I disagree.

  Suppose a candidate is applying for a job, which (let's say for the sake of whatever) has 3 responsibilities. Due to the position having those three responsibilities, the interviewer has three checklists of questions to ask the candidate. Now let's say that the candidate had the option to sign on but the position only had 2 of the 3 responsibilities. Then the interviewer only had 2 checklists of questions to ask. The responsibilities are still just as vital as they were before, and the questions just as vital, we've just merely removed a set of questions (and the potential contentions thereof).

  But then neither one of us can control (and only guess) how much value a person will assign to something or a group of somethings.

  That said, even if we look over this discussion, using it as evidence, I highly doubt anyone will place any lesser value upon adminship, than they do now. - jc37 16:21, 12 October 2008 (UTC)

• Oppose. Current processes are appropriate for the usage and giving of this particular tool, which should remain bundled with the other sysop tools. Cirt (talk) 08:04, 14 October 2008 (UTC)

  Cool. However, I'm not suggesting any change to the process. RfA will still exist. Gaining of all of the 36 admin user-rights would still go through RfA. This isn't about bestowal, but packaging. (Please read the full proposal and the rest of the discussions for more information. Else, feel free to ask for further clarification.) - jc37 08:10, 14 October 2008 (UTC)

  Understood. I stand by my comments, and still oppose. Thanks. Cirt (talk) 11:55, 14 October 2008 (UTC)

• Oppose While well-intentioned, I feel this would inevitably lead to the promotion of unqualified admins (under the logic, "Well, they have lots of problems, but they won't get the block too, so what harm can they do?" Besides, blocking can be instantly undone, and thus isn't the most "dangerous" admin right (that would be view-deleted). Andrew Lenahan - Starblind 10:28, 14 October 2008 (UTC)

Arbitrary discussion break

I'm going to try to re-explain, based on the confusion above (and elsewhere).

The proposal is to split the single package of user-rights that admins receive from one package to being grouped in two packages.

The process for bestowing those rights need not change whatsoever.

That includes RfA, or whatever other process bestows user-rights.

I've listed the reasons why this would be useful several times already, but to summarise, it's to provide options for those who might wish to contribute more to wikipedia, but do not wish what some see as the "burden" of having the block-related user-rights.

We should allow for that option.

And a reminder: If this proposal is implemented, current admins would not lose the right to block. This is merely modifying the package user-rights in the software, not modifying any user-rights that admins already have. And the "blocker" group would be granted by bureaucrats on en:Wikipedia, just as these rights always haves been.

And to make it clear: this proposal is not about giving non-admins the ability to block!

So adminship, and the RfA process would not change, but the following options (among others) would be possible:

• Candidates could request to not receive the "blocker" package upon requesting adminship. (For whatever their personal reasons are.)
• Individual admins may decide to not want the blocker tools, and could request them removed.
• Arbcom would have the option of removing the blocker tools from an otherwise trustworthy contributor.

This is just about providing options.

As someone said above, Let's free the wikignomes. - jc37 09:39, 13 October 2008 (UTC)

• Totally agree. Giving arbcom the option to implement this sort of a remedy is sufficient reason to implement this proposal. Even if they don't use such a remedy very often, there's no reason whatsoever not to give Arbcom the option. --Alecmconroy (talk) 11:21, 13 October 2008 (UTC)

• Removing just blocking abilities in case of an issue could very well be a better solution than a total de-sysoping, depending on the situation. I'm all for trying it out. -- Ned Scott 04:21, 23 October 2008 (UTC)

Focusing the mind - Discussion of "what's more 'dangerous'"

So, I see poor JC37 getting a might frazzled here-- let's try this approach.

Consider the tool to change a page from unprotected to semi-protected. This is a tool that has very little potential for damaging the encyclopedia. Whether the change is justified or unjustified, it is temporary, easily reversed, and will not affect 99% of our editors.

On the other hand, consider the power to edit protected pages and templates. This is a very dangerous tool that, in the wrong hands, could result in widespread vandalism all across the project.

Now surely the level of trust we must to have in someone to let them semi-protect a page isn't the same level of trust we must have in someone to let them edit protected templates.

Right? --Alecmconroy (talk) 07:50, 12 October 2008 (UTC)

Except that this approach gets sidetracked into personal preference about what tools people think are "more powerful"/ "more dangerous" than others.

And as far as this proposal is concerned: It doesn't matter.

The powers-that-be've made it fairly clear that they really don't want to completely unbundle admin package. (For various reasons, which are beyond the scope of this discussion.)

And over the last few months there have been a lot of proposals concerning the RfA process, and with allowing this tool or that to be given out to non-admins.

There's also been several proposals for a "minor"/"trial"/"provisional" admin.

These all obviously didn't attain community support. (Even with a lot of commenters, in some cases.)

So instead, I looked at this in reverse. What's everyone trying to do?

Assuage their concerns (especially those who feel that they are the "have-nots", and/or who feel that they would never be able to attain adminship), and at the same time, reduce the contention at RfA, while simultaneously finding a way for us to have more admins helping out with content and the backlogs. That this has quite a few other possible benefits (like dealing with abuse), was just gravy, in my mind.

I've been of the opinion that the blocking tools should be separate from adminship for several years now, simply due to constant reading of several noticeboards and various situations of WP:DR.

However, my understanding was that it wasn't as "easy" to implement in the software as I presume that it is now.

Hence the proposal.

Here on the Project, nothing would change. People would still go through RfA, current admins would still be able to block.

However, we'd have options.

If someone wanted to be a candidate but didn't want the blocking tools (and whatever they felt went along with that, either through contention at RfA, or in merely being granted them, or whatever), then they would have that option.

If arbcom felt that someone should have their ability to block suspended or removed, but not other user-rights, then they would have that option.

If current admins felt that they would be more comfortable editing with out the blocking tools, but still wanted to retain the content-related tools, then they would have that option.

This is only about providing options. It's not about "taking away". - jc37 08:33, 12 October 2008 (UTC)

I think there is something valid at the core of this. The issue of blocking can become extremely contentious when it involves established users. It can devour huge amounts of time and energy of an admin, something which does not occur in the same way with, for example, WP:DRV. This kind of aggro is very offputting to some users, who would otherwise be very helpful in using tools for article-related work. It's not a question of either "trust them with all the tools, or if they're not sufficiently trustworthy they shouldn't get any tools." There are trustworthy editors that wouldn't want to be lumbered with all the tools. For those editors, applying for, let us call it "content admin" tools could be an attractive option, giving them a bundle of protect/delete and whatever else was relevant, but it would be clear they were not in a position to get involved in those difficult editorial disputes, which could involve blocks. They would still of course have to be trusted and go through the same RfA process, but making it clear what they were applying for. As to the process to gain the rest of the tools at a later date, if they so wished, that is something that can be worked out and shouldn't fog the initial discussion. Ty 09:41, 12 October 2008 (UTC)

You also raise another interesting issue-- blocking ip users for simple vandalism and blocking established users for, say, personal attacks-- those two actions so different that they really don't deserve to both be lumped under the generic name of "blocking". I would trust almost any established user with a history of vandal-fighting to have a shot at using the tools to do simple vandalism blocks of anonymous users; But mediating and refereeing between between established users requires more than just basic trust, it requires substantial skill, delicacy, and steadiness of temperament. They're two totally different job descriptions, with two totally different skill-sets. --Alecmconroy (talk) 10:01, 12 October 2008 (UTC)

I don't tend to see blocking as especially contentious. Bad blocks are usually quickly overturned and unlikely to happen too often before dispute resolution is introduced. I tend to view the ability to semi-protect as on a par with blocking. If the right was handed out liberally the whole encyclopaedia would be indefinitely semi-protected within a very short time. Protection, and the ability to edit protected pages, take experience to do properly, without locking out valuable unregistered editors. The ability to distinguish a content dispute from vandalism, edit-warring from wikification, to judge the balance of positive to negative edits, to know when an edit has consensus or not, a user has expended all their unblock requests, or whether a title is so implausible that it needs salting, all involve the same judgment as blocking and are just as likely if not more to drive away new editors. I accept the ability to edit protected pages, especially templates, would be a useful right to dispense to trusted editors, but I don't see why this can't go through a RfA. -- zzuuzz ^(talk) 14:10, 12 October 2008 (UTC)

Before I respond, would you be willing to please do me a favour and (re-)read the proposal and the thread following it? - jc37 14:18, 12 October 2008 (UTC)

I've been following the discussions with great interest. There seems to be too many issues for me to address individually, so I thought I would address the false premise starting this section. Semi-protection is a block of all non-autoconfirmed editors and a huge deterrence to editing. It can be as harmful as blocking. I suggest, as others have indicated, that if a user has the nouse to semi-protect then they have the nouse for the rest of it. It's part of what makes adminship no big deal. Additionally admins must often make a decision between blocking, protection, and deletion, and sometimes must use all three at once. If you don't have all the tools available you won't make the best choice. If someone can only block all non-autoconfirmed editors instead of individual vandals then they will do just that. -- zzuuzz ^(talk) 15:51, 12 October 2008 (UTC)

"If you don't have all the tools available you won't make the best choice." - I might suggest that there usually isn't a "best choice" : )

Also, I would guess that free use of checkuser would make sveral types of situations easier from an admin standpoint (though not necessarily better...). So I dunno if I agree with your premise.

But all that aside, you seem to be talking about WP:DR, with the presumption that suddenly our 1500+ admins (roughly around 1K active) would suddenly not have the ability to block. And so suddenly people would scavenge for whatever other tool might "do the job".

Except that it's very likely that those who might want the option to not have the tools to block, would likely be opting so because they wish to avoid dealing in WP:DR. (And of course, page protection is fairly easy to undo as well.)

And as another aside, editors don't seem to have issues with how long a page protection log is. But on the converse, they do tend to have issues with how long a user's block log is. - jc37 16:04, 12 October 2008 (UTC)

Yep-- lots of gray all around. But blocking established users is tricky. Semi-protection is not. Anyone who we trust to identify simple vandalism should be capable of bestowing semi-protection. I dare-say, aside from the "identify whether a given edit is simple vandalism" aspect, we probably could take The Rough Guide to Semi-Protection and translate it into a bot of less than ten lines of code that could decide whether semi-protection is warranted. I think there are a HUGE population of users who are not currently admins who are capable of performing this task, but have no desire to have other admin tools.

And ya know-- if you don't think there are any such people, you can just !vote oppose on each and every Request for Semi-Protect rights. And if after three months we find there isn't anyone who we trust with semi-protect except for the admins, then we can discontinue the whole experiment.

And more than that-- if we liberally grant the right, we can liberally take it away, no questions asked, after the first oops. If you used the tool incorrectly, no biggie-- we're not going to tar and feather you, we'll just take the tool away and ask you to focus on other stuff.

A _much_ better system for your average gnome than the stressful "running the gauntlet" that is a full RFA. --Alecmconroy (talk) 15:42, 12 October 2008 (UTC)

Semi-protection can be tricky. Even in the "rough guide" there's about 15 different things to take into consideration, almost all of them subjective observations. A bot would have to be able to determine whether or not an edit is vandalism, so it would have to be at least as complicated as ClueBot. Blocking established users is not always tricky. If a user edit wars, they can be blocked, not that tricky as long as its clearly an edit war. If a user calls another user a "complete fucking retard," block them. Yes, there's probably plenty of users who would be competent at semi-protection, however, we have no pressing need for more people to do just that, WP:RFPP requests are handled in a timely manner by current admins. Personally I see the "no desire to have other admin tools" as pretty selfish reasoning. "I could help the project more, but I don't really want the ability to delete things, so I won't bother." Or its just a polite way of saying "I'm almost certain that the community doesn't trust me enough."

"you can just !vote oppose on each and every Request for Semi-Protect rights" - Yes, let's encourage people to do things that would be considered disruption almost everywhere else on the project; that makes for a pleasant editing environment.

"take it away, no questions asked, after the first oops" - What? Low tolerance for abuse is one thing, but why on earth would we want a zero tolerance policy for simple mistakes?

"the stressful "running the gauntlet" that is a full RFA" - RFA is only stressful for controversial candidates and people that make too big a deal out of the thing. Not everyone gets asked a dozen questions and has to deal with a dozen opposers. Mr.Z-man 17:50, 12 October 2008 (UTC)

The block/unblock permission is not the most dangerous permission in the 'sysop' package. For reasons I won't discuss (e-mail me if you're curious), there is another permission available without Foundation approval that has the capacity to cause almost irreperable damage to the site. If I had any doubt about an admin candidate's trustworthiness, or if their judgement was called into enough question to suggest withdrawing certain permissions, blocking is not the ability I would remove. While I sympathise with the idea of the OP, trying to separate the 'Big Three' of block, delete and protect, is unlikely ever to gain much traction. They are all awesomely powerful in their own way if used improperly; it is simply not possible to say that one is less or more dangerous than the rest. I would fully endorse splitting up the 'sysop' package to allocate more of the genuinely minimal rights in a more open and accessible fashion, but the Big Three must remain together, and loss of trust in one must necessitate a loss of trust in all. Happy‑melon 18:04, 13 October 2008 (UTC)

Just to clarify, I'm presuming most of your response is due to the discussion immediately above concerning what some editors consider "more dangerous" than others.

I don't consider blocking to be "more dangerous", either. The more often contentious, however? Yes.

See, I don't see them as "the big three". I think that's just an arbitrary semantic "box" they are placed in simply because someone in the past grouped those and other user-rights together.

And personally, I'm not interested in splitting up the admin user-rights package for disbursement to non-admins.

I'm interested in more adaptability for admins in which rights they may feel confortable with, and what rights the community may (or may not) feel confortable with an admin having.

But I do understand that that distinction has been somehow lost in this discussion.

Do you at least understand the distinction I'm proposing? - jc37 22:54, 13 October 2008 (UTC)

Indeed I do, and I applaud you for continuing to describe it time and again, as there do seem to be a lot of people above who don't. My point is that there is no situation where I would trust an admin with two of the 'Big Three' permissions but not the third. "Contention" shouldn't be the issue - removal of permissions is only considered where there is a clear case that the admin's judgement is flawed - anything that changes that is to be avoided. And without proper judgement, any one of the Big Three has the potential to do both physical and social damage. And I'm not sure how you can claim that the block/protect/delete triad are not permissions with unique power and potential for misuse - I simply don't agree that the distinction is in any way semantic. Almost all the discussions we've ever had about admin permissions takes as a given the fact that there are (at least) two tiers of permissions within the admin bundle; and I've never seen anyone make a convincing case for adding any others to the block/delete/protect group in that top tier. Happy‑melon 00:17, 14 October 2008 (UTC)

A fair opinion.

"My point is that there is no situation where I would trust an admin with two of the 'Big Three' permissions but not the third." - I understand this point. And I understand why it's made, and so on. But that's a comment to make during an RfA. I'm trying to also make clear the distinction that there is a difference between a stet package and a bestowed package.

One thing that this discussion shouldn't be about is a question of "trust". Because "trust" only has to do with when these user-rights are bestowed. It has little to do with how they are packaged in the software.

What does it matter to the RfA "voter" if the user-right package that candidate-x is requesting is grouped in one package or two?

It doesn't.

This whole thing seems to be about perception, and it seems ironic to me that more weight is given to the "perception" of the admin package by others, than to the perception of how the admin package may feel to those bearing it.

These are social constructs, assuredly.

So everyone seems to understand their own wants as far as comfort, but no one is interested in what someone else might want as far as comfort? Especially when that "comfort" involves less access/responsibility rather than more? Isn't this a volunteer project?

Why should we force individuals to accept everything, when they may only wish a few?

If we choose to trust them as admins, doesn't that mean we choose to trust their discernment?

And if they discern that this (having the blocking tools), would be more difficult rather than easier for them, shouldn't we respect that?

So far, the arguements seem to involve either something not proposed, or some personal want to force another individual to accept extra burdens because we refuse to allow them to receive what they feel comfortable with (less of a burden), merely to suit ourselves.

Does this seem inappropriate to anyone else but me? - jc37 04:20, 14 October 2008 (UTC)

That doesn't seem to be the line you take earlier in this discussion. As best I can see, the original proposal was for the rights to be separated so that it was possible for 'due process' (read ArbCom) to 'partially desysop' someone who had lost the faith of the community to block, but not to do other admin tasks. I argue that that situation should never occur, or rather, it should never be possible for it to be desirable to remove one of the block/delete/protect permissions but not the others. The thought of splitting them up so as to allow RfA candidates to choose a 'half-adminship', with the implication that it would be easier (like taking a driving test only for an automatic car), is an entirely separate issue. I would argue that the same reasoning applies in the granting of the permissions as in withdrawing them: the end result is the same. The one point I can least accept is that "this discussion shouldn't be about... a question of trust". Admin permissions are all about trust, indeed there is (or certainly should be) no other consideration. Indeed the whole permissions system, from autoconfirmed right up to steward, is based on trust; the hundred-odd permissions we have avilable are placed on a loose scale reflecting the level of trust we require from the people to whom we grant those permissions. For convenience we group the permissions into blocks and assign them en masse. I will be the first to support the statement that the 'sysop' block contains too many permissions and hence obtaining it is an unnecessarily huge undertaking, which flies in the face of the "no big deal" philosophy. But even if you split up the block/protect/delete permission on a technical level, there would be no benefit. The level of trust required to deserve any one of the Big Three is the same required for all of them, so anyone who earns one earns all three, and anyone who loses one must lose the other two. As for the "comfort" of candidates who do not intend to use all the tools in the sysop package, I don't think that that's an issue in the slightest. Take a look at my block log - admins who don't work in an area simply don't use the tools. That's no reason for them not to have them. All editors should have access to every tool that they can be trusted with, surely that's the essence of "no big deal". Implying that RfAs or desysoppings will be easier if there are 'half way houses' flies in the face of that philosophy. It's not about the tools or how they're used, abused or not used. It's about the judgement of the person with the tools and whether the community has trust in that person to keep on using them. By all means break up the 'sysop' package, but break it along lines of trust, not along lines of convenience. Happy‑melon 22:12, 14 October 2008 (UTC)

• "That doesn't seem to be the line you take earlier in this discussion." - Please re-read the original proposal. It's always been about several options and potential "benefits". You (among others) just seem hung-up on one of them.
• "The one point I can least accept is that "this discussion shouldn't be about... a question of trust"." - Did you read the very next sentence? This discussion should be discussing the proposal (I presume), and the proposal isn't about the bestowal/removal of the user-rights. It's about the packaging of the user-rights, and how that can provide for other options. So this discussion should have nothing to do with questions of "trust".

It seems to me in your comments, that you are "hung-up" on fear. You're apparently not opposing this proposal, you're opposing potential applications which may or may not follow this proposal.

So really, am I just looking at a page filled with unsubstatiated, irrational fear? WHy irrational? Because none of the options that such a change to the software could be implemented without community support.

A developer could make this change now, and there would be absolutely zero effect on the community (except that in the event of a successful RfA, bureaucrats would have to add two smaller packages instead of on big one).

• '"By all means break up the 'sysop' package, but break it along lines of trust, not along lines of convenience." - False analogy. Because the "convenience" would still have the presumption of trust.

Again, you make the presupposition that just because you (and/or others) have in the past grouped such tools together they must be grouped together. And then you get wrapped up into questions of what tools should be trusted with what tools.

Everyone's so hung up on what they want to give (force others to take), simply due to their own convenience (and preference), that they aren't allowing for what the target of this bestowal may wish to receive.

As I've noted above, while Wikipedia is an encyclopedia, there is a social dynamic to editing at Wikipedia. There is a Wikipedian community of editors. And having certain tools can impact how editors interact. And there are those editors who would find certain tools useful, and would be happy to contribute while using those tools, but perhaps aren't interested in other tools. Why should we force them to accept unwanted tools? If we trust them to help, let them help. Why make the presumption that every admin must be involved in WP:DR? Why can't there be editors that merely are "janitors"? (Rather than bouncers, or whatever anaologous term one might wish to use for the ability to block. An over-night janitor may "double" as a night watchman, but that doesn't mean that every janitor should be required to take on the responsibilities of a "watchman". - jc37 14:05, 16 October 2008 (UTC)

Multiple meanings of trust

It seems like there's a couple different types of "trust" floating around that are often getting conflated. One version is "trust not to be malicious"-- when a user has been around for a certain amount of time, kept their nose clean, invested some serious time in the project, and generally seemed to have the right temperament, I "trust them not to be malicious", and I'd be willing to give them any tools that could help the encyclopedia but could be misused by a malicious user to the detriment of the encyclopedia.

But, there's a whole other different sort of trust that's a higher level of trust, above and beyond the "trust not to be malicious". Before I'd be willing to give someone blocking ability, it's not sufficient just for me to "trust them not to be malicious". I would only support giving the power to block established users to someone who I "trust to have excellent judgment about complex matters". Being good-faith is not enough to be an admin-- you have to actually be good at using the tools.

Because we've just been using the word "trust", we've conflated these two meanings, and that's what's getting lost in these discussions of relative dangerousness of tools. We consider what the tools could do in malicious hands and recognize, correctly, that all are quite dangerous. But what's missing is that all the tools are NOT of equal difficulty.

There's a very large, large population of users who I "trust not to be malicious". There's a lot of people I trust to use the "semi-protect a page" or "block an ip editor" power. There's a much smaller population that I "trust to be good at using the 'block established editor' power". I may trust all of the editors to try their best-- but for some people, for the complex tools, their best just won't be good enough.

It would be nice, someday, if we could recognize the distinction. If someone, without having been malicious, nonetheless proves unable to use a particular tool, it would be nice if arbcom could let them still keep the tools they HAVE been able to successfully use-- rather than face an all-or-nothing choice. --Alecmconroy (talk) 11:30, 14 October 2008 (UTC)

More like the rollbacker system instead

Why don't we do it more like the current rollbacker system?

I took a look at the list over at Special:ListGroupRights, and that is a lot of things that an admin can do. Just cutting out the blocking still leaves so much that we still must have the RfA process for those users.

So I suggest doing it the other way around. If say 4 admins marked a user as trusted that user would be able to do some semi-risk tasks. And I think that it should be enough that one admin marks the user as not trusted to remove the tools from the user.

Let's identify some tasks that are fairly low risk:

• Do rollback.
• Perhaps apply and remove semi-protection to pages. (But the user should not be able to apply and remove full-protection.)
• Edit most protected pages. I think editing most protected pages isn't that high-risk. (Especially if MediaWiki space and the main page was not included. It would be nice if we had a special protection level for really high-risk things like the main page.)
• And perhaps some other semi-risk task.

This would mean that no RfA process would be needed for those users. Thus much less bureaucratic.

--David Göthberg (talk) 14:01, 12 October 2008 (UTC)

Looking over the list, another really basic right I see is "Have one's own edits automatically marked as patrolled (autopatrol)". This was proposed on the village pump last February, seemed to have interest, but kinda fizzled from status-quo-inertia. --Alecmconroy (talk) 15:28, 12 October 2008 (UTC)

Four admins does not equal community trust. We already have accusations of cabals, IRC, etc., this would lead to a ton of drama. KnightLago (talk) 16:19, 12 October 2008 (UTC)

It might be better if no new pages were autopatrolled. There are a significant minority of admins write articles once a year, or thereabouts. Why should their work not have to be reviewed like everyone else's? Best if we're all as equal as possible. Angus McLellan (Talk) 22:15, 12 October 2008 (UTC)

I think that autopatrol is really intended as an enhancement for the work done by the Recent Changes Patrol, not for new articles. As best I understand, patrolled edits haven't been implemented on the English Wikipedia. -- John Broughton (♫♫) 15:07, 16 October 2008 (UTC)

We use the patrolled edits feature on NewPages. Mr.Z-man 16:20, 16 October 2008 (UTC)

KnightLago: Well, I think we miss a human performed check above the autoconfirmed level. It should merely be a check that the user is a good editor that knows how things work around here and not is a vandal and so on. Then that user can be trusted with more tasks, that is some semi-risk tasks. And who should perform that check and grant that next level? Well, it probably has to be the admins that do that. So I hope it won't be seen as a "cabal thing" and that it should be possible to grant this next level to lots of editors. It should perhaps be considered a routine thing that after some months and a certain number of edits one puts oneself up on a list to be checked and granted the semi-risk level. And we already have that, that is the rollbacker level. I just suggest extending that.

Angus McLellan: I agree, autopatrol is silly. I am an admin and I expect and hope that people double check the things I do. When I do something new I usually announce it at some related talk pages so people who know the area can take a look. I mean, we all do mistakes every now and then, and even if there isn't a "mistake" there are always improvements to do. (I rather have my embarrassing mistakes fixed quickly than have them lingering around for a long time...) So I think the autopatrolled feature should be removed from all groups. Of course, I might be wrong about this, since the patrolled feature is used as a way to save work for the new page patrollers. And they perhaps don't want to see the edits done by trusted users.

--David Göthberg (talk) 00:51, 13 October 2008 (UTC)

Note that the software currently doesn't support such fine-grained control over protection (certain groups can only assign certain levels). Anyone with the "protect" right can protect to any level. If there is a consensus for this, it probably couldn't be implemented immediately. Mr.Z-man 05:47, 13 October 2008 (UTC)

"Log" for Newbies

Is there a way for there to be a Special:Log/newbies like there is a [1]? It would be quite useful for tracking new things going on; blocks on newbies, moves (does "Grawp" ring a bell?), etc. Thanks, ~ Troy (talk) 02:06, 21 October 2008 (UTC)

At which point are they considered "established"? If it's when they become autoconfirmed, the moves will not show up in the log, because only autoconfirmed users can move pages. Further, the log may get flooded with blocks on vandal-only accounts, which is the most common type of block on new accounts. It's just something I'm suggesting as I never knew that link existed. :) PeterSymonds (talk) 12:08, 21 October 2008 (UTC)

I also didn't know that [2] existed until a few days ago. As far as a log for newbies, I agree that it would be difficult to keep track of who is a "newbie" and who is "established". What about just making a log for all moves? I wouldn't think that there's a large volume of moves, and that would be a good method of fighting Grawp. -- Imperator3733 (talk) 16:39, 21 October 2008 (UTC)

We could call it the Move log. Algebraist 16:41, 21 October 2008 (UTC)

There is. DendodgeTalk^Contribs 16:42, 21 October 2008 (UTC)

Okay, I was wondering if there was already something like that. -- Imperator3733 (talk) 18:52, 21 October 2008 (UTC)

The "newbies" contribs shows the edits by the newest 1% of users, so for us, that's the most recent 472748 users. A log of blocks on newbies wouldn't work as blocks are done by admins on users just like a pagemove is done by a user on a page. Based on the number of new accounts between 21:00 and 21:59 today (UTC), we get about 400 new accounts per hour, so 81,000 accounts represents about 8.5 days of accounts. So about half of them would be old enough to (if they also have 10 edits) move pages, upload files, or mark pages as patrolled (the 3 logged actions restricted to autoconfirmed accounts). An aggregated log would have to filter out account creation though, as almost all account creations would be included. Logs entries are stored in the database by userid though, so it might be possible to build this into the software like newbies contribs. Mr.Z-man 23:01, 21 October 2008 (UTC)

If it is, I'd suggest going ahead with testing it out, because it would be quite useful. While I had Grawp in mind, mostly, some new users goof around as well and can't be trusted as easily. I'm not saying we should "WP:BITE" them, but if there's a reason to look at their contribs, there should be a reason to view new autoconfirmed user moves. ~ Troy (talk) 04:36, 22 October 2008 (UTC)

Most moves are done by experienced editors, or bots, and the vast majority are correct or at least very well-intentioned. So looking through the standard move log for vandalism is almost pointless; a newbie move log could therefore be quite useful. -- John Broughton (♫♫) 23:41, 24 October 2008 (UTC)

Bot proposal: remove autoformatted dates and leave solitary years alone

There is a bot proposal to remove autoformatted dates and leave solitary years alone. Please see Wikipedia:Bots/Requests for approval/Cleanbot. Regards Lightmouse (talk) 13:19, 21 October 2008 (UTC)

Discussion has closed; the bot request was denied. -- John Broughton (♫♫) 23:33, 24 October 2008 (UTC)

Making lists and category of languages easier to navigate

One of the most impressive thing about Wikipedia is how many language editions there are of it, as listed on List of Wikipedias by language, and also at Category: Wikipedias by language. There are, according to the the Wikipedia article, 262 languages in which one can read Wikipedia. I am in favour of keeping the list as it is; but could the category be organised more hierarchically, so that is grouped more hierarchically? At the university where I teach, students seem, in general to find the university's intranet easier to navigate if icons are arranged in folders. In the same way, would the category be better organized if we had, say, separate categories to list, for example, African language Wikipedias, South-East Asian language Wikipedias, American language Wikipedieas, European language Wikipedias and so on and so forth? ACEOREVIVED (talk) 19:44, 23 October 2008 (UTC)

No. A reader is most likely going to be interested in whether Wikipedia is available in a second language that the reader also has some fluency in; the easiest way to find out is to look alphabetically. That avoids having to know where the boundary between Europe and Asia is drawn, for example. Also, note that a language is not the same as a country, so it doesn't follow that geographical organization is optimal (for example, is English a European language (UK) or a North American one? What about Spanish (I'd guess that more people in South America speak Spanish than do people in Spain)? -- John Broughton (♫♫) 23:44, 23 October 2008 (UTC)

Thank you John, although my proposal above was only a suggestion that we categorise, not necessarily that we categorise according to countries -we could, for example, have a category "Indo-European languages" and then a category "Semitic languages" and then a category, say, "Austronesian languages". Just a suggestion. ACEOREVIVED (talk) 20:31, 24 October 2008 (UTC)

To be perhaps more constructive, since the list is in the form of a table, there isn't anything preventing someone from adding a column to that table, so that reader can sort the table by language family, or whatever. -- John Broughton (♫♫) 23:28, 24 October 2008 (UTC)

requesting to reactivate 2 WikiProjects (call for volunteers)

Request to restart inactive WikiProject General Audience

I would like some editors who have a better mathematics education than I, and perhaps some professional scientists (if they have the time, which I realize they don't) to please consider re-activating WikiProject General Audience. 69.140.152.55 (talk) 01:49, 28 June 2008 (UTC)

---

Relisted to generate a more thorough discussion so that consensus may be reached.
Please add new comments below this notice. Thanks, 69.140.152.55 (talk) 23:09, 24 October 2008 (UTC)

Request to restart inactive WikiProject Elections and Referenda

Please see discussion here. 69.140.152.55 (talk) 23:09, 24 October 2008 (UTC)

Radical new idea [bias towards humans]

Alright, so I haven't gotten annoying on Wikipedia on years, but I've noticed something and a lot of other users are getting bugged about it, too. It's the whole "humans rule the world" idea. No, bugs do. Or maybe algae... Anyway, it has to do with articles being mostly focused on humans. This, of course, is biased. Articles, such as "life expectancy" are focused on humans. No! The focus needs to be taken away from humans. At best, the article should be downsized and humans should be a subsection or another article in itself. What am I trying to say here? Articles are biased because they refer more to humans than other species. --Cyberman (talk) 05:23, 17 October 2008 (UTC)

Take it up with Bugzilla. ;) Durova^Charge! 08:15, 17 October 2008 (UTC)

Sounds like a WP:CSB issue. --Pwnage8 (talk) 12:30, 17 October 2008 (UTC)

Let's just nominate humans for deletion --Ron Ritzman (talk) 13:28, 17 October 2008 (UTC)

LOL!!! That was the funniest thing I've ever read on Wikipedia. All the speed delete comments... that was hilarious.EconomistBR 04:57, 18 October 2008 (UTC)

I agree with Cyberman in a general way, but I think it should be noted that when readers come here, they will most likely be looking for information on humans and that most editors are human and thinking in human terms when they make additions. Wikipedia's anthropocentrism can be dealt with gradually with the addition of information about non-humans. No reason to panic about it. Abyssal (talk) 18:06, 17 October 2008 (UTC)

Well, if bacteria gave a hoot, they could totally rule the wiki by consensus. If they brought even a fraction of their numbers to bear, they could totally re-edit a lot of articles to get rid of the higher-vertebrate bias, real fast. But I see that category:Prokaryote users is totally empty, so I guess they just don't give a flying fuck about unicellular rights. —Michael Z. 2008-10-18 05:57 z

Ah, I'd been looking for that category. Pseudomonas_(talk) 09:40, 19 October 2008 (UTC)

I think this is getting a little out of hand without realising why we don't want systemic bias... — Werdna • talk 22:47, 20 October 2008 (UTC)

Once again, opposable thumbs (and minimal typing skills) trump sheer population numbers. Her Pegship (tis herself) 04:55, 21 October 2008 (UTC)

I think I know where cyberman is coming from. How about a template on pages like Life expectancy that says something like "this page discusses human life expectancy. For a wider perspective, see Life expectancy (animal), Life expectancy (plant)". Just my 2c. Robinh 12:03, 21 October 2008 (UTC)

I kinda like Robinh's 2cs. Can I have them? Anthropocentrism is biased, goes against NPOV... and is bad, big bad, bad in a big way. Let's really do something about it. Aditya^{(talk • contribs)} 10:21, 23 October 2008 (UTC)

What's systemic bias got to do with presenting a neutral point of view, Aditya? The reason we try to avoid systemic bias is because we want our articles to be useful to anyone who reads them. We don't want people in Australia reading an article on Supreme Courts without some reference to courts other than the US Supreme Court.

Systemic bias is conveniently a non-issue in terms of "anthropocentrism", because we don't have very many non-human readers... — Werdna • talk 10:20, 25 October 2008 (UTC)

Wikipedia:Guide to image deletion

• Wikipedia:Guide to image deletion

I brought this up at WP:VPP yesterday (and have so far received no responses), but it occurred to me that I probably listed it in the wrong place, since it is not a policy proposal but a "how to" guide, like the others in the category. I'm hoping to be able to officially launch this soon.

This guide has been under development since October 1st and publicized since that time at various appropriate forums, including VP. It has been publicized at Wikipedia talk:Images and media for deletion, Wikipedia talk:Image use policy, and WT:CSD. It is currently linked at Wikipedia:Deletion policy#Processes, Wikipedia:Guide to deletion, Wikipedia:Deletion guidelines for administrators#See also and Wikipedia:Image use policy#Deleting images. It has also since October 2nd been listed at RfC, here. I think it has received sufficiently widespread exposure, and so far all feedback has been essentially positive. (One fellow, here, objected to actual deletion policy, but as this document is only a compendium of deletion practice, I pointed him to the appropriate forum to discuss his concerns.) Discussion has primarily centered around specifics of wording; there seems to be general consensus that the compendium is useful. Any further feedback or guidance in launching this would be helpful and greatly appreciated...right down to some guidance on at what point "proposed" is removed. :) --Moonriddengirl ^(talk) 12:04, 24 October 2008 (UTC)

I've gone ahead and labeled it as a how-to guide; I've also added it to the editor's index. -- John Broughton (♫♫) 16:16, 25 October 2008 (UTC)

Thank you. --Moonriddengirl ^(talk) 16:18, 25 October 2008 (UTC)

Proposal to clarify the description of WP:Babel levels

See Wikipedia talk:Babel/Levels#Should the descriptions be made clearer? -- Army1987 (t — c) 12:35, 25 October 2008 (UTC)

Category:All articles lacking sources

It is impossible to go through this list[3]. It needs a contents section that allows you to click a letter or number such as on List of biochemistry topics 89.204.247.134 (talk) 13:40, 25 October 2008 (UTC)

 Done —Ms2ger (talk) 17:26, 25 October 2008 (UTC)

A single and standardized maintenance/contribution page

It is my belief that there are far too many pages dedicated to encouraging and educating people on how to maintain and contribute to Wikipedia. The number of pages on this subject causes disorganization. Between Wikipedia:Contribute, Wikipedia:Community portal/Opentask, Category:Wikipedia maintenance, and Template:Resources for collaboration, in which many of the pages repeat each other, I think the information should be synthesized and combined into one page. Voyaging^(talk) 18:01, 25 October 2008 (UTC)

Change/split Primarysources template?

I have been thinking that the wording of the current Primarysources template misses a key aspect of how primary sources might be used problematically. An article can misuse, overuse, or overemphasize primary sources even if it also references plenty of independent ones. I have raised the issue at the template's talk page, but that doesn't seem to get much activity. PSWG1920 (talk) 22:51, 25 October 2008 (UTC)

Addition to the cursor in wikimapia.

While I understand this might not add to everyone's use, I would find it useful to have the option to have a cursor as crossed vertical and horizontal lines (lengths of 1/4 inch to full screen at my selection) with the lat & Lon numbers in either deg. min. sec. or dec. deg. attached to the vert and hor lines and at a distance to leave the intersection clear to view. This should be an option a user could select, among others, just so the average user should no be too annoyed with Me. Art—Preceding unsigned comment added by 24.190.246.208 (talk • contribs)

A wiki is any website using wiki software; there are thousands of them. Wikimapia is inspired by but completely unrelated to Wikipedia and its sister sites run by the Wikimedia Foundation.--Fuhghettaboutit (talk) 07:49, 26 October 2008 (UTC)

Reopening a discussion

I have been trying to find a template to show that a discussion has been reopened. I was pointed to {{relisted}} which in my original case was suitable. But what if it is not to reach a consensus but for a general discussion.

I therfore created afterwards {{reopened}}, which could act as this to generally say that it has been reopened e.g. from an archive, or as an alternative to relisted.

What do people think?

Am i on the right page to discuss this?

Simply south (talk) 19:56, 26 October 2008 (UTC)

I think in most cases outside of structured discussions like XFD, it would be better to just start a new discussion, though WP:STICK may apply in some cases. Mr.Z-man 20:49, 26 October 2008 (UTC)

Require autoconfirmation before allowing uploading

Don't know if this is a technical issue or just a policy one, but I really cannot see a reason why we shouldn't require autoconfirmation before allowing uploads. There really isn't a good reason why someone's first contributions would be uploading images and a large number of images that have problems are because people don't know anything about Wikipedia, let alone something as complex as our image policies. -- Ricky81682 (talk) 22:39, 26 October 2008 (UTC)

Autoconfirmation is already required before uploading files. PrimeHunter (talk) 00:16, 27 October 2008 (UTC)

Stylistic differences

When searching for something, and the text field brings up suggestions, some of those suggestions are the same except for capitalization, but some of those redirect to others of those; for example, type enough of "Albert Einsten" and it suggests "Albert einstein" [sic], which is nothing more than a redirect to the first of the two; how about eliminating these redirects from the suggestion field? OneWeirdDude (talk) 02:54, 26 October 2008 (UTC)

Indeed, these redirects only exist so that anyone who types them in would be sent to the proper article. But now that the search field narrows down the results as you type, you would select the proper one from the results given to you. It's really frustrating to type something and have five similar titles that are all redirects pop up. It's just clutter. Why not delete them? If all the redirects are bypassed (a lot of them are), they are completely useless. --Pwnage8 (talk) 03:05, 26 October 2008 (UTC)

I would also like the redirects to not show up in the suggestion field. They do get quite annoying. -- Imperator3733 (talk) 06:30, 26 October 2008 (UTC)

I submitted a bug report Foxy Loxy ^Pounce! 12:13, 27 October 2008 (UTC)

Creating discussion pages

When you click on a red discussion tab, I think you should be taken to the new section window (i.e. with a heading box; as if you'd pressed +) instead of just the normal edit window (as if you'd pressed edit). It would just help new users in creating new discussion pages in case they were not sure how many = signs they needed. It Is Me Here (talk) 18:17, 26 October 2008 (UTC)

• Oppose. I usually create discussion pages to insert wikiproject tags for the new articles. No need for headings there. Also: new users learn quickly :)) NVO (talk) 19:10, 26 October 2008 (UTC)
  • Hmm, how about if it were made toggleable in your Preferences? I.e. the default would be set to a new section view for new users, but veterans could change back to a normal edit view as before (as with the + vs. new section thing). It Is Me Here (talk) 13:24, 27 October 2008 (UTC)
    • There is a script, already: Wikipedia:WikiProject User scripts/Scripts/Talk page section tabs. I do agree that this could be useful as an option - I usually am adding a WikiProject template to a brand new article discussion page, and so wouldn't want this to be a default that I couldn't change within my preferences. -- John Broughton (♫♫) 14:28, 27 October 2008 (UTC)
      • Ooh, nice link - added to .js. But still, I feel that the new section option is more geared towards new users who want to discuss features of articles and bring points up, and the existing default of an edit window seems more geared towards experienced editors who do things such as WikiProject tagging. Thus, the current situation should be reversed, in that the default should be a new section window with the option for experienced editors to change to an edit window if they want. It Is Me Here (talk) 14:40, 27 October 2008 (UTC)
      • I would support adding this as a preference and making this the default only for new user accounts. It should be relatively easy to change - the only difference is the &section=new in the "new section" url. This would add to the list of preferences, but it's important that experienced editors not be affected by this change. We also shouldn't rely on JavaScript hacks, especially to provide something for new users. -- 141.224.68.9 (talk) 14:41, 27 October 2008 (UTC)
        • Sorry, I'm at work and forgot to log in. The above post was mine. -- Imperator3733 (talk) 14:43, 27 October 2008 (UTC)

Getting some subset of Wikipedia Users access to databases like JSTOR, LexisNexis, etc

The following just occurred to me--

Is there any way we could get some small minority of the Wikipedia community to have access to the sorts of databases any typical university would have-- things like JSTOR and Fulltext Science Journals, etc?

I have no clue how much such things cost, except to note that the cost is small enough that most university libraries are capable of providing it for all students.

I think it would be very useful to the project, in creating new articles on the latest in science, if we could provide that kind of access to some small sliver of the project-- either the foundation paying, or getting some large university library system to let us "piggyback" by them donating the access to the project.

Any thoughts on whether this might theoretically be feasible, and if so, how it could come to pass? --Alecmconroy (talk) 06:55, 27 October 2008 (UTC)

We already have plenty of wikipedians with access to this sort of stuff. See Wikipedia:WikiProject Resource Exchange. Algebraist 09:23, 27 October 2008 (UTC)

Lots of Wikipedians already have institutional access to these kinds of resources. Why don't you just ask one of them instead? Celarnor ^{Talk to me} 16:11, 27 October 2008 (UTC)

I've only ever NOT had access for a couple of years of my adult life. Ask your public library system(s) if they provide it, and how to get ahold of it. They've been my primary enabler. It is often possible to obtain membership in collegiate and university libraries at a cheaper rate than membership in the news aggregators above, and they are even more likely to provide access - Just be sure they tie it to a library membership and not enrollment. MrZaius^talk 01:06, 28 October 2008 (UTC)

See Category:Wikipedians_by_access_to_a_digital_library and its subcategories. It's not much yet, but with time more resources can be added there. — Carl (CBM · talk) 01:21, 28 October 2008 (UTC)

Categories at the bottom - Dots instead of "|"s

This is a proposal for an interface change in relation to categories as seen at the bottom of each page. I don't know if this is the right place for this, and if not redirection would be appreciated.

I would like to see dots such as "•" or similar to replace the "|" that seperates the categories, for aesthetics reasons. It is much easier on the eyes, as the wouldn't be any confusion between "1"s, "I"s and so forth. Many templates now use dots instead of |'s.  The Windler talk  09:50, 30 September 2008 (UTC)

A very good idea! --Kildor (talk) 10:20, 30 September 2008 (UTC)

This is a good idea, but it might be part of the software, in which case we would need to get the devs to make the change. I'm not sure if they would do that. -- Imperator3733 (talk) 16:35, 30 September 2008 (UTC)

I agree. Take this to Bugzilla. Paragon¹²³²¹ 16:38, 30 September 2008 (UTC)

Have a sysop edit MediaWiki:Catseparator. ^demon^{[omg plz]} 16:48, 30 September 2008 (UTC)

Is there a way for an individual to override the page (javascript or whatnot)? It'd be nice if we could choose whatever character we want to distinguish categories. EVula // talk // ☯ // 18:17, 30 September 2008 (UTC)

Can't give it an id, but couldn't you wrap it in a (span) class? --Izno (talk) 01:45, 1 October 2008 (UTC)

There seems to be some support and various suggestions. Which suggestion will get the task done. I don't understand some of the suggestions.  The Windler talk  02:01, 1 October 2008 (UTC)

The | separator is common throughout the software. (Look at the top of Special:Watchlist or the "Recent changes options" at Special:RecentChanges or at Special:Contributions/User.) I see no compelling reason to change it. --MZMcBride (talk) 06:05, 1 October 2008 (UTC)

I don't really mind if their all changed. This is a proposal, not a change. Lets see what others think.  The Windler talk  07:26, 1 October 2008 (UTC)

I don't think it would be bad if only the category separator was changed while the Watchlist and Recent Changes pages remained the same. (Although I wouldn't mind if they were as well) I really like the idea of a dot rather than a pipe. It is only a matter of editing MediaWiki:Catseparator. Scottydude _review 14:32, 1 October 2008 (UTC)

I don't think that is correct. We don't have a MediaWiki:Catseparator which was autodeleted as "No longer required" more than a year ago. Rmhermen (talk) 04:04, 2 October 2008 (UTC)

No, it is correct. MediaWiki:Catseparator was deleted by User:MediaWiki default, with an edit summary that comes from maintenance/deleteDefaultMessages.php. It looks like MediaWiki messages were formerly all created by default during the install, and then that was changed and that script was run to delete messages that had not been changed since the install. Anomie⚔ 11:21, 2 October 2008 (UTC)

So, do I need to go to this Bugzilla place or get an administrator to change this MediaWiki:Catseparator. This is getting a bit confusing. But to me, there seems to be some support.  The Windler talk  11:41, 2 October 2008 (UTC)

Any en.wiki administrator can change the separators in the category display to dots by creating MediaWiki:Catseparator with content other than the default pipe, providing there is a consensus to do so. Changing other pipe separators (eg in the watchlist) is not possible except by asking the developers to assign them a MediaWiki message. Happy‑melon 12:00, 2 October 2008 (UTC)

I'm gonna do it unless someone tells me not to. I hope that gets people's attention. If there is consensus here for the change after seventy-two hours from the timestamp in my signature, someone can drop me a reminder on my talk page and I'll create the appropriate MediaWiki:Catseparator. TenOfAllTrades(talk) 23:36, 2 October 2008 (UTC)

That sounds like a good idea. 72 hours seems like enough time, plus I can't really come up with any reasons that people would have other to not do this. I'll try to remember to remind you :) -- Imperator3733 (talk) 23:44, 2 October 2008 (UTC)

Thanks, it save me. I slightly become confused in the technical aspect. But thanks.  The Windler talk  00:01, 3 October 2008 (U

It is possible to do this via the following user script, without the need to make any global changes:

addOnloadHook( function (){
 var cat_div = document.getElementById('mw-normal-catlinks');
 cat_div.innerHTML = cat_div.innerHTML.replace(/\|/g,'•');
});

- SigmaEpsilon → ΣΕ 01:53, 3 October 2008 (UTC)

WTF??  The Windler talk  03:59, 3 October 2008 (UTC)

SigmaEpsilon is just saying that you can use that script on your monobook page and the pipes ("|") will change to dots but only for you, when you are logged in. I still support the idea of making the change for all viewers. Scottydude _talk 04:35, 3 October 2008 (UTC)

Gah. I see |'s used throughout the software, and I like it that way. Yes, this issue is primarily about personal preference, so please don't quote WP:ILIKEIT to me. I oppose this proposal as given unless I can be convinced that it won't disrupt the consistency of the interface, as other interface elements use pipes (|'s), as MZMcBride notes, and the effective change would only change category separators. Until it becomes a personal preference option, I don't think this should be changed. {{Nihiltres|talk|log}} 04:51, 3 October 2008 (UTC)

As I have said, it dosen't matter to me if the entire interface is changed. I believe however that the only use in the mainspace that most people view is the categories. And as you said, this topic is majorly about personal preference. But why shouldn't we question the personal preference of the developer(s) of the software. Why is their preference correct. I provided my explanation, in my original comment, that the dots are better to avoid confusion as such.  The Windler talk  05:56, 3 October 2008 (UTC)

If you wanted to, I'm sure you could modify the above script to switch the bullets to pipes. I'm sure it would be possible to implement this as a preference, but some people in the past have objected to the large number of preferences. We could always implement the pipe -> bullet change, and if a lot of people object, then we could consider implementing it as a preference. (I actually don't think that many people will notice this change, though, although I could be wrong) -- Imperator3733 (talk) 04:59, 3 October 2008 (UTC)

About consistency of the interface: As far as I can tell, only "internal" pages use the | as a separator. In mainspace, the dot is the more commonly used separator. As example, take a look at the Main Page! --Kildor (talk) 08:34, 3 October 2008 (UTC)

I support the change from pipe to dot, a dot is more ergonomic and also helps site consistency. If somebody wants to keep the pipe for whatever reason, he can use the user script. Cacycle (talk) 15:30, 3 October 2008 (UTC)

By the way, it might by just my computer/the way I did it but I put that code in my monobook and it didn't work. My monobook now consists only of that code above. It had nothing before.  The Windler talk  22:08, 3 October 2008 (UTC)

Either we should keep the pipe as a separator, and provide editors with the option of dots as a gadget, or the reverse - change the separator to be dots, and provide editors with a gadget to change it back to the pipe. We don't need to force absolutely everyone to see exactly the same thing, nor to have to know how to (and be willing to) modify their .js page in order to avoid something they don't like. -- John Broughton (♫♫) 23:41, 3 October 2008 (UTC)

So what happens now????  The Windler talk  02:43, 6 October 2008 (UTC)

I've implemented it but someone may need to check it to see that it's OK, as a bot previously deleted the page I edited (MediaWiki:Catseparator) and pulled the data in from another source. Orderinchaos 05:29, 6 October 2008 (UTC)

It works on this page I believe.  The Windler talk  05:39, 6 October 2008 (UTC)

But it dosen't work when I go out as a IP.  The Windler talk  05:43, 6 October 2008 (UTC)

Sometimes when a change goes out, for reasons relating to database load, it takes a while to percolate through all pages. If it's still doing that in 12 or 24 hours, let us know. Orderinchaos 06:16, 6 October 2008 (UTC)

I oppose this change.

I'm using the Cologne Blue skin. I'm sure large, in-your-face bullet separators are fine if you're using MonoBook. It makes sense for MonoBook users to enable this through monobook.js. However, a global change like this should be compatible with all skins, not just the default. Cologne Blue places categories at the top of the page underneath pipe-separated interwiki links and above the "Printable version | Disclaimers | Privacy policy" row, so this is a dramatic change. Even the top-level navigation ("Main Page | About | Help | FAQ | Special pages | Log out") is pipe-separated in Cologne Blue, so the bullets look conspicuously out-of-place. This mismatched UI is not something we have to scroll down to see: it's the first thing we see at the top of every page.

The new separator is a bullet rather than a middot. Bullets make the whole block of categories pop. That's fine for navigation templates, where the links are used for... well, navigation. But that's not the case with categories, which are much more likely to be navigated to rather than from. Also, the more discreet middots appear to be much more common in navigation boxes than bullets.

Most importantly, this is a broad change that so far has only been discussed by a handful of people. I had to poke around in the HTML before getting lucky with a google search to find this discussion. Soon, even that won't work. If anyone can think of a good place to post a link to this discussion so that more people can contribute, then please shout.

chocolateboy (talk) 13:48, 6 October 2008 (UTC)

I had a look what that skin would look like if all the line separators were replaced with bullets, I think it looks better with bullets: screenshot (ignore the slight blurring caused by Photobucket resizing the image). Surely the best way forward is to simply replace the lines with bullets wherever they appear, I can't see the problem unless people really think that the lines look better… MTC (talk) 14:21, 6 October 2008 (UTC)

They do look pretty good in that shot (though it looks like you're using bold middots rather than bullets).

Surely the best way forward is to simply replace the lines with bullets wherever they appear

I think the ideal solution would be for MediaWiki to use unordered lists for all such lists, and to leave the styling to the skin's CSS.

However, I don't think either of these solutions (all bullets/middots vs semantic markup and CSS) are much help at the moment. Here's a screenshot of the current mishmash.

chocolateboy (talk) 14:57, 6 October 2008 (UTC)

Please could you explain how you produced those saucers in your screenshot. I have tried different browsers and skins and was not able to produce such enormous bullets. This is how it looks in realityonline. Cacycle (talk) 01:06, 7 October 2008 (UTC)

Hmmmm..... How about this: &#149; &#149; &#149; &#149; &#149; &#149; ?-- Boracay Bill (talk) 02:14, 7 October 2008 (UTC)

In "reality"? I'm using Firefox 3.0.3 on Linux with standard Windows fonts and font sizes.

chocolateboy (talk) 09:45, 7 October 2008 (UTC)

Sorry :-) Maybe it is a bug in your "Sharpfonts" package - how does it look with the default font settings? We should use midpoints if the bullets look like saucers for a large proportion of Linux users. Cacycle (talk) 13:22, 7 October 2008 (UTC)

Sharpfonts isn't really a package. It's just a way of configuring Linux fonts to look like Windows XP fonts. The interwikis, categories and "Printable version | Disclaimers | Privacy policy" text all use the default font, which in my case is Verdana size 16. Verdana's a standard font, particularly on Windows, and, AFAIK, size 16 is the default Firefox font size. [4][5][6]

Here's what the Dot size reference list (from Template:•) and Boracay Bill's solar system look like on my system. Saucers indeed!

chocolateboy (talk) 14:51, 7 October 2008 (UTC)

The problem turned out to be the Verdana font - bullets in Verdana are much bigger than in Arial. For operating system and font compatibility we have to use (bold) midpoints, not the bullet symbol. Cacycle (talk) 18:35, 7 October 2008 (UTC)

Would you mind posting a screenshot of what bold midpoints middots look like in the lists? MTC (talk) 19:00, 7 October 2008 (UTC)

Please get rid of the bullets: they are far too bold, drawing the eye from across the page. Use either midpoints, which are acceptable typographic separators, or vertical lines, which are common link separators on websites (although it's true that they can slow down reading by looking like figure 1's, small l's, or capital I's).

Please follow two millennia of writing conventions rather than trying out new ideas. If you don't believe me, see what the expert says: search in Bringhurst (book) (Amazon) for bullet (p 304), “used chiefly as a typographic flag . . . to mark items in a list, or . . . to separate larger blocks of text,” and midpoint (p 313), “an ancient European mark of punctuation, widely used . . . to separate items in a horizontal line”. Thanks. —Michael Z. 2008-10-09 05:40 z

RfC: Category Separator

Here's my summary of the discussion above (please correct any mis-/missing attributions). Note that there is a difference between middots and bullets (see the "Dot size reference list" section here). The OP suggests a dot rather than a bullet, so it would be helpful if this could be clarified.

Support (dot only)

1. Cacycle The bullets are obtrusive saucers using the Verdana font (see above), we should use (bold) midpoints for OS / font compatibility
2. Orderinchaos 09:08, 8 October 2008 (UTC) (double vote, I know, but I can understand the Verdana font issue raised.)
3. User:Sardanaphalus. I think I'd prefer the bold-middot as used in templates. The bullet is too bold, while the middot alone is too small/faint. I don't think the vertical-line is as effective as a (bold) dot because it can resemble an uppercase 'I' or lowercase 'l'. How about making a choice between vertical-line, bold-middot, bullet or something else part of the user preferences?
4. David Göthberg – The bullet • was too intense, and as has been shown above it was even larger for some users. I find the current vertical bar | fairly okay, so I don't have that much of a personal point of view. But after much experimenting over the years the consensus for navboxes have become bold middots · , so I think we should at least try it out for a day or so and see what people think. And note, that navbox consensus is for bold middots, not just middots · .
5. The bullet is too bold, anything else is better, especially the “dot” (midpoint). See my comment above, with reference. —Michael Z. 2008-10-09 05:40 z
6. Based on the de facto navbox standard, I support the use of bold middots for consistency. TenOfAllTrades(talk) 15:48, 9 October 2008 (UTC)

Support (dot or bullet)

1. The Windler
2. Kildor
3. Imperator3733
4. Paragon12321
5. ^demon
6. Scottydude
7. Keith D
8. Looks a tiny bit better, IMO. --Conti|✉ 01:09, 9 October 2008 (UTC)
9. I kinda like the bullet/dot version, too. Abyssal (talk) 01:39, 9 October 2008 (UTC)
10. ILIKEIT :-) Foxy Loxy ^Pounce! 07:24, 12 October 2008 (UTC)
11. Kevin Baas^talk 14:57, 22 October 2008 (UTC) Much cleaner.

Support (bullet only)

1. I support this version of the proposal. It Is Me Here (talk) 17:15, 27 October 2008 (UTC)

Oppose (pipe)

1. MZMcBride
2. Nihiltres
3. chocolateboy
4. Mr.Z-man - Inconsistent with the rest of the software and looks especially bad in some non-monobook skins.
5. MBisanz ^talk
6. Didn't weigh in in teh discussion, but having seen the change I don't like how it looks. –xeno (talk) 17:35, 6 October 2008 (UTC)
7. emerson7 17:56, 6 October 2008 (UTC) i absolutely hate it!
8. I just noticed this change. I'm not too crazy about it, but it's not the sort of thing I'll lose much sleep over. --Bongwarrior (talk) 06:52, 7 October 2008 (UTC)
9. Not terrible but the pipe was better. Icewedge (talk) 06:53, 7 October 2008 (UTC)
10. Doesn't fit in well with the rest of the interface. _TalkIslander 13:47, 7 October 2008 (UTC)
11. —Animum (talk) 01:35, 8 October 2008 (UTC)
12. The pipe was better. The Anome (talk) 00:49, 9 October 2008 (UTC)
13. I spent an age searching through my preferences to see if something had glitched when these lumps started appearing in place of the simple lines. I'd have no objections if it was possible to choose between them in skins/preferences/whatever, but I must say that I prefer the ol' piping. Grutness...wha? 01:31, 9 October 2008 (UTC)
14. Not that it's a big deal, but I prefer the pipe (I think). -- Ned Scott 03:55, 9 October 2008 (UTC)
15. Ditto with Ned. bibliomaniac15 04:13, 9 October 2008 (UTC)
16. With the bullets I thought I was looking at a bloody navbox. Pipes are much more associated with "interface", at least in my mind. Waltham, The Duke of 05:17, 10 October 2008 (UTC)
17. —macy 00:25, 12 October 2008 (UTC)
18. My preferences in order: 1. Bullets; 2. Vertical lines; 3. Middots; 4. Bold middots. As I appear to be the only one who prefers bullets, I will place my vote/comment with the pipe supporters instead. MTC (talk) 18:01, 12 October 2008 (UTC)
19. Itub (talk) 15:06, 28 October 2008 (UTC)

Re: Oppose

Some general remarks to comments above in this section: 1. The current bullets are problematic with certain fonts, therefore we will most probably use an unobtrusive bold middot (·) instead. 2. It is the pipes which are inconsistent with the current Wikipedia styles (e.g. as agreed upon for templates), not the dots. 3. All anonymous users (our main audience) use monobook as well as the vast majority of registered users. I do not think that some minor aesthetic issue for the minuscule fraction of users of other skins should prevent us from fixing it for all other users. 4. There will almost certainly not be a gadget for such a minor issue that can easily be changed with one line of code on the monobook.js page as described above. Cacycle (talk) 14:45, 10 October 2008 (UTC)

"we will most probably use an unobtrusive bold middot." There's currently no consensus to make any change. chocolateboy (talk) 19:05, 10 October 2008 (UTC)

Couldn't have less of an opinion (either is fine)

1. I only noticed the change after it was pointed out here. I'm fine either way. --Stephan Schulz (talk) 07:01, 7 October 2008 (UTC)
2. Or maybe a little animated gif-image of Squirrels for all I care... well maybe not that. Eh whatever, so long as it's relatively professional and / or in good taste I don't mind (I'm sure I could even be convinced to like the squirrels) --Kuzetsa (talk) 23:05, 22 October 2008 (UTC)

1. Support I'd quite like squirrel separators actually--Jac16888 (talk) 23:09, 22 October 2008 (UTC)

It doesn't matter that much IF a gadget is provided to give editors a choice

1. Either we should keep the pipe as a separator, and provide editors with the option of dots (or whatever) as a gadget, or the reverse - change the separator to be dots (or whatever), and provide editors with a gadget to change it back to the pipe. We don't need to force absolutely everyone to see exactly the same thing, nor should editors have to know how to (and be willing to) modify their .js page in order to avoid something they don't like. (We've had this kind of discussion before, with changing the "+" tab to read "new section"; that's why there is a gadget to change the tab back to "+" for those who prefer the prior way.) -- John Broughton (♫♫) 16:55, 9 October 2008 (UTC)

   Fair enough, but I think we should try to avoid adding too many gadgets. The proverbial slippery slope... Waltham, The Duke of 05:23, 10 October 2008 (UTC)

   The right way to implement this would be to structure the list of categories as an ordered list <ol>, and set the format for inline separators using CSS. Then any logged-in editor could add a simple line of code to their monobook.css to change the separator. This works for the action tabs at the top of the page, so even MSIE isn't too retarded to let this work. —Michael Z. 2008-10-10 05:59 z

   Michael Z / Mzajac: I assume you mean an unordered list <ul>, right? Anyway, I have seen this CSS request for many lists many times here on Wikipedia. But I am still waiting for anyone to show how to code that in a way that works. I have seen code for CSS based vertical bars and for CSS based insertion of an image based dot. But an image based dot does not scale up when a user "zooms" (that is sets his browser to show a larger text size). So, do you know a CSS based way to insert a character like for instance a bold middot? --David Göthberg (talk) 07:31, 10 October 2008 (UTC)

   It can be done in Firefox, Opera and Safari [7], but not, currently, in IE :-) (unless this works). chocolateboy (talk) 19:23, 10 October 2008 (UTC)

   There's also a basic article on list manipulation at A List Apart (“Taming Lists”). In modern browsers it can be done with li:before { content: }, which does resize the bullet with text. Using border-left is suitable for generating the vertical line, and works in MSIE, too, so it could be a useful default behaviour. No one seems to worry about Wikipedia's ubiquitous blue unordered-list bullet getting resized, so maybe this won't be a problem here, and of course with CSS a registered editor could change the separator. In browsers which support CSS3 background-size, the bullet's size can be specified in ems, which should resize with the text display (I haven't tested this). —Michael Z. 2008-10-10 21:01 z

   Michael Z and chocolateboy: No, for horizontal lists it doesn't work to use border left since that means you get a left border on the first item too. The only way to remove the left border from that first item is to use some CSS3 code, but that is only supported by some browsers. So that is not an option. You get the same problem with the first item when you insert a character or an image with CSS. (Sorry that I did't remember this first item problem when I wrote my comment above.) So again, no one have shown a CSS based way to do this that actually works. That is; a way that works in most browsers. --David Göthberg (talk) 13:03, 12 October 2008 (UTC)

   FYI: :first-child is CSS2: only not supported by one browser [*cough*]. —Michael Z. 2008-10-14 18:08 z

   This isn't the border hack (nor is this). I don't have access to a recent IE to check it, but the first one (direct link) purports to get the li:before/li:after, li:first-child/li:last-child selectors and the content attribute working on IE. (It doesn't appear to work for IE6 under wine.) chocolateboy (talk) 01:39, 13 October 2008 (UTC)

   Since neither IE6 nor IE7 support the CSS :before and :after selectors, it's not going to work (And in fact, it does fail miserably in IE7 on another computer I happened to have handy here). Reports are that IE8b2 does support them, finally. Anomie⚔ 02:10, 13 October 2008 (UTC)

   Looking at the HTML, it looks like div#mw-normal-catlinks a+span {} might be used to select the first child in this case—would that work in MSIE? But anyway, if we can change the HTML to create an unordered list, can't we just add a class to the first item anyway? —Michael Z. 2008-10-14 18:08 z

   Michael Z: Unfortunately the CSS "+" selector doesn't work in all browsers, especially not in IE 5 and 6. But it also has some problems in IE 7 and 8, Firefox 2, Safari 3 and 3.1, and in iPhone 3G. So we can't use that one, sorry.

   But, I think you just almost cracked it. As you point out, it seems that if we can convince the MediaWiki developers to make the parser add a special class to the first <li> tag in lists, then we perhaps can start to use CSS inserted dots (or whatever separator one prefers) also in horizontal lists. (And also convince them to change the category list at the bottom of pages to be a HTML list.) That would mean we could use a different category list separator in the different skins. And even skin the separator in navboxes differently in different skins and so on. But before anyone runs off filing a bugzilla request, there is one more issue: As far as I remember such CSS inserted characters can not have any formatting, thus I think we can not insert a bold middot, just a middot. Thus that wouldn't solve it for most cases. We have to do some testing. I hope I am wrong about the bolding... --David Göthberg (talk) 15:55, 15 October 2008 (UTC)

   I just checked: li:before { content: "· "; font-weight:bold; font-style:italic; } formats the bullet (or whatever generated content) in both Safari/Mac and Firefox/Mac, so any character formatting should work. —Michael Z. 2008-10-15 18:35 z

   Unfortunately the ":before" selector is not supported by IE before version 8. I should perhaps disclose my source: quirksmode.org. I have tested many of those selectors on my own browsers and so far everything that page states has been exactly correct. I have Firefox 2, Opera 9.02 and a really old Internet Explorer 5.5 installed on my computer.

   --David Göthberg (talk) 20:49, 15 October 2008 (UTC)

Correct mark-up

As some people imply above; there should be no "character" separating such items; because separators are presentational, not data. The items should be in a list (i.e. use OL or UL; plus LI HTML elements, and should be visually separated with a (CSS-applied) background image or border. This is good practice; both semantically and for improved accessibility and usability. See also earlier discussion of this issue, still to be resolved, at Wikipedia talk:Accessibility#Horizontal lists. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:47, 12 October 2008 (UTC)

As I have told you before, and as you can read in the previous section: "No one has shown a CSS based way to do this for horizontal lists that actually works. That is, a way that works in most browsers."

What part of that don't you understand?

--David Göthberg (talk) 16:04, 15 October 2008 (UTC)

Which part of "still to be resolved" don't you understand? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:45, 15 October 2008 (UTC)

Ah, I misunderstood you. So, in a way it seems we agree about these things: I think I agree with you that it would be a good thing to use list markup for horizontal lists. And you seem to agree with me that so far we don't know how to make that work. So yeah, "still to be resolved". I hope the HTML tricks (or something similar to it) that Michael Z is suggesting in the previous section will work out. But I am pessimistic about this.

--David Göthberg (talk) 20:35, 15 October 2008 (UTC)

No trick is necessary, just structuring the list as an HTML list instead of meaningless divs and spans, and adding a class attribute to distinguish the first item. This will let us style the list with borders for vertical separators in MSIE, which, as reported in Quirksmode, doesn't support CSS2.

But the list will be more accessible in screen readers and other assistive technology, and simple CSS2 code will be usable to style the list more flexibly in modern browsers. So you can edit your own monobook.css to use bold bullets or commas, generate a bulleted list, or whatever you like. —Michael Z. 2008-10-15 23:40 z

So you mean we should ask the devs to use those hacks that supplies special CSS code only to certain versions of Internet Explorer and not to the other browsers? Ouch! (We admins can not apply those hacks in the CSS files we can edit, since it has to be done at another level.)

And I have looked into it a bit more: I think you have to apply a special class to all but the first list item, if you want to make IE 7 insert an image dot or a border for all but the first item.

And even if all those tricks were applied, then I wonder what it will do with the line wrapping in the link lists in for instance navboxes. It took us huge amounts of work to make that work right with the system we use now...

--David Göthberg (talk) 13:33, 16 October 2008 (UTC)

1. No. I mean that the HTML should be improved, and the default CSS be set so that it appears the same as the current pipe-separated list in all browsers. Then registered individuals, print versions, and other derivative projects can use CSS to change the presentation as they wish, and readers using assistive technology can have their screen readers tell them how many list items there instead of having to page through every single one. Optionally, a line or two of additional CSS2 or CSS3 code could improve the appearance for all users of newer browsers, while MSIE will ignore that and fall back to the old rendering; this is called progressive enhancement. —Michael Z. 2008-10-16 22:08 z

2. No, the container div of the list already has a unique ID, which can be used to apply CSS to the contained list, or to all contained list items (or to the first or last list item, in a modern browser). All that's needed is to add a class attribute to the first list item, which would allow good ol' MSIE to override the rendering for that item only.

3. It will do nothing to other parts of the page, because the CSS will select the div containing the category list. —Michael Z. 2008-10-16 22:06 z

We know how to make it work; it already does work. We just don't know how to make it aesthetically pleasing, to your exacting standards. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:51, 20 October 2008 (UTC)

Michael Z: Sorry, but as far as I understand, what you are suggesting won't work. Unless you ask the devs to use those hacks that supplies special CSS code only to certain versions of Internet Explorer and not to the other browsers. But I won't waste my time of trying to explain why, again. Instead I recommend you try it out in your user space and you will see what happens. And who knows, you might even solve it. (That would be nice.)

Andy Mabbet & Co: Another approach that would be interesting is that there might exist some kind of standardised markup that can be used to tell screen readers to not read certain things. If there is such markup for screen readers then I know exactly how we can use it. (Such standardised markup does exist for printing and handhelds and some other types of devices and is well supported by the browsers.) I suggest that someone who is interested in this investigates if there is such markup. If you don't find it on the web then you could contact the companies that make screen readers. I think they would be interested enough to respond on such a question. Especially if you point out that you will be documenting it at Wikipedia and thus the usage of it will probably spread to other web sites too. And if such markup is not yet standardised, such a contact could remind them of the need for them to create such a standard.

--David Göthberg (talk) 11:24, 20 October 2008 (UTC)

It may be possible to style content to be ignored by some aural browsers, but that wouldn't resolve the issue of lists not being marked up as lists. I think your faith in the power of Wikipedia to influence commercial providers is somewhat excessive. Also, my name is... Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:51, 20 October 2008 (UTC)

Aural Cascading Style Sheets are intended to do exactly that. No idea how well they're supported by existing screen readers, though. Anomie⚔ 12:43, 20 October 2008 (UTC)

My understanding is that JAWS (the MS Office of screen readers) reads the page content, as rendered by MSIE, including hiding any content which has, e.g., display: none; applied. Better to use existing techniques to make the page accessible to people using today's (and yesterday's) screen readers than to propose future changes. —Michael Z. 2008-10-21 07:36 z

Semantic lists on various browsers

I think it is possible. I whipped up an example which seems to work: Semantic category listings for Wikipedia.

There is a presentation glitch in the way MSIE draws borders on inline elements which wrap—I may have a clean workaround, but it's much too late to test it tonight. —Michael Z. 2008-10-21 07:08 z

Michael Z: Sorry, in your example the vertical bars are broken in Firefox 2, but the dots kind of work (apart from some line wrapping issues). In older Internet Explorers the vertical bars are very broken, and as expected the dots don't work at all. In my Opera both the vertical bars and the dots seem to work as you intend, but it doesn't have the kind of line wrapping behaviour that we usually want here at Wikipedia for horizontal lists.

--David Göthberg (talk) 03:08, 28 October 2008 (UTC)

Thanks for the feedback. Can you be more specific? I'd like to be able to identify and fix the problems. What line-wrapping issues do you see in Firefox and Opera?—I'll see if I can make the bullets appear only at the end of the line, never at the beginning (although our category listings currently show them either way).

Here's what I see, for rendering of the second version:

• MSIE6 shows vertical lines, but extra borders are drawn in the middle of items where the lines wrap—I think I can fix this.
• MSIE7 – same as MSIE6.
• Safari 3.1.2/Mac shows bullets. It wraps the line either before or after the bullet.
• Firefox 2.0.0.14/Mac – same as Safari.
• Firefox 3.0.3/Mac – same as Safari.
• Opera 9.62/Mac – same as Safari.

Do we really need to support twentieth-century browsers, or expect them to render accurately? MSIE5 was released in 1999, updated to 5.5 in 2000, superseded by MSIE6 in 2001, and is unsupported as of the end of 2005 (except possibly for some lifecycle clause for users of Win 2000 SP4 and MSIE 5.01).[8] In comparison, Netscape 4 had its last major update (4.5) in 1998, superseded by Netscape 6 in 2000, had a minor update (4.8) in 2002, and there is no longer any official support for Netscape versions 4 through 9. I probably won't be able to test the page rendering in either of these browsers myself. —Michael Z. 2008-11-02 17:18 z

Valued/Encyclopedic image proposal

I would propose that Wikipedia adopt a 'Valued' or 'Quality' images department. The images that garner this status on Wikipedia would have to be tagged with a different template to the Valued or Quality image seals, in order to distinguish between them. I suggest that images that receive this status should be highly encyclopedic images, although not necessarily of excellent quality. Images that illustrate a point in an exemplary manner, for example, could be nominated as these 'Encyclopedic Images'. There would obviously be problems, for example: who defines an image as being encyclopedic or the most valuable of a large group of images? What scope should or could an image be nominated within? Thus, a vote of consensus would be required. I think the initiation of such an area would benefit Wikipedia. Diagrams, sounds and various other media could also be included in this. I would be willing to draw up a draft for the page; however, the decision must first be made. What does the community think? Elucidate ^{(parlez à moi)} _{Ici pour humor} 08:21, 23 October 2008 (UTC)

Proposals normally work best when they are formed from the bottom up instead of the top down. That is, are we instituting something unnecessary, irrelevant and redundant (to Valued Images)? Or do we have images that are already being proposed for this status, have attributes that distinguish them from Valued Images (fair use, maybe?), yet will not detract from FP's (increasingly) high standards? Another issue is the benefit to the reader. I would think that a reader would be interested in a topic and then be pleasantly surprised to find a particularly illustrative image, rather than browse second rate (not FP, remember?) images and then stumble upon an obscure article. (If they want to browse by images, FPs are also enc.) Wikipedia is not an image repository like Commons. I'm beginning to see this proposal as a lot of red tape and hassle with no direct benefit to the reader. However, I am willing to listen to arguments in favor and especially anticipate reviewing prospective images--need must precede function.--HereToHelp ^{(talk to me)} 02:41, 25 October 2008 (UTC)

We were going to do this, except there's one on Commons that turned out to be much better. You might want to talk to Jjron about this, he was the original proposer. MER-C 03:22, 25 October 2008 (UTC)

Hey, let's just say the Commons one got up and running first, so we didn't pursue or implement the idea here. No reason to downplay the good work of our Wikipedia editors :-). --jjron (talk) 12:48, 28 October 2008 (UTC)

System warning notice style

We are now standardising the colours for several of the system warning notices such as MediaWiki:Editingold and MediaWiki:Protectedpagewarning. Everyone is welcome to join in the discussion and have their say over at Template talk:Fmbox#New type?.

--David Göthberg (talk) 15:16, 25 October 2008 (UTC)

We would really like some more users to come and look at our examples over at Template talk:Fmbox#New type? and say what colours they prefer. Since so far we are only four users who have stated an opinion, and we only agree that it should be some kind of pink, but haven't come to an agreement on what kind of pink.

--David Göthberg (talk) 21:04, 28 October 2008 (UTC)

Mass removal of icons from mainspace

I'd like to mass remove

• 
• 
• 
• 

And any other simlar icon usage from the main space where their usage is similar too [9] using WP:AWB as per Wikipedia:Manual_of_Style_(icons)#Help_the_reader_rather_than_decorate any opinions ?

The main problem at the bottom of your example [10] is that {{Template group}} with empty list parameters were added in [11]. That was pointless and should be reverted. The template documentation says the list is required and maybe the template should react if it's omitted or empty. But the icons may be useful in some other places. It seems important what you intent to remove as "similar to" the example. PrimeHunter (talk) 16:41, 27 October 2008 (UTC)

[12] is a other example of what I'm suggesting Gnevin (talk) 18:39, 27 October 2008 (UTC)

I think the main problem in your new example is also that {{Template group}} is used at all. The list parameter only contains one template which displays content in that place so there is no template "group", and one entry is not really a "list". I would remove drop the whole use of {{Template group}} and not just the icon which is a part of it. When other articles have real template groups with multiple templates then the icon may serve a purpose. It draws attention to the show/hide link which doesn't show or hide a template as usual, but a whole group of templates which can each have their own show/hide link. I'm not going to support mass removal without getting more clarification than two examples and "similar to" about what it is you want to mass remove. PrimeHunter (talk) 00:33, 28 October 2008 (UTC)

I Agree. See Design#Terminology (old diff, sense is prevailing now), which has one adamant defender. 96.50.4.248 (talk) 19:14, 27 October 2008 (UTC)

Ten More at Multimedia (diff). Ugly suckers. 96.50.4.248 (talk) 18:58, 28 October 2008 (UTC)

watchlist changes email

I've been mulling this over recently... One can set their watchlist (as well as RC) to generate a list of articles that have been changed that are collapsed by javascript, with one link of 'all changes' today, and by using the javascript, can pick and choose which 'diff' or 'cur' to work from.

What I'm proposing is that, like an email list, one can set an opt-in option on their preferences to allow them to be emailed when a page they were watching was changed. However, to reduce the number of emails any one person would receive (I can only imagine for the people who watch thousands of pages...), this option would provide the changes in a digest type format, rather than as separate emails. This would enable people to keep track of their watchlist while away, or allow people to view their watchlist (a day late) from their email rather than by logging on. Of course, this would also (only) work if they supply their email, but special:emailuser works only in such a way, and there is the opt-in for messages to be sent when your talk page is changed.

For example...

We have in the header: Watchlist changes for 2008-8-28 (or what not. Also to be sent out at the time [below] one day later)

• 5 changes to http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals) — http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&curid=3706897&diff=248137447&oldid=248122890
• 3 changes to http://en.wikipedia.org/wiki/Talk:World_of_Warcraft:_Wrath_of_the_Lich_King — http://en.wikipedia.org/w/index.php?title=Talk:World_of_Warcraft:_Wrath_of_the_Lich_King&curid=12591515&diff=248137244&oldid=247935307
• 2 changes to http://en.wikipedia.org/wiki/Wikipedia:Reliable_sources/Noticeboard — http://en.wikipedia.org/w/index.php?title=Wikipedia:Reliable_sources/Noticeboard&curid=11424955&action=history
• 3 changes to http://en.wikipedia.org/wiki/Wikipedia:Good_article_nominations — http://en.wikipedia.org/w/index.php?title=Wikipedia:Good_article_nominations&curid=3514978&diff=248134513&oldid=248127457

A slightly alternate form would be:

• 5 changes to [[Wikipedia:Village_pump_(proposals)]] — http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&curid=3706897&diff=248137447&oldid=248122890
• ...

I'm not quite sure on what time these emails would be sent out by the server, though I'm leaning toward 0:00 <local time> where local time is the time offset specified by the user for watchlist and recent changes.

Thoughts? --Izno (talk) 05:46, 28 October 2008 (UTC)

This is an interesting idea. I'm leaning towards sending the emails out every 12 hours (00:00 and 12:00 local time), although maybe it would be best to have a few choices (every 6, 8, 12, or 24 hours are some choices). -- Imperator3733 (talk) 06:06, 28 October 2008 (UTC)

There is a watchlist RSS feed available at http://en.wikipedia.org/w/api.php?action=feedwatchlist . Configuration is as follows:

Parameters:
  feedformat     - The format of the feed
                   One value: rss, atom
                   Default: rss
  hours          - List pages modified within this many hours from now
                   The value must be between 1 and 72
                   Default: 24
  allrev         - Include multiple revisions of the same page within given timeframe.

from http://en.wikipedia.org/w/api.php

Any decent mail program supports RSS, so emailing shouldn't really be necessary. MER-C 10:41, 28 October 2008 (UTC)

Recent Redirects

I'm sure that a page for recent redirects would prove to be useful, especially for spotting and reverting vandalism. A lot of Grawps' IP socks just redirect pages to nonsense, /b/tards are prone to do the same, and it's not uncommon for the usual vandals to simply redirect a user talk page as a form of Harassment. Any thoughts? ~ Troy (talk) 23:54, 23 October 2008 (UTC)

I think this could be valuable. It could be done by adding a filter to Special:RecentChanges; in particular, on the line that now says "Namespace: (select) Invert selection (checkbox) ", there could be another checkbox, "redirects only". The MediaWiki software already knows which pages are redirects (these show in italics in indexes like Special:Allpages), so filtering should involve a minimum of programming. -- John Broughton (♫♫) 13:20, 24 October 2008 (UTC)

Yes, that does sound useful.--HereToHelp ^{(talk to me)} 01:58, 30 October 2008 (UTC)

Proposal: ReCaptcha

Just wanted to put in a word for Wikipedia to start using ReCaptcha for our verification captcha. It's a community-driven information-technologic project like Wikpedia and I think it would be good for our karma.

This content was a direct copy from http://recaptcha.net/learnmore.html - we can't have copyvios here any more than the mainspace. Follow that link above to read what Jengod's talking about. Happy‑melon 20:05, 28 October 2008 (UTC)

Just something to think on. Thanks for reading. jengod (talk) 16:47, 28 October 2008 (UTC)

I'm inclined to agree; I'm somewhat surprised that we don't use it already, considering the goals of ReCaptcha. EVula // talk // ☯ // 20:35, 28 October 2008 (UTC)

It's been discussed before. The main objections are (1) it isn't open-source-based, and (2) it makes Wikipedia's continued operation dependant on the ReCaptcha site staying up. --Carnildo (talk) 20:56, 28 October 2008 (UTC)

It seems that they offer a PHP plugin that wraps their API. We could trivially reverse-engineer this into an extension or modification to the existing CAPTCHA software that would use ReCAPTCHA's images if available, but fall back onto our existing code if a request for a new captcha didn't succeed for whatever reason. The main issue would probably be the staggering increase in number of captcha requests the ReCaptcha project receives - do we have any stats on how often the captcha filter is triggered on wikimedia wikis? It must be tens of thousands of times a day. Happy‑melon 21:03, 28 October 2008 (UTC)

I think it would be a good idea to use ReCaptcha, as long as we have a fallback option like Happy-melon mentions above. -- Imperator3733 (talk) 02:49, 29 October 2008 (UTC)

It would be nontrivial to duplicate reCAPTCHA, and I wouldn't recommend it; but I don't see any reason why we shouldn't use reCAPTCHA most of the time, and only fall back on the built-in PHP CAPTCHA engine when it's not available. This would be an excellent way to promote CAPTCHA research and in digital archival and retrieval. Load shouldn't be an issue; my expectation would be that their current load is many times that of the WMF projects, and that regardless they would welcome the load for the additional value it brings. Dcoetzee 04:10, 29 October 2008 (UTC)

reCAPTCHA's audio captcha is also trivially breakable. A MediaWiki extension is already available, but its activation on Wikimedia projects has been repeatedly refused by Brion Vibber and Tim Starling on the grounds of it not being free software, the dependence on an external site, and the lack of security of its audio captcha. — Werdna • talk 14:10, 29 October 2008 (UTC)

Neither our article nor the reCAPTCHA website seems to explain what is happening to the millions of words deciphered each day. Where are these digitized books available to read? Are they free to download? Rmhermen (talk) 18:17, 29 October 2008 (UTC)

Ibid template

I'd like a new template created to enable tagging of articles that excessively use "Ibid." references — a practice that is discouraged in our footnotes guidelines because of the difficulty involved in keeping such references consistent over time (some articles, such as English Reformation, don't even use it properly). A full-text search for "ibid" turns up dozens of articles that could use such a tag. Dozens more use the equally problematic op. cit. and loc. cit. (these are also misused in some articles). I think this is prevalent enough (and will no doubt continue to be prevalent enough, even after the current instances are fixed) to warrant the creation of one or more templates (and associated category/-ies) to alert interested editors to such articles. I'd like to leave it to someone else, however, to choose the title and format of the template, since I don't have a lot of experience in creating these kinds of templates here on Wikipedia. Anyone interested? - dcljr (talk) 21:01, 24 October 2008 (UTC)

If you don't get any help here, try Wikipedia:Requested templates. -- John Broughton (♫♫) 16:18, 25 October 2008 (UTC)

Done. See {{Ibid}}. It mentions all three problematic notations you flag, and will place an article into a general cleanup category as similar templates do. I don't think this is high traffic enough that it warrants its own associated category. Tweak as necessary of course. I'll wait a bit for improvements/modifications before adding it to an appropriate section of Wikipedia:Template messages. Hmmm. I'm thinking Wikipedia:Template messages/Cleanup#Verifiability and sources would be the right place.--Fuhghettaboutit (talk) 09:09, 26 October 2008 (UTC)

Thanks. I have indeed "tweaked" it. Interested parties might want to check the wording of the template, as there has been some disagreement about how much detail is needed. - dcljr (talk) 04:33, 1 November 2008 (UTC)

Icons of search engine plugins should reflect language of Wikipedias

---As John Broughton suggests in the 7th paragraph I copy this here from the technical village pump---

Hello: I think that many people like me look for information in different Wikipedias (different editions/languages of it). I believe that not few people, to save time, use the offered (in one of the first code lines, that begins with <link rel="search") search engine plug-ins for the browsers. If Firefox is used each plug-in comes with an icon (in this case a W). The problem is that, as the icons of the different Wikipedias are all the same, it happens to me often that I search in a Wikipedia that I didn't want to look for. I think that this could easily happen to more people. The solution is easy: to put a flag in a corner of the icon: for example the one of Italy for the Italian Wikipedia. Thanks, --Edupedro (talk) 22:29, 26 October 2008 (UTC)

But is English a UK, English, or USA language? Is Portugese a Portugese or Brazilian language? What flag would we use for Anglo Saxon? And the flag would be so small, it would be hard to work out what it depicted. DendodgeTalk^Contribs 22:33, 26 October 2008 (UTC)

Hello: I would go to the origins and use the flag of England for the English Wikipedia and the one of Portugal for the Portuguese version. I imagine that some Australian, ... and Brazilian ... people would prefer to use different flags: the solutions is easy, create a page with the search engine plug-ins (for example Wikipedia:search engine plug-ins for the English edition) with different flags to choose from. For the Anglo-Saxon Wikipedia "ang" could be used instead of a flag. I've been using personalized icons for the Wikipedia search engine plug-ins from some months ago and can confirm that the flags are easily seen (and my vision is normal, not excellent) and really help to search faster, in a more comfortable way and not confusing looking for in a different Wikipedia. You can see a similar solution for the Dutch and Nynorsk editions in Mycroft and for Encarta in the same web. Thanks, --Edupedro (talk) 23:22, 26 October 2008 (UTC)

A person can already restrict searches to a particular language Wikipedia by adding a search term, such as site:en.wikipedia.org for the English Wikipedia. You can even create a "smart keyword" in Firefox so that you don't have to type as much. (Also, I think that the "W" icons you mention are actually part of the Firefox browser, rather than something provided by the Wikimedia Foundation; if so, it's somewhat pointless to make a suggestion on this page.) -- John Broughton (♫♫) 14:44, 27 October 2008 (UTC)

That's not actually true. While Firefox does ship with a Wikipedia plugin, every WP page also uses OpenSearch to provide a search plugin for auto-discovery by any compliant browser. OpenSearch allows a site to specify a default icon. The request is perfectly cromulent when discussing them. Smart keywords are undiscoverable and are basically deprecated in favour of OpenSearch (and the Add to Search Bar extension, which is due for integration into Firefox in future), and are a workaround for the issue described rather than a solution. Chris Cunningham (not at work) - talk 15:01, 27 October 2008 (UTC)

Hello: In the past I searched sometimes from Google adding for example site:en.wikipedia.org in the end. I think it's useful, but the search engine plug-ins make the searches faster and more comfortable. I didn't know about the "smart keywords" of FF: I've tried them and find them OK. But if you usually search in more than 20 web sites or pages (like me) I find it difficult to remember so many keywords and when you use 2 or 3 versions of the same web (for example of WordReference or Wikipedia) it can be confusing. So I prefer the search engine plugins: they work with Explorer and Firefox. The first one only admits the OpenSearch format and doesn't show icons, while FF admits both OpenSearch and Sherlock and shows icons, which is really helpful. Every page of en.wikipedia.org has as one of the first lines of code this one: <link rel="search" type="application/opensearchdescription+xml" href="/w/opensearch_desc.php" title="Wikipedia (en)" />. It offers the search engine plug-in, located where href says: http://en.wikipedia.org/w/opensearch_desc.php. If we go to that page and open it with the notepad we can see the icon label (<Image height="16" width="16" type="image/x-icon">), that contains the URL of the icon for the plug-in: in this case http://en.wikipedia.org/favicon.ico (the favicon of Wikipedia, shown if we enter this URL in the address bar of the browser). My suggestion would be to use instead an icon with something to distinguish it from other Wikipedias (languages). To avoid controversy it could be just the "en" Wiki (abbreviation). And to make it more visual I'd create a page called Wikipedia:search engine plug-ins with several plug-ins, each one with the flag of England, UK, USA, Australia, ..... so anyone can choose the one which prefers. Regards, --Edupedro (talk) 23:57, 27 October 2008 (UTC)

You may want to move this discussion to WP:VPPR, as a proposal. -- John Broughton (♫♫) 20:24, 28 October 2008 (UTC)

←I'm thinking this probably isn't the greatest idea. It's just an invitation to drama and arguments over using the 'right' flag. Plus, I just don't see many people using it--and those who would, probably already know, or know where to ask, how to change favicons. [ roux ] [x] 23:33, 29 October 2008 (UTC)

Well, to you Americans it might seem strange, but most of us Europeans speak several languages and regularly use several different language Wikipedias. (Consider that for most of us there are several countries within just some hours train ride.)

I use Firefox and I use the search plug-ins that Wikipedia offers, since they are very convenient and in many ways are better than using an external search engine. And since the search box on the pages don't open the result in a new window, then that box is not an alternative to the search plug-ins. I have a whole bunch of Wikipedia search plug-ins, but all of them have the same white [W] icon. So it is pretty confusing. It happens all too often that I can't find what I search for and try several alternative spellings until I realise that my search box has the German or Swedish search selected, not the English one.

One fairly okay alternative is of course as Edupedro suggested to use the short text form of the language, like "en" for the English Wikipedia. But we who use multiple languages know that it is a long standing tradition to use the "origin" flag of each language. That is, most multilingual web sites use the British flag for English, the Portuguese flag for Portuguese, and so on. I have actually several times seen Brazilian web sites where they use the Portuguese flag to mark the language, in-spite the site being very Brazilian.

And the flag doesn't have to be big, since it is merely a matter of telling apart a handful of known flags. One only needs some pixels to see the colour difference between for instance a British, German and Swedish flag. As little as 8×6 pixels can be enough for that. I think you can tell which one is which of these flags, with the Wikipedia favicon as size comparison:

--David Göthberg (talk) 02:38, 30 October 2008 (UTC)

That's Russia, Germany, and Swaziland, right? It's even worse on my laptop, where the first one is Puerto Rico and the third is Barbados, but I can't find anything with the black-and-yellow stripes of the second flag. --Carnildo (talk) 08:06, 30 October 2008 (UTC)

See WP:Icons for the issues with flags Gnevin (talk) 10:40, 30 October 2008 (UTC)

Carnildo: I hope you are just trying to be funny, right? What I meant is that since I know that I speak English, German and Swedish, and have installed the search plug-ins for those languages, then those tiny flags are enough for me to tell apart which plug-in is which. And I would actually use slightly bigger flags, since there are plenty of space in the favicon. And the three examples above were resized by MediaWiki's SVG renderer. When I use a better tool for the resizing and do some hand tweaking the images become slightly clearer. Now, if I only had some tool to add those images to the plug-ins...

--David Göthberg (talk) 16:01, 30 October 2008 (UTC)

I'm being completely serious. What I'm saying is exactly what I see when I look at those icons. You need to consider that not everyone has an LCD monitor capable of reproducing crisp single-pixel areas of color. My desktop monitor is an old CRT connected through a cheap KVM switch, while my laptop is an OLPC XO-1, which cannot display detail that is less than 2 pixels on a side (you should see the rainbow effects that result when someone tries to be cute and use halftoning instead of a 50% grey). --Carnildo (talk) 21:45, 30 October 2008 (UTC)

Another option could be to precede or superimpose the W logo with a little language code. These could be created using a tiny pixel font, 5 pixels or so tall. —Michael Z. 2008-10-30 16:49 z

DE.W

EN.W

WPT

The last one needs a 1-px white outline for the language code, so it's clearly readable over the W. —Michael Z. 2008-10-30 16:55 z

Hello: The Wikipedia's search engine plug-ins that I have at the moment installed are the one for the English version and the one for Spanish. I did the procedure (easy and quick but "craftwork") that you can see in this user subpage of mine to see flags in the bottom of the icons with the W. These flags are bigger than the ones shown by David Göthberg. I can recognize well David's flags and very well the ones I use. I used the tiny command-line program of Fatih Kodak to covert the personalized icons to the code I inserted in the plug-ins (it can be downloaded from this page of him -for Linux and Windows- and also can be used online from this page also of Fatih). I have had a look to Wikipedia:Icons and seen that has nothing for these plug-ins. We could put a link there to a new page (for example Wikipedia:search engine plug-in) with different versions of the English search engine plug-in, each one with a different icon: the default one (W), one with "en" on the bottom of the W, another one with the flag of England, another with the one of the UK, Ireland, USA, Canada, Jamaica, Australia, New Zealand, South Africa, India, ...... I think we shouldn't discuss about which one is the best, just offer the possibility to everyone to choose the one (s)he preffers. I think that page would really be helpful for many people (and avoid the "craftwork"). Thanks, --Edupedro (talk) 21:45, 30 October 2008 (UTC)

Edupedro: Oh, thanks for the links! Now I have inserted flag icons in all the Wikipedia search plug-ins I use. It looks very nice in my Firefox, no confusion anymore. I actually use flags that are 13x8 pixels, placed in the lower right corner of the usual [W] icon.

And yes, let's make a how-to page named something like Wikipedia:Search plug-ins, where we can document all this. I see that Wikipedia:Searching#Browser-specific help does have some (outdated) information on this. An option would be to update that one instead.

I have now read up on these plug-ins and did some testing, and have a nifty image trick to report. (But let's agree on the page name for our how-to page first and then discuss more there, or move this discussion to Wikipedia talk:Searching.) But I think I have found out something even better:

Instead of uploading the plug-ins to our how-to page I suggest we create them at mycroft.mozdev.org. I took a close look at that site and there is much more to that site than first meets the eye. We can actually update the existing Wikipedia search plug-ins there and add new ones, with any images we like. (And many of the Wikipedia plug-ins there do need a work over.) That site has much better handling of plug-in creation, updating and installation than we would have on our how-to page. I will probably create some plug-ins with the language icons I have made, and do some updating of the existing plug-ins there.

--David Göthberg (talk) 05:18, 31 October 2008 (UTC)

Hello, David (everyone invited also, of course): I changed the icons of Mycroft for Wikipedia in English and in Spanish a couple of times (with flags in the bottom) but they put the previous ones again, without the flags. So I think it will be better to do all for these languages in the Wikipedia site. I think that Mycroft people don't want to change the plug-ins already in OpenSearch format. But I see many still with Sherlock format. This can be a good chance to put personalized icons with flags while we change those plug-ins from Sherlock to OpenSearch. I think we can also edit Wikipedia:Searching and/or create the page you propose: Wikipedia:Search plug-ins, and redirect to it Wikipedia:Search plugins, Wikipedia:Search plug-in, Wikipedia:Search plugin, Wikipedia:Search engine plug-ins, Wikipedia:Search engine plugins, Wikipedia:Search engine plug-in and Wikipedia:Search engine plugin. And, as you say, we can inform about all this in Wikipedia talk:Searching. Today I go for a trip of one week, so probably I won't be able to write in Wikipedia. But if you can and want go ahead, please. Thank you, --Edupedro (talk) 01:56, 1 November 2008 (UTC)

To end the practice of 'nominate and support' on WP:FSC (and WP:FPC)

Currently nominators of featured sound candidates follow a practice of nominating and then supporting ('voting for') their own nominations (see for example here). This is also done on WP:FPC where the expression used is 'support as nominator'.

This has been an issue on WP:FSC because of the lack of transparency (to put it minimally) in the process of reviewing candidates.

So, I propose this 'nominate and support' ('support as nominator') practice be discontinued. Nominators in future should only nominate, and other editors should support (or oppose or whatever). --Kleinzach 01:00, 24 October 2008 (UTC)

As long as it's clear which !vote and comment is the nominator, what T^&(&*^ difference does it make? This is widely done, across all forms of polls where there is a nominator, and occasionally permits the nom to make a personal point not suitable for the nomination itself. The closing admin should always check to make sure the nominator is being counted, and not being counted twice; and this would be so even if we had such a rule. Septentrionalis PMAnderson 02:35, 24 October 2008 (UTC)

This is the text at WP:FSC:

If a nomination is listed here for at least 14 days with three or more supporting declarations and the general consensus is in its favor, it can be added to a Wikipedia:Featured sounds list.

The requirement appears to be nomination + 3 supports = 4 'votes'. It's not. It's really 3 'votes'. --Kleinzach 00:42, 26 October 2008 (UTC)

So clarify FSC, if necessary. But such largely arbitary lines are undesirable, precisely because they produce disputes like this on the margins. Septentrionalis PMAnderson 17:07, 26 October 2008 (UTC)

Well, that was my rationale for suggesting here that the 'nominate and support' practice be discontinued. --Kleinzach 23:56, 26 October 2008 (UTC)

Much simpler to acknowledge that it will continue to be done both ways, and clarifying the interpretation. You will not change everybody's behavior; you may be able to remind the closing admins to be consistent. Septentrionalis PMAnderson 01:20, 28 October 2008 (UTC)

Strongly support Klein's proposal that the redundant and misleading instruction that "three" supporting declarations are required (when of course the nominator supports) be changed to three aside from the nominator's declaration. At FAC, nominators are instructed not to explicitly declare, since the process of reviewing should be oriented towards reviewer declarations. IMV, three reviewer supports is a reasonable minimum, not two. Tony (talk) 02:56, 28 October 2008 (UTC)

I've notified WP:FPC of this proposal. Shoemaker's Holiday (talk) 04:47, 28 October 2008 (UTC)

As far as my observations go at wiki FPC, the nominators vote doesn't really count all that much anyway, I don't really see the point in changing it as far as FPC is concerned. There is some advantage in letting the nominator vote though, in the case of featured pictures it lets the nominator elict which edit they prefer and is useful in this context, so leave it imo. Noodle snacks (talk) 07:37, 28 October 2008 (UTC)

Yes, this seems to serve no purpose, and might even make things worse. The nominator's [insert appropriate word here] is important, sometimes even necessary for determining which version to promote. (I also note that I can count on one hand the contributions to FPC the proponents have made in the past year). The only reason why it is a problem at featured sounds is because of low participation, something that doesn't apply at FPC. MER-C 10:22, 28 October 2008 (UTC)

I still don't understand why it's considered a problem at FSC, in all honesty. Kleinzach and Tony are the only people saying it is, and have never really clarified why beyond "It's done that way at FA". Shoemaker's Holiday (talk) 12:35, 28 October 2008 (UTC)

Now then, my thoughts. 3 votes, including the nominator's, has been what's required for the entire history of WP:FSC, as a review of the archives will show. So, including the nominator in the count of three is the default, and changes would need consensus. I do not think that we have sufficient voters to justify an increase to 4 - in practice, this will only serve to increase the already somewhat excessive time that it takes to get enough people to review. (Featured sounds, due to still having relatively low numbers of voters, only has a minimum time period, not a maximum.)

I do not know what Kleinzach considers the "lack of transparency" at FSC. It certainly could benefit from more people, but I don't see any aspect that isn't transparent and above board. Shoemaker's Holiday (talk) 04:47, 28 October 2008 (UTC)

Agree with SH. If anything, the instructions could just be made clearer to say, "the nominator and three additional support votes are required" or something along those lines. howcheng {chat} 16:03, 28 October 2008 (UTC)

Now changed to three (including the nominator). The discussion whether including should become plus belongs at WT:FSC, and I have no real preference. Septentrionalis PMAnderson 16:16, 28 October 2008 (UTC)

Problem of determining the "general consenus"

That leaves the problem of determining the "general consensus" in favour of promotion. Here are two examples taken from this month's files:

• Hunters' Chorus, promoted despite 3 opposes against 4 supports
• Le trompeur trompé, promoted despite 2 opposes against 3 supports

They were promoted and immediately removed to the archive - examples (to answer Shoemaker's Holiday's question) of the lack of transparency in the WP:FSC process. Anyone involved would have assumed that these files would not be passed, but they were! --Kleinzach 02:51, 29 October 2008 (UTC)

Oh, tha. Well, I did try and start a discussion about what proportion of support to oppose should be required, but noone wanted to discuss it. A supermajority you seem o want (at least a 2:1 ratio of support to oppose) seems reasonable, but the discussions kept getting derailed. But I wouldn't call that transparency, more of an ambiguity that should be discussed, but was derailed every time I tried to get it to be. Want to try that again on the talk page? Shoemaker's Holiday (talk) 15:42, 29 October 2008 (UTC)

Why not here? Let's keep this is one place. I'm not sure 'supermajority' is the right term, more like 'overwhelming' support - but I'm open to suggestions on how this is formulated. Judging by your comments, this may be easy to agree on. --Kleinzach 00:20, 30 October 2008 (UTC)

While I think a little discretion should be allowed, I think a 2:1 ratio of support to opposes, "Weak" supports and opposes counting as half a vote, seems reasonable. Shoemaker's Holiday (talk) 01:15, 30 October 2008 (UTC)

That implies a 'voting' system. Is there agreement about going over to a voting system? --Kleinzach 01:20, 30 October 2008 (UTC)

Kleinzach is forum shopping. He failed to get consensus at FSC talk and rejected two compromise solutions. It is disappointing to see him raise the matter here in this manner: using examples as if no other remedy were possible, yet neglecting to note that I have specifically offered to nominate any of my own featured sounds for delisting if any editor disagrees with the closer's decision. It's surprising to see this turn of events (Wikisource and featured picture nominations kept me busy for several days); not sure what to make of this subthread--shall I open a delisting nomination now? Durova^Charge! 03:35, 2 November 2008 (UTC)

Hmm. Durova Try to avoid personalizing these issues, OK? True there's been a lack of consensus at FSC talk, although a series of people have agreed that there are problems with the FSC process (see here). I raised the issue here (as explained on the FSC talk) to place the discussion in a wider context, hoping to make some progress. I'm unaware of any serious 'compromise solutions' being put forward - or indeed that I've been instrumental in rejecting them.

If you are really willing to delist the controversial FSCs mentioned above (Hunters' Chorus/Le trompeur trompé) - without any more of these tortuous negotiations - that will be a step in the right direction. --Kleinzach 00:02, 4 November 2008 (UTC)