Wikipedia talk:WikiProject Stub sorting/Archive 7

Archive 1

←

Archive 5

Archive 6

Archive 7

Archive 8

Archive 9

Archive 10

Once again acheived

We have once again achieved full stub sorting. Currently, only those stubs that are candidate for deletion are under the category of stubs. We should keep up the tempo so that the number of articles in this category restrict to a bare minimun. -Ambuj Saxena (talk) 13:14, 4 March 2006 (UTC)

I think it would be better if you stopped altogether. Stub categories are category clutter. There are far too many articles marked as stubs for the system to be useful and there probably always will be. 62.31.55.223 01:34, 11 March 2006 (UTC)

I just sorted about 600 stubs to clear the slate again. —LrdChaos 06:16, 17 March 2006 (UTC)

overnight we seem to have got about 800 new stubs! BL Lacertae - kiss the lizard 02:00, 19 March 2006 (UTC)

I'm doing a wee bit of stub sorting tonight. Won't get the whole backlog done though, as these pesky "sleep" and "job" things get in the way. Panchitaville 04:31, 21 March 2006 (UTC)

It's a little boggling to have so many show up so quickly. Anyone worked out "where" they've come from? Are people like the above nay-saying anon, and those on SPUI's "petition", not using any sort of sorted type? Or... hrm, I notice quite a number of them are being automatically stub-tagged as very short, by User:Bluebot. Perhaps a case of what AWB maketh easier with the right hand, gives us more to do with the left! Alai 17:25, 21 March 2006 (UTC)

Yes, it's the work of a bot (at least 95+% of it, anyway). There was a secondary bot adding stub tags to articles and the occasional image page as well, but it didn't tag nearly as many because it was mainly fixing typos. Now if only a bot could be made to categorize these things... — Indi ^{[ talk ]} 15:19, 22 March 2006 (UTC)

{{Japan-myth-stub}} live

The Japanese Mythology Project has created {{Japan-myth-stub}} as per the proposal page (there was no opposition). I hope this is the correct forum to announce this. Please have a look and make sure it is properly sorted in the stub tree. Thanks! — BrianSmithson 17:33, 7 March 2006 (UTC)

Close enough. Normally you'd just note it with the proposal on WP:WSS/P. Both the template and category look well formed, too. Good work! :) Grutness...wha? 00:35, 8 March 2006 (UTC)

Can't beat copy and paste. :) — BrianSmithson 00:41, 8 March 2006 (UTC)

The Category:South American politician stubs looks very odd

I'm at my wits end with this one, and any help is *very* welcome. The stub template seems to work ok, but the category seems to bundle all stubs in one giant heap instead of sorting them by A, B, C etc. Both stub and category were modelled over similar stubs that worked well, so I really don't understand what's gone wrong here. Have any of you seen this one before? Valentinian ^(talk) 23:39, 23 March 2006 (UTC)

Yup. Problem was the sort key was a space, so everything was being sorted identically. ([[Category:South American politician stubs| ]]) Categories appear to be indexed by sort key, not numerically, so anything beyond the first 200 is (temporarily) "lost".

On a broader point, I wonder if we should address the issue in the various pages that discuss coding stub templates, whether it's appropriate to use noinclude and includeonly stuff. Absent such a statement, it seems a lot of it gets added anyway, but not very consistently. Templates are excluded from the category, or sorted to the front (or not); "template categories" get added; mini-essays are written in noincluded. Which of the above do we want to encourage, which to discourage, and which to take no stance on? For my money: top-sorting the template seems potentially OK (though it does complicate the code, and can have nasty effects if done wrong); the rest I'd be happy never to see any again. Omitting templates for categories isn't good, and if especially bad if there isn't a link to the template from the category page itself. Stub-template-categories are pointless (and CFD seems to agree). Essays should go on category pages. Alai 02:24, 24 March 2006 (UTC)

The solution, btw, is to change the above fragment to [[Category:South American politician stubs]]. I believe that you don't need to do the null edits to all articles now. Conscious 05:28, 24 March 2006 (UTC)

Yes, I noticed that a couple of weeks ago. The updates aren't quite immediate, and I've observed thm "rippling" through a category over a matter of minutes, so I imagine the underlying mechanism is essentially unchanged, but there's an additional layer that propagates them in a similar article-by-article way to the null edits. Alai 07:30, 24 March 2006 (UTC)

Thanks for your help. I don't know how I managed to miss that one :) Valentinian ^(talk) 10:58, 24 March 2006 (UTC)

Double-stub everyone

I realize there are some people still enamoured of the quaint notion that there should only be one stub tag on each article, but I wonder if we should go further with our guidance on double-stubbing people. Almost every biographical stub should really have both a nationality stub-tag, and a type relating to their main notability, generally an occupation. Indeed, the whole biography hierarchy is organised on those two bases. Single-stubbing of people leads to inconsistency, where some people are only classified along one axis, and others only along another; and makes subsequent resorting or resplitting harder (for example the scads of US-bios that are actors, military, politicians, businesspeople, but not tagged as such, or likewise for existing occupation stubs not yet split out by country). Would anyone else be in favour of adding this as an open task/strategic objective here, and delicately hinting at WP:STUB that it's not such a bad idea? Alai 05:57, 24 March 2006 (UTC)

Agree, but where an occupation has been split by nationality, for example {{Italy-singer-stub}}, only one stub tag is necessary. --Bruce1ee 06:20, 24 March 2006 (UTC)

Absolutely. I should have said to be more accurate, "stub everyone in such a way as to indicate a nationality, and an area of importance". Alai 07:26, 24 March 2006 (UTC)

I think this is a great idea for any stub supercategory that has been split orthogonally. I'm having difficulty keeping track of struct-stubs by nationality because the continent-struct-stubs keep being replaced rather than augmented with things like stadium-stub and bridge-struct-stub. Double-stubbing in these cases is a very important measure IMHO. Grutness...wha? 08:01, 24 March 2006 (UTC)

• Support per nom. --Mais oui! 08:55, 24 March 2006 (UTC)

• Sounds good, do you think we need guidance when there are 10 stubs as well? ;-) Martin 09:45, 24 March 2006 (UTC)
  • Yikes! I think that's a record! Grutness...wha? 10:24, 24 March 2006 (UTC)
    • Though like the Guinness Book of Records, I think we should avoid keeping track of records where setting it is likely to be hazardous to their health (or in this case, wikipedia's). Alai 19:15, 24 March 2006 (UTC)
• Support per nom. Valentinian ^(talk) 11:01, 24 March 2006 (UTC)

Consensus, and the deletion of "discovered" stub types

A new stub type going through the proper proposal procedure requires consensus to create. However, AFAIK, a stub type that was not created after going through the proper channels requires consensus to delete once it is "discovered". This seems a little perverse - effectively, it means that a borderline case of a malformed or unnecessary stub type increases its chances of survival by avoiding the proper channels. Obviously AFD, CFD etc should always require consensus to delete. Stub types for deletion is different because there's no obligation to ask for permission before creating a new article or category; stub types are only useful because there is a hierarchy and system that they should slot into. Would it be sensible for there to be a reversed burden of consensus for deletion (i.e. consensus is required to keep) for a stub type that skipped the proposals page? TheGrappler 14:44, 25 March 2006 (UTC)

It's somewhat perverse, yes, and certainly creates perverse incentives. Probably the only things that stop this from happening more is that, a) it'd be a shedload of work to do this on a large scale, and heartbreaking to have it all reverted (as people are never slow to poiint out after they've done so unilaterally); and b) surprisingly, most people are in fact not complete jerks, and are likely to make a good faith attempt to make nice with the stub-sorting project, where what they're going is indeed stub-sorting.

I suspect it'd be problematic to change. Stub creation is governed by "mere guidelines" (in the form of the WP:STUB page), and an even merer Wikiproject, in the form of this page-cluster -- and some people find even that much excessively burdensome. Deletion, OTOH, is a matter of policy. Establishing a "consensus to keep" standard on SFD would require we either on the one hand, make a formal policy proposal (and wait for the fur to fly); or, change it after only local discussion and consensus (among "the stub people"), then start implementing it (and then wait for the fur to fly even higher).

I'm not sure we've ever defined in numeric terms what our consensus threshold is to be. I know at times I've been seriously tempted to "re-weight" votes (to the detriment of the creator, their chums, and other "keep it because I both like it and find it useful, and I have to Perfect Right(TM) to 'vote' to ignore guidelines"). OTOH, the people closing the debate are generally the same people arguing adamantly to delete the things in the first place, so that risks looking over-cosy if done too liberally.

On balance, I'd favour we do one of the following. Firstly, we could "policify" WP:STUB, modifying or refactoring as necessary, to put that and SFD on more of an even footing, and establishing that the naming conventions, and the size criteria have that force. (I'd suggest we not try to make the Proposals page "mandatory", as people will probably see that as especially "unwiki", and personally, I think that if an unproposed stub is otherwise fine, we've nothing to complain about anyway.) Secondly (and either alternatively or additionally) we (try to) could establish speedy criteria to back up some of the more common problems, like undersized and obviously misnamed types. If we end up with the situation that unproposed and obviously problematic stub types can be deleted and renamed -- despite the "creator and chums" effect, and speedily or otherwise -- I'd be satisfied either way. Alai 06:25, 26 March 2006 (UTC)

I presume this ugly, intrusive beast (which would be excellent on the talk page) is an example of the problem:

Many MEP stubs can be expanded using the web site of the MEP. See [1], [2] and the MEP's group site. For a list of already expanded articles, see here.

BTW, wouldn't it be simple to write stub templates that are properly spare when used in the main namespace, and include instructions like the above when (also) used on the talk page?
--Jerzy•t 04:06, 7 April 2006 (UTC)

It would except for one small point - stub templates are never used on talk pages. Why mark an article twice?

WRT the main question, though, I'd be overjoyed if Alai's suggestion - in some form or other - were done. However, there are more than enough users who already accuse people involved with stub sorting as being "stub-nazis" or similar - any move to make it easier to detele stubs that haven't been proposed is likely to lead to howls of protest. Although there is no ill-will or bad faith in 99% of stub creation that hasn't gone through "due process", there are already a few renegade wikipedians who use stub creation as a method of making a point. This would only stoke up their sense of righteous indignation further. For that reason I urge extreme caution.

As to the weighting used for keep or delete, in the majority of cases that come through SFD it is fairly obvious. As far as the others are concerned, it should be remembered that deletion process pages are not voting pages per se. They are pages for discussion. This is the reason VFD was changed to AFD several months back. Because of this, the actual numerical value of comments is often far less important than the arguments of the voters. If a "vote" was 4 keep, 6 delete, but with valid and pertinent reasons given for keeping, I'd be far more likely to close the vote as a keep than if it was 5-5 with all the reasons for keeping being frivolous ones. In an ideal workd, I'd say 67% delete=delete, 50% keep = keep, anywhere between the two may require keeping the discussion open a bit longer to see whether there are any new opinions.

Grutness...wha? 08:49, 7 April 2006 (UTC)

That's very reasonable -- in theory. In practice, if we had five "votes" to delete that were brilliantly reasoned in terms of the WP:STUB guidelines, and three were "I like it and find it useful despite it being three articles in size, a cross-categorisation, recklessly narrowly scoped, and badly named" (I exaggerate only by way of condensation), we'd still get "stub-nazi" gibes if we went ahead and deleted it. (I'm certainly very reluctant to do so if I'm the nominator, or have been characteristically loud-mouthed in arguing for it.) Alai 23:17, 8 April 2006 (UTC)

Help me find a stub cat

Tried and failed to find a stub category for this article: Stop, drop and roll. Ideas, anyone? - the.crazy.russian (T) (C) (E) 02:09, 26 March 2006 (UTC)

I was about to suggest {{single-stub}} until I discovered you didn't mean the song! {{health-stub}} is probably closest, but that isn't really that satisfactory. The stub types cover about 99.99% of possible articles. This might just qualify in the final 0.01%. It might have to stay as just {{stub}} for now. Grutness...wha? 02:36, 26 March 2006 (UTC)

It's inevitable this will happen occasionally, due to the somewhat "bottom up" way stub types are created, as against the main category system. If we had higher-level types like "safety-stub" or "health-stub" (which do have perm-cat equivalents), which in theory would normally consist entirely of sub-types, we'd have greater coverage of cases like this. I suspect they're not that uncommon, but the "majority of the minority" that would ideally have a more general type are crowbarred into a more specific one without too much of the old Procrustes being employed.

It should be noted that the main cats are not without their 'issues' at the higher levels; if one asks, "what articles are underneath each of the 'top ten' categories", the answer is "all of them, under each". And that's to say nothing of inclusion loops. But that's another day's -- and another wikiproject's -- work. Alai 03:07, 26 March 2006 (UTC)

Compact list of stubs

The stub list is rather long, so I went creating a more compact list of all stubs, with only the specific relevant information needed to use them: Wikipedia:WikiProject Stub sorting/List of stubs. _→AzaToth 19:05, 28 March 2006 (UTC)

Yet another list to keep updated. It's also unreadably wide. Can we get rid of it, please? Alai 21:51, 1 April 2006 (UTC)

We already have enough trouble keeping the current lists updated, so we really don't need any more administrative work (well, if we had say 50 more stub sorters ...) Valentinian ^(talk) 21:56, 1 April 2006 (UTC)

Question?

Is this an actual policy of wikipedia or a guideline? I see nothing that indicates that this is anything more than a project that editors may or may not choose to follow. The process of proposing a new stub cat seems a bit red tape-ish. Please point out the errors in my logic. Cheers. youngamerican (talk) 17:16, 29 March 2006 (UTC)

There is no error in your logic. But they are nice guys really, and it only takes a few days, even one day, to get a good stub approved, so you may as well humour them and follow their procedure. They really do do an excellent job and deserve a lot of thanks and respect. --Mais oui! 17:38, 29 March 2006 (UTC)

Thanks. I have no problems with "humour"ing them, per se, I was just curious as to whether I would be doing so out of a choice to show deference to their hard work or because I actually had to. Cheers. youngamerican (talk) 17:50, 29 March 2006 (UTC)

It's only a guideline. There are good reasons for it, though. Consider that, even with people proposing stub types (which most people do) there are already 1500 or so different types of stubs. Those types - in the vast majority - all have easy-to-work-out names that conform to a specific naming pattern, are all formed so that they work in the same way, and all lead to stub categories that parallel "main" categories. The vast majority of them also conform to a hierarchy so that we don't have vague or overlapping stub categories. All of them (should) have the sort of numbers of stubs which will leave editors with plenty of work to do but not with so many stubs as to baffle them. To keep all that running smoothly requires someone to double check everything and make sure that new stub types work as well as those already in place. WP:WSS aren't megalomaniacs wanting to pwn Wikipedia's stubs (well, most of them aren't :) - it's just a case of wanting to keep this monster of a system running as smoothly as possible. Also, since it's the stub sorters who do the majority of the stub sorting, it's good for them to know what categories they should be sorting them into! Grutness...wha? 01:46, 30 March 2006 (UTC)

There are good reasons for many pages that are "only" guidelines; the manual of style, the reliable sources guideline, etc. So it rather depends on where one sets the bar for "may or may not". Alai 13:15, 2 April 2006 (UTC)

Stub sorting proposal

• If you are putting a {{"any_type"-stub}} on a page, place it two paragraph's (¶, pilcrow) (or a Newline) under the last line of text, for spacing.

I would like to ask other users (stub sorting users) if they could view my proposal, change it a bit, and put it on Wikipedia:WikiProject Stub sorting#Stub sorting methods Genereal Rules.

I have added this because stubs added one line after the text, are very close to the text, and it's easier to read if it is a bit spaced. This is simply for esthetic purposes, though this is an encyclopaedia it should also be pleasing to the eye, or it will be repulsive to readers.

Example, one paragraph:

Discography

• Album (2000)
• Album2 (2003)
• Album3 (2006)

or, two paragraphs:

Discography

• Album (2000)
• Album2 (2003)
• Album3 (2006)

You see the difference!

The example is related to music because I mostly do music related articles, but it's the same situation in any type of articles. For any questions or comments, please contact me! Death2 16:58, 31 March 2006 (UTC)

I really rather not see any instructions of this sort on the project page. We get enough flak for perfectly reasonable requests as "instruction creep" as it is. The point of stub-tags has very little to do with aesthetics, anyway: one might argue that a bit of ugliness is an incentive to expand the article, to get rid of it. Alai 21:48, 1 April 2006 (UTC)

Spacing and other related layout should be handled with CSS, not by inserting redundant whitespace. It's unfortunate that with the default style on, the stub template appears too close to the previous paragraph (I don't know the reason to this). This is what an extra newline produces in the final XHTML page: "<p><br /></p>". That's very ugly too from another point of view. Wipe 02:04, 26 July 2006 (UTC)

An alternative to stubs

Not sure if this is the right section, but as there are problems with stubs and stub-sorting, such as an article being categorized under several stubs (which can cause many different stub templates at the bottom of the page; example), requiring a lot of time and wasted resources, and different-sized images for stub templates (e.g. RC-stub image is much larger than India-stub image), I'm offering a suggestion:

I'm not sure if this is even possible programming-wise, but since all (or at least the great majority of) articles have categories, what if stubs were just signified in categories? The category pages maybe would then list the article with a bolded "s" similar to an "m" for minor edits or an "N" for new pages.

For example, Kinosaki District, Hyogo is under Category:Districts in Hyogo Prefecture, Category:Dissolved municipalities of Japan, and so on. On the category pages, Kinosaki District, Hyogo would have an s beside it to signify it's a stub. This way, instead of Hyogo location having its own stub page (Category:Hyogo geography stubs), categories themselves would show which articles are stubs.

This has several advantages:

• Articles will no longer be categorized under more than one stub. The only stub template will be the standard "This article is a stub. You can help Wikipedia by expanding it" which would somehow create the s thing beside article stubs on category pages (again, not sure if this is possible).
• People would spend less time (actually no time) tediously stub-sorting and more time actually contributing to articles.
• There will only be one stub template image, thus eliminating image inconsistency:

Here, the dome of St. Peter's Basilica is almost three times as big as the flag of India. This is awkward, to say the least...

--3345345335534 03:52, 2 April 2006 (UTC)

At first it does sound like a nice idea, simply having a code next to items in the categories indicating stub articles. But the major problem with that is that a large proportion of stubs have no category - probably 90% of those that appear in Category:stubs. It's often the stub sorters who add the categories in the first place. So no time would really be saved anywhere, and many things which arrive here simply marked with stub would never appear in any category, because stub sorters wouldn't be around to categorise them - in other words, they'd be lost to editors. Another problem is that there are currently closing in on 250,000 stubs. If all of them were marked with one template it would not just cause slight grinding of the servers but would likely cripple them beyond all repair. As for image inconsistency, it's no big deal. Let's face it, if you're worried because it makes the article uglier, that's what a stub template is designed to do to some extent. we're trying to get people to improve the stubs! As regards spending less time stub sorting and more time working on articles, most of us stub sorters actually spend more time working on articles than stub sorting (I'm in the process of getting what was a one-paragraph stub on the Catlins up to FA nomination standard). I doubt many of us would work more on articles if there wasn't stub sorting. So basically: nice idea, but not really practical. Grutness...wha? 08:15, 2 April 2006 (UTC)

---

But that is saving time, isn't it? Instead of categorizing an article under a certain stub, then coming back and adding categories to it, why don't you just add the categories then and there? Why list article "A" under stub "B" then come back and add category "B" when you can just add category "B" without first adding stub "B"?

For example: Applestone, it says he was a sculptor. I've added the {sculptor-stub} to it, and now its listed under Category:Sculptor stubs. All this is redundant, since I've also added Category:Australian sculptors to it. If I add the standard stub template, Category:Australian sculptors would then have an s beside Applestone to show it's a stub. People who look to expand stubs can just go to Category:Australian sculptors and look for the s, instead of going to Category:Sculptor stubs.

So essentially, you're just skipping the unnecessary step of categorizing the article under a stub. --3345345335534 16:22, 2 April 2006 (UTC)

We don't add the stub then come back later and categorise. It's all done in the same edit, and it's the categorising that takes the time, not the stubbing. Have a look at the stub-sorting guidelines and you'll see that stub sorters are supposed to add apppropriate categories at the same time that they sort the stub. A dedicated stub sorter will already know a large number of the stub templates - they are unlikely to know more than a small number of the main categories in wikipedia. So currently, when a stub appears in category stubs, your average stub sorter takes five seconds to add the appropriate atub template, then a couple of minutes trying to find the appropriate main category. The whole process takes maybe 150 seconds. Just adding the template would reduce that time by 10 seconds - assuming there were people doing it, which if there was no stub-sorting wikiproject, there wouldn't be (uness a separate parallel wikiproject was set up and caught on). So your proposal would save about 6% of stub-sorting time if the stub-sorting project still continued, or would leave hundreds of uncategorised and unstubbed articles if it didn't. And it would cause enormous server drain, due to the simply phenomenal number of stubs that exist that would all need to be marked with one template, (i.e., {{stub}}. Wikipedia's servers were severely affected a year and a half ago when there were 10,000 articles marked with {{stub}}. I doubt they would operate at all with 250,000 articles marked that way. So although it sounds a nice idea, it's not worth it. Grutness...wha? 05:41, 3 April 2006 (UTC)

Help!

I'm trying to get more involved in sorting, so I am attempting to learn to create approved templates - South Asian history in this case ({{SAsia-hist-stub}}) but it doesn't seem to be working like it should according to the creation guide. Request backup, please. Aelfthrytha 01:15, 5 April 2006 (UTC)

What's not working about it? -GTBacchus^(talk) 01:18, 5 April 2006 (UTC)

I've gotten to the part of creating the category Category:South Asian history stubs and I can't get it to show up under Category:Asian history stubs as its own subcategory. Although, somehow, I managed to get it to show up as a subcategory of...itself?Aelfthrytha 01:21, 5 April 2006 (UTC)

Found it. It was in the {{Stub Category}} template syntax. In the "category=C" part, you aren't supposed to fill in the name of the stub category itself, but the name of some non-stub category that you want to add this stub category to. In this case, there is no Category:South Asian history or Category:History of South Asia, so I just added it to Category:History of Asia. Does that fix it? -GTBacchus^(talk) 01:41, 5 April 2006 (UTC)

Yes, except it'd be nice if it showed up in Asia-hist-stub as an individual category, too. That was the biggest thing I was trying to figure out. Thanks! Aelfthrytha 01:48, 5 April 2006 (UTC)

Hmmm. You mean you want Category:History of Asia to show up on the page Template:SAsia-hist-stub? You can just add the category to the template page, but I'd put <noinclude> tags around it to keep that category from getting automatically appended to every page with the stub tag on it, which wouldn't be ideal. -GTBacchus^(talk) 05:04, 5 April 2006 (UTC)

Multiple Stub Tags

Question. If a stub could fit in more than one section, is it better to give it two stub tags, or choose one so that the page looks nicer? On the one hand, having two tags would help it get unstubbed faster, but on the downside it would ruin the page. --Xhin 05:28, 5 April 2006 (UTC)

Two, and even three stub tags are quite the norm these days. If it's a Bulgarian writer, and we don't have {{Bulgaria-writer-stub}}, then use {{Bulgaria-bio-stub}} and {{Writer-stub}} and put the article into Category:Bulgarian writers -GTBacchus^(talk) 06:06, 5 April 2006 (UTC)

Yes, the standard way is to give two stubs unless there is a "complex" form available. As you said, having two tags would help it get unstubbed faster, since more specialist editors will see it. As to "ruining the page", stubs are already usually ugly articles, a bit of short term further disfigurement to help them to grow faster isn't too big a problem. Grutness...wha? 07:36, 5 April 2006 (UTC)

Top-sorting of stub categories

Is there general consensus about top-sorting of stub (sub-)categories? If so, is there further agreement about whether we're using " " or "*" -- or indeed, anything else -- as the sort key (prefix)? I'll put in a weak vote for "*", and a strong vote for consistency either way. As the same applies to categories in general, I've also mooted this here. Alai 23:48, 5 April 2006 (UTC)

It depends - a blank space is often as useful or more useful - what I tend to do is use |*xxx for one type of split and | xxx for another when things are being split on two dimensions (have a look at Category:United_States_geography_stubs to see what I mean). Grutness...wha? 02:40, 6 April 2006 (UTC)

As long as the name itself is included, I don't think it matters either way. I've seen subcategories being sorted with just a '*' and while they all certainly appear under the '*' section, they appear with no other ordering (other than the order in which they appear in the database, I guess). --TheParanoidOne 05:33, 6 April 2006 (UTC)

Yes, I believe there is a consensus on top-sorting. I personally prefer using space for this, but some categories are top-sorted with an asterisk. And yes, as Grutness says, for some categories it's very useful to use both methods (for exapmle, films by genre and by nation). Surely, "| Stuff" or "|*Stuff" should be used instead of "| " and "|*". Conscious 05:57, 6 April 2006 (UTC)

I have no objection to using two characters for multi-dimensional splits (and I can certainly think of some that need it), but I'd strongly prefer to have some guidance on which it should be, otherwise, and in my recent experience, it ends up getting changed, left inconsistent within a category, getting changed again, etc, and other such petty annoyances. Can't we just pick one? (And I did note, as a prefix; I didn't suggest it be used as the entire sortkey.) Alai 14:15, 6 April 2006 (UTC)

WP:SC?

Another entry in the contest to work out what WP:SC is an abbreviation for? Alai 15:55, 6 April 2006 (UTC)

Hilarous... and given the usage of the term cabal, possibly speediable A6. But I'm quite willing to let FoN have his little joke :) Grutness...wha? 23:44, 6 April 2006 (UTC)

Categorization of section stubs

I have noticed that Category:Articles with sections needing expansion has become very large. Could we put section stubs into different categories depending on the article they are in, like article stubs? SCHZMO ✍ 21:37, 11 April 2006 (UTC)

I would suggest editing the template to change the category to [[Category:{{{1|}}} articles with sections needing expansion]]. This should make no difference whatsoever to the existing articles, but will allow you to use e.g. {{sectstub|Biology}} to categorise as "Biology articles with sections needing expansion". Joe D (t) 21:43, 11 April 2006 (UTC)

I've gone ahead and done this, but I'd be cautious about using the new system on too many articles - somebody may have issues or spot flaws. Additionally, if we do adopt this system it will require some coordination to make sure we don't end up with duplicate categories, or go to the other extreme and have a proliferation of categories with hardly any articles in. Joe D (t) 21:52, 11 April 2006 (UTC)

"Section stubs" aren't stubs. They are, as you point out, articles with sections that need expanding. As such, they're not dealt with by WP:WSS. Grutness...wha? 02:03, 12 April 2006 (UTC)

A problem across the Tasman

We have a template {{Australia-university-stub}} and a category Category:Australia university stubs. Unfortunately, some (to use a local colloquialism) nong changed the name of th caategory on the template, so now there are 92 stubs swimming in a limbo called Category:Australian university stubs. I've reverted the template, but should we (a) null-edit the articles, or (b) rename the category? Grutness...wha? 12:14, 15 April 2006 (UTC)

I think it is ok now. For whatever reason. Valentinian ^(talk) 15:29, 15 April 2006 (UTC)

Stubs templates and WikiProjects

I have a question and I thought this might be the best place to ask. Is it acceptable to add a link to a WikiProject in a stub template? (eg. {{digi-stub}}) Joelito 17:43, 16 April 2006 (UTC)

I've seen it, so far as I know there's no established consensus not to do it. Though really, it makes more sense to me to put it on the stub category page, where there's the space for it. OTOH, that's the least of this template's problems: the use of "qif" to put these articles into one of two different articles is horrible, and really should be shot on sight. (I've reverted the coding, and I'm putting the "semi-stub" category up for deletion.) Alai 18:35, 16 April 2006 (UTC)

There was some discussion here about a month ago that failed to get anywhere. Suffice it to say that some people don't like them and/or will remove them, for various reasons; but there seems to be no formal policy regarding them. Kirill Lokshin 19:19, 16 April 2006 (UTC)

I would like to propose some official policy regarding this matter. Joelito 21:14, 17 April 2006 (UTC)

I doubt you'd get one that worked. We can't even get a n official plicy on template creation, let alone what's actually in them. In any case, the two camps are very nearly equally divided - the wikiprojects want the links, many other editors don't. Grutness...wha? 01:03, 18 April 2006 (UTC)

Category:Hotel stubs

Is this an offical cat or one that just happened to have been created? I think this is already covered by the offical Category:Hotel company stubs. Vegaswikian 02:13, 21 April 2006 (UTC)

ISTR the idea of an actual hotel-stub was rejected when hotel-company-stub was made, since hotels ar already well enough covered by struct-stub. This one prbably needs sfd'ing. Grutness...wha? 08:34, 21 April 2006 (UTC)

new tool: StubSense

Here's a new toolserver tool, StubSense. Give it some random category, and it will list the most frequently used stubs for articles under that category. --Interiot 02:52, 21 April 2006 (UTC)

Cool. Valentinian ^(talk) 11:01, 21 April 2006 (UTC)

What's really great is that if this tool is used on a stub category e.g. Category:African politician stubs it's possible to see how many articles are double stubbed with e.g. {{Nigeria-bio-stub}}. This'll make it a lot easier looking for possible child categories. Valentinian ^(talk) 13:36, 21 April 2006 (UTC)

I've added a "list" feature, since I noticed that categories sometimes have many mis-sorted articles. For instance, looking at Category:Faculties by university in the United States, there were 29 articles with {{academic-bio-stub}} and 27 articles with {{US-academic-bio-stub}}. Most likely, most of the former could be sorted into the latter (I'll sort these now... it's just one of the clearest examples of category-level stub-sorting I've found). --Interiot 21:15, 23 April 2006 (UTC)

Category:Blogging stubs

I was doing a bit of a tidy up on a random vlogger, BowieChick and was looking for some stub to throw on it. I found Template:Vlog-stub and the Category as shown above. However, vlog-stub has like 5 things in, and is probably too narrow a stub type. Whereas there doesn't seem to be a generic stub for bloggers is there? I could look further, but I really don't care much for blogs or blogging anyway, but would like to point this out to those stub fetishists who keep the WP running. - Hahnchen 14:54, 21 April 2006 (UTC)

This query was moved over from Wikipedia talk:Stub - Hahnchen 20:48, 21 April 2006 (UTC)

I'm moving it again, to its proper place at WP:WSS/D. Grutness...wha? 03:48, 22 April 2006 (UTC)

A request about picture requests

Very many stubs lack pictures. Since the requested image procedure is underused (and, indeed, seems to be barely functioning) I have been working on a subcategorisation of Category:Wikipedia requested photographs by location, especially relevant for buildings, structures and places. Hopefully people will add their local area subcategory to their watchlist and keep an eye on it from time to time to see if they can help out. At the moment the system is in quite a basic form - the USA is subcategorised by state, everywhere else by country except Africa (likely to be broken down soon) and Antarctica. The trick to sorting an article in this way is to use {{reqphotoin}} or {{reqphotoin2}} in the article's talk page, for instance: {{Reqphotoin|Australia}} adds it to Category:Wikipedia requested photographs in Australia and {{Reqphotoin|Canada|the United States}} adds it to Category:Wikipedia requested photographs in Canada and Category:Wikipedia requested photographs in the United States. I am basically posting here for two reasons: (1) this sort of activity seems to be the thing that very many stub-sorters might enjoy, and (2) if stub-sorters did a little of this while stub-sorting (you're all likely to come across many articles fitting this description) that would be great too! If there is enough support it may even be worth setting up a dedicated WikiProject. Are there any stub-sorters who are interested in helping out with this task? Or others who wouldn't do it specifically, but may do a little whilst they are stub-sorting? TheGrappler 23:27, 23 April 2006 (UTC)

Cameroon-geo-stub

Per the United Nations definition of Middle Africa, could {{Cameroon-geo-stub}} be made a subcategory of Category:Central Africa geography stubs in addition to Category:West Africa geography stubs? — BrianSmithson 22:30, 24 April 2006 (UTC)

As you'll see from the wording in Category:West Africa geography stubs, we don't use the UN designations (although perhaps we should...?). I must admit bias, though - I'm not personally in favour of them because I feel Cameroon is culturally, politically and socially far more closely aligned with Nigeria and the rest of west Africa than it is with central Africa (my dad used to work in various parts of west Africa, so I have a little knowledge of the region). In any case, the way things are going it's a fairly moot point - give it a few months and most countries in Africa will rpobably have their own geo-stubs and the regional subcats will be unnecessary. There are a lot of African countries within a dozen or so stubs of reaching threshold. Grutness...wha? 02:41, 25 April 2006 (UTC)

What you say is very true for anglophone Cameroon but not for the formerly French-controlled part. South-central and southeastern Cameroon is much closer to CAR, Gabon, Equatorial Guinea, etc. than it is to Nigeria. As for the stub, there already is a Cameroon-geo-stub; it just doesn't sort into Central African geography stubs. It should, in my opinion, be sorted under both West and Central African geo-stub categories, thus satisfying both the British POV (it's West African) and the French one (it's Central African). — BrianSmithson 17:18, 25 April 2006 (UTC)

Fair enough - sounds reasonable for places which have separate categories. ISTR that the Georgia and Turkey categories are in both the European and Asia ones in much the same way. Grutness...wha? 00:49, 26 April 2006 (UTC)

"under-stubbed" people

I've compiled a couple of lists "un-double-stubbed" articles from two of the oversized people stub-types: the UK- and US-bio-stubs. These are lists of articles that have no occupation or notability stub type, and no permanent category either (other than things like date of birth, death, the dreaded "living people", and various meta-categories). If anyone is stuck for something to do (as if!), they might take a batch of ten of those, double-stub (or perm-cat) them, and strike that block from one or other list. If this is a roaring success, I can upload similar lists for other categories, and of course if anyone has any input on the format, or the basis for generating them, please fire away. Alai 04:42, 26 April 2006 (UTC)

where is this list? Grutness...wha? 07:00, 26 April 2006 (UTC)

They're linked above. (User:Alai/UK-under, User:Alai/US-under) Alai 07:29, 26 April 2006 (UTC)

(slaps head) I thought they linked to the templates :) Grutness...wha? 05:59, 27 April 2006 (UTC)

Double-stubbing using AWB

Alai recently encouraged me to try AWB, and it seems like a pretty useful tool. Pardon me for asking a stupid question, but is there any easy way to use the find-and-replace feature to change an article from using one template to using two - e.g. from {{SouthAm-footybio-stub}} to using both {{Bolivia-stub}} and {{SouthAm-footybio-stub}} ? My computer and I don't really agree on this one. Btw, don't bother fixing this example, btw, I'll do them by hand. Valentinian ^(talk) 23:05, 27 April 2006 (UTC)

Forget it :) It appears my computer and I have resumed diplomatic ties. The only thing that's slightly annoying is that simply using find-and-replace doesn't place the two templates on different lines so I do that by hand. If anybody knows of a more clever way, I'll be all ears. Valentinian ^(talk) 23:16, 27 April 2006 (UTC)

I'm not 100% sure what you're trying to do, but "\r\n" is what your computer will call a newline, I think that will help. Martin 23:21, 27 April 2006 (UTC)

I'm trying to replace one line of text with two (short) lines separated by a newline. Thanks for the tip. I'll give it a try. Valentinian ^(talk) 00:01, 28 April 2006 (UTC)

It worked like a charm. Thanks again. Valentinian ^(talk) 00:20, 28 April 2006 (UTC)

category heading

When im putting a stub category in another category, what letter should it be in the alphabetical categorization? thanks, --Urthogie 11:12, 2 May 2006 (UTC)

If you're putting it into a non-stub category, you'd normally use µ (although some people prefer to pipe it as "|stubs". If you're putting it into a parent stub category, you can use either a blank space followed by the name or an asterisk followed by the name - which you use will depend largely on what other stub categories are in there and how they're done (sometimes the two different types are used when two different forms of splitting are used, such as "by location' and "by type'). The question, of course, remains... what stub category are you categorising, and where to? Grutness...wha? 01:09, 3 May 2006 (UTC)

Hip hop stubs to hip hop.--Urthogie 10:49, 3 May 2006 (UTC)

need help finding a stub

Could anyone help me find a stub for rowing and/or boat races? I'm having problems finding where to look, before I propose one. thanks Mike 16:04, 4 May 2006 (UTC)

I don't think there is one. ISTR that there were proposals for both Yachting and Canoeing/Kayaking not that long ago, but I can't seem to find them anywhere at WP:WSS/P. Grutness...wha? 01:38, 5 May 2006 (UTC)

You're maybe thinking of {{Sailing-stub}}, which you nominated for deletion, and I deleted, unfeeling brutes that we are. Perhaps we should smoosh 'em all together as {{boatsport-stub}}, until such time as they're seen to be viable in finer grain categories (duplicate/redirected templates from more obvious names also a possibility). Kudos on the clearing-out of the sports-stubs, Mike. Alai 05:28, 5 May 2006 (UTC)

Sportbio: a fly in the naming guidelines ointment

I was trying to mentally compose some notes to add to the naming guidelines on current schemes, customs and practices, etc, etc, and it occurred to me: what to say about sportbio-stub, and children? Do we want to talk round that, and further systematise it as an exception, or should we rename the whole hierarchy in line with the more general -bio-stub scheme? I thought it better to flag this up here first, since you can be sure that nominating it as a SFR will produce the usual amount of reflexive "STRONG NO CHANGE WHATSOEVER, this is the way we've Always Done Things" votes. Alai 20:49, 6 May 2006 (UTC)

At the risk of being contrary, I think the sportsbio-stub system is the better of the two. The general rule is occupation-stub, followed by nation-occupation-stub. Where there is no one-word name for an occupation, the usual thing to do would be to create a concatenation from some descriptive term and "bio". The problem is that sports stubs do this by keeing the hyphen for the country split, some other occupations add in an extra hyphen. If you wanted total consistency you'd have to either drop the hyphen from things like academic-bio-stub or add "-bio" to things like explorer-stub. If we were going to do either, I'd favour dropping the hyphen. BTW, if you're looking for a bio-stub with hyphen problems that are definitely against our NGs, have a look at Hong-Kong-bio-stub! Grutness...wha? 23:03, 6 May 2006 (UTC)

But the current name isn't sportsbio, it's sportbio. :) I disagree with your analysis of what consistency demands (as does current practice for everything else): elsewhere we either have "occupation-stub", or "topic-bio-stub", so far as I know, the sports are the only place we have "topicbio-stub" (correct me if I'm wrong -- oops, I can correct myself, mathbio is also cited on the BGs, but it's only a redirect). The first and second seem perfectly reasonable alternatives, but the combination of the second and third on an entirely ad hoc basis is needlessly confusing. Yes, you could systematically go for the third, than the second, but that would involve changing even more types. Alai 02:05, 7 May 2006 (UTC)

I'd go for sport-bio-stub as it matches up with topic-bio-stub that you mentioned. --TheParanoidOne 09:03, 7 May 2006 (UTC)

Prussia geo stubs

Hey all, I just stumbled upon this: Kreis_Jarotschin and discovered there's a boatload of these things here: Category:Counties_of_Prussia. Some of these would be germany geo stubs, some would be poland geo stubs, and all of them are historical. I am soliciting suggestions on how to sort these. - CrazyRussian talk/contribs/email 16:14, 10 May 2006 (UTC)

These are pretty problematic articles. It seems like somebody is creating "Kreis ..." for a lot of areas in Poland, without checking of the information is actually present elsewhere, (see the talk page of Posen District), so {{Poland-geo-stub}}. Perhaps also: {{Germany-hist-stub}}. If this is carried over the Danish border it'll get rather problematic, since e.g. Kreis Hadersleben (German) is exactly the same as Haderslev Amt (Danish), only the language is different. Valentinian ^(talk) 16:38, 10 May 2006 (UTC)

I'd treat them exactly the same as other historical regions - combination of X-hist-stub and currentlocation-geo-stub. That's how things like Roman Provinces are deal with. Grutness...wha? 05:17, 11 May 2006 (UTC)

I've sorted them this way. Actually quite easy they all relate to areas in modern Poland. Valentinian ^(talk) 10:36, 11 May 2006 (UTC)

Why?

I'm curious about something. Do stub categories really attract experts to expand articles? Does anyone really look at the stub category pages for articles to work on? Or is it more just a tag to alert readers that the subject may not be complete? -Freekee 04:16, 15 May 2006 (UTC)

• I'm sure it serves that purpose, but obviously for that, stub sorting isn't required, just any ol' tag would do. I think it has some utility in regard to attracting editors to subjects related to to ones they're already interested in (not necessarily experts as such), but obviously that's hard to quantify. Another benefit of stub types is as a placeholder for permanent categories; "bulk stub-tagging" and subsequent re-sorting will get an article into the general vicinity of an appropriate category, as opposed to being left to languish until the initial batch of editors think up an exact categorisation. Alai 04:27, 15 May 2006 (UTC)
  • FWIW, a lot of editors on wikiprojects do use the stub categories for exactly this purpose, and it's quite clear from the fluctuations in numbers with every tally i do of the geo-stubs that a lot of articles do evebtually get expanded. Grutness...wha? 06:06, 15 May 2006 (UTC)

{{Mascot-stub}}...

...is busted. It was pointing to Category:Stubs, which flooded that cat, and now it's pointing to the non-existent Category:Mascot stubs. Would a maven plz fix it? - CrazyRussian talk/contribs/email 18:23, 15 May 2006 (UTC)

Classifying article as "stub"

What criteria are involved in deciding whether or not an article is a stub? Wikipedia articles are obviously not all the same length: a famous world politician is going to merit several pages, whilst a minor 15th century composer about whom little is known may be worth an entry in Wikipedia but is never going to make it beyond a "stub". Yet the "stub" tag will remain there for ever because the short paragraph is really all that is commonly known about him. Does this matter? Hikitsurisan 06:36, 21 May 2006 (UTC)

It's not ideal for that to be the case, but it does tend to happen to an extent, I'll grant. Another option in many cases would be to merge, though a suitable target isn't always clear (minor 15th century of <blah> genre/country?). If a topic has been well-researched, isn't deletable as insufficiently notable, and can't reasonably be merged to some larger article, then in theory it shouldn't be tagged as a stub (though if it's very short, others may somewhat reflexively add it back again). I'd try to avoid a long-term "full article" being less than 500 characters, at least. Alai 07:03, 21 May 2006 (UTC)

Presently far too many articles are classified as stubs, I think some people add a stub tag to any article that isn't finished -- which is the vast majority of our articles of course. The problem with this is that it totally defeats the point in actually using stub tags, i.e. how do stub tags help you identify very short articles when about 40% of all articles are stubbed? To me a stub is any article that is just a couple of sentences, we should be much bolder about removing tags from articles that are much longer than this. Martin 09:19, 21 May 2006 (UTC)

Some editors add a stub template to everything, but I'm pretty sure they're a minority. I find the situation a bit more complex. WP:STUB defines a stub as:

A stub is an article that is not long enough to be a full article. In general, it must be long enough to at least define the article's title, which generally means 3 to 10 short sentences. Note that even a longer article on a complicated topic may be a stub; conversely, a short article on a topic of narrow scope may not be a stub.

Another way to define a stub is an article so incomplete that an editor who knows little or nothing about the topic could improve its content after a superficial Web search or a few minutes in a reference library. An article that can be improved by only a rather knowledgeable editor, or after significant research, may not be a stub.

I pretty much try to go by the three-to-ten short sentences rule. If the article has this length and is clearly too short or incomplete, I tag it as a stub. But I'd like to hear more input on this one. Valentinian ^(talk) 20:07, 21 May 2006 (UTC)

That'd be pretty much what I do. OTOH, I'm possibly a little less blithe about removing stub tags -- and I'm sure I'm not the only one, give the 40% figure (which probably also misses quite a few that are very short, but aren't tagged at all). This is especially so if I'm "mechanically" restubbing things in bulk from StubSense- or dump-originated lists, using AWB, though if I get a "long stub" alert, the article's been perm-catted in such a way as to make the stub type redundant from that aspect, and there's not anything else flagrantly stubbish (like 90% of the article being a table, or a suspicious-looking splodge of unwikified text). If I'm editing the article "manually", I'd generally be quicker to de-tag it if it seems to have edges from "stub" to "start" (or better).

One thing that's possible is to automatically generate lists of long stubs, and have people examine them systematically for "tag lag". I believe BlueMoose was producing these at one point; if he's stopped, I could do so. CatScan also has facilities for this, if you find it working on any given day. Alai 23:31, 21 May 2006 (UTC)

BlueMoose was doing this - he had lists of long stub-tagged articles and short un-tagged articles. The problem with simply going by length is that in many cases some things are clearly stubs even when they seem very large if you're going by length alone. I regularly come across articles with one short sentence of text followed by an infobox, a list of examples, and a navigation box. That adds up to quite a length, but the basic article is just the one initial sentence, so it's still clearly a stub. On the other hand, we have things that clearly aren't stubs even though they're short. The article on the village of Croughton, where I used to live, is short and isn't a stub, simply because the village itself is very small. The same length of article on New York would be embarrassingly stubby. Grutness...wha? 02:47, 22 May 2006 (UTC)

Sex bias in bio-stubs

I'm concerned with the use of male icons in bio-stub messages, which are both androcentric and reinforce stereotypes. For instance, it seems to say that the person depicted in the image is what a "typical" Korean or "typical" American politician looks like, and reinforces the idea that women are a less perfect representation of a group than a man (in the same way that "man" used to be used to represent everyone). My suggestion is to prohibit the use of images of people in bio-stub templates. Sarge Baldy 18:44, 21 May 2006 (UTC)

This isn't a proposal for a stub type; WSS talk page, please. Alai 19:09, 21 May 2006 (UTC)

Apologies, I thought that "reorganization of existing stub types" might including these sorts of broad changes. Sarge Baldy 19:17, 21 May 2006 (UTC)

Rather than removing all the icons, perhaps more thought should be given to addressing the balance by simply replacing some of the male images with female ones. Grutness...wha? 02:00, 22 May 2006 (UTC)

Personally, I've always found the majority of sex bias issues rather silly. The icon isn't meant to represent anything but one of the more well-known examples of a group, to make a stub template look pretty. For example, Abraham Lincoln, who if I recall correctly is the US politician icon, is among the first people many think of when considering US politicians. I think you're making an awfully big deal out of an awfully small icon. Crystallina 03:52, 22 May 2006 (UTC)

me too - but although neither of us think it's a big deal, some people do, so it's still worth thinking about. And let's face it, if just adding an icon of Marie Curie to chemist-stub or Marian Jones to athlete-stub is going to keep more people happy, I say it's not too much to ask. Grutness...wha? 05:38, 22 May 2006 (UTC)

Well, I just thought an overall policy might be useful when you have stub icons such as this one: Template:Korea-bio-stub, generalizing an entire people as male. I mean, even without the overwhelming male bias on Wikipedia, can you really picture someone thinking to choose the depiction of a woman to represent the people of any country? Using a more "affirmative action" sort of policy would be much better than things are now, although it seems a bit more difficult to implement, and I don't think there's all that much of a value in the picture icons anyway; they often just look tacky. Sarge Baldy 18:11, 26 May 2006 (UTC)

Sure, I can think of a region that chooses a woman as a symbol of the contry. The value of the icons is that their meaning is more quickly recognized when an article is just scanned and not read in depth. Without icons, the stub notices tend to blend in with the article text. Slambo (Speak) 19:00, 26 May 2006 (UTC)

That's pretty common, actually: the whole abstract-nouns-are-female thing, essentially. It doesn't mean there's a presupposition that the (stereo)typical French person is female: she's a symbol of the nation, not of the citizen. Using Indira Gandhi or (ahem) Maggie Thatcher would be more in line with G's suggestion. Should we be using them at all: I've lost track, what's the current word from the devs and site people on the server load issue, for one thing? Alai 01:14, 27 May 2006 (UTC)

Sharing common code

Hi guys,

after fixing {{Italy-politician-stub}} I have noticed that all the other templates in the European Politicians category have similar problems. Many of them diverge into their own style, with variations in italicization and/or image size. Would you mind if I factored out all the common code and made each template just forward to the master one? Note that all these templates are already meta-templates, so factoring out common code can only improve consistency and make maintenance easier. —Gennaro Prota^•Talk 12:14, 22 May 2006 (UTC)

The standard flag size normally 30px, and I updated a very large number of national templates this standard around 1 month ago, and I haven't noticed any massive changes since then. I used the 30px as a guideline since this was / is the most used variation. Indeed, exceptions exist - e.g. the Norwegians, but in this particular case, it has to do with graphics problems for this flag. Other examples probably exist. I like the idea about a standard flag size, but the standard should remain at 30px to avoid more work than necessary. Regards. Valentinian ^(talk) 18:14, 22 May 2006 (UTC)

Btw, I'm pretty surprised if the code diverges as much as you say. For the simple reason that I've created virtually all the politician-templates you mention, and almost all of them were copied from the same original. I've never noticed any stub tag that does not have the same ID, stub, following the "recipe" listed at WP:STUB. Did I completely miss something? Valentinian ^(talk) 18:20, 22 May 2006 (UTC)

And copy-and-paste is indeed the error. Believe me, it is the worst enemy of programmers and anyone who has to maintain a code base: it creates a zillion copies of one simple thing and give them a zillion of autonomous lives. The creatures will be all in sync at the beginning but at some point in time they won't. Guaranteed. And if you need a change you have to do it in all copies (admitting you have a way to identify/find all copies). As to the ID, I guess you took it the other way round: I meant that we should *not* use the same id (actually, I don't see why we use an id at all) because when you have multiple stub tags in the same article they clash: ids must be unique within a document. —Gennaro Prota^•Talk 19:24, 22 May 2006 (UTC)

I'm no programmer, but I understood this one. I can only agree that copy-paste creates its own problems. I'm still somewhat puzzled why you've removed the italics from {{Italy-politician-stub}} since this makes the template rather unique, but this is irrelevant to the main point. I've done a sampling of around 15-20 stub templates and as far as I can see, all stub templates use the same ID, regardless of their topic matter. You seem to know a lot more about the technical side of the templates than most of us here. If this is a problem in need of fixing, it seems to be a universal problem for all stub templates. Unfortunately, we've been told that mass edits to the stub templates is not the most welcome behaviour since it apparently causes a lot of strain on the servers. For this reason, we need to be absolutely sure about which approach to take, so any new policy - if implemented - will only require 1 edit per template. Valentinian ^(talk) 19:59, 22 May 2006 (UTC)

The id was probably introduced to have a chance to switch stub tags off via CSS. Conscious 20:10, 22 May 2006 (UTC)

Hi guys, and sorry for the late reply. First of all I'm happy to see that I'm talking to smart people. I assure you there are tons of IT "professionals" who don't understand the evils of copy-and-paste. And last time I was on commons, I found a template which had different docs in three different places. When I asked what was the most up-to-date documentation someone peremptorily replied: "Don't touch them, they say basically the same and redundancy is good". Ok, back to the point... I'm a programmer (C++) but I'm no wiki-template or HTML expert. Removal of italics was unintended: I guess I removed the first two ' characters when removing   and then found an unmatched '' at the end, which I removed as well, thinking I had introduced it. Oh, let me also suggest to never let you frighten by someone's appearant competence: it could be completely false. I can explain what's going on, there's no need to believe me "on faith" :)

The   solution is faulty because it adds a space before the first word *only*; thus if you make the browser window small enough you'll get something like:

| this is
|a stub (no space before "a")

instead of

| this is
| a stub

IDs must be unique within a HTML document as per the HTML standard. Browsers usually ignore duplicated IDs when rendering the page but technically speaking the behavior in presence of duplicates is undefined. And that will cause troubles for Javascripts that try to find an element of the page by ID, of course. What Conscious says is already taken care of by the metadata class (try a print preview on the template). Actually I'm against hiding the whole message in print. Those who read the article on paper should still know it is a stub, IMHO. I also don't like when many stub tags are added to a single article, such as in Luigi Einaudi: you see it's a lot of duplicated info; I would rather prefer something along the lines of:

This article is a stub belonging to the following categories: Italian politician stubs • File:Liberty 1 by bencwright.jpg Liberalism stubs

You can help Wikipedia by expanding it.

When printing, I would prefer to short everything to "This article is a stub/you can help", without the table. I'm not a big fan of the images either.

As to the reason why there's no accepted width for flag images, I think it's because they have different ratios. Wiki-markup only allows you to choose the width: the height is chosen respecting the original image ratio, so it may end up being too high or too small for some flags. (unsigned comment by User:Gennaro Prota )

Well, for one thing, your proposal would definitely remove the duplicate "this ...-article is a stub ..." messages we've been criticized for. This in turn might remove some of the opposition to the double-stubbing of articles, we've encountered. I did notice the missing space before the A occationally, but I actually thought it was yet another bug in IE, so I guess I owe Bill Gates an apology. You are right about the flag size problem, and it would have been a lot easier if we could simply assign a standard vertical size instead of a horizontal one. Your proposal is very interesting, but I'd like to hear a bit more input from other stub sorters. To play the Devil's Advocate, the first issue that jumps to my mind is that a new mother of all (stub) templates would need to be fully protected since any edit to it might affect more than 100,000 articles (and this is a low estimate.) I'm a bit nervous that the server people might have a fit hearing about such a template. All in all, I feel this proposal merits a bit more thought (on my behalf anyway). I have no clear favourite regarding how the articles / stubs should look in print, but your example looks good as an on-screen version. Valentinian ^(talk) 17:37, 24 May 2006 (UTC)

A couple of questions - a) is there any reason why 30px is used for the flags, not 40px as with country-stubs and geo-stubs? b) is there any reason flags are used at all? Up until recently we've been using a famous politician for many countries, which I think is a far better idea; 3) is there any reason why the text of the template isn't italicised? Grutness...wha? 01:58, 23 May 2006 (UTC)

As far as I can see, the 30px is the most used version all around, but if 40px can be agreed upon, then by all means. Some of the European material used 25px, and I've changed them to 30px (I'm a bit usure about the Brits, btw.) I simply think it would be easier to make as few changes as possible. I just took another sampling of county- and geo-templates and the vast majority use 30px. 2) Using famous politicians as stub icons was my preferred version as well, but introducing them usually resulted in a few less-than-enthusiastic comments. Some editors felt it was confusing that the image was a different person than the topic of the article. Others disapproved for more partisan / historical reasons (see e.g. the edit history of {{Czech-politician-stub}}. {{SouthAfrica-politician-stub}} and the U.S. material seem to be uncontroversial, on the other hand. 3) No matter which code is used, the template should be italicised, so I'll changed that back. But the main issue still seems to be what to do with a "standard" code, and if all templates should use the same ID or not. Valentinian ^(talk) 09:06, 23 May 2006 (UTC)

V is right about his estimate being low: 400,000 would be closer. GP's correct on the SE principals, but there's no way this could be implemented using meta-templates: every time the master were edited, the server would fall over for a week (and the perpetrator would be banned for a year). The only way to do this would be do maintain a centralised list of template parameters, and when a change is to be made, to propagate it to the individual templates in a gradual fashion, by bot. Even that would have to be very tightly controlled, as a single stub template edit could be very "expensive" (bear in mind that UK-bio-stub is transcluded 3,000 times), which is likely far too much "democratic centralism" for the tastes of our numerous critics. Continued semi-controlled quasi-consensual anarchy is far more likely to be the order of the day for the foreseeable future. Alai 01:22, 27 May 2006 (UTC)

In that case, it seems like the implementation of any such policy - nomatter who appealing the theory sounds - would be contain all to much risk of sending the servers back into the stone age. It seems like we'll need to stick to a cumbersome but low-risk system. Valentinian ^(talk) 15:31, 27 May 2006 (UTC)

Not sharing common code

Yes, this is not a typo. I think a completely different approach should be used for stub marking. The current situation is a total mess where even experienced users find it difficult to choose the appropriate stub tag(s) for a given article. Actually, we already have categories, so why having "stub categories"?. If an article is, let's say, an Italy-related article and it is a stub then it is, as a plain logical consequence, an "Italy-related stub". Therefore, MediaWiki should manage everything. We should only mark the article as stub and the software should provide a way to browse either all stub articles or all stubs by categories. And it could use a special symbol (let's say [stub] or [s] to indicate stubs in categories pages. The current "solution" is absolutely unmaintainable and error-prone and wastes everyone time. —Gennaro Prota^•Talk 17:15, 24 May 2006 (UTC)

This comes up periodically, and indeed, there's certainly some redundancy between the two. But firstly, mediawiki doesn't manage any of this, so this'd have to go via the developers.

So?^(gp)

Secondly, if you think the stub sorting system is a total mess... have you seen the permanent categories lately? Stub-sorting is at least marginally easier than categorisation, as the range of options is a good deal smaller, and at least somewhat managed; and because tagging with a template is a little more convenient than with a category.

This argument is moot. Categorization is a concept on its own. What if someone then comes with something like {{Italy-politician cleanup}}, {{Computer software cleanup}} etc.? I simply think MediaWiki has been developed without any stub marking idea in mind. Fortunately that's trivial to add. About the granularity issue, it's up to the reader to decide how deep in the tree he wants to go. And if categories are a mess that's another problem.^(gp)

Lastly, it wouldn't achieve the same effect. Perm-cats are allowed to be small to the point of silliness (I've in the past nominated singleton cats for deletion, and had that opposed), and filtering for the stubs only would exaggerate that: you'd end up with a very deep, "stringy" system, very different from the situation of having only "viable" stub types with at least 60 articles in them each (supposedly -- naturally some people aren't happy when their "pet" over-categorised stub type is culled on grounds of mere size). Alai 22:39, 24 May 2006 (UTC)

Now you are totally inventing rationales, sorry.

-- (gp)=Gennaro Prota^•Talk 12:06, 25 May 2006 (UTC)

I am not "inventing rationales"; please assume good faith. I've also no idea what you mean by your reply to my second point; I think I've demonstrated that the issues are far from "trivial", but as you don't address any of my points, further comment would seem, well, pointless. Alai 14:35, 25 May 2006 (UTC)

It was not meant to be offensive. You are doing that in good faith, but you are inventing rationales, in the sense that what is allowed/what is not isn't written anywhere: you just said what you *imagine* to be the rationale for having a separate stub classification. And even if it is written somewhere, it is absolutely unfeasible, so it was an experiment which failed. As to the second point, I meant that if we want a separate tassonomy for stubs, why not having one for articles to be cleaned up too? And then why not a separate one for articles that have a bad punctuation? You see, this is an unmanageable approach. The fact that an article is a stub and the fact that it belongs to a given category are totally orthogonal (read: independent); thus the corresponding markers should be independentely applicable and usable. I also don't understand why each time a software modification is required everyone seems to be afraid. If Mediawiki developers refure to implement features which improve our work on Wikipedia we can always create a fork; MediaWiki is free software. Please, let me know if I have still not addressed all your points. —Gennaro Prota^•Talk 15:09, 25 May 2006 (UTC)

You haven't addressed the main concern - which is the viability of stub categories on the basis of size. You may look on it as inventing a rationale, but it is the main single reason why stub sorting exists. Otherwise we'd have done it by the method you suggest or similar ages ago. There is simply no point in calculating and marking stubs in cases where there may be one or two stubs per category. The whole purpose of stub sorting is to help editors to find stub articles that they can expand. To do that, it is no use to list the one or two stubs per category that need sorting - it is far more useful; to have reasonable numbers of stubs assembled into one place. Stub sorting does that by creating categories only when the number of stubs hits a reasonable threshold and splitting these categories only when the number of stubs becomes excessive. That can't be done by the methods you suggest, which is why similar suggestions have been rejected in the past. Look at it this way. You're an editor looking for stubs to expand. You might be able to expand 1/10 of the stubs around in a moderately broad subject area. Which is easier - to look through a category containing 100 stubs, picking out the ten or so you can work on, or looking through five to ten main categories each of which have one or two stubs before even finding one that you can edit? Grutness...wha? 01:19, 26 May 2006 (UTC)

I'm wasting my energies in a pointless discussion. Please, cling to your ideas. Given that stub categories don't even follow a consistent naming convention, 80% of the times I'll not know what name to use and I'll just attach {{stub}}. Then, maybe, someone else who has tons of time to waste will sharpen the category. Some of the people who contribute to Wikipedia subvert all the good rules of data processing and are even so pretentious to state they are right. What's more, they do that in a tone that almost mocks at the person who is trying to highlight their errors. What could we do? Either we should reserve maintenance tasks and design choices to people who understand how to maintain an enormous information base such as Wikipedia is (and that computers have been created to spare time, not to waste it) or we have to be contented with the a bloom of parochial approaches we already have and which don't help anyone. —Gennaro Prota^•Talk 17:08, 27 May 2006 (UTC)

Is that another way of saying that - rather than answering the points raised - you'd prefer to attack the people raising the points? The stub categories follow as logical a naming convention as we can - every time we find a new one that someone has created out of process with a dumb name, we try to rename it according to the standard stub naming guidelines. That we have trouble keeping up is not our fault. In any case, you don't need to know the names of the categories to add stub templates. All you need to know is the names of the templates - which again are as logically formed as we can make them (you should see the fights that have occurred here in the past with people who have arbitrarily named stub templates any olfd thing rather than try to follow and easily understandable pattern!) And no-one here has made any attempt to mock you. Then again, you haven't "tried to highlight our errors", either - all you have done is point out to us a system that would not perform the same tasks as we are trying to achieve. If you can come up with a method which fulfils all the requirements of stub sorting (which so far you haven't done), come back and we'll listen. Grutness...wha? 23:26, 27 May 2006 (UTC)

Transclusion on WP:WSS/P and WP:SFD

I have a proposal to use per-month trancluded pages for WP:WSS/P, like Wikipedia:WikiProject Stub sorting/Proposals/June 2006. Hopefully this will simplify archiving and reduce the size of the page you load when editing.

Another proposal is to change logging scheme for WP:SFD. Currently, closed discussions are cut-and-pasted to the logs. What about transcluded per-week logs? I think that per-day logs (similar to WP:CFD) would be clearly too short (sometimes there are 0-1 nominations per day). Per-month logs, on the other hand, are going to be too long (about the combined size of these two). We can also create templates similar to {{cfd top}} and {{cfd bottom}} to mark closed discussions. Conscious 07:47, 27 May 2006 (UTC)

The first, on /P, seems a clear win; it doesn't materially affect the appearance of, or procedures on, the page, and should make things easier all 'round. The second I'm not quite as sure about; it'd involve significant changes to how the page operates; in particular, actually closing discussions inside of a week, admittedly no bad idea in itself. Perhaps we should start off with the closed-discussion templates as a first step. Alai 15:17, 27 May 2006 (UTC)

I'd definitely support it on /P. Not sure it's really necessary on SFD - it's relatively short - but {{sfd top}} and {{sfd bottom}} would be worthwhile, I'd think. Grutness...wha? 23:14, 27 May 2006 (UTC)

Well, is there any sense it {{sfd top}} and {{sfd bottom}} if one has to move discussions to logs anyway? I mean, the discussion is closed if and only if it's been moved to the log. Conscious 20:03, 28 May 2006 (UTC)

Not strictly so; the discussion can be closed, and still be awaiting orphaning, or deletion, which currently involves c'n'p within the page. If we're going to go with transclusion, I'd also like to see the closure tags already in place and seen to be working smoothly, rather than changing several experimental variables at once, as it were. Alai 20:29, 28 May 2006 (UTC)

The reason I think they'd be useful is because of the number of times that discussions have been moved down to "old business" and been ready to deal with, then someone comes along and adds further comments. Most of the time the extra comment isn't helpful (some times, if it's a close call it may tip the scales one way or the other, but usually it makes no difference at all). Grutness...wha? 01:15, 29 May 2006 (UTC)

I've created the templates. Artists, feel free to change the colour. Conscious 07:01, 29 May 2006 (UTC)

looks good - but is there any way of making the text a little darker, or is it a standard "deletion template grey"? It's a bit difficult to read against that background. Grutness...wha? 10:43, 1 June 2006 (UTC)

The text is black, so it would make sense to change the background colour. Conscious 19:21, 7 June 2006 (UTC)

Once its in the box it appears as mid-grey on IE. Grutness...wha? 08:35, 8 June 2006 (UTC)

What about three-day logs, by way of an admittedly arbitrary compromise between the possibly-too-short per-day, and the possibly-too-long week? Alai 18:40, 7 June 2006 (UTC)

Well, first, do we agree that it's a good idea to have transcluded logs at all? Re your question, I'd favour weekly logs. In addition, they could use names like /Log/2006/Week 23, generated with {{CURRENTWEEK}}. Conscious 19:21, 7 June 2006 (UTC)

Agreement in principle's hard to factor out from agreement on the practicalities, since the whole point is what'd be the better in practice. In particular, weekly logs would mean that some items would necessarily go unlogged for that long, and half a week on the average (as opposed to the current "however long it takes", admittedly often longer). It'd also mean that any unclosed items for the whole week would hold up all those, making that both more likely, and making it affect more items when it occurs. So my current feeling is, "not if it means doing them on a weekly basis". Alai 20:22, 7 June 2006 (UTC)

And I just don't understand how 3-day logs would be implemented :) Conscious 06:13, 8 June 2006 (UTC)

It's not clear to me how much work said generation of names would save, but hypothetically, why not /Log/{{CURRENTMONTH}}/Period {{#expr:({{CURRENTDAY}}+1)/3 round 0}} or something along those lines? Alai 11:30, 9 June 2006 (UTC)

It's not really clear to me that it would be that helpful on WP:SFD, which isn't the largest of pages. I'd be far more pleased to see it used at WP:WSS/D. Grutness...wha? 11:37, 9 June 2006 (UTC)

I don't see that logging on any given schedule is much of an issue at /D (which is the real point of transclusion, not size). Alai 11:55, 9 June 2006 (UTC)

Size not an issue? You don't have a dial-up modem, by the sound of it! I start loading the page, then make a cup of coffee, come back and it's still loading. Size is a big issue as far as I'm concerned. On WP:WSS/D, where you really only need to see the latest items at the end of the page, individual month transclusions would be extremely useful. Grutness...wha? 12:31, 9 June 2006 (UTC)

That bears no resemblance to what I actually said. What /D needs is to be archived slightly more often than at ten-monthly intervals; that's hardly an argument for transclusion, especially if people continue not to archive. SFD, however, actually is logged on a semi-regular basis, but doing so by copying and pasting on an item-by-item basis is distinctly tiresome, and transclusion on a sensible basis could help with that. Alai 12:51, 9 June 2006 (UTC)

There's no doubt we have a problem with /D. It needs to be archived at the very least, many of the entries are resolved. But what about abandoning it at all in favour of a stubberg-type list? Alai and I maintain such a list, it is generated from each database dump and contains all stub categories not listed at /ST. Discussions at /D aren't generally very lively, and aren't binding. Now imagine we transfer this load to SFD (I mean, people take some categories from stubberg to SFD from time to time). What do you think? Conscious 13:02, 9 June 2006 (UTC)

I'd broadly agree with your diagnosis, not quite sure about the prescription. While I think the "unlisted list" is very handy, trouble is it's sufficiently large (approximately 450 entries) that it itself presents "management issues". Separate lists of each batch of new unlisteds from each dump might be more digestable, and would be handy both for spotting the "incoming", and as a means of tracking the undersized-but-might-grow contingent, several iterations along. We probably would still require some sort of discussion page, but if we move away from the not-very-successful model of a "tracking system" at /D, we'd probably be ahead on the deal. Alai 13:46, 9 June 2006 (UTC)

Yes, a good consideration is needed. For example, a list to watch shouldn't contain newest entries (newer that 2 months, for example) or should just be sorted by date of creation. I'm just throwing in an idea, maybe there's a way to get /D straight. Conscious 14:11, 9 June 2006 (UTC)

On third thoughts, I'm inclined to say that we should actually go with per-day transclusion and logging. It's potentially slightly more work, but equally one should be able to do a number "at one gulp" pretty readily, without the complication of a whole week being held up by one "problem case". Alai 03:39, 1 July 2006 (UTC)

We seem to have stalled somewhat: I suggest we implement some version of this, starting on the 1st August. If I'm left to my own devices, naturally it'll be done my way... I'll leave a note at WT:SFD, too. Alai 22:23, 14 July 2006 (UTC)

{{stubbox}}

What do we think of the above? The coding looks dodgy to me, given the unclosed div tag, and I'm not too sure about the visual appearance, but the general idea seems to be on the lines of something we've been discussing for a while. The main stumbling block seems to be that unless we start messing around with the coding of the stub types themselves, or duplicating same, there's still the same amount of spamming with redundant information (this is a stub; please expand; yadda). If anyone has any bright ideas on how to improve... Alai 01:50, 30 May 2006 (UTC)

Untagged stubs

I hestitate to do this, since we've plenty to do as things stand, but... Preliminary poking around in the db dump indicates over 10,000 very short articles not tagged as stubs. I'm going to try to produce a cleaned-up list, possibly after the next en. db dump, but before I do so I thought I'd better check a) are people ready for the shock, and b) exactly what criteria should be used? Bluemoose was previously using a size threshold of 350 bytes; I'll use the same, unless someone has strong preference otherwise. He was also excluding any page with a template inclusion; I'm more likely to exclude on the basis of category membership. In particular, anything that looks like a disambiguation page, copyright violation tagee, deletion or wiktionary candidate. More marginal would be categories indicating a lack of sources, expansion request, merger, cleanup, incomplete lists, wikification, context, verification, and importance. I'll include or exclude these or the basis of whatever feedback I get here. Alai 03:50, 30 May 2006 (UTC)

I'd exclude dabs, redirects, listdevs, and deletion candidates (CV or AFD) but include the rest. it'll be a long list and there are bound to be non-stubs on there, but it's more likely to get all the ones that are stubs. Grutness...wha? 05:13, 30 May 2006 (UTC)

Further investigation indicates about 7,500 of these without any categorisation, so that aspect's something of a nicety: plenty to be going on with, possibly excessively so. I won't upload those for the time being unless there's a major clamour, as it's by this stage about 12 days out of date, and I don't want to get a pile of hate-mail about whipping you into a frenzy of action(?) on the basis of possibly dud info (though I'd be surprised if it's changed that much). My crystal ball's a little misty as to when the next en. db dump will be (and no-one on meta is letting on); presumably not until after a de. dump has finished, which itself will take a number of days, and it's not yet begun; but I won't in any event be downloading it before the 7th. Alai 00:42, 31 May 2006 (UTC)

Category:Stubs rising fast

All hands to the pumps! Category:Stubs is back to almost 400 articles... Grutness...wha? 06:48, 30 May 2006 (UTC)

Misuse

Seems that User:220.253.3.186 has discovered a new way to vandalise using stub templates. Have a look at this. To paraphrase the great Alexei Sayle, "Stub templates are very important to this story - see how many you can spot!" Grutness...wha? 08:37, 30 May 2006 (UTC)

Icon discussion at VP

The following discussion at the pump about a mysterious glitch with stub icons has produced the answer to a question I've wondered about for a while. It'll be worth keeping an eye out for any other icons that have this problem!:

---

Putting the politics and economics stubs together indents the second one. Is this attributable to the size of one of the graphics?

RyanEberhart 01:41, 5 June 2006 (UTC)

We've had that problem with some stub icons but not with others. You might want to ask this question over at Wikipedia talk:WikiProject Stub sorting - because it's worth finding out which templates cause that problem and fixing them. I think it is a size thing, but I'm not technoboffin enough to know for sure. (BTW, I "substed" those templates to remove the categories). Grutness...wha? 05:33, 5 June 2006 (UTC)

It's the "left" in the image link for the first template (removed below). This causes the image to "float" left, allowing subsequent text (and images) to flow around it. -- Rick Block (talk) 01:47, 6 June 2006 (UTC)

Excellent. Thanks for that - I'll try to remember that if I see it happening again! Grutness...wha? 00:00, 7 June 2006 (UTC)

---

Shorten me

The template {{GuantanamoBay-detainee-stub}} is quite long, well over one line on my small screen. Ideas on shortening it are appreciated. - CrazyRussian talk/contribs/email 15:56, 11 June 2006 (UTC)

Thanks, Alai. Looks good. - CrazyRussian talk/contribs/email 18:31, 11 June 2006 (UTC)

(ec)And on mine too, at least at the default browser width. I've had a go. Alai 18:33, 11 June 2006 (UTC)

Stubsense down?

Looks persistently fried. Anybody know what's up? - CrazyRussian talk/contribs/email 00:28, 12 June 2006 (UTC)

• Wish I did. I'm guessing more problems with toolserver's database replication, but I have no more information than you. Asking on meta rarely produces much of a response. If anyone's really stuck, I may be able to run off-line queries to give similar results, if people can describe exactly what they want, and don't mind seriously ad-hoc turnaround times. Alai 18:11, 12 June 2006 (UTC)
  • I took a peek at Interiot's page, and it looks like they are attempting to reload the corrupted data to the toolserver. It looks like they've taken the toolserver's entire en-wiki database offline until they've finished with the experiment. Valentinian ^(talk) 21:17, 12 June 2006 (UTC)

Renaming "stubs" to "Ready references"

There is an active discussion at Template talk:Stub about changing the way stub templates are worded (originally the suggestion was to change all references to the word "stub", but that seems to - thankfully - have died down. The gist of it is that templates saying "This article is a stub" are not instantly understood by casual editors, who would be far more likely to understand something like "This article is short and undeveloped". Input from more of the old hands would be welcome! :) Grutness...wha? 08:36, 13 June 2006 (UTC)

tl and cl

Since I know how heavy a use this WPmakes of them, I thought I shouid point this out: [3] (For those who don't know, Brion is the Wikimedia Chief Technical guy...) - SoM 10:51, 15 June 2006 (UTC)

I wish he'd make up his f!@#$%^g mind. First he says "no problem", then he says this. How long before he gives a third opinion on it? Grutness...wha? 14:56, 15 June 2006 (UTC)

I guess we're all complete and total idiots. So much for assuming good faith. Crystallina 04:02, 16 June 2006 (UTC)

Since clearly being Wikimedia Chief Technical Guy exempts one from normal considerations such as consensus, civility, and answering a simple question in a straight way, I dast not speculate. I'm no strong objection to them being subst'd, but if it's not an efficiency issue (and I thought that the main hit here was in regards to 'editing' heavily-used templates), then it's a little pointless to flip this from "must not" to "must" in any particular hurry (cvue robots making tens of thousands of edits). Alai 18:08, 16 June 2006 (UTC)

Let's not fall into the trap of returning incivility with the same coin. I *presume* he just had a bad day. I couldn't care less if we stubst these themplates or not. Valentinian ^(talk) 20:35, 20 June 2006 (UTC)

Proposal: Category:stub templates

I was searching for a stub template name recently and it took a while to find it. I had a look for something like category:stub templates (like in our Turkish Wiki) but found nothing. I went to #wikipedia on IRC, had a chat and they proposed to ask a bot to do some work...

If one analyses for example Category:Animal stubs one needs maybe one Category:Animal stub templates category for all those stub templates listet there but it would be nice to have a bot do it because it may be way too much work to add a <noinclude>[[Category:stub templates]]</noinclude> (or even sub categories) to every single stub template. Any ideas? --katpatuka 10:07, 24 June 2006 (UTC)

(maybe better in Wikipedia:WikiProject_Stub_sorting/Proposals ?)--katpatuka 10:07, 24 June 2006 (UTC)

A user has tried this one before but opinion was pretty strongly against, so the categories were deleted again. I don't think the situation has changed since then. Valentinian ^(talk) 10:31, 24 June 2006 (UTC)

I think this would be fairly profoundly redundant; they're listed on WP:WSS/ST, an automatically generated list is produced by a script Conscious runs to detect the "unlisted" ones as well as the above, and they're included in the stub categories themselves (both rooted at Category:Stub categories, and comprehes. Yet another method seems unnecessary, work to maintain, and clutter in the templates. Alai 18:35, 24 June 2006 (UTC)

Stub Category templates

We have {{Stub Category}} and {{regional stub category}} to provide some basic boilerplate for categories. I'd like to propose a third {{Biography Stub Category}} to provide boilerplate that would be appropriate for all the stub biography categories. I have a proposed version at User:Caerwine/Template:Biography Stub Category that in addition to what {{Stub Category}} does, includes text recommending the three basic categories all biographical articles should ideally have, year of birth, year of death/not dead yet, and what they are. Any thought for either possible improvement or abandoning this idea? Caerwine Caerwhine 01:13, 25 June 2006 (UTC)

Seems a good idea to me. I think as well as a comment on categorisation, this might be a good place to note that occupation-based stubs types should also have a regional tag, and vice-versa. Alai 01:53, 25 June 2006 (UTC)

Commons stub pictures

Over on the Commons they have a category commons:Category:Stub pictures that has some nice pics that people might find useful for stub templates, especially the ones that mix a picture with a wiki puzzle piece. Caerwine Caerwhine 03:13, 25 June 2006 (UTC)

Centralised discussion of "undersized" types?

I'm wondering if we should have a designated place for "noting" that a stub type is undersized. At present, if a stub type is already on the list, or has been proposed, or has already survived an SFD, it's not really a "discovery" any more, though we could use that page regardless certainly; or else a section on the todo page (long-standing undersized types). I suggest this as it seems that often we take a "tiny" type to SFD, whereupon it's either populated, there's suggestions we might wait and see if it grows, or else there's protestations that it's soon to be. A less formal process might have similar effects, and perhaps with less agro on occasion. Alai 22:03, 29 June 2006 (UTC)

A couple of points - firstly, what you describe is a very similar thing that happens on AFD - articles taken there are either deleted or "saved" by sudden rapid growth, so i don't see that as too much of a problem. As for a list of small stubs, I though someone (actually I thought you!) kept a list of those on a user sub-page. If so, that page could easily become a de jure part of WP:WSS just by adding it to the WP:WSS category, same as I have with my geo-stub count and splitting lists. If necessary, mover the user subpage to an official WP:WSS pagename. Grutness...wha? 02:33, 30 June 2006 (UTC)

Yup, I do indeed (I assume you're referring to this, which is at any rate the most recent incarnation of much the same thing). I could certainly move it to the WSS project-space if people would find that useful and convenient. (Can't do much about the update rate, though: I'm at the mercy of whatever the heck is going on with the db dump.) That doesn't track creation date, whether there's a wikiproject, whether it's already been on SFD, etc, etc, so it's not a complete or integrated solution. I'm not suggesting types being populated while on SFD is a "problem", or otherwise a bad thing at all, I'm just wondering if there's a better way to get the same good result. Alai 02:50, 30 June 2006 (UTC)

Actually, reversing myself yet again, {{popcat}} pretty much covers this. On the other hand, might it be worthwhile splitting out the stub types, say with {{popstub}}? (With associated category, which one could of course then request to be populated...) Alai 22:36, 1 July 2006 (UTC)

I've gone ahead and "forked" this as Category:Underpopulated stub categories. Alai 06:45, 18 July 2006 (UTC)

Fooian X stubs vs. Foo X stubs

We have a mess here, especially in, but not limited to, UK and US stub types. I'd like to suggest the following additions to the naming guidelines.

1. If the parent non-stub category is Fooian X's that the stub category be Fooian X stubs.
2. If the parent non-stub category is X's in/of Foo that the stub category be Foo X stubs.

I realize that this won't matter much to Grutness since for some inexplicable reason, Wikipedia uses New Zealand rather than New Zealander as the Fooian of New Zealand in the main categories.

Anyway, this is nice and straightforward, and I hope it will attract the support of others. Caerwine Caerwhine 15:36, 2 July 2006 (UTC)

Well, Wikipedia's correct in that. New Zealand is one of those rare countries where the correct adjective is the same as the country's name. It's only the noun form of the people who live there that is different. I'm a New Zealander, that is, a New Zealand person, who lives in a New Zealand house in a New Zealand city. Oh, and support BTW, although it'll probably mean a lot of renaming. Grutness...wha? 06:45, 3 July 2006 (UTC)

I thought this for a long time, wondered whether it was all due to a peculiar technical rule :-) TheGrappler 10:42, 4 July 2006 (UTC)

:) BTW, another reason this should be done is that we're slowly getting more flak in places like CFD for the differences between stub ncategory names and non-stub category names. Things like this, for instance. Grutness...wha? 12:49, 4 July 2006 (UTC)

Strongest possible oppose. This would institutionalise the pointless flip-flopping we already see between for example, "France this" vs. "French that" on no rational basis, rather than actually do anything to fix it. Does anyone really think that Category:France buildings and structures stubs is an especially sensible name for a category? Why on earth should we utilise awkward-sounding names that would never fly in the permanent category space, to purport to be consistent with same? While not actually being so, of course, since we'd be rearranging the component words with blithe disregard to what's in any way a customary usage. To take the implications of this scheme on its face, if "geography of France" were renamed to "French geography", we'd then flip between from "France geography stubs" to "French geography stubs"? That makes no sense whatsoever. There has to be some internal logic (or indeed, any logic) to stub category names, beyond "a given part of speech appeared in a parent, let's use it somewhere or other in the stub name, after throwing away the prepositions that caused that word to be used in the first place". I'm frankly boggled Grutness would support this, having previously said exactly the opposite in at least one context, though perhaps in hindsight I shouldn't have been since we do have a lot of these "Awkward Attributive Noun geography stubs" kicking around at present. Alai 07:56, 7 July 2006 (UTC)

My support is more for the suggestion that we should try to somehow get the stub category names in line with the main categories than it is for the actual suggestion of "Foo X stubs"/"Fooian X stubs". The problem with importing the standard category names wholesale is that it would lead to some even more cumbersome combinations such as "X of Foo stubs". But the closer we can get things to consistency with the main categories the better. Grutness...wha? 11:05, 7 July 2006 (UTC)

I'd gladly support "somehow in line with" myself: on some issues, they're pointlessly wayward, both internally, and wrt the perms. Case in point would be the whole people/personnel/biography/biographical business, which is completely needless. Of course, the perms are often all over the shop, too, so this is trying to hit a moving target. I'd rather have internal consistency than external, which is in fact essentially what the perms do themselves: have rules for each "layer", and horizontal consistency within that (... on a good day...) rather than fully-vertically-integrated common usage, particularly on nouns vs. adjectives. Alai 02:27, 9 July 2006 (UTC)

Abolish stub types altogether

My argument is simply this: Abolish stub types. Articles would be tagged as stubs by any user, either just like they are now (eg {{stub}} appearing in the code) or perhaps by some other mechanism, such as Flickr-like tagging (see folksonomy). Then the articles would be able to be listed as stubs under the category (or categories) the article has had applied to it. If no category has been applied to the article then it will appear under an 'uncategorised' stub list.

This simply removes the problem of thousands of stub types doesn't it? reinthal 07:09, 3 July 2006 (UTC)

This proposal crops up occasionally and does sound appealing, but there are problems with it - notably that quite a lot of the time stub articles don't have categories and an uncategorised stub list would be extremely long (even if only 5% of stubs have no category - a very low estimate - that would mean a list of 20,000 stubs). See Wikipedia talk:WikiProject Stub sorting#An alternative to stubs for a recent similar suggestion. Grutness...wha? 08:24, 3 July 2006 (UTC)

That problem would only be temporary, though. Articles with a non-general stub but no categories were presumably tagged by someone who took the time to look up the correct stub for their article, but didn't bother to add a category. This proposal would essentially force people to add a category, and remove the redundant effort involved in giving an article a specific stub only to later add the categories that are clearly implied by that stub. At its most extreme, we could try to work something out so that putting {{stub}} in an article with no categories causes glowing red text 24-point text to appear at the top of the article that says "THIS ARTICLE IS UNCATEGORIZED. {{stub}} requires a category. Please add a category to this article along with the stub!", much like transcluding subst-only templates does now. Of course, that wouldn't work with the number of existing stubs with no categories we have... We could always decide on a few categories that are decided by each existing stub, and run bots to slowly turn them into generic {{stub}} while adding the necessary categories. This would be almost necessary in implementing this suggestion, anyway. Once those bots had finished running, the only things left in cat:uncategorized stubs would be what's currently in Category:Stubs. --Aquillion 22:54, 21 July 2006 (UTC)

This would be a great solution (and the only really reasonable one in the long run, in my opinion), but it requires major code changes in MediaWiki to implement properly, since MediaWiki does not support category intersections at the moment. If you can write up a patch that does it, great, but in the meantime, the status quo is what we have to use. -- grm_wnr Esc 17:13, 3 July 2006 (UTC)

There are several issues here: is a "quick technical fix" going to be available at some point; is it OK to get rid of some of the criteria of stub-sorting, like keeping stub categories within a certain size range, which the category-intersection model would make impossible, unless there was some after-the-fact way of fixing this up; and would such a system be more or less usable from the point of view of the "sorters"? None of these are clear at first inspection. I imagine we'll persist until they become moreso, or else the whole edifice collapses under the weight of the sheer amount of work required to prop it up. There's no question that there's much inefficiency built into the current sorting of sorting and re-sorting articles, even after they have permanent categories. Alai 03:01, 9 July 2006 (UTC)

"Stub category names should be guessable"

Can people explain exactly what their rationale, and exact criteria for "guessable" stub category names are? Who is being assumed to be doing the guessing, and on the basis for what body of knowledge? People working from the particular permanent category? Other stub categories? One or other naming conventions page? Without further elucidation I don't know what "guessable" category name is supposed to be, much less why they're desirable, in particular above and beyond other desidirata. Alai 06:04, 11 July 2006 (UTC)

Moving the Atlantic Ocean with a teaspoon

As you can see from the To Do page, we're not getting too far with stub sorting and indeed seem to be going backwards with every update bringing progressively more categories and stubs. Is there any way to fix this other than just "sort more"? Crystallina 18:06, 11 July 2006 (UTC)

For stub sorters? Probably not. For editors in general? Expand stubs until they are no longer stubs (and remove the stub notice). Simple. :) --TheParanoidOne 20:12, 11 July 2006 (UTC)

I'm seriously tempted to suggest redefining "oversized" to mean over 1000 articles in size... Alai 04:56, 13 July 2006 (UTC)

Hrm. On second thought and upon reading the edit summaries I probably should not have said anything at all, carry on. Crystallina 17:48, 20 July 2006 (UTC)

Wikipedia Integration: solution to some stubs

I have worked with a few individuals to form a project to eliminate poor stubs and duplicate content in favor of more comprehensive articles. I agree some articles will always be "stub" in size, but those that are suspect to development in more than 1 article for the same subject matter should be merged, and maybe split off again when deemed necessary.

WP:ʃ

Cwolfsheep 23:15, 12 July 2006 (UTC)

Syro-African Depression

is a quad stub. kzz* 21:45, 13 July 2006 (UTC)

Unfortunately this regions covers five countries and we normally stub geographical articles with one template per "affected" country, so this one could have had five. This method does look a bit stupid but is an attempt to make the article appear in as many relevant categories as possible. In cases such as this, using a template for each country seems to be only possibility to treat all countries equally. But it is a prime candidate for expansion. Do we have any experts around? Valentinian ^(talk) 00:09, 14 July 2006 (UTC)

The other option is simply to revert it to its region as a MEast-geo-stub. Grutness...wha? 01:22, 14 July 2006 (UTC)

I agree with Grutness. If the feature covers that many countries of the Middle East, it would be better to use the single broader-term stub. -Acjelen 14:15, 14 July 2006 (UTC)

I can easily buy that solution. The max. is probably around three to four countries, so this one might be a bit too much. Valentinian ^(talk) 00:14, 15 July 2006 (UTC)

I usually use a limit of four, FWIW. Grutness...wha? 01:55, 15 July 2006 (UTC)

I'd tend to concur. There may be circumstances where a convoluted structure of the stub types, and an unusual article argues for more stub tags, but a simple list of countries isn't one of them, nor is any similar use of "sibling" templates. Alai 03:35, 15 July 2006 (UTC)

A (suggested) new wheeze for dealing with articles double-stubbed into oversized categories

FYI, I've made a request for approval for a bot-task for replacing double tags with "consolidated" stub types. With luck, this will help somewhat with the re-sorting backlog, though it certainly won't be a complete solution by any means. Alai 04:36, 18 July 2006 (UTC)

Stub Class articles rearing their confusing head again

Talking of bot requests for approval, please note this. In extremis, what this could be is a stub-un-sorting bot, but what it really illustrates is the confused thinking about the whole "Stub-class" thing. Is "Stub-class" the same as "stub", or not? We were unable to get a straight and consistent answer to that when the question arose at SFD, with at least one person arguing to keep the two categories separate on the basis of being different (without really defining how, or addressing the issue of terminological confusion). This sounds like a possible trainwreck. Alai 16:12, 18 July 2006 (UTC)

I've added by 2¢ to that bot request... hopefully others here might do likewise... Grutness...wha? 01:39, 19 July 2006 (UTC)

Two changes related to "Stub-Class" vs "Stub". The first seems the most contentious as it has replaced a legitimate stub category with a Stub Class category. --TheParanoidOne 20:52, 20 July 2006 (UTC)

Said editor now seems to be merging Stub-class and stub categories, using stub-class on articles rather than talk pages (or indeed, on both), and generally creating a mess with them. While there's a degree of home-brew screwup at work here, I think it does also go to underscore the capacity for confusion from the terminological overlap. Alai 21:02, 22 July 2006 (UTC)

I've reverted these: the editor in question seems to think these are "artificial" distinctions (right, great idea having talk pages and articles in the same category, obviously). I sense this one will run and run, in one form or another, though. Alai 18:18, 4 August 2006 (UTC)

Wikipedia Integration

I've identified this project as a candidate for material to be analyzed by Wikipedia Integration methodology. Please feel welcome to offer suggestions and feedback. WP:ʃ Cwolfsheep 16:22, 22 July 2006 (UTC)

• Exactly what does this analysis (or indeed, methodology) involve? I see no discussion there of WSS, and the link to this project is amid links to such non-entities as Wikipedia:WikiProject Wikipedians for writing an encyclopedia. Alai 00:36, 23 July 2006 (UTC)

Tentative steps in bot-work

As well as merging double tags on stubs, I've also started using my bot to restub some articles on the basis of their permanent category, and parent stub type. See the current contents of Category:Non-profit organization stubs. This method might not find the most appropriate possible stub type, but it should at least find a notionally appropriate stub type. I'd be interested in hearing people's thoughts on this approach, and on what instances (if any, of course) they think it's appropriate to do this on, etc. Alai 03:05, 23 July 2006 (UTC)

• OK, this is now approved, so if anyone has any suggestions for to-do's for full-speed edits, please suggest away. Alai 05:03, 25 July 2006 (UTC)
  • One possibility is the clothing-stub/fashion-stub mess recently mentioned at SFD. Half the items marked fashion-stub should be marked clothing-stub and vice versa (and no doubt some should be marked with both). Grutness...wha? 05:44, 25 July 2006 (UTC)
    • "Ah, but which half...?" If you can suggest a "rule" for this based on the perm-cats, that may be a possibility. Alai 06:17, 25 July 2006 (UTC)
  • Well, that's my point. Any with a permcat of Fashion should get fashion-stub, any with a permcat of Clothing should get a clothing-stub. It won't completely sort them out, but it should improve both stubcats immensely. Grutness...wha? 08:12, 25 July 2006 (UTC)
    • Just trying to be as explicit as possible -- so I can blame you when it all goes wrong :). What about (perm-)subcats? Category:Fashion's a subcat of Category:clothing, but I could put all contents and subcat contents of "Fashion" in that first, and then the remainder of those with other subcats Category:clothing, say. Alai 15:10, 25 July 2006 (UTC)
      • This is now half-done: I've taken all the clothing-stubs with a fashion cat, and moved them over to fashion-stub. Doing it the other way around is a little more involved (I suppose that what we're looking for is fashion-stubs with another category that's also in the clothing hierarchy, but isn't also in the fashion sub-tree), but at any rate we should shortly be rid of the {{clothingstub}} redirect. Alai 06:00, 7 August 2006 (UTC)

new WPSS template

I've just created a new WPSS template for use at the top of category and template talk pages. occasionally WPSS has been tripped up by not knowing about discussion taking place on a template or category's talk page... hopefully {{WPSS-talk}} will reduce the chance of that happening in future. Grutness...wha? 06:28, 24 July 2006 (UTC)

Stub Sorting Award

Would someone mind generating some support for your award? Otherwise the proposal will get archived. --evrik 15:39, 22 June 2006 (UTC)

• I have humbly submitted a design for a Stub Sorting Barnstar. Please take a look! Cheers, ♥ Her Pegship♥ 05:27, 27 July 2006 (UTC)

I think it looks great :) SynergeticMaggot 08:48, 27 July 2006 (UTC)

• A stub sorting award proposal has been submitted by User:Kukini, and designed byUser:Pegship in WIkipedia:Barnstar and award proposals. After reaching consensus, the barnstar was approved and posted on WIkipedia:Wikiproject awards.--Ed 23:07, 27 July 2006 (UTC)

Image load on servers

I think a lot of us have had the impression that it was always better to use very "light" stub images due to potential load problems with the image servers. This post from WP:VPT (Village Pump, Technical) says that this is not a problem at all, since the image is rendered only once. Apparently, we can use any type of stub image that we like.

(copied from a post with the same headline)

Q: Are some images more processing-intensive than others? I was under the impression that image resizing and rendering was done only once (say, the first time an image is requested at ##px), so even if complex svg rendering is required, it wouldn't particularly matter. However, a user has expressed concern that some large images should not be used for stub templates because of their high server load. Is there truth to this? ~ Booya ^Bazooka 14:47, 29 July 2006 (UTC)

A: A large image is rendered into a thumbnail the first time it's used at a specific size, so a large stub image has the same load on the servers as a small stub image (assuming both were thumbnailed at the same size). The load is also much smaller than you might think, due to brower caches and proxies. There was a time (about a year ago IIRC) when a lot of stub images were removed due to server load issues (the image servers were not keeping up with the load); since then, new image servers were added and it's no longer a problem. --cesarb 16:28, 29 July 2006 (UTC)

So at least that is one less concern. :) Valentinian ^(talk) 21:52, 29 July 2006 (UTC)

• At least until the next time the image servers start being overloaded again. It's still a good idea if you have several servicable images of equal utility to choose from to pick ones that will keep the load down. Caerwine Caerwhine 17:25, 30 July 2006 (UTC)

What surprised me was that it seems that the servers generate a small thumbnail once and then uses this image rather than the larger file. Anyway, if I have to chose between two good images and one is a lot smaller than the other, I normally go with the smaller image. Valentinian ^(talk) 18:06, 30 July 2006 (UTC)

Image size for stub icons has never been about server load (although whether there are images or not was). Icon images are kept small primarily because having large images in a stub template draws too much attention to it and away from the article. That's the reason why a small clear stub icon is always preferable to a large clear one, especially when the image is vertical, since that is more likely to take several line widths - which beomes a problem when there is more than one template. Grutness...wha? 09:10, 31 July 2006 (UTC)

subst'ing stub templates

Does it say anywhere that stub templates should not be subst'ed? I've had a user telling me that I should be subst'ing all stub templates. If there is an official policy on this, I think it should be put on the project page. --Bruce1ee 11:31, 10 August 2006 (UTC)

This is the official policy: NEVER EVER SUBST STUB TEMPLATES. EVER. Martin 11:36, 10 August 2006 (UTC)

Actually the user (aka me) was saying that he (I) had been told to subst. Happy not to - it takes fewer key clicks. Glad there's a policy. (Where?) --Dweller 12:12, 10 August 2006 (UTC)

No harm done, really. It was pretty easy to fix. However, we probably need to write this rule somewhere easy to see. Valentinian ^(talk) 12:18, 10 August 2006 (UTC)

It's written up somewhere on one of the WP Policy pages as to which templates should be substed and which ones shouldn't - I'll see if I can find it. Grutness...wha? 14:18, 10 August 2006 (UTC)

It says on WP:SUBST, but that is a bit out-of-the-way. Martin 14:19, 10 August 2006 (UTC)

That was the one I was thinking of. It appears to be guideline rather than policy on WP, but it's regarded as policy at WP:WSS. Subst'ing stub templates causes no end of problems so it is strongly discouraged in a "don't cross the beams"-type way. Perhaps putting it in big friendly letters on WP:STUB would be a good idea. Grutness...wha? 14:25, 10 August 2006 (UTC)

... or how about here: WP:WSS#General_rules. --Bruce1ee 14:38, 10 August 2006 (UTC)

Done, in both places :) Grutness...wha? 14:53, 10 August 2006 (UTC)

Thanks for that! --Bruce1ee 15:01, 10 August 2006 (UTC)

informal titles

Alai made a comment about how this WikiProject is no fun, so I was wondering if there could be informal titles or something. Something like a leadership council, but without actual responsibilities. Alai already suggested one title: Stub Approval Group Moderator Director For Life [4]

Just something fun to think about. *shrug* ~ Amalas rawr ^{=^_^=} 20:10, 11 August 2006 (UTC)

Then, seeing as how I hang out in Category:Rail stubs and work on them most, I hereby claim "Chief Rail-stub Mogul" for my own title. B-) Slambo (Speak) 20:33, 11 August 2006 (UTC)

• I'd like to be 40px Wearer of the Sorting Hat. ♥ Her Pegship♥ 21:15, 11 August 2006 (UTC)
• Oh, good grief. Grutness...wha? 01:16, 12 August 2006 (UTC) (Geo-stub Coordinator-General and NZ-stubber Pursuivant)
• I seem to be The Countess. At least my talk page suggests it. Either that or She Who Is On The Verge Of Getting Fired For Stub Sorting At Work. Crystallina 22:42, 12 August 2006 (UTC)
  • Mind if we call you Bruce to keep it clear? B-) Slambo (Speak) 01:50, 13 August 2006 (UTC)

Parameterised multi-stub template nonsense...

See {{Maintenance}}, and weep. It's probably not SFDable, either, as it's not just a stub template. (The technical term, to paraphrase Slavoj Žižek, would be "nightmare".) Alai 20:29, 14 August 2006 (UTC)

• It looks like it's only in chemistry type articles (amino acids, chemicals, cell biology, drugs, etc) and it has pretty much only one editor: User:BorisTM. I also found this old discussion but it doesn't have many answers. ~ Amalas rawr ^{=^_^=} 20:56, 14 August 2006 (UTC)
  • Doesn't "nightmare" per definition involve the tax man? (Rambo go home, you never met Ole Stavad). Valentinian ^(talk) 21:15, 14 August 2006 (UTC)
    • Seriously, TFD ? Valentinian ^(talk) 21:15, 14 August 2006 (UTC)
      • Yes, seriously TFD. Grutness...wha? 22:48, 14 August 2006 (UTC)

Category:British royalty stubs

Category:British royalty stubs says it is for stubs relating to British royalty - however, only actual royals are currently in it. Can I add members of royal households and courtiers, etc? Dev920 12:42, 15 August 2006 (UTC)

Yellow Stub Message Background

Wouldn't it make sense for stub tags to be displayed on yellow backgrounds, just as page tags are? It would seperate them from the article, look smarter on the bottom of each page, and would make them more prominent to the eye. Crimsone 20:19, 15 August 2006 (UTC)

• I vote no, if that's an option.

1. stubs usually already have plenty of colored boxes - {{cleanup}}, {{wikify}}, {{uncat}}, {{sources}}, etc
2. The colored boxes are distracting, not helpful. People come to wikipedia to read the articles. I think that the helpful editing messages should be as unobtrusive as possible.

~ Amalas rawr ^{=^_^=} 20:28, 15 August 2006 (UTC)

That being the case, would you have an alternative suggestion for the separation of the stub message from the article, so that it is clear that the sub message is not part of the article itself, and is clearly seperate from it in a visual (aesthetic) sense? Crimsone 20:39, 15 August 2006 (UTC)

I actually had that discussion on the AWB talk page (link to discussion), and you can just leave 2 blank lines before the tag, and it looks fine. Cortex (archaeology) is a good example. ~ Amalas rawr ^{=^_^=} 20:56, 15 August 2006 (UTC)

A fair comment. While I still feel the yellow box background would look better, I can't disagree that the two additional spaces fulfill the need for differentiation. The two spaces are certainly adequate though. Thanks :) Crimsone 21:58, 15 August 2006 (UTC)

FWIW, this suggestion has come up frequently in the past, and the consensus has always been as Amalas suggests. Stub templates aren't meant to be noticeable - anyone can see if an article is too short. All they're meant to do is provide a means of categorisuisng the articles and a quick link to any relevant information on how to extend the article. Making them stand out is a bad idea, esopecially in those cases where the article is so short that any boxed/coloured template would dominate the article's actual text. Grutness...wha? 01:55, 16 August 2006 (UTC)

A further thought - I notye that {{Aviation-stub}} uses grey text rather than black to separate it from the main body of the text. (This was never proposed, it seems, but still... ). Perhaps a similar thing could be done with other stubt emplates. Admittedly it's a bit too grey at the moment, but perhaps something like this would work? Grutness...wha? 01:33, 19 August 2006 (UTC)

Categorization proposal

I would like to propose that articles be placed in categories at the same time they are stub sorted. For example, if an article tagged with {{stub}} is sorted to {{US-novelist-stub}}, which places it in Category:American novelist stubs, that article would also simultaneously be placed in Category:American novelists. The former categorization will disappear when the stub tag is removed. But the later category should stay, so its placement cannot be part of the stub template. Please let me know what you think and how to best implement this. Thanks! — Reinyday, 23:48, 17 August 2006 (UTC)

In theory a good idea, until you look at the details. Often the appropriate permanent category is not the one that is the parent of the stub category, but one of the parent's subcategories. There's no good way to handle permanent categorization than other than by manually placing the categories. Now if we can come up with some ideas on how to encourage people to place the permanent categories, that would be great. Caerwine Caerwhine 00:36, 18 August 2006 (UTC)

It'd be possible to create a "stub-plus" template designed to be subst'd into the article, which for each type has a) the code for the stub-tag itself (not itself subst'd, of course), and b) some additional permanent categories, where that's possible. But it'd be a good deal of work to set this up for every stub template, and if it were only done for some, it would cause more confusion than it would help things. And it'd depend on people using it correctly, and not (for example) failing to subst it, or getting confused and substing "normal" stub templates instead. A different approach would be to do something similar by bot: if an article has a stub tag, but no perm-cats, add an appropriate one (where available). Or there's the traditional wiki approach: masses of volunteer labour will get these things done sooner or later... Alai 03:00, 21 August 2006 (UTC)

There will always be way more categories than stub types, so I don't think it can be done automatically. Piet 12:52, 21 August 2006 (UTC)

It would be more of a problem if it were the other way around... The above observation just means that the "automatically" added perm-cat won't be the most specific, and will typically have to be further refined by hand, and obviously there will be categories that don't correspond to a stub type at all, and hence will have to be added by hand. So the marginal benefit over the present system (where it's all done by hand, but with the stub category placing it somewhere it the right general neighbourhood) may indeed be slight, if any. Alai 16:31, 21 August 2006 (UTC)

I like the spirit of the idea, but I think in practice it would be somewhat redundant. Generally -- perhaps there are exceptions -- "Category:XYZ stubs" is already a subcategory of "Category:XYZ"... thus when a stub is sorted it is already sorted into the parent category. As noted above, of course, this is not usually the most appropriate category, but it is a start. What might be useful to WikiProjects and the like would be a list of "XYZ stubs without real categories." -- Visviva 17:27, 25 August 2006 (UTC)

I could certainly generate such a thing. One subtlety is how you define "real" category: there are any number of "maintenance" categories and the like used in the article-space. A often-useful technique is to start looking at "Category:XYZs", as you say: those may not be the only appropriate categories, but they should have one of those at least. Often more pressing though is that if an article is tagged with a <country>-bio-stub template it may lack any indicated of occupation or notability, either as a stub type or as a perm-cat (and vice versa). Do you have a "customer" Wikiproject in mind for a "pilot scheme"? Refined categorisation is also useful for driving re-sorting stubs when they get oversized, so it'd be in "our" interests to facilitate and promote this. Alai 18:44, 25 August 2006 (UTC)

Sortkey

I'm not sure this is the right place for this, but at least some people will see it. I saw some stub templates with a parameter, and realized that could be used as a sortkey for the categories. Of course this would require changing all the stub types (or just biological, since those should usually have sortkeys for their other categories). The appropriate section would be changed to (for {{bio-stub}})
[[Category:People stubs<includeonly>{{#if:{{{1|}}}|{{!}}{{{1}}}|}}</includeonly><noinclude>| </noinclude>]] (for some reason using &#124 didn't work). TimBentley (talk) 02:34, 19 August 2006 (UTC)

This is the perfect place for this comment! Actually, I've thought in the past that adding a sortkey pipe would be very useful for stubs (especially, as you point out, bio-stubs - biographical not biological, though :). It would require a helluva lot of work, though. Anyone know whether it would cause server issues for such high-use templates, or any other problems? If not, it's definitely worth considering - though, as I said, it'd be a LOT of work. Grutness...wha? 03:02, 19 August 2006 (UTC)

My main objection is that it would considerably complicate the basic stub template code, making it even less comprehensible to casual users and coders than it already is. We'll need to carefully document why it's there at Wikipedia:Stub#Creating_stub_template and if we can get {{metastub}} to produce the code after being substed, it would be even better. Caerwine Caerwhine 04:01, 19 August 2006 (UTC)

I think this would largely wasted effort, myself. There's over a hundred thousand bio-stubs just for starters, and ultimately, this is being done just to be thrown away. Better to spend the effort on expanding the article. It might be marginally easier to find the right stub if they were sorted by surname, but better that they be sorted uniformly lexigraphically than a hodge-podge of the two in a single category, which is the most likely outcome. If people really must do this (and it's already unilaterally in place in some cases, then please used a named parameter, and not just "1". Every so often someone gets a bright idea for a stub templates that's parameterised in some way or other, and of course invariably, "their" parameter is "1", too. Alai 02:52, 21 August 2006 (UTC)

I notice that Instantnood has added an extra parameter to {{Stub Category}} to cater for this, which assumes that the sort key is indeed parameter #1. As noted above, I think this is pointless at best, and potentially confusing. In fact, there's been a lot of hither-and-yon edits on this template. As this is used about on about 2,500 categories, it's probably well into "high risk template" territory, and we should probably think about protecting it on that basis. Alai 18:41, 1 September 2006 (UTC)

Sounds like a very good idea. go for it. Grutness...wha? 23:51, 1 September 2006 (UTC)

StubCatDiffuse?

I'm wondering if we should systematically employ either {{CatDiffuse}}, or some bespoke equivalent, on "once and future oversized" stub categories. I don't know if people pay any attention to these things, but it might be worth a shot. A more far-reaching version would be to modify the templates to indicate they should be replaced by something more specific, though in such cases we'd have to make sure that in every case there was a suitable sub-type that would be applicable. An interesting existing example: {{football-stub}}. In addition, we should probably be more systematic in out use of {{verylargestub}}. Alai 03:11, 21 August 2006 (UTC)

• -Good idea. A "bespoke equivalent" would be better, pointing discussion of wholesale changes to WP:WSS/P rather than to the category talk page, but other than that, a good idea. Grutness...wha? 05:44, 21 August 2006 (UTC)
  • I hereby mass-nominate everything that is now, or has ever been over ten listings pages (i.e., north of 2000 stubs) to get this, for a start. And working down from there... Alai 06:19, 21 August 2006 (UTC)

Actor stubs status

I'd more usually stick something to this effect on the /To do page, but "actor stubs still oversized and need sorting" isn't exactly in the "news" department. Specifically, I think I've "diffused" these as much as is possible on current data. The good(ish) news is that the actors and US actors are down to five pages, and the UK actors down to seven pages (I think the last may not be as well-categorised as the others). Caveats would be that these have been moved in several directions at once, so there's lots of stubs that probably ought to be double-stubbed according to specific medium and nationality combos that have not, and that the judgements as to "primary" medium are rather crude: I've moved anything with both a film and TV category (but not a stage) to "-screen-", and anything with only one of those two to that stub type; the "stage" types don't look viable on that basis. The bad news is, first as I said I may not be able to do much more, short of a manual slog through each of those parents, dealing with the cases that have either too little categorisation, or "too much". And secondly, that this is going to make types like UK-tv-actor- worse and worse from here... Alai 01:20, 22 August 2006 (UTC)

• I currently go through some actor stubs each day, but hopefully these posts get more people to help out. Actor stubs is too big, but I agree with what Alai said... the more actor stubs is sorted, the bigger the other stubs are (US-movie-actor, US-actor, etc). Maybe people need to work on getting some pages past the stub status? I will try to do what I can, but I currently sort other groups of stubs as well. RobJ1981 01:56, 22 August 2006 (UTC)

In case anyone is feeling at a loose end: I've compiled lists of UK actors allegedly of big screen, small screen, and stage and of none of the above. Obviously tagging the former with all three, or with "-screen-" and "-stage-" rather defeats the purpose of the exercise, while there's no category clue what to do with the latter at all. So per-article inspection and re-sorting required. (Feel free to delete chunks of the pages if you do a "batch".) Alai 06:35, 22 August 2006 (UTC)

Martial Arts

I'm not sure if this is the right place to say this, but I find it a little POV to associate a Ying-yang with martial arts. I mean, chinese people weren't obsessed with ying-yangs and korean people didn't even know what they were until the rest of the world did. Assosiating a ying-yang with martial arts is like putting the american flag on a category called "smart people". After all, we have pretty smart people. How long is it until that is not a biased, POV statement? Has anyone realised Taekwondo is more popular than Karate? An image associated with chinese popular culture does not belong on a category full of martial arts stubs.Daniel_123 | Talk 13:58, 23 August 2006 (UTC)

• I've continued this discussion on the template's talk page. I would suggest that all further discussion be conducted there so as to keep it in one place. ~ Amalas rawr ^{=^_^=} 16:01, 23 August 2006 (UTC)

Yet more sub-class shenanigans

I'm rather boggled that yet another bot proposal has shown up to create talk-page spam on an industrial scale, announcing that stubs are (coincidentally enough!) "stub-class articles" -- whodathunkit, hrm? And what's more, this one has already been bot-flagged, and has made over 150,000 such edits already. No wonder the db dumps are getting larger and slower, that's probably almost as many new talk pages that have been created, with remarkably little information content. This is admittedly benign to stub-sorting per se, as it's making no automated changes to existing stub templates, but isn't the duplication getting a little ridiculous at this point? If these things are essentially the same, why do we need two parallel structures, and if they're crucially different, why does mass-duplication of current contents make any sense? Alai 05:50, 28 August 2006 (UTC)

Well, I'm glad that someone else is unimpressed with the assessment tags. Obviously the people behind kingbotk think what they are doing is worthwhile. Perhaps efforts further up the chain will be required. -Acjelen 15:14, 28 August 2006 (UTC)

Person singular, AFAIK. A manual assessment, adding some actual information content along the lines of "this is a blah-class article", where "blah-class articles" are supposedly likely to make it into WP1.0 (don't ask me what the "blah-class" threshold might be, the 1.0ists are as clear as mud on this, and for all I know are going through this exercise just for the sheer fun/hell of it) might be fair enough. But I can't for the life of me see the point in tagging every single stub in the db, that was never at any point in any number of being selected for 1.0, with talk-page spam explicitly stating this factoid. BTW, the discussion is now at Wikipedia:Bots/Requests for approval/Kingbotk. While listed as "on trial run", I'm inclined to believe that the bot-flagging has been construed as de facto approval. Alai 16:06, 28 August 2006 (UTC)