Wikipedia talk:Articles for deletion/Archive 21

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 15 Archive 19 Archive 20 Archive 21 Archive 22 Archive 23 Archive 25

VfD's ridiculous size: suggestion

The VFD page is over 1,300,000 bytes - that's just the HTML. That's bloody ridiculous. In idle discussion of the problem on wikien-l, RickK says he uses dialup and has no problem, but both TBSDY and myself have problems with loading and rendering the page even on broadband, and another dialup user said they don't even try to look at the page any more.

Suggestion: make WP:VFD just an index to the daily pages. Each of these is also huge, but should be a little more manageable.

Thoughts? - David Gerard 14:04, 8 Mar 2005 (UTC)

FWIW, I have no problems with loading it (IE6, broadband). My suggestion: having seperate pages for certain deletion criteria, such as vanity, original research, etc (this is in-line with David's [I think?] previous suggestion) which would contain the votes/comments discussion, and an index of links to subpages on the main vfd page. The vfd page would be split in 2/3/4/whatever pages, the criteria for deletion would be clear and a list of all pages under vfd would be available. --jag123 14:27, 8 Mar 2005 (UTC)
That's a novel change of policy. I'm proposing keeping things just as they are now, except the main VFD page just links to the day pages instead of transcluding all of them. All the VFD nominations at once is just too much text to put on one page manageably - David Gerard 14:30, 8 Mar 2005 (UTC)
Even on broadband it takes significantly longer than it should (imo). Like the VFD header says User:Tony_Sidaway/Deletion or User:AllyUnion/VFD_List are both possibilities. Personally I think a functional page would be effectively JUST the index. The day links and the entries underneath. Something like;
  • day
    • item
    • item
    • item
    • item
  • nextday
    • item
And so on ... I do agree that it's not as functional as it should be. So Wikipedia:Votes_for_deletion/index ?? -- Dbroadwell 14:38, 8 Mar 2005 (UTC)
I for one support this change. Other possibilities include Preliminary Deletion and Categorized Deletion. None of these proposals are mutually exclusive, so we might end up with a VfD categorised by day, subject and type (whether or not it is such a blatant violation of our policy on article topics that the idea that the proposal could even be challenged seriously is laughable). Johnleemk | Talk 14:40, 8 Mar 2005 (UTC)
I support the list of links but I do enjoy going through several entries (on a single page) to see the comments, reasons, use of policy, etc. I think it would be nice if there could still be some sort of grouping (by day, for instance, would also split the page in ~5), so those who can load large pages aren't forced to click each link to see what's going on. --jag123 14:47, 8 Mar 2005 (UTC)
If you volunteer to maintain Wikipedia:Votes for deletion (full list), that would probably be ideal :-) That way we keep the full page but don't put many casual users off participating by the overwhelming size of the thing - David Gerard 15:04, 8 Mar 2005 (UTC)
It's quite easy, really. Just include the templates for all the days. The maintainer could just keep a link or bookmark to edit the page so he/she wouldn't even have to load the page itself; just the short edit page. Unless, inclusion of pages including pages isn't allowed? Johnleemk | Talk 16:10, 8 Mar 2005 (UTC)

VfD source is currently composed of lines of the following form:

{{Wikipedia:Votes for deletion/Log/2005 March 3}}

This could instead be changed to:

* [[Wikipedia:Votes for deletion/Log/2005 March 3|Votes for deletion 2005 March 3]]

An example of something like this is at:

In my experience it works very well and I think it's compatible with David's suggestion. --Tony Sidaway|Talk 15:13, 8 Mar 2005 (UTC)

I like Tony's solution at User:Tony Sidaway/Deletion, and would support that becoming the "official" format. --BM 15:32, 8 Mar 2005 (UTC)

These solutions are only temporary band-aids. As the English Wikipedia grows in size (and it will), we will be faced with this situation again in the near future. Then what, index by hour? We must either raise the bar for contributing to this cancerous problem, or continue to be overwhelmed by it further. —RaD Man (talk) 15:49, 8 Mar 2005 (UTC)
The long term solution is to gradually increase the speedy deletion criteria to cover the types of pages that always get deleted while at the same time preventing the listing of pages that are certainly going to be kept. VfD debates should only be used to cover the grey area where policy is as of yet unclear. - SimonP 16:07, Mar 8, 2005 (UTC)
I agree with Simon. Sadly, according to my surveys of VfD (User:Johnleemk/VfD statistics), the latest additions to CSD have done next to nothing. I strongly feel Preliminary and/or Categorized Deletion is needed. Johnleemk | Talk 16:10, 8 Mar 2005 (UTC)
  • Concur with Johnleemk. What would also help is combining nominations of related articles (for instance, a number of 'powerups from Nintendo games' were recently nominated, and basically the reasoning is the same for most of them). Of course, if we get more shared nominations, it must be possible to 'break out' one that people feel doesn't belong in the group. Radiant! 09:54, Mar 10, 2005 (UTC)
This is true. However, the bandaid will IMO help for at least a few weeks! - David Gerard 16:12, 8 Mar 2005 (UTC)
And in those few weeks we can try to build a policy that addresses the underlying problem. Has anyone discussed the use of categories and discussion on article talk pages to manage this. For example, a category for Possible Vanity article, which can then be discussed on the article's talk page with sysops deleting a page when the consensus appears to be that the page is vanity. --Theo (Talk) 16:21, 8 Mar 2005 (UTC)

I favor some reasonable band-aid that amounts to breaking up VfD into day-sized chunks, and/or some band-aid that makes it easy to get a topic overview and selectively participate in discussions of interest.

I oppose commingling technical issues with policy issues (we must change VfD policy in order to make the page load faster).

I would add that it does not make sense, and never has, for anyone to feel that they must systematically review each and every VfD item and cast a vote on every one. Dpbsmith (talk) 17:29, 8 Mar 2005 (UTC)

For several months the Wikipedia:Canadian wikipedians' notice board has maintained its own list of Canada related VfDs. This has worked quite well and articles related to Canada tend to receive attention from those who know the subject at hand. Perhaps this model could be built upon? Any such scheme would require several dozen lists, however. - SimonP 17:46, Mar 8, 2005 (UTC)
That's why I proposed this strictly as a format change, not a VFD policy change - David Gerard 17:52, 8 Mar 2005 (UTC)

I oppose the change. (I use dial-up.) If someone wants to make a links-only page in parallel and will volunteer to maintain it, go ahead. Do not get rid of this structure, though. My workflow is far more efficient with the whole list on a single page. It is the only reasonable way to rescan my votes to see if someone has added new evidence which could/should cause me to change my vote. It is also the only feasible way to get a sense for the common arguments and points of confusion that need to trigger a more generalized discussion of policy or procedure.

However, there are some things we should do to control the pure page size. I believe (but can not yet prove) that the pastel boxes pushed up page size dramatically. As those age off, the size should decline. Extremely long discussions can and should be untranscluded in accordance with Wikipedia:Votes for deletion/Maintenance. (My personal rule is to untransclude a discussion when I notice that it exceeds about 5 screens.) I'd also like to discourage the use of fancy graphics in signatures but that might not be feasible. By the way, if you think this page is bad, try loading VfD/Old. Rossami (talk) 19:26, 8 Mar 2005 (UTC)

As David says above, I have no problems with downloading it with my dialup modem which rarely reaches better than 49,999 bps. I have no problem with breaking it down by day, but I strongly oppose trying to break it down by categories. RickK 19:52, Mar 8, 2005 (UTC)

I think David's idea has merit. Myself, I never read the main page but simply open the /Today page (or other pages like /March_9). Radiant! 09:54, Mar 10, 2005 (UTC)

Another idea

Presently we've got a deletion policy that can be broken down into an itemized list. We can provide a VfD template for each reason for deletion (eg: a template called something like template:vfd-wwin-dict for an item excluded under the dictionary rule on WP:WWIN), and require nominators to use one of these templates. The template would add the article to a category for deletions of that type. The nominator would also have to add the item to the relevant daily log, and this would be partially automated as in the present template:vfd

To facilitate nomination for deletion, the deletion policy and WP:WWIN would show the name of the appropriate template alongside each reason for deletion.

This would have the following advantages:

  1. Nominators would have to read and understand the deletion policy. This alone would tend to curb mindless deletionism.
  2. Some of the proposed manually maintained lists would be self-maintaining, navigable categories instead.

I'm sure someone can think of disadvantages. It would be harder to nominate for deletion, perhaps? Yes, but is this such a problem? The average deletion listing stays on VfD for a week or so and is voted on by around a dozen people, each of whom is supposed to examine the article and decide whether it's encyclopedic or not. If we're asking VfD "members" to expend this amount of effort, asking the nominators to spend a fraction of that effort setting up the VfD seems reasonable to me.

On the other hand, perhaps this would be too complex and unwieldy. Thoughts? --Tony Sidaway|Talk 18:04, 8 Mar 2005 (UTC)

I like this idea, but it would be complex. What about using bots? How hard would it be to create a bot that automatically added any page that was marked with a VfD template to the appropriate VfD page? Could the same bot list every VfD debate on a central page for those who like the current system? Could a bot check to see if an article is in any of the sub-categories of Category:Canada and if so automatically add it to Canadian wikipedians' notice board? - SimonP 18:23, Mar 8, 2005 (UTC)
It sounds a lot like the old Wikipedia:Deletion requests proposal which I liked because it would explicitly move us away from a "voting" structure. As above, though, I oppose splitting the page unnecessarily. Rossami (talk) 19:33, 8 Mar 2005 (UTC)
The joy of this suggestion is that obviates the need for any extra page maintenance; the equivalent of the VfD page is generated by the category processing. The focus moves to the individual pages. --Theo (Talk) 20:34, 8 Mar 2005 (UTC)
The difficulty is that it is impossible to rely solely on categories as they have no timing mechanism. - SimonP 20:43, Mar 8, 2005 (UTC)
Is a timing mechanism necessary? The page history shows when the Deletion proposal category was added. The worst that can happen is that a deletion-worthy page survives longer than is necessary. Even this could be mitigated by the use of a Deletion agreed category; sysops would have to take care not to take such categorization on trust but I imagine that few editors would delete anything without reading it first. --Theo (Talk) 21:53, 8 Mar 2005 (UTC)

If there is a VfD problem, it is the number of articles being nominated, the amount of editor-time currently going into arriving at a consensus about all of them, and to a certain extent the conflict and ill-will that results from continuous debates about what should be included or not.

But I'm not sure this problem is the result of too many "bad" nominations -- by which I mean, a nomination where there is either unanimity or near unaninimity that an article should be kept. My impression is that most nominations obtain a reasonable number of delete votes, even though there might not be a consensus to delete as the final outcome. If this is so, eliminating "bad" nominations would have hardly any impact on the overall size of VfD.

The increasing number of VfD nominations is a result of three things:

  1. a steady increase in the rate of article-creation.
  2. the lack of consensus for administrators to have much discretion about what should be deleted, leading to very narrow speedy-deletion criteria.
  3. the lack of general consensus amongst Wikipedians as to what should be included in Wikipedia (inclusionism versus deletionism), which results in a quite vague deletion policy.

Given this, the solution to the VfD problem lies in one of the following areas:

  1. make it more difficult to create articles in the first place, so that fewer VfD nominations are necessary. I think at present this is a non-starter, as it would be viewed as very "anti-wiki" to control article-creation.
  2. change the software so that deleting an article is less permanent making it possible for deletions to be reverted; then remove the requirement that one must be an administrator to delete an article. This would make article-deletion the same as any other kind of edit. Deletion would simply be reverting the article to the state that it was in prior to creation (that is non-existence). Another way to think about it is that it would make article-creation revertible, the same as any other kind of edit. Article-creation would not be privileged over article-deletion, and both would be revertible. This might lead to creation-revert or deletion-revert wars, but that would be the same as any aspect of Wikipedia editing and could be controlled by behavioural conventions, such as the 3RR. The problem is that one would need a fairly significant change to the software to make it feasible.
  3. find a way to give administrators (or some subset of them) greater discretion to speedy-delete articles. This has been tried, so far without great success in obtaining consensus. Because of "inclusionism versus deletionism", people don't want to trust administrators to delete except in the most crystal-clear cases.
  4. clarify the deletion policy, especially on certain specific issues, so that less time is spent arguing on VfD about these cases. For example, a lot of VfD nominations and voting would be eliminated if there were consensus about schools, fictional universes, local detail, and a few other contentious areas.
  5. find some acceptable way to expedite the disposition of articles which don't fit the "Speedy Deletion" criteria but where the disposition is quite clear long before the full 5 days have elapsed. (e.g. the standard example of this being "obvious vanity").

--BM 19:53, 8 Mar 2005 (UTC)

1, is agreed to be a non-starter. Wikipedia:Proposal to expand WP:CSD failed to do much to enable 3. 4 has failed, e.g. Deletion policy/schools saw a 27 to 4 vote in favour of keeping "Any school about which we can write a non-trivial, non-stub, NPOV article," yet these are still routinely nominated on VfD. Versions of 5 have been rejected on three occasions. That seems to leave 2 as the only option for actually reducing the number of pages that are nominated on any given day. - SimonP 20:25, Mar 8, 2005 (UTC)

Please see Wikipedia:Votes for deletion/Policy consensus/Deletion criterion boxes. The discussion currently strongly opposes such a system. RickK 20:01, Mar 8, 2005 (UTC)

  • Concur with RickK. There are a substantial number of VfD nominations that do not fit neatly into categories but nevertheless have a strong consensus to be deleted. While this does seem to call for a revision of policy, that would take time and effort (and meet with opposition, as SimonP points out). A call for a strict keeping to the letter policy would hamper evolution of Wikipedia. Forced categorization of VfD votes into groups is an example. Radiant! 09:54, Mar 10, 2005 (UTC)

A random idea

Maybe VfD could be split in various identical subpages, for instance

The nominator would then throw a dice to choose which one to use[1].

cesarb 22:45, 8 Mar 2005 (UTC)

Actually, I had thought of a variation on this idea, which is completely orthogonal to the "VfD-is-too-big" issue. The idea is borrowed from Slashdot's meta-moderation, where what I am borrowing is not, repeat not the "meta" part, but the concept that every user is regularly invived to vote on a small random sampling of issues. This involves many people in decision-making, and giving each person a light load.
My idea is that periodically, every user would get a new message on their Talk page, saying something like "You can help WIkipedia by participating in Votes for Deletion. Click here..." and you'd get a page containing randomly generated links to (maybe) five VfD discussions. Your own personal VfD page, with only five items on it. Like "random page," but instead it's "five random VfDs" and you're positively invited to participate occasionally.
To the extent that people participated, this would tend to make VfD a sampling of general Wikipedian opinion, rather than a sampling of the opinions of VfD "regulars." Dpbsmith (talk) 02:20, 9 Mar 2005 (UTC)

I don't think people would like to be spammed with things they're not interested in. If they wanted to participate in VfD, they could. Unless somehow they signed up for the spamming. RickK 05:21, Mar 9, 2005 (UTC)

Hm, now that's an interesting idea. It could be made by a bot (to which you could subscribe by putting your login in a list somewhere in the User space). It does not even need an admin (except to allow the bot to run unattended). cesarb 20:23, 9 Mar 2005 (UTC)
I think Dpbsmith's idea has merit, but I believe it would be better spent on stub categorization than on VfD voting. Wikipedia has far too many uncategorized stub articles. If every user put the appropriate categories and/or tags on a random stub twice or thrice a week (which seldom requires a lot of expertise, so it can be done by most anyone), WP would be a better place. Radiant! 09:54, Mar 10, 2005 (UTC)

Yet another idea

How about people only nominate things for deletion that meet deletion criteria? That would certainly cut the size down. The Recycling Troll 22:39, 8 Mar 2005 (UTC)

Good idea. Even better: if something meets the deletion criteria, just delete it. There is just the small matter of who determines whether an article meets the deletion criteria, and how. Oh wait, that is what we are doing on VfD, isn't it? --BM 23:36, 8 Mar 2005 (UTC)

  • You think? Kappa 01:29, 9 Mar 2005 (UTC)

On a related note, it would be nice if people didn't find an article they like, and then look for the nearest deletion criterion that might possibly fit, stretching it out of all recognition in the process. And then propose that a category could do the same job. Kappa 12:09, 9 Mar 2005 (UTC)

  • The problem is that deletion criteria by necessity have a number of gray areas. There is no consensus over what exactly construes 'vanity', for instance. The policies are subject to interpretation (as is any text over a certain size). That is exactly what VfD is for. Every nomination in good faith meets the nominator's interpretation of deletion policy criteria. Radiant! 09:59, Mar 10, 2005 (UTC)
    • And btw, this is exactly the proposal that met heavy opposition in How to make VFD of manageable size above. Radiant! 10:01, Mar 10, 2005 (UTC)

Merging rather than deletion

Redirects are cheap, fun, and
easier than votes for deletion!

Apart from the obvious vanities that most everybody agrees should be deleted, a major category on VfD is *cruft (i.e. fancruft, pokecruft etc). Many people have their own POV on keeping/merging/deleting so these discussions are essentially semi-random repetitions of the same elements.

What would seriously help, is if any stub or substub article along the lines of 'X has a relation to Y' would be merged into Y (with suitable redirect). The reasoning is, that as long as X is a substub, it is better off merged with Y. Once X gets enough information to warrant its own article, it can be broken out again.

For instance,

  • Joe Unknown is the father of Jane Famous
  • Foo is a powerup in the computer game Bar
  • Jim is the owner of JimCo Ltd

To facilitate this, it might be useful if some sort of macro was made to make merging easier and/or faster. Radiant! 09:54, Mar 10, 2005 (UTC)

Redirecting and merging subtopics with too little freestanding information to support an article is already exactly what's recommended in Wikipedia's deletion policy. It's really puzzling that people don't just go ahead and do that instead of bringing them here, since it's less work for the person who wants to see the article gone, VfD readers, and especially the admins who have to clean up after the mess. Maybe people are under the mistaken impression that deleting articles saves disk space or something? --iMb~Mw 10:30, 10 Mar 2005 (UTC)
  • Exactly, so my question is, how can we get more people to merge articles? That would also help clearing up the tens of thousands articles in the stub and substub backlogs. In the 'another idea' thread above, it is suggested that every WP user could get a daily link to something random to fix. Would that help? Radiant! 12:33, Mar 10, 2005 (UTC)
  • I've run into many many cases where a merger of not just one but half a dozen stubs could make a better stub, but I've hesitated and here's why. I make the likely incorrect assumption that when people put up a stub they do intend to expand or believe that it will be expanded in due time; that's a consequence of trying to honor the "assume good intentions" guideline. By simply merging whenever it is convenient, we sort of ignore this guideline. That's my feeling, but I also feel that I might be wrong on this, that people might be putting up stub after stub because there is the thought that a concept without an article of it's own is in some way "less important" than concepts bundled together in a single article. Thus we have explosions of characters, episodes, books, etc. that could/should be bundled.
Of course, turning something to a direct can always be undone later if more information turns up to justify a freestanding article, and anyone can do that without invoking all this red tape. The flip side of assuming good faith is being bold, and I'd say that moving the text into a different article, with a redirect so the original contributor can still find it, is a lot friendlier than hiding the original link in the archive. iMb~Mw 13:49, 10 Mar 2005 (UTC)
Oh, heh, I forgot to mention what this has to do with deletion ... by nominating for deletion, putting my self in my fellow's shoes, the outcome is perhaps seen as a community decision so that the "weight of responsibility" for the outcome does not rest sole on the nominator's shoulders, whereas merger is a personal act that might require individual explanation and negotiation. I'm speculating, but I don't think I'm too far outside the probable. Courtland 13:08, 2005 Mar 10 (UTC)
  • I think the reason stubs are created is more to do with convenience, e.g. it's easier to create an article from a red link than add content inside another one, and red links encourage users to do just that. Kappa 13:41, 10 Mar 2005 (UTC)
(this in reply Courtland) to Yes, that's probable, though I don't think I'd phrase it as kindly (and yes, the little yellow box is a joke, though a more prominent mention of the alternatives at the top of VfD might not be so horrible). --iMb~Mw 13:49, 10 Mar 2005 (UTC)

There are really two cases. The first is where the content of a stub or sub-stub is merged, but the entry is maintained as a redirect. Any editor can do this. You don't have to be an administrator. The second is similar, but the editor doesn't think that the entry needs to be retained as a redirect and prefers that it be deleted. That is, the goal is the same as when a person votes on Vfd, "Merge, then delete", a vote that many admins are reluctant to implement because of GFDL reasons. A non-administrator can achieve this by merging content, then submitting the resulting redirect to Wikipedia:Redirects for Deletion. Together, if successful, these amount to deletion of the original article.

I think there are two reasons why people don't do this:

  1. people want some kind of community sanction for the merge. Just merging content can seem a little bold. VfD is a place to go to get this consensus. (I've found it isn't a great place for this because people are confused about what you want -- at least they were when I tried it.)
  2. in the case where you want the redirect deleted after the merge through RFD, there is the issue of history. which is a concern on RFD the same as on VFD. --BM 17:42, 10 Mar 2005 (UTC)

I agree that people need to be WP:BOLD more often when it comes to merging lonely stubs, and even (in some cases) more substantial articles; at the same time I recognize the need in some cases to search for a bit of community consensus. It isn't VfD to which people should be coming to find that consensus, however. I would suggest the following for editors who wish to merge.

  • If an article is a substub, and no work has been done on it since it was created many months ago, redirecting to a more comprehensive treatment of a larger topic is almost always an improvement, and should be relatively uncontroversial.
  • For more substantial stubs—particularly those that have received more recent attention—one can start with a note on the the article's talk page, and possibly a note to the article's regular contributor(s). Something along the lines of "I believe this article should be merged with foo, for the follwing reasons x, y, and z. Does anyone see any reason why this might be inadvisable?" Give it a few days, and if there are no negative comments then proceed with the merge.
  • For really big merges, or changes in the structure of whole groups of articles, or merges that have generated controversy, one should probably go through Requests for Comment. You should pull in a lot of response from seasoned editors, and the process has a somewhat less adversarial feel than VfD.

Regardless, it would help a great deal if people would only nominate articles that (they believe in good faith) are genuine candidates for deletion. VfD should not be a dumping ground for "I'm not sure what to do with this article". I would love to hear any ideas on how we can convey that point more clearly to editors. --TenOfAllTrades | Talk 18:14, 10 Mar 2005 (UTC)

One of the problems I find with Wikipedia is that there is really no forum in which to collectively plan what might be called the "supra-article" organization of the Wikipedia. While within an article ("infra-article"), editors collectively have total freedom to refactor and restructure articles, once one gets above the level of the article, things get very sticky and cumbersome. Anybody can create an article, but people trying to organize a subject area and to discuss how to refactor its multiple articles and categories have no reasonable forum in which to plan that. One is obliged to either go to the Talk page of a particular article in the subject area, where one runs up against people who have a stake in at least maintaining the integrity of that article, or one must try to make the arguments in the noise of VFD, CFD, RFD, etc, etc. In the latter case, there is so much noise related basically to dealing with vandalism (vanity articles, etc), that it is hard to get the necessary attention. Indeed, on VfD, proposing something for deletion because it logically should be part of some other, broader, article, is not even a recognized grounds for a VfD nomination, and proposing something for deletion, even if the aim is to move the content elsewhere, is swimming against the generally inclusionist tide in VfD. There is no forum where one can put forward and get consensus for, and then implement over time, an "editorial plan" covering a large multi-article, multi-category, subject area, the achievement of which involves the creation, renaming, deletion, redirection, merger, etc of multiple articles. It has to be done bit by bit, and any of the deletion steps have to go through VfD, which is a dice throw. --BM 19:33, 10 Mar 2005 (UTC)

That's where Wikiprojects can come in. We don't use them enough, but when they do get used they seem to work pretty well in getting at least some consistency. --iMb~Mw 20:55, 10 Mar 2005 (UTC)
Most of the Wikiprojects seem to be about planning the creation of a subject area, rather than about refactoring an existing one. If there were Wikiproject that involved significant refactoring, it would still have go through piece-meal VFD, CFD, RFD, etc to implement each step, with the risk each time that some fickle or unexpected vote would throw the whole editorial plan out the window. --BM 21:05, 10 Mar 2005 (UTC)
  • Refactoring doesn't require deleting anything. Redirects are cheap. Kappa 22:06, 10 Mar 2005 (UTC)
  • Perhaps editors who wish to plan and undertake a significant refactoring should be encouraged to start appropriate Wikiprojects...the question is then how should they be informed that this is a possible (or even preferred) route? I concur with Kappa, there's very little need for VfD and RfD during refactoring. If merging is being done properly, GFDL concerns would prevent most outright deletions. Where deletions are required, they should be eased by references to the relevant Wikiproject discussions...I would hope. CfD might be a sticking point in this, as I can see it being an important part of a major refactoring. Then again, if the refactoring is done, deletion of depopulated categories shouldn't be contentious. --TenOfAllTrades | Talk 22:27, 10 Mar 2005 (UTC)
  • I am presently compiling a list of all maintenance projects not related to a specific topic (e.g. typo squad, image labeling, etc). There are some problems with maintenance, but the main problem is this: stub sorting has a backlog of nearly 25000 articles. And it seems that stubs (and substubs) are being created faster than they are expanded or categorized.
  • Perhaps we could start a Wikiproject:Stub Merging, the purpose of which is to find groups of related stubs and merge them into lists and the like. It could have a talk page that discusses how best to do this, and where the borderline for merging lies. A Vote for Merging, if you will.
  • Regarding the supra-article organization of Wikipedia, I present the following idea as food for thought. I realize it's probably far too bold for implementation, so think of it as a thought experiment...
    • Lock the category system. Only admins may create new categories, rename existing ones, or change the parent/child hierarchy of categories. Add a simple page 'category request' where people can ask for new ones, and it gets added if after 5 days there is no objection or consensus holds in favor.
    • Note that the Wikiproject Stub Sorting already does this - if you want a new category for stub sorting, you must propose it, establish likely usefulness, and wait a few days for consensus.
    • Related to this, lists are often used as a duplicate of categories, on grounds that a list can contain redlinks to articles not yet written. However, a category main page can contain descriptive text, therefore it can also contain these links. Centralized information is better than two divergent systems.
  • Radiant! 12:29, Mar 11, 2005 (UTC)

I like Radiant's idea, but in the spirit of brainstorming here is something really radical that plays off his idea:

  1. Ensure that all categories and articles flow down from a very few "top level categories". To do this, we would require that every article and category should be created in at least one category. Thus every article and category would trace its way up to at least one (and perhaps several) of a few "top level categories". Perhaps the top level categories on the Main Page are a reasonable place to start, but there should not be very many "top-level" categories.
  2. Eliminate VFD, CFD, RFD, and probably a couple of other FD's.
  3. For each top-level category, create a "Subject Area Management" page, where people will request, discuss, and vote on category deletion, merges, moves, and article deletions, moves, rename/redirects, and merges. Subpages of these would be used for discussing how the categories should be applied to articles, for gaining consensus on an "Editorial plan" on what articles are needed, and general discussion of deletion policy, categorization policy, etc.
  4. The category system might be locked, if necessary, in which case category creation would also be handled on these pages. That is independent of the rest of the scheme, and I don't know if it needs to be locked. If not locked, editors interested in the categories would need to monitor them and category deletion would become more of a concern.
  5. If any of the top level categories is too big, the management page could be associated with a second level category.
  6. Instead of VFD, CFD, RFD, where we now have "inclusionists" versus "deletionists" shooting it out in the abstract on articles being added all over the Wikipedia, we would have groups of editors interested in large subject areas discussing and trying to gain consensus on how that subject area should be presented overall within the Wikipedia and what the standards for inclusion are, categorization, how the topic space should be divided over articles, standard templates to be used, etc, in those subject areas. The "xFD" pages would be replaced by something similar to large "Wikiprojects" for the major subject areas of the Wikipedia. Each of these might have a number of smaller "Wikiprojects" within it. --BM 17:15, 11 Mar 2005 (UTC)
I believe a lot of unnecessary VfDs are made in part because of bureaucratic policies that appear to have discouraged people in redirecting articles and in part because of newbie ignorance. Making it easier to redirect an article (or at least making it obvious) would be a great help. Another thing: I'd like to see how BM's proposal would deal with vanity pages/advertising. Johnleemk | Talk 11:10, 13 Mar 2005 (UTC)
  • I agree with that. It would be an easy matter to rewrite some of the basic templates to make this more clear. The bright yellow box above would be useful on several VfD-related pages for newbies. Radiant! 12:06, Mar 13, 2005 (UTC)