Wikipedia:Categorization policy

From Wikipedia, the free encyclopedia

✘ This Wikipedia page is currently inactive and is retained as a historical archive.
Either the page is no longer relevant or consensus has become unclear. If you want to revive discussion regarding the subject, you should seek broader input via a forum such as the proposals page of the village pump.

Contents

[edit] This is a discussion, not a vote

Please add opinions and discussion to the talk page, and add well-formulated amendments or additional suggestions below.

Please bring this page to the attention of others by linking to it from whatever relevant discussion pages you can think of.

[edit] Description

Wikipedia strives to be the sum of all human knowledge. However, for knowledge to be useful, it must also be accessible. The obvious way of making the Wikipedian articles more accessible is categorization.

Some Wikipedians feel that the category system has become overly complex. They have concerns about inconsistent naming, partial redundancy with other categories and/or lists, and what they feel is overspecialization to near-empty categories (e.g. Finnish botanists). The category renaming and deletion page has a backlog of two months.

It is suggested by these users that it would be better to impose a standardised categorization system in Wikipedia. They argue that for individual articles, the process of letting every user write about whatever he wants works great - but for the overlying structure, it is better to develop a consensual system that is internally consistent.

[edit] Proposed policy

[edit] Locking categories

The category system should be decided upon by the community consensus, rather than by any random user on an individual basis.

  1. Any user can make suggestions to Wikipedia:New category requests. After five days, the category will be created unless there is serious consensual objection, using existing categorization guidelines.
  2. To ensure no wrong categories are created, only admins can create or rename categories.
  3. Only admins can move categories into (or out of) other categories.
  4. Any user can move articles into (or out of) categories.
  5. New category requests will ensure that new categories comply with category standardization (e.g. German cities vs. Cities in Germany), as well as proper capitalization and spelling.
  6. This is supposed to obviate the excesses of WP:CFD, and New Category Requests are expected to quickly die down into a couple per week.

Note that the Stub Sorters already use a similar system for creating new stub categories and related templates.

This is open for discussion on the talk page. It is not presently being voted on.

[edit] Withdrawn policy suggestions

The suggested policies on lists and nav.templates have been withdrawn, because of a variety of good reasons and comments to oppose them. See the talk page for details.

[edit] Redundant lists

To improve consistent categorization, all lists that are a mere series of links (e.g. List of computer viruses) should be converted to categories. Any list that is redundant with an existing category should be a redirect to the category, after merging its links and redlinks into there. See also Category:Lists_that_should_be_categories.

One advantage of lists over categories, is that a list can contain redlinks of articles that haven't been written yet, and categories cannot. However, since a category main page can contain text (e.g. Category:Songs), the redlinks should instead be put there. It would be preferable if any user can add new redlinks.

If this is technically problematic, or a (potentially long) list of redlinks at the top of a category is considered ugly, the redlinks can instead be kept on the category talk page.

The major technical problem with categories compared to lists is that categories are horrendously inefficient, requiring hundreds or thousands of times the resources per page view. This extreme cost disparity arises because the contents of category pages isn't cached. Instead, it's generated anew, using a new database query and page build with every page view. A normal list page is simply loaded from the Squid cache server closest to the viewer, a very inexpensive operation. At present, 6 or so Squid cache servers handle about 80% of all hits to the sites, with some 40 other machines needed to handle the rest.

Lists that contain information in addition to links (e.g. Fictional chemical substance) should, of course, be kept.

The description of lists gives three purposes for lists: information, navigation and development. It may be the case that navigational lists are obviated by categories, and developmental lists could be placed inside category text as specified above. That leaves informational lists, which tend to be very encyclopedic in nature.

  • You also have to remember that lists can be ordered in other ways than alphabetic (like categories). Also, putting redlinked articles somewhere in cats will look odd because they won't be listed like other articles. So I think some navigational lists have become obsolete because of cats, but I don't see a reason why we can't have both. It's always easier if you can find info in multiple different ways. Mgm|(talk) 13:42, Mar 19, 2005 (UTC)

[edit] Redundant templates

Certain groups of articles use templates for inter-navigation, that are partially redundant with categories. While many of them are useful (e.g. Polish history), others are arguably less so (e.g. Orcs, which is nominated for deletion (update:deleted) and Buddhism which recently managed to survive a vote for deletion).

The problem with having a template for a category is that they can easily become divergent. A solution would be to implement software that displays a category as a navigational template, or a bot that automatically updates a template from a given category.

A consensus might be achieved on for which categories a navigational template would be useful. A criterion might be whether the template adds a meaningful ordering (other than alphabetical) to the topics in the category.

[edit] Technical solutions

Technical solutions may make a policy change unnecessary and provide additional benefits.

[edit] Combining categories

This proposal and the discussion has been moved to User:SebastianHelm/categorization/combining. Similar proposals have been presented at

[edit] Related proposals