Wikipedia:Village pump (proposals)/Archive 51

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

Village pump (proposals) archive  

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

---

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

Main page layout—it's getting old and boring

Our current main page layout is plain and boring. It hasn't been updated in years. I think we should have some kind of "customer satisfaction" survey about the main page. The 2008 redesign proposal was blown off, maybe it's time we tried again? I think it could use a re-do to make it look more modern. iMatthew ^talk at 19:48, 13 August 2009 (UTC)

Have you seen Wikipedia:Main_Page_FAQ#Is_there_some_way_to_make_the_Main_Page_look_better.3F? Who then was a gentleman? (talk) 21:37, 13 August 2009 (UTC)

Indeed I have. But my personal choice of how I view the main page has nothing to do with the design seen by millions every day, that gives off the initial impression to visitors. iMatthew ^talk at 02:53, 14 August 2009 (UTC)

I'm somewhat opposed to completely re-designing the main page; millions of readers and editors are already used to it, and it's served effectively for several years without any issues. –Juliancolton | ^Talk 03:08, 14 August 2009 (UTC)

I've thought of that, but people today are of course looking for newer looking, modernized website. I was thinking about this today when I saw that Yahoo's main page was/is being redone. If we can get new things up on the main page, and remove anything that people don't use, it's very likely that Wikipedia will get more visitors, and more contributors. New, fresh, modern looks are what attract people. Being that we've had this main page for about 3 years now, people are getting tired of it. There aren't any "issues" per say, but an update to refresh the page's look could really help Wikipedia. This is just my opinion, which I believe I share with many out there. iMatthew ^talk at 03:19, 14 August 2009 (UTC)

I personally think we should have a boring and unchanging, persisting main page layout. Anyway, this was extensively discussed by hundreds of users last year with a design competition and numerous different actual designs made and ended with no consensus to change anything. See Wikipedia talk:WikiProject Usability/Main Page/Final archive (2006); Wikipedia:2008 main page redesign proposal, Wikipedia talk:2008 main page redesign proposal/Survey; Wikipedia:2008 main page redesign proposal/Different; Wikipedia:2008 main page redesign proposal/straw poll 2008-10-18.--Fuhghettaboutit (talk) 03:18, 14 August 2009 (UTC)

I mentioned that in my first comment. The 2008 proposal was sort of blown off though, and I think we should try to pick it up off it's feet and continue working on it. iMatthew ^talk at 03:21, 14 August 2009 (UTC)

I think it is pointless to do a change at this time, because we know that the default skin is going to change significantly in the coming year, but we don't exactly know what the end result of that is going to be. As such, designing a "New look" for the main page is gonna be difficult, because so much of the look around it will change. Until we have a better grip on what the skin changes are going to be end up looking, any form of a redesign is probably wasted time. —TheDJ (talk • contribs) 11:17, 15 August 2009 (UTC)

I tried the new skin. It was ugly. Noodle snacks (talk) 13:28, 15 August 2009 (UTC)

Hear, hear. Who then was a gentleman? (talk) 03:18, 16 August 2009 (UTC)

Proposal: Infobox change

In the recent usability study, infoboxes consistently tripped new editors up.

I think we can get around this: Instead of the long, lengthy infobox code that currently dominates our articles, why not instead simply transclude Article/Infobox, which would contain the complicated code currently kept in the article? With a small amount of extra coding, Article/Infobox could be automatically watchlisted alongside Article, just like Talk:Article is.

Thoughts? Shoemaker's Holiday ^{Over 184 FCs served} 12:15, 9 August 2009 (UTC)

Unless there is a technical reason not to, I think this is brilliant. KillerChihuahua^?!?Advice 13:06, 9 August 2009 (UTC)

There is a technical reason, obviously: subpages are not enabled in the article namespace. Granted, the chance of an actual title clash is reasonably small—I rather doubt we'll see a band naming themselves "Something/Infobox" or anything of that sort—but I would suspect that an infobox subpage can't be enabled without enabling subpages generally.

Beyond that, some articles contain more than one infobox, for various reasons, and these infoboxes are not necessarily contiguous within the article; how would a subpage structure handle that case? Kirill ^[talk] [pf] 13:11, 9 August 2009 (UTC)

Kirill made two of the comments I was going to. Also, this creates yet more pages where non-free content is showing. Would taxoboxes be included? What about tables? What about other "boxes", like this one? J Milburn (talk) 13:15, 9 August 2009 (UTC)

The usability study showed the major problem was random crap before the first paragraph of main text. Later additions can be put in as normal. Basically, this would encompass everything that takes more than, say, two lines at the top of the edit box being put into a new section (It could be calledd Article/Header if you'd rather), so that new editors are faced with a minimum of complicated templates on clicking the edit button. a new namespace, say, Headercrap:Article, is also a possibility. Shoemaker's Holiday ^{Over 184 FCs served} 13:22, 9 August 2009 (UTC)

Would that include the various header banners ({{unreferenced}}, etc.) as well as normal infoboxes, then? I'd think that it would be beneficial to maintain some separation between temporary banners and permanent templates; for example:
{{Banners/Article}}
{{Infobox/Article}}
Article text starts here...
Kirill ^[talk] [pf] 13:33, 9 August 2009 (UTC)

Great idea. There may be technical problems, but I'm sure those can be worked out somehow. We could restrict this to infoboxes that appear at the very top of an article, so that a newbie sees the actual article text when he clicks "edit this page", and not something like this. --Conti|✉ 13:23, 9 August 2009 (UTC)

An alternate solution is to use templates that start with "Infobox/", such as {{Infobox/Shark}}. This is more flexible in terms of naming. Non-free images have to be wrapped in includeonly, but that isn't much of a problem. — Carl (CBM · talk) 13:24, 9 August 2009 (UTC)

We could put them in the talkspace and append /1, /2, etc. when more than one exists. I would also suggest adding "v.d.e" links to allow direct editing of the subpage. Dendodge _T\^C 13:25, 9 August 2009 (UTC)

There's no reason that Article/Infobox couldn't contain multple infoboxes. Numbering the subpages defeats the point, as finding five or six numbered lines at the start of the edit window is just as confusing as the current system. Shoemaker's Holiday ^{Over 184 FCs served} 13:27, 9 August 2009 (UTC)

That's only true if the infoboxes are contiguous (unless you allow a selectable transclusion off the subpage [e.g. {{Article/Infobox|1}} ... text ... {{Article/Infobox|2}}]). We want to retain the ability to have multiple infoboxes, each in a different place within the article; and, ideally, we want to use the same transclusion method for all infoboxes, to minimize the extra work involved when repositioning them or creating new ones. Kirill ^[talk] [pf] 13:36, 9 August 2009 (UTC)

Whatever the system, it needs to let editors easily access and edit the infobox. Neophyte editors have enough trouble understanding templates and reference generation. ---— Gadget850 (Ed) ^talk 13:41, 9 August 2009 (UTC)

There is one practical caution against this , and that is the situation with references. References in infoboxes are often not the unique use of the reference, and thus it requires a lot more work to coordinate this between infobox and article body if they are separated. --MASEM (t) 13:57, 9 August 2009 (UTC)

As I see it, advantages to this proposal are:

• Less confusing to newbie editors who want to edit the article text.

And disadvantages:

• More confusing to editors who don't really understand templates but want to edit the infobox (even with vde links).
• The special infobox template page is less likely to be watched.
• Confusion over what should be done with infoboxes elsewhere in the article.
• Confusion over how non-infobox templates at the top of the page should be handled.
• Difficulty in sanely sharing references between the article and infobox.
• Non-free images cannot be displayed in the special infobox template page, requiring includeonlys in the special infobox template page.

IMO, this is another of those usability-spawned proposals where anything we can do here now is likely to be premature and unlikely to be particularly successful. The solution most likely to be actually usable requires rather large changes to MediaWiki, to basically change editing from one big text field to multiple text fields (e.g. "header", "main body", "references", "metadata (categories)", and so on). Anomie⚔ 14:40, 9 August 2009 (UTC)

Agreed; I'm worried that this would actually make things more confusing rather than less. For newbie editors who just want to see the article text, sure; it's great. But non-newbies -- anyone with a few day's experience -- it becomes more confusing. I'm also not comfortable with making wide-ranging changes like this while the usability project is still working from their end; many of the changes coming in the next couple of months could make this problem moot. Powers ^T 14:48, 9 August 2009 (UTC)

Perhaps we could put the infobox into a section called "data", and then find some way to have it up in the top right (javascript?). I've often thought that if we want to be correct about article layout in terms of html and all that (eg. with stylesheets removed), that's a horrible place for the infobox. If you have your CSS off, it basically takes up the entire top of the page, when it's clear that our articles should begin with "An infobox is a table of data about a certain subject...", and not a bunch of random data.    M   20:33, 9 August 2009 (UTC)

That was my thinking too (but the infobox should be placed at the top of the page by CSS, not javascript). Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:45, 9 August 2009 (UTC)

CSS won't work, doesn't have the capacity to do this cleanly.    M   02:02, 10 August 2009 (UTC)

JS won't work for accessibility reasons. --Izno (talk) 19:09, 10 August 2009 (UTC)

Er, the current layout won't work for accessibility reasons (blind users being hit with an infobox first thing). The very rare people with js disabled will still be able to see the infobox in a different location on the same article. This includes mobile device users, who shouldn't see the editbox on top anyway.    M   20:00, 10 August 2009 (UTC)

• Counsel patience. It's likely that usability will come up with a WYSIWYG (or at least something close to WikEd) in its search for editbox improvement. Ideally, we'd see something like what can be found with the Wikia WYSIWYG editor, which collapses templates and references to be edited in a separate, forms based layout. --Izno (talk) 19:09, 10 August 2009 (UTC)
  • Editbox improvement? Say No to editboxes.    M   20:00, 10 August 2009 (UTC)
    • I agree with Izno. why drag this up again right now ? We all know it's suboptimal, hack the fact that we have parserfunctions is suboptimal for "inexperienced users". That doesn't mean it's bad and it doesn't mean we need to solve this right now after having not solved the problem in years. The usability team is looking at what they can do, and I for one, like none of the ideas suggested here. Javascript positioning, separate namespace, it has all been suggested before and never has it seen consensus. Unless someone comes up with a briljant NEW idea, i think we should wait and see what the usability team comes up with. —TheDJ (talk • contribs) 15:31, 11 August 2009 (UTC)

namespace?

What about creating a separate Infobox: namespace? —Ruud 18:51, 10 August 2009 (UTC)

Preferably with some MediaWiki assistance, that makes it work more like the Talk: namespace than the Template: namespace. For example, no Infobox talk:, (optionally) automatically adding an infobox tab or edit infobox if one is present, perhaps even displaying it automatically on the article without the need for an {{Infobox:PAGENAME}} at the top of the article. —Ruud 19:06, 10 August 2009 (UTC)

Too hard to find, to cluttered to link. Putting it into its own heading and then moving it with js is much, much easier.    M   20:00, 10 August 2009 (UTC)

Doing such a thing with JS is also very evil (accessibility, increased loading time due to the page needing to be re-rendered). What would be the preferable solution under the assumption that a change to the MediaWiki software wouldn't be a problem? —Ruud 20:11, 10 August 2009 (UTC)

Um, doing it with JS is not "evil". Accessibility would be improved (blind users and others who adhere to correct order of html wouldn't see a random infobox on top. I think there's a misunderstanding of how browsers work - loading the page and images from the server is slow. Rendering the page is blazing fast - though there may be a delay before rendering is triggered. I think we have it narrowed down pretty well: take the text out of the lead (kill infoboxes, import using templates, import from a heading below using js), or change how it's displayed (color-coded, or hidden (there are scripts that hide it)). I think we have the bases covered. Someone should consider writing a bit of userscript js that finds the infobox and prepends it to the body, so we can try it out.    M   22:36, 10 August 2009 (UTC)

Well, if I browse to a long page, such as your talk page, the page doesn't appear doesn't appear instantaneously. It's starts rendering immediately, but takes a while (less than a second, but more than enough to be noticeable) before the last header appears. The script wouldn't be able to move the infobox to the top before that time, likely creating an annoying pop-in effect (although this really should be tested empirically.) But you also didn't elaborate on my question of what the preferable solution would be, from the users point of view, ignoring some potential technical barriers. —Ruud 22:57, 10 August 2009 (UTC)

It might be good if the infobox code could be moved to the end rather than the start of the wikitext. But I'd be anti any scheme to put the infobox on a separate page and transclude it. That would just increase user confusion, hamper editing, force you to watch two pages instead of one, create additional search complications, and generally cause a lot of trouble just to "solve" what isn't exactly a major problem anyway...--Kotniski (talk) 09:19, 11 August 2009 (UTC)

Magic words - like ToC

I think the only real workable solution is to treat certain templates like the ToC, and create magic words that can be put into base text that will locate the specific template top-right (or top-center or whatever). Perhaps this could be even further expanded to cover navboxes or other templates: bottom of the page, top-right of Section 3 (for review templates, like at New Super Mario Bros.#Reception). Then we could put all or a lot of infobox/template code at the bottom of articles, where people won't mind them. ▫ JohnnyMrNinja 02:05, 12 August 2009 (UTC)

I brought up the question of whether this is feasible at the VPT. ▫ JohnnyMrNinja 17:09, 17 August 2009 (UTC)

WP:NOTIFY

I was sure that this existed, but when I went to cite it, realized that it doesn't. I had understood the particular warnings on the various noticeboards (AN, ANI, WQA, SPA, etc.) that one should notify an editor whose conduct is being reported to be manifestations of a deeper policy, or at least community norm, of notification. Viz. that as a matter of wikiquette if nothing else, if you are trying to get someone into hot water, you should notify that person so that they have basic due process (notice and opportunity to be heard). Whether you are asking for sanctions against someone at ANI or on an admin's talk page, or anywhere else, you should let that person know.

Is my understanding correct, that there is a broad community norm of notification? Is this reflected in any existing policy? If the answer to 1 is yes and to 2 is no, how do I go about proposing such a policy? Do I just create WP:NOTIFY and slap the "proposed" tag on it?- Simon Dodd { U·T·C·WP:LAW } 20:52, 15 August 2009 (UTC)

Personally, I notify people of such things wherever possible. I've always assumed this to be the norm. I would certainly support the creation of, at least, an essay explaining why it's important to notify editors of discussions concerning them and their actions and how this can be achieved (with links to relevant templates). One problem I've recently come across on Wikipedia is the lack of clarity between discussions, and this would be an important part of fixing the problem - people need to be encouraged to be open with all conversation.

That said, I feel making it a policy to notify people is instruction creepy and should be avoided. However, an essay suggesting to notify wherever sensible would be a good addition, and something worth pointing certain editors to.

I suggest you create it (albeit at Wikipedia:Notification with WP:NOTIFY as a shortcut) and give it an essay stamp. It may go to policy later, but I still fear pushing for that seems CREEPy. If you want any help writing it, I'd be more than happy to aid. Greg Tyler ^{(t • c)} 23:13, 15 August 2009 (UTC)

Also, see Wikipedia:Policies and guidelines for information on how to go about proposing new policies. -- œ^™ 23:36, 15 August 2009 (UTC)

That's not really relevant for an essay. Anyone can write an essay--it's the logical first step in developing a guideline, which will only be adopted as such when and if consensus favors it. Jclemens (talk) 20:14, 16 August 2009 (UTC)

Just wanted to answer the poster's question about proposing policy in case they ever decide to in the future. And hopefully, for anyone else that may be reading, dispel any ideas of "just slap the proposed tag on it!" after writing their essay. :) -- œ^™ 00:47, 17 August 2009 (UTC)

Automatic redirect when user requests new user name

I'm reading the RFA of 7. One of the points of discussion is an incident where someone used(hacked) a prior account.

It may be that polices are in place to ensure this cannot happen again, but I don't get that impression from the discussion. As I understand it, if you decide you want a new user name, you abandon your old one, which can be taken over by someone else. To avoid that, it is recommended (but not required) that you re-register the old name and redirect it to your new name. In fact 7 tried to do this but was tripped up by an understandable rule, prohibiting the creation of a new name substantially similar to an old one.

Now I move into speculation - I speculate than an ordinary editor cannot create a name in this circumstance, but someone with more rights, perhaps an admin, could create the account. I don't know whether that happened in this case, but it seems plausible it could happen sometime.

Why not make the suggested policy mandatory, and implement it in software? If a user desires a new user name, and the request is granted, why not make the creation of the new name (presumably requiring more than editor rights in order to move the history over) simultaneously re-register, or maintain the registration of the old name with an automatic re-direct to the new name, possibly also adding something to make sure someone couldn't use the old name to do anything else, (i.e. the old name is not allowed any rights).

As I learn more about the twists and turns of the software, I realize there are something that sounds easy but turn out to be more difficult than they sound, but I would think this is possible. I assume when a user requests a new name, we would never want the old name being used ever again, neither for a new user (who would be confused with the prior owner) or the old user, who would then have multiple accounts. (I'm aware that multiple accounts are allowed, but this isn't the way to accomplish that.)

I haven't made this a formal proposal, because I'd like to hear from some more experienced users, who might tell me that it already works this way, and I just missed the announcement, or that it is impossible as stated for reasons I'm not following. After feedback, if there's anything to this idea, I'll try to write it up as a formal proposal.--SPhilbrickT 23:06, 15 August 2009 (UTC)

This ability already exists. –xeno^talk 11:52, 17 August 2009 (UTC)

Glad to hear it, thanks for the response.--SPhilbrickT 17:04, 17 August 2009 (UTC)

Making it possible to import edits from the Nostalgia Wikipedia and Meta to Wikipedia

I'd like to make it possible to import edits from the Nostalgia Wikipedia and Meta to the English Wikipedia. The Nostalgia Wikipedia is a copy of the Wikipedia database from 20 December 2001 which contains several edits which aren't in our database but probably should be. For example, compare the first edit of the saint article on the English Wikipedia with the history of the saint article in the Nostalgia Wikipedia. Meta was originally a place for discussion of Wikipedia policies, and some pages were moved from Meta to here by cut and paste, like our blocking policy.

I specialise in history merging old edits (see my user subpage about page history), and I'd find it useful to be able to import old edits from the Nostalgia wiki and Meta. Should this ability be given to admins as they request it, or to *all* admins?

If this discussion results in the ability to import pages, I'll refer it to this page on meta. I don't think that what I want to do (i.e. import edits to fill out page histories) is at all controversial, but the ability to import edits could be dangerous in the wrong hands, so I think it should be restricted in some way. Graham87 15:10, 14 August 2009 (UTC)

Heck, I would like the ability to import edits from every Wikipedia... So we don't have to use garish templates like {{iw-ref}} in the mainspace. –xeno^talk 15:12, 14 August 2009 (UTC)

Why is Special:Import deactivated on en.wp any? –Drilnoth (T • C • L) 15:43, 14 August 2009 (UTC)

See Wikipedia:Village pump (technical)/Archive 59#Special:Import. See also: Wikipedia:Village pump (policy)/Archive 63#Attribution/GDFL and translations (and sourcing). I never followed it up, but it just looks like we have to gather consensus and ask the devs to turn it on... –xeno^talk 18:33, 14 August 2009 (UTC)

This is a very good idea. I personally cannot see any issues with people wanting import right - and I've seen Graham87 doing complex history merges before so I know he would use the rights appropriately. Can import be granted, or do settings have to be changed for it to be possible to import from certain places? Majorly talk 18:26, 14 August 2009 (UTC)

There are actually two import rights: import and importupload. Every administrator has the first one. It allows to import from any WMF wiki. The only problem is to define sources of import. However Graham actually asks for the ability to import from Nostalgia wiki, which is not a WMF wiki. This requires the second user right, which currently only available for 'Importer' user group. In addition this right is somewhat dangerous as it allows to import almost anything and is currently disabled on WMF Wikis. Enabling the second userright will be more difficult. Ruslik_Zero 19:06, 14 August 2009 (UTC)

Nostalgia is a WMF wiki. Majorly talk 21:18, 14 August 2009 (UTC)

Then it should be fairly simple to add nost: to the import list, so any admin could transwiki nost:saint; the only difference from any other wikipedia is the default skin. -Steve Sanbeg (talk) 22:24, 14 August 2009 (UTC)

It is a WMF wiki, but not a MediaWiki wiki. It uses UseModWiki instead. Import would therefore depend on what markup translation tools and functionality are available. –Whitehorse1 03:02, 15 August 2009 (UTC)

It uses the same version of MediaWiki as this site - it just uses the Nostalgia skin. See Special:Version on the Nostalgia Wikipedia. Graham87 07:47, 15 August 2009 (UTC)

Oh, also see my ramblings on this issue on the technical village pump back in October 2007, which didn't get much response. Since then, I've done a lot more exploration into old Wikipedia edits, and I've found many more cases where history in the Nostalgia Wikipedia would be handy to have in the English Wikipedia database. I think that for a start, almost all the history in pages that have been frequently edited at nost.wiki should be imported here. Graham87 08:18, 15 August 2009 (UTC)

I think a bug should be filed now. Ruslik_Zero 18:35, 16 August 2009 (UTC)

bugzilla:20280. –xeno^talk 18:57, 16 August 2009 (UTC)

Sounds great! Thanks very much. :-) I think I got a bit confused between the importer user rights, which are given to individuals who want to import pages from raw XML dumps, and adding sources for Special:Import, which allows all admins to import pages from specific sources. Graham87 06:27, 17 August 2009 (UTC)

There is another bug related to this topic. Ruslik_Zero 19:05, 18 August 2009 (UTC)

Yes, I noticed that prior to filing the more specfic report. Since there is no way to tell when 14264 will be fixed, 20280 is filed as temporary bandaid. –xeno^talk 19:07, 18 August 2009 (UTC)

Microformats

There is currently a discussion on Template_talk:Asbox#Microformats_in_stubs, about wether or not it is desirable to add microformats to stub templates. This would add special markup to for instance {{Ghana-stub}}, that makes it possible for a microformat understanding system to detect that "Ghana" means a place called Ghana for instance. The arguments pro are: does no harm, adds machine readable context. The arguments against are: adds extra complexity to stub templates, and stubs are not part of the "proper" article content, as well as "all these locations will get their microformat trough infoboxes in the future, why do the work twice". New insights are welcomed. —TheDJ (talk • contribs) 19:58, 17 August 2009 (UTC)

I agree that this is unnecessary and has little benefit. A stub template is a temporary thing, only lasting until the article is expanding. — Martin (MSGJ · talk) 21:17, 17 August 2009 (UTC)

A classic non sequitur. But please keep discussion to the linked page. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:55, 18 August 2009 (UTC)

Automatically create user subpage for new users

I understand and support the principle of Bold, but that guideline emphasizes editing existing articles, not creating a brand-new article from scratch with zero experience. While our guideline to writing one's first article mentions starting in user space, it is often ignored. New users are coming to Wikipedia, thinking they can create a brand-new article in mainspace and see it survive. I think the experience of pouring time and effort into an article in good faith, then seeing it disappear through CSD or AfD must be discouraging to people who might otherwise turn into fine editors. We do a disservice to potential new editors by not being clearer about the best way to write an article form scratch.

I have a simple solution.

Whenever a new person creates an account, I'd like to see the account prepopulated with a user subpage - call it user:Newname/My First Article

Populate it with some useful advice(e.g. "when you think this is ready, here's how to ask for editor review", and "here's how to move it to mainspace").

Automatically include a Notes section with {{reflist}}, as the creation of references trips up many new editors. I'm sure others can add to what would be a good new article template.

My guess is that a new editor who creates an article in user space, asks for editor review before moving, and then moves into mainspace will be much more likely to avoid CSD or Afd - probably by a factor of ten.

I see this as a major gain for a relatively small cost.--SPhilbrickT 16:59, 18 August 2009 (UTC)

Countless user accounts are registered and never used, all of these instances would generate a page that would then never be edited. I think the general concept behind this is sound, but the implementation should instead give the user an option "Click here to generate a user subpage that you can use to draft your first article" would be better. It could then preload the common elements and helpful notes you describe. –xeno^talk 17:02, 18 August 2009 (UTC)

xeno, I really like your version of the idea. hmwitht 17:05, 18 August 2009 (UTC)

I also wonder, as a less extreme option, if there's a link someone could click on the first article page that creates the page with elements and notes. hmwitht 17:08, 18 August 2009 (UTC)

xeno, I think I read recently that something like 99% of the disk space is images, so am I assuming correctly you are more concerned about clutter than space? If so, the page could have a 90 day expiration date. if it isn't used by then, they are probably not going to use it, or know how to create one themselves. I also like the "click here option". We work hard to put help everywhere, yet just about everyday someone is overwhelmed and doesn't know where to start. The "click Here" option would accomplish most of what I want. Hmwith, if I understand your proposal, it would be a link in the "first article" advice, where the user would click and it would generate a user page. I like that as well. That's a common manual task performed by many at the help desk—making it semi-automatic would help.--SPhilbrickT 17:50, 18 August 2009 (UTC)

Clutter, log entries, etc. I'd much rather the page be created only after some action by the user. –xeno^talk 17:52, 18 August 2009 (UTC)

It was never finished but I always thought and still think that the Wikipedia:Article wizard is one of the best ideas out there which addresses these issues and others. I think it could have a widespread positive effect on Wikipedia if it was finished and provided to new users in a way that was well calculated to get it seen by new users, such as through a link as Xeno suggested for subpages above, in welcome templates, and in other parts of user interface—things that would make it the default method that new articles were created. I may just make a second attempt soon to move it forward--Fuhghettaboutit (talk) 04:03, 19 August 2009 (UTC)

I like that concept a lot, but have some suggestions. This doesn't seem like the right place to trash out details- should I post at your talk page?--SPhilbrickT 22:51, 19 August 2009 (UTC)

I have for a long time been meaning to do something based on the AFC wizard (Wikipedia:Articles for creation/Wizard-Introduction), which is great and would only need minor tweaking I think (at least up to the point where we start talking about new page templates, which would be a natural extension). I wasn't aware of Wikipedia:Article wizard (or maybe I forgot), but that seems the place to house this. And Wikipedia talk:Article wizard seems as good a place to discuss that as any. Rd232 ^talk 23:09, 19 August 2009 (UTC)

I'm not sure that a new user would be able to know or even care if that subpage exists; the normal welcome page could just have option to create it, with appropriate text preloaded, i.e. :

To create your first article, just push the button, and fill in the text in that page

-Steve Sanbeg (talk) 19:11, 20 August 2009 (UTC)

This may be a silly question, but here goes anyway: Why should new users have an automatically-created userpage (or be prompted to create a user page)? -- Fullstop (talk) 19:39, 20 August 2009 (UTC)

Ah, because numerous new users create new pages that are immediately subject to speedy deletion as lacking context (WP:CSD#A1), having no content (WP:CSD#A3), failing to assert importance or significance (WP:CSD#A7) and so on. Moreover, with a controlled process, like some kind of article wizard, we would get new articles with categories included, foster proper formatting, teach compliance at least in some measure with the manual of style; we would be able to inform users of our policies requiring sourcing, and banning copyvios, and attack pages, and some users, not all but some, would not create some of these problematic articles. There are many benefits built in. Take a stroll over to Special:Newpages, sometimes called the "raging firehose of crap," and peruse for a while. Or take a gander at CAT:CSD where everyday we go to delete about a thousand articles because they are copyright violations, defamatory attack pages, resumes, vanity pages, unmodified spam, people scrawling messages to their girfriends, etc.--Fuhghettaboutit (talk) 00:16, 21 August 2009 (UTC)

That sounds a lot like the Article Launcher idea I brought up here a week or so ago that was kinda ignored. Guess I didn't explain it enough. Support. :)----occono (talk) 00:20, 21 August 2009 (UTC)

Site Notice for free images/Wikimedia Commons

With almost 3 million articles in the English Wikipedia, I wish that there was a site notice asking contributors/the public to upload their pictures with a free license to Commons. I think this is better than the site notice we have, currently. miranda 02:48, 21 August 2009 (UTC)

Alternative to the big orange bar when you have new messages

Just a thought but there should be an option for a less intrusive way to notify editors of new talk page messages, either by a selection in "preferences" or by a gadget. My suggestion (at least on the monobook skin) would be for "my talk" to be highlighted. Thoughts? --Ron Ritzman (talk) 22:15, 15 August 2009 (UTC)

I just came her to suggest changing it myself, but because I think for new users it could easily be mistaken for "You have 1 New Message!" spam banner ads.----occono (talk) 23:40, 15 August 2009 (UTC)

I just threw this together, which is a JavaScript workaround but allows for massive flexibility and integration with any part of the page in pretty much any way you like. Feedback on how to improve the script/description page would be greatly appreciated! Greg Tyler ^{(t • c)} 23:53, 15 August 2009 (UTC)

I'd support optional alternatives, but no change to the default behavior; there's no way I'd ever notice the "my talk" link being bold. The giant orange box? Pretty difficult to miss, which is the entire point. EVula // talk // ☯ // 17:20, 18 August 2009 (UTC)

EVula, I fully concur. I would miss anything less noticeable. Hell, I think I've missed the big, orange bar before. hmwitht 17:22, 18 August 2009 (UTC)

I agree with EVula. Optional atlernatives are okay, but the default notification should remain as the orange bar. --[midnight comet] [talk] 17:27, 18 August 2009 (UTC)

My problem is with "You have new messages." I think it's sounds too much like those scam banner ads.----occono (talk) 21:06, 18 August 2009 (UTC)

OK, I don't know how difficult this is, but here's what *I'd* like: Instead of the "latest change" link, there should be a button that takes you to the section in which the latest change occurred. I dislike clicking on "new messages" and then having to look for it, and the diff output is sometimes hard to read, in addition to being slow. --Trovatore (talk) 21:37, 18 August 2009 (UTC)

Why did you stress "I'd"? All suggestions are welcome...----occono (talk) 21:46, 18 August 2009 (UTC)

(EC) That would require some pretty critical parsing. Whilst some messages have the /* This section */ bit, others aren't made notice of. Some people edit multiple sections, others add their comments to the lead. So yeh, some serious clever parsing or a bit ol' PHP rewrite. It would be handy though, especially for long user talk pages. Greg Tyler ^{(t • c)} 21:47, 18 August 2009 (UTC)

I have to design the implementation too? :-). OK, how about this: Pull the anchor out of the edit summary, and use that for the link. It won't always be correct, but it should work 90% of the time. (Tangentially related project: Fix the code that generates those anchors, so that it works even when people have markup in section headings. I know you usually shouldn't have markup in section headings, but there are a few cases where it's tough to avoid.) --Trovatore (talk) 21:50, 18 August 2009 (UTC)

Yeh, that should be possible. I'll look into implementing it for my JavaScript code in the next few days. Greg Tyler ^{(t • c)} 22:02, 18 August 2009 (UTC)

Simply adding a (history) button (iirc there is a script that does this already) would allow you to use popups to view the page history, clicking the section anchor from there. –xeno^talk 22:06, 18 August 2009 (UTC)

That would save one click over the current way of doing things, and you still have to go find the section anchor in the history. I'd really like the link straight to the section from the bar, which would save two clicks and some mouse-searching. --Trovatore (talk) 22:50, 18 August 2009 (UTC)

Sure, it would be nice. –xeno^talk 22:52, 18 August 2009 (UTC)

If we are going to change it, interlock it: prevent any saves from occurring while there are unread messages. Removes any uncertainty as to whether someone has ignored a message prior to editing or simply hasn't read it yet.—Kww(talk) 16:45, 22 August 2009 (UTC)

Lock all edits? What about when you just want to pop on to change something, but want to leave the notification in place for when you log on more concretely? Greg Tyler ^{(t • c)} 19:35, 22 August 2009 (UTC)

Oh yes, no edits, no dessert, three hours of goose-step. BNW all around. NVO (talk) 19:55, 22 August 2009 (UTC)

I could strongly support a variation of this: if someone leaves a message on my talk page while I'm editing another page, and I hit "save page," WP should do that-thing-it-does when you try to create a new section without including a header: i.e. it should show a preview of the page with a caption at the top, "While you were editing, a message was left at your talk page. If you hit "save page" again, your edits will be saved; or click here to open the message in a new window." (i.e. new window because we don't want people's edits to get lost) Andrew Gradman ^talk/_WP:Hornbook 15:03, 23 August 2009 (UTC)

Interwiki synchronization

My propose is to use template en:Template:Iwiki-conflict for all pages involved in intewiki conflicts. More details you can find at page m:Interwiki synchronization and in template documentation. Also users who contributes in other language sections of Wikipedia can create translated analogues of template in those languages. If we will have similar templates in all languages we will be able to use bot to add template to all involved pages automatically. What do you think about this idea? DixonD (talk) 20:41, 16 August 2009 (UTC)

It sounds like a good idea, but I don't think it is important enough to warrant a message box on the article itself. I would have no problem with a message on the talk page though and I have boldly converted Template:iwiki-conflict for this purpose. Regards — Martin (MSGJ · talk) 07:59, 17 August 2009 (UTC)

Oh, I'm already answered for this here: Wikipedia:Requested_templates, but I think this page is more appropriate for discussion. Me comment there:

I think it have same importance as, for example, "This article is an orphan", "This article may need to be wikified" and other. Interwiki synchronization have very little attention from wikipedians because most of them not even know about it existence. If we set template on article, problem can be solved very quickly, but not if in talk page. DixonD (talk) 11:29, 17 August 2009 (UTC)

I think that creating a template which would add a category like "Articles with interwiki conflicts" wouldn't hurt, but I'm against putting big, glowing boxes everywhere. We've already got too many of them. Maybe it would be possible to put an info about the conflict directly into the interwiki box? For example a question mark next to the name of a language? The users of the language would notice it and, possibly, fix it. Lampak (talk) 16:41, 17 August 2009 (UTC) P.S. But I doubt it's technically possible. Lampak (talk) 16:45, 17 August 2009 (UTC)

I'm also have doubt that it's technically possible, but if yes in this case it is reasonable to put a question mark after all languages because we don't know what exactlyinterwiki caused conflict until it would be solved. But anyway I think moving info to talk page will cause that almost readers of article even don't notice that exists interwiki conflict. For example, look at Talk:Open source and Talk:Open source software. I'm really doubt that you notice from the very first that there exists some problems with interwikies:) DixonD (talk) 17:04, 17 August 2009 (UTC)

Have you seen Template:Interwikiconflict? — Martin (MSGJ · talk) 14:04, 23 August 2009 (UTC)

Question regarding Flagged Revisions

I was working on a proposal, but see it is largely a variation of Wikipedia:Deferred revisions and Wikipedia:Delayed revisions. Two questions:

1. I see the bug report for English Wikipedia, but I don't know when it might be fixed. Is there a rough guess (weeks? Months? Years?)
2. I see that it had been installed for other languages—is there any reason to think it would not work for Tagalog?--SPhilbrickT 13:02, 21 August 2009 (UTC)

Double redirects

As a follow-up to Wikipedia:Village_pump_(proposals)/Archive_44#Double_redirects, I posted a note at Wikipedia talk:Double redirects#Many double redirects are good. — Sebastian 00:47, 24 August 2009 (UTC)

Suggestion

August 24, 2009

Good Day Everyone at Wikipedia,

I´m sure you are used to getting congratulations from people all over the planet, and in many languages by now. Mine is adding another one to your collection for a job that is very well done and keeps on growing for the benefit of all mankind. In this regard, I wish to extend my best wishes to Jimmy Wales and to the entire team at Wikipedia.

I also have one or two suggestions to put forward for consideration.

The first one would be to add another portal to the list. Why not have a portal named say, Business and Economics. The portal would include such topics as accounting, bookkeeping, credit including defaulting/delinquency and bankruptcy, economics, finance, insurance, investments, mortgage and personal lending (could form part of credit or simply addressed separately), project management, qualitative analysis, quantitative analysis, risk management, statistics, and other related topics.

How would I initiate the separate portal one would ask? To begin with, I would classify each article listed in the 3 million plus articles currently in English, and show the classification next to the article name as a cross-reference. Example: Cat - Portal: Natural & Physical Sciences, sub category Biological Science. By classifying all articles, beginning with the English language, all articles that would be classified as part of the Business and Economics portal and the connecting sub categories would be appropriately identified, indexed and included in the new portal. Example: Balance Sheet – Portal: Business & Economics, sub category Accounting.

Accordingly, and in time, the new Business & Economics portal would not only be a comprehensive source of information for reference, but a self-teaching tool and guide on any subject that could otherwise be learned in school, university and of course applied in a real life environment. I believe that the separate portal approach could foster increased learning. For instance, someone accessing the Business and Economics portal directly may learn interesting and useful information that otherwise the person may not have been aware of from the main site.

In conjunction with Mr. Wales´s philosophy of capturing the sum of human knowledge in print form for easy reference by everyone, I believe the effective use of this information is to depict it as a self-teaching and tutorial guide so that people can not only inform themselves (passive approach), but also use this information for personal benefit and furthering human progress (creative, progressive and constructive approach).

Yours truly,

Charles Roy

• Hello Charles. It sounds like you would be interested (and, I'm sure, welcomed) at Portal:Business and economics. Welcome to Wikipedia!
  — Ω (talk) 02:59, 25 August 2009 (UTC)

Displaying a condensed entry/definition of a word when hovering over a link

Hello, I am a long time Wikipedia user, although I just signed up for an account today in order to post this message :p. I've noticed that when I'm reading an article, I often click on one or more of the links on the page to read about a related topic, or for more detail on a related concept, etc. More often than not however, I will click on a link only to explain or further my understanding of a concept that I'm reading about, or for a definition of a specific word, so I click on the link, do a brief read of the connected article, then go back and continue reading.

So, my proposal is that when you hover over a link in an article, a cursor pop up displays a condensed/summary entry of that related article, or a short definition of a word (if appropriate). Now I understand that this would take some time to implement, as summary entries would have to be created for pretty much every article, however I really think there are benefits to readability and comprehension of articles. Really the summary would just have enough info to give someone a rough idea of the concept or main idea of the related article, or a short definition of a word.

Anyone feel like this would be a useful change to implement on Wiki?

Thanks for your feedback.

We've got it already! They're called navigation pop-ups, and you can turn them on by clicking on "my preferences" (at the top of any page while logged in), then on "gadgets" and then checking the box for navigation pop-ups. DuncanHill (talk) 16:59, 15 August 2009 (UTC)

I'll also endorse the pop-ups. Sometimes, the popups contains enough information so that I don't need to visit at all ( a definition, for example) and other times the popups lets me know it isn't going to be the place I want to see. In short, I love them.--SPhilbrickT 23:10, 15 August 2009 (UTC)

Hey great! thanks for the heads up.

I would start a motion to make them default.----occono (talk) 03:47, 17 August 2009 (UTC)

I can support that. There may be users who don't want them, so I'd like there to be an option to turn them off. I'd leave the option, just change the default setting to "on".--SPhilbrickT 11:10, 17 August 2009 (UTC)

I think a lot of people would want to turn them off right away. I got sick of them very fast (every time I moved my mouse, I was accidentally triggering a new pop up). Still, I could support this idea as long the option to turn them off were very transparent, e.g. available within the popup itself. Andrew Gradman ^talk/_WP:Hornbook 14:53, 23 August 2009 (UTC)

I tried it and couldn't stand it. I think a better proposal, since all users have the option to turn it on, is to have some kind of a banner ad once in a while to make users aware of it. Noisalt (talk) 11:38, 25 August 2009 (UTC)

Proposal: eliminate silly bureaucracy at AIV

Something I've encountered from time to time is what appears to be bureaucracy for its own sake at AIV. Depending on which admin sees a report (not necessarily mine, but anyone's) a blatant vandal-only account may be blocked, or the block request may be declined because the person "hasn't been warned enough or has been incorrectly warned". Apparently, you have to go in order from Test1 through test4 before they can be blocked.

I don't understand the value in giving 4 warnings to people who are obviously here to play games by creating new articles of patent nonsense or spam about their bands, then continually recreating them after they've been speedied multiple times. 90% of them are bored kids who know exactly what they're doing is wrong. The other 10% are pretty obvious to anyone who is not a total blockhead, and can be helped along.

AGF and welcoming new editors should not be a suicide pact. Obvious trolls who are reported at AIV should just be blocked, without having to go through the process of placing 4 warnings (that will just be ignored), reverting more vandalism and tagging more garbage pages for speedy, before someone is willing to block them. Come on, we're not vogons! <>Multi-Xfer<> (talk) 00:46, 19 August 2009 (UTC)

There really isn't as much silly bureaucracy there as you might think. The real key is, if it's conceivable that someone is just experimenting, or doesn't realize how annoying their edits are, then we assume good faith (you knew someone was going to say that, right? At least I didn't link it) that they can be turned from the dark side. You don't want to give an obvious vandal 4 bites of the apple, but you do want to give experimenters a few bites. For example, someone creating an article about their band is not really a vandal; they're new, and don't understand the rules, and (if their article is speedy deleted) likely cross. The warnings try to explain this. Only if they ignore the warnings and repeatedly re-create do we want to block them.

A couple of pointers: First, there's no requirement that all four warning levels are used; I often go the level-1, level-3, level-4, report route, or sometimes level-1, 2, 3, report. You'll get your wrist slapped if you start off with a level-4 for "hi mom" edits, but if you give them a gentle warning, a stern warning, and a warning mentioning blocking, and they keep it up, they'll get blocked. All admins are using their own judgment, so you can't really force someone to block if they don't think it's appropriate yet. I agree that sometimes requiring even three warnings is obviously not needed (e.g. "ha ha I'm vandalizing and you can't stop me"), but it has been my experience that if you take the time to clearly explain why the editor you are reporting should be an exception to the general rule, an admin will block them. That's a fast-moving place, so you can't expect them to read your mind. An extra sentence in the report saying "exact same article vandalized last month until the IP was blocked" (or whatever) makes all the difference. --Floquenbeam (talk) 01:27, 19 August 2009 (UTC)

Floq has hit the nail here. AIV is a bit of a nuanced venue, we have to strike a balance between not biting newcomers and preventing damage to the encyclopedia. Some vandalism warrants a block without warning, whereas some just need gentle coaxing to cut it out. And don't forget that this user is now a positive contributor (people are probably sick of me pointing that out by now =).

For my purposes I usually start with {{welcome-vandal}} for named accounts, followed by an L3 (which is also my usual starting point for anything except mild test-edit type vandalism) for IPs, and go from there. I guess the point I'm getting at is, context matters.

In any case, AIV is getting replaced by an hyperspace bypass next week, so none of this will matter. –xeno^talk 01:33, 19 August 2009 (UTC)

I myself nearly always go 1,2,4 - only rarely using level 3 warnings. In most cases, you know after two edits (and almost certainly after 3) whether someone is likely to persist in bad edits indefinitely; I've felt for a long time that we should only have three levels of warnings, with perhaps a single "we will block you" warning as the equivalent of a fourth level. If there's consensus here, that's the simplification I'd most like to see. — Gavia immer (talk) 01:59, 19 August 2009 (UTC)

Another important aspect imo is timing. I often find users who received a level 1 warning then, probably thanks to Twinkle and Huggle, received a level 2 for vandalism occurring before the level 1 warning. I'm unlikely to push to 4 in that case, for example. You really need to, as Floquenbeam and Xeno said, judge each situation individually. ~ Amory (user • talk • contribs) 02:25, 19 August 2009 (UTC)

I guess my question is, if there is a pattern that [some] administrators will only require three warnings... why do we have four? I think the points the OP makes are correct to make in some ways; he makes the point that it is bureaucratic to say "we require four, because that's how many warnings there are"... --Izno (talk) 03:03, 19 August 2009 (UTC)
PS: Hyperspace bypass? =d

I don't know of any admins that require that all four warnings be given, but they do tend to enforce that the last warning be a level-4 warning. I generally skip level 1 unless I can convince myself that the edit might have been accidental, and I don't have reports rejected. It is important that the last warning explicitly say that the next edit will result in them being blocked, and that the edit they are supposed to be blocked for happened after that warning was given. I don't think that's excessively picky.—Kww(talk) 03:16, 19 August 2009 (UTC)

Agree with all that it's a balancing act. Most admins do not robotically require 4 warnings. There just one kind of page that in my book it's a very bad idea to even give more than one warning: vicious attack page on apparent BLPs (which I block on sight with no warnings).--Fuhghettaboutit (talk) 03:52, 19 August 2009 (UTC)

I spose the reason I bring it up was because of a report I made earlier. I frequrntly patrol newpages. Someone had been creating and recreating nonsense articles and it was pretty obvious they knew what they were doing... they had ignored multiple deletion notices and had been warned, first with test1 and then after they recreated the articles a couple more times (and had then speedied) I left a test4. Reported to AIV, and was told they had been insufficiently or incorrectly warned and to come back to re-report if they kept it up. They ended up being blocked by a different admin after they continued recreating the same nonsense articles. I do think n00bs and someone who just doesn't quite get it should be given some leeway, but I also tend to think (or hope) that most people would realize that after the third time their article that is just a few sentences saying "my death metal band is the greatest in the world, etc. etc., they would happen to notice that it keeps getting deleted and that the related warnings I've then left on their page (usually test1 or test3, depending on how blatant their vandalism is) probably mean something. I HAVE noticed that different admins tend to react differently... some seem to think as I do and issue blocks to people who are obvious vandals (at least as I see it), while others are in the middle, and still others are hesitant to block almost anyone unless the full gamut of test1-4 has run, perhaps several times, and even then they only give a 6 hour block. A lot is up the the interpretation of the individual, I just wish it was easier to get obvious vandal accounts blocked straight away without several warnings, which they're probably just laughing at anyway. EDIT: You all have good points. Floq makes sense to me. <>Multi-Xfer<> (talk) 04:48, 19 August 2009 (UTC)

Obvious vandal IPs should be blocked straight away if there's a pattern (if it's just a one-off, then forget about it). Obvious vandal accounts should be blocked anyway (to prevent their becoming autoconfirmed). If it's not obvious (they might be just experimenting) then warnings might be appropriate before blocking (I would have thought 1, or an absolute maximum of 2, warnings would always be sufficient). We should show our genuine editors and our readers more respect than to allow preventible damage to our encyclopedia; we should certainly show vandal-fighters more respect than to make them waste their time jumping through hoops. (If a vandal is going to reform, then they can do so after the block has expired, or apologize and ask for it to be revoked - if they really are interested in contributing positively, they'll understand why the block was placed, and hopefully be encouraged to contribute knowing that steps are taken to protect their contributions from damage.) --Kotniski (talk) 09:13, 19 August 2009 (UTC)

Hey, if no-one disagrees with this view of the matter, perhaps it's time to make it the policy... Or are there counterarguments?--Kotniski (talk) 14:09, 22 August 2009 (UTC)

The process works pretty well as is, I don't see a compelling reason to change things. Someone who stops vandalizing of their own accord after a couple warnings is much more likely to become a useful contributor than someone who is blocked right out of the gate. RxS (talk) 14:24, 22 August 2009 (UTC)

Do you have any evidence for that? Remember that "being blocked" doesn't have the same meaning to a casual vandal that it has for us. And the process might work fairly well, but still lots of effort is being wasted reverting preventible vandalism and giving pointless warnings, and much vandalism is getting through, damaging our encyclopedia and possibly deterring many times more people (non-vandals) from contributing (if you think what you write is likely to get vandalized anyway, why waste your time?) I think this "vandals may reform" argument is pretty thin (few are likely to reform anway; and being blocked shouldn't stop them reforming).--Kotniski (talk) 14:39, 22 August 2009 (UTC)

Reading this my conclusion is that we should change the advice we give, particularly in relation to obvious vandals. I agree with Kotniski. Dougweller (talk) 14:51, 22 August 2009 (UTC)

Do you have any evidence that vandalism is keeping new editors from editing? I see a lot of generalities here but nothing very specific. The current process gives admins the flexibility they need to be nuanced. I've blocked vandals with only one warning (or in some cases no warning at all) so none of this is written in stone. Some (not all) vandal fighters can be over zealous and we shouldn't be making it easier to bite new users. Like I say, the process works fine now, there's no compelling reason to change it. Not biting newbies is more important than saving vandal fighters time. RxS (talk) 15:08, 22 August 2009 (UTC)

You say nothing is written in stone, but then we hear of admins who refuse to block vandals on the grounds that they haven't received the right number of warnings. If the instructions made it clear (much clearer than they do now) that warnings aren't a prerequisite for blocking, then I think admins would feel far more flexibility in blocking where appropriate. We should certainly make it clear as well, though, that this only applies to obvious vandalism (like adding swear words). Inappropriate warnings are as much biting of newbies as inappropriate blocks - that's a rather different issue. We're talking about here people who are clearly not newbies at all, they're here to harm us, and while we can still be polite to them (in case they wish to become newbies sooner or later) we can certainly stop them from doing more harm.--Kotniski (talk) 15:44, 22 August 2009 (UTC)

I'd like to see evidence of reports being turned down at AIV because there weren't four warnings. I see a lot being rejected because there wasn't a final warning given, but that's a substantially different issue than insisting on the complete 1,2,3,4 sequence.—Kww(talk) 16:47, 22 August 2009 (UTC)

It's still silly bureaucracy, as the OP says. is In fact my own experience of AIV has been pretty positive - if there's a vandal on the loose, someone will block without insisting on a warning - but the instructions we give don't make it look like that. Hence many people are doubtless discouraged from reporting when it would be beneficial for the encyclopedia for them to do so.--Kotniski (talk) 17:04, 22 August 2009 (UTC)

(outdent) The ideals behind the 'beyond a reasonable doubt' standard in courts is often summed up in civics class as an expression of the idea that we'd rather see 10 guilty people walk free then one innocent man put in jail. As a core principle of the project we have held that letting a vandal screw a few, easily reverted edits is the price we pay for making sure we dont scare off bright eyed potential contributors. One may call replacing the Kleenex article with "FUCK OFF!!" vandalism, but its just as likely to be a well intentioned, if crude, test. One may argue for or against this approach, but like the conviction standard mentioned it's largely set in stone at this point- for the right reasons. --M^ask? 09:15, 25 August 2009 (UTC)

What? Nothing's set in stone; no-one's being put in jail. Bright-eyed newbies don't do that sort of thing (or if they do, will understand why they get blocked for it); real bright-eyed newbies are many times more likely to be deterred from contributing when they see that the resident bureaucracy takes the side of vandals over genuine editors.--Kotniski (talk) 09:46, 25 August 2009 (UTC)

Policy and Guideline improvement drive

Is it time to set aside some community resources in order to conduct a "Policy and Guideline improvement drive"? Just thinking about it, it's possible that Wikipedia has recently (as in the last year to 18 months) reached some sort of tipping point. There are more then 3 million articles now, Wikipedia is regularly featured on Google, the user-base has changed both in size and character, and governance itself has significantly evolved. I don't have anything really specific in mind other then an amorphous feeling that some policies and guidelines are showing their age. There does seem to be a lot of conflict that occurs still, and some of that is sometimes due to (lacking) policy in my opinion. And then there are real issues such as the deletion policy... Anyway, I was just thinking about this for some reason, and wanted to bring it up.
— Ω (talk) 11:16, 23 August 2009 (UTC)

YES. Our policies are so illegible. I not only support this, but volunteer to print the bumper stickers. Andrew Gradman ^talk/_WP:Hornbook 15:07, 23 August 2009 (UTC)

PS my personal interest has less to do with changing than with clarifying policies. But in my recent experience, whenever I've tried to clarify a policy, I've revealed that "purpose" of the unclear language was to obscure the fact that people never did agree on that point; the language is intentionally ambiguous to make both parties feel like they'd won! Andrew Gradman ^talk/_WP:Hornbook 15:10, 23 August 2009 (UTC)

That actually brings up a fundamental question that we should probably have a discussion about. Traditionally, Wikipedia's policies and guidelines have intentionally been more descriptive then prescriptive. I don't think that should be completely abandoned, but perhaps it should start to bend a bit more towards the prescriptive side now. After all, there has been a quite decent amount of history developed now which could and should guide us into the future.
— Ω (talk) 22:24, 23 August 2009 (UTC)

Note: After writing this, I've discovered that I'm not the only person to have had similar thinking. See especially Wikipedia:Areas for Reform#Poorly written policies. I was actually thinking of a wider, more purposeful effort here, but I have no problem with connecting onto an existing effort and attempting to propel it forward.
— Ω (talk) 05:13, 24 August 2009 (UTC)

There's also WP:WikiProject Policy and Guidelines and WP:WikiProject Manual of Style, which have similar aims. Some of us spend quite a lot of time trying to improve the policies and guidelines, but it's a task you quickly get fed up with, since there are always people fighting to preserve some piece of text, however nonsensical, because they think it helps them win arguments or they think Wikipedia will collapse without it.--Kotniski (talk) 08:01, 24 August 2009 (UTC)

Yes, I'm starting to get a sense of what you're referring to just by reading some of the talk pages and what's occurring on Wikipedia:Areas for Reform. What I was thinking about should actually be a means to break that sort of logjam, though. The best way to break up the sort of internecine battling that you're talking about it through the injection of "fresh blood", after all. If we prominently advertised a general improvement drive that should prompt some people who do not normally participate in actual policy/guideline formation (such as myself...) to at least take a look at, and be encouraged to edit, said documents.
— Ω (talk) 09:22, 24 August 2009 (UTC)

My first thought on reading this was, "Why? You don't have enough people mad at you right now? Why not go edit Creationism or Chronic fatigue syndrome instead?"

Seriously, it would be possible to improve some part of nearly every policy or guideline, but I think you'll find it's a bit more complicated than just "fixing" whatever doesn't look perfect on reading over the policy. Imprecision and infelicitous language is frequently present for a reason. The (good) reasons range from a clear and documentable lack of actual consensus on the ground to editor confusion to plain uncertainty about what the consensus is. You'd be better off adopting a single page, or a cluster of related pages, and hanging out for a month to figure out the actual problems that the page is trying to address.

For example, one guideline repeats the same statement four times (a "This is not WP:RS!" statement), not counting the big orange banner at the top of the talk page -- and it still gets editors asking whether it's the right page to complain about reliable sources. From a literary perspective, this level of redundancy is poor, but I regularly think about making these messages more aggressive. Perhaps a click-through-for-content screen would help, with big red text that says something like this: "If your question has anything at all to do with a reliable source in an article, then you are in the wrong place. Click here for information about reliable sources. Click here for questions about formatting citations to reliable sources. Click here to indicate that if you proceed to this page, which has bloody nothing to do with reliable sources, and then you ask about a reliable source anyway, you agree to be publicly laughed at and to display a Barnstar of Shame at the top of your user page for the next week."

(It will never fly: there are too many friendly editors at the page.)

Again: Please help out. These pages regularly need people to just show up and give their opinions. But do it carefully, after you've learned what the most frequent questions are, not as a big "fix it all now so we can be done" push. WhatamIdoing (talk) 19:09, 24 August 2009 (UTC)

You're actually describing the problem perfectly. The reason that a "Wikipedia wide improvement drive" would be a good idea is to correct the problems that you're touching on above. The reason that those problems exist is largely due to the inconsistent, and ad hoc, manner in which policy and guidelines have developed over time. There's nothing at all unusual occurring here on Wikipedia (other then possibly the size of the project), we simply need to, as a community, accept the fact that we're not exceptional and therefore be willing to attempt to learn from existing managerial and community building resources. Aside from that, I don't find the fact that an improvement drive may initially create some controversy as a convincing argument against doing it. That's just a cop out.
— Ω (talk) 02:52, 25 August 2009 (UTC)

Agreed with WhatamIdoing. Policy is hard. Respect is earned. If you want to jump in hip deep and make lots of changes, go right ahead ... just be ready to listen to what people are saying if you get reverted. Some odd-looking language is there for a reason; some can be replaced without harm. - Dank (push to talk) 03:03, 25 August 2009 (UTC)

Where in the world is the perception coming from that this is some sort of personal crusade on my part, or something? I'm not talking about me or my opinions. Nor am I talking about respect (where did that come from? I detect a hint of some sort of Ego issue, here). I'm bringing up a proposal for a site wide event here, I'm not advocating for any particular changes. Even based on my own long standing personal experience with online communities this is turning... weird. Surreal, even.
— Ω (talk) 04:49, 25 August 2009 (UTC)

• A few comments --

1) WhatamIdoing, that was a very insightful post just there. I have gotten burned so many times in the last few months trying to make what (I thought) were cosmetic edits on policy pages; the forces controlling the weather on their talk pages is simply unfathomable.

2) Ohms law, I think this is just an instance where the internet has made people's comments seem dryer than they were intended (I would like to think that Dank was writing in a hurry?) ... A lot of people (like me) already respect what you're doing; we just don't envy you!

3) I agree with WhatamIdoing that the most effective method will be to "adopt a page". Over at WP:WikiProject Policies and Guidelines, when I added my name to the list of members, I noticed that there's some invisible text which encourages people to venture off on their own; I think that should change.

• Many thanks for undertaking this thankless work... Andrew Gradman ^talk/_WP:Hornbook 05:23, 25 August 2009 (UTC)

I agree with the many editors who suggest adoting a specific policy and joining the several people who work to improve it. But let me provide a little context for WP:Areas for Reform. There was an atempt by the ArbCom to create a policy committee, precisely because ArbCom flt there was a need for reform. There was an RfC in which many people - close to a hundred - participated. Most agreed that there was a need for reform; some agreed with the way ArbCom was going about it, and some agreed on a particular direction for reform. Others agreed there was a need for reform but objected to the way ArbCom was going about it, and objected to diferent directions. Although I expressed a stong position in the RfC, it seemed to me that Wikipedia could use a space where people advocating any direction of reform could develop proposals. When I created "Areas for Reform" I started with specific questions that people on all sides of the RfC had raised and left a means for people to add new questions. There has been ongoing discussion there since. I invite people here to take a look at the diferrent questions being discussed. I close with one plea for the value of such a page (which I think Ohm shares, given his actions here): people working on a policy are doing so in isolation of more general trends and arguments at Wikipedia and are often focused on very specific issues pertaining to that policy. When ArbCom tried to create a policy committee I think they were expressing the need for a group of people a little insuated from the demands to solve urgent problems ight away, but who were also thinking about the "big picture" of where Wikipedia is going, what it can and ought to be. I think there is a need for this kind of discussion, I just do not think it should be limited to an exclusive group of people. I hope other editors who are thinking about "the big picture" of how Wikipedia is functioning will see whether any of the questions currenty being discussed at WP:Areas for Reform get at something important. if so, I hope they take advantage of that space as a place to brainstorm without having to worry about immediate consequences (yet), and then as a place to generate proposals for new policies or proposals to change existing policies ... which can then be taken to the appropriate policy talk page. I think this process might help generate fresh ideas. Slrubenstein | Talk 08:51, 25 August 2009 (UTC)

I wanted to mention that, as I noted above, I discovered the WP:Areas for Reform project page after starting this at Village pump (misc.) but before moving it here to (proposals). I did consider removing this or modifying it to just point there, but I ultimately decided against doing so. I see this as something complementary to the Areas for Reform effort, not as an effort to compete with it. As mentioned, it seems that I'm not the only person to recently express some concern about the general state of our policies and guidelines. I believe that the Areas for Reform effort is an important project to undertake from a strategic level, but I also feel that a general "let's push to improve what currently exists" effort is also important from a tactical level. Re-reading the statements by WhatamIdoing (talk · contribs) above, I think that (s)he even agrees with this general thinking, based on the expressed "adopt a policy" line of thinking. A more informal, be bold style effort to just get people to look at and make an edit to some policy page is something that I see as being helpful, and at the same time conforming to "the Wikipedia way". I have a theory that one big reason most policy and guidelines are in the state that there in is a perception that their somehow "special", and a feeling of "I'm not important enough to edit them". That is what I'm attempting to address, here.
— Ω (talk) 09:19, 25 August 2009 (UTC)

External links noticeboard

Why isn't there an external links notice board?Smallman12q (talk) 14:54, 19 August 2009 (UTC)

What exactly would you like to see happen at such a noticeboard? WP:AIV already deals with persistent spammers. WP:RSN deals with the reliability of references to external links and WP:SPAM deals with most spam-related issues. Cool3 (talk) 15:08, 19 August 2009 (UTC)

Agreed with cool. Such a noticeboard would be redundant, and only encourage forum shoppers.--Unionhawk ^{Talk E-mail} 15:52, 19 August 2009 (UTC)

There was a discussion about it before, and I for one would love to have one (as it's not always spamming really even if they are inappropriate), but it was shot down, as it seems to be again. ♫ Melodia Chaconne ♫ (talk) 16:19, 19 August 2009 (UTC)

(ec)I brought up discussion of an external links noticeboard at the pump awhile back, but interest kind of fizzled out. Looking at WT:EL, it look like there might be a more pressing need for one than ever. How would I go about getting approval for such a board? I fully disagree that such a noticeboard is redundant, as there are many issues that come up when dealing with external links that are not spam, nor vandalism, and external links do not fall under our policy on sourcing. Relevant issues would include gathering a consensus on individual cases where links may or may not be appropriate, which isn't relevant to our EL guidelines as a whole (and therefore are not appropriate on WT:EL). ThemFromSpace 16:20, 19 August 2009 (UTC)

It would be a place to gather consensus on whether or not to include links and which ones. Aside from spamming...and all those other vandal issues, according to WP:EL, links should be kept to a minimum. And while disputes over which links are pertinent and best represent the topic are rare, they do occur. Currently other than the talk page, it is difficult to get other people's opinion as there is no place to go.Smallman12q (talk) 18:39, 19 August 2009 (UTC)

Perhaps the new WP:Content noticeboard could handle these issues. Rd232 ^talk 23:04, 19 August 2009 (UTC)

It doesn't really seem pertinent(while external links are "content" they're really an annexation of sorts to the actual content. Can't a "trial run" be done?Smallman12q (talk) 00:43, 20 August 2009 (UTC)

If I were to go about setting up such a board, how will I have to get it done? I'm thinking of setting up a draft version in my userspace and polling around to get input/feedback on it, and then perhaps moving it to the mainspace to try some discussions. What are any formal hurdles that I would need to get through to go about doing this? ThemFromSpace 03:38, 24 August 2009 (UTC)

That's basically it. Create a draft in userspace...get some feedback(rfc). If you receive an overall positive response(a consensus), take it to main article space...and enjoy=D. It's a rather informal process as there aren't many notice boards being created. I fully support an external link noticeboard creation ^.^. (Wikipedia:Noticeboards doesn't have a "creation" section, perhaps one should be added). Cheers. (Please include a link to your draft noticeboard, I'd like to assist in its creation.)Smallman12q (talk) 14:29, 24 August 2009 (UTC)

I set up a draft at User:Themfromspace/External links noticeboard, based off of several of our other noticeboards (mostly COIN). Feedback is requested to determine the scope of the board and to gauge the level of interest and likely participation. ThemFromSpace 23:32, 24 August 2009 (UTC)

Because it would be full of people who think every external links is spam. --Apoc2400 (talk) 15:45, 26 August 2009 (UTC)

Policies and guidelines should include citations -- to the talk page archives

We would use <ref group="arch">, where "arch" stands for archive. These footnotes would be invisible by default, until users make them visible in their preferences.

Just as lawyers consult legislative histories and precedents before making an argument in court, our editors (ought to) explore the archives to examine whether proposed changes to policies and guidelines are consistent with well-reasoned consensus (as I have done here). However, lawyers have the advantage of "annotated" codes and citators. I'm proposing something like that for our own policies.

Some of you have been here since the beginning, but I'm barely a year old. I am constantly proposing changes to our policies that, it turns out, were thoughtfully considered and rejected years ago. I think this proposal could cut back on ill-considered churn by people like me.

PS If this proposal was considered and rejected already ... that supports my argument ;) Andrew Gradman ^talk/_WP:Hornbook 01:42, 22 August 2009 (UTC)

Sounds like an interesting idea, but also hard to implement I think. But I agree that it would be very helpful in preventing the same old discussions coming up again and being rehashed over and over. BTW have you read through WP:Perennial proposals? -- œ^™ 04:31, 22 August 2009 (UTC)

yeah, the "default invisible" was just an added frill. Optional. If it's the achilles heel, strike it out ... Andrew Gradman ^talk/_WP:Hornbook 04:52, 22 August 2009 (UTC)

Regular refs would work, even if not pretty --Kim Bruning (talk) 08:29, 22 August 2009 (UTC)

Unfortunately policies and guidelines have evolved in a very messy way. The worst thing is that there is no procedure for establishing whether there is consensus for something or not - basically Ps&Gs are shaped either through edit warring, or through someone sneaking something through without it being noticed. Only a few people take an interest in the content of any given page, and hence it is their views that are reflected on that page, not those of the community. Consequently different pages often come to contradict each other. Even tidying them up to make them more readable and comprehensible often meets with resistance from individuals who treat particular tracts of text as some kind of immutable scripture. I don't believe these pages have much effect on what actually happens on WP (except when their words are interpreted to mean something they weren't intended to), but the sorry condition (and excessive number) of them must surely confuse and even deter new contributors.

My vision is that Wikipedia should have nice, tidy, structured documentation that makes it easy for people to find the information they need - whether about the project in general, how to use the software, or about what is considered good practice on WP. (I would put all this in the Help: namespace, leaving the Wikipedia: namespace for process and discussion, but that's a detail). Disagreements about what actually is good practice would be resolved through RfC's or similar, but with clear results (i.e. closure by disinterested parties if necessary). So to get back to the point, yes, we should have links to discussions as references where that would be helpful, but those discussions should have a clear conclusion that shows why the recommended practice is supported.--Kotniski (talk) 09:21, 22 August 2009 (UTC)

The trouble is that the archives for the most-relevant pages, over time, have become ENORMOUS. Many archives for the Manual of Style, the Village Pump, the Reference desk, the Help desk and their sub-pages are in triple digits. And as questions revive, or come up in slightly different ways, they'll appear in discontiguous archives. I encountered this recently when trying to find out if Bernhard Weiß was an acceptable form for an article title in English Wikipedia. The search-function yields four or five different archives on the "Es-zett" question, one or two from the main Wikipedia Talk:Manual of Style and others from the talk pages of more specialized MoS sub-pages. It would be terrific beyond words if an archive link could take you directly to both the original and the most recent discussions of a question, but it's hard for me to conceive of a way this could be done. —— Shakescene (talk) 20:26, 22 August 2009 (UTC)

A fair portion of my WT participation is pointing out previous discussions on similar topics, with and without additional commentary. Flatscan (talk) 05:03, 23 August 2009 (UTC)

The other trouble is that policies and guidelines and essays are basically just summaries of consensus over the entire wiki, so there are no clear discussions to point to.

Establishing whether something has consensus can be done through WP:SILENCE, which is admittedly messy.

Clarity may come at the cost of disenfranchisement.

Perhaps a clear procedure could be written out in some external document, not subject to politics, with the understanding that the document is not binding?

That said, some references are better than none. We could refer to meatball: discussions, outcomes and solutions from talk pages of articles and etc, particularly wise things from archives, etc...

--Kim Bruning (talk) 00:31, 23 August 2009 (UTC)

I suppose the next step would be for me to write an essay, in my userspace (and possibly later at WP:WP policies need citations, too), laying out the reasons for this, and some responses to the objections; then I'll tell people about it on the talk pages of a bunch of polices/guidelines, and get more feedback on the talk page. (Of course, until I do create that essay, keep putting feedback here.) Andrew Gradman ^talk/_WP:Hornbook 15:21, 23 August 2009 (UTC)

You're best bet is to try and add refs to some high profile policy. It may or may not catch on. - Peregrine Fisher (talk) (contribs) 16:22, 26 August 2009 (UTC)

No need to make them invisible. It's already being done... what was it, WP:OFFICE? has some ref content at the bottom. The only problem is that some people might take this to mean that consensus can't change, but that's a problem best handled elsewhere.    M   23:18, 26 August 2009 (UTC)

New option

It would be cool if there was a new option to automatically watch pages.Accdude92 (talk) (sign) 17:09, 26 August 2009 (UTC)

There are some options in your preferences I think. - Peregrine Fisher (talk) (contribs) 17:11, 26 August 2009 (UTC)

Yeah. In the "watchlist" section of your preferences, there are some boxes which, when checked, allow you to automatically add pages you edit, move, and create to your watchlist. ~ Amory (user • talk • contribs) 17:31, 26 August 2009 (UTC)

ITN change

Just an FYI, that there is a discussion occurring about possible changes to the ITN section of the main page, located here: Template talk:In the news#Use of Wikinews. Feel free to jump in on the conversations!
— Ω (talk) 09:42, 27 August 2009 (UTC)

Independent Reviews

Has anyone considered the idea of having Peer reviews by experts in fields who aren't members of Wikipedia? i.e. Having people who run a website about gardening do a review of a gardening-based article?----occono (talk) 23:26, 27 August 2009 (UTC)

Wikipedia:External peer review? Nanonic (talk) 04:27, 28 August 2009 (UTC)

I see, thanks :)----occono (talk) 09:11, 28 August 2009 (UTC)

This is a minor edit option is unnecessary

Since there is a kilobyte counter there is no need to have a minor edit option. If the edition is smaller then 500 k, the system should automatically save it as m. --Janezdrilc (talk) 14:42, 28 August 2009 (UTC)

I think you misunderstand the meaning of minor edit. It doesn't have to do with the byte size. A 0 byte edit could be considered a "regular edit" (it could be a controversial change that should not be marked minor) and a 500kb edit could be considered a minor edit (rolling back vandalism). Please see WP:MINOR –xeno^talk 14:47, 28 August 2009 (UTC)

What if I rewrite an entire paragraph? That is certainly not minor, but may only result in a difference of a few bytes. The current system works best, IMO. Dendodge _T\^C 15:09, 28 August 2009 (UTC)

Remove the sandbox functionality from the intro page

{{unanswered}}

I am talking about Wikipedia:Introduction, a page that welcomes our new users. The page has sandbox functionality, in other words, the users are free to make test edits there as long as the intro template stays untouched. Too bad it doesn't, and new editors may be greeted by something along the lines of "lol wikipedia is teh suxx0rz haxd" or "Get stuff online www.fakesite.com". This is mostly incompetence and misunderstanding the purpose of the page instead of actual vandalism, but to ensure that the page looks the way it's supposed to when a new user views it, I suggest we remove the sandbox functionality from this page altogether. Obviously, it's good to have a sandbox page for our newcomers, so I suggest editing our current sandbox template to point forward to Wikipedia:Introduction_2 (titled "Learn more about editing") so new editors wouldn't have to look for the next page of the introduction OR creating a new sandbox page between the first and the second introduction page. Any support, comments, suggestions? Kotiwalo (talk) 19:03, 19 August 2009 (UTC)

I would vehemently oppose such a change. It's really helpful, in my opinion, to be as encouraging and as forthwith as possible with readers and editors alike when they reach Wikipedia. If anything, the links to WP:Introduction should be more prominent on the Main Page. The more links someone has to follow, the less likely she or he is to actually follow them. Yeah there's vandalism there, but the vast majority of it is really just people flexing their wikimuscles and testing their boundaries. Besides, unlike most other areas, it's not really harming anyone greatly. Screwing with a sandbox makes it worse for the next guy, but it's not exactly libelous. ~ Amory (user • talk • contribs) 01:43, 20 August 2009 (UTC)

Yes, screwing with a sandbox wouldn't be a big deal, but it's also our introduction page, and since many new editors have wiped out the welcome template, either accidentally or intentionally, there is a good chance of our new editors being greeted by profanity or other not especially "welcoming" content. It wouldn't matter as much if there was a way to ensure that the welcoming template wouldn't be deleted, accidentally or in bad faith. Kotiwalo (talk) 09:53, 20 August 2009 (UTC)

Why not add something like the sandbox header, so that the page would get refreshed with the proper content every 12 hours? Warrior4321 22:00, 20 August 2009 (UTC)

There is one on the intro page I guess, but it would have to be cleaned after every single edit to ensure that the template stays intact, and that would take away the entire point of the sandbox. Separate page would be better. Kotiwalo (talk) 05:41, 21 August 2009 (UTC)

Is there anyway you can divide the page so one part(or section) can be semi-protected and the other part gets cleared every 12 hours? Warrior4321 17:47, 21 August 2009 (UTC)

I'm very sure that there's a way but I'm also rather sure that it won't be too quick an' easy. Kotiwalo (talk) 18:23, 21 August 2009 (UTC)

Perhaps creating a page with the introduction on another page (like the sandbox header), and then transcluding it into there? We can place a invisible comment right beside the transclude, telling them to leave it alone? That would provide new users who are not sure where to edit much more room. Warrior4321 19:22, 21 August 2009 (UTC)

Actually the intro page has the following:
{{Please leave this line alone}}
<!-- Feel free to change the text below this line. No profanity, please. -->
Sadly, this doesn't always work. Kotiwalo (talk) 08:11, 22 August 2009 (UTC)

(outdent)I have recently been watching the introduction page. No idea how that started, but I regularily check out the new user contributions and revert offensive or immature edits. It has begun to irk me that the message we use to greet newcomers is routinely vandalised into absolute nonsense. Wikipedia is not the place to read about ketchup farts, or at least a main page isn't.

I wish to propose that the page for editing WP:Introduction redirect to the page for editing WP:Sandbox. This way, new users can read the introduction, still click edit, and edit the sandbox instead of defacing the message that they just read. WP:Introduction could then be protected from editing. - ʄɭoʏɗiaɲ ^τ _¢ 14:01, 22 August 2009 (UTC)

I really like that idea! Any idea, how we could edit the edit button? Warrior4321 19:11, 22 August 2009 (UTC)

Why not make it work the way {{doc}} works on protected templates (via transclusion of the sandbox -- in this case -- onto the protected intro page). That way the message stays intact, and you can have a special edit link right there (though the "edit this page" tab won't work right, unfortunately). Maybe have Cluebot and/or its friends lightly patrol the sandbox for profanity to stop that. --Thinboy00 @117, i.e. 01:48, 29 August 2009 (UTC)

Basque Wikipedia

Hi from the Basque Country!
This is a message to the administrators of wikipedia in English or for someone who can help me with this issue:

I´m an user and contributor of the Basque Wikipedia., Basque language is one of the oldest in Europe and the world, it has thousands of years old and is one of the few languages that survived the arrival of Indo-Europeans to Europe. Perhaps being one of the oldest nations or countries of the world not even have their own state, but our language is our homeland and pride. It put us on the map and give a reference recognizable to English speakers, the city of Pamplona (Iruña in basque language), where they celebrate the internationally famous festival of San Fermin are in the Basque Country.

After this brief introduction I would kindly ask you this request:

On July 15, 2009, in the Basque wikipedia we exceed the figure of 40,000 items, today (August 8, 2009) and we have 42,000 items, achievement of which we are very proud, because if we compare proportionately the number of speakers of the Basque language (about a million) with other spoken language Wikipedia in more than one state or nation in the world with millions of speakers is like to be proud.

Because one of the aims of Wikipedia in addition to expanding human knowledge worldwide is also to expand the knowledge of all languages of mankind: From the Basque Wikipedia We wanted to make the request to the users and particularly to the Admin of the English wikipedia would be possible if you put the link to Basque Wikipedia in your English Wikipedia´s language list of everyone in your main cover ("Languages" section: as is currently the case Galician or Catalan language) and the Wikipedia list of more than 40,000 items that is below your main entrance page ("Wikipedia languages" section). Since English is currently the most powerful, influential and widespread in the world (your wikipedia already has 3,000,000 articles), the presence of Basque Wikipedia in your list of the world would be a great help to supervival of our language and their knowledge in the world.

Awaiting your reply.

Greetings from the Basque Wikipedia.
. --Euskalduna (tell me) 15:05, 26 August 2009 (UTC) (UTC)

Please see Template:MainPageInterwikis —TheDJ (talk • contribs) 16:33, 26 August 2009 (UTC)

The Basque Wikipedia is mentioned in List of Wikipedias, and might be mentioned in articles in the English Wikipedia which have used considerable input from articles in the Basque Wikipedia. ACEOREVIVED (talk) 21:26, 26 August 2009 (UTC)

Having re-read your posting, I understand that you would like the Basque Wikipedia to be mentioned on the Main Page, where - at the bottom of the page - a list of languages other than Wikipedia in which Wikipedias exist can be found. I think you had better contact a Wikipedia administrator there (I am not one myself), who may be able to help with proposed changes to the Main Page. ACEOREVIVED (talk) 19:47, 28 August 2009 (UTC)

I WANT TO POST

I WANT TO POST AN INFORMATION ON AARON BERKMAN, A RECOGNIZED WELL LISTED ARTIST. COULD YOU PLEASE ADVISE HOW I MAY PROCEED IN POSTING THE INFORMATION IN ADDITION TO AN IMAGE. THANKS, JEANETTE HENDLER —Preceding unsigned comment added by Jeanettehendler (talk • contribs)

Please don't type in CAPS LOCK. Ask for help like this at Wikipedia:Help desk. Thank you.----occono (talk) 17:51, 23 August 2009 (UTC)

When you go there, you are likely to get advice like this:Writing an article for Wikipedia is harder than many people realize. Even professional writers find that the format and style needed for a good encyclopedia article are different than what might be appropriate for other venues. You could:

• Get someone else to do it—If your only goal is to make sure that an article is added to Wikipedia, you can request that someone write an article on the subject.
• Start by editing other articles—If you are interested in becoming an editor at Wikipedia, our experience demonstrates that it is better to start by improving existing articles, which will help you get a sense of how this place works, and then you will be ready to write your first article from scratch. A good place to visit is the Wikipedia backlog, where there are literally hundreds of thousands of articles needing help from editors. Find an article in a subject area you know, and add a source, or a reference, or simply help write it better.
• Go ahead and try—If you do decide to write an article immediately, please read our policy on conflicts of interest, then read our guide to writing your first article, which will repeat some of the good advice above. Then please use the Article wizard, which will help you through the steps. I urge you to accept the option to save your first draft in your user subpage, which will reduce the chance your work will be deleted before it is ready.

--SPhilbrickT 18:15, 23 August 2009 (UTC)

Hm what an encourager to contributors that template is. Rich Farmbrough, 04:14, 30 August 2009 (UTC).

Yea, there seems to be a recent uptick in... negativity? recently. End of summer, maybe? I don't know.
— V = I * R (talk to Ω) 04:32, 30 August 2009 (UTC)

@Jeanette, click here: edit Aaron Berkman and start adding stuff.
— V = I * R (talk to Ω) 04:32, 30 August 2009 (UTC)

Wikipedia forums

I think that there should be a forum for wikipedia.Accdude92 (talk) (sign) 14:14, 27 August 2009 (UTC)

I think that Wikipedia is an encyclopedia and we don't need forums, the current discussion pages are enough. Kotiwalo (talk) 14:17, 27 August 2009 (UTC)

Because I'm a trouble maker I'd like to respond to Kotiwalo, and the many other users who state the same thing right away whenever similar questions about forums is brought up- if discussion/talk pages (whether user or article) were enough as you state then we'd never have needed the Village Pump or Wikiprojects. Forums are just one more useful tool for people with similar interests to find each other, exchange useful tips and sources and info. I know I have a number of "friends" I enjoy asking to look over articles I work on and hear from them "hey, working on x article I found this source, it might come in handy for you on that y article your working on". Wikipedia is a family, we may not always agree, we may fight, but in the end we all mean well and want to work together on a common goal to make this a better place. If having a forum to make new friends will improve some editor's contributions, then it is a useful tool. Only if these forums become a distraction and/or do not increase an individual's contributions then I would recommend that the forums/liquid threads whatever be discouraged or blocked to those who only use Wikipedia as a social networking site and dont do any editing at all. That is something I would like to see implemented- if you use this site as a social networking site you are blocked from it. Perhaps that would satisfy some who disagree with their implementation. Those who, like Kotiwalo, want to say "this is an encyclopedia and forums are not what Wikipedia is about", then they dont have to participate in a forum, but they need to back off and stop being anti-social in a vocal way. Be anti-social but be quiet.Camelbinky (talk) 01:12, 30 August 2009 (UTC)

There are forums to discuss Wikipedia off-site, however. hmwitht 14:18, 27 August 2009 (UTC)

An ordinary web forum for general discussion would be good, but there isn't really one now. There are mailing lists. --Apoc2400 (talk) 17:15, 27 August 2009 (UTC)

Really? Warrior4321 17:41, 27 August 2009 (UTC)

There used to be, WikBack, but it appears to be down now. I visited it frequently when it first went live, but eventually stopped going. Just tried it again and nothing. Not sure what happened. Maybe a lot of people eventually stopped going as well.↔NMajdan•talk 17:42, 27 August 2009 (UTC)

There's no an official one, but they exist. hmwitht 01:24, 28 August 2009 (UTC)

Shockingly, there are also anti-Wikipedia message boards as well.↔NMajdan•talk 02:00, 28 August 2009 (UTC)

Liquid Threads are coming... eventually (and personally, I can't wait!). That should address the basic concern being expressed, here.
— V = I * R (talk) 04:16, 28 August 2009 (UTC)

Wikipedia Review is fairly active. Chuthya (talk) 11:59, 28 August 2009 (UTC)

That's to what I was referring. :) hmwitht 00:01, 30 August 2009 (UTC)

Collapsible spans in lead para for etymology and/or pronounciation

I really like knowing about etymologies, but they can get in the way of smooth reading of the lead paragraph in many articles. I'd like these to be in collapible spans (I think this would need some technical implementation) when they get past a certain length.

Beijing (pronounced /beɪˈdʒɪŋ/ or /beɪˈʒɪŋ/ in English; Chinese: 北京; pinyin: Běijīng, IPA: [pèɪtɕíŋ] ; Wade-Giles: Pei3ching1 or Pei3-ching1) (also known as Peking (/piːˈkɪŋ/ or /peɪˈkɪŋ/)) is a metropolis in northern China and the capital of the People's Republic of China.

would therefore be replaced with something looking a bit like

Beijing [pronunciation and etymology] is a metropolis in northern China and the capital of the People's Republic of China.

expanding to the former when clicked. As with collapsible divs, these could be custom-CSS-ed for users who want them always-visible. The downside would be that that the text inside the span might get read, expanded and checked less, and it's another click if that's what you were mainly after looking at the article. The OED website does something similar, hiding pronunciation and etymology by default. Pseudomonas_(talk) 13:48, 25 August 2009 (UTC)

I like this proposal. The pronounciation is sometimes too long and can get very annoying to read through in the lead. An option to open the pronounciation, when desired seems much better. Warrior4321 16:57, 25 August 2009 (UTC)

I agree... what about developing a template that we could use? something along the lines of {{Lead sentence|Beijing|pron-en|beɪˈdʒɪŋ|IPA-en|beɪˈʒɪŋ|(etc...)}}
— Ω (talk) 18:22, 25 August 2009 (UTC)

I'm not too fammiliar with making templates of this sort at the moment. Is there a place such as requests for templates?? I couldn't find one. Warrior4321 18:54, 25 August 2009 (UTC)

Before going too far on this, there may be a consensus against collapsible elements in the main part of an article.
I did a quick search, and didn't find it, but I was once considering collapsing a large table and warned against it. Collapsing nav templates at the bottom of the article was specifically exempted, IIRC.
I share the concern about cluttering up the beginning of the article with too much etymology. --SPhilbrickT 22:03, 25 August 2009 (UTC)

Here's the guidance: MOS:SCROLL--SPhilbrickT 22:09, 25 August 2009 (UTC)

I think that a specific exemption to use collapsible spans in the lead specifically for this purpose is achievable, if it is indeed needed. Just among us here, there's some question abot how to implement it, but everyone seems to agree that it's a good idea. Obviously, there are only 4 people involved so far in this discussion, but I'd think that any discussion which doesn't (yet) have an obligatory Oppose added to it is certainly suggestive that widespread consensus is achievable.
— Ω (talk) 22:11, 25 August 2009 (UTC)

Don't count on me. What was wrong with Beijing example, anyway? NVO (talk) 22:13, 25 August 2009 (UTC)

(undent) To respond to an earlier question, Wikipedia:Requested templates is the place to ask for help with a new template. And, for what it's worth, I'd support such a template, as being a benefit to the average reader, who isn't interested in pronunciation and etymology. -- John Broughton (♫♫) 22:20, 25 August 2009 (UTC)

At the risk of getting ahead of things, I'd not want to overstandardize the pronunciation & etymology sections with new templates, just collapse an arbitrary block of text tidily in those cases where they're too long. Pseudomonas_(talk) 00:07, 26 August 2009 (UTC)

I like this idea a lot, though I must say, the original language should be included outside of the collapse, though not necessarily the transliteration. But it would be nice to hide the arcane pronunciation guides and elaborate linguistic notes. --Golbez (talk) 22:35, 25 August 2009 (UTC)

I think the original language is generally a detail about the word, rather than about what the word signifies, and belongs under the cut, especially when the answer is, as so often, Greek via Latin via Norman French via Middle English. I'll concede there are exceptions, though; there always are. Pseudomonas_(talk) 23:57, 25 August 2009 (UTC)

I take the point made in MOS:SCROLL about accessibility. At the moment, collapsible spans are not possible; I don't know whether this is changeable by admins or needs devs. I figure that if this proposal is popular with the community then people who know more about screen-readers and the like should decide if there's a non-obnoxious way of implementing it. Pseudomonas_(talk) 23:57, 25 August 2009 (UTC)

MOS:SCROLL is easily bypassed if the need to improve the encyclopedia is clear. As I said above, we can easily carve out an additional exception for this, if needed. Pronunciation and etymology are good information to include, but their not (normally) central to understanding the topic, so a template that collapses this (sometimes exceedingly long) information seems perfectly appropriate. There seems to be a decent amount of support for this, so at least getting the template created to accomplish the task seems to be the obvious next step. Having a concrete implementation to look at is what will prompt movement on this subject.
— Ω (talk) 00:27, 26 August 2009 (UTC)

Excellent. Can anybody here create the template? Warrior4321 05:04, 26 August 2009 (UTC)

I'm pretty sure that I could, but I'd need to find the time. Leave a note at Wikipedia:Requested templates, and someone will get around to it.
— Ω (talk) 05:15, 26 August 2009 (UTC)

I'll ask in IRC. Warrior4321 15:31, 26 August 2009 (UTC)

I wonder if having a system where the span was default-visible and then hidden by javascript would avoid the problems with accessibility &c.? Or is that the way the other collapsible things are done anyway? Pseudomonas_(talk) 22:21, 30 August 2009 (UTC)

CC badge?

Is there a reason we don't have one of the Creative commons badges at the bottom of our pages? I seem to remember a GFDL badge being there once upon a time. --Cybercobra (talk) 11:04, 26 August 2009 (UTC)

http://creativecommons.org/policies suggests that the images might not be free enough (though IANAL) - they're somewhat trademark encumbered. I suspect this might mean that the licenses in commons:Category:Creative_Commons_icons need to be tweaked somewhat. Pseudomonas_(talk) 12:08, 26 August 2009 (UTC)

I bring it up because I noticed Wikinews has one of them on its footers: [1] --Cybercobra (talk) 12:24, 26 August 2009 (UTC)

Hm, OK. I don't know what the standards are for the stuff that sits around the text. AFAIK the Wikipedia logo is trademarked, so maybe it's OK. Pseudomonas_(talk) 12:52, 26 August 2009 (UTC)

Wikinews uses the following interface message, n:MediaWiki:Copyright, to add this button. I agree that we at least should add one of the CC license microformats. —TheDJ (talk • contribs) 16:36, 26 August 2009 (UTC)

Yeah, a Google search filtering only results free to use excludes Wikipedia, so, it at least needs the CC metadata, or whatever, flagging it for free use for searches.--Unionhawk ^{Talk E-mail} 16:45, 26 August 2009 (UTC)

(Off topic, and purely a matter of personal interest) How do you do a Google search filtering only results free to use? That would be very useful, but I've never been able to find any Google feature offering that functionality. Dendodge _T\^C 16:56, 26 August 2009 (UTC)

(←)In 'advanced search,' there's a link that says "Date, usage rights, numeric range, and more." Click it, and there will be a dropdown box that you can choose the appropriate license. It only works with Creative Commons though, I think.--Unionhawk ^{Talk E-mail} 17:00, 26 August 2009 (UTC)

First try at example microformat

I generated a preliminary example for what something like that may look like:

code

<a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/"><img alt="Creative Commons License" style="border-width:0" src="http://i.creativecommons.org/l/by-sa/3.0/us/88x31.png" /></a><br />The text of the page:<span xmlns:dc="http://purl.org/dc/elements/1.1/" href="http://purl.org/dc/dcmitype/Text" property="dc:title" rel="dc:type">{{FULLPAGENAME}}</span> by the <a xmlns:cc="http://creativecommons.org/ns#" href="http://wiki.riteme.site/w/index.php?title={{FULLPAGENAME}}&action=history" property="cc:attributionName" rel="cc:attributionURL">contributors of Wikipedia</a> is available under the <a href="http://wiki.riteme.site/wiki/Wikipedia:Text_of_Creative_Commons_Attribution-ShareAlike_3.0_Unported_License">Creative Commons Attribution-ShareAlike License</a>; additional terms may apply. See <a href="http://wikimediafoundation.org/wiki/Terms_of_Use">Terms of Use</a> for details. <br /> Wikipedia® is a registered trademark of the <a href="http://www.wikimediafoundation.org">Wikimedia Foundation, Inc.</a>, a U.S. registered <a class='internal' href="http://wiki.riteme.site/wiki/501%28c%29#501.28c.29.283.29" title="501(c)(3)">501(c)(3)</a> <a href="http://wikimediafoundation.org/wiki/Deductibility_of_donations">tax-deductible</a> <a class='internal' href="http://wiki.riteme.site/wiki/Non-profit_organization" title="Non-profit organization">nonprofit</a> <a href="http://wiki.riteme.site/wiki/Charitable_organization" title="Charitable organization">charity</a>.

Wether or not to use an image, and the exact wording and formatting still requires quite some discussion of course. We wouldn't want to get that wrong. —TheDJ (talk • contribs) 17:08, 26 August 2009 (UTC)

A demo is visible on the test wiki. Note that it only looks decent if you use Vector/Beta, in Monobook, it's one big mess. (Note that there are two license links, one to our OWN licens page, and one to the creative commons version, to make sure we are picked up by search engines. —TheDJ (talk • contribs) 17:41, 26 August 2009 (UTC)

Cool! I think it might look better in Monobook if a linebreak were inserted like so: "additional terms may apply.<br/> See". Agree it already looks fine in Vector, although I don't know if I like the stacking of the buttons. --Cybercobra (talk) 23:17, 26 August 2009 (UTC)

This includes page specific stuff though, so IF we do this, I first need to check with domas or brion to get an OK on this. We can remove that metadata if we have to. Basically the only critical part to "Searchable detection", is having this link in a rel=license. We currently have our own link, but perhaps we should have both, with the CC link hidden. —TheDJ (talk • contribs) 00:09, 27 August 2009 (UTC)

I think we should at the very least add the microformat, as I propose here: MediaWiki_talk:Wikimedia-copyright —TheDJ (talk • contribs) 00:47, 27 August 2009 (UTC)

I asked domas, and we should not use page specific functions on footers like this. —TheDJ (talk • contribs) 17:42, 27 August 2009 (UTC)

I guess we could open a bugreport to generate the RDFa crediting format in the core, that will be significantly less expensive. The license microformat should be no issue at all, the badge is really something that requires a lot more community input. —TheDJ (talk • contribs) 18:30, 27 August 2009 (UTC)

Truth be told, my focus was more on the badge; I didn't know about the RDF tagging before you brought it up. Although the tagging is still an excellent idea--Cybercobra (talk) 20:39, 27 August 2009 (UTC)

Image badge

Right, now that the microformat was added, any thoughts from people on the original question of an image badge? Possibilities: [2], [3], [4] --Cybercobra (talk) 05:31, 30 August 2009 (UTC)

I'm opposed to this; there's no reason for it at all. We should only use graphics for graphical information. It's just visual pollution. —Noisalt (talk) 01:00, 31 August 2009 (UTC)

Query: Then why do we have the "Powered by MediaWiki" and "A WikiMedia project" badges? --Cybercobra (talk) 01:12, 31 August 2009 (UTC)

You tell me. I have exactly the same opinion about them. —Noisalt (talk) 01:47, 31 August 2009 (UTC)

Policy change proposal

I'm posting this in response to the CNN article which was reporting on Wikipedia's decision to use editors for select articles to approve changes before they're made public. I'd like to suggest that Wikipedia enact a system of "community based edit approval" on selected articles wherein pages need to have changes approved before being made public. Edits would be voted on by users before taking affect. In this way, when a user makes a change to an article it will not be immediately visible on the article's main page. Instead, it will be logged onto the articles edit page for review and if it receives a set amount of negative votes in a certain amount of time then edit will be discarded and the article will not be changed. This would be a good way to prevent vandalism and preventing bad changes from ever coming into action. 74.131.111.224 (talk) 23:19, 27 August 2009 (UTC)

This is the gist of Wikipedia:Flagged revisions. -- Taku (talk) 21:02, 29 August 2009 (UTC)

Voting would never work, most articles don't get enough traffic. Mr.Z-man 21:11, 29 August 2009 (UTC)

It does make sense to let the reader somehow rate and vote for particular versions. That is, the most article with the most votes will become one that is visible. (I know this isn't what was proposed above.) -- Taku (talk) 21:37, 29 August 2009 (UTC)

Opening such a vote up to the general public allows for manipulation of content. Say you're a member of a pro-whatever group, you can slant an article to favor your side, then ask all the other group members to vote for that revision, so even if it gets reverted, it'll still be the most popular version. Since the voting is done by the general public, there's no accountability. Mr.Z-man 01:57, 31 August 2009 (UTC)

Hide bots in history

I wish a hide bots button on history pages. There is so huge amount of bot edits on every history page it is really annoying to check other "real" edits. --Janezdrilc (talk) 14:42, 28 August 2009 (UTC)

I think this would make things very confusing and probably could not be implemented elegantly. –xeno^talk 14:49, 28 August 2009 (UTC)

As xeno said, this would become far too confusing. The bot edits would be merged with another users' edits, which would incorrectly attribute them to a non-bot user. What if a user reverts a bot's edit? Then there'd be a history entry where nothing changed. –Drilnoth (T • C • L) 15:10, 28 August 2009 (UTC)

Are bot edits in the history marked up as such via a class in the <tr> or something? If that's the case, I'm willing to guess it would be possible to develop a gadget/javascript to hide the edits (no, I haven't checked myself). Likewise for minor edits, if you wish to hide those. Ideally, we'd be able to turn it on and off with a link/button. --Izno (talk) 17:11, 28 August 2009 (UTC)

The problems would not be from difficulty of hiding them in the history page itself, the problems would be from the confusing diffs that would result from removing entries from the page. Mr.Z-man 17:19, 28 August 2009 (UTC)

(undent) Such a gadget would only hide the entries on the history list, not the edits themselves. So if the original history looked like this:

• (cur)(prev) 0:10 1 January, 2000 User:Example (foo)
• (cur)(prev) 0:05 1 January, 2000 User:ExampleBot (bar)
• (cur)(prev) 0:00 1 January, 2000 User:Example2 (baz)

etc.

Then the "truncated history" would be this:

• (cur)(prev) 0:10 1 January, 2000 User:Example (foo)
• (cur)(prev) 0:00 1 January, 2000 User:Example2 (baz)

etc.

but clicking the first "prev" link would (assuming no major restructuring on the part of the gadget) show a diff between the edits at 0:05 and 0:10, not the edits at 0:00 and 0:10, and the author of the old version would be correctly identified as User:ExampleBot (i.e. everything would "just work"). If the gadget somehow was designed to show the diff between 0:00 and 0:10, it would look as though the user had selected this diff via the radio buttons on the original history (complete with message about intermittant edits etc.). This, however, would entail a much more complex gadget. In short, the MediaWiki software is not stupid and won't do inconsistent things like those mentioned above without warning you. --Thinboy00 @144, i.e. 02:27, 29 August 2009 (UTC)

I like seeing bot edits... yes, most of the time they can be ignored, but occasionally a bot will make an edit that needs to be over-turned. It is important to check what bots do, to make sure that their changes are appropriate for a specific article. Blueboar (talk) 16:51, 29 August 2009 (UTC)

I'm pretty sure that simply "hiding them" was the intended functionality, Thinboy, and I think I'd actually find it useful myself. It makes the "diff" button harder to use (unless such functionality as "you may be including bot edits" is implemented), but not disturbingly so. --Izno (talk) 18:22, 29 August 2009 (UTC)

Here is one solution. You put this option in Preferences -> Gadgets -> User interface gadgets. So if you pick this option out every history page whould include show/hide buttons where bots should be listed. And if you want to make a preview or undo, you just have to click show. That's all. --Janezdrilc (talk) 22:42, 30 August 2009 (UTC)

Aha, I have to explain my reason. The problem is that smaller Wikipedias have a series of bots on the history lists (interwikis) while bigger wikis like en: or de: maybe don't know that problem so strictly. --Janezdrilc (talk) 22:46, 30 August 2009 (UTC)

Check my work?

It's entirely possible that what I'm thinking about exists already and I'm simply not aware of it, but recently I've been running across situations where I feel that I'm "going out on a limb" somewhat. You know that feeling that you get, where you don't want to just leave something, but you also don't really feel comfortable with the change that you've just made? has there been discussion about some sort of feedback system that addresses this, at all? The first thing to come to my mind is some sort of template.. something like {{Check me}} or... something.
— V = I * R (talk to Ω) 07:13, 30 August 2009 (UTC)

{{check}}? --Cybercobra (talk) 07:20, 30 August 2009 (UTC)

nah... I mean, I suppose that template (or even the whole range of similar templates) could be refactored somehow. What I was thinking of is something more immediate and temporary. Like: "OK, I'm changing this because it's clearly wrong/incorrect/needed, but I'm not sure if my change is exactly correct so can you check my work please?" basically... a message box with a message that says "the last change made should be checked. Once checked, please remove this template". Something like that.
— V = I * R (talk to Ω) 07:33, 30 August 2009 (UTC)

Proposal: Have a bot autodelete any stub article of less than 250bytes if not edited in X months

Per WP:REDLINK and WP:STUB, I think there should be a balance between creating an article of one or two sentences and allowing an unimproved micro stub to exist indefinitely. My view is that a redlink is as much or more an incentive to research and create an article as is a stub to expand, but that a minimal stub detracts from the impression of the encyclopedia as a serious enterprise. As I am aware that many editors do create a very short stub as a type of placeholder and then they (or a project) begin expanding them I would think there should be a generous allowance to permit them - or others - to work upon them to bring them up to article status.
Per WP:Stub Wikipedia is not a directory and it would be difficult to argue that a one or two sentence page would not fall into that definition - except perhaps place names; "X" is a small village in Y province/state of country Z", and discussion might suggest particular stub types that might be exempt from the cull. Also suggestions regarding time frames may be beneficial, especially with input from those who can provide analysis on the likelihood of expansion on stubs over time from creation.
I look forward to comments. LessHeard vanU (talk) 14:01, 21 August 2009 (UTC)

I'd oppose your proposed exemption: to my mind, a bot that went through and automatically deleted orphan stubs should be specifically targeted at the efforts to convert Wikipedia into an atlas. A bot-created stub about a remote yak-herding village that has only been edited by bots since its creation is a perfect target for deletion. If someone wanted to write a more customized bot that automatically created "list of settlements in so-an-so" based on the geographic coordinates in those stubs, I wouldn't object to that as an alternative to outright deletion.—Kww(talk) 14:06, 21 August 2009 (UTC)

This has the same problem as people using bots (scripts) to create stubs - no human oversight as to what is happening. 250 bytes, while it may sound reasonable, is an arbitrary cutoff - and unfortunately any cutoff would be rather arbitrary. There is no way to ensure that the content being deleted should be deleted. The idea of removing data to encourage the addition of data strikes me as being somewhat backward. While I can safely say that I would (probably) support the deletion of most individual sub-stub articles of this size, I am uncomfortable with turning a bot loose to do the work on its own. Shereth 14:08, 21 August 2009 (UTC)

We should not be deleting articles until a person has at least looked at it. An article being short and not edited often is not criteria for deletion. Chillum 14:09, 21 August 2009 (UTC)

Add in a view counter parameter? I am suggesting 250byte (but am open to variance based on experience) as a really small size which unlikely be more than a directory type stub, but if it is being viewed regularly then there is evidence of worth. In a general response to comments so far, deletion is not judgement or permanent; if something that should be there gets removed then it will be recreated and hopefully for the better. LessHeard vanU (talk) 14:28, 21 August 2009 (UTC)

I suppose you could tack on numerous "parameters" for the bot to go on. Has it had more than 1 non-minor edit? Does it have X number of views? No edits since X? Only edited by bots? Only X bytes long? Inbound links? A lot of these would help ease my concerns, but the major stumbling block to me is that it's all run by bot. I am extremely hesitant about bots being involved in the creation or deletion of articles, for ultimately the inclusion criteria can only be judged by a human, not a machine. Now, I could see a bot placing them in a CSD-like "stubs eligible for deletion" category that could be reviewed by actual humans who could make the final call on whether it should be deleted, but then we're creating an awful lot of work ... Shereth 14:35, 21 August 2009 (UTC)

Add in a two-week notification to the creator of the article before the deletion, and that seems to be good (Make sure this is well-advertized with an opt-out - I don't thikn some bot operations want to see 1000s of the same messages). --MASEM (t) 14:10, 21 August 2009 (UTC)

I would oppose this, per Shereth. Arbitrary cutoffs are bad. For example:

[[File:JohnSmith.jpg|thumb|John Smith]] '''John Smith''' was a sixteenth century English author. While he wrote several collections of poetry, including [[Collection1]], he's most famous for his plays, mainly [[His famous comedy]]. {{author-stub}}

is only 247 bytes, yet it includes an image, links to other relevant articles, and contains key background information. However, one could write an article that consists of nothing but a well-filled infobox and a stub tag, and have it be well more than 250 bytes. If an article goes several months with no edits, I think its rather unlikely that a well-researched full article is on the horizon, and the only thing that's preventing it is the stub. My guess is that we would just end up with a redlink for another several months or years, and rather than providing what little information we can, we provide none. Mr.Z-man 14:33, 21 August 2009 (UTC)

• Perhaps someone could do some data-gen to give us some examples of the articles that would be caught by LHvU's proposed net? –xeno^talk 14:36, 21 August 2009 (UTC)

• I would oppose this. Being short and stable is not any kind of criteria for deletion. DuncanHill (talk) 14:48, 21 August 2009 (UTC)

• Why not have the bot just prod all the articles, rather than delete? Of course, this would create a tremendous backlog of prods if done all at once, so perhaps this could be run at a limited rate, or something like that. Cool3 (talk) 14:57, 21 August 2009 (UTC)

I had thought of that, too, and was worried about the backlog - I hadn't considered throttling the reporting bot. Shereth 15:01, 21 August 2009 (UTC)

• Oppose. we are not on a timetable to finish the encyclopedia. If stubs are notable, they can linger as long as it requires for an interested editor to come along and improve the article. With the current "completness" of the encyclopedia, it will require longer and longer for stubs to develop, but that is no reason to delete them. See also Duncan Hill's comment. —TheDJ (talk • contribs) 15:04, 21 August 2009 (UTC)

  I would support such a bot adding articles to a category for human review. Chillum 15:07, 21 August 2009 (UTC)

• The main question is, is there consensus to delete any kind of substub even if the topic passes WP:N & friends? If so, of which kind? I for one wouldn't mind seeing all "Foo is a Bar" type substubs gone, in particular if we already have a "List of Bars" article.
  My biggest problem with stubs is when they are so short that they have to be considered wrong, which can usually only happen with (quasi-)bot-created stubs (e.g. Philipp von Bismarck, Otto Fürst von Bismarck (CDU), Karl-Heinz Daehre, Mario Czaja, Karl Eduard Claussen, Christine Clauß, Paul de Chapeaurouge, Rudolf Böhmler, which all omit the most defining points of those people). With the current proposal at WP:VPP that should hopefully happen less frequently for any newly created stubs. Question remains how to identify all the existing substubs that fall into that category, be it for improvement or deletion. By default I'd think that they will always need human eyes on them, but as xeno said, a examplary selection of substubs generated by whatever filters would be enlightening.Amalthea 15:36, 21 August 2009 (UTC)
• Yes, size isn't a deletion criterion. The best treatment of a permanently short article might be to merge it, move it to wiktionary. etc., but these are operations for a human. No harm though in having bots generate lists of articles based on any criteria people find useful (but of course there's no need to add tags or categories to the actual articles - that just floods the changes lists unnecessarily).--Kotniski (talk) 16:04, 21 August 2009 (UTC)
• I also disagree with this proposal, it would have the potential to catch articles such as this one where there was content but only in a template thus making the article shorter than it actually was by byte size. I am aware this would be ok due to the article being edited within a reasonable time scale but I fear other similar articles could be caught. More basically I disagree with the premise as very short articles can be expanded by anyone, while new articles can only be created by registered users. If the articles have enough context to avoid meeting the speedy criteria and have potential to be expanded they should not be deleted or merged out of existence. Some verified information is better than no information. Davewild (talk) 18:53, 21 August 2009 (UTC)
  • Well, I don't find the last part true. Take Paul de Chapeaurouge, for example, which I mentioned before: The only verifiable (not verified!) information we have on him is that he was "a representative of the CDU" – which is basically a footnote in his biography, he joined them when he was 70, and all the time he was a founding member of a different party. Substubs like this, generated from a list, often leave out the important parts, but make it appear as if they presented the high points. Having no article would be preferable here, since the only verifiable information we have would have turned up in a search anyway, by way of the list. Amalthea 19:41, 21 August 2009 (UTC)
    • Having the article in the case you have raised does have a good purpose as it provides an easy link to the German wikipedia article which can be used for expansion of the article, which is more likely to happen now that link is there than from a list. Pointing the reader, as well as potential editors of the article, towards such a more substantial article in another language is not a bad thing. It also would not be even close to coming under this proposal anyway as it has over 500 bytes so I question whether this proposal would even achieve the aim that it's proponents would want. Davewild (talk) 19:57, 21 August 2009 (UTC)
      • The criteria are in a state of flux, of course. :)
        I'm not sure our typical reader will even notice the interwiki link and, again, this substub conveys an incorrect picture of that person. If a reader goes away with the impression that the most notable feature of him was what's in the article then we have done him a disservice. And of course, there's for example Sabine Christiansen where I'm pretty sure the interwiki link is complete bogus as well. Amalthea 20:22, 21 August 2009 (UTC)
• Oppose The age of the stub article is not relevant. It could develop into something better one day. And even a stub for a Wikipedia valid topic, is better than nothing at all. Dream Focus 19:48, 21 August 2009 (UTC)
  • Well, I would refer you to the (random!) example I've just presented directly above. Amalthea 19:52, 21 August 2009 (UTC)
    • Which would not even come under this proposal anyway as I point out above. Davewild (talk) 19:59, 21 August 2009 (UTC)
• Oppose for the reasons already mentioned.--Cube lurker (talk) 20:01, 21 August 2009 (UTC)
• Oppose as nobody is more encouraged by a red link. On the contrary, starting an article from absolute scratch is a more daunting task for the unprofessional editor then making edits to an article that has already passed the deletionists of wikipedia (New page patrol). Further to this, there is nothing gained from deleting these articles. There is only loss of information. Just because someone has it subjectively in their mind that this information is irrelevant, does not mean that it is irrelevant. - ʄɭoʏɗiaɲ ^τ _¢ 15:10, 22 August 2009 (UTC)
• Oppose Having a stub is better than nothing at all, and having half of the picture is better than having no idea at all who a person is. If information/pictures/interwiki links are incorrect, that has nothing to do with the article being a stub. Anything incorrect should be fixed. hmwitht 14:37, 23 August 2009 (UTC)
• Oppose Look at any paper encyclopedia and you will find lots of articles shorter than 250 characters. Stubs are fine. Sometimes I just want to know what something is. I also question the premise that redlinks are more likely to be expanded. Stubs allow IP users to expand. --Apoc2400 (talk) 15:41, 26 August 2009 (UTC)
  • Accius is a good example. It is 300 bytes, but that is due to lots of markup. John Vandenberg ^(chat) 12:57, 1 September 2009 (UTC)

Have the bot list such stubs for review and possible prodding/deletion/merger, etc

Well, it appears that there is a large sentiment for "something is better than nothing" - even if it triggers WP:NOTDIR, so perhaps it would be best that any initial run bot would simply list these stubs and a taskforce could go through and remove the real junk (once tagged by the bot it would whitelist any stub not deleted). Any subsequent bot runs could PROD an article under the criteria, and again allow flesh and blood operators make the decision. I would comment that this is not attempting to "finish up the encyclopedia" but to remove content that is no longer up to standard - much like some old FA's lose the status - and improve the overall quality of the project. I would, of course, sign up for such a review body in the first instance. LessHeard vanU (talk) 20:11, 21 August 2009 (UTC)

^^^ The first part of this is a "just do it" solution, no one can stop someone from compiling such a list. I would suggest the eminently helpful MZMcBride, he's great with this kind of thing. Maybe ask at WT:DBR. –xeno^talk 20:14, 21 August 2009 (UTC)

This seems to be an eminently good idea. Something vaguely similar was recently done with bilateral relations articles (a group of people went through a list of them all trying to weed out the junk) with what seemed to be fairly good results to most folks. Perhaps forming some sort of project/group/taskforce/etc. to help carry out the process wouldn't be a bad idea, and of course as it could become a standing group of sorts as new articles would enter the list over time. Cool3 (talk) 20:29, 21 August 2009 (UTC)

We already marks stubs for reviewing, via the {{stub}} templates that we put on them. The issue is not lack of marking, it's lack of volunteer time to review tens of thousands of articles. — Carl (CBM · talk) 20:32, 21 August 2009 (UTC)

This tool may help with this effort. -- œ^™ 04:28, 22 August 2009 (UTC)

• I have (had) generated a list of articles of below 250byte that has not been edited in 12 months, tools:~mzmcbride/lessheard.txt - there are 1500+ of them. A brief review indicates that some like "List of" are likely useful - but the number that uses an underscore ("_") in the title indicates that it is unlikely to be found as a search item: there may even be another better titled article on the subject. There are obvious candidates for a BLP review, too. Oh, well, I have my bot list, and something for me to do that doesn't involve being droll at the drama boards... Anyone wanting to take a punt at reviewing/prodding/deleting/redirecting/merging is welcome. If there are more than a couple we might even have to organise a small project. LessHeard vanU (talk) 16:45, 22 August 2009 (UTC)
  • An underscore and a space are equivalent: Life_Will_Be_the_Death_of_Me = Life Will Be the Death of Me. Amalthea 17:10, 22 August 2009 (UTC)

**I am happy to try and expand some of these articles. It would be a good idea to move the list onto wikipedia, where notes can be placed against entries where action is taken or which are quite appropriate to be kept short such as the disambiguation pages on the list. Davewild (talk) 18:01, 22 August 2009 (UTC)

• • • I see the list is on wiki already at User:LessHeard vanU/Mini stubs. Davewild (talk) 18:23, 22 August 2009 (UTC)
      • I am being ruthless, so if anyone sees a redlink and think they can find sufficient info to turn it into either a small article or a good stub (and don't have sysop flags) let me know and I will undelete. LessHeard vanU (talk) 19:26, 22 August 2009 (UTC)
        • Why are completely going against consensus? How about you don't delete them unless they fail afd? Prodding is pointless here as very few people likely have the stub watchlisted. Also, titles with an underscore are titles with spaces, so yes they are easily found in a search. I find it disturbing that you don't know that but are going around deciding which articles aren't fit for the encyclopedia. - ʄɭoʏɗiaɲ ^τ _¢ 15:33, 23 August 2009 (UTC)

A glance shows that LessHeard is already carrying out some rather poor speedy deletions from this list. The high failure rate at low volume is a good indicator that introducing a bot to increase the volume is a bad idea. Christopher Parham (talk) 15:30, 26 August 2009 (UTC)

deletes are here at the moment. Rich Farmbrough, 04:13, 30 August 2009 (UTC).

Date parameter

I did include a date parameter in {{Asbox}} at one point, in case it was ever thought useful to explore how long things remained as stubs, and perhaps triage them. It was taken out as scope creep. However if it would result in less stubs, in a good way, it can be put back in. Rich Farmbrough, 04:03, 30 August 2009 (UTC).

a general Conversation page?

Now I know that wikipedia isn't the place for "chatting", BUT I think a page just for talking and for getting to know all the editors, and other members, would be nice to have. As of now, everybody is sepperated. I also know that there is irc, but not everyone can use irc.Accdude92 (talk) (sign) 14:19, 25 August 2009 (UTC)

Wikipedia is not a social-networking site. We're here to build an encyclopedia. However, collaboration is encouraged. Try contacting an editor on his/her talk page. hmwitht 17:30, 25 August 2009 (UTC)

• mw:LiquidThreads should help, when and if it's ever deployed (see Andrew Garrett's blog for details on development). The kludginess of the current talk page system is what drives the long standing institutionalized anti-social behavior that Wikipedia presently espouses (as displayed in the reply above). I know exactly what you're saying, and personally agree with the sentiments, but until the technical restrictions are handled nothing is going to significantly change.
  — Ω (talk) 18:34, 25 August 2009 (UTC)
• For kicks, you could always try and have conversations with people in the WP:SANDBOX. Whilst WP isn't social networking, or a forum, I do sometimes feel that minor less-streamlined talk would help the atmosphere greatly. Generally when I try and do something humorous people just flip me off on here, which is a shame. It would certainly be cool to remedy that and let people have breathing space. I can handle being shot back at, but I'm sure it turns decent new editors away. Greg Tyler ^{(t • c)} 20:58, 25 August 2009 (UTC)

I agree we need a general "chat room", but maybe keep it for finding editors who have similar interests and collaborating with people instead of making it just another AOL/Yahoo!/Myspace/Facebook thing where people are. It would be nice to have a general conversation forum where you could say "Hey, this is what I've been working on, anyone out there have similar interests?" because often people are working on articles within a similar topic and never know about each other and may have insight and info the other may have been looking for. Also a great place for potential wikiprojects to be formed since suddenly a large group of people realize they have a large collection of articles they want to colloborate and organize better. If anti-social people like the one that replied up above dont want to get to know others then that is their choice, but they can not force their personal beliefs on the rest of Wikipedia.Camelbinky (talk) 22:21, 25 August 2009 (UTC)

Wouldn't it cause mass edit conflicts? Warrior4321 22:26, 25 August 2009 (UTC)

Only if it was designed poorly. If you're really concerned, you could bring your concerns up with Werdna (talk · contribs), since he's currently leading the development of LiquidThreads.22:41, 25 August 2009 (UTC)

IRC is the best way to socially interact (generally, on the Internet as well, in my opinion). I'm not sure why someone wouldn't be able to use IRC - it's easy enough to learn with some tutorial or you can always just use an applet if you have connection problems. -- Mentifisto 15:17, 26 August 2009 (UTC)

I agree with the sentiments about IRC, but even an official Wikipedia IRC channel isn't really on Wikipedia. Most people just won't bother to use something "offsite", for various reasons.
— V = I * R (talk to Ω) 03:50, 30 August 2009 (UTC)

True, IRC has to be offsite, but Wikipedia supports it and has a whole host of channels to talk on. Webchat.freenode.net makes it easily accessible, too. If you want to chat about Wikipedia, I would support IRC as the place to go. Besides, holding it on site would mean the servers had to hold masses and masses of pointless, spammy conversations. That seems like a waste when there's such valuable information held there too. Greg Tyler ^{(t • c)} 16:34, 31 August 2009 (UTC)

The other issue with IRC though is that it's chat. Personally, I just don't like chat... as for server load questions, that's really not something to be concerned with.
— V = I * R (talk to Ω) 13:37, 1 September 2009 (UTC)

Talknotice

Sometimes, we have important community announcements, but there is no optimal way to advertize them. We can use the watchlist notice, but IPs can't see it, and logged-in users don't always frequently check their watchlist, so it's not that efficient. There's also the sitenotice, which makes the message visible to all users on all pages. But some announcements are not intended for all readers or are not important enough to be put on the sitenotice, so we could use a talknotice working like the sitenotice and displayed only on talk pages, also dismissible. If we agree that such a thing is desirable, it'll be requested to the developers. Cenarium (talk) 00:26, 26 August 2009 (UTC)

I second this proposal; the decision of what to do at the end of the coming flagged revisions trial (as Cenarium notes elsewhere) is one such announcement where watchlists don't reach enough users but sitenotice reaches too many.--ragesoss (talk) 19:27, 30 August 2009 (UTC)

Sounds good to me. - Peregrine Fisher (talk) (contribs) 21:24, 31 August 2009 (UTC)

Could we just put namespace checking code into the sitenotice? Something like {{#ifeq:{{NAMESPACE}}|{{TALKSPACE}}|...}} should do? — Dispenser 21:38, 31 August 2009 (UTC)

I tried on testwiki and the sitenotice couldn't handle it, if you put checking code in, it will be displayed on pages as parsed on the page Mediawiki:Sitenotice itself. I think it's for performance reasons. Cenarium (talk) 22:51, 31 August 2009 (UTC)

If we needed it right now we could use CSS or JS to hide on articles. — Dispenser 07:07, 1 September 2009 (UTC)

I filled T22458 requesting this. Cenarium (talk) 00:22, 1 September 2009 (UTC)

I love this idea. I think it might work better if the notice was displayed in all the secondary namespaces, and perhaps while editing. That way, anyone who isn't just a casual reader will see it. — Jake Wartenberg 04:14, 1 September 2009 (UTC)

Wikia already developed this functionality, so could be a good starting place - it's available here: https://wikia-code.com/wikia/trunk/extensions/wikia/SiteWideMessages/ ... via a special page you can send out dismissable messages that show up on user talk pages. Because it's on user talk pages, it triggers the new message notification, so users will know it's there. You can target groups of people (admins, for instance), individual users, or just everyone. If needed, you can also retract messages after they were sent out. The messages can have an expiration date so they go away on their own after a specific date/time - useful for things like maintenance notifications where no one cares 1 month after the event. Also handles anon user talk pages, empty user talk pages, diffs, etc. This was a particularly useful extension as it allowed us to communicate with people en masse for whom we had no email address. The dismissable part of it is what made it appealing to the users. Jqsjqs (talk) 22:50, 16 October 2009 (UTC) More here: http://help.wikia.com/wiki/Help:Talk_Page_Messaging Jqsjqs (talk) 00:06, 17 October 2009 (UTC)

Table of contents

Check out Maglev (transport). Its table of contents is floated over to the right, next the the main text, instead of above the rest of the text. I'm sure I'm not the only one who has been annoyed by having to scroll and scroll and scroll and scroll to get past the TOC. Maybe using the method found in "Maglev (transport)" in all articles, or at least all long ones, would make Wikipedia more usable overall. All it would require would be a TOCright or TOCleft in double curly brackets where the table of contents is.--(User:Star Trek enthusiast) (talk) 23:21, 27 August 2009 (UTC)

If you want to get to the bottom of the toc, just click the first "item" on the table of contents. It will take straight to the bottom of the toc, no scrolling required Warrior4321 00:35, 28 August 2009 (UTC)

It won't work in every article, since many articles include either an Infobox or a picture on the upper right of the article (where the TOC appears in the Maglev article). Any individual articles can be changed to display the table of contents on the right hand side by placing the {{TOCright}} template on the page.
— V = I * R (talk) 04:25, 28 August 2009 (UTC)

It's a lousy system for smaller screens. the (edit) link for section one is left hanging at the top of the TOC while section one actually starts underneath the TOC. NotAnIP83:149:66:11 (talk) 10:00, 31 August 2009 (UTC)

A better verb for "search on Wikipedia"

Every day I say or hear "Donno, check it up on wikipedia" or "even google it on wikipedia". A better verb needs to be coined as to wikipedia sounds silly. If it does, what is it? just an odd thought, but this could go a long way, so I am posting. --Squidonius (talk) 11:31, 24 August 2009 (UTC)

I sometimes use 'ask wikipedia', as in "I don't know, you could ask wikipedia". Personally I'm not a fan of awkward neologisms like 'google it' so if you do coin a new verb, I for one won't be in a hurry to adopt it. Mike1024 (t/c) 12:29, 24 August 2009 (UTC)

"Wikoogle"! Dendodge _T\^C 12:50, 24 August 2009 (UTC)

(ec) Just say "check Wikipedia" or some other variation. Using "Google" as a verb evolved from the near-ubiquity of the engine and its unique, short name (two syllables, not five like Wikipedia). If they had tried from the start to make "Google" a verb, it wouldn't have worked - these things need to happen naturally. It's usage as a verb is actually bad for the company, as the more common the term becomes in the daily lexicon, the more diluted their Trademark becomes, which could easily cause it to lose that status. All that being said, I do know plenty of people who say "Wiki it," which, while technically incorrect, tends to work out the way you want it to nicely. ~ Amory (user • talk • contribs) 12:54, 24 August 2009 (UTC)

I don't think it's that difficult to say "Look it up on Wikipedia", like you would say for any website. I don't think we need to just say "Wikipedia it", but go for it, if people know what you're talking about. hmwitht 15:00, 24 August 2009 (UTC)

"Wikipedia it" is a problem because it could mean more than one thing. Does that mean "read an article" or "re-write the article" or "spend the rest of the week trying to determine consensus on a single sentence"? WhatamIdoing (talk) 19:12, 24 August 2009 (UTC)

Woogle it. Wikit. Wikifact check. Wing it (from Bing it). Ahhhh, all of these suck. Maybe we would need to create a "wikisearch bar" so we could spread the the phrase wikisearch with some grounding in reality. (By "we", I mean "all of us except me and Mike1024". The brows of people who make up neologisms are decidedly higher than those of the people who use them.) Andrew Gradman ^talk/_WP:Hornbook 05:53, 25 August 2009 (UTC)

Perhaps there could be a new verb coined here - after, Google has become such a popular search engine that people now talk of "googling the web" rather than "surfing the Web". Perhaps we could talk about Wikipeding for a term? I would be against, however, saying "wikifying it" because there are a lot of other Wiki websites (such as Wikinews}other than Wikipedia.

ACEOREVIVED (talk) 06:23, 26 August 2009 (UTC)

For the term to have a chance of catching on, we'd have to associate it with our search toolbar -- e.g. as a substitute for the word "Go" in the search button. But when I imagine any of our current ideas being put in that position,

• Wiki it!
• Wikit!
• Wikisearch it!
• Wikipede it!
• WP it!
• Wikify it!
• Wikoogle it!
• Woogle it!
• Wing it!
• Waltavista it!
• Wahoo it!

I lose my appetite. Sorry Jimbo. Andrew Gradman ^talk/_WP:Hornbook 06:59, 26 August 2009 (UTC)

"Wik". Noisalt (talk) 11:33, 26 August 2009 (UTC)

No need to name it after a long-time banned user. It's like saying "Grawp it!", which, come to think of it, would sound good except for the, um, interesting connotations. :-) Graham87 16:11, 26 August 2009 (UTC)

I like "wiki it". - Peregrine Fisher (talk) (contribs) 16:16, 26 August 2009 (UTC)

I appreciate your liking of this term, but I stick with what I said above - I am a little unsure of "wiki it" myself, as there are other Wiki websites besides Wikipedia. How about Wikipede it, as AGradman suggested above? ACEOREVIVED (talk) 19:54, 26 August 2009 (UTC)

People, this whole discussion is out of place on this page, and pretty much useless anyway. We don't really get to pick. If a word arises, it will be by the usual, natural course of linguistic evolution -- someone says it and it catches on. Trying to direct that process is unlikely to be effective; it's more likely to just annoy people. --Trovatore (talk) 20:05, 26 August 2009 (UTC)

The task is to find an abbreviation of Wikipedia (5 syllables) that fits in "___ it" and is short verbally (not just in writing). Then we start using it. "Wiki it" slurs into weekeet. "Doubleyou-pee it" doesn't quite work. Check TFE? WiP? WP, pronounced as 'wip'? Whip it. Ha ha. From now on, in my head, I'll be pronouncing WP as Wip, and referring to Wikipedia as WiP. Join me! and soon we too may have an awesome nounverb.    M  

While I would never personally use any such verb, I never use "google it" either as I prefer ask.com, I would like to state I hope this thread continues and more chime in. Its fun, its interesting, it is what the Village Pump is about. Collaborate and do not let editors like Trevatore discourage or bully you into not posting and continuing. Wet-blankets abound and they need to be ignored, because if he or anyone else doesnt like this thread then they dont have to read it, we do not censor on wikipedia. Be merry and continue please. You are the heart of Wikipedia and jovial exchanges on here are a great distraction from the depressing arguments and petty bickering often found here. Collaboration should be encouraged, not stiffled. This is the perfect forum for this discussion, dont leave, I'll defend you to my last key-stroke.Camelbinky (talk) 01:29, 30 August 2009 (UTC)

Wikipate! Grandmasterka 03:26, 30 August 2009 (UTC)

In the same light that editors should never need to create articles about themselves if they think they're notable (as eventually someone will write an article about them anyway), I think trying to create a phrase for people to use is a fool's game. If society's consensus is that they enjoy saying "Wik it" or "Wing it", then that can be adopted as a neologism. Otherwise, I think we should just wait. Pushing for it almost seems like we're desperate to be "hip" and "in tune with society". Let's face it, we're on our own wavelength and not in tune with anything else. (That said, I heard that Wikipedia's natural frequency is similar to Middle C...) Greg Tyler ^{(t • c)} 21:58, 1 September 2009 (UTC)

I just noticed that Trovatore made the same point above and would like to clarify that the second half of my post is totally irrelevant, unfounded and spurious nonsense. Greg Tyler ^{(t • c)} 22:00, 1 September 2009 (UTC)

Wikipedia should keep peace on the earth...

Hello!

Sorry for my limited knowledge of English, but I think that the images like these:

http://az.wikipedia.org/wiki/%C5%9E%C9%99kil:Anti_Armenia.png

http://az.wikipedia.org/wiki/%C5%9E%C9%99kil:No_France.svg

http://az.wikipedia.org/wiki/%C5%9E%C9%99kil:No_Israel.svg

should not be in Wikipedia nor Users pages of Wikipedians.

Wikipedia should be a place for knowledge not for rasistic expressions of some users.

Skrabbit (talk) 16:45, 31 August 2009 (UTC)

Those images are on azwikipedia, and there's nothing we can do about them here. Sorry. Majorly talk 16:47, 31 August 2009 (UTC)

For what it's worth, they're actually all hosted on Commons. You could take the matter up there at Commons:Commons:Deletion requests or similar, though I can't say I'm up on Commons policies. Cool3 (talk) 17:12, 31 August 2009 (UTC)

I will happily tag those images on both with whatever their equivalent of {{db-attack}} is. Those images can't be used for anything positive I imagine. - ʄɭoʏɗiaɲ ^τ _¢ 17:14, 31 August 2009 (UTC)

Except the first image. Majorly talk 17:15, 31 August 2009 (UTC)

Thing is, not everything in life is positive, especially in an encyclopedia about everything. Majorly talk 17:15, 31 August 2009 (UTC)

Yes, but there's a difference between showing something negative that happened or that exists, and promoting hate. The anti-Israel flag is quite clearly being used in a negative way by the userpages it is on. - ʄɭoʏɗiaɲ ^τ _¢ 17:42, 31 August 2009 (UTC)

In fact, all three seem to be used on userpages, although I can't tell you much more than that... ~ Amory (user • talk • contribs) 20:02, 31 August 2009 (UTC)

(od) Somewhat relevant to this thread: commons:Commons:Deletion_requests/Image:Anti_Poland.png which also discusses commons:Category:Anti_logos and its >220 member files. I don't know what to make of the discussion, but in any case there isn't anything to be done within the scope of this project. BTW, someone attempted to speedy the no-France image and the speedy tag was quickly removed by the author. Sswonk (talk) 21:35, 31 August 2009 (UTC)

I have nominated the Israel one. It is clearly part of a political agenda, as can be gathered from the pages it resides upon. Unlike the anti-france or anti-japan images, it regards a current and ongoing confrontation, and not a simple dislike towards the policies of a government. - ʄɭoʏɗiaɲ ^τ _¢ 19:16, 1 September 2009 (UTC)

Table on the recent changes page

The content on the Recent changes page is very badly arranged. Could tha data be sorted in the table? --Janezdrilc (talk) 14:42, 28 August 2009 (UTC)

How would you prefer to see it? Who then was a gentleman? (talk) 19:27, 28 August 2009 (UTC)

The table could have about 6 columns: Column1 labels N or m, Column2 Title, then hour, counter of bytes, author and finally notes. --Janezdrilc (talk) 22:28, 30 August 2009 (UTC)

I don't understand. There are 7 columns already. Are you asking for more info, or less? Who then was a gentleman? (talk) 21:03, 31 August 2009 (UTC)

The OP may be interested in "Enhanced recent changes", which can be toggled in the "Recent changes" tab of Special:Preferences. Dendodge _T\^C 21:05, 31 August 2009 (UTC)

I meant a table with grid like this (for now there is just bulleted list):

(diff) (hist)	m	Hyderabadi haleem‎	01:58	(+3)	Sarabseth (talk | contribs)	→Preparation: grammar
(diff) (hist)	N	User:Darrenhusted/sandbox22‎	01:58	(-25)	Hooliganb (talk | contribs)	→Karl
(diff) (hist)		Wikipedia:WikiProject Macau/Popular pages‎	01:58	(+57)	Baxtersmalls (talk | contribs)	Popularity stats for WikiProject Macau
(diff) (hist)		Dexilla‎	01:58	(+456)	Mr.Z-bot (talk | contribs)	→Links: moved to subcategory, Replaced: Category:Tachinidae → Tachinidae-stub,, Removed: fly-stub, using AWB

I wonder whether you meant that you would like to see the Wikipedia "Recent Changes" feature become better categorised. At present, I agree that if you click on "Recent Changes", the only order seems to be the purely temporal order of the last x number of changes (which some Wikipedians might think is fair enough - after all, this is the name of this feature). However, perhaps there could be a way to categorise this feature, so people can find what they may wish to see in this feature more easily. ACEOREVIVED (talk) 20:02, 2 September 2009 (UTC)

Article wizard 2.0

Right, this has been on my back burner for a long time, and I've finally done it: based on the article for creation wizard, I've created Wikipedia:Article wizard2.0, (superceding the less helpful and less pretty and underused WP:Article wizard) as a generic wizard for registered users to create articles, including a simple template at the end. Comments please on the idea and execution; and on how we can promote it when it's ready. I've previously considered things like the MediaWiki page that produces the Search Results page (I forget the name now), that kind of thing. NB The one thing that the old Article wizard does that may be worth taking is emphasising the need to search for alternate spelling etc (see Wikipedia:Article wizard/other). But I'm tired and hungry now... Rd232 ^talk 14:13, 30 August 2009 (UTC)

I like it. I've posted feedback at Wikipedia talk:Article wizard2.0. hmwitht 14:34, 30 August 2009 (UTC)

It's an excellent start. I have a few comments, but have to gather my thoughts. Will respond in more retail at the talk page.--SPhilbrickT 17:53, 30 August 2009 (UTC)

Did not work at all, aborted without retry... and did not even say "thank you for your time, come next week...". Yes, I was honest, I really thought it's not ready for FA yet and will need some more work because the book says it's never too late and be bold and ... oh well. Seriously, I doubt that the user who do need help will actually go through all these hurdles. It's like a bank's call center computer that will drain your phone battery before even getting closer to whatever you needed... No, they'd better learn the rules the good old way. NVO (talk) 19:50, 30 August 2009 (UTC)

And the award for the least constructive comments on this topic so far goes to.... Seriously, a really good wizard of some sort would be a great asset. How about helping to create one? Or roll your own if you think this one is that bad a starting point. Rd232 ^talk 22:46, 30 August 2009 (UTC)

Wikipedia:Article_wizard2.0/subpage is broken (this is used in construction of a userspace proto-article)(instead of showing the name of the viewer, it shows the name of the last person to edit the page). Recommend replacing {{REVISIONUSER}} with Special:Mypage. --Thinboy00 @276, i.e. 05:37, 31 August 2009 (UTC)

done, thanks. Rd232 ^talk 18:57, 1 September 2009 (UTC)

An overview of Outstanding issues is now available at Wikipedia talk:Article wizard2.0#Outstanding issues. Thanks. Rd232 ^talk 18:57, 1 September 2009 (UTC)

Thank you for your work, I had thought about something like that and it could help some new users. Cenarium (talk) 17:11, 2 September 2009 (UTC)

Search box at the bottom of the page

Is there any way a Search box could be added to the bottom of every page? If one gets to the bottom of a page and is using Firefox, you have to grab the scroll bar and scroll all the way to the top of the page to get to the Search box. This isn't a problem in IE, which allows you to right click on the scroll bar and request to go to the top of the page, but you can't do that with Firefox. Or, maybe even just a link that says "Go to the top of the page". Who then was a gentleman? (talk) 20:57, 2 September 2009 (UTC)

Your keyboard doesn't have home or end buttons ? —TheDJ (talk • contribs) 21:11, 2 September 2009 (UTC)

See also Wikipedia:Keyboard shortcuts. Alt-Shift-f goes straight to the searchbox in Firefox on Windows or Linux. PrimeHunter (talk) 21:16, 2 September 2009 (UTC)

I never knew those would do that. Thanks. Who then was a gentleman? (talk) 21:19, 2 September 2009 (UTC)

On my Mac, I can also usually just hit Tab to force focus directly on the search field (though it'll get thrown off by other form elements, such as the options on the Watchlist or Contribs pages). EVula // talk // ☯ // 22:08, 2 September 2009 (UTC)

Proposal to transform the Audit Subcommittee into an independent committee and grant new responsibilities

Please see here for details on this proposal and preliminary discussion. It's proposed to transform the Audit Subcommittee into an entity independent of the Arbitration Committee and grant several additional responsibilities regarding the overseeing of the checkuser and oversight permissions. Cenarium (talk) 22:40, 1 September 2009 (UTC)

The question of the independence has been reported for later consideration, and there is now a proposal to add new responsibilities to the Audit Subcommittee and regularly organize CU/OS elections, also added to CENT. Cenarium (talk) 03:45, 3 September 2009 (UTC)

Unsourced tables

Is there a template for marking a table/chart/graph as unsourced (for example, something you can put underneath the image or the {{bar box}} that would say something along the lines of "the sources of this table/chart/graph are unclear"? I couldn't find any. And, if there isn't, does anyone think adding one would be useful? I could create one fairly easily. rʨanaɢ ^talk/_contribs 21:02, 2 September 2009 (UTC)

What's wrong with using the standard {{citation needed}}? hmwitht 21:20, 2 September 2009 (UTC)

I was thinking for marking a whole table, or an image, rather than specific facts within it. (The one that got me thinking about this was the bar chart at South Korea#Religion.) rʨanaɢ ^talk/_contribs 05:20, 3 September 2009 (UTC)

Well, I figured that you could either add it at the end of the table or after the sentence describing what's inside the table right above it. hmwitht 13:43, 3 September 2009 (UTC)

Organ harvesting poll

A poll has been created on whether Reports of organ harvesting from Falun Gong practitioners in China‎ is a standalone topic, or should it be merged to Organ harvesting in the People's Republic of China? Please go to Talk:Organ harvesting in the People's Republic of China/FG poll. Ohconfucius (talk) 14:04, 3 September 2009 (UTC)

I fixed that link for you. UltraExactZZ ^Claims ~ Evidence 18:05, 3 September 2009 (UTC)

Request move discussion {{otheruses4}} → {{about}}

I am requesting discussion on moving the common hatnote template {{otheruses4}} → {{about}} (or → {{otheruses}}) because the current name (with an arbitrary 4) is hard to remember and esoteric. I have started the discussion at Template_talk:Otheruses4#Request_move_discussion. If you are interested, please come to discuss whether the template should be moved and if so, to where. Thanks, -Sligocki (talk) 20:43, 3 September 2009 (UTC)

Link to the introduction instead of the community portal in the sidebar

Please see and comment here on this proposal. Thanks, Cenarium (talk) 23:03, 3 September 2009 (UTC)

Making our editing interface more clear and helpful

Hello all! You're probably aware that Wikipedia is reviewing its editing interface at the moment, the purpose being to make it easier to use. A lot of time and money is being spent, and this is all obviously a great idea. However, while the developers are still at work, I feel a massive improvement could be made relatively easily. The text that surrounds the edit box is confusing, unsightly, and not at all helpful. It is fragmented, and is clearly a product of years of tinkering by many different people. I feel we should take a step back and organise this important text in a much more presentable and informative way. Below are two images of the interface; before, and after my proposal.

The current editing interface, as seen by an anonymous user

Current proposal: two boxs – editing instructions for anons and newbies only at the top, warnings for all users at the bottom (incorporating the legally required text). Note also the text between the edit box and summary box.

Initial proposal: consolidate all the advice and warnings into a simple notice at the top.

As you can see, my proposal is simpler, clearer and prettier than the current situation. I'd also like that a similar one be created, identical except for the removal of the third 'create account' line, for users who are logged in. I'd also hope that its display could be turned off in user preferences. Anxietycello (talk) 15:48, 30 August 2009 (UTC)

Users with modest screen sizes will have to scroll a whole screen down to get to edit window. Why? NVO (talk) 19:32, 30 August 2009 (UTC)

It could be turned off by experienced users, so wouldn't affect you. It is mainly aimed at new and unregistered users. Anxietycello (talk) 21:12, 30 August 2009 (UTC)

First-time users will simply not find the edit window if it's in the bottom third of the screen or, worse, below the screen. They'd walk away. Usability basics. Of all the things that must be on the screen you've left out the most important. Edit window. NVO (talk) 18:19, 31 August 2009 (UTC)

That's highly speculative opinon, not usability basics. In my highly speculative opinion, I'd expect anon users to be more welcomed by the sentence "welcome to the eiting interface" than what they're currently faced with; the "you are not logged in" warning. See the second draft image below, in which the box takes up less vertical space. Anxietycello (talk) 19:53, 31 August 2009 (UTC)

Which is more than you can do with the current text, which takes up the same amount of room. Anxietycello (talk) 23:33, 30 August 2009 (UTC)

But you can easily hide it with the current setup. Also, you're missing the required text regarding the CC-BY-SA and GFDL. Anomie⚔ 00:54, 31 August 2009 (UTC)

Perhaps that highly technical text could be left as it is, but just after the save button (so that the edit here/summarise here text can be used). Anxietycello (talk) 12:52, 31 August 2009 (UTC)

I like this proposal, and you're absolutely right about the hodgepodge of the current interface. It needs developing but it's a good start. Obviously it would need to easily be disabled (and should mention in no uncertain terms that sources are required). —Noisalt (talk) 01:05, 31 August 2009 (UTC)

Perhaps there could be a [hide]/[show] symbol next to it, and an option to hide it outright in user preferences? I wouldn't say that Anomie's idea of 'easily' is the same as mine. Anxietycello (talk) 12:52, 31 August 2009 (UTC)

I can see how its clearer, by putting everything in once place. But I'm not sure its more helpful. This seems like cleaning your bedroom by putting everything on one shelf in the closet. Yes, the room is less cluttered, and you know where everything is, but that doesn't mean its a more usable system. Mr.Z-man 02:02, 31 August 2009 (UTC)

The main USP of my idea is that it has instructions on how to edit, for those within that market that we've so far been totally shunning. Anxietycello (talk) 12:52, 31 August 2009 (UTC)

But, it doesn't, really. It just takes what's already there, gets rid of a bunch of it, and puts the rest all in one place. Mr.Z-man 13:49, 31 August 2009 (UTC)

Just visually, there's too much whitespace on the page anyway. — V = I * R (talk to Ω) 14:03, 31 August 2009 (UTC)

Was that supposed to be a reply to me? Removing whitespace does not add instructions on how to edit. The proposed design does not have anything that the current interface doesn't, and I believe its missing things that the current interface has. Mr.Z-man 18:35, 31 August 2009 (UTC)

But it does! It has simple editing instructions - see the fourth, fifth and sixth bullet points on the top box. I have submitted a second draft, take a look at that, and I'm sure you'll be more satisfied. My proposal uses simple language in clear explainations. This may all seem moot to you, the experienced user, but I really feel for what those average joe types said in the video (File:Wiki feel stupid v2.ogv). Please take the time to read the recent Usability and Experience Study. My proposal is now this; the top box will display only to IP users (maybe also newly registered ones), and the bottom box will be perminantly visable to all. It's not just "thrown onto one shelf", it is a clear, coherant organisation of several highly important – fundamental, even – messages that must be taught to new users. Anxietycello (talk) 19:33, 31 August 2009 (UTC)

I agree that we need better instructions, but "Type in the big honking box full of text" is pretty much "Using a Computer 101". Anything that involves typing more than a few words typically involves typing in a textbox and almost every form everywhere on the internet has buttons. If anything, "Show changes" is the one that needs explanation. The problem is the complicated nature of wikitext, not people not being able to find the editbox or the "Save" button. Have you actually watched the video you keep linking to? Mr.Z-man 21:38, 31 August 2009 (UTC)

Yes I have, and the thought I went away with were that people were baffled by the information overload on reaching the edit page. Ok, I can see that the instruction box preceding the edit box isn't filling everyone with enthusiasm. Would you support the text shuffle following the edit box? Being more organised, perhaps it will be easier for people to understand the basic rules, etc.? Anxietycello (talk) 23:03, 31 August 2009 (UTC)

You should take this to the Usability initiative, since this is exactly what their working on right now... — V = I * R (talk to Ω)

Drawn up a new draft, adding the suggestions given. Header moved to the sides to shrink the box and remove whitespace. The code I used to make the text and boxes can be found at User:Anxietycello/Interface. Anxietycello (talk) 14:15, 31 August 2009 (UTC)

If you were reducing the amount of text, then I would support it. But you're not, so I don't. I would get rid of the "Welcome to the editing interface!" to start. Maybe if that was displayed only the first time, it might be OK (probably not), but it would become annoying fast. Having to dismiss it would also be annoying. Anyways, I would liek to see the six sentences reduced to about two. - Peregrine Fisher (talk) (contribs) 21:32, 31 August 2009 (UTC)

The top box would be displayed to anonymous users and newly registered accounts only. You would never see the top part, except when not signed in. Anxietycello (talk) 22:16, 31 August 2009 (UTC)

Well, then how about a shorter bottom box? - Peregrine Fisher (talk) (contribs) 22:24, 31 August 2009 (UTC)

Afraid not; the last four bullets are required by law in order for the website to operate, and the first two bullets are our own rules, which are fundamental to the operation of our encyclopedia. These things need to be said. Anyhow, as it stands, my box takes up less room (about 20% less) than the current situation and still says all the same things. Anxietycello (talk) 23:03, 31 August 2009 (UTC)

What's with the side boxes saying "Welcome"? Get rid of those. —Noisalt (talk) 00:21, 1 September 2009 (UTC)

Trimmed down alterations

A rearrangement of the text that follows the edit box. My proposed version (right) contains all the text of the current version (left), but presents it in a more logical and clear fashion. It also includes a request that all work submitted be neutral, verifiable and encylopedic - the core of our complex rulebook. Note how it also takes up less room.

Ok, I can see that the idea for the box I started with is not being happily accepted, for both aesthetic and practical reasons. Perhaps a simpler reform would be better recieved? Forget the top box for now, and lets focus on the mess of text below the edit box. As I said before, it is fragmented, and is clearly a product of years of tinkering by many different people. It is also a highly important peice of information, one that people should be able to easily read and understand. I therefore propose the above re-organisation. Any thoughts? Anxietycello (talk) 00:56, 1 September 2009 (UTC)

I can only support less text, but others may like more, I don't know. - Peregrine Fisher (talk) (contribs) 01:00, 1 September 2009 (UTC)

It takes up less vertical room than the current situation, and is only 168 words vs the current 183. While I do agree that it should be as short as possible, I also feel that all the text in my proposal is necessary. Is it so hard to scroll past? Surely you wouldn't need to very often? Anxietycello (talk) 01:23, 1 September 2009 (UTC)

I see what's going on. I didn't even see the "If you do not want your writing edited" stuff in the original because it's in a small font. I think I like the placement, but I'm not liking how it seems so much longer, even though it's shorter. - Peregrine Fisher (talk) (contribs) 01:30, 1 September 2009 (UTC)

See, yeah, it is as if having some text <small> and some text <big>, some bold and some bulleted makes things less visible, somehow more easy to gloss over. It's all important! Is that what you mean by it seeming longer now? Actually not so easy to ignore? Anxietycello (talk) 01:42, 1 September 2009 (UTC)

Well, I'm not convinced that it's all important, but yes, that is what I mean. - Peregrine Fisher (talk) (contribs) 02:21, 1 September 2009 (UTC)

Also, after 20000 edits, today is the first time I've ever bothered to read any of that. It's kinda like the ads on the side of a google search. I don't even see it. Can we just link to an explanatory page? - Peregrine Fisher (talk) (contribs) 02:27, 1 September 2009 (UTC)

Unfortunately, no, we can't. It has to be on that page as specified by the organisation that issues wikipedia with its licencing rights. See anomie's post above. 212.183.134.64 (talk) 02:38, 1 September 2009 (UTC)

That's not true. Lots of sites have a "Terms of Use" link, with all the info on a dedicated page. - Peregrine Fisher (talk) (contribs) 03:12, 1 September 2009 (UTC)

Lots of sites copywrite their text and operate for profit. We run under a very specifically free licence that has very specific rules. See here Anxietycello (talk) 14:48, 1 September 2009 (UTC)

I'm honestly not trying to be a stick in the mud here, but I'm really wondering why this discussion is occurring here rather then on the Usability study page. This is exactly what they are tasked with studying and improving, and they have the money, resources, time, and backing of the WMF to actually implement changes. Their also smack dab in the middle of evaluating exactly what this is attempting to address, so your suggestions and comments would be much more likely to have an impact there regardless.
— V = I * R (talk to Ω) 06:02, 1 September 2009 (UTC)

Ok, I've posted to Wikipedia Usability initiative here. -- Anxietycello (talk) 17:45, 2 September 2009 (UTC)

Hmm. Hadn't seen that meta page. It looks like we could trim it, but I'm not going to follow this discussion between wikis. Good luck. - Peregrine Fisher (talk) (contribs) 17:50, 2 September 2009 (UTC)

Strong support, the current state is really a cluttered mess. The symbol box should be right under the submit box (BTW, wikEd aleady rearranges the page in that way). The proposed text should actually be tweaked to be more concise and easier to read. Cacycle (talk) 21:20, 4 September 2009 (UTC)

Editable history

We talked about this a little bit, above. There should be a method to edit the minor flag and at least your own edit summaries. The easiest way that I can think of to implement that would be to add them as editable fields to the old revision view of a page. That page is missing the edit summary anyway, so this is technically two enhancements. Bug 20511
— V = I * R (talk to Ω) 05:31, 5 September 2009 (UTC)

Something like that has already been proposed (Wikipedia:Village pump (proposals)/Archive 30#Being able to edit your edit summaries, Wikipedia:Village pump_(technical)/Archive 44#Edit summary grace period?, bugzilla:13937). In short, something like that would be somewhat useful in some rather rare cases and very confusing in some other rare cases (for example, when someone has already seen the previous edit summary). Thus some precautions would be necessary... On the other hand, a script or a gadget that would allow one to confirm the edit summary to prevent the editor from saving the page accidentally (proposed in Wikipedia:Village pump (proposals)/Archive 30#Being able to edit your edit summaries by Rjd0060) does look like something that might be helpful sometimes... --Martynas Patasius (talk) 15:24, 5 September 2009 (UTC)

Ah, thanks for pointing out the other proposals. I searched high and low for them, but I must have been using the wrong keywords (I suspect that "edit edit" and the like is a real issue for search engines, here). Anyway yea, I see a lot of nay-saying, but I don't see any real criticism of the idea/proposals (I'm obviously for the idea though...). The gadget implementation/functionality already exists, but that is not even close to a complete solution.
— V = I * R (talk to Ω) 17:03, 5 September 2009 (UTC)

Add more html tags... especially abbr and acronym

wikipedia has <code></code> <u></u> <b></b> <i></i> <s> </s> but is missing very useful tags such as CSS or <acronym title="North Atlantic Treaty Organisation">NATO</acronym> which would really help with the readability of articles. This would make it so users wouldn't have to scroll up to the top of the page to remember what an acronym stood for. Personally, I think all acronyms/abbreviations should use this tag. We could start by just enabling the feature. Dragonsshadows (talk) 16:08, 4 September 2009 (UTC)

Well, I am in no way against this per se, but to remind eveyone, all initialisms should be spelt out the first time they're used, which might devalue the suggestion. - Jarry1250 ^{[ In the UK? Sign the petition! ]} 16:10, 4 September 2009 (UTC)

I tend to spell them out at least once per section, personally. Of course, the really well known abbreviations (NATO, NASA, US, etc...) don't normally need to be spelled out at all, but that's a whole different story.

You can acomplish the goal here with linking, by the way (as long as there is a redirect, at least). For example: CSS shows "Cascading Style Sheets" when you hover over the link.
— V = I * R (talk to Ω) 16:27, 4 September 2009 (UTC)

It's worth pointing out that the current HTML 5 proposal is leaning toward deprecating both <abbr> and <acronym>, because the suggested use – marking up a string once so that specialized tools get a hint about how to treat the same string elswhere – doesn't really fit the HTML model. It's probably not a good idea to add tags that will have to be ignored by most clients in the future. — Gavia immer (talk) 18:34, 4 September 2009 (UTC)

<acronym> is to be obsolete in HTML 5, but <abbr> is listed as what should be used in its place^[5] and it says that they should be treated the same^[6]. Mr.Z-man 16:34, 5 September 2009 (UTC)

• The following templates may be of interest:
  • {{tooltip}}, which uses the title attribute, available on most (X)HTML elements: CSS 2
  • {{abbr}}, which uses the abbr attribute: IMF , and {{abbrlink}} which wikilinks the term: IMF Tooltip International Monetary Fund
     –Whitehorse1 16:55, 5 September 2009 (UTC)

Finding out when an article was created in the "History" of an article

At present, if you go to the "History" of an article, it is not easy to find when an article was first created if it has had a long history - for example, the article Criticism of Wikipedia has been in existence since at least August 2005 (I gave up back-tracking after then). Please forgive me if you are more informed about the mechanics of Wikipedia than me, as there may be an ansewr to this one already - is there a simple way to find out the date when an article was first created? If I am making a proposal here, it is to have something like a little note saying when an article was first created in the "History" of the article. ACEOREVIVED (talk) 20:42, 5 September 2009 (UTC)

There certainly is. Click History, scroll down, and click "earliest". It's underneath the 'Compare selected revisions' button. The creation date is the first entry at the bottom of that page. –Whitehorse1 21:01, 5 September 2009 (UTC)

^ That. By the way, I've replied re Oldafdfull up ^^^ there somewhere. - Jarry1250 ^{[ In the UK? Sign the petition! ]} 21:13, 5 September 2009 (UTC)

It's not even necessary to scroll down to click the "earliest" button, it's at the top too. -- œ^™ 02:18, 6 September 2009 (UTC)

Proposal: Always indicate length of block

(I am not sure if this is the right place for this proposal. I looked around but didn't find anywhere better...)

I have noticed that some "you've been blocked" messages that admins add to the talk page of a blocked user do not include the duration of the block. The length of the block can be found elsewhere, but it seems like a fundamental characteristic of the block and should be included in the blocked user's talk page entry. Is there some reason why it's not included? If not, I propose that the length of block always be included in such messages, and block templates be adjusted (docs and otherwise) to indicate the requirement. Alternatively, perhaps there is some way for the Wiki software to detect the length of the current block and the templates could be modified to use that mechanism and thus avoid the need for the admin to specify the information manually.

FYI, here is one recent example. (I am not criticizing the admin involved in that edit.) Here's is another example by a different admin who apparently added the length of the block by adding text that wasn't part of the template. — John Cardinal (talk) 15:49, 4 September 2009 (UTC)

I think you are a little confused with your diffs - the first one you give is for a second block notice that does contain the length. The second one is not an admin adding the block length to another admin's notice, but rather a single admin placing a block notice with a note about the length after it. In any event your core point remains - block notices should absoultely specify the length of the block being made. This should probably be mentioned in WP:BLOCK. Shereth 16:00, 4 September 2009 (UTC)

Hmm... I did post the wrong URL for the first block--sorry about that. For the second, I didn't explain it well. I was indicating that the admin was different from the first URL. My point was that the length of the block seemed to be added outside of the block template the admin used. In other words, the admin keyed something like this:

{{someblocktemplate}} Blocked for 1 week

... as opposed to specifying the length of the block as a parameter to the template. — John Cardinal (talk) 18:17, 4 September 2009 (UTC)

Some admins don't use a template at all... –xeno^talk 18:19, 4 September 2009 (UTC)

Sometimes I don't want the vandal to know how long they've been blocked for. I don't want them coming back. EVula // talk // ☯ // 19:30, 4 September 2009 (UTC)

The message the blocked person sees when they try to edit shows the length of the block already, the talk page note is just for other people looking at the block, who can also look at the block log. MBisanz ^talk 20:05, 4 September 2009 (UTC)

Agreed, I don't think this is a big issue. –Juliancolton | ^Talk 01:41, 5 September 2009 (UTC)

I wasn't concerned about the blockee; this is about the other interested parties. If the message is going to be there at all, why not have it be complete? — John Cardinal (talk) 02:50, 5 September 2009 (UTC)

I often leave out the length particularly with IPs so that they don't just mark their calender and come back. Chillum 02:57, 5 September 2009 (UTC)

That doesn't seem like good logic to me. If we don't want them to come back, we should make the block longer or permanent. In addition, if they try to edit they are told the length of the block (I've never seen this—never been blocked—but someone described it above). If the length is not a secret, then it's not a secret. — John Cardinal (talk) 03:14, 5 September 2009 (UTC)

Just because something is not a secret doesn't mean we should go out of our way to broadcast it. And for IPs, lengthening the block sometimes isn't an option. The block duration may be shown when they try to edit, but there's also the very real possibility that they may not notice it, become discouraged by having the fun ruined, and simply go away. EVula // talk // ☯ // 04:14, 5 September 2009 (UTC)

IPs sometimes change owners, sometimes they do not. I don't do a longer or indefinite block to avoid collateral damage. Chillum 03:19, 5 September 2009 (UTC)

I have to admit that the idea behind "sometimes I don't want them to know" makes me uncomfortable. I understand completely where that's coming from, I've been there myself, and there is no means to actually keep it secret, but... Anyway, this doesn't really bother me personally, but I wanted to mention my thoughts there.
— V = I * R (talk to Ω) 04:37, 5 September 2009 (UTC)

Whenever I block someone, I add the length of the block in the template and in the message. It's a matter of courtesy. The blocked person has a right to know the duration of the block. JoJan (talk) 14:34, 5 September 2009 (UTC)

(outdent) The current situation doesn't seem rational to me: any blocked user who tries to edit is told they are blocked and for how long, yet some admins don't put the length of the block in the talk page entry where it's useful to other editors. It doesn't make sense to me that omitting the length of the block helps avoid collateral damage, as uninvolved editors who happen to use the same IP and try to edit will see the block info. Moreover, it's unlikely they'll see the talk page entry unless they are veterans, in which case they'll know how to find the block info. I thought through some other use cases and I don't think there are any where hiding the length of the block has any real benefit.

I can't accept arguments based on users not noticing information that we deliberately put into the message. It's irrational: if we put the info in the message, we intend the user to see it. If we don't want them to see it, we should leave it out. If we want some users to see it, and others not, well... how does it feel to want? Once we display the message, we can't control which readers notice and which ones don't.

On the other hand, the info is available and my proposal was only intended to make it more convenient to see it. There's clearly not consensus and while I don't agree, it's not a big deal. Thanks for considering this proposal. — John Cardinal (talk) 15:06, 5 September 2009 (UTC)

As nonsensical as the current situation may seem to you, I'm just as puzzled at your insistence that not including the block duration on the talk page is some actual issue. Who needs to see the block durations the most? Admins (useful in gauging how long to block a repeat offender). Sysops can see that from the Special:BlockIP page, they don't need to refer to the talk page (at least, they should be doing that). Regular editors most likely don't care, and if they do, they can always click on the very readily apparent Block Log link on Special:Contributions. The argument can be made that a user's contribs are a better gauge of their actions than their talk page (where warnings and block notices can easily be removed); in reality, any user who is only looking at a talk page without checking contribs or the block log when dealing with a suspected vandal (account or IP) is doing a poor job of investigating. As has already been pointed out, the user that's been blocked doesn't need it on their talk page either.
As I can only think of three parties that might reference a block's duration, and have illustrated how it's a non-issue for all three parties, I'm wondering what the exact problem is. EVula // talk // ☯ // 19:51, 5 September 2009 (UTC)

I agree with EVula, I don't put the block time because people should be referring to the block log. An admin can make a mistake in the talk page message, a vandal can change the message, two admins can block simultaneously making the block length message incorrect. Maybe you want to see the block log at the bottom of the talk page if a user is currently blocked? Possibly a good idea.--Commander Keane (talk) 11:11, 6 September 2009 (UTC)

Photo tags

Wikipedia will benefit greatly from photo tags. When looking for a picture of a specific person, every article on a person, place or thing can have itself tagged on specific pictures. Like that, when looking for a picture of "Barack Obama", all the pictures tagged with his name will appear. This will make editing much more convenient. Feedback ^☎ 03:07, 6 September 2009 (UTC)

Search Commons. Categories there are used to similar effect (e.g. category:Barack Obama --Cybercobra (talk) 03:37, 6 September 2009 (UTC)

Categories aren't the same. And not all pictures are in Wikimedia Commons. Feedback ^☎ 12:31, 6 September 2009 (UTC)

Categories are supposed to be what you're looking for, though.
— V = I * R (talk to Ω) 13:27, 6 September 2009 (UTC)

Deletion discussions with "No Consensus" as a result

There are some articles which were nominated for deletion and the reult is "No consensus". Should we then be given information about the default position being keepig the article? ACEOREVIVED (talk) 21:28, 3 September 2009 (UTC)

What information are you looking for? — The Hand That Feeds You:^Bite 22:51, 3 September 2009 (UTC)

I can give an example - if you look at the article on Bob Taggart and go to its talk page, you can see that the article was nominated for deletion in August 2009; the tag on the talk page just says "The result of the discussion was no consensus". I guess that I am really saying that this tag needs modification, so that it should say something to the effect of "The result of the discussion was no consensus, and therefore the article is being kept, as that is the default position". ACEOREVIVED (talk) 23:09, 3 September 2009 (UTC)

Isn't that sort of implied by how the article wasn't deleted? Mr.Z-man 23:32, 3 September 2009 (UTC)

[edit conflict] ¶ I think that, in general (and not just with –fD discussions), when no clear consensus for a specific, articulable change can be gathered, the bias is in favor of stability and thus no action. [For one thing, to echo Eugene V. Debs' refusal to lead workers to the Promised Land, if something can change easily one way without a firm consensus, it could just as easily change back in the other direction, resulting in ping-pong or a magnified but legitimate variation of edit warring.] There are many things that I, like any editor, might like to change, but the onus is on the innovators rather than (despite WP:Ownership) upon those who prefer to keep the status quo ante. But that's probably a philosophical point when you're asking something more practical. —— Shakescene (talk) 23:46, 3 September 2009 (UTC)

The template ({{oldafdfull}}) uses the "result=" parameter, with result being what we want, so we couldn't change the existing ones without massive edits. They are linked in the form {{oldafdfull|page=<pagename>|date=<date of nom>|result='''keep'''}} below the afd tag for easily copy/pasting them to the talk page. So it would be too much cost for a little benefit in any way we proceed. Cenarium (talk) 00:01, 4 September 2009 (UTC)

We could, I think (if I understand correctly, not guaranteed), add some jiggery-pokery to the template to display something different from the input parameter ( {{#ifeq:{{{result}}}|'''No consensus'''|'''No consensus[1]'''|{{{result|}}}}} ?) which would probably add some overhead but which would ultimate be one edit. - Jarry1250 ^{[ In the UK? Sign the petition! ]} 19:06, 4 September 2009 (UTC)

Thank you Jarry 1250, that is the type of thing I had in mind. A template such as "No consensus - result = keep article (default position)" would be more informative than what there is at present, and would not require major editorial changes. ACEOREVIVED (talk) 23:13, 4 September 2009 (UTC)

I've done a quick mockup to test that the theory works at Template:Oldafdfull/sandbox - but everything about it can be changed. Hope that helps, - Jarry1250 ^{[ In the UK? Sign the petition! ]} 18:12, 5 September 2009 (UTC)

I can see how this could be helpful for clarity. But I don't think the wording is right. Saying that our default position is 'keep' sounds too much like an official standing. As said above, "no consensus" just means to leave it be. A closure as "keep" can be held as future evidence that the article is worthwhile, whereas a "no consensus" means that no agreement was reached, and the article could still reasonably be deleted or kept. Perhaps the text should state something more like '* This technically equates to a "keep" consensus, but shouldn't be considered as such.' Thus it states that the result isn't to keep the article, but physically the article is in the same state as it would be should a "keep" result appear.

I'm aware that that wasn't explained brilliantly. But do people see what I'm getting at? Greg Tyler ^{(t • c)} 22:17, 7 September 2009 (UTC)

I agree that no consensus means do nothing or perhaps do not delete. I would support an explanatory link worked into the text, pointing to WP:Articles for deletion#How an AfD discussion is closed. WP:Guide to deletion#Recommendations and outcomes is an alternative if an explanation of no consensus is added. Flatscan (talk) 04:11, 8 September 2009 (UTC)

Mind maps

I think it would be great to use the "what links here" and "what links from here" information for creating mind maps. The reader would only need to specify in how many "levels of links" he or she is interested. For example, I would like to see all "what links here" and up to two levels of articles linked from the current page, i.e. a map with the current page in the midle, pages linking to the current page, pages linked to from the current page ("at level 1") and pages linked to from these ("at level 2"). Anša (talk) 12:22, 6 September 2009 (UTC)

Oh, oh oh! Can we play the 7 degrees from Kevin Bacon game with his article using this proposal?! "How many articles can you use to link Kevin Bacon with gravity?" It sounds like a fun game to me.Camelbinky (talk) 17:58, 6 September 2009 (UTC)

I seem to remember something, probably an off-site tool, that allows you to do just that. ♫ Melodia Chaconne ♫ (talk) 18:08, 6 September 2009 (UTC)

There's the six degrees of Wikipedia game (google it), but it's a bit out of date and different from this, AFAIK. - Jarry1250 ^{[ In the UK? Sign the petition! ]} 18:09, 6 September 2009 (UTC)

Cool, I like the Six degrees of Wikipedia project. However, my motivation is to get a "mind map", i.e. a picture showing connections between concepts. The link structure should reflect this to a large degree, although the average distance from one article to any other being around 4.5 (as to March, 2008) makes it clear that this works only on the first few levels. Still, it could work nicely in the more specialized areas, such as links among articles on special topics in the natural sciences. Maybe, mindmaps could be constructed from some more elaborate list of wiki articles, such as the division into categories. Anša (talk) 09:44, 7 September 2009 (UTC)

Would this help identify WP:Orphans ? —— Shakescene (talk) 10:19, 7 September 2009 (UTC)

More Privacy and Rights for Users Who Are Being Checkusered

Users who are being checkusered and accused of having sockpuppet accounts should have more privacy and the right to defend themselfs when banned/blocked. At the moment such users get blocked and banned without any warnings and have their private information displayed for everyone to see. They cannot edit or defend themselfs either.

My proposal is:

1.) Being more discreet about private information such as related IP-info (even when used for editing)

2.) The right to edit their talkpage so they can defend themselfs. —Preceding unsigned comment added by 7853hgh (talk • contribs) 14:12, 7 September 2009

I don't think we give out private information unless it is relevant to addressing behavioral problems. And generally people are allowed to edit their talk page unless they have a history of abusing it. If this has happened to you then perhaps you could link to where this has happened? Chillum 14:16, 7 September 2009 (UTC)

Their private information is not displayed for everyone to see, and with the exception of extreme cases, blocked editors are allowed to defend themselves on their talk pages. That said, Checkuser information covers more than just their IP; a CU won't take action based on weak evidence. EVula // talk // ☯ // 16:14, 7 September 2009 (UTC)

• Disclosure: I have checkuser privilege, but not on en.wp.

The WMF privacy policy provides very strong protection of logged user information. Are you familiar with it? Do you have reason to believe it has been breached? Otherwise, how would you characterise it as being deficient in relation to being 'discreet'?

To my knowledge, the vast majority of user-specific blocks permit the user to continue editing their talk page. This courtesy isn't extended where the talk page is used for abuse, or there is good reason to assume it will be used for abuse.

Detecting sockpuppets with the aid of data provided by the checkuser tool is not particularly difficult unless the puppeteer devotes significant effort to hide their tracks. Please, remember this is combined with publicly available information such as user contribution history. --Brian McNeil /^talk 17:58, 7 September 2009 (UTC)

Proposal to add link to Wikinews in Template:Recent death

A proposal to add a link to Wikinews articles in {{Recent death}}. Please see Template_talk:Recent_death#Optional_link_to_a_Wikinews_obituary. Thank you for your time, Cirt (talk) 17:25, 7 September 2009 (UTC)

♣ Questionnaire on Wikipedia Editors' Motive and Characteristics

Greetings.

Korea Information Society Development Institute (KISDI), a government-affiliated research institute, conducts a research on motive for contribution as well as cultural characteristics of participants in collective intelligence sites as Wikipedia and Yahoo Answers. (See www.kisdi.re.kr for the detailed information about our Institute.)

The survey aims to identify factors affecting Wikipedia users' usage and participation. Your responses are absolutely confidential and will only be used to extend our understanding of collective intelligence. We count on your responses to help us make policies for encouraging collective intelligence.

A small amazon gift card will be offered for those who complete the survey.

Thank you for your full cooperation.

Sincerely,

Joo-Seong Hwang | Senior Research Fellow | Convergence and Future Strategy Research Division

E-mail redacted

→Click

Please do not include contact details in your questions. We are unable to provide answers by any off-wiki medium and this page is highly visible across the internet. The details have been removed, but if you wish for them to be permanently removed from the page history, email this address.--Unionhawk ^{Talk E-mail Review} 01:19, 8 September 2009 (UTC)

Pure vandalism edits

I was just thinking that it would be nice to be able to mark pure vandalism edits as such, in a pages edit history. The benefit to that could be the ability to hide such edits if the viewer desires to do so (in the same manner as minor edits and bot edits can be "hidden").
— V = I * R (talk to Ω) 07:31, 3 September 2009 (UTC)

Well, who would mark the edits as vandalism? Sysops are too few, but if everyone could do it it'd be abused. Maybe based off of the rollback ability? It seems like the kind of thing that could easily be misused. ~ Amory (user • talk • contribs) 13:57, 3 September 2009 (UTC)

Maybe a flag this edit button on the edit page that allows admins to take a look at it.Accdude92 (talk) (sign) 14:03, 3 September 2009 (UTC)

(edit conflict) That's just more work for the admins, and not worth it. Also, if it were just based on around rollback, you'd miss shady uses of it. hmwitht 14:05, 3 September 2009 (UTC)

Maybe a new group of people that only have registered user power, and the power to deal with vandals.Accdude92 (talk) (sign) 14:10, 3 September 2009 (UTC)

huh... I've seen this thought process expressed before here. I'm not really sure how this could be abused, anymore then the "minor edit" flag could be and is abused. Everyone always seems to want new features limited to some select group or another as well, which I don't understand either. Ah well.
— V = I * R (talk to Ω) 14:13, 3 September 2009 (UTC)

The minor edit argument is, for lack of a better word, minor. In this case, however, I can easily foresee t3h ePIC LULZ that would be achieved by marking edits as vandalism, especially those reverting vandalism. ~ Amory (user • talk • contribs) 17:24, 3 September 2009 (UTC)

I honestly don't see why... maybe I'm just not explaining what I envision correctly? All it would do is exactly what the minor flag does now, which is basically nothing. Whether or not a particular edit, or even a whole series of edits, is marked isn't actually going to have any real impact aside from possibly making the use of that flag pointless.

While we're on the subject though, It would also be nice to be able to edit the minor flag. I know that I've either forgotten to click it or accidentally clicked it several times, and I know that some people will either always or never use it, so being able to edit them ought to increase their utility in most instances. Being able to edit my own edit summaries would sure be nice, as well.
— V = I * R (talk to Ω) 17:34, 3 September 2009 (UTC)

The difference is that people can only mark their own edits as minor. Unless we expect that vandals to mark their own edits as vandalism, this would mean that people could mark other people's edits as vandalism. Mr.Z-man 17:38, 3 September 2009 (UTC)

In which case it would be entirely unnecessary makework and inconsistently applied. –xeno^talk 17:40, 3 September 2009 (UTC)

There's an easy "fix" (in quotes because I don't see the above as an issue, but I recognize that many do) to that issue: Tie the use of the "vandalism flag" to the undo feature. Since pure vandalism edits are almost always undone, this seems to me to be an obvious choice.
— V = I * R (talk to Ω) 17:59, 3 September 2009 (UTC)

What we should do is give everyone the ability to roll back (well, all autoconfirmed users, or everyone who asks for it - and strongly encourage people to ask for it - but take it away from the minority who abuse it). Then we could make rollback the standard recommended way of dealing with vandalism, and record rolled-back edits as vandalism edits. This could be used for all sorts of purposes - filtering watchlists and edit histories as suggested here, and automated tracking/warning/blocking of vandals (though obviously no automatic blocks just because a lot of your edits got rolled back). Obviously you'll get occasional misuse, as you do with every WP feature, but that shouldn't be a reason not to do it when it could provide such benefits.--Kotniski (talk) 17:48, 3 September 2009 (UTC)

Is there a problem that this solution purports to solve? –xeno^talk 17:55, 3 September 2009 (UTC)

Yea, I guess. I'm not real clear on exactly what rollback is (an easy multiple undo, is the best sense of it that I have). My only real worry there is that it's not as transparent. Everyone can see reverts in thee history, and I think that is the way it should be. I just want a way to hide them in the history when their in the way, is all.
— V = I * R (talk to Ω) 17:59, 3 September 2009 (UTC)

Kotniski's suggestion wouldn't work. Native rollback is used for many other things other than vandalism (bots gone wrong for example, and some people use various edit-summary-changing scripts to use rollback in place of undo). I think that it's too complicated to do what you want to do. Even if it were tied to a rollback, then shouldn't the rolling back edit be hideable as well? –xeno^talk 18:06, 3 September 2009 (UTC)

(edit conflict) Yea, I think so. To be clear, all I want, and all I think is ever needed, is a dumb flag. Even if anyone could edit the flags of anyone else's posts, it wouldn't really be harmful. It may make using the flag on the edit history of that page somewhat pointless, but that's not really a big deal. That's also the reason why I honestly don't see is as an abuse issue. There's just no exposure provided by it, which is what vandals and trolls always really want.
— V = I * R (talk to Ω) 18:18, 3 September 2009 (UTC)

(1) Rollbacks are just as visible in the history as undos. (2) If there were an option to hide rolled-back edits, then presumably it would include hiding the rolling-back edits (this is obviously something for the developers to think about rather than us). (3) Obviously the software could detect whether the rolled-back edit was made by a bot, and adjust accordingly. (4) If someone changes the edit summary, the software could easily detect that. (5) It's not complicated - it would make things much simpler (well, it would give developers a means of making things much simpler for editors - vandals could be warned/reported automatically, so we wouldn't have to worry about that any more). (6) A few trifling concerns is no reason to say right from the outset "this suggestion wouldn't work".--Kotniski (talk) 18:15, 3 September 2009 (UTC)

eeech... "vandals could be warned/reported automatically" now I think we're getting in to real potential abuse area. I could just imagine some schmuck tagging 100 people and causing an uproar before being blocked.
— V = I * R (talk to Ω) 18:21, 3 September 2009 (UTC)

This introduces many layers of complicated interactions, with only very minor benefits. –xeno^talk 18:23, 3 September 2009 (UTC)

I think the potential benefits far outweigh the alleged complexity (it's not complexity anyway, it's - shock, horror - "something we're not used to"). And the "uproar" in the case described would be minor - let him do that, it's better than having him vandalize 50 articles (and we're talking autoconfirmed accounts here, not random IPs, so it's not going to happen every day).--Kotniski (talk) 12:55, 4 September 2009 (UTC)

I was talking about the complexity of changes we would be asking the Mediawiki developers to make. –xeno^talk 14:39, 5 September 2009 (UTC)

I have to admit that this thought crossed my mind as well. That's actually one of the benefits that I see to what I'm actually proposing here though, in that implementing the flag idea should be fairly straightforward. It's essentially just a copy of the existing functionality for minor flags, along with the addition of a bit field in the database table. It's entirely possible that there's some underlying problem with doing that, and I would be perfectly willing to accept it if that turns out to be the case, but somehow I doubt it. The rollback thing, on the other hand... that's a whole different ball of wax.
— V = I * R (talk to Ω) 15:05, 5 September 2009 (UTC)

It's not really, though, is it, it's just implementing your suggestion using existing functionality (the rollback button could be the vandalism flag). The only problem is overcoming the WP superstition that rollback is an important privilege that needs to be guarded. Anyway, I'll vote for your bug report.--Kotniski (talk) 16:28, 5 September 2009 (UTC)

Doesn't the rollback tool already use tags to mark some rollbacks as "vandalism"? Personally, I think that access to the rollback and admin tools ought to be fairly automatic, but that's a whole other issue. My main thinking in bringing this up was just to add a relatively simple, and non-controversial, means of marking and "hiding" those edits ("Hiding" as in the ability to mask them out just like minor edits or bot edits can be currently). I can see where you're going, and I don't really disagree, but I just don't see that type of proposal going anywhere "politically". I think that this at least has a chance, and could even prove to be statistically useful down the road.
— V = I * R (talk to Ω) 16:56, 5 September 2009 (UTC)

Enhancement request filled

Anyway yea, the proposal is to just add a simple flag, exactly like the minor flag, which we could add to posts. The simple implementation is to make it's use available when using the undo feature (to mark the edit being undone). The more involved implementation would be to ask to have the tick box on the edit page (I'm not sure what the correct name for this would be, but the version that you see when you click on the date link of an edit from the page history). That page could actually include check boxes for both, "minor" and "vandalism", and if it's your own edit, it could allow you to edit the summary as well.
— V = I * R (talk to Ω) 18:33, 3 September 2009 (UTC)

Yes, independently of the above more far-reaching idea based on popularizing rollback, I think this is a good idea. --Kotniski (talk) 12:55, 4 September 2009 (UTC)

Bug#: 20510 filed for the "vandalism flag", specifically. Maybe it'll get somewhere, maybe not... It's a small thing, but I think it would be nice.
— V = I * R (talk to Ω) 05:25, 5 September 2009 (UTC)

another possible complication

I've seen "RVV" or "vandalism" in many edit summaries, when in fact that what was not what the reverted entry was. Sometimes it's pure disagreement or difference of opinion; sometimes the reverted editor was going by a different unit or spelling convention; and sometimes that editor had a different source of facts (sometimes more recent, sometimes older, sometimes just different). Often what seems obvious to the average reader (and thus the most recent editor-but-one) has been shown over extended discussion on a Talk Page to be inaccurate or imprecise, but that doesn't mean that the reverted edit wasn't made in good faith. The reversion might well be justified, but what was reverted wasn't necessarily vandalism. —— Shakescene (talk) 20:03, 3 September 2009 (UTC)

True, and I've seen the same issues myself. I simply don't see how that is a significant problem which this proposal needs to address. I see people "misuse" the minor edit flag constantly as well, but that's not a reason (to me, at least) to remove it.
— V = I * R (talk to Ω) 03:23, 4 September 2009 (UTC)

Quite. We mustn't throw out every suggestion for new functionality just because someone sometime might abuse or misuse it.--Kotniski (talk) 12:55, 4 September 2009 (UTC)

It might be a good idea to implement a "vandalism reversion" flag, akin to the "minor edit" flag. Then again, the risk of abuse (which would inevitably lead to bad faith assumptions and large disputes) is concerning... –Juliancolton | ^Talk 01:44, 5 September 2009 (UTC)

That's a very fine and interesting point. Maybe if there were a V flag, editors would stop lazily or carelessly using "RVV" as an-all-purpose abbreviation for "revert" and just hit the "vandalism" flag when it really seems to be vandalism. On the other hand, it's equally easy to see how a simple check-box might aggravate the problem. —— Shakescene (talk) 04:04, 7 September 2009 (UTC)

Rollback should theoretically trigger this also- it's supposed to be used solely to revert blatant vandalism (or other non-controversial tasks, like reverting your own edits to your own talkpage), since under normal circumstances you CAN'T add an edit summary. --King Öomie 19:44, 8 September 2009 (UTC)

Remove the sandbox functionality from the intro page

{{unanswered}}

I am talking about Wikipedia:Introduction, a page that welcomes our new users. The page has sandbox functionality, in other words, the users are free to make test edits there as long as the intro template stays untouched. Too bad it doesn't, and new editors may be greeted by something along the lines of "lol wikipedia is teh suxx0rz haxd" or "Get stuff online www.fakesite.com". This is mostly incompetence and misunderstanding the purpose of the page instead of actual vandalism, but to ensure that the page looks the way it's supposed to when a new user views it, I suggest we remove the sandbox functionality from this page altogether. Obviously, it's good to have a sandbox page for our newcomers, so I suggest editing our current sandbox template to point forward to Wikipedia:Introduction_2 (titled "Learn more about editing") so new editors wouldn't have to look for the next page of the introduction OR creating a new sandbox page between the first and the second introduction page. Any support, comments, suggestions? Kotiwalo (talk) 19:03, 19 August 2009 (UTC)

I would vehemently oppose such a change. It's really helpful, in my opinion, to be as encouraging and as forthwith as possible with readers and editors alike when they reach Wikipedia. If anything, the links to WP:Introduction should be more prominent on the Main Page. The more links someone has to follow, the less likely she or he is to actually follow them. Yeah there's vandalism there, but the vast majority of it is really just people flexing their wikimuscles and testing their boundaries. Besides, unlike most other areas, it's not really harming anyone greatly. Screwing with a sandbox makes it worse for the next guy, but it's not exactly libelous. ~ Amory (user • talk • contribs) 01:43, 20 August 2009 (UTC)

Yes, screwing with a sandbox wouldn't be a big deal, but it's also our introduction page, and since many new editors have wiped out the welcome template, either accidentally or intentionally, there is a good chance of our new editors being greeted by profanity or other not especially "welcoming" content. It wouldn't matter as much if there was a way to ensure that the welcoming template wouldn't be deleted, accidentally or in bad faith. Kotiwalo (talk) 09:53, 20 August 2009 (UTC)

Why not add something like the sandbox header, so that the page would get refreshed with the proper content every 12 hours? Warrior4321 22:00, 20 August 2009 (UTC)

There is one on the intro page I guess, but it would have to be cleaned after every single edit to ensure that the template stays intact, and that would take away the entire point of the sandbox. Separate page would be better. Kotiwalo (talk) 05:41, 21 August 2009 (UTC)

Is there anyway you can divide the page so one part(or section) can be semi-protected and the other part gets cleared every 12 hours? Warrior4321 17:47, 21 August 2009 (UTC)

I'm very sure that there's a way but I'm also rather sure that it won't be too quick an' easy. Kotiwalo (talk) 18:23, 21 August 2009 (UTC)

Perhaps creating a page with the introduction on another page (like the sandbox header), and then transcluding it into there? We can place a invisible comment right beside the transclude, telling them to leave it alone? That would provide new users who are not sure where to edit much more room. Warrior4321 19:22, 21 August 2009 (UTC)

Actually the intro page has the following:
{{Please leave this line alone}}
<!-- Feel free to change the text below this line. No profanity, please. -->
Sadly, this doesn't always work. Kotiwalo (talk) 08:11, 22 August 2009 (UTC)

(outdent)I have recently been watching the introduction page. No idea how that started, but I regularily check out the new user contributions and revert offensive or immature edits. It has begun to irk me that the message we use to greet newcomers is routinely vandalised into absolute nonsense. Wikipedia is not the place to read about ketchup farts, or at least a main page isn't.

I wish to propose that the page for editing WP:Introduction redirect to the page for editing WP:Sandbox. This way, new users can read the introduction, still click edit, and edit the sandbox instead of defacing the message that they just read. WP:Introduction could then be protected from editing. - ʄɭoʏɗiaɲ ^τ _¢ 14:01, 22 August 2009 (UTC)

I really like that idea! Any idea, how we could edit the edit button? Warrior4321 19:11, 22 August 2009 (UTC)

Why not make it work the way {{doc}} works on protected templates (via transclusion of the sandbox -- in this case -- onto the protected intro page). That way the message stays intact, and you can have a special edit link right there (though the "edit this page" tab won't work right, unfortunately). Maybe have Cluebot and/or its friends lightly patrol the sandbox for profanity to stop that. --Thinboy00 @117, i.e. 01:48, 29 August 2009 (UTC)

Relisting since this got ignored and archived and since its a very logical and easy to implement idea that could really improve what new users first impression is. - ʄɭoʏɗiaɲ ^τ _¢ 01:59, 7 September 2009 (UTC)

I don't see how transcluding the sandbox onto a protected page will help - as far as I can see users still won't be able to edit/save. We could use an edit notice and a cleaning bot; we could also revisit the idea that the Intro page needs to allow people to save; mightn't telling people to go to the Sandbox for further testing, be enough? Rd232 ^talk 08:20, 7 September 2009 (UTC)

As far as I can see the template documentation transcludes a link onto a protected page, which goes to a sandbox in edit mode. WP:Introduction already has such a link, so the only thing that would need doing is protecting it. That breaks the "edit this page" example function though. Is there any way to make the "edit this page" button edit a different page? Surely not. Is it worth filing a bug for a single page? Not sure. Rd232 ^talk 15:01, 7 September 2009 (UTC)

Thats why I proposed above that the page for editing WP:Introduction redirect to the page for editing WP:Sandbox. - ʄɭoʏɗiaɲ ^τ _¢ 16:48, 7 September 2009 (UTC)

I don't understand. On Wikipedia:Introduction people edit the page by clicking the Edit This Page button, not by clicking a link like this [7]. Rd232 ^talk 17:08, 7 September 2009 (UTC)

(Because the "Click here to edit the sandbox" link on that page already goes to WP:Sandbox.) Rd232 ^talk 17:09, 7 September 2009 (UTC)

Then so should the edit button at the top of the page. I really don't see why this suggestion isn't better received... It keeps the functionality, but ends the vandalism at the introduction. - ʄɭoʏɗiaɲ ^τ _¢ 17:25, 7 September 2009 (UTC)

So you do mean making the Edit This Page button do something other than Edit This Page? Unless you know something I don't, that's currently not possible. Rd232 ^talk 21:05, 7 September 2009 (UTC)

Yes... I'm sure the nifty programmers could come up with a simple code to make it work. - ʄɭoʏɗiaɲ ^τ _¢ 06:31, 8 September 2009 (UTC)

Mmm, fine with me if you want to file a bug. Can't imagine it being a priority for the overworked programmers though... Rd232 ^talk 10:09, 8 September 2009 (UTC)

Upgrade of the "Categories" system

“Categorization is a feature of Wikipedia's software, enabling pages to be placed in categories which can then be used by readers to find sets of articles on related topics. Categories can be defined as subcategories of other categories, allowing easy navigation between connected subject areas via a tree-like structure. This helps readers find articles on particular topics even if they don't know which articles exist or what they are called.”

However, the current system is not intuitive; it is hidden at the bottom of the page; it does not make the most of its navigational potential; category pages look unappealing.With the minimum change it should be possible to display the same information much more effectively. The following is suggested:

• The current information is displayed in a fixed size box
• The box could be accessed as a drop-down tool or as a permanent box on the right hand corner (or wherever).
• Lists of categories are the same as at present but are scrollable hence no need for huge boxes
• Lists are single-column and clickable
• There is the facility to go “up” in category levels as well as “down”
• Entries are sometimes quite long so the use of a small but clear font would assist – there are small black fonts that would do the job

I would be pleased to discuss further with any programmers willing to give it a try. There are probably many other category-based improvements that could be achieved at the same time: a tool to edit and manage categories for example.Granitethighs (talk) 10:32, 7 September 2009 (UTC)

Feature request: The ability to view a category as "flattened"; that is, see all pages in the category and its subcategories, recursively, on one logical page. --Cybercobra (talk) 11:34, 7 September 2009 (UTC)

"a tool to edit and manage categories" Are you aware of WP:HotCat? --Cybercobra (talk) 11:34, 7 September 2009 (UTC)

Not entirely sure what this proposal would look like, but certainly categories are not currently doing their job very well, and it's mainly a problem that requires developer assistance (though various requests for improvements at Bugzilla have brought little effect). In fact I'd like to see categories dumped in favour of a far more natural and powerful system - some syntax for stating characteristics of article subjects ( {profession=singer;sex=male;birthdate=...;nationality=...}, that sort of thing), then users could search based on exactly what characteristics they chose, without editors constantly having to make judgments about what levels of categorization are going to be a help or a hindrance.--Kotniski (talk) 11:47, 7 September 2009 (UTC)

The proposals at Wikipedia:Category intersection and Wikipedia:Link intersection may be of interest. ---— Gadget850 (Ed) ^talk 12:53, 7 September 2009 (UTC)

To that, I'll add Semantic MediaWiki and Dynamic Pagelist. Both are fairly intensive extensions, though SMW seems a popular one to be added in the near future. --Izno (talk) 14:23, 8 September 2009 (UTC)

I find Categories rather confusing. They seem to a casual user as performing the same function as (A) the lists of ... in small type at the foot of pages and (B) the "List of ..." articles. In fact what is the functional advantage over a "List of" article?

Also category pages are confusing when (as very often happens) "There is one sub-category" which appears at the top and 134 regular entries underneath. As said above, the pages are more unattractive and do not seem to adopt the "house style" of a Wikipedia page.Sussexonian (talk) 21:40, 7 September 2009 (UTC) In answer to the question of what is the advantage of a category over list, the answer can be summarized in one word - hierarchy. If you click on a category, and then go the bottom of that category, you will see that often the category is itself a member of a more superordinate category. I personally rather like the category system in Wikipedia - as do many other Wikipedians, as is evidenced by the Association of Categorist Wikipedians. After all, if one wishes to learn about the Linneaan division of the world, this could be an extremely useful tool. One might find that a gibbon is a primate, which in turn is in mammal, which in turn is a vertebrate, which in turn is a chordate and so on and so forth. ACEOREVIVED (talk) 22:55, 7 September 2009 (UTC)

specifying foreground color when changing background color.

when people create tables and mboxes and such things and they change the background color why do they automatically assume that the foreground color is going to be black? I use white forground and, while it works well enough for most of the pages that I actually use, a few pages (including some important ones) are nearly unreadable. when people change the background color they should also specify exactly what foreground color to use as well. would it be reasonable to ask that this be made into a policy? Lemmiwinks2 (talk) 00:15, 8 September 2009 (UTC)

Do you have a specific example? Most boxes and the like have associated CSS that set defaults. ---— Gadget850 (Ed) ^talk 01:37, 8 September 2009 (UTC)

Virtually all that I have seen. But if you want specific examples then:

{{portal|Bible}} {{Biblical longevity}}

plus the barnstar on my user talk page (before I changed it)

the mbox on my user css page.

virtually the entire 'my preferences' page.

I'll try to find more. Lemmiwinks2 (talk) 23:31, 8 September 2009 (UTC)

Something's obviously wrong with your configuration somewhere, then. If what your describing were common people would be screaming and tearing the place apart... are you using any customized CSS/js? what skin are you using?
— V = I * R (talk to Ω) 00:16, 9 September 2009 (UTC)

As Lemmiwinks2 stated clearly, he is using white text. Algebraist 00:18, 9 September 2009 (UTC)

Ah, I just re-read his first post and I see that now. All I can say is, if you do non-standard things you've got to expect that it will create some issues. I don't want to sound rude but, why should you're personal style choices be the basis for all of the rest of us being required to do makework? You should be able to, and in fact can (as demonstrated by this thread) do what you like for yourself, but expecting the rest of us to conform to the choices of individual customizations seems... egocentric? But, what do I know. If someone want to go around and add foreground color values to style tags, I seriously doubt that anyone would stop them.
— V = I * R (talk to Ω) 00:44, 9 September 2009 (UTC)

I'm not even going to try figuring out all the rules you have in User:Lemmiwinks2/monobook.css and User:Lemmiwinks2/vector.css, but there appears to be a bunch related to boxes. Try clearing out whichever you are using and purging. If that fixes it, then add stuff back in a bit at a time. Nor do I know why you have boxes on your user and talk pages with that blue background. ---— Gadget850 (Ed) ^talk 00:26, 9 September 2009 (UTC)

As I said in the discussion below on the proposal to introduce orange and green wikilinks, we must be careful not to confuse people with colour blindness (black and white text should not do this).

Coloring Wikipedia text is a BAD idea

I read this article a couple of minutes ago:

http://www.wired.com/wiredscience/2009/08/wikitrust/

Please, please don't implement this. Not only would this make reading articles difficult with this turned on, but I can only see this causing a lot of issues with 'truthiness'. Editors with get into discussions and, rather than coming to a consensus, they will simply let the edit color speak for itself.

I understand Wikimedia Foundation's interest in making Wikipedia seem more accurate to the eye of the general and scientific communities, (Despite Wikipedia already being the most expansive and accurate general source in existence. ) but rainbow coloring pages doesn't seem like the way to do this. It's distracting, may actual reduce accuracy, and makes the page seem disjointed. Instead, let's extend the extension which shows page rankings under the page title and color codes page titles respectively to where it's used by default, as well as a link to a 'research safe' version of the article. (A recent history of the page with an equal or greater ranking.)

This method would not only ensure accuracy, but would also provide a standard, static-style encyclopedia which could be used reliably in a professional or academic context. 8bit (talk) 05:41, 1 September 2009 (UTC)

What's actually occurring is covered at Wikitrust. It appears to be a Gadget, not anything forced on every user by the base software.
— V = I * R (talk to Ω) 05:48, 1 September 2009 (UTC)

Even as a gadget, I'm still kind of against it, as it seems like something which would lead to truthiness, but either way, what of my alternate proposal as a default setup? Here's an image of approximately what I'm picturing:

8bit (talk) 06:04, 1 September 2009 (UTC)

I do wish we'd show regular readers our assessments. It's a valuable piece of info when trying to figure out how much to trust an article. - Peregrine Fisher (talk) (contribs) 06:09, 1 September 2009 (UTC)

@Peregrine Fisher: See s:Wikisource:Text quality. A system like this might work here, but on the other hand, I think we should strive to keep readership and editorial stuff separate whenever possible. Meh, just a thought... –Juliancolton | ^Talk 01:50, 5 September 2009 (UTC)

There's been a relatively extensive discussion on the wikien-l mailing list, feel free to read it as well if you like. This thing is gonna take a while to get here, if at all, and it's not going to be exactly as the sensationalist article writer makes it sound. The main aspect is how extensive a section of text has been edited, and the ability to link to the diff where it was added, something that is really cool. ~ Amory (user • talk • contribs) 12:31, 1 September 2009 (UTC)

Thanks, Amory. In this case, this does sound pretty cool as an editing tool, so long as it doesn't, say, give older users or users with more edits higher color priority or something, as that article seemed to imply. 8bit (talk) 18:09, 1 September 2009 (UTC)

8-bit, the colors don't appear by default and are accessible in a tab for those who want to use the tool (try with [8]). I think it's an innovative idea, but I'd like to see a demo on this Wikipedia. Eklipse (talk) 20:16, 1 September 2009 (UTC)

The one problem I see is that some good editors could acquire an "unstable" rating merely by getting involved in edit wars over style, or because they're commendably trying to clean up and neutralize an oft-vandalized page like Barack Obama or Sarah Palin, while mediocre editors can appear sounder than they are merely by the accident of doing most of their work on poor but uncontroversial pages where style and format don't come up as issues. —— Shakescene (talk) 20:43, 1 September 2009 (UTC)

I could swear I remember this idea being suggested years ago by some random user...He should sue! :) ----occono (talk) 00:31, 4 September 2009 (UTC)

Shakescene, I seem to remember hearing that the researchers managed to compensate for that sort of thing, by giving people back reputation rating when other editors reverted to their version of an article. I'm sure that the top-rated editors will still be "quiet" ones who make plenty of uncontroversial changes, but that's par for the course with an automatic assessment. {{Nihiltres|talk|edits}} 01:35, 8 September 2009 (UTC)

In short, if the nationalists are quiet enough that nobody reverts the next FYROM, they will become trusted editors, and their POV will become trustworthy. God preserve this, and keep it far from us! Septentrionalis PMAnderson 15:47, 9 September 2009 (UTC)

Yeah, I was looking at where it was implemented, and, I'm not sure how well that would work. Shouldn't trust be based on weather or not it is cited, not how trusted that contributor is?--Unionhawk ^{Talk E-mail Review} 16:01, 9 September 2009 (UTC)

• This probably takes no account for copy editting does it? Which means it will treat a copy edit of an article in the same way it would a fact correction. Having someone copy edit over my work, or copy editting over my own work, would in effect be lowering my "quality rating". Seems to me this might discourage copy editting.. —Charles Edward ^{(Talk | Contribs)} 18:55, 9 September 2009 (UTC)

Alternate proposal

Instead, let's take FA off the main page; the others can stay, they cause less harm. This would immediately reduce the amount of nationalist POV-pushing, where each national gang tries to get their national glory on the main page, like Samuel of Bulgaria - which was written out of the nationalist schoolbook of Bulgaria, vintage 1912. The source, and the article, give Samuel and his allies all the positive adjectives; his enemies, including his brother, get the negative ones. Fortunately Karanacs noticed this and declined the star, but that doesn't happen anywhere near often enough.

The useful aspects of FA and GA would continue; there would continue to be stars for ego-boo, and reviewers would continue to look at articles. About one time in three, as now, review would improve an article; actual harm would be rare, as now. Septentrionalis PMAnderson 16:10, 8 September 2009 (UTC)

I doubt POV pushers are coming directly from the Main Page; they're likely looking up the articles that interest them, same as any other editor (vandal or otherwise). EVula // talk // ☯ // 16:14, 8 September 2009 (UTC)

But the more sophisticated ones are writing articles that suit them, as here; I'm talking about the FA nominator and his friends. Septentrionalis PMAnderson 16:33, 8 September 2009 (UTC)

Then what's the point of taking FA off the main page? EVula // talk // ☯ // 20:05, 8 September 2009 (UTC)

I've said it often enough; if anything's to be taken off the main page, it should be DYK and ITN. These highlight what Wikipedia does worst; newly created unfinished stubs, and articles on rapidly changing topics prone to editwars. At least FAC means someone looks at the article (and Sandy, Raul and Karanacs are generally fairly good at spotting blatant puffery). – iridescent 20:38, 8 September 2009 (UTC)

But it's good to have those on the main page, so people go to them and improve them. I've found many a page to work on via ITN and DYK. OrangeDog (talk • edits) 02:39, 10 September 2009 (UTC)

Link color proposals

Invitation to edit: Orange links

Archived

Note: This is a proposal I created on the Strategic Planning wiki. Since it is primarily relevant to the English Wikipedia I decided to post it here to get some feedback. GeometryGirl (talk) 21:08, 6 September 2009 (UTC) Observations and background Wikipedia currently has two types of links: blue links (for existing articles) and red links (for nonexistent articles). The major benefits of blue links are navigational. As for red links, it has been shown that they stimulate article production. Indeed, Wikipedians want to "turn all links blue" and this has been, and still is, a major bolster to article production, especially for small Wikipedias. For larger Wikipedias, the focus is changing from article production to article amelioration, and the disappearing red links are losing their former impact. Details of proposal Description As an addition to the positive red links, orange links (or links of some other descriptive colour) could attest for articles in poor shape. For example, all stubs and start class articles could be linked to by orange links. Various implementations are possible, from offering orange links to every user by default, to limiting them to signed-in users. Potential benefits The potential benefits are similar to red links in prompting users to produce content. Orange links would encourage editors to expand and improve articles, as a support to the already existing red links that encourage editors to start articles. In effect, similarly to red links, orange links would drive editors to where work is needed. Extensions The idea can be extended to different classes of articles. For example, we could have all featured and good articles be linked to by green links. This may incite viewers to read articles they would not have otherwise read, so as to drive users to quality content. Choice of colours The similarity between the orange and red colours is significant since stubs and start class articles are almost nonexistent, containing barely any information. As for the green colour for good and featured articles, it would reflect upon the green logo already used for good articles. A careful choice of colour should be made to minimize potential confusion for colour blind people. References Erik Moeller's talk from the 2009 Wikimania in Buenos Aires. Specifically, slide 6 of his presentation Problem recognition: in the past there were red links, and slide 20, step 2 Solution: create new micro-opportunities. Diomidis Spinellis and Panagiotis Louridas (2008). The collaborative organization of knowledge. In Communications of the ACM, August 2008, Vol 51, No 8, Pages 68 - 73. They noted that "Most new articles are created shortly after a corresponding reference to them is entered into the system." Discussion (orange links) This is an interesting and ingenious suggestion, and you have obviously thought out this proposal well.However, I am not too sure it would work. Many Wikipedians might prefer the simple task of having any article, no matter how small, linked by a blue link and red links for articles that are not in Wikipedia - to implement this change would mean much editing to Wikipedia. Perhaps it would be easier to reserve orange articles for those articles where, if you type a word in the box on the left, you get redirected elsewhere, i.e. where there is not an article with verbatim that name in Wikipedia, but there is an article on a similar topic. If we had the orange article as a marker of quality of an article, it could lead to edit wars on whether articles should be linked by red or orange links. ACEOREVIVED (talk) 23:45, 6 September 2009 (UTC) Thank you for the reply. Why do you say that "to implement this change would mean much editing to Wikipedia"? Isn't that the goal? GeometryGirl (talk) 23:56, 6 September 2009 (UTC) I would guess that this would require some modification of the underlying MediaWiki software. --Cybercobra (talk) 00:18, 7 September 2009 (UTC) That seems pretty clear. Hopefully it's not too horrendous a job. Anyway, I don't think we should worry about this as yet per WP:Performance. GeometryGirl (talk) 00:54, 7 September 2009 (UTC) I like the idea, but you can't sweep under the carpet how the colours will be determined in practice: it's the key issue. How will the software decide whether to show the link as red, orange, blue, green? Rd232 talk 01:51, 7 September 2009 (UTC) The software would use categories to determine the colour: red for nonexistent articles (as usual) orange for Category:Stub-Class articles and Category:Start-Class articles green for Category:GA-Class articles and Category:FA-Class articles blue for the rest (C class, B class, A class, etc.) That seems awfully arbitrary. Why should C-class articles be treated the same as B-class? And A-class is supposedly higher than GA-class, why is it treated worse? Why should articles that went through a rigorous FAC be treated the same as articles that were marked as "good" by a single person? What about articles that are in multiple classes? Some projects don't use C or A-class. Some projects have strict standards for what classes to use, others (most, really) are just an arbitrary rating. Mr.Z-man 17:35, 7 September 2009 (UTC) Are you aware of the existing functionality to show articles of less than a given size as a differently-coloured link? It can be triggered by changing "Threshold for stub link formatting (bytes)" to a non-zero value in the Appearances tab of Special:Preferences.-gadfium 02:18, 7 September 2009 (UTC) If you go into your User Preferences, click the Advanced tab, and scroll to the bottom, there is an option for stub linking. You enter a threshold number of bytes, and any links to articles smaller than that size will show up poo coloured. I personally changed mine to orange because the poo colour resembles clicked-upon blue links. You can do this by editing your theme's CSS file (In most cases, this would be monobook.css) and adding the following text: a.stub:link {color: #ff6600;} a.stub:active {color: #ff6600;} a.stub:visited {color: #ff6600;} a.stub:hover {color: #ff6600; font-weight: bold;} You may need to fiddle with it to make it suit your needs, but this does the trick. You can also change the third line to a.stub:visited {color: #cc5500;} to make visited links a deeper orange - ʄɭoʏɗiaɲ τ ¢ 02:33, 7 September 2009 (UTC) That is a great functionality I was not aware of. However, what I propose is more subtle: it is not based on size but on quality. GeometryGirl (talk) 12:00, 7 September 2009 (UTC) the problem here is that you're trying to mix up two different systems. MediaWiki is the software that runs Wikipedia, and it is used for much more then just Wikipedia (Wikinews, WikiBooks, all fo the Wikia sites, etc...). The quality rating categories are something that we specifically do here on Wikipedia, and not every article even has a quality rating (although, by this point, it is awfully ubiquitous). So... implementing this sort of suggesting in software would be next to impossible, and even if is was specially made as a plugin/extension for Wikipedia it's application woudl be (very) uneven and prone to gaming. All anyone would have to do in order to change the link color that everyone (who is using the gadget/skin) sees is to go to the talk page and switch the Class in a wikiproject template (or simply add a cat). Worse, categorization is not mutually exclusive, so it's not only possible but probable for an article to either have both Category:Stub-Class articles and Category:GA-Class articles at the same time, or none of the X-Class categories, which leads to the obvious question of what the software should set the link class to in that case. It's not a bad suggestion at all, it's just... impractical. Sorry. — V = I * R (talk to Ω) 13:37, 7 September 2009 (UTC) Thank you for your comment User:Ohms law. First of all, this proposal is only intended for Wikipedia. Second, what is the problem in "mixing up" categories with MediaWiki? Isn't that one of the purposes of MediaWiki, to serve Wikipedia? I don't understand your concern, are we not in an age where software has become flexible? Also, why is "All anyone would have to do in order to change the link color that everyone (who is using the gadget/skin) sees is to go to the talk page and switch the Class in a wikiproject template" a big concern? Wikipedia is prone to vandalism, true, but Wikipedia has dealt pretty well with vandalism in the past. And what do you mean by "it's application would be (very) uneven"? As for articles with conflicting categories, these are "anomalies" which should not occur, and we can easily code robots to deal with the problem. As for articles without any quality assessment, it is a good incentive to have them assessed! GeometryGirl (talk) 14:05, 7 September 2009 (UTC) I actually agree with the view towards vandalism, but that's the sort of thing that always seems to be said in these proposals so... I guess that I felt obligated to do so as well. The underlying reliance on the category system is extremely problematic, though. There's simply no means to control category use, and there shouldn't be, which makes attempting to bolt external extensions to it generally a bad idea. Categories are a search assistance first and foremost, and proposals which distract from that focus are likely to meet considerable resistance. If you really look around, you'll notice that articles with conflicting (Class) Categories, or none at all, is far from a rarity. That articles can have different assessments for different projects is actually a feature of the current assessment system as well, and I don't think that should be discouraged. The more heavily trafficked articles have largely been assessed but certinaly not all of them have, and there are numerous lightly trafficked articles (which are largely the target of this proposal, it seems) that are not assessed at all. I don't want to be all negative though, since I do sort of like the idea behind this... I think that the current assessment system using the Category system is a slight problem as well. The best bet would probably be to completely decouple this proposal from the Category system, which would mean the addition of a separate special assessment field for all articles. I'm not sure how that would play with many Wikipedians (I could imagine that some Wikiproject groups would not be happy with it), but it's probably worth floating the idea around just to find out. The link color issue itself should be shelved for now though, in order to keep the focus on the "global assessment property" proposal. A case could certainly be made to add on functionality for assessments outside of the Category system, since assessments are clearly supported by the community, and are only using the category system because there's nothing better to use. — V = I * R (talk to Ω) 15:13, 7 September 2009 (UTC) I disagree with you when you say that "There's simply no means to control category use". Take for example featured articles and good articles. These categories are extremely well controlled, and no article can suddenly claim featured status without passing through FAC. I am also surprised when you say "Categories are a search assistance first and foremost". Can't the function of categories evolve over time? Anyway, I don't really care (for now) about the specific way this link colouring feature would be implemented, I mainly want to know if Wikipedians think it is a good idea. If they think it is a good idea then this will certainly bolster some brainstorming as to how exactly we will implement this. This brings me to my last point, that I disagree the "color issue itself should be shelved for now" since the colour issue justifies thinking (or rethinking) categories. GeometryGirl (talk) 15:27, 7 September 2009 (UTC) More accurately, the GA and FA categories are simply well watched. Anyone can place any article in the GA or FA class categories (or even both), it's just that with the number of people involved in those two assessment classifications the article is unlikely to stay there. Simply removing articles from such classes is equally easy as well, but those articles are trafficked enough that such removals are also reverted fairly quickly. The use of categories can certainly evolve though, it's just that the underlying functionality really shouldn't. There's simply no need for the functionality itslef to do so, really. Using Categories informally for tasks such as classification is one thing, but formalizing such relationships in software is an entirely different issue, and should generally always been avoided. If the proposal is good enough to implement in software, adding a new system specifically for the purpose is a much preferred design pattern to follow for many reasons (ease of implementation, encapsulation, maintainability, etc...). Color itself isn't actually the central issue here either, by the way. That is the way that you're expressing your desire, but what you're asking for is the addition of a couple anchor CSS classes. Different skins actually handle the coloring in their own fashion, and individual users can custumize link coloring for themselves (I currently do. all "redlinks" are green, to me). That's the primary reason that I recommend shelving the color aspect for now, since it's really a (technical) secondary aspect to this. Determining how to consistently decide what class an anchor to an article should use is the primary issue, and adding a new field/property to articles is the means to achieve that. — V = I * R (talk to Ω) 15:49, 7 September 2009 (UTC) Excellent proposal. Now I've got to highlight these pale links just to read them. Thank you, dear Academy, another cool use for my mouse. NVO (talk) 16:25, 7 September 2009 (UTC) KISS. Five different colors for links (regular blue link, regular red link, the two proposed additions, and the lighter blue interwiki link)? That's confusing for the average editor; our readers shouldn't need a cheat-sheet just to use the website. For those that are interested (before clicking the link) about what the page's quality is, isn't this what we have pop-ups for? It should be an opt-in feature (ie: a gadget), not default behavior. EVula // talk // ☯ // 16:34, 7 September 2009 (UTC) Agreed. I seem to recall somewhere there was an informal poll or survey at one time that asked if readers actually knew what the FA-star in the tops of FAs actually meant, and the majority of non-editors didn't. While improving content is a great goal, it shouldn't be done at the expense of making the site more confusing and harder to use for readers. Mr.Z-man 17:35, 7 September 2009 (UTC) What about the more Wikipedia-knowledgeable logged-in users? Anyway, wouldn't the benefits outweigh the possible confusion? Also, keep in mind that redlinks are now (very rare), and FA and GA articles are also pretty rare. So most links would be blue or orange. GeometryGirl (talk) 17:47, 7 September 2009 (UTC) You can set up a colour-coding system (though it doesn't run by default, for performance reasons) using this rather neat script. Shimgray | talk | 17:54, 7 September 2009 (UTC) Shimgray, I use the same script for quite some time now, and it is (according to me), one of the best scripts on Wikipedia. It provides the reader with the quality and importance of the article, right from the article, rather than having to go to the talk page. Concerning, the proposal, I don't see how the orange links can help. While showing the readers which articles are high quality articles which are FA and GA, it will not do anything but create a new "rule" that only article with a green wikilink are "good" and should be clicked on. Warrior4321 02:34, 9 September 2009 (UTC) These two criticism's directly hit at the reasons why I was suggesting adjusting the proposal, above. I think that there is a good core to this proposal, it's just the implementation details that are slightly askew. — V = I * R (talk to Ω) 18:12, 7 September 2009 (UTC) @GeometryGirl: What about them? They make up a rather small minority of total users. If people are confused by it, then we don't get the full benefits. My reference to the FA-star was not about FAs, it was about how we put things in articles like that without actually considering whether or not readers know what its for. With redlinks its rather obvious. But since everything from Start to B (even including GA to some extent) is typically an arbitrary rating chosen after only a cursory review, it will not be very obvious what the difference is. By adding more colors into the text, pages also get harder to read. Mr.Z-man 19:05, 7 September 2009 (UTC) Sorry, what I meant was: What about implementing this ONLY for logged-in users. Anyway, I have started a more modest/mature/first-step proposal below. GeometryGirl (talk) 14:11, 8 September 2009 (UTC) I use User:Anomie/linkclassifier.js, which provides similar functionality. You can also use the CSS line #bodyContent a.external { color: #008000 } if you, like me, find it hard to tell the difference between the colours of internal and external links (it turns them green). Dendodge T\C 16:02, 8 September 2009 (UTC) GeometryGirl invited me to comment here - I think that finding intuitive ways to highlight articles that need attention is a good idea. I do want to note that red links being somewhat annoying is probably a significant part of the reason they work - there's something particularly satisfactory about seeing an article with lots of red links "turn blue". That said, I do share the concern about making the reader experience potentially significantly more confusing. How about an implementation that adds a simple summary in an appropriate location, such as "22 articles linked from this one could use your help (expand)", which would then list the articles and the specific problems when expanded?--Eloquence* 02:08, 9 September 2009 (UTC)

Invitation to read: green wikilinks

Dismissed

Wikipedia currently only has two types of links: the blue links for existing articles, and the red links for nonexistent articles. I propose to add a system of green links whereby any wikilink to a good or featured article would be coloured green. Q&A (and summary of discussion) Q: Why implement this? A1: Green links would invite users to read quality articles, relevant to the article they are currently reading, that they might not have otherwise read. A2: Green links would complement "Today's featured article" in showcasing article for which the quality has been vetted by Wikipedia. A3: Green links might motivate editors to "turn all links green". Q: How would this be implemented? A1: Using the well watched and controlled categories Category:GA-Class articles and Category:FA-Class articles, and the help of a script similar to this rather neat one, or this one. A2: Some other ingenious way! Q: For who would this be implemented? A: Green links would be implemented by default for all readers. Q: What are the drawbacks? A1: This proposal assumes that FA and GA represent our best work. (Comment from Septentrionalis and iridescent, see below.) Reply: Green links don't claim to link to "the best" articles, just articles who's quality has been vetted by the Wikipedia community. A2: Some colourblind may not distinguish green/red or green/blue. A3: There are potential performance problems. Reply: Per WP:PERFORMANCE, users should not worry about performance. A4: People might not understand the purpose of green links after clicking one. (Comment from EVula, see below.) A5: Quality articles are not necessarily articles that people want to read. (Comment from Kotniski, see below.) Reply: Green links are only a suggestion for a read, similarly to "Today's featured article". Also, links in an article are relevant to the article being read, and hence relevant to the reader interested in the article in the first place. A6: This add complexity to the linking system, and may cause confusion. (Comment from EVula) Reply: True, but only very few links would be green, since very few articles are good or featured. Q: Why green? A1: Because of the connection with the green GA logo . A2: Because green is very distinct from the existing blue and red. (Except for certain colourblind, see above.) Q: Why does this proposal exist in the first place? It does not solve any problem! (Comment from EVula.) A: The goal of this proposal is not to solve a problem, but to improve the current wikilinking system for collateral benefits. Discussion (green links) Please discuss here. In good wikispirit, I am leaving this proposal "open". Feel free to edit it! GeometryGirl (talk) 14:05, 8 September 2009 (UTC) This assumes that FA and GA are better than other articles. This is true only to the extent that, having received attention, they are less likely to be grossly incompetent or stubs. (Unfortunately, gross incompetence and bias are possible; for examples, see the appallingly sourced Daniel Webster, the appallingly written Names of the Greeks (now removed after four years), and the tendentious Kingdom of Mysore.) FA and GA are sometimes useful processes, but their utility consists of examining articles (often competently and thoroughly, sometimes not) and of being an array of incentives to write decent articles. They evaluate articles very badly, being prone to PoV log-rolling and sheerly irrelevant comments (such as Wikipedia:Featured_article_candidates/Battle_of_Red_Cliffs, which was primarily some editor's snit about Harvard referencing - but none of the comments, including my own, were significant.) In short, I very strongly oppose this, until FA and GA acquire a better population of reviewers, which I expect shortly after publication. My only edit would be to insert the word never as often as necessary. Septentrionalis PMAnderson 14:49, 8 September 2009 (UTC) Wow, that's a pretty interesting and extreme point of view. Sure, Wikipedia is not perfect, and nor are FA or GA (or the underlying processes). But remember, perfection is not the goal. And let's face it, FA and GA are better than other articles, at least on average, and by a large margin! Please do not take it personally, but I think your elitism might obstruct Wikipedia from moving on. What I mean is that we cannot wait for perfection to be attained before showcasing work. GeometryGirl (talk) 15:19, 8 September 2009 (UTC) We can wait until the processes become more than the prejudices of the ignorant and the incompetent, however. FA and GA are failures - at evaluation; they always have been, and may be expected to continue to be indefinitely. They do far too much showcasing of our worst work as it is; and cause far too much strife in the process. As long as it is very hard to evaluate content, hard to correct the writing of English, and easy to apply the semi-literate prescriptions of the Manual of Style, FAs and GAs will have lots of useless footnotes, a decorative spattering of dashes, and will be - on average - only slightly better than the run of articles - and sometimes much worse. (This of course assumes an equal amount of attention; the mere fact that a dozen editors have looked at an article - and one has presumed to nominate it - means it is better than a stub - usually.) Septentrionalis PMAnderson 15:42, 8 September 2009 (UTC) Far too often, those who cannot write articles review them, and the reviews are exertions of power by those who do not understand the article, the subject, or the English language. I will not give any examples of the worst, because it would be unfair; instead, I will give an example where one reviewer tied up an article for days - on a point where he was, to his credit, eventually convinced he was wrong. Now consider the number of reviews made by less competent reviewers who decline to admit that they were wrong. FA and GA are themselves impediments to improving Wikipedia; the only way through is to ignore them, and above all, not honor these failures. Septentrionalis PMAnderson 15:50, 8 September 2009 (UTC) Well I would be interested to see if a majority of Wikipedians think like you, Septentrionalis. I have not seen many folks like you in the past. GeometryGirl (talk) 16:00, 8 September 2009 (UTC) Oh, we're not hard to find. Look for experienced editors no longer involved in FA or GA, and mention the subject. Many have not enough experience to find, as I do, that the problem is endemic, but that's a difference of degree. Septentrionalis PMAnderson 16:10, 8 September 2009 (UTC) Still not a fan of the change. We've got two colors for links (red and blue), with another derivative color (light blue), all of which is rather easy to determine rather quickly. Someone can click a green link and not see what the difference is once they've arrived at that page (as opposed to a redlink, where they are prompted to create the article, or a blue link, which is an article, or a light blue link, which is an interwiki link). Make it a gadget, that'd be fine, but implementing it as an actual standard feature of the wiki, no. EVula // talk // ☯ // 15:59, 8 September 2009 (UTC) "Someone can click a green link and not see what the difference is once they've arrived at that page (as opposed to a redlink, where they are prompted to create the article, or a blue link, which is an article, or a light blue link, which is an interwiki link)." Interesting point. Did you think you could find some solution to this problem? GeometryGirl (talk) 16:17, 8 September 2009 (UTC) That's the thing right there: I don't think there's a problem that this proposal is trying to resolve. Are people not clicking on links that they'd otherwise be interested in because they're afraid of the linked article's quality? Doubtful. EVula // talk // ☯ // 16:35, 8 September 2009 (UTC) This goal of this proposal is not to "solve a problem", just to "make things better"! "Are people not clicking on links that they'd otherwise be interested in because they're afraid of the linked article's quality?" I'm also doubtful. But that's not the point! The point is to make people read relevant quality articles that they would not have even thought of reading. GeometryGirl (talk) 16:43, 8 September 2009 (UTC) Look, I'm not trying to be a wet blanket, but I'm just not seeing any benefit to this. We don't need to fill our articles with a slew of different colors, especially for the relatively unimportant purpose of drawing people's attention to links that they probably don't care about. It's already possible to over-link and make an article illegible with a mass of blue links; making everything blue or green isn't an improvement. We shouldn't try to "make" anyone read anything; if they're interested, they'll click the link. EVula // talk // ☯ // 20:03, 8 September 2009 (UTC) Why should we want to make readers read particular articles that they're not really interested in? Aren't the FA and GA processes and categories themselves (and the "Featured content" link on every single page) enough by way of showing off?--Kotniski (talk) 16:15, 8 September 2009 (UTC) This feature is not "article forcing", it is a milder "article suggestion" :) similar to "Today's featured article". GeometryGirl (talk) 16:20, 8 September 2009 (UTC) OK, so if I had an extra colour of link to play with, to suggest particular articles to readers, I would base it not on alleged quality, but on alleged close relevance to the subject of the present article. For example, the colour could indicate an article that links back to the current one (implying a close degree of relevance). --Kotniski (talk) 16:28, 8 September 2009 (UTC) That's an interesting suggestion! You should maybe make a proposal... Going back to your previous comment, links in an article are relevant to the article being read, and hence relevant to the reader interested in the article in the first place. GeometryGirl (talk) 16:31, 8 September 2009 (UTC) Agree entirely with Pmanderson. You're presupposing that GA/FA are our best articles; in reality, most of what the GA/FA processes measure is compliance to arbitrary guidelines which have little relevance to actual usefulness. Aside from conforming to the MOS, what makes A215 road or A Ghost Is Born better articles than Winter Palace? – iridescent 16:55, 8 September 2009 (UTC) Actually I am just presupposing that these articles follow the relevant criteria, which are Wikipedia's quality criteria. Isn't it the purpose (although this purpose may not have been attained) of the current quality assessments, to discriminate quality articles? And, as you point out, quality is subjective. But that's the nature of quality, and we have to deal with it. Anyway, you have taken the example of A215 road. To (maybe) reassure you, this link will appear in only very specific articles (I don't know, road articles...) and I'm sure the reader would be happy to know that if he clicks that link he will find a road article that follows MOS and other FA criteria, i.e. what Wikipedia considers to be a quality article. GeometryGirl (talk) 17:04, 8 September 2009 (UTC) To put it another way, green links don't claim to link to "the best" articles, just "quality articles (according to Wikipedia)". GeometryGirl (talk) 17:11, 8 September 2009 (UTC) Wholly opposed to the idea, per Pmanderson. FA/GA, the GA in particular, are far too overrated as it is; there is little community oversight in the process. There is no need to "advertise" these articles any more than they already are. Shereth 17:14, 8 September 2009 (UTC) What if the proposal was limited to FA? Would you be happier? GeometryGirl (talk) 17:16, 8 September 2009 (UTC) If, by "happier", you mean "less stridently opposed", then I suppose I would be. I still see no value in green-linking FAs. It has been my experience that the featured article process is a misguided attempt to demonstrate an article is "good" in that it can abide by the vagaries of the Manual of Style, and has very little to do with the quality of the information in the article itself. Again, I see no reason to promote the process as it stands by making links to these articles more visible. Shereth 17:20, 8 September 2009 (UTC) Sorry, I don't agree at all, and you seem to be missing the point; Shereth has it spot-on. FA and GA aren't "Wikipedia's best articles", they're "Wikipedia articles, which conform to the Manual of Style, have appropriate alt-text on the images, and whose primary contributor has decided to submit them to the timesinks of GAN/FAC". Plenty of our most prolific writers don't submit anything to the assessment processes (Giano is one who springs to mind); many, probably most, of our best articles will never qualify for GA/FA without major rewrites due to MOS issues, or a primary contributor who's either left the project or isn't interested in FAC. Plus, most obviously, Wikipedia has 10,000 active editors but 10 million readers, and those readers who aren't editors will have no clue what GA/FA represent and will likely take them as some kind of endorsement. (Imagine the furore when Gropecunt Lane was on the main page, multiplied almost infinitely as users find themselves directed towards 1987 (What the Fuck Is Going On?), Super Columbine Massacre RPG!, Fuck the Millennium, 1993 child sexual abuse accusations against Michael Jackson, The Year of the Sex Olympics...) Sorry, but I really do think this is an unsatisfactory solution, to a non-existent problem, that will only confuse our users. By all means make it a gadget, but something this arbitrary should never be a part of the standard software. – iridescent 17:23, 8 September 2009 (UTC) I think I got your point Iridescent. Thanks. But something bothers me. There are many opponents to the FA process! Why does the FA process still exists? Why haven't the plentiful opponents removed time/energy sink from Wikipedia? GeometryGirl (talk) 17:30, 8 September 2009 (UTC) Because we have no interest in tilting at windmills; the process of trying to get rid of it would be a time/energy sink in and of itself, and there are better things to be concerned with. If people want to while away their hours amassing rows of gold stars to display on their user pages, then I say more power to them - but I will oppose efforts to further glorify the process. Shereth 17:32, 8 September 2009 (UTC) And it will be tilting at windmills: FA, especially, does have some utility - just not as an evaluation mechanism; those who point this out will be supported by all those who are pleased by the present system. Editors like GA because getting stars for articles without having to go to the effort of writing good ones can be pleasant; on the other hand, every Language Reformer at Wikipedia will swarm, first to get their pet fix written into the Mass of Stupidity, and then to enforce it at GA and FA. Septentrionalis PMAnderson 18:35, 8 September 2009 (UTC) (ec) There are 10,000 active editors. How many names do you see at WP:FAC? And I speak as someone who does still participate there; I doubt that even the most ardent supporters of the FA/GA processes would dispute that the current process-creep and "oppose, article fails to comply with MOS subsection 43.4.3(m)" crowd are driving people away (just read this thread...). – iridescent 17:33, 8 September 2009 (UTC) I worry about communicating to readers that these are "approved" articles, when our approval process doesn't include elements like fact-checking that most readers would assume were present. This seems like a useful gadget, but not an appropriate default setting. Christopher Parham (talk) 17:48, 8 September 2009 (UTC) "Reply: Per WP:Performance, users should not worry about performance." - WP:PERF applies to things done in the normal course of using the site and policy decisions. Proposed changes to the MediaWiki software or changes to global JavaScript, as this would require, do need to worry about performance. Mr.Z-man 17:32, 8 September 2009 (UTC) Good point. To be honest, I know nothing about it! Why don't you edit the Q&A yourself to reflect the matter? GeometryGirl (talk) 17:38, 8 September 2009 (UTC) I'm opposed to giving FA/GA articles special wikilink colors. We can't even get consensus on whether GA articles should have an icon on the article page, so I doubt there would be consensus for turning their wikilinks a special color. In general, I think that this system of multiple wikilinks colors would confuse most readers. I'm an experienced editor, and I don't think it would be very helpful. I am not more likely to click on a wikilink because the article is rated highly; I am likely to click on the wikilink if I am interested in the topic. Karanacs (talk) 19:43, 8 September 2009 (UTC) Unlike most of the editors who have opined here, I don't think the MOS-creep problem is not nearly as prevalent or burdensome as some think it is, aside from the alt text requirement (which arose recently). However, I'm opposed to this wikicolor proposal because a) as Karanacs said, links are for topics relevant to the subject, not for high-quality articles; b) not all FAs and even more so GAs are created equal; and c) the extra colors would confuse and distract readers from what they are reading. Dabomb87 (talk) 21:27, 8 September 2009 (UTC) Iridescent, I'm dying to see examples of high-quality articles that failed FAC because they failed a single MOS criterion. Seriously, show us some, and we'll be happy to address them. I don't doubt that there are occasional problems, but saying a problem is epidemic and not offering any examples is weak. I think all this furor against FAC/GAC is sour grapes by people who don't like having to go out of their comfort zone. Following the MOS is not hard (you can always ask for help) and any point in the MOS is there for a reason. That said, I'm not sure whether I agree with this proposal. I agree with Karanacs that we shouldn't have colors on Good Articles unless there's an icon to go with it, and that's a very different discussion. And to color only FA links seems pretty worthless – FAs are so rare that the links will be more of a distraction than anything. Noisalt (talk) 21:56, 8 September 2009 (UTC) Er... my record at FAC reads 9 nominated, 9 passed; I'm not sure you can really accuse me of sour grapes here. Most of the current problems are summed up here; if you want specific recent examples of what I'd consider high-quality articles being opposed over trivia, try [9] and [10] are a couple of recent ones off the top of my head, but everyone will have their own favourite example (just search the recent archives for "too many redlinks"...). – iridescent 22:18, 8 September 2009 (UTC) "Too few links" is a rare comment (not even an oppose there), but I will concede that fair-use images have become far more contentious lately. However, that doesn't prove that MOS issues are burdensome at FAC—perhaps except that complaints about alt text are quite frequent. Dabomb87 (talk) 22:36, 8 September 2009 (UTC) (ec) Mr iridescent, please. Your first example of what you "consider high-quality articles being opposed over trivia" is slightly unfair. The point was maybe trivia for you but it was just a comment, not an opposition as you claim. @Dabomb I didn't say there was "too few", just "few". GeometryGirl (talk) 22:39, 8 September 2009 (UTC) In reply to both of the above : the essential thrust of the argument is that these types of nitpicking opposes or "comments" have a habit of placing a large amount of emphasis on style while routinely glossing over content. The one time I tried my hand at getting something featured, I spent far more time chasing after stray dashes, tweaking alt text and weeding out single unspelled digits than paying any attention at all to the actual content thereof. While in the end the attempt was successful, it was not a process I would like to repeat again. Shereth 22:43, 8 September 2009 (UTC) IMO, in an ideal content review process, the article submitted would already be comprehensive, neutral, accurate and suitably referenced to reliable sources, meaning that the only issues that would need to be resolved should probably be minor prose/stylistic/formatting points. Dabomb87 (talk) 22:49, 8 September 2009 (UTC) Well, yes, if an article does not require review, FA would not have to do one; if we had a review system that did FAC's work for it in checking accuracy, verifiability, neutrality, and clarity, FAC could then tweedle ad libitim about "MOS breaches" without much further harm. But is an FA like that any use whatever to the encyclopedia? Septentrionalis PMAnderson 14:57, 9 September 2009 (UTC) In case of confusion, GeometryGirl and I are unrelated. I haven't considered this proposal in detail, but I can see the idea and its merits. If I were proposing something similar, I would keep blue-links in general, and suggest something between blue-links and red-links (yellow-links?) for articles that existed but are not currently of much help to the reader. I've no idea how such a criterion would be defined or implemented, but "not yet a GA or FA" is not the right choice as these account (depressingly) for about 99.7% of our articles (I sincerely hope we can make an impact on that appalling figure in the coming years). Anyway, I'm certainly not proposing anything, but am open minded to any ideas which might help readers. Geometry guy 00:55, 9 September 2009 (UTC) Thank you for raising this proposal, and for leaving a message on my userpage about it. It seems to me that the rationale for this proposal was different to your that for your above rationale for the "orange links" one - you took the view there that certain orange links would be a good way to get Wikipedians to improve certain articles, just how red wikilinks, you claimed there, help Wikipedians to create new articles. For this very reason, I am not too sure of this suggestion. This is only my own personal view, but I cannot quite work out why you may wish to draw attention to articles that do not need improvement. Please do not take that comment the wrong way - it is only my own humble view, and I expect you have good reasons for this proposal. ACEOREVIVED (talk) 19:55, 9 September 2009 (UTC)

Stub edit tab: emphasis and invitation

Archived

For stubs, I suggest having the edit tab changed from edit this page to edit this stub. Why change "page" to "stub"? The word "stub" is more of a invitation to contribute. Indeed, "stub" suggests work is needed and that the reader is welcome to help. This would help create editing micro-opportunities. Why orange? Orange is a more "visible" colour than the current blue. Orange is similar to red, underlying the similarity between stubs and nonexistent articles. Discussion (edit tab) Don't bite too hard! :) GeometryGirl (talk) 11:56, 9 September 2009 (UTC) To more directly address the stub proposals though: You gloss this over potential problems section above, but the fact is that stub articles are not really special, and certainly should not be singled out as potentially needing attention. The root of this proposal seems to lie in a fundamental misunderstanding of what a Wikipedia:Stub article actually is. — V = I * R (talk to Ω) 13:04, 9 September 2009 (UTC) "A stub is an article that is too short to contain suitably encyclopedic material" is the definition of a stub. Since this is indeed an encyclopedia, I think that means this most definitely does mean that they should be singled out as needing attention, and not just potentially. A stub article is not appropriate for an encyclopedia. I have seen some editors say "some articles just cant ever get beyond a stub", the correct response to those people is- 1- the article shouldnt then exist and should probably be merged with similar stubs as a list article or 2- its a short article but not a stub, a short article that has encyclopedic content and is a good article can be classified as more than a stub even an FA. I see no misunderstanding in what a stub is in this proposal, give good faith that people know what they are proposing, since doing otherwise and lecturing that they dont is bad-faith. With that done I do have to say that this is still a bad idea because its simply semantics. Who cares if it says "edit this article" or "edit this stub", it wont actually bring in more editors in my opinion.Camelbinky (talk) 13:35, 9 September 2009 (UTC) That is very much my point, thank you Camelbinky. What do you think of the orange link proposal above? And why don't you think making the link orange will not attract more people? GeometryGirl (talk) 13:40, 9 September 2009 (UTC) I see that is what the lead says now, but if you actually read the document it does (more accurately) state that stub articles are not specifically an issue to be resolved. Some articles should be stubs, and there's nothing wrong with that. They simply don't need attention due to the fact that they are stubs alone. — V = I * R (talk to Ω) 13:55, 9 September 2009 (UTC) (edit conflict)Actually, merits aside, I have to wonder if this is technically feasible. Presently, tab names are assigned based on namespace, with no regard for content. --King Öomie 13:42, 9 September 2009 (UTC) That's what I was attempting to get across, above. It's really not technically feasible right now. — V = I * R (talk to Ω) 13:55, 9 September 2009 (UTC) Well, it COULD be done, but it'd have to be global javascript, and could potentially play hell with people's Monobooks. Again, not seeing a possibility of global deployment. Looks fine for opt-in, though, I'm sure a script could do it (you can already reduce the "Discussion" tab to "Talk"). --King Öomie 14:00, 9 September 2009 (UTC) While well intentioned, I find it extraordinarily doubtful that this change would result in any increase in the amount of stubs being upgraded. It is the article/subject itself - not an orange link at the top - that determines whether or not someone is interested in editing it. Shereth 16:21, 9 September 2009 (UTC) Why are there 300 000 000 different viewers a month but only 90 000 active editors in a given month? Come on! It's not just "the article/subject itself". Sure, that is a necessary condition, but it surely is not sufficient. GeometryGirl (talk) 16:30, 9 September 2009 (UTC) I don't follow your point. There are 300M visitors but only 90K editors because the vast majority of people are interested in reading, not editing. Visitors know Wikipedia is editable by anyone. As a general rule people edit articles that interest them. Put simply: if I am looking for information on Horse Mesa Dam, I go to the article and find very little information, so I move on to another source. How is changing the color of the "edit" link is going to cause a revelation that I should jump in and improve the article? I appreciate what you are trying to do, but colorizing the tabs at the top is not going to incite people who have no interest in editing to chagne their minds. Shereth 16:44, 9 September 2009 (UTC) My point is that Wikipedia is giving out the wrong message with everything blue. Basically, the current message is "you can edit Wikipedia if you want, but we are doing fine without you". The message Wikipedia ought to give is "you can edit Wikipedia and we really need you to do so". Get my point? GeometryGirl (talk) 16:47, 9 September 2009 (UTC) To put it another way, Wikipedia needs money, and they periodically ask for donations. Well Wikipedia also needs editors, and we should be advertising the NEED, not just the possibility of becoming an editor. There is a real need... (and a lot of potential). GeometryGirl (talk) 16:51, 9 September 2009 (UTC) I get your point. I don't agree with it. I do not agree that bluelinks imply "This article is finished and doesn't need improvement". I do not see how orange links would thusly imply "This article needs help", and I especially do not see how the casual reader is going to understand that implication. Moreover, I don't think you get my point. People who are not here to edit are not here to edit; changing link colors is not going to change that fact. People who are here to edit, edit what interests them; changing link colors is not going to change that fact. Again, I appreciate what you are trying to do, but I just don't see this as doing anything to help. Shereth 16:53, 9 September 2009 (UTC) So you do not think that there are people who come to Wikipedia "to read", would be willing to contribute, but do not contribute because they do not feel the need to contribute, or are not prompted enough to contribute? (Because, e.g., Wikipedia already has 3 000 000 articles and is doing just fine.) GeometryGirl (talk) 16:57, 9 September 2009 (UTC) The goal is to convert people from readers to editors. Really basic. GeometryGirl (talk) 16:59, 9 September 2009 (UTC) As Shereth said, everyone who comes here knows that anyone can edit. It's on the logo. If they don't WANT to edit, and they come across a lackluster page, they're STILL not going to want to edit. It doesn't matter how colorful the blown piston is, I still don't want to learn how to fix my engine. The tab name change is fine, for consistency's sake, but the color change is really not required. --King Öomie 17:04, 9 September 2009 (UTC) (ec, response to GG) No, I don't think so. Take an example. I am a casual reader who is willing to contribute, and I go to Horse Mesa Dam. I see that the article is really short, and even has stub templates that say "This article ... is a stub. You can help Wikipedia by expanding it." Are you saying that, when I go to hit the "edit this page", I will see the blue link and therefore conclude "Oh wait, it is bluelinked, they must not need my help?" Really, I should be dispensing with all of these hypotheticals and simply ask : how does an orange link (as opposed to a blue link) convey, to the causal reader, that we really want their help? If they are a casual reader, how are they supposed to understand this distinction between blue and orange links? I agree with your goal of trying to entice readers to become editors. Put simply, however, orange-linking a tab is very unlikely to contribute to this goal. Shereth 17:07, 9 September 2009 (UTC) (e/c)I think you're completely misunderstanding his argument. I agree with Shereth. Bluelinks do not imply that the article is complete, or doesn't need any work. I don't what you're basing that on, other than personal opinion. Every article could be improved. No article is ever "finished" I don't see how changing link color is going to do anything other than make articles harder to read and introduce accessibility problems for people with poor vision (orange text on white background has rather poor color contrast, and I believe it fails WCAG AA priority level). Mr.Z-man 17:08, 9 September 2009 (UTC) I agree with you guys, bluelinks do not imply that the article is complete, or doesn't need any work. I agree. However, what I am saying is that there is a difference between "YOU CAN EDIT" and "YOU NEED TO EDIT"? I agree with you, most people know that they can edit. But do they know that Wikipedia needs them? For you engine, you can just ask a mechanic. But Wikipedia is volunteer based... Can't ask people other than our readers. I really don't see how the proposed change reflects that though. It relies too much on implied meaning by color and a slight wording change. Imagine if {{cleanup}} was nothing but a box with a picture of a broom in it. 1) I don't think the connection is very obvious and 2) As Shereth said, people edit what they're interested in, not what we tell them they should be editing. Mr.Z-man 17:21, 9 September 2009 (UTC) And in response to GG, in the case of a busted engine, I'd likely rely instead on the volunteer network of 'My Neighbor Jeff', who keeps my car running because I do the same for his computers. --King Öomie 17:28, 9 September 2009 (UTC) Pale orange, as proposed, is barely visible. It looks darker on cheap uncalibrated office-type LCDs; step up to a properly calibrated screen, you'll be amazed how light it is. As long as background is white, orange is a no-no. On a completely different issue, don't rely on article ratings below FA. Never. English wikipedia has no way of enforcing consistent and reliable article ratings. Take a look at this diff. Stub to GA. Guess what? It was not a stub. It was not GA either. How long could it go unnoticed? NVO (talk) 17:14, 9 September 2009 (UTC)

Stub edit tab: new proposal

Dismissed for now

For stubs, I suggest having the edit tab changed from edit this page to please edit this stub or please edit this stub or Please edit this stub pr Please edit this stub. Why change "page" to "stub"? The word "stub" is more of a invitation to contribute. Indeed, "stub" suggests work is needed and that the reader is welcome to help. This would help create editing micro-opportunities. Why add "please"? To make readers understand that they contribution is required for Wikipedia to exist and evolve. "Please" also formally expresses an invitation to contribute. Why red? Red is a more "visible" colour than the current blue. Red expresses the similarity between stubs and nonexistent articles. Red expresses a need. Orange is too pale. Why green? Because red links on Wikipedia exclusively mean "this page does not exist". Why stubs? Because stub articles are not appropriate for an encyclopedia: "A stub is an article that is too short to contain suitably encyclopedic material". Also, new editors would less likely get lost in the small amount of wikisyntax contained in stubs. Finally, in many ways, improving a stub is easier than improving a developed article. For who? For all readers by default. Discuss (edit tab new proposal) Don't bite! GeometryGirl (talk) 17:27, 9 September 2009 (UTC) Weak Oppose Working through the rainbow now. Red links on Wikipedia exclusively mean "this page does not exist". --King Öomie 17:32, 9 September 2009 (UTC) Ok, we can find some other colour. Green? GeometryGirl (talk) 17:34, 9 September 2009 (UTC) And subconsciously suggest that the article is fine? The full gamut of begging readers to expand the stub is accomplished by the {{stub}} template itself- if that won't sway them, more pressing will only serve to irritate. <Creative slippery-slope argument that sways your opinion> --King Öomie 17:36, 9 September 2009 (UTC) (ec) I don't want to badger you. Really I don't - I like what you are trying to do in encouraging more participation and in getting more readers to become editors. Really. This proposal, however, is just the last one re-done in new colors. The choice of color (red, blue, green, orange, magenta, ultraviolet, whatever) is not relevant. Even the wording ("Edit this page", "edit this stub", "please edit this stub", "We really need some help expanding this stub so please lend us your expertise and expand it into something bigger") is of little relevance. The whole point of my argument is that a tab at the top of a page is not going to encourage participation in the project. The ultimate goal of this proposal is noble but at the moment the energies here are being misdirected down a dead-end street. You are aware that the wording of pretty much every single stub template reads "This article ... is a stub. You can help Wikipedia by expanding it." The appeal has already been made, making it again is expending effort where it is not effective. I'm sorry, I just can't support a proposal that has little to no real benefit to it. Shereth 17:37, 9 September 2009 (UTC) Have you tested this proposal? Does it really have little to no benefit? That's slightly pretentious. But anyway, the template says "You can help Wikipedia" and not "please help Wikipedia" (in the same way that we have "Please donate" and not "You can donate"). It is a (subtle) matter of sending the right message. GeometryGirl (talk) 17:41, 9 September 2009 (UTC) Then perhaps your energies would be better spent on trying to refine existing mechanisms (by proposing changes to the stub templates) rather than by trying to re-invent the wheel? Shereth 17:44, 9 September 2009 (UTC) Please, assume good faith, and don't bite. Why not even do both? (For the template, I hadn't even thought about it.) GeometryGirl (talk) 17:46, 9 September 2009 (UTC) Pardon? I'm not sure where I have failed to assume good faith or violated WP:BITE? I have made every effort to be civil with my replies and I expect not to have these kinds of policies waved in my face for no apparent reason. As far as "why not do both" - it is woefully inefficient to do something twice when once will suffice. Modifying templates requires simple edits, whereas what you are proposing requires changes to the MediaWiki software itself. When a simple solution exists, why continue to pursue the more complex? Shereth 17:50, 9 September 2009 (UTC) Well you where saying I was "reinventing the wheel" when that was not at all my intention (faith). Maybe I just took the comment badly after all the negative comments I have been having in exchange of all the time I am donating. I have created a new proposal below. GeometryGirl (talk) 17:55, 9 September 2009 (UTC) Proposing something has become a battle. It seems editors are having the same problems with editing. No wonder editors are leaving. GeometryGirl (talk) 17:57, 9 September 2009 (UTC) Pass/fail statistics aren't subject to a grade curve. --King Öomie 17:59, 9 September 2009 (UTC) I think this has almost all the same problems as the orange proposal. It still relies too much on the meaning being implied by using colors and "stub" instead of "page." It doesn't have the accessibility problems of orange. However, green sends the wrong message entirely. Green suggests that the article is fine, a lot more than blue does. Red on the other hand, would be confusing by having it serve 2 different (albeit related) purposes. And to reply to some recent comments, proposing things is a discussion. If nobody disagreed with the idea, chances are we'd already be doing it. Mr.Z-man 18:05, 9 September 2009 (UTC) Again, I'm not sure why changing the edit tab would encourage editors; there's a lot of made-up "this would help!" arguments being made, but without any explanation as to why or how. EVula // talk // ☯ // 18:07, 9 September 2009 (UTC) (edit conflict)Ok, make it blue, but underline it, I don't know. What do you think of Please edit this stub? ...why? Why would it be underlined? None of the other tabs are, and it's more important (in my mind) for things to be consistent. EVula // talk // ☯ // 18:12, 9 September 2009 (UTC) OK, OK, as you want. Remove the underlining, Please edit this stub GeometryGirl (talk) 18:21, 9 September 2009 (UTC) @EVula Why this would help? Because it changes the attitude Wikipedia has towards readers. Instead of saying to them "you can edit this page" which doesn't imply any need for this page to be edited, Wikipedia would say "please edit, you must!". It's a PR campain. GeometryGirl (talk) 18:12, 9 September 2009 (UTC) Ah, that's why we disagree: you are wrong (I mean that in the nicest way possible, but after so many proposals in short order where everyone has been nice, I feel that someone needs to be a bit more blunt about it). Our readers don't have to edit Wikipedia; to say that they must is a lie. We, of course, would like to encourage more readers into getting involved, but honestly, it just plain isn't something for everyone. We need to remain open so that anyone can edit, but we don't need to be going out of our way to make sure that everyone does edit. As it is, I'm still not sure how "please edit" will achieve any sort of change whatsoever; I really think you're wasting your (apparently boundless) energy. You'd be better served trying to figure out a way to make editing more approachable by those readers who are interested in editing, rather than trying to fit square pegs into round holes. EVula // talk // ☯ // 18:21, 9 September 2009 (UTC) I exaggerated a bit when I said "they must". But please see this video, it is my inspiration. GeometryGirl (talk) 18:25, 9 September 2009 (UTC) I don't what to badger you either, but ultimately I agree with Shereth. I ahve all along, actually. I agree with the underlying goal here (encouraging participation), but this just isn't he means to achieve it. I can tell that you're feeling a bit embattled here, and for that I'm really sorry especially since you're obviously highly motivated to address the participation issue. I don't want to discourage you at all, and I don't think that Shareth or anyone else does either. We're just trying to say that you're energy is currently misdirected a little bit, is all. My recommendation is to check out, and jump into participating in and assisting, the Usability Initiative. This whole subject area is exactly what their tasked (and funded!) with pursuing. — V = I * R (talk to Ω) 18:13, 9 September 2009 (UTC) Thanks for the advice. I have already posted two proposals (one for green links, and one for orange links) on the usability wiki. The project seems dead, no one participates. Money doesn't make everything... GeometryGirl (talk) 18:19, 9 September 2009 (UTC) A lot of people participate, actually. My watchlist moves faster than my car. --King Öomie 18:23, 9 September 2009 (UTC) Well not mine! What is on your watchlist? GeometryGirl (talk) 18:26, 9 September 2009 (UTC) Approaching 400 pages. I could add WP:AIV and WP:ANI to make it REALLY fly. --King Öomie 18:46, 9 September 2009 (UTC) Oh, so you are watching every page! Well I'm just watching two, and they are basically dead. I looked around other pages and haven't found very active pages... GeometryGirl (talk) 18:49, 9 September 2009 (UTC) I'm watching less than 0.014% of all the articles on En. Non-contentious articles can remain stagnant for weeks, and tend to see a flurry of activity when the subject is reported on in some fashion (read: Colbert). This is perfectly normal. Try following Barack Obama. Articles like Nickelback are plastered with vandalism multiple times daily (and my heart goes out to the vandals, they who know the truth, but lack the means to express it civilly :D). --King Öomie 18:57, 9 September 2009 (UTC) She was talking about at the Usability Initiative, not en.wikipedia. — V = I * R (talk to Ω) 19:03, 9 September 2009 (UTC) Hmm, I'm not sure. She referred to posting these proposals twice, and then referred to "the project" as dead, which I interpreted as the entire project. --King Öomie 19:07, 9 September 2009 (UTC) Quote: "I have already posted two proposals (one for green links, and one for orange links) on the usability wiki. The project seems dead, no one participates." :) — V = I * R (talk to Ω) 19:09, 9 September 2009 (UTC) Quote: "The project seems dead, no one participates." :D Final word goes to GG. --King Öomie 19:12, 9 September 2009 (UTC) I was talking about the usability wiki, obviously. Thank you Ohms law. GeometryGirl (talk) 19:52, 9 September 2009 (UTC) =( --King Öomie 20:16, 9 September 2009 (UTC) Just because they don't use the wiki that much doesn't mean the project is dead. Its still very much active on the software development side. Mr.Z-man 21:59, 9 September 2009 (UTC)

Changing the stub template

Proposed at WP:Stub

I propose to change to This article is a stub. Please help by expanding it. or something similar. If I'm not mistaken, this belongs at Template talk:Stub. But for good measure, Support. --King Öomie 18:00, 9 September 2009 (UTC) Actually, there are about 20,000 stub templates. I'm not really sure where it should go. --King Öomie 18:02, 9 September 2009 (UTC) Thanks to one very sexy bot operator all stubs are now built with Template:Asbox. One simple change could make that phrase green, whether there is consensus to do so is another story. Discussion about that should occur here or maybe at WT:Stub. –xenotalk 18:04, 9 September 2009 (UTC) All narcissism aside, I'd think a notification of this discussion at WT:STUB would be sufficient. But of course, we are all very thankful for sexy bot operators :) Shereth 18:12, 9 September 2009 (UTC) I'm not sure where the obsession with green is coming from, but it's getting ridiculous... EVula // talk // ☯ // 18:10, 9 September 2009 (UTC) Happier now? No green? Please, I wrote "or something similar", be constructive. GeometryGirl (talk) 18:14, 9 September 2009 (UTC) I can support a wording change but I am not a fan of the current format. Why the green? Shereth 18:12, 9 September 2009 (UTC) Changed the colour. GeometryGirl (talk) 18:15, 9 September 2009 (UTC) This is a potentially helpful tweak: please raise it at Template talk:Stub. Geometry guy 21:30, 9 September 2009 (UTC) I have just had a thought. As any lecturer who has presented using overhead acetates or Powerpoint will know full well, one has to be very careful with choice of colours, so as not to confuse students who may suffer from colour blindness. Are you sure that your choice of colour scheme will not do this? One thing I should say is that perhaps the most common form of colour blindness is red-blue colour blindness - so perhaps you are right, we do not need to change the colours of wikilinks! ACEOREVIVED (talk) 23:11, 9 September 2009 (UTC) I have a feeling I was actually thinking of red-green colour blindness - please, pleaes, consider this. Although I do not suffer from colour blindness myself, remember, Wikipedia should be accessible to all. ACEOREVIVED (talk) 23:23, 9 September 2009 (UTC) FWIW, red-green is the most common form of colourblindness, followed by total colourblindness, then blue-yellow - though that's all beside the point. I have a question, though... why is this change being proposed? If it serves no purpose (and for the life of me I can't see what purpose it would serve), then it simply seems to be wasting effort. What difference does centring the text do other than moving the icon away from the left margin and potentially making formatting look odd in a few cases? Similarly, what difference would changing the colour make other than making readers wonder whether the stub message is a hyperlink? In both cases it would increase the visibility of the stub template (something which we've been doing as much as possible to avoid at WP:WSS - the more discreet a stub template is, the better), but other than that, it wouldn't really make for any other than a cosmetic change. By the way, King Oomie is right - changes to the stub template(s) are normally discussed over at either Template talk:Stub or at Talk:Stub. Indeed, there have been numerous suggestions on changing the look of stub templates there in the past in many different ways - including, IIRC, a rejected suggestion to centre stub messages. Grutness...wha? 01:27, 10 September 2009 (UTC)

Watched counter

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

A recent changes page for unwatched articles

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

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

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

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

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

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

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

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

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

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

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

You could just use variables, like

"Recent Changes on Village pump (proposals)/Archive 51: RodRabelo7, on 09/1/2024"

But it would be a good idea for rollback

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

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

Would it be a good idea to move this proposal into its own page, and if so, where should it be located?    M   22:10, 6 September 2009 (UTC)

Recent unwatched changes straw poll

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

• Support. –M^T 04:28, 5 May 2009 (UTC)
• Support. -- John Broughton (♫♫) 18:24, 9 May 2009 (UTC)
• Support sounds good to me. It does provide a route for vandals to find unwatched articles, but I think the benefits outweigh that. Rd232 ^talk 18:34, 9 May 2009 (UTC)
  • While technically true, any such vandalism would land the vandal with a kick to the pants, since their edit would float to the very top of this slow-moving list. –M^T 19:46, 10 May 2009 (UTC)
• Support. Mark Hurd (talk) 15:05, 10 May 2009 (UTC)
• Comment - Just file a bug. If its a good idea and technically feasible, someone will do it. The existence of a straw poll will likely have no effect. Mr.Z-man 15:26, 10 May 2009 (UTC)
  • Isn't a bug with a supportive straw poll more likely to be implemented soon than the same bug without? Rd232 ^talk 19:35, 10 May 2009 (UTC)
  • When people voice their support for a proposal, others become more inclined to try to see it implemented. This may include filing a bug report, searching documentation, speaking with devs directly, changing the relevant code, and submitting a patch. "Well, someone else will get to it eventually" is not the approach that we should take at this page. Even if the devs were entirely blind to community requests, your support would nevertheless encourage other editors (like me) to try to see this implemented. –M^T 19:46, 10 May 2009 (UTC)
    • With this specific proposal, it may, but only because the schema change would need approval from Brion. With the amount of work required to do this, I doubt a little straw poll is going to have a significant effect on any developer's motivation. Mr.Z-man 18:58, 13 May 2009 (UTC)
      • Then let's hope that it grows to become a much bigger straw poll :) as this might demonstrate a need for better tracking of unwatched pages   M  20:29, 13 May 2009 (UTC)
• Support - I really like this idea. I know from personal experience that non-obvious vandalism on poorly watched pages can go undetected... I have a couple such pages on my watch list & when I took a month off, I cam back to find some vandalism on one of them that had been sitting for 2+ weeks. --ThaddeusB (talk) 18:34, 13 May 2009 (UTC)
• Support - Great idea. Kevin Baas^talk 20:34, 13 May 2009 (UTC)
• Strong support: The admins can't do this alone. I love the idea. Dendodge _T\^C 20:38, 13 May 2009 (UTC)
• Bug 18790 has been created. Suggesting improvements (or establishing that there is a clear need for this) here is what will help with implementation, though voting at bugzilla in addition to here should help make it more noticed. At bugzilla, only 55 wp enhancements have 10+ votes, 19 have 20+, and 8 have 30+, out of over 1300. Registration is easy, and the vote link is at the bottom-right of the bug page, under 'related actions'. (Please use this feature to vote instead of leaving a comment at bugzilla, as comments are relayed to mailinglists).   M  22:31, 13 May 2009 (UTC)
• Support - Makes a lot of sense and fills a great need. J04n(talk page) 09:58, 22 May 2009 (UTC)
• Support - If this can be done without overloading the system, then by all means please do. (Every little bit helps in targeting vandalism.) --Ckatz^chat_spy 17:18, 26 May 2009 (UTC)
• Support per above proposal --unsigned by Assasin Joe
• Support per all the other comments that I read. This would be very useful to find vandalism in more hidden pages. –Drilnoth (T • C • L) 17:02, 27 May 2009 (UTC) See my comment below. –Drilnoth (T • C • L) 15:46, 14 August 2009 (UTC) Support per my original comment. –Drilnoth (T • C • L) 19:46, 14 August 2009 (UTC)
• Support – Wow, this is a really good idea. As long as it can be configured in software, I think it would be very useful. American Eagle (talk) 06:36, 31 May 2009 (UTC)
• Support If implementable, it's an ingenious solution to the problem of vandalism to unwatched pages. --Cybercobra (talk) 08:52, 31 May 2009 (UTC)
• Support only for admin, oppose otherwise - It would be simple enough for a vandal to watch a page, and then it would fall off of everyone's radar. That would turn a good thing into a very bad one. ▫ JohnnyMrNinja 06:57, 5 June 2009 (UTC)
  • Restricting the page to admins is one solution, but I don't think that there's a problem. We would count only autoconfirmed watchers active in the past 7 (or 60) days, and the implementation would also give us recent-changes for pages with 1 watcher, or under 5 watchers, and so on. The sort of coordinated vandalism to 'get around' this is rather visible and is more difficult to deal with if we keep the pages admin-only.    M   01:14, 6 June 2009 (UTC)
    • Isn't that going to be a gigantic strain on the servers? Right now, our watchlists are the biggest strain (right?), so wouldn't a watchlist that watches thousands of pages that are selected from every page on EN based on a series of checks on each page and every user that watches any pages at all... Wouldn't that slow our WP down to the barest crawl? Even if the list of articles matching the criteria were only updated every other day or so, a watchlist that big is a massive beast. Of course you could limit the number of pages that show up, but it would still check the entire list for the 100 most recent changes (right?). I'm certainly no expert on how Mediawiki works, so maybe I'm wrong. Limiting it to admins is a better solution, I would think, if even that is feasible. If it's between having an even-more unstable connection to WM projects or having the fact that Franklin Township, Wright County, Minnesota is referred to as a "gaylord" for two weeks, I'm okay with the latter. But, again, maybe I'm mistaken about the strain. ▫ JohnnyMrNinja 09:12, 10 June 2009 (UTC)
      • No - actually, it might speed things up. The proposal is not to put every unwatched page onto a global watchlist, but to record the watcher count in the recent changes table. This is extremely fast compared to a global watchlis, and is fast in general (see Bug 18790). If the page causes people to reduce their overburdened watchlists (which it should), it may actually increase performance.    M   00:27, 11 June 2009 (UTC)
        • If that's the case then it could be workable, and it is a good idea. With the inclusion requirements you've specified, the list would actually pick up far more pages than the regular unwatched pages list. But I must stress that launching it for everybody is a bad idea, because if something goes wrong and it is deactivated, we will have provided a complete list of un-and-hardly-watched pages, and then removed our ability to protect them. I am not a fan of segregating access normally, but I still feel that it should only be accessed by admin (maybe rollbackers?) until such time that it shown to not contain bugs and we decide we're going to keep it permanently. The only thing you need to be Autoconfirmed is to not have been blocked yet. ▫ JohnnyMrNinja 02:25, 11 June 2009 (UTC)
          • Right, it wouldn't be the same, though this means it would pick up more unwatched pages and not false positives. It wouldn't be a complete list, since it would only record edits made in that short period of time (no doubt those articles would be gobbled up into watchlists by our editors). I do think that these points deserve attention, but it might be early to decide how we want to deploy the feature.    M   18:29, 16 June 2009 (UTC)
            • A few comments. This almost certainly won't speed anything up. Watchlists are not the biggest strain and the slow part of watchlist generation is generating the HTML, not the 1 database query to get the list. You're calculating something that's not currently calculated and not removing anything else. You say in one comment that people would "reduce their overburdened watchlists" then in another that pages would be "gobbled up into watchlists by our editors." That can only affect performance in one way. The question is just will the extra calculation on every edit be fast enough to be usable. Blocking a user does not remove the autconfirm right. A blocked, autoconfirmed user could still do anything that requires autoconfirmed, as long as it doesn't also require editing rights. Even if they're blocked before becoming autoconfirmed, their account doesn't stop aging, and most blocked users can still edit their talk page; so they could even become autoconfirmed while blocked. Mr.Z-man 20:36, 16 June 2009 (UTC)
              • A reduction in the size of watchlists and perhaps the need to check them might reduce some of the burden. It's not important whether it will or not, just that it definitely won't bog down the server. In the long term, this will allow editors to reduce their watchlists. In the short term, editors will tend to add these articles to their lists until they see that it's unnecessary. If something went wrong, which is entirely unlikely, we'd have no problems watching the small list of recent unwatched articles. Dedicated vandals will always get through to some extent, but checking for autoconfirmed is something cheap, relatively accurate, and effective for the majority of cases.    M   00:23, 22 June 2009 (UTC)
                • Restricting it to autoconfirmed would be trivially simple to bypass. Vandals wouldn't even need to create new sleeper accounts to see the list, they could just use existing, blocked ones. If you're not concerned with dedicated vandals, then it shouldn't be restricted at all, as only dedicated vandals would likely even take the time to check such a list. Mr.Z-man 03:28, 22 June 2009 (UTC)
                  • Misunderstanding, I think. It's safe to let everyone see it; I think the concern was a vandal registering 5 accounts, watchlisting many articles, and then vandalizing them. Autoconfirmed would be for whether the editors are counted as watchers, which makes this strategy not worth the effort.    M   08:11, 26 June 2009 (UTC)
• Support the unwatched list it too big to do anything useful with by admins. Perhaps proven vandal fighters would get blocks of these unwatched pages to add to their watchlists. Talk to me if you are interested in this idea. The article names could be emailed to those who want to change them to watched articles. Graeme Bartlett (talk) 02:16, 6 June 2009 (UTC)
• Support Sounds like a good idea. Dream Focus 09:35, 6 June 2009 (UTC)
• Support Graeme two posts up says it well. Casliber (talk · contribs) 05:29, 25 June 2009 (UTC)
• Yep, definitely a good idea. –Juliancolton | ^Talk 22:07, 2 July 2009 (UTC)
• Support Very useful idea. It will increase the efficiency of the list. In my opinion, I would not mind if I had a list of pages to watch on top of my current list. It is all going for the same cause in the end anyways. -- Dspradau → talk  14:45, 6 July 2009 (UTC)
• Support, a very good idea. 'Nuff said. Jamie^☆S93 21:41, 9 July 2009 (UTC)
• Support, with considerations. It should only go ahead if it is known with certainty to not cause added strain to the servers, as well, I think one of the suggestions above should be seconded: make it admin only for a test period, before opening it up for everyone to use, just as a precaution. (I know, I'm hardly here, but, at least I'm hardly here over a long period of time *grin*, which should let me have some say). kaVri 19:28, 12 July 2009 (UTC)
• Support - This feature would increase average article quality on Wikipedia by combating vandalism on unwatched pages. One could see it as a complement to Flagged Revisions. EconomistBR 20:56, 15 July 2009 (UTC)
  • I've heard stories about something called "flagged revisions", but I think those are just ghost tales that old editors tell each other around the campfire. They'll be implemented soon is the punchline to all the jokes. There was something about them appearing when Brion Vibber got back from his honeymoon, but he seems to be back now... Delicious carbuncle (talk) 21:54, 15 July 2009 (UTC)
  • Though I don't think that flagged revisions are as useful as they seem (I'd prefer a per-person way of tracking articles and not revisions, which is somewhat easy to implement using the watchlist), I agree that the two would work well together. Similarly, if we turned on the 'how many people are watching this page' feature, those interested in watching the unwatched pages would be able to tell if they are already watched.    M   21:05, 20 July 2009 (UTC)
• Oppose, this will just make things worse, giving the vandals a potential hit list they can use. ViperSnake151  Talk  13:33, 24 July 2009 (UTC)
  • You might be misunderstanding the proposal. While technically true, any such vandalism would land the vandal with a kick to the pants, since their edit would float to the very top of this slow-moving list. It's safe to leave cheese out when there's a lethal spring-loaded bar attached - which is exactly what this list is.    M   17:44, 31 July 2009 (UTC)
• Support – definitely. This is a good way to revert vandalism. —MC10|Sign here! 02:34, 25 July 2009 (UTC)
• Nuclear support. This is a brilliant idea. In the past I've randomly picked some unwatched pages to put on my watchlist, but they were never edited that I saw, and I removed them as a futile addition. One caveat, though. Are we only looking at pages that show up on zero watchlists, or will this include, for example, pages only watched by people who are long gone? Come to think of it, where we have permablocked vandals and the like, can we strip them of their watchlists and prevent them from watching articles (given that they would only have nefarious reasons to be watching anything)? Cheers! bd2412 T 19:28, 31 July 2009 (UTC)
  • It marks the recent-changes entry with how many recently-active & autoconfirmed editors were watching at the time of the edit. This ignores long-gone editors, and the 'watch pages to hide them' vandal tactic is painfully time-consuming (so watchlist-stripping is not needed). Yes, we would be able to filter recent-changes to pages with 0, <5, or >500 watchers.    M   19:52, 31 July 2009 (UTC)
• Support Ben MacDui 15:42, 1 August 2009 (UTC)
• Support Far better to match the system to the content, not vice versa: there have been calls to raise the BLP notability bar to cut down on content needing to be watched. Esowteric+Talk
• Support - great idea. --[midnight comet] [talk] 18:24, 3 August 2009 (UTC)
• Support - makes life easier. Kayau Wuthering Heights VANITY FAIR paradise lost 08:17, 4 August 2009 (UTC)
• Support-It seems like a great idea. However, there must be hundreds of thousands of unwatched articles. Perhaps we should start off with admin's first. In addition, there really should be a limit as to how many a person could see.(I see no reason to have a public list of 150,000+ unwatched articles as this invites vandalism).Smallman12q (talk) 19:28, 4 August 2009 (UTC)
  • The list pretty much only displays recently-edited unwatched pages, rather than all unwatched pages. It would slowly grow until pages started falling off the end. You're probably right about the title - we shouldn't have a page called 'here are our unwatched pages' (which isn't true anyway, since we'd watch them using this list). It should probably be just another option in the recent changes list.    M   02:05, 5 August 2009 (UTC)
• Support. What a great idea. To the editor who said it should only be admins, I can understand, but suspect that more help will be needed than just sysops. What about making it availible to those who have had rollback without incident for six months or a year? Unschool 02:17, 10 August 2009 (UTC)
• Support Couldn't hurt anything, and might wind up being useful. causa sui× 04:43, 13 August 2009 (UTC)
• Support I can't see it doing any harm to try this, at the very least. Sophus Bie ^(talk) 03:13, 14 August 2009 (UTC)
• Neutral. Would certainly be useful but... vandals can watch pages to. A vandal who is smart enough to use that list to find pages which aren't watched would probably be smart enough to watch the page after vandalising it. :/ I know, WP:BEANS, but I think that it needs to be mentioned. One option would be to limit it to a trusted group like rollbackers. –Drilnoth (T • C • L) 15:46, 14 August 2009 (UTC) Switched back to support, above. –Drilnoth (T • C • L) 19:46, 14 August 2009 (UTC)
• Support. I do not quite understand this technical jargon (please do not waste time trying to explain to me), but if the only way the server load can be tested, is to be implemented, I support. All critics seem to have been silenced by M's rebuttals. Lumenos (talk) 04:44, 15 August 2009 (UTC)
• Support. Sounds like a good idea. I just hope it doesn't backfire because of unforeseen circumstances. Maybe it should be tested first in a trial run for admins only. -- œ^™ 20:18, 15 August 2009 (UTC)
  • I like the idea of testing in a safe way first, before making it live for all. That unfortunately might mean restricting it to admins, unless someone has a better idea. (One possibility would be to force the list to be definitely small enough to process, eg show only the first 100 unwatched-change pages per day. Or show those 100, but only create a new batch when all those 100 have been watched...) Rd232 ^talk 08:45, 7 September 2009 (UTC)
• Comment This seems to have broad support, and a bug was filed. Should the poll be closed? --Cybercobra (talk) 03:45, 18 August 2009 (UTC)
  • 34 support, 1 Oppose as of your comment, so the support is strong, yes :) It's still not clear though if this is something the community sees as not just a good idea, but something that's really needed (per my 13 May comment above). Many editors are also giving a lot of informative feedback (eg the 'rollbackers only' points) and ideas, without this generating 'drama'. I think it will die down soon enough anyway...    M   02:21, 19 August 2009 (UTC)
• String support provided access to it is limited to trusted users (perhaps admins and rollbackers?). עוד מישהו Od Mishehu 08:38, 18 August 2009 (UTC)
• Support Brilliant idea ! Mr.TrustWorthy----Talk to Me! 17:19, 18 August 2009 (UTC)
• Support GeometryGirl (talk) 11:01, 19 August 2009 (UTC)
• Support ----occono (talk) 17:06, 23 August 2009 (UTC)
• Yep, would be good. I suggest that only rollbackers and sysops be able to see it. Pmlineditor  Talk 12:10, 30 August 2009 (UTC)
• opppose Until we know exactly how many unwatched articles/pages there are. If there are more than 10,000, I can't imagine a watchlist which would do much good unattached to some external tool. Protonk (talk) 08:27, 7 September 2009 (UTC)
  • My feeling is that the number is far north of 10,000 Protonk (talk) 08:34, 7 September 2009 (UTC)
  • Please read the proposal before commenting. I've replied to this objection 3 or 4 (or more) times now. The list would not expose all unwatched pages. Why would we need an external tool?    M   06:38, 12 September 2009 (UTC)
• Neutral To be honest, I just don't care much about the underlying issue here. It certainly wouldn't bother me if this were implemented, but since I would be unlikely to ever use it I can't support it.
  — V = I * R (talk to Ω) 08:52, 7 September 2009 (UTC)
• Oppose: Of course, it's always tempting to say "I want something", but we have to look at the cost. As Protonk points out, it is not trivial to implement and may require even an additional tool. That's not worth our developer's time. There are more important bug requests, and the watch problem can be better addressed with flagged revisions. — Sebastian 01:09, 12 September 2009 (UTC)
  • Nothing is trivial to implement, but this is certainly not on the difficult end of the spectrum. Could you give more details on what exactly you think makes this non-trivial, or what aspect may require an additional tool?    M   06:38, 12 September 2009 (UTC)
  • Now that I read it, this reply makes we want to support the proposal here based on "it would be better to use flagged revisions", which I think is a terrible idea.
    — V = I * R (talk to Ω) 09:34, 12 September 2009 (UTC)
• Support, even strong support. I would use this daily at least. Gosox5555 (talk) 01:31, 14 September 2009 (UTC)
• Support I've seen some unwatched pages (like schools, for instance) get vandalized and stay vandalized for a while until someone comes back and vandalizes it again. This proposal will certainly help counteract this, or, at least help cut down the number of edits people have to look out for. Hardtofindaname 08:35, 14 September 2009 (UTC)
• Mindblowing support- and in response to suggestions that vandals can watch pages- IP vandals can't. Suggest only listing a page as 'unwatched' if it's not watched by autoconfirmed users. --King Öomie 19:52, 18 September 2009 (UTC)