Wikipedia talk:WikiProject Stub sorting/Proposals/Archive/2006

Reverse chronological order

Many parts of wikipedia use a reverse chronological order: the most recent edits at the top of the page, and the older contributions at the bottom. Would it be an idea to use that on WP:WSS/P as well? After all, the top of the page is the first thing of the page that many people see. I believe it would stimulate outsider input if they could immediately see where to propose a new stub type. I also don't think it's very convenient to have to scroll through the entire page, or to have to sift through the content box, for ongoing discussions. Many of the discussions in the top of the page (the proposals from October, November and early December have already come to an end, so I don't see why they should clutter up the page this way. What pushed me to come to this proposal/suggestion is the recent reformatting of Proposed mergers, which has gone from an alphabetical order to a reverse chronological order. Aecis ^{Mr. Mojo risin'} 00:45, 12 January 2006 (UTC) PS. I'm prepared to do the reformatting myself when I'm less busy in real life, but I feel that we might need to go through a request for page protection during the course of the reformatting

I think it doesn't really matter, if the page is archived regularly and thus kept at a moderate size. Conscious 18:17, 12 January 2006 (UTC)

That leaves the issue of how the page will look in between archiving sessions. You will probably agree with me that the page was barely readable prior to the current round of archiving. I believe that a reverse chronological order can prevent such a mess, instead of having to clean up after it. Aecis ^{Mr. Mojo risin'} 18:34, 12 January 2006 (UTC)

wouldnt it make archiving more fiddly or will that become reverse order too? BL kiss the lizard 22:38, 12 January 2006 (UTC)

Why would it become any more fiddly? It would simply be done from the bottom up, instead of from the top down. In other words: anything that is archived is already on the bottom of the page and out of sight. Aecis ^{Mr. Mojo risin'} 22:42, 12 January 2006 (UTC)

say youve got the following to archive:

Dec 1
Dec 2
Dec 3

with the archives the same way round as the project page youd simply copy and paste the lot in one go. but if the project page is

Dec 3
Dec 2
Dec 1

and all the sections on those days are also newest at the top, youd have to reorder everything as you went when archiving. seems fiddlier to me. BL kiss the lizard 01:19, 13 January 2006 (UTC)

If it indeed does make archiving more fiddly, I don't think it should matter. After all, WP:WSS/P doesn't exist for the sake of archiving, but for the sake of proposal and discussion. And archiving could also be done in reverse order. Aecis ^{Mr. Mojo risin'} 09:00, 13 January 2006 (UTC)

Reverse chronological order makes sense to me. Can we do Wikipedia:WikiProject Stub sorting/Discoveries at the same time? (Wikipedia:Stub types for deletion is already rev-chron.) — Fingers-of-Pyrex 19:00, 13 January 2006 (UTC)

Doing so for WP:WSS/D would probably be an especially good idea, as things get very little input there and it tends to be quite long. --Mairi 22:16, 15 January 2006 (UTC)

I will be missing the time I used to spend scrolling down the page, but I think I will get over it, so I would support the proposal. I guess it will make archiving a bit more fiddly, but I think it's worth it.--Carabinieri 21:33, 14 January 2006 (UTC)

A good idea. As suggested by Aecis, the archiving can simply be done reverse order as well. It should be done for WP:WSS/D as well. --Valentinian 23:37, 16 January 2006 (UTC)

Strongly support reverse order, and at Discoveries. Much more user-friendly.--Mais oui! 01:07, 23 January 2006 (UTC)

So there is a consensus for reformatting the page? If so, I will request page protection for the duration of the reformatting. Aecis ^{Mr. Mojo risin'} 12:51, 25 January 2006 (UTC)

Assuming we're going forward with this (and I think we ought to unless someone says otherwise shortly), I've written a script that'll reverse the sections, so no one has to do it by hand. The output from it (using a fairly recent version of WP:WSS/P) is in my sandbox. Maybe this'll spur us on to actually implementing this :) Mairi 06:12, 31 January 2006 (UTC)

When are you able to run that program? I think we can now take the final step and get the reformatting done. I don't think we need to go through RPP for this. Aecis ^{Mr. Mojo risin'} 00:16, 1 February 2006 (UTC)

If we want to get it done tonight, I could run it anytime in the next hour or 0300 - 0700 UTC. (The latter time slot also works tomorrow too.) I don't see any need to thru RFPP, it shouldn't be protected for long... Mairi 00:22, 1 February 2006 (UTC)

I don't think I'll be able to assist you in the reformatting, as I'm about to go to bed. It's 1.30 am here now :s Aecis ^{Mr. Mojo risin'} 00:29, 1 February 2006 (UTC)

Ahh, ok. I should be able to manage tho. I'll wait til I get another response from anyone (or until tomorrow night), before going ahead with it. Mairi 00:59, 1 February 2006 (UTC)

We've made it all the way to QDB

I just saw the following quote on the internet [1]:
<jkl> "This pornography-related article is a stub. You can help Wikipedia by expanding it."
<jkl> That's the worst pickup line ever.
-:)

Aecis ^{Mr. Mojo risin'} 10:56, 24 January 2006 (UTC)

Unsortable stub category

See Talk:David Hassinger. Two issues:

1. If anyone knows a better stub flag for this than bio-stub, obviously that would be good. But engineer-stub isn't right IMO, and I can't find a better one.

2. Is there a call for an unsortable category? One for articles that would otherwise go into categories like people stubs, as they are in a subject area for which there are too few stubs to justify a stub category? Depending on the answer to (1) above, this may be a case in point. If it stays in people stubs it will probably waste a lot of people's time. Andrewa 21:18, 24 January 2006 (UTC)

How about {{music-bio-stub}}?--Carabinieri 21:20, 24 January 2006 (UTC)

I believe that the current tag ({{music-producer-stub}}) is very appropriate, but otherwise Carabinieri's suggestion would be good. And what about {{US-bio-stub}}? Aecis ^{Mr. Mojo risin'} 21:26, 24 January 2006 (UTC)

Agree, we've solved question 1 well IMO. I'll leave question 2 as a suggestion. It's just a matter of whether this might, overall, reduce the average amount of time that needs to be spent on a stub before it becomes a proper article, which is after all the goal! The members of the project (which IMO does sterling service just BTW) are in a much better position to comment on this than I am. Andrewa 21:40, 24 January 2006 (UTC)

there are an estimated 200000+ stubs, and only a few days ago Category:stubs was completely empty. so obviously they can all be sorted. Category:stubs is the only place needed for unsortable stubs. if we make a seperate Category:unsortable stubs then lazy people will simply put things in there rather than sort them further and itll simply become a new Category:stubs BL Lacertae - kiss the lizard 03:32, 25 January 2006 (UTC)

Page reversed

As per the above discussion, I've gone ahead and reversed the order of this page. I'll hold off on reversing WP:WSS/D until there's more feedback on the new order. Mairi 00:57, 3 February 2006 (UTC)

My double-stubbing based proposals...

I hope I'm not spamming the page excessively with these; if it's any comfort, there's only about another five of those that meet the basic criteria I've been using, and that look basically sensible. After that, I'll upload the remainder of the raw data, if people want to check if some of the overlaps of size < 60 are 'under-tagged', which is I suspect extremely likely. Alai 03:17, 11 February 2006 (UTC)

They're all perfectly logical ideas for splits, and in almost all cases it makes perfect sense to do them. So I've certainly no objection. Grutness...wha? 04:38, 11 February 2006 (UTC)

Yet more lists of things

I'm done with the trawl through the over-threshold double-stubbings of oversized categories: the complete list is here, if anyone wants to review the data, or propose any of the ones that I skipped. I've also just compiled a secondary list, also where one potential parent is oversized, but where the overlap is <60 (but >=30). In many of these cases I'd imagine that there's "under-double-stubbing" and some of these will actually be viable, should anyone wish to propose these semi-speculatively, or do a more accurate count. Alai 03:23, 12 February 2006 (UTC)

Archives

I'll grant that we're often behind the game on archiving this page, but I'd prefer if we could avoid archiving proposals that aren't "finalised": in particular, proposals that are "approved", but not yet created. Unless we flag those in some other fashion. Otherwise, chances are the creation queue will get even more ad hoc than it is at present... Alai 14:30, 3 April 2006 (UTC)

HEY FOLKS-How about an Obvious Need

This first section has been updated in Egg on Face subsection following. Apologies for lacking information as noted.FrankB

In that it is frequently easier to guess a related category name or syntax (exact name and capitalization, etc.) it would be most helpful if category pages were annoted with a uplink to the parent. It would certainly help those of us most occupied adding expansion materials to correctly concurrently add the correct categories.

• So I am suggesting henceforth, if you are in this project, you start editing pages to have a notation such as this (just added) to Category:History of Canada:
• Main Article: History of Canada it is a sub-category of: Category:History of North America. The latter took me a few moments to track down, which would have been more productive otherwise (as I'm still seeking yet another (but related) branch in the heirarchy).

I suspect it will greatly help all our tasking! 'Can't believe this hasn't been thought of before!' See 'egg on face' comment below! FrankB

• Perhaps someone more knowlegable than I can design a template like the ones that build the nice graphical boxes like the notice boxes WP:Btw. i.e. similar to the graphical appearance given by template:guideline {{guideline|[[WP:Btw]]<br />[[WP:BTW]]}} for this purpose.

Best regards, FrankB 20:13, 12 April 2006 (UTC)

I'm a bit lost as to how this is related to stub sorting. --TheParanoidOne 20:40, 12 April 2006 (UTC)

• Obviously- directly nothing, but you folks do scan a category here and there, and the issue I visited about was not gemane, but the inspiration struck while reading some of the above. So here it landed.FrankB

• Also if you scroll to the bottom of the category you will see that Category:History of Canada is a child of: Category:Canada, Category:History by country and Category:History of North America. I don't rely see the need to duplicate the category links manualy, or did I misunderstand something? --Sherool (talk) 20:45, 12 April 2006 (UTC)
  • No -- I'd just never caught onto that... see below: FrankB

Egg on Face

• Somehow I've been missing that -- probably 'stuck mentally' in 'Article Think Mode' if I ever saw that low on a Cat Page.
• Most I see are fairly large, and you have all the edit fonts, buttons, summary windows, et. al., all in the way and I conjecture I never saw that low on a category page, or at least never noticed while scanning what was there for inspiration on what might lead up the tree... talk about perverse irony!
• 'One' has commented on my talk that the idea of Main Article logging is meritorious, and in fact, running across several of those in the last two weeks is what triggered the idea. Thus the annotation like Main Article: History of Canada it is a sub-category of: Category:History of North America. still seems a good idea, especially in long Category pages.
• I can't be the only editor that has never caught on (without being hit with a 2-by-4) about the parent category hiding off along the page bottoms! Well, at least I hope so!
• Thus the modified proposal would be we all do that for long cat pages at the least. The added benefit of the Main article or list of same is that an editor can quickly cross check it's categorization—which tends to be thorough— and copy back as needed into the side (related) article without a lot of digging.

Since I do a lot of those side article fix ups, I admit to bias... but the idea has merit. Even if it's nothing to do with sorting stubs per se. Those checking in here must be traversing a fair number of articles, so there's a thought with merit, do as you will with it! Best regards, FrankB 03:58, 13 April 2006 (UTC)

More Egg, et. al. next day!

I apparently never saved out on the edit I was recommending. It should have looked like This example or when polished for presentation and organization, the current: Category:History of Canada . Apologies FrankB 20:59, 13 April 2006 (UTC)

Category:University stubs

People of WSS, come help sort Category:University stubs. There are too many of them and I have finals coming up. Thanks. - CrazyRussian talk/contribs/email 22:31, 26 April 2006 (UTC)

Add it to Wikipedia:WikiProject Stub sorting/To do - that way it'll get more people noticing it! BL Lacertae - kiss the lizard 05:45, 27 April 2006 (UTC)

Speedy policy

A thought I just had while recording a vote: should we have some sort of speedy creation policy for obvious splits of oversized categories? --CComMack 11:30, 4 May 2006 (UTC)

although I can see that it would be appealing, I'm against it - there have been several seemingly "obvious" splits which have been improved after a couple of days of debate. We tend to turn a blind eye to the more obvious ones being created a couple of days early though, so the "one week rule" is fairly flexible. It's definitely worth leaving a few days between proposal and creation, though. Grutness...wha? 12:17, 4 May 2006 (UTC)

I agree with Grutness. The current policy of just turning a blind eye, when it's obvious that there won't be any problems, is ok.--Carabinieri^T_T^a_a^l_l^k_k 12:48, 5 May 2006 (UTC)

Stub categories

One of my activities in WP:WSS is adding stub categories to Category:Stub categories. In many cases, this is a pretty obvious and straight-forward activity. I'm not sure about one kind of stub categories though. Should categories like Category:People stubs by nationality and Category:People stubs by occupation be moved to Category:Stub categories, or should they be kept as they are? Aecis ^{Appleknocker Flophouse} 22:02, 9 May 2006 (UTC)

"Other stub-related discussions"

At some time recently, we seem to have lost this section from the bottom of WP:WSS/P.... which makes this an ideal time to suggest a very slight reorganisation of the page. If you're like me, you often fail to notice any changes to the "other discussion" section, and having one part of the page "new at top" and the other "new at bottom" has always seemed a little clumsy to me. I'd like to propose that we change the system slightly so that, while proposed new stubs are still at WP:WSS/P, any other stub-related discussions come here, to the talk page. I think they'll be far more easily seen here and be far more likely to get an active discussion. Any thoughts? Grutness...wha? 09:52, 23 May 2006 (UTC)

Speculative fiction, science fiction, and fantasy stubs

We currently have a fair amount of double stubbing with science fiction and fantasy related stubs. Over in the main categories they've adopted the use of the superset speculative fiction to desl with essentially the same problem. I propose that we do the same here in stub sorting, however thereis one big issue to consider. What do we do with the abbreviation "sf" in our stub template names?

1. Shift science fiction over to "scifi" and use "sf" for speculative fiction.
2. Keep science fiction over at "sf" and use "specfic" for speculative fiction.
3. Phase out the use of "sf" and use "specfic" for speculative fiction and "scifi" for science fiction.

Options 1 and 3 have the disadvantage of requiring the existing science fiction stubs to go to SFD for a mass rename of the templates.

Options 2 and 3 have the disadvantage of using the clunky "specfic" element for the spec-fic abbreviation sometimes used for speculative fiction.

Given that option 3 suffers from both disadvantages, I think we can discount that. From the standpoint of naming, if we were starting from scratch. option 1 is the best choice, but the inertia of people who think sf = science fiction would be a problem, but not a large one since scifi is a subset of speculative fiction. Right now I favor option 1, but could be persuaded otherwise. In any case, I'm in no rush here, but would like to get some sort of consensus. Caerwine Caerwhine 07:27, 17 June 2006 (UTC)

• You may not realise this, Caerwine, but the term "sci-fi" is seen as a gross insult by many sf fans. It's the equivalent of describing a model railway buff as being interested in toy trains. In the fannish community it's pronounced "skiffy" and used to refer to people whose idea of the pinnacle of science fiction is the original series of Battlestar Galactica. I'd be strongly opposed to using scifi-stub for that very reason. Specfic is a bit clunky, but I'd say it's the best of the options on offer. (PS - as former President of NZ's National Association for Science Fiction, I can happily argue this one all day ;) Grutness...wha? 07:56, 17 June 2006 (UTC)
  • I'm aware that some stuffy sci-fi fanatics resent the term, but it is less ambiguous and I'm definitely of the camp that sees "sf" as encompassing all the sub-genres of speculative fiction including science fiction, fantasy, and even such tripe as Galactica 1980 that no sane person should admit to even knowing about. Option 1 has the advantage that if a sorter is of the "sf"="science fiction" camp, they have merely given it an under specific classification while with option 2 a sorter of the "sf"="speculative fiction" camp has over-specified it as science fiction. It may be that battle over what is sf may well mean that we need go with option 3. Certainly "sf" seems to be more ambiguous in actual usage than "ag" is. Caerwine Caerwhine 09:07, 17 June 2006 (UTC)
    • perhaps it's one of those "different countries, different rules" things, but I have seen real fist-flying fights started by someone suggesting someone is into sci-fi. And if it is changed I will personally change it back, irespective of Wiki protocol. To me, it would be like changing US-stub to Whining-fascist-dictatorship-stub would be to someone from Texas. Grutness...wha? 12:09, 17 June 2006 (UTC)
      • Could be, or it could be that I'm one of those people who while I enjoy sci-fi find no particular need to spend money on a convention pass for the privledge of waiting in line to get the author to sign a copy of his book or listen to a panel discussion on what is space opera and what are its finest examples. I hold no animus against you for your elitist view on what constitutes sf and what is sci-fi; just as I hope you will hold none on my exaggeration of sci-fi conventions, drawn from my experience at gaming conventions, which are worth paying money to attend! Caerwine Caerwhine 23:46, 17 June 2006 (UTC)

I'm also in favour of keeping science fiction at sf and not sci-fi. —Nightstallion (?) 09:49, 20 June 2006 (UTC)

The other option is to combine the lot into "SF". Within the science-fiction community, SF is seen as the standard abbreviation, whether you mean "science fiction", "speculative fiction", "science fantasy" or any of the like.--BlueSquadronRaven 22:37, 16 November 2006 (UTC)

Not the face!

AKA, multi-stub templates revisited. Anyone not completely burnt out on this idea, please have a quick look at User:Alai/A Hypothetical Stub, to see if this might be a possible basis on which to tweak the appearance of multi-stubbed articles, via a meta-template. (Before anyone goes sub-orbital, note that none of this is "bleeding into" the template, category or article spaces at present, this is purely a testbed (hence the uncategorised pseudo-templates, awkward inclusion syntax, etc).) To summarise: this works by testing for "short" versions of each of the included stub templates, and if they all exist, including them in a single horizontal row, following the generic portion of the stub canned text, on a separate line. If any are missing, it instead just includes and stacks up the "normal" stubs. What's key here is that: it uses existing template names, not "freeform" parameters, or category names, hence no extra stuff to remember; and it fails in a graceful way if there's no "short" version of the associated template (as is bound to happen, both initially, and as new templates are introduced), and gives the usual template redlink if it doesn't exist at all, rather than a category redlink. Beyond that, I'm not wedded to any of the details, and if people can improve the appearance or whatever, please fire away (just not with live ammo, in my direction). It would need to be tweaked or duplicated to deal with treble- and quadruple-stubbing, but that's straightforward. Let me admit up front that this doesn't address the possible massive inclusion issue, which I'd basically suggest we deal with by tweaking the code in advance, discussing it with the devs, and then super-duper-protecting the thing. OTOH, even if this gets some sort of support, it won't instantly appear on 60,000 articles, so it's not going to be an immediate crisis in that regard. Alai 05:18, 27 June 2006 (UTC)

So for example, the "production version" would use code like {{multistub|bio|UK}} to double-stub as both a UK-stub, and a bio-stub. (I know, silly example, as obviously there's a UK-bio-stub.) Alai 06:11, 27 June 2006 (UTC)

• I can only see supporting this if we have:
  1. A way of easily determining which combos are in use;
  2. People who will commit to converting the uses of multistub, such as the given example, which duplicate existing stubs to that stub; and
  3. A policy of converting combos over a certain threshold (say 15, 20, or 30) to double-catted templates without having to go thru the formal proposals process.

  Even so, I'm strongly skeptical about this. Caerwine Caerwhine 07:01, 27 June 2006 (UTC)

  • The first is an interesting point; I'd have to give how to do that some further thought. Obviously an "upper approximation" is the intersection of the two categories, though I don't think CatScan allows both intersection, and testing for a template inclusion. Maybe I should think again about asking for a toolserver account, and get tweaking... Could certainly be done with an offline report. The other two seem to me just to be "usage" issues, similar to what already arises in analogous situations at present anyway, and I wouldn't think they'd present a problem. The last idea I'm inclining to already, on the basis that templates should be pretty "cheap", and hopefully uncontroversial, where they're simply upmerged to or double-including existing categories. Alai 07:51, 27 June 2006 (UTC)
• not really happy with this idea. we use "whatlinkshere" a lot at WP:WSS, and i dont see how we could with a multistub. BL Lacertae - kiss the lizard 05:48, 29 June 2006 (UTC)
  • That's true, it'd break that, as compared with a single double-stubbed template with the same categorisation. Then again, we don't really use double-stubbed templates that much, do we? (I've been known to do so myself, but I thought I was about the only one...) What links here is already of limited use when it comes to category intersection, which is what you'd really be looking for in such cases, no? Alai 15:06, 29 June 2006 (UTC)
    • partly but i also use it for other things. seeing if a templates been involved in discussions on process and user talk pages, looking at how long some articles have been stubbed (the oldest ones are listed first on whatlinkshere), checking for problems with uncategorised stubs and deletable stub types, that sort of thing. BL Lacertae - kiss the lizard 01:29, 30 June 2006 (UTC)
      • That should still work, though: look at this, for example. Now admittedly, there's (potentially) one extra version to check for in each case, but I wouldn't think that'd be a fatal problem... Alai 01:44, 30 June 2006 (UTC)

Finer-grained section headings?

I realize this month may be an extreme example (mea maxima culpa), but I wonder if the monthly sections aren't getting to be so far as to be a hazard to navigation. Would sub-headers by date (or even by week?) be to anyone's liking? Or indeed, to anyone's intense disliking? Alai 17:33, 24 August 2006 (UTC)

• At 146 entries for August, it sure seems awfully hard to navigate. The by-day works for SfD since there's a definite 7 day time period. Perhaps something like that should get implemented here? Maybe motivate people to actually create things once they're approved. ~ Amalas rawr ^{=^_^=} 18:15, 24 August 2006 (UTC)
  • Indeed, I've found myself resorting to search-on-page for (<current date> - 7) to find out what was good to go (or otherwise). At the very least an "old business" marker, or some such other wording or turn of phrase, and probably both, for the sake of clarity. Alai 19:34, 24 August 2006 (UTC)
    • Actually, some of this stuff could be cleared out as it's been approved & created. What's the procedure for archiving, and can anyone do it (i.e. moi)?♥ Her Pegship♥ 20:55, 24 August 2006 (UTC)
      • We don't have a procedure, so not only can anyone (e.g. vous) do it, you can make up how to do it up as you go along. :) Specifically: until recently, we were using the "one massive page and cut'n'paste archive when someone had the will" method. Now, or at any rate for June, we went over to the "transclude a month at a time, and rotate the transcluded page into the archive after a further month" method. This avoids c'n'p logging, and limits the total page size to two months' worth at worst, but does nothing to help with clearing out those that are clearly stale (or more narrowly, those approved and created, and/or those approved and not created if that's then noted elsewhere, and/or those that are clearly rejected). There's nothing to prevent us using a mixture of the two, certainly. (Log when resolved to a numbered archive, or by month if all else fails.) Personally I find c'n'p archival to be a real pain in the neck, so you'll have no competition from me in doing this. Transclusion on a finer-grained basis helps very little, unless we were to go all the way to per-section transclusion, a la AFD, which I suspect would not be popular. Logging by bot's another option, but obviously requires the setup effort, and determining a clearly-defined criterion by which to automatically archive. Alai 00:03, 25 August 2006 (UTC)
        • Cut'n'paste does have one advantage, unfortunately - it ensures that everything archived has been dealt with fully, and keeps items under our noses at WP:WSS/P until they are. Other than that, I agree - it's a pain to do. Perhaps the system used at AFD is a good one - I don't mean in terms of item by item transclusion, more the idea of re-proposing things to get a firmer consensus. That could be done at the same time as a month is logged (possibly at the same time as a new month page is started. Say, for example, when the September subpage is made, anything that hasn't been dealt with from June could get added to it at that point - "to gain consensus", and the June subpage could be archived then. Grutness...wha? 03:30, 25 August 2006 (UTC)
          • Per-item translusion would have the same benefit, and might be slightly more likely to actually happen on that basis, but probably isn't worth the extra hassle of creating a page per proposal. It does work at AFD, but it'd give "proposing things! how unwiki! and systematically biased! etc!" crowd another thing to complain about. (However, there might be some benefit in having per-parent-type per-topic discussions, perhaps linked to from th main proposal page. But that's a different issue.) I can't say I'm wild about "churning" items if they have clear enough consensus. (Unlike, say, the US sports venues, which it's necessary to churn manually every so ofte due to lack of same...) It's adding to the length of the current page, and it's wholesale double-handling. If they're to be given any case-by-case treatment, archive them to a separate "holding" area, though a simple link at WSS/T seems preferable to me in any event. "Manually tagged" bot-archival would be a reasonable compromise, but I don't know how to set them up at this point. At any rate, if someone is daft^Wkind enough to do it manually at the present time, they are more than welcome to do so... Alai 05:14, 25 August 2006 (UTC)

Archive solution?

• Possible, though labor-intense, solution to archiving can be seen here.

— Preceding unsigned comment added by Pegship (talk • contribs)

• • Works for me. I've added a link at on the Archive page. If you're archiving only approved-and-created proposals (which I think is clearer than having them mixed, so my all means continue that way), it might be a good idea to put it at an archive name that makes that explicit, as we'll presumably end up with more than one archive per month. Alai 05:13, 27 August 2006 (UTC)

Both WP:WSS/P and WP:WSS/D are somewhat messy (WP:WSS/D still lists discoveries from December last year). This looks like a good way to go. Valentinian ^{(talk) / (contribs)} 09:12, 27 August 2006 (UTC)

So which items from WP:WSS/D should go in the archive? ♥ Her Pegship♥ 15:27, 27 August 2006 (UTC)

That should be archived separately, as Caerwine is-or-was doing of late. Someone that wants to make a lot of work for themselves could of course cross-reference the two, but that sounds like masochistic territory to me. Alai 02:47, 28 August 2006 (UTC)

completed proposals idea

The "old business" marker is a good start, but I'm wondering if we need something more to help go through the old Proposals. I put together a few dummy templates and an example of how they would be used. My idea uses 3 different templates: one for "create", one for "do not create", and one for "other/no consensus". In theory, I'd like for there to be only one template that would change the color based on what parameter you put in, but my wikicoding skills are severly lacking. The idea was that the templates would be color-coded so that you could easily go through the proposals page and help create things that were approved, but no one got around to actually creating. Also, if you had proposed something, you would know the result of the debate quickly.

This was just my first crack at it, so feel free to offer suggestions, changes, comments, whatever. This may not be a great solution, but it was just an idea.

Example page ~ Amalas rawr ^{=^_^=} 19:34, 29 August 2006 (UTC)

• You know what? I fail. I fail hardcore. That's what I get for not reading Pegship's above discussion. There already is a {{sfp top}}. Never mind. ~ Amalas rawr ^{=^_^=} 19:38, 29 August 2006 (UTC)
  • Nononononono! Carry on - Great minds think alike. AND I like that green, so I'll revise the template. ♥ Her Pegship♥ 20:02, 29 August 2006 (UTC)
    • Actually, let's use yours. The color coding is great, plus 3 versions means less typing. In addition to the "other" version, we can still use {{sfp top}} to fill in more descriptive results, as in {{sfp top|created as revised}}. ♥ Her Pegship♥ 20:05, 29 August 2006 (UTC)
      • Good point about having a "catch-all" template for flexibility. I should probably then change the wording of the "other" template to read only "no consensus", as the "other" would be covered by {{sfp top}}. ~ Amalas rawr ^{=^_^=} 20:12, 29 August 2006 (UTC)
        • Kewl. I have revised the archive pages with the template code, so feel free to move them to template space any time. Cheers, ♥ Her Pegship♥ 20:16, 29 August 2006 (UTC)
• They've been template-ized as {{sfp create}}, {{sfp nocreate}}, and {{sfp other}}. Now all we need is to go through all the proposals, starting with July since it's still on WP:WSS/P. ~ Amalas rawr ^{=^_^=} 20:29, 29 August 2006 (UTC)
  • I will start on July as of my time stamp in this sig. I will be stopping ~1/2 hour after that, so feel free to continue where I left off. I'll do my best to guess the result. If I don't know, I will probably leave it blank. I don't know if we should tackle the archive as well. ~ Amalas rawr ^{=^_^=} 21:00, 29 August 2006 (UTC)
    • I'll deal with the archives (for now!). Thanks - ♥ Her Pegship♥ 21:21, 29 August 2006 (UTC)
    • I'm done with July. I suppose the ones that are marked as "no create" could just be moved straight to the archive. Now, for August! ~ Amalas rawr ^{=^_^=} 13:55, 30 August 2006 (UTC)

Archived July

I copied all the discussions to the July archive page. I've left copies of those still needing creation on the Proposals page, so if you create one, please feel free to delete the discussion. Cheers, ♥ Her Pegship♥ 19:27, 31 August 2006 (UTC)

Question

Hello, excuse me butting in on this page. The philosophers would like a way of searching philosophy articles that need expert attention. So how do I query for articles that are both in the 'Philosophy' category, and 'Need expert attention'? If there is a way of doing this, of course. Dbuckner 15:41, 4 September 2006 (UTC)

Category:Philosophy stubs would be a good place to start. --TheParanoidOne 20:35, 4 September 2006 (UTC)

There isn't really a tool for this at present, as far as I'm aware. The CatScan tool can do this, but it isn't currently able to handle the English Wikipedia. Similarly, we had Wikipedia:Pages needing attention/Philosophy, which was to have been updated by User:Pearle, but that seems to have fallen through. A messy but surprisingly effective solution is a Google search on en.wikipedia.org for the word "philosophy" and the phrase "pages needing expert attention." -- Visviva 05:50, 19 November 2006 (UTC)

Feel free to archive

I've been tagging and moving sections to the archives, as it becomes clear what the consensus is (if any) and once the template has been created (if approved). Some of these discussions, though, I find a little hard to follow (mommyhood has limited my ability to follow a train of thought very far...), so if someone has a better feel for whether something is "create", "nocreate" or whatever, please feel free to tag it as such and I'll do the heavy lifting (i.e. moving sections to the appropriate archive page). Cheers, ♥ Her Pegship♥ 04:15, 12 September 2006 (UTC)

Wikipedia:WikiProject Musicians/Stub sorting

I'm not sure what the outcome was of the proposal to delegate responsibility to the above-named WikiProject, buf if the proposal was rejected could you please mark that page as rejected or historical? I have some doubts about the organisation at the moment and would counsel against accepting the proposal at this stage. --kingboyk 14:03, 19 September 2006 (UTC)

What proposal? This is the first I've heard of one - can anyone remember this ever having been mentioned? I can't find any sign of it in the archives, either. I'm against it, too, BTW - decentralising stub sorting will only lead to confusion. Grutness...wha? 23:23, 19 September 2006 (UTC)

"New proposals" header

I've added a "New poposals" header to the page, as is done on other process pages like CFD - it seems to make the process work a little more smoothly there, so why not here, too? Grutness...wha? 00:50, 23 September 2006 (UTC)

• I didn't like the header at all, and I had assumed some random person put it there (sincere apologies to you, Grutness), so I removed it. It seemed redundant to the month header and I don't think that all caps was the way to go. I did, however, keep the HTML comment that was written because I felt that was very useful. ~ Amalas rawr ^{=^_^=} 18:40, 28 September 2006 (UTC)

Archiving

I've been itching to move the August old business off this page. Shall I shift concluded discussions over to Wikipedia:WikiProject Stub sorting/Proposals/Archive/August 2006 completed, even if the approved stub types haven't been created? They can still be found on the archive summary page. Or shall I let August linger on Proposals until the page length begins to annoy? No rush, I'm sure, just a yen for tidiness on my part. ♥ Her Pegship♥ 18:25, 28 September 2006 (UTC)

Suggestion on Instructions

Hi my suggestion is that right after it says "Good number means about 60 articles or more, or 30 or more if associated with a WikiProject, though this figure may vary from case to case." you include the link to the "stub sensor". This page does not mention "stub sensor". If I had only known about stub sensor 2 months ago... Goldenrowley 21:31, 12 October 2006 (UTC)

What is the link to stub sensor? --Ohms law 09:18, 14 November 2006 (UTC)

Singular/Plural name nouns?

I just ran across a good example of waht appears to be a common problem with stubs. Category:African writer stubs uses the plural form of African, which I think is appropriate. However, the template to place articles within: {{Africa-writer-stub}} uses the singular "Africa". Is this appropriate? Could the template name be changed? Should the template name be changed? It can be difficult finding some of these stub categories, and it seems to me that a lack of standardisation in this respect is one reason why.--Ohms law 09:19, 14 November 2006 (UTC)

• Actually, the example you just used is standard. The templates are designed (or at least they try to be) as short as possible, always using the singular noun form. The category names are sometimes longer/more descriptive and use the adjective form. ~ Amalas rawr ^{=^_^=} 14:54, 14 November 2006 (UTC)
  • I see. Thanks for the clarification. Knowing this will certainly make stubs easier to find. --Ohms law 16:28, 14 November 2006 (UTC)

Match stub to Category Proposal

Please forgive the newcomer for asking the silly question, but i'm not about to go digging through month's or even years worth of discussion to try to decipher the answer to this. The simple question that I have to ask is, why not simply allow the creation of a foo-stub subcategory for each and every existing category? It seems logical to me that each actual category would have a coresponding foo-stub subcategory to it. I don't see what's so special about a stub that differentiates them from the normal wiki categorisation policies/procedures. It appears to me that we're duplicating and creating extra work for ourselves, when it would be easy enough to create a foo-stub subcategory to any category that has use of a stub tag. --Ohms law 17:39, 14 November 2006 (UTC)

• I'm moving this from the project page, since I assume it's a point of discussion, rather than a mass proposal for several hundred thousand new stub types are such. In short: there would be far too many; many of them do not relate to primary notability; and if an article were tagged with stub types corresponding to all of the categories of which it should and would be a member, there would routinely be articles tagged with a dozen stub templates. Alai 18:08, 14 November 2006 (UTC)
  • No problem regarding the move, probably should have placed it here to begin with. I want to make it clear that I'm not critisizing stubs themselves, or all the work that has occured before me. My thought process is simply that we're collectively "making a mountain out of a mole hill". It would seem to me that it would be much more of a transparent procedure for all wikipedians if we were to change the stub procedure itself to be a component of categorization, rather than having stubs as a separate entity. Currently, stub sorting is in addition to, and separate from categorisation which seems very counter productive to me. I would think that one of the primary functions that us "stub sorters", being organisers, ought to be fulfilling would be to actually categorise articles within wikipedia itself as appropriate. It seems to me that we are currently doing that occasionally, in addition to actually sorting these special articles within our own system. In other words, what's the need for a whole new system of categorisation (besides, stubs are by definition supposed to be temporary anyway) in addition to, and separate from the normal and accepted system of categorization that already exists. Shouldn't we be supporting the permanent organization of articles anyway? To clarify, i'm not proposing the instant creation of thousands of new templates/categories. I'm actually proposing the removal of the current special "stub categories" in favor of a procedure to sub-classify stub articles as stubs within the normal wiki category that they should be in anyway. --Ohms law 18:31, 14 November 2006 (UTC)

• • • But with biography articles, for example, generally getting sorted into at least three categories (XXXX births, YYYY deaths, and the appropriate occupation category), then we're looking at at least three stub categories too. For a more concrete example, Angus Daniel McDonald is currently listed in Category:1878 births, Category:1941 deaths, Category:American railroad executives of the 20th century and Category:Southern Pacific Railroad, and currently has two stub templates on it. If each category the article is in has its own stub category, we've just doubled the number of stub templates on the article (there are already two stub templates on that article) and increased the number of categories that it resides in. While the theory is simple, the implementation would create a large amount of additional editing and maintenance. Slambo (Speak) 18:48, 14 November 2006 (UTC)
      • I understand exactly what you are saying, Slambo and I can't say that I disagree either. However, consider the fact that, if each normal category implicitly allowed a "stub" subcategory (with appropriate guidance/formatting/etc..., of course) that that would entail much more transparency to the normal user than the current system. I can't help but feel that all of this effort that us "stub sorter's" are putting forth in organising a vast array of articles here, is ultimately wasted. If our efforts were to have a permanent effect upon wikipedia (that being to place articles into normal categories) beyond the initial effort to bring notice to articles that need additional content; I can't help but think that that would help wikipedia as a whole much more than what we are currently doing. --Ohms law 19:06, 14 November 2006 (UTC)
      • Additional thought: From a technical standpoint, the "stubness" of an article could easily be automated if marking a stub were to "only" entail something along the lines of adding a "{category name}-stub" template to the article itself. I could imagine a bot that had the sole purpose of placing or removing articles from a category "stub sub category" with little or no human intervention. Perhaps my understanding of stubs is flawed somehow, but isn't the intent to simply call to attention articles that need additional content to meet wiki standards? It seems to me that if "stub-ness" itself were completely automatable and transparent, that that would assist wikipedia itself tremendously. --Ohms law 19:21, 14 November 2006 (UTC)
    • Ah. I think you might have to go look at months and even years worth of discussion, after all. This comes up periodically (look for section headers in the archives such as "you fools, you're all wasting your time!", etc. Yes, there's some redundancy between stub-sorting and categorisation ("helpfully" increased by the relatively recent addition of "Stub-Class articles" talk-page categories), but that doesn't mean it's possible to dispose of one in favour of the other at the drop of a hat, and nor is it necessarily practical to demand that someone completely categorise an article when they're stub-sorting it. Removing stub categories doesn't make a lot of sense, as firstly wikipedia has no category intersection at present, so if you just had a single "stubs" category (... as was the case several years ago...), and were looking for stubs on a per-topic basis, you'd be screwed. Secondly, even if there were, it'd quickly lead to an exercise in "guess the right category to find a feasible number of stubs in", as the degree of "stubiness" varies hugely from topic to topic, as you might notice if you peruse the stub list. So until such time as someone completely re-engineers WP's category system, or else comes up with a solution no-one has suggested to date (or, we all just give up in disgust), I think we're stuck with it for the time being. Alai 19:10, 14 November 2006 (UTC)
      • (caught in an edit conflict! lol)And I will gladly look Alai! I simply need to be pointed in the correct direction is all. ...let me read your whole reply, and respond as I will though. Thank you! --Ohms law 19:21, 14 November 2006 (UTC)
      • I'm supposed to be in bed right now, but as is typical for me once I start a discussion I can't walk away before saying everything on my mind. Specifically in reply to the point that "Removing stub categories doesn't make a lot of sense" and all that follows, I would offer that following thoughts: Statistical analysis is seemingly easily available in regards to an ultimate technical solution (ie.: articles in "this" category average X bytes, this one is {below|above} X bytes?). Also, i'm not ashamed to admit that i'm not entirely certain what you mean by the phrase "wikipedia has no category intersection at present", so any additional deatails are welcome. Most importantly in my mind is the point:

        Secondly, even if there were, it'd quickly lead to an exercise in "guess the right category to find a feasible number of stubs in"1

        This hits directly home to my primary point, I think. Currently, we are expending time and effort in categorizing articles within the stub system regardless. If this time and effort were to ultimately lead to categorising the article withing wikipedia's normal category system, wouldn't that be more helpfull than the current methodology? Regardless, I'm off to read the Archives... :) --Ohms law 19:40, 14 November 2006 (UTC)
• I'm still not at all clear exactly what you're suggesting as an alternative (if anything). A stub type per category isn't workable; no stub types is also not workable. While there is (as I say) some redundancy between the two, each is also a help, or at least a hint, in applying the other, so things aren't quite as bad as it might first appear. Alai 20:01, 14 November 2006 (UTC)
  • OK, imagine that creating a stub were a procedure only to add a sub-category to an already exiting, accepted normal category rather than being a separate procedure and categorisation system. Rather than having a stub type per category, couldn't there be a stub sub-category implicit to every category as the need arises? ie.: rather than attempting to determine appropriate sub categories for all the articles that are in "American people stubs", wouldn't it be more effective to mark, for example, Abby Rockefeller Mauzé as being in the categories of: [[Category:Rockefeller family|Mauzé, Abby Rockefeller]] [[Category:American philanthropists|Mauzé, Abby Rockefeller]] [[Category:1903 births|Mauzé, Abby Rockefeller]] [[Category:1976 deaths|Mauzé, Abby Rockefeller]] [[Category:American socialites|Mauzé, Abby Rockefeller]] [[Category:Rockefeller family stub|Mauzé, Abby Rockefeller]] [[Category:American philanthropists stub|Mauzé, Abby Rockefeller]] [[Category:1903 births stub|Mauzé, Abby Rockefeller]] [[Category:1976 deaths stub|Mauzé, Abby Rockefeller]] [[Category:American socialites stub|Mauzé, Abby Rockefeller]] (blah, that doesn't come out well here on the talk page...) Again, I very much appreciate how this could appear to be adding an additional (technical and personal) burdon. The thing is, I think that stubs as they exist are already adding a similar burdon, and it would probably be more effective if that burdon were to lead to progress twords normal categorisation. --Ohms law 20:21, 14 November 2006 (UTC)

• • • A stub category is, in just about every case, "a sub-category to an already exiting, accepted normal category". They're not in a separate hierarchy, there's simply a "system" to avoid have such sub-categories for absolutely all categories, for the reasons I initially mentioned -- i.e., precisely to guage such "need". Category:1976 death stubs, for example, would be truly pointless for stub-sorting purposes: no-one is a specialist in all people who died in 1976, so what benefit is "sorting" on that axis? Likewise, Category:Rockefeller family stubs is far too small to be worthwhile as a stub type. So your suggested scheme is not only more work for the "stub sorter" (who is now supposed to do complete categorisation, and then some more besides), but is less effective for sort-stub "consumers". As I've said, I think stub-sorting does lead to progress towards normal categorisation (much as it may be disparaged as "not real categorisation" over at WP:CAT). What it isn't is a replacement for it. Alai 00:51, 15 November 2006 (UTC)
  • ugh, I need to work on the presentation of what i'm saying here. I'm "hot" on the idea, but there's no extremely urgent need to address it. I'll think about it some and hopefully post a more well thought out proposal later on (after playing with the idea some in the sandbox, probably). --Ohms law 20:21, 14 November 2006 (UTC)

• After reading the replies here, thinking about it some, and reading some of the history of similar discussion that have occured I beleave that i've stumbled into an old debate. What's worse is that it seems that i've reopened an old wound in the process, witch is not at all what I had in mind. I believe that my idea here is significantly different from the older "why is this neccesary?" sort of debate. My main concerns (in my mind) simply deal with streamlining the new stub process and also in pushing our efforts closer to the categorization process. It is aparent to me now though that this is not the time, and I as a newer member here am certainly not the person, to be advocating such a change. So, It was nice to actually have a conversation here. Off to do some sorting I go... :) --Ohms law 15:43, 15 November 2006 (UTC)
  • I don't think the issue is one of timing, and I certainly hope it's not one of who-the-bearer is. (I'm not going to be the person to tell you that Wikipedia is entirely free of credentialism or cliquery, mind you.) Rather, it's one of firstly, technology, and secondly, division of labour. Basically, it's not, as far as I can see, to do anything much different than the present system, if you want anything at all like the current results, as expressed in the stub guidelines. There's also the question of complete categorisation, vs. adding simply a category. While some people will seemingly tell you that an article is "uncategorised" if it's in Category:American actor stubs, and "categorised" if it's in Category:American actors, the truth is rather fuzzier. Until such time as there's both the wiki-support, and the widespread practice for completely categorising an article, and annotating in some manner which of them corresponds to primary notability for stub-finding purposes, there's bound to be some duplication and ad-hoccery between the two. But yes, in principle we should be working to reduce same... Alai 18:39, 15 November 2006 (UTC)

restart, clarification

OK, I guess that i'm restarting this discussion. The point that I am trying to make here is that I beleave that we should be attempting to match the existing permanent category structure, as closely as is reasonable within the current guidelines for creating stubs categories. As an example of how we are not currently doing this, I'd like to point out this example:

Category:Texas contains within it a sub category Category:Texas stubs. This is good (the stubs cat matches the perm cat).

Category:Dallas stubs and now Category:Fort Worth stubs have been created as cub categories of Category:Texas stubs. This is a mistake, in my opinion. For one thing, having stubs categories that are children of other stubs categories creates an atmosphere of permanence (in categorising the articles) that I don't beleave we should be encouraging. Category:Cities in Texas has been established as a permanent category, and therefore is where stub articles about a city in texas should be. Therefore, there should be a Category:Cities in Texas stubs category/template. If such a category becomes too large for some reason, we could then create (for example) a Category:Dallas, Texas stubs category and sort out those articles tht need to be in it.

Simply put, I don't understand why we have our own category structures (stubs categories that are sub-categories of other stubs categories). Any stub category should, in my mind, be a dead end and have as it's parent the most relevent permanent category that otherwise exists.--Ohms law 11:52, 16 November 2006 (UTC)

• I believe I've answered this about three times now. Before I do so again, can you give me some indication of what was lacking in my earlier attempts? Such as, for example, this one?
  • I don't follow what you mean by "our own category trees". Every stub type is in the (permanent) category tree, and the considerable majority of them have a direct "permanent parent". I really don't for the life of me see why you're saying that Category:Fort Worth, Texas shouldn't have a corresponding stub-cat, but that Category:Cities in Texas stubs should -- the former might be marginal, but the latter doesn't make any sense at all, sorry. Are you objecting to "skipping a level" in the hierarchy... or what? If you're simply looking for a broader scope, wouldn't that of Category:Dallas-Fort Worth Metroplex or Category:Tarrant County, Texas make more sense?
• I believe Grutness stated at some length (and with some vehemence, indeed) why "cities" and "non-cities" is a bad place to start sub-dividing. We do attempt to match the existing permanent category structure, just not -- for the reasons previously articulated -- all of it. If you're not suggesting all of it, I don't see why you're insistent on having stub children of this particular perm-cat, as against the others. Alai 12:08, 16 November 2006 (UTC)

---

Simply put, I don't understand why we have our own category structures (stubs categories that are sub-categories of other stubs categories). Any stub category should, in my mind, be a dead end and have as it's parent the most relevent permanent category that otherwise exists.--Ohms law 11:52, 16 November 2006 (UTC)

---

• Is it your position that Category:Dallas stubs and Category:Fort Worth stubs are not sub categories of Category:Texas stubs? Do those categories have other parents that I cannot see?
• There may very well be enough stub class articles about Dallas, Texas on wikipedia at the moment that they should be sorted into their own Category:Dallas stubs. That is immateriel to what I am talking about here. What I am saying is that in the permanent category structure, there is a Category:Cities in Texas that has children such as Category:Dallas, Texas. We have not supported this permanent structure by creating our own structure with Category:Dallas stubs as a child of Category:Texas stubs. I see little reason for a stubs category contain other stubs categories as children. If there are enough stub class articles about various cities in Texas, then there should be a Category:Cities in Texas stubs that has Category:Cities in Texas as it's parent, and might even have Category:Texas stubs as a parent if someone feels that that is important.
• currently, (mainly due to these reasons) the stub sorting project does not respect the WP:CAT guidelines. This probably is the reason for much of the confusion regarding the creation of new stubs categories, as well as the occasional outburst of angst to the entire project that I have read some of in the archives.

--Ohms law 12:30, 16 November 2006 (UTC)

I'll quote from the virtual classroom article I wrote on stubs: Why are the stub categories different from other categories? To put it simply, the main categories are designed to make it easier for readers. A reader looking for an article on a particular subject can go straight to a category on that subject and find the specific article they are looking for. In contrast, stub categories are aimed at making it easier for editors. If an editor knows about a particular subject, they are likely to want to be able to pick and choose between a number of articles they can work on. For that reason, your are unlikely to find stub categories with only one or two articles, like you can with permanent categories. The Stub sorting WikiProject does its best to ensure that stub categories are of a reasonable size - not so big as to overwhelm an editor, but not so small as to make it necessary for an editor to look through lots of categories (ideally, we use about 50-500 articles as an optimal size for stub categories). For that reason, stub categories aren't always identical to main categories, although we aim to make the discrepancy between the two as small as is practical.

To put it in terms relating to the above example, neither Dallas-stub not ForthWorth-stub is in itself likely to be particularly large. The same group of editors is likely to know about both of these groups of stubs. As such, it makes more sense for the stubs to be in one place, to reduce the effort of editors having to look in more than one category. Yes, there is a permanent "Cities in Texas" category, but it is populated either by subcategories or individual articles, each related to a specific city (which makes sense, when you think about it). Given the overall size of the Texas geography stubs category, splitting the stub category in this way would be counterproductive - especially given that for many places, one subtype of geo-stub by feature is a huge proportion of geo-stubs (in many cases, the parent cat would be reduced by some 75% or more, which makes it a complete waste of time - why go from having one large category to having another large category?). Again, to take an extreme example, consider {{Seychelles-geo-stub}}. There is a subcategory of Category:Geography of Seychelles for Category:Islands of Seychelles. But what good would a {{Seychelles-island-stub}} do? It would simply take over 80% of the items currently marked with Seychelles-geo-stub - hardly aiding stub sorting.

There is also an additional problem, in that a large number of editors object to the over-stubbing of articles - if an article has more than about four stub types it is usually seen as being a bad thing. In contrast, to a large extent, the more permcats an article has, the better. So the more accurately an article can be stubbed with as few stub types as possible, the better. This comes back to the idea I mentioned above about how stub categories and permanent categories are essentially used for different purposes by different groups of people. It also leads to the situation which is currently being discussed on other topics at WP:WSS/P, that adding one stub type is often done at the expense of adding another, rather than bing done as a complement to it.

A further problem yet occurs with the sheer size of the stub category tree if this was to be implemented. We currently have 1500-2000 stub categories, which is large but not totally unmanageable. The number of pernmcats is considerably larger. Monitoring of them alone would become a full-time task, let alone actually implementing them. To give one example, the size of WP:SFD is already big enough (in fact, there have been complaints before about its size). compare it to the size of WP:CFD.

Another problem if the category tree is to be used as an absolute model is the one I already mentioned when this was being discussed at WP:WSS/P - many permcats are significantly below a viable threshold for stub sorting and cannot but remain so. Many would indeed be permanently empty.

The stub category tree is different to the permcat tree, but there are very good reasons for it to be so. It is, however, parallel to a large extent, using the parts which are most appropriate to the task of stub sorting, but ignoring the ones which would actually make the task harder. Consider it a compromise that works better than either a fully identical system or a completely separate system would do. Grutness...wha? 22:16, 16 November 2006 (UTC)

similar discussion

I Just saw/found this, which seems to be somewhat topical: [2]--Ohms law 18:55, 14 November 2006 (UTC)

This is similar discussion as well: [3]--Ohms law 19:46, 14 November 2006 (UTC)

Minor Edit?

[4] is not entirely helpfull in answering this question, from what I've read. I have my own opinion, but I'd like it to be verified by my peers. Simply stated, is the act of stub-sorting by itself (editing an article simply to change the -stub template) a minor edit? --Ohms law 19:52, 14 November 2006 (UTC)

I usually code my stub sorts as minor if that's the only change made because it doesn't significantly change the article's content. Slambo (Speak) 19:55, 14 November 2006 (UTC)

ok thank you, that's what I wanted to know. FYI, i had forgotten that I had turned on the "minor edit as default" option earlier. I guess i'll just leave it in the normal 'not-minor' option, since i'm obviously used to it that way... --Ohms law 20:00, 14 November 2006 (UTC)

Concluding discussions - help!

Hi folks - could someone look at October and tag the discussions, if they are indeed concluded? Sometimes I have a hard time working out what was said, done, or decided...thanks!! [Mommy Brain] Her Pegship 00:36, 18 November 2006 (UTC)

60 articles for new stub

How much of a rule is the 60-article threshold for new stub types? I'd like to create a {{Cameroon-bio-stub}}, but by my count, there are only 54 articles that qualify. There is, however, a {{Cameroon-footy-bio-stub}} that would theoretically be a subcategory of the one I'd like to create. There'd also be a lot more stubby articles in Category:Cameroonian people, but, well, I don't like writing stub-length articles. So, is 54 articles okay in some cases? Should I wait a bit before proposing the new stub type? — BrianSmithson 08:54, 27 November 2006 (UTC)

It's more a guideline than a hard-and-fast rule, and varies from case to case. In a case where a parent category has only 150 articles, splitting out 50 on a vaguely-defined topic is less likely to be approved than if the split is from a heavily populated category where a split is more obvious. In this case, Africa-bio-stub is pretty full, and splitting by country is a standard form of split, so I don't think there'd be too many eyebrows raised if a 54-article category was proposed. Certainly it's the sort of circumstances where it wouldn't be SFD'd if we discovered an un-proposed stub type. It sounds like a pretty reasonable stub type to create to me. Grutness...wha? 11:47, 27 November 2006 (UTC)

Actually, Africa-bio-stub isn't full - but it should be. For some reason, there's an instruction in the category telling people only to use the nation-stub but not the bio-stub if no nation-bio-stub exists (contrary to what's normally done with such stubs). Wonder why... Grutness...wha? 12:02, 27 November 2006 (UTC)

Yeah, I was puzzled by that, too. In preparation for proposing the bio-stub, I went through and added Africa-bio-stub to several articles in the Cameroon-stub category only to be told on my talk page not to do so. No idea what the deal is. Thanks for the pointers on the stub proposal. — BrianSmithson 13:01, 27 November 2006 (UTC)

I think 54 is perfectly OK where there's an existing (viable) subtype. There's no formal guideline-within-guideline about that, but for my money a well-formed sub-category is worth about twenty articles' "credit" (i.e. stub category with 40 articles and a sub-cat, 20 and two, or three or more subcats are all OK, if they make hierarchical sense). As Grutness says, even lacking subcats no-one is going to much object to types at that level, especially where there's either a splitting need, or a structural predisposition for them to exist. Alai 15:19, 27 November 2006 (UTC)

The Cameroonian template sounds fine to me. No problem with a category either since it is so close to the normal threshold. I realize Category:African people stubs is a bit unnormal, but the problem was that it was not only full; it was completely bloated. On the other hand, you-have-no-idea how much material was only tagged with this template and / or an occupation stub, so searching for further splits was next to a mere waste of time. When I began adding nationality templates, I realized that much of this material would end up with a total of four templates in order to cover the occupation side properly, at a time when we were being criticized for adding too many stub templates. So as I went through the the lot, I sorted everything according to nationality and replaced {{Africa-bio-stub}} with a nationality template wherever possible. Given that next to all African countries now have national templates, this emptied {{Africa-bio-stub}} pretty quickly. I pretty much figured that if I had to nuke one of four potential templates, I'd rather keep both nationality and occupation. Finding new splits was impossible anyway since I had to go through everything by hand which took ages. Just splitting off the 800 politicians was bad enough. As I see it, the problem is simply that the African material is way bigger than many people probably think. Remember that we used to think most of these countries would never get a nationality template? Now many of them have both generic, -bio and -geo templates. Some even have more than this. I'd really prefer if we could avoid bloating this category again. Valentinian ^{(talk) / (contribs)} 19:47, 27 November 2006 (UTC)

That makes sense. Perhaps it's one we should keep a closer eye on for more by-country splits. Grutness...wha? 23:25, 27 November 2006 (UTC)

We should indeed keep an eye on it, but I just rechecked the list and the only African entities without a national template are (drumroll): Réunion, Mayotte, and Saint Helena. So the potential for new country-level splits is somewhat limited. Valentinian ^{(talk) / (contribs)} 00:00, 28 November 2006 (UTC)

Speed(y)ing things up, slightly.

I realize this will do little (if anything) to satisfy the "just do it" school of thought that reckons the whole proposal system is completely intolerable, but I've been thinking that we might somewhat reduce the "waiting time" on this page. It's rare that a discussion continues full-tilt for a whole week, and even when it does there's nothing to stop "closure" being delayed in such cases until it's clear there's consensus (or a clear lack of same). I'd like to suggest five days, on the basis of this being the timescale of AfD, and having the advantage of being the interval from the end of one weekend, to the start of the next, if people are inclined to do a chunk of stub-sorting and analysis at same. Lest anyone be caught out by such a breakneck pace (sic), I'd also like to suggest we initiate a practice of placing notification of proposed "splits" on the category talk page of the parent (a single subst'd template would suffice for this, parameterised by section header). (I think this latter is a good idea in any event, regardless of the waiting period, I just mention it here by-the-by.) Alai 15:52, 27 November 2006 (UTC)

• I completely agree with the 5 day period. A lot of discussions just sit around waiting for that 7th day so they can be closed. As far as splits go, it sounds like a good idea. I'd like to see a template draft for that, if at all possible. ~ Amalas rawr ^{=^_^=} 16:24, 27 November 2006 (UTC)
  • OK, see {{substubprop}}, {{substubprop2}}, and Category talk:Television episode stubs. Feel free to tweak away. Alai 20:56, 27 November 2006 (UTC)
• I agree with the five days, but with a slight proviso: five days if there are no opposing comments - otherwise the debate should continue for the seven. A lot of the more procedural splits don't need a full seven days, though, and we often turn a blind eye to early creation anyway. Grutness...wha? 00:50, 28 November 2006 (UTC)
  • I think that's needlessly to complicate matters procedurally, and is better handled by my 'consensus' observation. Are we supposed to have a "mostly old business" marker in addition to a "bona fide old business" one? And this would be increase the tortuousness of the "process" and the required instructions, which is just the opposite of what I'd hoped. As regards the blind eye: we're not exactly in a position to do much else (which is implicitly part of the motivation for suggesting this). The complete absence of an "or else" argues for not making it more of a production than is practically necessary. Alai 02:25, 28 November 2006 (UTC)

• So, any word on the 5 day period? Also, would this be something that could/would be implemented on SFD? ~ Amalas rawr ^{=^_^=} 19:53, 1 December 2006 (UTC)
• Support the 5-day period, but I would like to point out that some of the stubs approved NEVER get created. So I guess this only matters to the "sexy" ones. My 2¢. Her Pegship 20:11, 1 December 2006 (UTC)
• Well, three supports is good enough for me; hopefully we can craft some wording to say something to the effect of, "five days unless discussion is on-going/consensus isn't clear" that would mitigate Grutness's concern, without needing anything so boggling as a 'double deadline'. I'm less keen on changing the timeline for SFD; IIRC almost all the deletion "processes" seem to use seven days, aside from the frenzied hotbed that is AFD. But there's probably scope for expanding the scope of what's "speediable", especially for renames that would fall within the scope of a CFD speedy. Peg, I'm probably fairly guilty on the "orphaned proposals" front, partly as I on occasion deliberately propose a range of options, anticipating that only the 'most favoured' will actually ever be created 9especially when several different options are involved). For various eastern European countries, I'm still awaiting to hear if anyone had any opinion as to whether people wanted "regions", "districts", or both... And partly, as I'm trying to prioritise the oversized categories, so sometimes when I propose a range of subcats, I only immediately implement the ones sufficient to whack it temporarily below the arbitrary magic number, on the basis that someone else might create and populate the rest, or else I'll get back to them when the cat "re-oversizes", or at the theoretical future time that every stub cat is < 800 articles... Alai 02:33, 2 December 2006 (UTC)
  • No harm, no foul. I will happily list them on the archive summaries anyway in hopes that whoever is passionate about them will discover & implement them. BTW, I agree about allowing SFD to run its 7-day course, as it may prevent some protests about rushing the process. Cheers! Her Pegship 03:05, 2 December 2006 (UTC)
    • Indeed; we've had at least one comment that seven days is too short (why it should be longer than any other deletion process escapes me, though). Alai 03:18, 2 December 2006 (UTC)
  • So, as I see it, SFD will continue to run 7 days, and SFP will go for "5 days unless discussion is on-going/consensus isn't clear. To be honest, that sort of things happens now even with 7 days. If I don't think consensus is clear or people are still discussing it heavily and they haven't quite come to a solution, I won't close it right away. It already works in practice. ~ Amalas rawr ^{=^_^=} 14:43, 2 December 2006 (UTC)
    • That's right, and that's pretty much what motivates the suggestion. Let's bear in mind that /P is basically just an exercise in notification and discussion, there's no "official" binding result (other than as regards what goes onto /ST, I suppose), so I think it's in our interests to make it as straightforward as possible. Alai 14:54, 2 December 2006 (UTC)
      • Well, I've been bold and updated the proposal procedure to reflect our discussion. Feel free to tweak away. Also, I will go ahead and move the old business marker up 2 days to reflect this as well. ~ Amalas rawr ^{=^_^=} 15:04, 2 December 2006 (UTC)

Instruction creep...?

In the spirit of Wikipedia:Be Bold, Wikipedia:Avoid instruction creep and WP:NOT#Wikipedia_is_not_a_bureaucracy I think it needs to be made clear somewhere that this is not a required procedure. If I know a stub-template is a good idea and I know it doesn't badly overlap another template, then why wait a week? ---J.S ^(T/C) 20:46, 7 December 2006 (UTC)

I agree completely. This WikiProject, like all WikiProjects, has no authority of its own. It is well-suited for discussing questionable template ideas and locating and eliminating stub templates that are unnecessary, incorrectly created, etc. But it is very clearly an optional procedure, not a required one, and this should be made more clear. Owen 20:55, 7 December 2006 (UTC)

No, this is a required procedure. We have it posted everywhere that you need to proposal a stub before you create it. Also, we have recently shortened the proposal time to only 5 days. I don't see how this is instruction creep. ~ Amalas rawr ^{=^_^=} 20:55, 7 December 2006 (UTC)

Right, it's posted everywhere. And it shouldn't be, because WikiProjects are voluntary projects designed to improve certain areas of Wikipedia, not formal projects with strict bureaucracies. Owen 20:57, 7 December 2006 (UTC)

You have reached consensus for this as an official policy? Yikes. I didn't see the policy tag on the Proposals page...?

You have expanded the creation of a small subset of templates to a 5 day application process. That is the definition of expanding bureaucracy... hmmm this makes me uneasy. ---J.S ^(T/C) 21:02, 7 December 2006 (UTC)

Okay, fine. I'm sorry for making it sound like this was an absolutely required procedure. It's just that we try to put guidelines on stub templates and categories so that they are organized in one place and follow standard naming procedures. When things get created out of process, it makes a lot of trouble for everyone. ~ Amalas rawr ^{=^_^=} 21:33, 7 December 2006 (UTC)

I don't think creating things out of process is a problem, except when it's done recklessly. There are many other times when it's a benefit to Wikipedia for people to be bold and start a template, especially when there are no clear reasons not to. As a WikiProject, I think it would make sense to reduce the bureaucratic role by eliminating the required waiting period, but suggest to editors to use this page as a way to discuss stub template ideas before they are created. If you suggest something here, and get a number of voices supporting your idea, you should feel comfortable enough to just create it, without having to wait to meet some sort of quota. Having specific required guidelines is definitely a form of instruction creep. Process is important, but not as important as helping to put the encyclopedia together. Owen 21:57, 7 December 2006 (UTC)

Consider the following points:

1. It is not required by policy. Neither is it required by policy that anyone not involved in a wikiproject can create extra work for that wikiproject by changing or creating wikiproject-specific templates and project pages. Yet it isn't done for courtesy reasons, this being a community. I'm sure that if I started creating templates relating to the Chemistry WikiProject or Astronomy WikiProject, and started adding them to articles which currently have those project's own templates and replacing the ones currently there, there would be hell to pay.
2. WP:BOLD states categorically that being bold relates to articles only, but not to categories or templates, which take far more work to clear up if mistakes are made.
3. The sheer size of process pages such as WP:CFD indicate what can happen when non-article features like categories are incorrectly named or created. With stubs, due to the automatic linking of templates and categories, any such problems are compounded greatly. Creation of stub types without some form of checking that they are suitable can create very large amounts of work to clear up.
4. There are fundamental differences between the way standard categories and stub categories operate due to the different reasons for their creation. Most features on WP are designed to be of primary use to readers. Stub types aren't - they are designed to make life easier for editors, and as such they need to be handled differently.
5. Also whereas an article can happily have many many categories, there are complaints if an article has more than about three stub types. As such, it is important to maximise the coverage with the minimum possible overlap of stub categories and the minimum possible margin of error. Having stub types that fail to "meet some sort of quota" would easily see the proliferation of stub types which would defeat this purpose.
6. Even with fairly stringent stub creation criteria, there are already over 3000 stub types - far more than most people could be expected to remember or deal with easily. Without some form of control, no matter how voluntary, the regulation of stub types would be impossible - and without regulation, the situation quickly becomes unworkable with the accidental creation ofparallel stub types and minute fragmentary splits.
7. You may not think that creating things out of process is a problem, except when it's done recklessly - but perhaps that simply indicates that you have had less experience dealing with stub types in general. Many perfectly logical-seeming stub splits have been made which have had to be deleted and re-sorted due to unforeseen problems with them. "Reckless" stub creation is actually a very minor problem compared with good-faith stub creation - as evidenced by the proportion of stub types deleted via SFD which were not "recklessly" created.

Grutness...wha? 23:12, 7 December 2006 (UTC)

One thing I'm seeing here that worries me is a the amount of "turfing" going on. I think the aim is admirable and the project is a good idea in general, but I'm getting the "stubs are ours" vibe.... and that a problem in culture. I hope clear indications is that this is an optional, but highly recomended process, be implemented. ---J.S ^(T/C) 02:24, 8 December 2006 (UTC)

What Grutness says could perhaps be said a bit shorter. WP:WSS tries hard to make sure that stub templates and categories use names and scopes compatible to similar material, since the actual process of sorting stubs is virtually impossible if this isn't followed. Stub sorting was a lot more time consuming before we implemented the current naming system. If a sorter already knows that the biographical template for Germans is named {{Germany-bio-stub}} it makes his/her life a lot easier if the corresponding template for Danes is named {{Denmark-bio-stub}} rather than {{Danskere-bio-stub}}, {{Danish people-stub}}, {{Danes-stub}} or similar and if the template for Hungarians is {{Hungary-bio-stub}} rather than {{Magyar-stub}}. WP:WSS has no intention of hindering other projects in their work, but we would also like to be able to accomplish our work which is sorting stubs. Without the naming system, this becomes impossible. The current system takes a lot less time than all the renames / rescopes we have been through in the past. Resorting 500 articles by hand because somebody simply chose an odd spelling is not the funniest way to spend an evening, but most stub sorters have spent many hours doing just this kind of work. But if you have a good idea, feel free to list it at WP:WSS/P. If the suggestion has no major problems it will no doubt be approved. Happy editing. Valentinian ^{(talk) / (contribs)} 02:43, 8 December 2006 (UTC)

It's not a policy, but Wikipedia:Stub is a guideline which states that the formal process should be followed. (Admittedly, the page could be toned down somewhat.) I'm sure that if you're an experienced editor and find a legitimate reason to create a stub template (instead of mere vanity, e.g.: "There's a cool template for project X so we / I / this page should have one also!"), you can endure the few days. Efforts to enhance a category of stub-sized articles last much longer. By the way, there are many other WikiProjects that deal with the maintenance of Wikipedia itself. If this WikiProject comes across as an exclusive club (a bit surprising considering the amount of participants), it might be appropriate to stress that anyone is welcome. Wipe 03:56, 8 December 2006 (UTC)

probability stubs

Category:Probability stubs should perhaps be merged in Category:Statistics stubs. --MarSch 17:23, 12 December 2006 (UTC)

Perhaps. There is actually a permcat called Category:Probability and statistics. ~ Amalas rawr ^{=^_^=} 17:35, 12 December 2006 (UTC)

Swedish regions

I just noticed that Alai had suggested back in October to create subcategories for two of the Swedish regions.

Cat:Stockholm County geography stubs 78

Cat:Western Götaland geography stubs 69 (both figures from October)

Nobody commented on this suggestion and I missed it myself. The problem is that a few of the Swedish permcats are oddly named. Almost all of them use the Swedish name, but "Western Götaland" differs for one reason or another and its "twin", Category:Östergötland (Eastern G.) is named "correctly". Do we really have to go through the entire process again just to correct the second category name to Category:Västergötland geography stubs? The corresponding article is called Västergötland, btw. Valentinian ^{(talk) / (contribs)} 02:04, 22 December 2006 (UTC)

If the permcats are inconsistent, perhaps it's more a case of them being taken to CFD first, and see what happens there - we can always (speedily) rename things if necessary to conform with whatever the decision on the permcats. Grutness...wha? 02:34, 22 December 2006 (UTC)

California geo stub categories

Fairly recently the {{California-geo-stub}} and {{California-south-geo-stub}} had all of the California counties added as daughter stubs (e.g. {{LosAngelesCountyCA-geo-stub}}), but currently the county stubs still point to the two main California-geo-stub categories (e.g. Category:Southern California geography stubs). There are now over 80 LA County geo stubs, and I've probably only found about half of them to convert from SoCal geo stubs to LA County geo stubs. Since the county stubs have already been proposed, approved, and created, do I still need to propose its accompanying category, or can I go ahead and create Category:Los Angeles County geography stubs and then modify {{LosAngelesCountyCA-geo-stub}} without having to get additional approvals? ^BlankVerse 03:26, 30 December 2006 (UTC)

You should propose them, but it's a formality only, really. If there are over 60 stubs, I don't think anyone will object to the creation. Best to just run it past the proposal page to make sure, though, in case there are any unforeseen problem with naming conflicts or the like. Grutness...wha? 05:25, 30 December 2006 (UTC)