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)

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)

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)

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)

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)

Straw poll for "view-deleted activation" now open

In June 2008 the Arbitration Committee announced a request that the English Wikipedia consider allowing some non-administrators the ability to view deleted material. The summary of the announcement was

The activation of the passive "can view deleted" right, and a policy allowing its grant for good cause, would allow non-administrator users to gain wider participation in the English Wikipedia community. For details and discussion, see Wikipedia:Arbitration Committee/June 2008 announcements/Activation of view-deleted-pages

Note that this is a request that the idea be considered, nothing stronger. The announcement led to this proposal. As this conversation has gone on for several months, the proposal has shifted around quite a bit. This makes it very unclear where editors are currently giving their support or opposition. For the sake of clarity, I am attempting to pick out the main proposals, and create a straw poll around them. Please share your opinion at Wikipedia:Village pump (proposals)/Persistent proposals/Straw poll for view-deleted. ~ JohnnyMrNinja 09:05, 26 September 2008 (UTC)

The proposal has been marked as "failed to gain consensus", following a statement by the legal counsel for the Wikimedia Foundation. See the straw poll page for details. -- John Broughton (♫♫) 23:51, 3 October 2008 (UTC)

Straw poll notice on Watchlist

I would like to put a notification about the "view-deleted" straw poll in the watchlist. My reasoning is that this is a big decision that will affect all users, possibly the way that Wikipedia works, but not everyone reads the noticeboards where I posted messages. Also these noticeboards move rather quickly (especially WP:AN), so this will make sure that more people have a chance to see it. This is the line I would like added -

A poll is now open to determine if non-administrators should be able to view deleted pages. All editors are asked to voice their opinions here.

Thoughts? ~ JohnnyMrNinja 16:26, 27 September 2008 (UTC)

The proposal has been marked as "failed to gain consensus", following a statement by the legal counsel for the Wikimedia Foundation. See the straw poll page for details. -- John Broughton (♫♫) 23:51, 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 | Discalimers | 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)

Support (dot only)

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

Support (bullet only)

1. MTC

Oppose (keep 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)

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)

WP:DYK Mailing List Proposal

please see Wikipedia_talk:Did_you_know#A_Couple_of_Suggestions... for more info.

Thanks,

BG7even 08:31, 2 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)

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)

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)

Rollback option

• Wikipedia:Village_pump_(policy)#Rollback_option

(I meant to post it here, but I didn't check berforehand what WP:VPP redirects to : )

So, see the discussion there. - jc37 02:47, 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)

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)

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)

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)

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)

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)

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.