Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

The proposals section of the village pump is used to discuss new ideas and proposals that are not policy-related (see Wikipedia:Village pump (policy) for that).

Recurring policy proposals are listed at Wikipedia:Perennial proposals. If you have a proposal for something that sounds overwhelmingly obvious and are amazed that Wikipedia doesn't have it, please check there first before posting it, as someone else might have found it obvious, too.

Before posting your proposal:

• Read this FAQ page for a list of frequent proposals and the responses to them.
• If the proposal is a change to the software, file a bug at Bugzilla instead. Your proposal is unlikely to be noticed by a developer unless it is placed there.
• If the proposal is a change in policy, be sure to also post the proposal to, say, Wikipedia:Manual of style, and ask people to discuss it there.
• If the proposal is for a new wiki-style project outside of Wikipedia, please go to m:Proposals for new projects and follow the guidelines there. Please do not post it here. These are different from WikiProjects.

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

Wiki cache for references

There is a problem with material cited with an online reference, when that reference disappears, especially when someone then deletes the content on the basis it can't be verified. There are two situations: a) sometimes it is known, or can be suspected, that a ref will disappear because of the nature of the site (its practice is not to archive its own pages)—there is then the opportunity for pre-emptive action; b) it is unexpected—in this case it may still be available on google, but possibly only for a short time.

Some solutions to this might be:

1. An archive noticeboard, where editors ask for endorsement that the material they have used is accurately based on the ref. This would be viable for simple uses of the ref, such as straightforward factual material.

2. An archive noticeboard where relevant extracts from the ref are posted and endorsed. This would be useful when not a large portion of the ref is being used.

3. A Wiki cache, similar to google, where editors can cache a page directly. This would be particularly useful if it could also cache a google cache.

The best solution is 3, as it does not require any other editor participation or endorsement. 1 and 2 don't need any developer work, and could be instituted immediately. There could be a combination of these.

Ty 09:00, 13 September 2008 (UTC)

I share Ty's concern about cited web pages disappearing. Some topics are mainly covered by web pages, and articles on these topics risk being left unreferenced in a few year's time.

Option 3 looks best, as it's hard to tell in advance how much detial wil be needed, e.g a Ga /. FA reviewer might want to check that an article paraphrases a source correctly and does not select only passages that favour a POV.

A wiki cache could be implemented by a bot. The bot should only cache pages the first time they are referenced, as they may be later taken over by advertisers / domain resellers. The bot should:

• exclude citations that have an ISBN, DOI, PMID or other reference number that identifies an alternative route to the information.
• exclude web pages that have an ISBN, DOI, PMID or other reference number; but insert these reference numbers into citations if they are not already present.

The greatest difficulty for a bot would be multi-page web articles such as those at Findarticles.com - I'm still trying to think of a solution for that. -- Philcha (talk) 09:54, 13 September 2008 (UTC)

I was envisaging a more modest proposal, where the wiki caching would only take place when a user initiated it, as there's no need to wiki-cache refs that are likely to be available indefinitely. In the case of manual caching, multi-page articles could be done one at a time. Ty 11:22, 13 September 2008 (UTC)

How can editors judge which refs "are likely to be available indefinitely"? Some sites go off-line without notice. Many of the online mags drop pages completely after a couple of years; this is most common in "popular culture" subjects, e.g. computer games. A few academic mags move pages to archives, and I've recently had to contact one of these to tell them that the archive entry for the article I wanted linked to the wrong article. -- Philcha (talk) 11:44, 13 September 2008 (UTC)

That's up to editors to judge. You have given examples where they are not likely to be available indefinitely, so may well need to be cached. Likely to be available for example are Hansard and The Times (the latter available from more than one source from 1785). Items already cached in the web archive would presumably not need to be cached on wiki as well, unless there is a prospect of that project disappearing. Some refs are not particularly critical; some have information duplicated in other sources, e.g. a newspaper carrying a syndicated story. I'm not against caching every ref on wiki, but I don't think it's essential. Ty 12:13, 13 September 2008 (UTC)

Also, not all editors will have the know-how or will to follow all these steps manually. SharkD (talk) 11:58, 13 September 2008 (UTC)

There aren't any steps yet, as there isn't any system in place. It could be as simple as editing a URL and clicking a button. Ty 12:14, 13 September 2008 (UTC)

Wouldn't a cache cause serious copyright issues? I know Google is willing to push the boundaries of fair use, but since we're a free content project, we should take a more cautious approach. Perhaps a collaboration with the Internet Archive would be a better idea, where we could ask them to go through our references and make sure their archive includes those links. JACOPLANE • 2008-09-13 12:03

Far less copyright issues than google, which is a commercial entity. It's a service already offered by WebCite. Cached refs could be marked "No Index", and only be accessible to users when the original source became unavailable. Ty 12:20, 13 September 2008 (UTC)

This is an itneresting proposal; it would be possible to implement a very simple system whereby a source could be copied onto the toolserver – obviously the text cannot be released under the GDFL so cannot be placed on Wikipedia. (I won't comment on the potential space issues.) But I think that copyright is the main concern. Sites such as google's cache and waybackmachine are the only reason I think there's even the slimmest chance that we could take it further. Many papers are freely available for reading under the condition that "no further copies can be made". I would suggest raising a query at Wikipedia:Copyright_assistance, as hopefully an expert will be able to tell us how to work the loopholes. I for one would be reluctant to begin to create a bot for this purpose without assurance that I wouldn't be bringing on a huge copyright lawsuit from all the major publishers! Martin (Smith609 – Talk) 14:46, 13 September 2008 (UTC)

I was going to mention WebCite. If someone is concerned that a reference is going to go away, why not just use WebCite directly instead of reinventing it? Anomie⚔ 15:03, 13 September 2008 (UTC)

Some pages don't archive on WebCite. I've tried to use it to archive a google cache and it rejects it. Ty 15:23, 13 September 2008 (UTC)

As a counterpoint, if a web site, which in all other ways is considered reliable, but yet does not archive pages as a matter of practice (this being different from an accidental loss of date) , can that site really be called "reliable"? There's a reason that print sources, whenever possible, are preferred over web ones in that there's always (at least, in the practical future) a copy of the print version. I'm not saying that sites that use robots.txt or other methods to block caches or archive.org aren't a problem, as long as they keep their own material around. Those that don't... that's a questionable issue. --MASEM 15:14, 13 September 2008 (UTC)

Reliability, in wp referencing terms, refers to quality of content, not whether or not a site then keeps that content forever. That's an entirely different type of reliability. Sites choose not to archive either all or some of their content, for a whole variety of reasons. Maybe it's no longer of use for them, but that doesn't mean it's no longer of use for us. Ty 15:36, 13 September 2008 (UTC)

I do realize our current definition of reliability says nothing about archiving, nor am I saying it has to; I guess I'm bringing up the point for thought: should retention be considered as part of our definition of reliable? Should we be relying on web caches for reference content? --MASEM 16:00, 13 September 2008 (UTC)

Reliable sources can include difficult to access books and even user-generated translations of foreign language content, so I'd say no, retention and accessibility are not our primary concerns when judging if a source is reliable, just authority. It is, however, going to be an increasingly significant problem as time passes. Archival of the sources for at least our featured content should probably be considered an important goal. --erachima talk 16:16, 13 September 2008 (UTC)

Print sources have their drawbacks, e.g. how often does a reviewer have the books already? More seriously Wikipedia has a lot of articles about notable topics in what could be called "popular culture", where most of the sources are web-based - the examples I'm most familiar with are computer games (and chess, to a lesser extent), but I'm sure there must be a good 100 other categories. FAs in these categories could be down-graded to "C" or even "start" class if cited pages vanish.

WebCite has 2 drawbacks from this point of view: it archives only pages that the authors / publishers have thought to archive; and it expects publishers to pay for at least some aspects of its service (WebCite FAQ), which will deter some.

From the point of view of coverage, I think Internet Archive (Wayback Machine) is a better bet: it's not academically oriented; it's free; and it's crawler driven, although the crawler is Alexa.

Re copyright, Internet Archive's info is rather scanty, but WebCite FAQ refers to a case Field vs Google, US District Court, District of Nevada, CV-S-04-0413-RCJ-LRL, which ruled that caching does not constitute a copyright violation, because of fair use and an implied license.

If we relied on either of these archives, there would still be a question of what monitoring would be required. 404s and other HTTP "error" codes are easy. The problem is URLs that are taken over by advertisers / domain resellers - these often use HTTP 301 redirects to a single "sales" page, so 301s can't be trusted. I can't think right now of a way to at least semi-automate this kind of checking, and hope someone else can. -- Philcha (talk) 15:48, 13 September 2008 (UTC)

Options 1 and 2 seem like too much overhead. Adding refs is difficult enough, with the tags and templates. Making people "register" their refs on a noticeboard would be way too much work. There's no way to make it mandatory, and if its optional, it will probably be rarely used. Option 3 has issues with copyright, and also storage capacity. Wikipedia probably has several million external links, even if only 1% are references, that's still tons of server space. In some cases, such as an online version of print media, maintaining a link isn't necessary. Its helpful, but only the details of the original publication are necessary. Mr.Z-man 16:09, 13 September 2008 (UTC)

I'm not suggesting a mandatory system, but an optional one for editors who wish to use it and have a concern that an important ref may go missing and thereby cause an invalidation of content. This would apply where the only available reference was online, not to a duplication of print media. If it is rarely used, then 1 and 2 will have very little overhead, but can fulfil an invaluable function in certain instances. The web archive often does not deep index pages or has a gap in indexing which misses out an updated page. It is also not possible to tell for 6 months or so whether it is in the web archive or not. I don't see this as being a problem for server space, as developers have said that should not be a consideration for policy, and their job is to make sure the technical backup meets the needs of the project. If it is a problem, they can tell us. The bottom line is that there can be a perfectly valid ref with important content that suddenly vanishes (this happened to me with The Times and, despite emails, I couldn't get it fixed). The content shouldn't be compromised over a technicality, which can be easy enough to fix. Ty 22:56, 13 September 2008 (UTC)

Server space shouldn't normally be a consideration for policy, but most policy proposals don't involve adding creating a massive database of text. Also, many newspapers remove articles from public access after a certain time, so that only people with paid subscriptions can read them. Bypassing this by storing an indefinite cache on our servers accessible to all seems like it would most certainly be illegal. Mr.Z-man 04:59, 14 September 2008 (UTC)

I was going to say this, but someone already did. Most proposals don't involve the sheer hugeness of disk space that you'd be talking about, especially if you're going to retain formatting. But, aside from that, remember that the content we are referencing is not free. It is written by someone with a copyright to that content; that is the bottom line, and we have to deal with it. We can't just copy other people's work without permission (even with permission, really, if we want to keep with our ideals) because it works best for us. Celarnor ^{Talk to me} 06:47, 14 September 2008 (UTC)

I agree with Z-man. 1 and 2 seem like they take far too much overhead, and option 3 isn't very likely to work in the US copyright system. Celarnor ^{Talk to me} 00:58, 14 September 2008 (UTC)

If you agree with Z-man, it won't take much overhead at all, because "if its optional, it will probably be rarely used," so it will be a resource to save some rare refs. The precedents for use in the copyright system have already been pointed out, namely google, web archive and web cite. Wikipedia is in much safer position than a commercial entity such as google. Do you have a an alternative suggestion to deal with this issue? Ty 04:01, 14 September 2008 (UTC)

Just a note, where Google and Internet Archive have court cases and specific exemptions (respectively), neither WebCite (to my knowledge) nor Wikipedia have either of these. I'd rather not get into changing Wikipedia into a resource for copyrighted full pages: Just use links to archive.org if you must. Kylu (talk) 05:34, 14 September 2008 (UTC)

That does not solve the problem of content created with valid refs that disappear and are not on archive.org. Suggestion 1 does not involve storing any material at all, and suggestion 2 only a minimal relevant amount. Ty 06:15, 14 September 2008 (UTC)

Do you really think your first suggestion would be of much use? I don't imagine very many people utilizing it; however, I do think that is the only remotely viable one of the three. Celarnor ^{Talk to me} 06:43, 14 September 2008 (UTC)

A 'solution' that opens the project up to civil suits from the owners of each and every external link cached in such a manner does not seem to be a solution in my eyes. Google has an exemption as a search engine; courts have specifically ruled that by putting your content up on the internet, you grant an implied license for purposes of locating your content via a search engine; I'm not familiar with the particulars of the IA case, but I imagine there are similar restraints regarding whatever implied license is granted for caching therein; Wikipedia would be using these for an express purpose outside of the scope of either one of those.

Please remember that that Wikipedia exists in the Real World (unfortunately, the United States), and we have to abide by whatever copyright laws, no matter how draconian, apply to where our servers are. We can't simply ignore them and store other people's content because it's convenient for us to do so. Celarnor ^{Talk to me} 06:43, 14 September 2008 (UTC)

I agree with the motivation, particularly re. pages describing modern technology, since they are likely to become obsolete and be taken down or changed. (How many web-based references will you find for the ISA bus these days? What about MCA?) However, is there a reason that the archives at archive.org aren't suitable or sufficient? Perhaps WF could work together with archive.org to ensure that the pages referenced here, even the specific versions referenced here, are archived. Could WP's software automatically add links to the archive.org copies of linked pages? Jeh (talk) 17:09, 14 September 2008 (UTC)

Archive.org is limited in that it won't necessarily cache the page you need, and that even if it does, the lag time before it becomes available can be critically detrimental; for example, an Edge ref went dead, and this affected 3 video game FAs; that was two months ago, and without a cache, we'd still be waiting for archive.org to (possibly) check it. Der Wohltemperierte Fuchs ^(talk) 22:59, 15 September 2008 (UTC)

That is why I suggested "perhaps WF could work together with archive.org to ensure that pages referenced here, even the specific versions referenced here, are archived." Let archive.org handle the copyright issues; they apparently are doing so already. Jeh (talk) 12:56, 18 September 2008 (UTC)

Yes, I proposed this in WP:VG. If there were a way to predict beforehand what the URL to an archive would be, then we could simply add the link to the future archived version when making the citation. SharkD (talk) 01:54, 17 September 2008 (UTC)

That is a good idea. However, my original motivation was because of a ref that had disappeared but was still available on google, although not necessarily forever. I don't think webarchive caches the whole of the google cache. Could the people above who have opposed the intitial suggestions kindly come up with a solution themselves. Or do we just watch refs slip away in these cases and delete valid content? There is a relevant discussion at Citing sources. Ty 01:33, 24 September 2008 (UTC)

FYI, a cache system was put in place on the French Wikipedia several weeks ago. It is provided by Linterweb, the company that operates the Wikiwix search engine. Briefly, external links added to articles are automatically cached; a link to the cached version is displayed near the corresponding external link (see Image:Capture-cache-wikiwix.JPG). Currently, only registered users can see these links by editing their monobook.js, but there's a vote to decide whether they should be displayed by default for all users. For more information, see fr:Utilisateur:Pmartin/Cache (translation) and fr:Discussion Wikipédia:Prise de décision/Système de cache#Le projet cache (translation). Korg (talk) 19:45, 26 September 2008 (UTC)

Some pages don't archive on WebCite. I've tried to use it to archive a google cache and it rejects it. Before we think about building what is essentially a duplicate of WebCite, it would be useful to know a bit more than that it does not archive 100% of what is requested there. If it accepts 99%, for example, then we should be thinking about an automated system (bot?) for archiving, and only after that is in place do we need to worry about the remaining 1%.

To me, the most challenging issue here is newspapers that put their stories on the web for free (with advertising) for only a limited time (sometimes as little as a week), and then sell access to the stories thereafter. Typically the URL changes; mostly (I think) the old URL doesn't even link to the new one (often because the archive sales site is a third party). Such stories are problematical because if Wikipedia keeps copies, the newspaper isn't going to be happy at all.

I think options 1 and 2 are non-starters. Option 1 would require a huge amount of editor time (time much better spent actually improving articles), and is likely to be plagued with a lack of endorsers (unless we really have a lot of people who want to do such drudgery), not to mention sock-puppet endorsements of bogus cites. Option 2 is an encouragement for egregious copyright violations. -- John Broughton (♫♫) 14:43, 28 September 2008 (UTC)

There is option 4, namely that if material is referenced and the ref link is later found to be dead, it is accepted that it was viable at the time the material was inserted and kept in place, maybe marked as "expired". The current system means that if a link goes dead and for some reason cannot be found elsewhere, then the information can be removed, which seems a nonsensical approach. I would like to point out that my initial suggestions were intended for exceptional cases, not to be applied across the board. Also, to avoid copyvios, for which concern has been expressed, cached references could even be deleted, so that they would be retrievable by admins if necessary. Ty 23:58, 3 October 2008 (UTC)

Then we would have vandals inserting plausible sounding hoaxes which we couldn't verify because they marked the info as having a source that expired. Abyssal (talk) 00:40, 5 October 2008 (UTC)

Do note there is quite a difference between "long-standing reference goes dead" and "reference added this morning is already dead". Anomie⚔ 02:30, 5 October 2008 (UTC)

Yeah, but how would that difference show up in the article itself? What aspect of the proposed change prevents some person from adding a hoaxed source and then immedately marking it as expired?Abyssal (talk) 10:10, 7 October 2008 (UTC)

What prevents someone from making up a quote from an obscure book, and so on? If you look in the history and see it was first added and marked expired on the same date, you would be suspicious. Or possibly more likely, people watching the article will see the addition in their watchlists and revert it right away. Anomie⚔ 15:55, 7 October 2008 (UTC)

Matters on wiki are often ones of judgement. That is the case here. If an established editor with a good record has used a ref and some time later it expires, having not been challenged in the meantime, then it would be counter-productive to start deleting material on that basis—especially if the person deleting obviously has a grudge against the article, a case which I have experienced. Ty 09:18, 10 October 2008 (UTC)

The ever growing list of stub templates & categories

Problem. We have this huge list of stub templates, which seems to ever grow longer, and is basically used to categorize "stubs". However we already have a category system, which as far as I can tell is perfectly fine (maybe not browsing them though, see below). So in essence we have two overlapping categorization systems which leads to duplicate work by the Wikipedians who perform the already pretty tedious tasks of handling new/raw articles. Besides, the stub categorization is not as comprehensive as regular categories.

Proposal 1.

• Divorce "stubs" from categorization. The relevant information is that the article is a stub, categorization provides the information for sorting.
• Improve category browsing, so filtering stubs in & out is possible.

I would also like to point out that assessment of articles is pretty much generalized now to all articles on Wikipedia thanks to many wikiprojects, yet stubs seem to be a special case, which leads me to another related proposal:

Proposal 2

• Harmonize the rating of articles. Stubs or featured articles, the idea is the same, it gives an indication as to the quality of an article. Sorting and browsing featured articles should be no different from sorting and browsing stubs. Withdrawn per NVO's rationale, I can see how that would not be viable. Equendil Talk 10:01, 25 September 2008 (UTC)

I leave the "how" aside on purpose for now, however Wikipedia:Category intersection might be relevant here. Equendil Talk 10:49, 23 September 2008 (UTC)

I agree with Proposal 1, and would support removing all the stub categories as soon as there is decent category-intersection browsing. Pseudomonas_(talk) 11:37, 24 September 2008 (UTC)

Second that. As for "harmonization", it requires an overhaul of present-day practice when a B grade is granted by a single editor at will, and A grades are issued within wikiprojects (very small groups). As long as this practice continues, there will be differences in treatment of different groups. I don't see how this can be remedied - there's too many A/B articles to be handled trough wikipedia-wide channels like FAR. It needs to be decentralized, so accept the inevitable. NVO (talk) 09:48, 25 September 2008 (UTC)

Agree with Proposal 1. The huge list of stub templates is a liability. We should only have one system of categorization. --Kleinzach 01:09, 6 October 2008 (UTC)

As pointed out below, Proposal 1 would make the whole reason for having stubs - to make it easier for editors to find them - unworkable. There are very good reasons for having two separate category systems, a stub one for editors and a permanent one for readers, and this proposal would render the work of editors looking for a reasonable number of articles to sort through in order to find ones they can expand impossible. It may be a chore to sort stubs in the current way, but removing that system would bee a giant step backwards for ease of editability. I would hope that your support of this proposal is not due to your recent run-in with WP:WSS, Kleinzach, but I would suggest that it became clear during that debate that you did not fully understand the reasons why stubs are sorted the way they are, and that could well be an explanation why you would think that Proposal 1 would work. It wouldn't - at least not in a way that would provide anything but a detriment to Wikipedia. Grutness...wha? 01:18, 6 October 2008 (UTC)

See Equendil's proposal above. A competing system of categorization makes it more difficult for content-contributing editors to locate and maintain sets of articles. I've worked with stubs on five projects - ranging from one with no stub types at all, to one with 40+ (see here) - so I've had a lot of experience of this. One of the problems with the WP:WSS is the assumption by that project that they understand categorization better than the editors who are actually writing the articles. --Kleinzach 02:13, 6 October 2008 (UTC)

Yes, it's Equendil's proposals I'm referring to. They simply won't work in the way that stubs do as far as enabling editors to find stub articles, for the reasons given below. And though you may have had a lot of experience at this, your recent discussions with WP:WSS made it clear you still don't really understand why stubs are sorted the way they are or how they are different from Stub-Class assessments. Equendil's propossals would work very well with Stub-Class assessed articles, but very poorly with stubs. As for WP:WSS's assumptions that they understand articles better than the wikiprojects working on those articles, there are two comments to make: 1) we don't - we regularly discuss the best way to split articles with the wikiprojects concerned (though it has to be admitted that sometimes these discussions have been accidentally missed), and 2) many, if not most, stub types are for areas in which there are no specific wikiprojects. Grutness...wha? 05:09, 6 October 2008 (UTC)

And many of them cover multiple projects creating other problems. --Kleinzach 05:18, 6 October 2008 (UTC)

To the best of my knowledge, no editor has ever brought a complaint to WP:WSS relating to problems causedd by a stub template being used by multiple projects - if they had we would have striven to find a way around such problems. Quite the opposite is the case, in fact, using the same stub type for several projects tends to help when those projects need to work together on articles. You did mention that you found problems with stub types in use on different projects during recent discussions at WikiProject:Opera, but IIRC it was quickly pointed out by other members of both projects how it was actually an advantage, and the split of stubs relating to opera went ahead to the satisfaction of almost everyone related to that project. Again, the proposals laid out by Equendil would work beautifully with Stub-Class articles, which do relate directly to individual WikiProjects; they would however be ineffective with stubs. Grutness...wha? 05:31, 6 October 2008 (UTC)

That's a mischaracterization of discussions elsewhere, but this is not the place for forensics. For the sake of other contributors, please keep on topic. --Kleinzach 05:48, 6 October 2008 (UTC)

My last sentence in the above, which pointed out again that the Proposal confuses and concatenates Stub-Class and stub, is exactly on topic, as it is an important point at the heart of the discussion on this proposal. As to the rest, I was simply replying to your comment about multiple projects using the same stub types - a comment which itself has no bearing whatsoever on the proposal, and is delightfully vague exactly what these supposed "other problems" are (problems which, as I said, have never been commented on at WP:WSS). If you would care to keep to the topic yourself, any responses I make will also be on topic. Grutness...wha? 07:41, 6 October 2008 (UTC)

It's not the purpose of the system of stub types to be "comprehensive". The purpose is to enable sorting of stub-sized articles into categories of reasonable size, according to their primary notability. In order for this to be reified from the permcats directly, one would need not only category intersection, but also category union -- in arbitrary combination indeed; one would need the categories to already exist on all the articles in question, and to have some way of indicating which of those categories are of primary topic-sorting significance. As none of those is presently the case, I don't see such an idea as being foreseeably viable.

Stub-tagging and stub-sorting is also not about "grading" articles in the sense of the ever-more-byzantine "1.0" classification system (which introduced the "stub class article" concept many years after the guideline-defined idea of a "stub", without ever actually clarifying if they were the same or not). Unless the idea is simply to abolish the one in favour of the other, I strongly suggest keeping discussion of the two separate. Alai (talk) 16:39, 28 September 2008 (UTC)

I agree - there is a large-scale misunderstanding over the several different uses the word "stub" has on wikipedia - the proposals above seem to be confounding two of them (stub and Stub-Class, which are entirely different things). Also, as Alai points out, the current system is designed primarily to provide stub categories of a size best suited to browsing by editors. Overhauling the system in the ways suggested would remove that and make the job of picking and choosing stubs to be expanded harder, not easier; an editor might have to search through several permcats to find even a handful of stubs on a relevant subject, whereas now every stub category, theoretically at least, should have between about 60 and 600 articles. Though stub-sorting is a chore, it does provide benefits for editors that the proposals would lose. Grutness...wha? 23:10, 28 September 2008 (UTC)

Support prop 1; this definitely annoys the heck out of me and I agree with the rationales provided. Der Wohltemperierte Fuchs ^(talk) 01:17, 6 October 2008 (UTC)

How about just assign these stub templates to the related WikiProject?

It seems to me that these are similar to WikiProject talk page banner templates, in that they indicate the "type" of article. The difference would simply be to not include the "word" WikiProject in the stub template text. (since it would be placed in mainspace.) So for example, WikiProject Comics places "Comics-related stub" templates.

So essentially, if there isn't a WikiProject, perhaps there shouldn't be a related stub template? - jc37 01:20, 6 October 2008 (UTC)

That would be terrible, and also completely unworkable - first you'd have to work out exactly what is and what isn't covered by a project (something often the members of a project can't decide), and then you'd have to accept that there would be a big pool of stubs that would never be sorted because they fall outside the aegis of every project. Even if you were to accept that, you'd have the problem of stubs which fall within the boundaries of several different projects, and also the problems that would occur when a new wikiproject forms, or when an established wikiproject becomes moribund. There's also the problem that has arisen in the past where editors not part of a wikiproject feel intimidated about editing a stub article if it is marked as being maintained by a specific WikiProject (as the banner templates say). It is vital that editors aren't put off improving articles and are actually encouraged to edit. Stub templates are worded in an attempt to encourage this. Assessment banners, though they do not actively discourage editing, can have this effect due to their connection with a "closed group of editors", i.e., a Wikiproject. Your comment about the similarity with Wikiproject banner templates is, however, true, and is exactly the point that has been made here - that people do confuse the two even though they are different systems. This project arose when assessment templates used "Stub-Class" as one of the assessment levels even though there was already a long-standing stub system in place that was unrelated to it - the system we are currently discussing. Grutness...wha? 05:41, 6 October 2008 (UTC)

Assigning stub templates to the related WikiProject would indeed be good and practical approach. --Kleinzach 02:19, 6 October 2008 (UTC)

Stubs are deliberately kept separate from all wikiprojects for the exact reason you outlined above - that quite often they are to be used by multiple projects. In other cases, there are no relevant wikiprojects for particular stubs. There is a perfectly acceptable system which is used by wikiprojects, but it is not stubs - it is Stub-Class articles, part of the assessment process used by individual projects. Grutness...wha? 05:41, 6 October 2008 (UTC)

What is a stub? Here is the definition used by the Version 1.0 Editorial Team:

The article is either a very short article or a rough collection of information that will need much work to become a meaningful article. It is usually very short, but can be of any length if the material is irrelevant or incomprehensible.

That's it. It's not a categorization system of Byzantine complexity. It's a short article. --Kleinzach 10:51, 7 October 2008 (UTC)

And thus you prove my point. What you've just described is actually a Stub-Class article, not a stub. The definition of a stub is at Wikipedia:Stub. It is through the confusing and conflating of these two completely different definitions that this proposal has been made and moch of the argument in favour of it has been made. As pointed out above, Stub-Class might well work very well with the proposal. Unfortunately, stubs (as defined at Wikipedia;Stub, would not. It would have been better had Stub-Class (often incorrectly shortened to "stub", as here, just to add to the confusion) been called something completely different when the assessment scheme was inaugurated. These points were alluded to by Alai, above. Unfortunately, to do so now would be to increase editors' confusion even more. Grutness...wha? 00:02, 8 October 2008 (UTC)

The definition of a stub at Wikipedia:Stub is:

A stub is an article containing only a few sentences of text which is too short to provide encyclopedic coverage of a subject, but not so short as to provide no useful information.

That's essentially the same definition as offered by Version 1.0 Editorial Team. --Kleinzach 00:32, 8 October 2008 (UTC)

Enable mw:Extension:Nuke

Meta recently had a poll that passed that permits small wikis to enable the mw:Extension:Nuke. Due to its size, the English Wikipedia was not included in the poll and the decision has been left to us locally if we would like to enable such a feature.

In short, nuke permits administrators to delete all the recent pages created by a single user. This feature would be especially useful with grawp and spammers and would be easier on the servers than current deletion scripts used by admins to fight grawp (as well as more accurate). So I'd like to start a local poll on the question of enabling the nuke extension here.

Support enabling

1. Obviously. MBisanz ^talk 12:16, 25 September 2008 (UTC)
2. This would be very advantageous for admins and developers alike; both reducing server lag and helping with the mass reversion of spammers and vandalbots. — ^.^ ^{[citation needed]} 12:55, 25 September 2008 (UTC)
3. Sounds like a good idea with no obvious negatives. -- Imperator3733 (talk) 16:35, 25 September 2008 (UTC)
4. Looks good to me. Shereth 16:43, 25 September 2008 (UTC)
5. I agree, this could be very helpful. Mr.Z-man 16:53, 25 September 2008 (UTC)
6. Support, definitely. - Rjd0060 (talk) 17:07, 25 September 2008 (UTC)
7. Support; nuke it from orbit, it's the only way to be sure. --—— Gadget850 (Ed) ^talk - 17:12, 25 September 2008 (UTC)
8. Mwawhawhawhawhaw... er, I mean Support... :D Happy‑melon 17:23, 25 September 2008 (UTC)
9. Giving nukes to 1500 random people on the internet? What could possibly go wrong? Support henrik•talk 18:00, 25 September 2008 (UTC)
10. Support. --MZMcBride (talk) 18:41, 25 September 2008 (UTC)
11. Though I'd be even happier if there was an un-nuke option as well. EVula // talk // ☯ // 21:41, 25 September 2008 (UTC)

    I'd like to amend my comment to say that I definitely think that a seven day limit would be a fantastic way of limiting inadvertent (or even malicious) abuse of the tool. EVula // talk // ☯ // 00:51, 30 September 2008 (UTC)

12. Support. I've always wanted to have my own nuclear weapon. So long as I don't have to have the demon core on my desk as well.-gadfium 22:08, 25 September 2008 (UTC)
13. Support, as long as I get to keep the football. Waltham, The Duke of 03:23, 26 September 2008 (UTC)
14. Support, per MBisanz (talk · contribs). Cirt (talk) 12:46, 26 September 2008 (UTC)
15. Support Seems like a good enough idea. –Juliancolton ^{Tropical Cyclone} 12:52, 26 September 2008 (UTC)
16. Support, this would be very helpful (and Grawp will die of radiation poisoning). ffm 12:57, 26 September 2008 (UTC)
17. Support with some upward limit on pages created. Protonk (talk) 18:57, 26 September 2008 (UTC)
18. And when it supports uploads, it'd be great on imagevio uploaders as well. MER-C 13:21, 27 September 2008 (UTC)
19. Support but I really think the software should be scripted to allow un-nuking with the same amount of work. It can't be that hard to code a reverse-option, all it has to do is undelete a list of articles which are hopefully logged to have been nuked. Or aren't they? I really think there ought to be a nuke log if they aren't. SoWhy 13:35, 27 September 2008 (UTC)
20. Support as a valuable tool against vandalism and spam, but at the same time if this is a problem, why not just put a common-sense restriction on article creation for new accounts, something like 1 article per day for the account's first 30 days or 100 edits, whichever comes last. Andrew Lenahan - Starblind 18:27, 27 September 2008 (UTC)
21. Support, provided that the tool is in fact limited to what is in the recentchanges table (as discussed below) - that is, is limited to new pages created by an editor in the past 30 days. With that limit, a rogue or compromised account isn't likely to be able to do much damage before being de-sysopped. -- John Broughton (♫♫) 00:44, 28 September 2008 (UTC)
22. Support, with John Broughton's proviso to limit the period to 30 days. In practice, that could even be reduced to 7 days or even less, since a spate of spurious creations is likely to be noticed by someone relatively quickly. Horologium (talk) 01:11, 28 September 2008 (UTC)
23. Support though a limit to 30 days would be good. Hut 8.5 11:03, 28 September 2008 (UTC)
24. Support but I do like the idea of some sort of time limit (Broughton/Horologium) Scottydude _review 13:10, 29 September 2008 (UTC)
25. Support, provided that the nuke button is big and red ;P. Seriously, though, this is a good idea. I agree that a limit to 30 days would be a good idea. _TalkIslander 10:17, 1 October 2008 (UTC)
26. Support with limit. And yes, an un-nuke option would be handy there too. Garion96 (talk) 12:01, 1 October 2008 (UTC)
27. support With the understanding that Nuke will be used only for the most blatant of vandalism and not in other situations. JoshuaZ (talk) 17:21, 5 October 2008 (UTC)
28. — Werdna • talk 00:45, 11 October 2008 (UTC)

Oppose enabling

1. Pending un-nuker or equivalent. We must have balance in the force. -- Ned Scott 03:28, 26 September 2008 (UTC)
2. Far too open to accidental misuse (or even deliberate misuse, in the unthinkable event that we ever get an admin who is less than entirely scrupulous in his regard for policy). DuncanHill (talk) 23:05, 26 September 2008 (UTC)

   Why are we letting a hypothetical situation that has never happened (to the best of my knowledge) stop us from effectively undoing situations which are all too common? EVula // talk // ☯ // 00:41, 30 September 2008 (UTC)

   I hope that's sarcasm... --NE2 02:38, 6 October 2008 (UTC)

   Echo the above. Considering the huge problem that it will produce when misused (and it will get misused, just as every other tool does), I'd rather not have it granted at all. Celarnor ^{Talk to me} 10:34, 6 October 2008 (UTC)

3. We make too many mistakes as it is. DGG (talk) 00:29, 30 September 2008 (UTC)
4. "Pending un-nuker or equivalent" as stated above -- Philcha (talk) 09:01, 6 October 2008 (UTC)
5. Too open to abuse, weak community oversight, difficult to undo, etc. Too many negatives, not enough benefit. Celarnor ^{Talk to me} 10:31, 6 October 2008 (UTC)
6. Per Ned, there needs equally automated way to revert this. — CharlotteWebb 11:02, 6 October 2008 (UTC)

Questions

Since we've just had several issues with admins recently, including socks, and an arbcomm case, I'd like to know how easy it would be to reverse this. So, would these also be undeletable as a group? - jc37 17:24, 25 September 2008 (UTC)

It would be added as a right to the admin group. Seeing as admins already have a large number of rights at Special:ListGroupRights and this feature can be duplicated by external software, there is really no more risk to an rogue admin with this tool than there is to an admin without it. Just that non-rogue admins will have an an easier time cleaning up with it. MBisanz ^talk 18:04, 25 September 2008 (UTC)

Let me clarify: If User:nuker (an admin) "nuked" three pages with the tool, is there an "un-nuke" version of the tool for undeleting all three simultaneously (the way they were deleted), or would they have to be undeleted one at a time?

This becomes even more "fun" when hundreds of pages are "nuked". - jc37 18:09, 25 September 2008 (UTC)

Currently, no, Mediawiki doesn't have an Un-Nuker, but many admins do have scripts that will do the same thing. So basically we'd be replacing Script-based Deletion and Script-based Undeletion with Software-based Deletion and Script-based Undeletion. MBisanz ^talk 18:16, 25 September 2008 (UTC)

Mk. Thank you for the clarification. While (presuming the trend continues) this is likely to pass, I think I'll stay neutral. Thanks again. - jc37 18:23, 25 September 2008 (UTC)

The successful detonation of a nuclear weapon above ground is invariably accompanied by a spectacular display of fireworks, which cannot be rewound (unless on video).

I don't know why jc37 finds this disagreeable, but I consider the parallel with real-world nukes quite poetic. :-) Waltham, The Duke of 03:23, 26 September 2008 (UTC)

Well, since you asked : )

A key thing about the existing "tools" on the wikis is that there is something of a "balance". Any action can potentially be undone by another action of presumably equal effort.

Well, that "balance" has been gradually changing as new scripting tools and extensions and so on have been added. The speed at which someone can take an action is not necessarily the speed at which someone can undo the action any more.

And even Arbcomm has spoken out in several decisions regarding fait accompli (which is a fair amount of what such tools can potentially be). Imagine that someone is bold and moves every article of a certain topic to a name of their preference, even though those articles were a part of a larger topic, and follow a different convention, and consensus is that this should be reverted. Now unless one also has AWB (which should not be presumed), then undoing this could be quite a task. And this is just one example. I honestly have seen far more examples of "personal preference pushing" using tools than we really should see.

And so if we now allow admins to mass delete pages, but there isn't a counter for other admins to undo that action, well, I think you see my concern.

That said, I'm doing some backflips bending over backwards to WP:AGF, and am attempting to hope for the best. And I do understand the value of admins having the ability. Hence staying neutral. - jc37 09:40, 26 September 2008 (UTC)

I'm inclined to share Jc37's concerns. Also, what is the definition of "recent edits" here? And does it only delete pages that have only one contributor or will it also delete pages that others have edited? What, for example, would happen if a rogue admin attempted to nuke in short order the articles created by Rambot and other editors with large numbers of contributions? The available documentation is not very clear about such things. older ≠ wiser 14:30, 26 September 2008 (UTC)

If this proposal is adopted, it should only be given to admins who pass RfA after its introduction, as RfA's prior to that will not have examined the candidate's perceived trustworthiness with such a powerful tool. Also, how about watchlisting this? It is a proposal for a massive change to admins' tools. DuncanHill (talk) 23:17, 26 September 2008 (UTC)

No it isn't, its not giving them the ability to do anything that they can't already do. Right now they'd have to go to Special:Newpages, filter it to show articles by the user in question and delete those pages. Mr.Z-man 15:38, 27 September 2008 (UTC)

Recent edits means everything that's in the recent changes (database) table. Entries in the table are set to expire after 30 days. MER-C 13:46, 27 September 2008 (UTC)

Is that documented somewhere? There is only the barest mention of "recent edits" at mw:Extension:Nuke. I'd be less concerned over implementing this if the scope is limited to only the past 30 days. older ≠ wiser 22:49, 27 September 2008 (UTC)

No, not really. If you can understand (at least vaguely) PHP, in getNewPages(String username) (view source) - which returns the list of pages to be nuked - it does a query against the recentchanges table. The lifetime of table entries is governed by $wgRCMaxAge, which is set to 30 * 86400 seconds = 30 days. MER-C 06:55, 28 September 2008 (UTC)

Thanks. Any clarification about my other main concern -- does this nuke only pages where there was one editor, or does it not check whether there were other editors? older ≠ wiser 16:53, 28 September 2008 (UTC)

I don't know. Sorry. MER-C 09:59, 29 September 2008 (UTC)

I am not a code-person, but it is enabled at Commons, so maybe a an admin from there can explain that question. MBisanz ^talk 17:07, 29 September 2008 (UTC)

I think if the developers can create a rollback feature for nuke, then that would be great. An admin can view the "nuke" log, and click on the rollback button, much like rollbackers rollbacking a page from the page's history page because of vandalism, it would work and look the same way. It would be a great idea to the developers. Techman224^Talk 02:57, 11 October 2008 (UTC)

See bug 15942. MER-C 02:47, 12 October 2008 (UTC)

Hm. Looks like this is going to be enabled. Now, what's the name of that bot that created 20,000 pages again? *requests adminship* -- Gurch (talk) 21:02, 30 September 2008 (UTC)

Alternate proposal

Since we are (rightly) worried that no easy way to "undo" this mess exists and we have had admin issues in the past. Let's instead give the nuke rights to 'crats. They are, right now, the vice presidents of the wikipedia world (presiding over the senate and going to state funerals). This gives us an easy way to have the functionality but restrict it to a very trusted group of people. Protonk (talk) 18:19, 26 September 2008 (UTC)

But this would be a fundamental change in the nature of what a 'crat does. The basic maintenance of the 'pedia, in the form of deletions/protections/etc is the domain and duty of administrators, and tools to that effect should pertain to them. If we do not trust administrators as a whole with a tool that pertains to administrative actions, then we should just not have the tool to begin with, rather than delegating admin duties upward. Shereth 18:29, 26 September 2008 (UTC)

That's fair. Protonk (talk) 18:56, 26 September 2008 (UTC)

As a bureaucrat, I don't think the nuke tool should be put solely in our hands (obviously we would have it as admins); our job is to ascertain community consensus, and our duties tend to involve user right modifications (promoting admins and other 'crats, bot flags), with renaming being outside of that. Nuking vandals is totally outside what we were chosen for, and limiting its scope to a dozen or so editors would severely limit its abilities (in a bad way). EVula // talk // ☯ // 18:14, 30 September 2008 (UTC)

18:46, 4 October 2008 (UTC)

Give it to Oversighters? There's usually one or two online at any given time and they're responsible, easy-to-reach and concerned with protecting the site from user-based abuse. ╟─Treasury§Tag►contribs─╢ 17:30, 5 October 2008 (UTC)

That's a much, much better idea. I don't like the idea of well over a thousand people retroactively having a new ability this strong granted to them. Celarnor ^{Talk to me} 10:33, 6 October 2008 (UTC)

If it's not too late for an idea, might I suggest implementing a new access level (perhaps called the "nuclear club") that has access to the nuke. Admins could be promoted to nuke status by bureaucrats based on input from both the admins and the community at large. Horselover Frost (talk) 08:40, 11 October 2008 (UTC)

Towards New proposal policy

Many community members strongly disagree with the current policy. We are proposing a modification of languages criteria to star a wikimedia project, with a community draft]. feel free to contribute with your opinion:

thak you, very much. — Crazymadlover

Re-enable searches in the user talk space

As some might now (though I suspect most don't), user talk pages are no longer indexed thanks to bugzilla:13890. This was cited as the conesnous for that change: Wikipedia:Village pump (proposals)/Archive 25#Stopping search engines from indexing the user talk namespace?

I think I speak for a lot of people when I say what the frak?

We've already got the __NOINDEX__ magic words that let us exclude pages if there's an issue. There's no need for this change and there's a lot of reasons to oppose. -- Ned Scott 02:58, 26 September 2008 (UTC)

• Support indexing as the nominator of this proposal. -- Ned Scott 02:58, 26 September 2008 (UTC)
• Oppose indexing per the inappropriate search results linked at Wikipedia talk:NOINDEX of noticeboards#Noindexing user talk space and other thoughts. Users sometimes post under their real names, and their user talk page may have "is biased editor", "is not notable" strewn all over it, which is not a good look and might harm unrelated people who happen to share the same name. About 99% of the content in the user talk namespace is fine; the other 1% should not be indexed by search engines. The Wikipedia search can be restricted to the user talk namespace like this. I concede that noindexing user talk space is less important than noindexing pages like requests for arbitration, which are much more likely to contain defamatory content. Graham87 03:32, 26 September 2008 (UTC)
  • Removing 100% of user talk pages for the sake of 1% is a really bad idea. Our internal search leaves a lot to be desired, and we can opt out of indexing on a per-page basis thanks to __NOINDEX__. -- Ned Scott 04:23, 26 September 2008 (UTC)
• Support indexing until evidence is presented that Googles access to the user talk namespace is systematically causing harm it should not be hidden, if a user does not want his/her talk page index they can use the "magic word" per Ned Scott. - Icewedge (talk) 05:46, 26 September 2008 (UTC)

• Support indexing, per my reasoning above (repeated here for reference): Having a full and complete searchable index of wikipedia should be the norm, and only in a few cases where demonstrated and repeated harm has come to the project or individuals, and we're unable to contain it with normal editing, should we use sweeping technical measures like this rather than the usual revert and ignore. So, in absence of evidence of concrete harm google indexing of these namespaces has caused, I don't see any reason for a blanket prohibition on indexing. [de-indexing is] a poor technical solution to a social problem. I'm not blindly opposed to de-indexing pages - there are some cases where it can be a practical solution, but I don't think we should do it on a whim and in the absence of demonstrated harm. Wikipedia should be open, warts and all. henrik•talk 08:24, 26 September 2008 (UTC)

• Support freedom of choice: The choice of having userpages/talkpages appear in Google should be up to each individual user, not applied unilaterally to everyone. (In case anyone cares; I have NOINDEX tags on my userpage and talkpage). ~ User:Ameliorate! ^{(with the !) (talk)} 08:52, 26 September 2008 (UTC)

• Oppose indexing (Support noindexing) - Honestly, I'm not sure what the concern is. Is this another round of: "But I wanna use my external search engine"? Or is there something more than this? - jc37 09:27, 26 September 2008 (UTC)
• Oppose indexing - user space creates an area that is largely unmonitored for libel and spam. Indexing it is only asking for problems. --B (talk) 12:54, 26 September 2008 (UTC)
  • What problems? There were no problems that couldn't be solved with our existing tools (blanking and NOINDEX magic word) for all of the years the userspace existed up until two weeks ago. Swing by WP:MFD sometime and see if your claim of being largely unmonitored is true. -- Ned Scott 03:50, 28 September 2008 (UTC)
• Oppose indexing - Agree with rationale provided by all the oppose comments above. Cirt (talk) 12:59, 26 September 2008 (UTC)
• Indexing is fine. Use the appropriate magic word if necessary. Stifle (talk) 15:23, 26 September 2008 (UTC)
• Oppose indexing - We shouldn't put the convenience of a relatively small number of users who would need this kind of information in Google results over people's real lives. I really don't buy the "but the internal search isn't good enough" argument for user talk pages. You're either going to be searching for plain text on the page, in which case it should be fine, or you're going to be searching for the username, which if it isn't a real word, Google isn't going to be able to do much better than MediaWiki. Mr.Z-man 16:11, 26 September 2008 (UTC)
  • I'd rather not believe that you are that ignorant about the shortcomings of our internal search. -- Ned Scott 03:50, 28 September 2008 (UTC)
    • I'd rather you give me some examples. What kind of cases do we need to search user talk pages, where the internal search isn't good enough but Google is? I can't even think of a need to search user talk space at all, besides possibly searching my own archives. Of course Google is better, they have 400000 servers to use for nothing but searching; I think we have something like 20 dedicated to searching. But you're talking like it doesn't work at all. From my experience, most of the complaints about the internal search are just people repeating other people's complaints without actually investigating it themselves. Mr.Z-man 17:29, 28 September 2008 (UTC)
• Oppose indexing I want more spaces de-indexed, not this. MBisanz ^talk 16:18, 26 September 2008 (UTC)
• Comment you can, actually, "opt in" to indexing by applying {{Index}} to your talk page. Protonk (talk) 18:16, 26 September 2008 (UTC)
• Oppose indexing - If user talk pages were indexed, those pages would flood Google results. I remember when I searched for my user name before NOINDEX was added, user talk pages filled the results page. With NOINDEX, there are much more relevant results. Besides, if someone was looking for a user on Wikipedia, wouldn't they want a user page as a result, not a talk page? -- Imperator3733 (talk) 18:37, 26 September 2008 (UTC)
  • They were "flooding" Google results before, and it was fine. -- Ned Scott 03:47, 28 September 2008 (UTC)
• Oppose indexing per all the very valid reasons above. It is not that difficult to use Wikipedia's search to search User_talk: and User: this proposal is merely about being able to use an external search engine for that. I understand that it is better but we would flood search results and put lots of content that isn't monitored like rest of WIkipedia out to a wider range of people. Scottydude _review 16:04, 27 September 2008 (UTC)
• Oppose indexing due to users' entitlement to privacy coming above all else. ╟─Treasury§Tag►contribs─╢ 16:17, 27 September 2008 (UTC)
  • What kind of ignorant dipshit posts to a public website and claims they have any entitlement to privacy of those public comments? If you go shouting out in the streets then you don't get to complain if someone notices you. If anyone here needs to post something in private then they can use e-mail or any number of alternative options. -- Ned Scott 03:47, 28 September 2008 (UTC)
    • Probably the kind of ignorant dipshit who posts nonpublic information or blatant libel about someone other than himself. Or the kind of ignorant dipshit who comes to Wikipedia and doesn't realize when first making an account that there are websites set up specifically to out and harass Wikipedians. Mr.Z-man 17:29, 28 September 2008 (UTC)
      • Excluding user talk from being indexed won't make those problems go away, and it's highly doubtful they'll even help the problems significantly. Libel information is found in the main article space, the main user space (drafts), and other talk namespaces all the time. I'm sorry, but we shouldn't be bending over backwards to the morons who post on the internet and are surprised when google finds it. My name was indexed on blog pages long before I ever became active on Wikipedia. Forum posts as well. Are you people new to the internet? You really have to be a fool to think that you have an entitlement to privacy when posting public comments on one of the largest websites on the internet. -- Ned Scott 03:28, 29 September 2008 (UTC)
        • I'm not, but many of our users are. Its getting hard to tell if this proposal is about our convenience in administering the project, or issuing a big "screw you" to new users, based on your recent comments. You might be able to attract more support if you didn't act so emotionally attached, calling users "ignorant dipshits" and "morons." And I'm going to assume that "You really have to be a fool" was just a general statement, and not aimed at myself... Mr.Z-man 04:30, 29 September 2008 (UTC)
          • Actually, most new users I come across know at least that much. Hell, my parents probably know better than to post anything private to the internet without being sure that it wasn't a public place. My point isn't to say "screw you", but rather my point is that the privacy issue only applies to an extreme minority. Rather than saying I'm emotionally attached, it's more of a case that I'm appalled at the lack of common sense here. I'm not saying that everyone who opposes indexing lacks that common sense, just the ones using rationales like "entitlement to privacy". I don't completely disagree with the idea, but I sure as hell know that no one is entitled to privacy on a public website.
          • I'm also appalled that this change was done on a whim and with no community support, and no one seems bothered by that. You might not have a problem with it when it's something you agree with, but there's nothing stopping people from filing bug reports that you disagree with, and not being able to do a damn thing about it. -- Ned Scott 10:02, 1 October 2008 (UTC)
          • Z-man, I don't know why it is that in every debate I'm in with you, you always assume the wrost from me.
            • When you use terms like "ignorant dipshit" and say things that could possibly be construed as calling several users commenting here (including myself) fools, I'm not sure what you want me to think... Mr.Z-man 16:59, 1 October 2008 (UTC)
              • Well.. I.. ok, I see your point.. Getting worked up in all of this does hurt my point, and I've made a lot of rude comments. My apologies, if that means anything. -- Ned Scott 23:45, 6 October 2008 (UTC)
• Oppose indexing What needs to be indexed by external search services is the encyclopedia, not the mechanics of making it. We can develop our own wp-internal indexes for that. Not just a matter of privacy, but of avoiding confusion. DGG (talk) 00:27, 30 September 2008 (UTC)
  • Yeah, good luck with that. -- Ned Scott 10:02, 1 October 2008 (UTC)
• Oppose indexing. Since, as Protonk points out, you can still cause pages to be indexed by use of the appropriate template, the question really becomes what the proper default should be for external search engines in user space. On balance, I do think that it is better to take this personal content, some of which includes working copies of articles that are not yet intended for article space, out of the search results. Xymmax ^{So let it be written} _{So let it be done} 15:07, 30 September 2008 (UTC)
  • User space is still indexed. -- Ned Scott 10:02, 1 October 2008 (UTC)
    • It should also be non-indexed by default. Reyk _YO! 20:41, 1 October 2008 (UTC)
      • I've put {{index}} on my user page pre-emptively, in case your position ever wins out. <brrrrr> scary thought! ^^;; --Kim Bruning (talk) 11:08, 4 October 2008 (UTC)
• Oppose indexing - gang, we have enough reputation problems already, without the nonsense that fills so many talk pages being splattered across the search engine results. --Orange Mike | Talk 19:02, 30 September 2008 (UTC)
• Oppose Indexing- anyone who wants to opt in can do so by using the appropriate template; privacy should be the default. Reyk _YO! 05:53, 1 October 2008 (UTC)

  How does not indexing user talk space help privacy, can you explain? (Aren't those pages still published on the public internet?) Why is privacy actually desirable on wikipedia, according to you? --Kim Bruning (talk) 11:06, 4 October 2008 (UTC) There are several people I know who refuse to answer e-mail, because they prefer to have their discussions on *public* talk pages. Hmmm, If those same people are exceptionally paranoid about it, would they now refuse to post to user talk as well? I wonder about that! :-)

• Oppose as user space is not a forwards facing space but an internal space. Hiding T 13:51, 1 October 2008 (UTC)
• Indexing please - people need to stop seeking solutions to problems that don't exist. –xeno (talk) 14:41, 1 October 2008 (UTC)
• Oppose indexing - When they were indexed these pages often came out highly placed in Google search results. That runs directly counter to the entire 'Wikipedia is not MySpace' philosophy. I even recall a recent article about a reporter who found that there was a, rather 'colorful', Wikipedia user with the same name as them... whose Wikipedia page came out as the top search result on the name. Wikipedia content should be indexed. The rest of it should not. Especially not userspace. --CBD 15:24, 1 October 2008 (UTC)
• Oppose Indexing There is no need for the vast majority of internet users to be able to search anything other than the article, portal and maybe image spaces, and there is really no need for them to see any of the talk spaces. Nobody should be sent to a user talk page by google. The inconvenience to a few thousand editors is not worth cluttering up the search results for millions with irrelevant information. Jim Miller ^{See me | Touch me} 17:36, 1 October 2008 (UTC)
• Oppose Indexing We're here to offer the convenience of an encyclopedia to the public, and that's it. There is no benefit to the public of allowing indexing of talk pages. As has been mentioned ad nauseum on a dozen conversations across a dozen dozen pages, unless BLP and standards involving living people (including editors themselves) are as rigorously enforced on talk pages, talk page archives, or any derivatives, we can't present this in "public" via anyone-can-find-it-search. It's too dangerous, reckless, and irresponsible. If there is still a problem with our internal search engine, for internal user-use, then that discussion or consideration has absolutely nothing to do with this no-indexing. That's a question of why volunteer developers are doing things other than fixing our broken search engine. rootology (C)(T) 13:24, 2 October 2008 (UTC)
• Oppose Indexing Dud idea, if you ask me... Can think of a good reason why I would want to search for my own (or somebody else's) contributions using Google. I can think of even fewer to allow the whole world to search for my contributions to talk pages and user-space articles. These spaces should not be indexed, FULL STOP. It should not even be an opt-in process. The nominator's convincing rationale was "what the frak"... I don't think I need to say any more. Ohconfucius (talk) 13:58, 2 October 2008 (UTC)
• oppose indexing Internal search has gotten better as of late and if there is any user space that has lots of issues it is probably user talk space. If we are going to go down this road in general then this might even make more sense than AN and ANI. JoshuaZ (talk) 21:37, 2 October 2008 (UTC)
• Oppose indexing. While in the end it's up to the user to make sure any privacy-invasive or otherwise dangerous material is not kept on their Talk page, not everyone is patrolling their talk pages every day; the chances of someone posting something on a talk page -- a personal attack, a posting using personally identifiable information, etc. -- is too great. As Ohconfucius says above, there's no use to be had in allowing a talk page to be indexed anyway. Many online forums -- Yahoo Groups comes to mind -- don't allow indexing of their pages; Talk pages, especially user talk pages, are often of the same principle as forum pages, and shouldn't be indexed, either. 23skidoo (talk) 05:55, 3 October 2008 (UTC)
• I'm strongly in support of indexing of user and user talk pages. I've undone the archiving of the discussion because something can only be snowballed if it's (virtually) unanimous, and that's not the case here. Besides, I have very strong reasons for having userspace google-able as well.

Part of the implicit social contract of a collaborative project such as wikipedia is that it contributes to a persons' online reputation. We have precious little to reward (or punish) our users with as it stands.

User: and User talk: are two places where outsiders can find out about a person's value to the project. You can tell I might be someone who relies on my online reputation, because I'm using my real name.

Having your name explicitly linked to your actions, or prone to retribution is also something that keeps an awful lot of people honest. Google acts like a kind of third-party oversight.

Wikipedia is a public location. Everything you do is public, with all the privileges and responsibilities that entails. So it has always been, so it should stay.

Whatever the ultimate decision, however, I'll be adding {{index}} to all my user and user talk pages over time. I think I've built up a few of those over time ^^;;

--Kim Bruning (talk) 10:44, 4 October 2008 (UTC) And... done that <ouw my poor wrists :-(>

Kim, I appreciate the sentiment but is there any real evidence that anyone cares enough that they would not create problems because of this worry? I suspect that most real troublemakers won't ever be involved enough to find out what our policy is in regard to page indexing. JoshuaZ (talk) 23:22, 6 October 2008 (UTC)

Another issue

Regardless of who supports what, is anyone else bothered by the fact that this change was first made without any real discussion? I know we don't want to give the devs grief over stuff like this, which is most likely a misunderstanding (AGF), but we really need a better way of dealing with these kinds of changes. -- Ned Scott 03:56, 28 September 2008 (UTC)

• I think it is unfair to say there wasn't discussion, because I can remember reading discussion on this point all the time I've been here. However, I agree that perhaps we do need to centralise these discussions better, and that bug reporting and interface tweaks can have ramifications that merit discussion. Hiding T 13:51, 1 October 2008 (UTC)
  • What I meant was that there was only one cited thread, and in that thread there really wasn't any discussion. -- Ned Scott 02:33, 7 October 2008 (UTC)
• Agreed, there was hardly consensus for the change (at the time). –xeno (talk) 14:41, 1 October 2008 (UTC)
• Actually, we HAVE a centralized place for these kinds of discussions... Bugzilla itself. Unfortunately, most people don't keep an eye on that. Might make sense to have a local page listing recent suggestions so people know to go there and comment. Maybe a column in the 'signpost' or part of the existing B.R.I.O.N. column. --CBD 15:24, 1 October 2008 (UTC)
  • Please God do not use Bugzilla as a chat forum. It is most definitely not intended to be used as such. A board like this one is where discussion about changes to the project's configuration should take place, with possible cross-posting to other places. --MZMcBride (talk) 15:46, 1 October 2008 (UTC)
    • We can have all the discussion we like on Wikipedia, but if all the developers see is the request on Bugzilla then that's all they have to go on. Ultimately, somebody has to go there and say, 'please do not do this because it has problems X, Y, and Z'. --CBD 16:42, 1 October 2008 (UTC)
      • Right. The correct procedure is having all the discussion about a new proposal or configuration change here or on a similar noticeboard. And then when ready, someone files a bug with the 'shell' keyword and links to the oldid of the on-wiki discussion. And, within two hours or two years, a sysadmin will resolve the bug. :-) --MZMcBride (talk) 02:25, 2 October 2008 (UTC)

early close comments

moved from above, since the discussion has reopened

I'm closing this now as it seems to be snowballing. It seems like the widely held consensus is that User talk: pages should remain noindexed as was set by the developers. While there may or may not have been consensus for this at the time, it's clear from this discussion that the majority of interested users are uncomfortable with the indexing of these pages for a wide range of reasons, including but not limited to: confusion between people; confusion between encyclopedic content and userspace content; privacy and "outing" concerns from attack sites; lack of need due to built-in search functions; etc. While it is true the outing concerns do not happen often, they do occur often enough that we regularly see otherwise good editors leave the project due to what essentially boils down to blackmail in the loosest of terms (I do not intend to make any sort of legal accusation/threat/statement with that comment, that is simply my personal observation on previous matters). Removing these pages from Google will not stop that (and I notice nobody said that here), but it will certainly slow it down, as well as address many of the other concerns raised about indexing.

If a user wishes to have their usertalk page indexed by search engines, they are entitled to do so by adding the template {{INDEX}} to their user talk page. This will override $wgNamespaceRobotPolicies and grant access by search bots to your talk page. Some time should be allowed after the addition for the googlebots to get around to finding it again, but ideally the page should be searchable by external engines within a week or so. Naturally, users should not add this template to any page but their own; this is a personal choice, and users have the right to decline search indexing if they wish. Since the great majority of those here are declining it, the default will remain as-is; noindex. Hersfold ^(t/a/c) 21:17, 3 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. [1][2][3]

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

• Template:RFCstyle

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

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)

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 here instead. MTC (talk) 18:01, 12 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)

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 [4], 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)

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)

Category required prior to creation of article.

Category:Uncategorized pages is growing every day, and even with such excellent tools such as HotCat, it can be difficult to manage. I think categories are important on wikipedia for organisation and mantainance as well as article-hopping for the average reader. Is there perhaps any support for a system where a warning/marker pops up on any article being created without categories that, while not interfering with the editing windows, reminds the editor that they have not added any categories yet? It might just help cut down on the number of category-less articles out there. SGGH ^speak! 13:19, 2 October 2008 (UTC)

I have concerns with a system like that being non-user-friendly for naive editors. I'd rather let more experienced people add the categories. Is there a good tool written to ease the process of going through the list of uncategoried pages? Many of them seem to be biographies, which should be relatively easy to categorize. — Carl (CBM · talk) 14:16, 2 October 2008 (UTC)

I agree with CBM that it's undesirable to deter new editors - if we do, Wikipedia will stagnate. Articles will need to re-categorized anyway, since their scope increases as they grow. We also need a better "add category" tool: no automatic entry in the text box of whatever happens to be highlighted in the dropdown/popup menu; multiple selection to avoid having to wait for the page to refresh after each category is added; and preferably more information about what each category is meant to contain; and ideally a true search facility, as new users will not necessarily think of the first word of the right category. -- Philcha (talk) 14:42, 2 October 2008 (UTC)

Nuh-uh. Having a lot of information with some of it uncategorized is better than having less information but all categorized. This is way too creepy and probably only going to serve as a deterrent to contributions from newbie editors. Better that someone have to step in after the fact and tack on a category or two, than to have never had the article in the first place due to a lack of categorizing. Shereth 22:15, 2 October 2008 (UTC)

Perhaps it might be a good idea to place an indicator on special:newpages that would show that a given page was uncategorized? I don't think that could be done easily with .js, so that would have to go to the devs (even then, I don't know that it would be easy). --Izno (talk) 06:22, 3 October 2008 (UTC)

Would it be easier if there was a newpages patrolling bot tagging them with {{uncategorized}}? Not my favorite cleanup template when issued by a human being, given how trivial it is to at least find a relevant but imprecise top-level cat to start out with, but it might help some, if it isn't already happening. (I haven't seen it lately.) MrZaius^talk 08:36, 3 October 2008 (UTC)

So long as said bot didn't actually tag the pages as being patrolled, I think that might be helpful. I'm pretty sure there is a category WikiProject, so they could be notified? --Izno (talk) 13:41, 3 October 2008 (UTC)

That would be Wikipedia:WikiProject Categories, though the task force handling uncategorized articles is probably most relevant. -- John Broughton (♫♫) 23:29, 3 October 2008 (UTC)

• Nope Process creep. Categories help build the web. We would wish that new and IP editors would do that, but it is usually the province of regular editors. I think if we had a better category system for selection we would see fewer uncategorized pages (think of the upload screen on commons), but that would be a feature, not a restriction. Protonk (talk) 05:05, 5 October 2008 (UTC)

• is there any reason why the initial state of a new page isnt "uncategorised" instead of just having that "+" in there? that might indicate more clearly to a newbie that there was something to be filled out. cheers Mission Fleg (talk) 04:51, 7 October 2008 (UTC)

• A newbie may not know the correct category and may put it in the wrong one if forced to. It'd actually be better leaving them on the workpile so someone who knows that area of work can categorise them appropriately. A gentle reminder so those who *do* know the categories can act accordingly wouldn't go astray, though. Orderinchaos 09:14, 8 October 2008 (UTC)

• i'm not suggesting they be forced to i'm only suggesting that instead of having that '+' in there you have "uncategorised" in there exactly as if it had been tagged. thats effectively what happens now except a bot does it at some future point (might be seconds might be days) so why not have it start that way. Mission Fleg (talk) 09:49, 8 October 2008 (UTC)

• If we think that new page creators are capable of finding one or more good categories, then I think that the best solution is to use a bot to post a note on their user talk pages, telling them that more people will find the article if they add one or more categories to it. (The same bot might check for a WikiProject template on the article talk page, and, if missing, suggest to the article creator that adding such would be useful.) A bot doesn't require new (developer) code, and is easily modified (perhaps several different messages could be tried, to see which one seems to work best). -- John Broughton (♫♫) 17:00, 9 October 2008 (UTC)

The solution is to make adding a category easier. Look at what Commons does with its images.. — Werdna • talk 00:43, 11 October 2008 (UTC)

Scale sizes on images as addition to resolution.

From Freenode/#wikipedia <KordeX> hello, i have a suggestion for image handling: the scale automaticly to be calculated from size like 16:9 and so on. It would display on page-page just next to HeightxWidth This is a very easy patch for the base. (Mikko Kortelainen)

Improvement week(s)

Sorry, this random thought popped into my head the other day and I thought I'd entertain it. First question: is there any technical way to implement a wiki-wide freeze on article creation? If so, I just think it would be interesting and helpful if Wikipedia had "improvement weeks", where an article creation freeze was put into effect and instead directed people to improve bad articles or send them to AfD. After all, we're shooting for quality, right? Der Wohltemperierte Fuchs ^(talk) 13:14, 3 October 2008 (UTC)

I think a lot of people creating articles would just do nothing, rather than move over to improving article, however the main benefit to your idea would be that it frees up the people doing new pages patrol for other tasks. I'm not sure that's worth the inevitable loss of contributors caused by restricting what they can do. --Tango (talk) 15:37, 3 October 2008 (UTC)

It would also free up admins who delete more than a thousand pages per day, primarily after CSD nominations. But I doubt that you'll get consensus on this (so whether it can be technically done is somewhat irrelevant), if only because some new articles are in response to breaking news. (As an aside, please note that wiki and Wikipedia are not synonyms.) -- John Broughton (♫♫) 23:26, 3 October 2008 (UTC)

It would be easily possible by adding "." to the TitleBlacklist. However I'm certainly not going to be the admin who does that :D Happy‑melon 15:31, 4 October 2008 (UTC)

Wikipedia and wiki are indeed different terms, Mr Broughton, but I'd like to note that Wikipedia and Wiki are probably synonymous. At least that's what I've learnt in Roger Ebert's blog, hehe. Waltham, The Duke of 05:28, 10 October 2008 (UTC)

Why do you want to drive new editors away? Little Red Riding Hoodtalk 20:58, 5 October 2008 (UTC)

This has been proposed in various forms in the past, up to and including locking down all but the most critical project-space pages. The usual rationale for rejection is that most people would just not contribute during the time, rather than feel forced to do something that they really don't want to do. Many would go and improve articles, but it isn't really worth the overall loss of productivity and the potential loss of new users. Mr.Z-man 02:35, 6 October 2008 (UTC)

Bad idea. Sometimes improving an existing article involves creating a new supporting article, e.g. I created Crurotarsal to support Archosaur and Evolution of mammals. Suture (anatomical), which I also created to support Archosaur, is now rather popular. -- Philcha (talk) 08:58, 6 October 2008 (UTC)

Wikipedia: Common Sense guideline

The idea for this proposal came to me while at Talk:Sandwich. An argument over there was about if a sandwich required leavened bread to be classified as such. This struck me as very odd, as I know that a sanwich is a bit of food between to bits of bread. Even a (wise) proposal by an un-involved user was ignored. This got me thinking about a new guideline: Wikipedia: Common Sense. Here's my (rough) draft:

Wikipedia:Common Sense

Sometimes users can cite policies so much down the slightest wording, that it causes uneeded argument.

E.G. This article states that "milk is milk". It does not cite a reliable source that states that milk is milk. -Mr.Verifiability

These arguments an become long, tedious, and, due to stuborness on both sides, are very diffcult to resolve. The solution is to use common sense.

E.G. Because it is a generally accepted fact that milk is indeed milk as evidenced by the name, among other thing, and there has been no known soures stating that milk is not milk, the article should state that milk is milk. -Mr.CommonSense

This does not mean that all, or even most facts can go uncited. It simply means that basic facts, supported by common sense, do not need to be cited.

There it is. [[User:Tutthoth-Ankhre|Tutthoth-Ankhre~ The Pharaoh of the Universe]] (talk) 19:12, 3 October 2008 (UTC)

Support

1. Support My propsal. [[User:Tutthoth-Ankhre|Tutthoth-Ankhre~ The Pharaoh of the Universe]] (talk) 19:12, 3 October 2008 (UTC)

Oppose

1. We shouldn't need a rule that tells people to use common sense, they should just ... use common sense. That being said, something like this is also open to abuse. One person's common sense is another person's fringe theory POV. Mr.Z-man 19:16, 3 October 2008 (UTC)
2. Mr. Z man says it all. No need for something like this, and it will be misused. Protonk (talk) 05:06, 5 October 2008 (UTC)
3. I imagine that if an explicit "common sense" exception was added to WP:V we would probably observe some creep as to what counts as "common sense". It is much better to simply leave it unspoken that common sense always applies. For all means make it a user essay if you want though, it's not a bad point but I don't think we need another guideline that really brings nothing new to the table and would be heavily prone to abuse. - Icewedge (talk) 07:03, 5 October 2008 (UTC)
4. Common sense is culture-dependent. Obviously, not everyone has seen a sandwich in his life. -- Taku (talk) 02:17, 8 October 2008 (UTC)
5. I believe that would work in theory but fail in practice due to the opposes outlined above. Foxy Loxy ^Pounce! 07:32, 12 October 2008 (UTC)

Commenting

1. One thing I've learned is that common sense is uncommon. Begging the question won't make silly people sensible. - Denimadept (talk) 19:30, 3 October 2008 (UTC)
2. It would be nice to have some sort of common sense guideline. Like this one, Wikipedia:Common Sense. Better still, this one, WP:Ignore all rules. In general, people do use common sense whilst editing here, and for those who don't, telling them to do so probably isn't going to help. Really the best thing to do in a situation where people are being pedantic about the rules, is to point them to IAR and hope that they get it--Jac16888 (talk) 20:06, 3 October 2008 (UTC)
3. As Jac16888 has pointed out, we already have a number of pages that discuss common sense. You'll find more at the "common sense" topic in the editor's index. -- John Broughton (♫♫) 23:22, 3 October 2008 (UTC)
4. While I like the idea, I suspect this guideline would take the prize for the most universally ignored guideline on wikipedia (and that's saying something...). --Ludwigs2 02:24, 8 October 2008 (UTC)

Wikipedia:Tip of the day/August 31, 2006 is the same as Wikipedia:Tip of the day/August 31

Why do we have duplicate pages here? GO-PCHS-NJROTC ^(Messages) 01:51, 4 October 2008 (UTC)

The "tip of the day" is a rotational list of 365 tips, so you may well see the same tip on August 31, 2009. I'm not sure why there is a 2006 page and also a 2007 page - Wikipedia:Tip of the day/August 31, 2006, but not a Wikipedia:Tip of the day/August 31, 2008 page, but it's really irrelevant - Wikipedia is not a paper encyclopedia, and it actually takes more server resources (not to mention human time) to delete a page than to simply let it exist (ignore it). But if you really, really want to know, and the matter isn't explained at the page Wikipedia:Tip of the day, then ask as Wikipedia talk:Tip of the day. -- John Broughton (♫♫) 13:48, 4 October 2008 (UTC)

Random Article Within a Category

I've always loved the idea of the random article button, but it never takes me anywhere interesting. So, I thought it would be awesome if readers would be able to get to a random article within a specific category with similar ease and convenience to just clicking the random article link. If that were to be implemented it would definitely be a feature I would use quite a bit. I'm surprised that no one seems to have proposed it before (or have they?). Abyssal (talk) 17:02, 4 October 2008 (UTC)

For sure it is a good idea, I think software features are meant to be requested on bugzilla and there is already a bug filed for this proposal: Bug 15834.--Commander Keane (talk) 09:19, 5 October 2008 (UTC)

Contributing to wikipedia without keeping to formal prerequisites

Being able to enter new pieces of information or corrections into the respective articles' editors and submit them to an area within wikipedia where wiki editors wikify what has been sent (instead of altering the article instantly) might attract those people to the wiki idea who are willing to share their knowledge, but do not want to deal with wikipedia's formal prerequisites.--Emaster82 (talk) 22:42, 4 October 2008 (UTC)

I second this and pose a related suggestion; I also think there should be some way for casual readers to be able to submit questions or requests for information that they wanted to find in the article, but couldn't. This could give editors ideas on what articles need and could give us some direction in cases where we thought an article was comprehensive but notwas actually not meeting the needs of our users. Abyssal (talk) 00:35, 5 October 2008 (UTC)

I would encourage editors who are looking for information – especially information that ought to be in our articles but isn't – to visit Wikipedia's Reference Desks. Not only are the volunteers there generally very enthusiastic about returning rapid answers to questions, but many of us also try to fill in gaps we find based on questions we received. (Explicitly noting that an article is missing info is always helpful, too.) There was a formal project to encourage this effort (Wikipedia:WikiProject Reference Desk Article Collaboration), but I get the impression that most editors just go ahead and do it without any formal framework.

Notes or questions regarding missing information might also be placed on article talk pages, but very few articles have closely-watched talk pages.

Most article prose contains relatively little markup, and one doesn't need to know anything about markup to make small corrections or additions. (An unwikified paragraph or two here and there is no great crisis, and someone will be along eventually to straighten it out.) Neophytes should be encouraged to post requests for assitance to the Help Desk; editors there are glad to offer advice, and are also willing to step in to fix any formatting problems.

New articles are often created in a somewhat, or completely, unwikified state. If the prose is serviceable, someone doing new page patrol usually fixes up the new article (formatting, wikilinking, categories, stub notices) inside of an hour or two. I don't think we need a formal process for dealing with unwikified new articles, as we already seem to be coping well. TenOfAllTrades(talk) 02:04, 5 October 2008 (UTC)

I'm very pleased with the answer above and now too think that creating an extra area for wikifiying purposes is unnecessary.--Emaster82 (talk) 17:42, 5 October 2008 (UTC)

How about just putting the note on the article talkpage? Kylu (talk) 04:29, 5 October 2008 (UTC)

There are also templates Template:Expand and Template:Expand-section for this task. --Martynas Patasius (talk) 19:19, 5 October 2008 (UTC)

I don't think non-members and passerbys know how to use Wikipedia's template system. Abyssal (talk) 22:13, 8 October 2008 (UTC)

Moving infoboxes from articles to the Template: namespace

Currently, when a new or experienced user hits "edit this page" on a page like Microsoft, this is what they see. It's a mess. It's confusing. And it's horribly incomprehensible for a lot of users.

I'm proposing that we move infoboxes to subpages of their respective templates and incorporate "view - talk - edit" links into the boxes themselves at the bottom. So, for example, Microsoft's infobox would be located at Template:Infobox Company/Microsoft and Template:Infobox Company would be modified to have "view - talk - edit" links at the bottom of it.

Over a year ago, I converted some of the chemical element infoboxes to a subpage-type format and editing of the articles is now much more user-friendly. Compare: previously to now.

Thoughts, suggestions, comments, concerns? --MZMcBride (talk) 04:09, 5 October 2008 (UTC)

Wish I could think up something that clever. o.o Kylu (talk) 04:14, 5 October 2008 (UTC)

Offhand, it makes more sense to me for infobox templates filled-out with article-specific details to be article subpages instead of being template subpages. -- Boracay Bill (talk) 04:17, 5 October 2008 (UTC)

That'd be fine, except there are no subpages in article-space. A page like OS/2 is indexed in special:random (making it an article), whereas User:OS/2 would be one of User:OS's subpages. Kylu (talk) 04:28, 5 October 2008 (UTC)

While I think a complete redesign of how templates like infoboxes work would be ideal, that's a long, long way off. This would be good in the meantime. Mr.Z-man 18:19, 5 October 2008 (UTC)

This would make it more complicated for the people that know what they're doing, and not only in obvious ways. Someone fixing links to disambiguation pages might have to click through to the infobox. Someone updating a headquarters city will need to make two edits, one to the article and another to the infobox template. If the infobox name is based on the article name, it will have to be moved if the article is moved. --NE2 18:34, 5 October 2008 (UTC)

Why don't we just put overly complex infoboxes in subpages (Microsoft/Infobox in this case)? By definition, an infobox about a single company isn't a template anymore; it's encyclopedic content. If someone happens across one with Special:Random, big deal; we can just put a noinclude tag around the explanation that it is used on Microsoft. If someone is confused by that, I'd be surprised if they have the mental capacity for editing anyway. :) EVula // talk // ☯ // 21:10, 6 October 2008 (UTC)

That wouldn't work since article space doesn't have subpages. -- Imperator3733 (talk) 21:52, 6 October 2008 (UTC)

---

I'm proposing that we move infoboxes to subpages -- MZMcBride

it makes more sense to me for infobox templates [...] to be article subpages -- Boracay Bill

Why don't we just put overly complex infoboxes in subpages (Microsoft/Infobox in this case)? -- EVula

Great suggestion! Anything that reduces line noise and preserves the wikitext spirit of being quick and easy to edit gets my vote.

That wouldn't work since article space doesn't have subpages

It does work (see here and here). OK, it's not technically a subpage i.e. there's no backlink to Microsoft, but it's otherwise the same. The only caveat is that the infobox must be transcluded as {{:Microsoft/Infobox}} rather than {{Microsoft/Infobox}}.

chocolateboy (talk) 10:44, 7 October 2008 (UTC)

And it will also show up as an article on places like Special:Random, and will be counted as an article for the article count on the main page. Mr.Z-man 12:48, 7 October 2008 (UTC)

And it's another page for vandals to attack and users to have to watchlist. Der Wohltemperierte Fuchs ^(talk) 12:54, 7 October 2008 (UTC).

Separate pages also make it difficult to maintain named references (very commonly used when details in an infobox are duplicated in the box). I think the better solution is to standardize the way the infoboxes are presented in article bodies, using the "lined up on equals sign" approach so that it's clear its a special function. --MASEM 13:17, 7 October 2008 (UTC)

All good points. Still, I'd suggest keeping it that way for a while. More people are likely to spot the change in the Microsoft article than are monitoring this discussion, and they can weigh in here. It's easy enough to CSD the subpage if that's the consensus.

I think the better solution is to standardize the way the infoboxes are presented in article bodies, using the "lined up on equals sign" approach

Yeah. I've tried to do that (here for instance). It works well for uncluttered templates like that, but the Microsoft infobox is full of references and nested templates, which end up line-wrapping, so the unreadability is hard to avoid.

chocolateboy (talk) 13:31, 7 October 2008 (UTC)

Namespace aliases

We use a variety of shortcuts to important pages on-wiki, to save ourselves typing a few characters; these invariably involve shortening the namespace prefix to an acronym. We call common namespace abbreviations 'pseudospaces' because they refer to namespaces that don't actually exist: the pages are created in the mainspace and their corresponding talk pages are "Talk:ABBR:Foo" rather than "ABBR Talk:Foo". A while ago the developers, having written the necessary underlying code, made the "WP:" prefix an actual alias of the "Wikipedia:" namespace, and similarly for "WT:" and "Wikipedia talk:". So typing "WT:FOO", you would immediately be directed to "Wikipedia:Foo", and it was impossible to create a mainspace page at "WT:FOO" in the same way that it is not (AFAIK) possible to create a mainspace page at "Help:Foo". A maintenance script was used to move all the shortcut pages starting with "WP:" and "WT:" to new locations in the Wikipedia: and Wikipedia talk: namespaces. The update was fairly painful because there were a lot of name conflicts between pages named "WP:Foo" and "Wikipedia:Foo", and a number of templates beginning with "Template:WP:...". I have been investigating the corresponding situation with other popular shortcuts such as "T:", "P:" and "CAT:", with mixed results.

From Special:Prefixindex/T: we can see the 30 or so extant "T:..." shortcuts: I have confirmed that there are relatively few potential name conflicts, and no template conflicts. In every case where there is a name conflict, the two pages are either the template target and its shortcut redirect, or two redirects to another template; the conflicts could be trivially resolved by deleting the redirect or by merging the histories of the two redirects, respectively. It would therefore be possible to implement "T:" as a namespace alias for "Template:" relatively painlessly. This would of course prevent these shortcuts from multiplying while at the same time allowing every short template name to be used as a potential shortcut. There is a small issue with the "T:..." alias: the valid article t:kort. I'm not sure what could be done with this, perhaps there is some unicode replacement for the colon (or the t for that matter!) that we could use for the main article? A redirect from Template:Kort (which would be the result of typing "t:kort" into the search bar) would have to be condoned but that's no big deal - we already have such redirects from Help: A Day in the Life to Help!: A Day in the Life, for instance). It would be nice to be able to define "TT:..." as an alias for the Template talk: namespace, but this is unfortunately the interwiki prefix for the tatar wikipedia!

The situation with the "P:..." alias is similar. There are some three hundred "P:..." pages, the majority of which have no equivalent page "Portal:...". The very few that do (see list) are without exception redirects or targets, as with the T: alias. Once again there is a minor problem in the article P:ano. There are no pages of the form "PT:...", but this is the interwiki prefix for the Portugese wikipedia so it is not possible for us to use it as an alias.

The situation with the "CAT:..." shortcut is more difficult: there are a large number of them, this time redirects without exception, but I don't think that defining "CAT:..." as a namespace alias for "Category:..." would be very helpful, as it would mean that the normal rules of category links would apply: writing [[CAT:CSD]], for instance, would result in the page being added to CAT:CSD rather than being linked to it. If there is an option to specify that "CAT:" is equivalent to ":Category:" then this would be useful, otherwise these redirects will probably have to remain. There are no pages with the prefix "CATT:" so this could be easily enabled as an alias for the "Category talk:" namespace.

There are only a handful of pages with the "H:" prefix, all redirects to Help: space; none of their alias pages exist. However there are a number of templates prefixed with "H:", associated with the bot-imported help pages from metawiki. This help system itself appears to be in disuse and needs to be rethought, so this may not be an insurmountable obstacle. "HT:" is the interwiki prefix for the Creole wikipedia.

There are no valid shortcuts with the prefix "I:" to images, and three valid articles; such an alias would also suffer from the same problems as the "CAT:" alias above. "IT:" is the interwiki prefix for the italian wikipedia. There are no shortcuts or articles at "U:", just a handful of implausible redirects, or "UT:" - "UT" is also not an interwiki prefix so could be used as an alias for the "User talk:" namespace.

In summary, the following namespace aliases could be easily created with minimal effort, with the associated benefits.

• HT: → Help talk:
• U: → User:
• UT: → User talk:
• CATT: → Category talk:

In addition, the following aliases could be created if a few issues were resolved:

• P: → Portal: – p:ano
• T: → Template: – t:kort
• CAT: → Category: – if automatic category linking could be disabled
• I: → Image: – if automatic image inlining could be disabled

I guess this is more of a status update and food-for-thought exercise than a concrete proposal at this time, but there is clearly some mileage in this and the potential to remove a lot of 'backstage' housekeeping links from the 'reader-facing' mainspace. It would also probably be a good idea to discover or plead for a solution to the problem of needing to create an article that begins with a valid wiki (or interwiki) prefix; we already have a few of these, and sooner or later someone is going to write a book entitled "Wikipedia:The free encyclopedia" or "Portal:A great SciFi novel"; our handling of these is currently quite inconsistent, a coherent approach (preferably by escaping the colon in some fashion) would be desirable. Comments? Happy‑melon 17:33, 5 October 2008 (UTC)

I think most or all of these would be unnecessary. "User" and "Help" are short enough that its not really worth saving 3 characters for a link that's more confusing. And how often do we need to link to most of the talk namespaces like category talk or portal talk where creating shortcut links would be justified? Other than WP/WT, I think the only namespace that's ever shortcut-ized is CAT and, rarely, H. Mr.Z-man 21:14, 5 October 2008 (UTC)

Solution in search of a problem, in my opinion. It's not really an issue. EVula // talk // ☯ // 02:53, 6 October 2008 (UTC)

I support the proposal, or at least the general idea behind it. If it saves typing and isn't a big deal to implement, then there's benefits, but no drawbacks, which means there is no good reason not to implement it. Criticisms so far aimed at the idea sound suspiciously like arguing "I'm not interested in it" to have a page deleted. Abyssal (talk) 11:08, 6 October 2008 (UTC)

It saves a tiny bit of typing at the expense of cryptic links and pointless shortcuts. We shouldn't be encouraging users to clutter up userspace with shortcuts to their own userspace and we shouldn't be using confusing links like H:IOUF when trying to explain to new users how to upload files. Mr.Z-man 16:46, 6 October 2008 (UTC)

I've always been wondering why there isn't a CAT shortcut for the category namespace, and have wanted to see one; I hadn't taken into consideration the complication of the dual nature of these links. Having corrected a number of faulty links to categories (including one in an archive), which actually categorised the page they were in instead, I can see a good use for a CAT: alternative to :Category:. People often forget that crucial initial colon. (On the other hand, might such an alternative cause more confusion?)

As far as other namespaces are concerned, I've never seen a reason to shorten words like User and Help, in which case the balance does seem to tilt towards over-abbreviation. The template namespace is easily accessed through {{tl}} (although there would be merit in a shortcut, mainly for template talk pages). Waltham, The Duke of 01:27, 7 October 2008 (UTC)

• Support this change. We already have CAT:s littering the "article space" so why not make it officially a namespace redirect? I also like all the other redirects, I have always wondered why WP: (& WT:) are so special. Foxy Loxy ^Pounce! 08:07, 12 October 2008 (UTC)

Attack of the Killer B's

Meet Killer, your friendly local booster for B-class article improvements.

Ever feel frustrated by the thought that it's really hard to get Did you know credit for expanding anything bigger than a substub, and it's a big gap from there to good article? Okay, let's fill that gap. Proposing the Killer B's to thank people for raising the dreadful up to pretty good.

Killer B recognition goes to improvement drives for existing articles that start out at C-class or below, with a few requirements:

1. The article comes to full-fledged B-class work: useful overview of the subject, pretty well written, pretty well referenced, no uncited controversial stuff, no tags for serious shortcomings.
2. Double its word count (not counting lists).
3. Get it to at least 1000 words.
4. Bring it to a total of 10 or more reliable sources with inline citations.
5. Add at least 5 new reliable sources yourself (it may already have some sources before you start).
6. Do all the improvements within 1 week.

There wouldn't be any special designation for Killer B at the article, but we could keep a 'Beehive' to thank editors for their contributions and offer cute doodads for userspace. The basic setup would operate similar to GAC: anyone can review and the process works on an honor system. Durova^Charge! 20:28, 6 October 2008 (UTC)

Template:Vote-Support I agree, but I'd be more inclined to simpily have an award, like a barnstar, awarded by common editors for such a thing --Ipatrol (talk) 00:40, 7 October 2008 (UTC)

Yes, Killer Bs would be awards similar to barnstars awarded by common editors. Durova^Charge! 00:55, 7 October 2008 (UTC)

I see, but what I was trying to say is that I don't agree with the "beehive" part of your proposal. Also you might run into issues with WP:OWN, in otherwords, who of the editors on such a page would get that award? --Ipatrol (talk) 01:00, 7 October 2008 (UTC)

Generally one or a small team of people who raised an existing article up to B class within those parameters over the course of a week. What objection do you see with WP:OWN that doesn't exist for a similar program such as DYK or GA? Durova^Charge! 02:13, 7 October 2008 (UTC)

I like the general idea, but I really dislike the actual characterisation of it - I mean come on, a bee called 'killer'? We're not in primary (elementary) school... get rid of the whole 'bee' thing, make it more like the existing barnstar system (i.e. a bit more mature, without a character), and I'll be more happy to fully support. _TalkIslander 14:01, 7 October 2008 (UTC)

Well, I'll see what else I can do. It helps to give these things some kind of personality--gets people to remember them. Suppose I found a still from an old 1950s B-movie horror flick? Durova^Charge! 20:04, 7 October 2008 (UTC)

No, see, that's the problem. I won't support it with any personality - like I said, we're not in primary school, we don't need a mascot-type-device, seriously we don't. Barnstars work, they're not a 'who, they're a 'what'. Make this a 'what' as well, and ditch any personality or character. _TalkIslander 21:47, 7 October 2008 (UTC)

Agreed. The red-white termite doesn't look appetizing, does it? NVO (talk) 14:52, 8 October 2008 (UTC)

That's 'cause you're not supposed to want to eat it. And I support the proposal. :D Abyssal (talk) 22:10, 8 October 2008 (UTC)

How about this:

The B class award I award this Barnstar to Village pump (proposals) for their achivement In getting Wikipedia:Main Page to B class status.

--Ipatrol (talk) 17:04, 11 October 2008 (UTC)

Yeah, see, sadly I kinda want to squash that little stripey dude. I don't do well with the six-leggers, and I'd bet I'm not the only one. Plus that goofy grin of his...Yeah, he's gotta die. Sorry, but...CRUNCH.Gladys J Cortez 02:51, 12 October 2008 (UTC)

Wikipedia Index Proposal

I would like to suggest, a form of invisible universal category that all articles would belong to. It would be called the Index. it would be viewable to all people, just like an index an the back of a paper encyclopedia. It would look like category pages currently do. Until developers can get in on this, bots would attach all articles they find to an "index" category. The index would have an abridged versiom of articles with only at least a certain number of monthly visitations, an an unabridged version with all articles. You may comment, discuss, or vote under the following categories. --Ipatrol (talk) 00:57, 7 October 2008 (UTC)

Special:AllPages--Jac16888 (talk) 01:01, 7 October 2008 (UTC)

It looks like you're describing Special:Allpages. --Carnildo (talk) 20:19, 7 October 2008 (UTC)

Public feedback

Just throwing this out there; I'd love to see it implemented as other projects already have but it would need wide community acceptance. Please see the bottom of any Wikinews article or the sidebar of Wiktionary. These projects have implemented a feature where anonymous readers can submit feedback about articles so the project knows how it can improve. I know that it will be a good way to better learn the public's perception of Wikipedia. Many people will read something wrong, a vandalized article, or something that needs improvement, but they don't know how to fix it or that they can even edit it. They then just write Wikipedia off as worthless. A public feedback system will let us know exactly what articles need to be improved the most as well as in what way. Very few of our millions of readers ever make an edit, so we really don't know exactly what they want. This is obviously a major change that wld require wide community acceptance, but I urge you to consider this beneficial plan and perhaps implement a short testing period before making anything official. Thanks, Reywas92^Talk 02:45, 7 October 2008 (UTC)

I used to think this would be a good idea, but then take a look at all the parallels in other sites. Many news sites that used to allow comment posting have removed this feature, and I'm not even going to touch YouTube comments. Then look at Wikinews, how is this helpful? Mr.Z-man 17:48, 7 October 2008 (UTC)

Feedback would have to be via a controlled questionnaire from with little or no scope for text input. This would make things easier for readers providing genuine feedback, easier for editors analysing the results and harder for flamers, etc. Ideally such a questionnaire should be designed with some reader involvement to ensure the right questions are asked and answer options provided - probably different reader groups per article category, as e.g. readers of scientific and pop culture articles will have different expectations. This sounds difficult, so internal brainstorming might be the only option. -- Philcha (talk) 18:22, 7 October 2008 (UTC)

Also keep only 1 response per article per user id / IP address.

Only one response per IP address? You mean the entire nation of Qatar is only permitted two opinions on a given article? --Carnildo (talk) 22:25, 7 October 2008 (UTC)

Something like this was implemented on Wikia actually: wikia:central:Special:ProblemReports. I honestly think it doesn't work very well on Wikia, as only administrators of the local wiki or Wikia staff can change the status of the report, but perhaps they would be kind enough to release the extension by GFDL (I don't know if it is or not), and then it could be implemented here for autoconfirmed+. As for your concern Philcha, there is actually more textual input than a questionnaire in that format, but I'm sure the tweaks would be possible if it was felt that textual fixes were ambiguous.
That all said... this doesn't go with the Wikipedia mantra. People should fix it themselves if they see an issue, or bring it up on the talk page. i.e., I don't think it should be implemented here. --Izno (talk) 01:26, 10 October 2008 (UTC)

Not everybody's bold. We should be pragmatic and give people the lowest barrier for entry required. I think being able to say "this article needs some love" without getting wrapped up in dealing with it encourages participation (what Wikipedia is about) rather than discouraging it. And it should absolutely be available for everyone, blocked, logged-in or administrator. — Werdna • talk 00:33, 11 October 2008 (UTC)

Symbol Key

I've been having a bunch of issues trying to figure out what all the symbols mean, though I'm starting to figure out what some of them are, like the bronze star. But there are just so many symbols (or at least to me) that I don't really get them all (e.g. one day I was looking at a page and next to German/Deutsch, I think, there was a gold star, and so I didn't know what it was and it annoyed me, tough I eventually figured out it was the equivalent to the bronze star). I think that would be very helpful. Like what does the green circle with a plus sign in it mean? That would also be helpful to new users. Thanks! Helixer (talk) 22:10, 7 October 2008 (UTC)

A gold star on an article means that it is a WP:Featured Article, the green symbol stands for WP:Good Article, the only bronze star i can think of is a WP:Barnstar. Any others?--Jac16888 (talk) 22:33, 7 October 2008 (UTC)

As you say, Wikipedia:Featured articles describes it as a bronze star. The mouseover for the star on a featured article says "Featured article", and clicking it leads to Wikipedia:Featured articles where the star is described, so I don't think any more explanation is needed. The gold star on interlanguage links to featured articles is made by {{Link FA}}. The mouseover for the corresponding language link is "This is a featured article in another language." (See for example United States). Does your browser not display mouseovers? The symbol for Wikipedia:Good articles is a green circle with a plus. Again, both mouseover and clicking it should usually explain it. If it's on a user page then it means the user has contributed to a good article. PrimeHunter (talk) 23:08, 7 October 2008 (UTC)

Sorry my bad, never even noticed that FA star was bronze, thought it was just a dark gold colour--Jac16888 (talk) 02:25, 8 October 2008 (UTC)

I would hope that the good article symbol isn't in any articles. There's been several large discussions about this, all resulting in either no consensus or a consensus to not put the GA icons in articles. Mr.Z-man 16:15, 10 October 2008 (UTC)

Deletion reason

Hi all - when you go to delete a page via http://en.wikipedia.org/w/index.php?title=(pagename)&action=delete you are presented with a handy-dandy list of reasons for deletion that you can pick and choose from. At present, that list is simply all the Speedy Deletion criteria, plus the catch-all "other reason". I'd like to see a further reason added to that list - "Per consensus at deletion process page". Consensus at AFD, CFD, and the like is surely one of the most common reasons for deleting a page, and would be a useful extra item to have on that list. Grutness...wha? 23:53, 7 October 2008 (UTC)

MediaWiki:Deletereason-dropdown has the various reasons. MBisanz ^talk 15:14, 8 October 2008 (UTC)

Other reason: (provide link to the xFD). –xeno (talk) 15:21, 8 October 2008 (UTC)

Per Xeno, but a bit more explicitly—if a page is being deleted pursuant to consensus in a discussion, the deletion log entry should include a link to the closed discussion. Just saying per consensus at deletion process page isn't nearly as helpful, and can be confusing for someone following up if a page has been deleted more than once (was the 'deletion process page' AfD? DRV? A second or third AfD? etc.). TenOfAllTrades(talk) 16:03, 8 October 2008 (UTC)

If you try to delete a page with PROD or AFD, the default reason you get is either the deletion rationale for the PROD or a link to the AFD. Hence such an option would be redundant. Hut 8.5 06:47, 9 October 2008 (UTC)

The reason it's not there may be because such deletions should always include a link to the deletion discussion. That would not be possible if it was a dropdown option. If something is deleted at xfd, you should put something like "per [[Wikipedia:Articles for deletion/Main Page]]" as the deletion reason. --- RockMFR 17:40, 9 October 2008 (UTC)

Such a link always exists in the "what links here" links - which is why its so often not specifically included in the deletion log reasons. Grutness...wha? 00:34, 10 October 2008 (UTC)

It should always be included in the summary, as most readers are probably not aware of the what links here feature. --- RockMFR 01:59, 10 October 2008 (UTC)

The 'what links here' may include a lot of other pages – links from user space, multiple deletion discussions, AN postings, other deletion discussions, etc. – and it may not be immediately obvious in what order the linking deletion discussions took place. (Was it AfD1, AfD2, DRV? Was it AfD1, DRV, AfD2? Was it AfD1, DRV1, AFD2, AfD3, DRV2, AfD3, DRV3?) Links from the deletion log will always be in clear chronological order, and should always be deletion-specific. TenOfAllTrades(talk) 05:39, 10 October 2008 (UTC)

I've been bold and added it. Feel free to remove it if it causes problems. — Werdna • talk 00:31, 11 October 2008 (UTC)

It's been reverted (not by me, I add). I agree with the principle: the 'XfD' option should not be added to the dropdown menu unless it is possible to automatically fill in a link to the deletion discussion. Those links are vitally important, as they display whenever someone then tries to recreate the page and may be consulted to discover why it was deleted in the first place. Happy‑melon 09:56, 11 October 2008 (UTC)

It is absolutely needed to link those discussions for the reasons mentioned above. It is also more comprehensible for new users or readers ("per rfd", but also "csd g2", "U1", etc, are not) and more professional. It should be noted in MediaWiki:Confirmdeletetext, something like:

• If you intend to delete as a result of a deletion discussion, link to this discussion.

While it is easier for afds, all discussions have permanent blue links, for example for tfd, Wikipedia:Templates_for_deletion/Log/2008_October_11#Header.

All the closing guidelines, general and specific, should reflect that.

Cenarium ^Talk 23:53, 11 October 2008 (UTC)

Forcing or reminding users to sign their comments

I don't know how big a problem it is in the main wikipedia, but users quite often forget to sign their comments on talk pages of the smaller wiki I use to contribute to. How about automated signing of comments so that it cannot be forgotten or refused (if technically possible, of course)?

Alternatively, I suggest creating a box in the "Editing" column on the "My preferences" special page so that, if the box is checked, users would be reminded to sign their comments if they haven't done that yet when trying to save the talk page they have been working on. The "Prompt me when entering a blank edit summary" function works similarly.--Emaster82 (talk) 03:07, 10 October 2008 (UTC)

While not a part of the Mediawiki software itself, SineBot automatically adds signatures to most talk pages if a user forgets. User:Slakr is responsible for the care and feeding of SineBot, and might be able to give you some tips on how to implement something similar on your own wiki. TenOfAllTrades(talk) 05:31, 10 October 2008 (UTC)

Another device I didn't know of. Anyway, I might indeed contact the bot's nurse for help.--Emaster82 (talk) 14:08, 10 October 2008 (UTC)

The problem with a system-level solution is that, sometimes, users need to edit a talk page without signing. For example, I don't need to sign if I'm placing {{WPBiography}} on a talk page, or if I'm correcting someone's botched link. MediaWiki can't tell the difference between an unsigned comment and a non-discussion content edit. EVula // talk // ☯ // 23:08, 10 October 2008 (UTC)

I don't see that as a problem. We already have a box at the bottom of the edit box marked "Watch this page" which is checked by default. We could have a similar box marked "Sign this post". If we did that, and removed the signature icon at top, we would have a situation where we no longer have to ask for posts to be signed. It would be done automatically unless we asked for it not to be done. I think this change is long overdue, and I thought there was an announcement a few months ago that this feature was being developed. What happened? Even experienced users forget to sign now and then, and I get annoyed when it happens to me, so I'm hoping to see this change happen sometime. --A Knight Who Says Ni (talk) 13:06, 11 October 2008 (UTC)

Some projects do have global JavaScript that reminds users to sign on most discussion pages, and if they don't need to sign a particular edit, they just have to click "Save page" again. This feature could be limited only to IP and new users by default. —AlexSm 14:40, 11 October 2008 (UTC)

Will be sorted by LiquidThreads, and David McCabe has been hired to finish it for Wikimedia. — Werdna • talk 12:53, 11 October 2008 (UTC)

can't we just search without specifying the language on www.wikipedia.com

on the main page of www.wikipedia.com, when we type in a keyword to search, we need to type in the language too... can't we just search without specifying a language?

for example, if we search for 李克勤 on google, we don't really need to specify the language, because it is taken as UTF-8 and there is a perfect 1 to 1 match of those characters in UTF-8. There is no ambiguity...

is it because the content portion of wikipedia is so big that we want to limit the range of search? won't building a good index solve that problem? or otherwise, can we just search for all the "titles" of the whole wiki database if the user choose not to specify a language in the main box, and then down below, there is a more extensive search box where users can enter the keyword and then specify the lanugage as well? thanks.

You can search all language wikipedias at once with Google. Algebraist 08:39, 10 October 2008 (UTC)

Automatic language selection on the home page based on computer's local settings is very annoying. My computer has foreign settings, but in 99.9% of my searches I need to browse the articles in English. It is annoying to have to select English every time I open wikipedia.org. I don't want to be switched automatically into the other language.

You can't really search in www.wikipedia.com, since that's just a redirect to the actual address, www.wikipedia.org. *Dan T.* (talk) 20:39, 10 October 2008 (UTC)

If you want English specifically, then what are you doing at www.wikipedia.com or www.wikipedia.org in the first place? Go to en.wikipedia.org. Algebraist 23:12, 10 October 2008 (UTC)

Or just change your browser's preferred language to English. Firefox at least lets you have one language for the user interface and another for web content if you'd like. —Remember the dot ^(talk) 23:15, 10 October 2008 (UTC)

Discussion on gender metadata

Please see comment I made here about obtaining and recording gender (male/female) metadata. Opinions would be welcomed. Thanks. Carcharoth (talk) 02:05, 11 October 2008 (UTC)

General discussion on metadata

I (Carcharoth) split this general comment off from the above announcement by me. Carcharoth (talk) 14:36, 11 October 2008 (UTC)

I'm not crazy about the use of metadata on Wikipedia. (Metadata has a double use: it can be used for auto-generating technical terms – and male/female isn't too technical – but it can also be used for "screen scraping" as used by personal information gatherers, identity thieves, and spammers. It is also a "what you see is not what you get" form of coding, or maybe I should say "what you don't see is what you get". I think that some day we'll have to consider whether metadata should be officially banned on Wikipedia, if only because it is [or could be] made redundant by existing Wiki features, and I'd be in favour of that.) We already use categories, a built-in feature of Wiki software, and the information you're seeking could be found if we used the category feature in biographies. --A Knight Who Says Ni (talk) 12:27, 11 October 2008 (UTC)

Metadata should be encouraged! I don't understand what you're on about in terms of identity theft. — Werdna • talk 12:54, 11 October 2008 (UTC)

As much as I dislike people who say "go do a Google search" as a response, a Google search of "metadata controversy" could be an eye opener. --A Knight Who Says Ni (talk) 13:11, 11 October 2008 (UTC)

Have you read metadata? I'm talking here about the organisation of article data (information in the article, not the true metadata such as article history and edits) using tags. Data on its own tends to collapse into untidy heaps. I agree that existing and future Wikipedia methods should be used, but banning metadata will never happen, if only because some data is metadata. See Wikipedia:Metadata (currently in a sorry state, but being expanded) for more. My personal interest is in at Wikipedia:Biographical metadata, though I also take an interest in the geographical side of things. Examples of metadata systems used at the moment to create synergy between different applications are the one where Wikipedia tags appear on (Google?) maps, and the links taking you to a map in general. The ISBN system is another one. Carcharoth (talk) 14:36, 11 October 2008 (UTC)

It's OK as long as it does not force additional coding on the editor and does not worsen readability of wikitext in edit window... but then who really cares? it just exists somewhere in the background, like a systme clock. Or ? NVO (talk) 18:09, 11 October 2008 (UTC)

The "additional coding" being a burden to the editor is a problem, I'll admit. The best systems would (and some do, I think) allow non-technical editors to add stuff in plaintext, and for technical editors to wrap the data in tags. Unfortunately, if the tags are not visible, maintenance is difficult. If they are visible, then editors get put off editing. Tricky. Carcharoth (talk) 19:17, 11 October 2008 (UTC)

• Suggest moving this discussion to Wikipedia talk:Metadata. Carcharoth (talk) 14:37, 11 October 2008 (UTC)

Non-english warning

There doesn't seem to be a WP:WARN for adding to an article in a language other than english. The closest one is uw-english, but it's intended for non-english communication on talk pages, rather than non-english additions to articles. Additionally, uw-english is only available in english, which is unlikely to be helpful in a situation where communication is being attempted in a person that may have only a basic grasp of the english language.
I propose:

• That a standard warning series of templates be created for this situation.
• That each template contain links to a translation of said template into as many languages as possible.
• That a similar multi-lingual template be created to replace uw-english.

I eagerly await the community's input. Horselover Frost (talk) 08:54, 11 October 2008 (UTC)

Sounds like a good idea. I wonder if there is already something like this at one of the other Wikipedias. --A Knight Who Says Ni (talk) 12:14, 11 October 2008 (UTC)

Is there any particular reason you didn't post this at WT:WARN? You also overlooked {{uw-notenglish}}. The main issue I see here is getting people to actually write translations of the templates. Anomie⚔ 14:13, 11 October 2008 (UTC)

I did overlook that one. However, it is also over-specialized (in this case, just for the creation of new pages). What we need is a generic warning for inappropriately using another language in article space. (Also, I posted the idea here rather than at WT:WARN because implementing it in the various languages would require more editor resources than WikiProject user warnings is likely to garner.) Horselover Frost (talk) 21:25, 11 October 2008 (UTC)

This could be a joint venture with other languages as well. The translations could be stored at Meta and then each language has its own template with links to the translations. Anyone from one of the other languages could write the translation, which could then be added to the templates. -- Imperator3733 (talk) 19:25, 11 October 2008 (UTC)

Have you taken a look at Category:Poor English welcome messages? I've used the en-es one on a couple of instances, and I don't know if we need to start escalating welcomes (which are pretty much level 1 warnings) to higher level level warnings once the users have had that first notice. -Optigan13 (talk) 22:03, 11 October 2008 (UTC)

Whatever Template:Welcomeen-es is supposed to be, it is really, really poor Spanish. SandyGeorgia (Talk) 22:06, 11 October 2008 (UTC)

Should we run the set of messages by WP:Translation by someone with a strong knowledge (xx-4 or xx-5) for each language, or is there a better place to find a set of translators to review those templates? Still, does anyone thing there is a need for multiple levels of (hopefully well-written) notices for people who submit non-english articles? -Optigan13 (talk) 22:48, 11 October 2008 (UTC)

I would think having an xx-4 or xx-5 do the translating would be fine and we should be able to use WP:Translation. As far as multiple levels, I would think two levels would be fine for now. If needed, we could always add another level. -- Imperator3733 (talk) 05:58, 12 October 2008 (UTC)

The ability to block vs. "no big deal"

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

• Please read the entire proposal before commenting.

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)

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

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

Focusing the mind

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)

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)

Proposals for Topics in "Today's Featured Article"

Dear friends,

I have begun to read "Today's Featured Article" of the Wikipedia everyday. I appreciate this effort and consider this as a very good venue for self-education. In fact I have made it my default page so that I can read it everyday.

However, I noted that the topics, at least in the past one week, concerned things that were too minor or trivial for a global audience. Today's article for example is about Trafford, a small town in England. There are countless small towns all over the world and one doesn't gain much knowledge by knowing the hundreds of thousand small towns in the world. Yesterday it was the Grass Fight during the Texas Revolution. It would have been better if the feature is on the Texas Revolution rather than the Grass Fight because majority of people didn't even know that there was a Texas Revolution.

May I make a suggestion?

Can we make the daily Featured Article a kind of long-term educational program that will widen and deepen the liberal education of Wiki readers? In making this, we can make it cover a broad range of significant human knowledge that will matter in the lifetime of a person -- covering history, science, arts, religion, philosophy, humanities, geography, etc. It can include topics that are seldom heard-of, but still of significance when learned. Here are examples:

Quarks / Strings Michelson Morley Experiment Asoka Lemmings Angkor Wat Gordian Knot Western Schism Anti-Popes The Fourth Crusade Samadhi Hundred Years' War Genome Project A priori and a posteriori Impressionism Knight Templars Ataturk Cargo cult Marianas Trench Timaeus (dialogue) etc.

Being an educator myself, I am willing to be of help in suggesting articles for the Featured Article section.

May I take this opportunity to thank all those nameless volunteers who make this truly revolutionary encyclopedia possible.

With warm regards, Vicente Hao Chin, Jr. Author, The Process of Self-Transformation

In order to be Today's featured article, an article must first be a featured article; that is, it must have been identified as one of the best articles Wikipedia has to offer. If you want the articles you mention to appear on the main page, you've got a lot of work to do getting them up to Featured standard first. Algebraist 09:24, 12 October 2008 (UTC)

See WP:TFA/R, but our TFAs have to be of general interest to a broad readership, i.e.; not only scholarly topics. SandyGeorgia (Talk) 09:29, 12 October 2008 (UTC)

Wikipedia is an encyclopedia, not an educational site, see WP:NOT. "Wikiversity", I believe, is. We didn't choose (well, more precisely, the TFA director) didn't choose Texas revolution because it isn't a featured (meaning "quality" in this context) article. Though we have more specialized featured articles, like General relativity. Cenarium ^Talk 16:08, 12 October 2008 (UTC)

Edit summaries on talk pages

199.125.109.136 (talk) 19:48, 12 October 2008 (UTC)