Brion sarcastically wrote:

Wow! Just like article titles. Maybe we should let only sysops name articles, then everyone else can fill in the information.

But, they might repeat information or organize it badly. Better to let sysops define the structure of the article, then everyone else can fill in the bodies of the paragraphs.

I was proposing a voting scheme so why the straw man? I know and accept we are a wiki but do we allow the wiki process to drive our software developement? Isn't forming relations in a database that a SORT command could operate on more of a software thing? Wiki is not a panacea and we are treding into uncharted waters - I'm not aware of another wiki implementing a category scheme successfully. Are you?

Either way, I am not advocating a "sysop-only" system on top of some broad staring categories - at least until we establish a framework for how a category system will work. Once that is set-up and working well, then we can consider whether or not it is wise to open up the floodgates and let people make weird little sub-categories the wiki-way.

Having category aliases (just like redirects) and letting categories include other categories would make this "problem" moot.

Perhaps - so long as we have an RC that can be effectively managed. Of the 3000 edits made a day on en.wiki I review about 1000. Most people review far less and only at certain times of the day. There is great potential for categories to become nearly as numerous as articles real fast. That will clutter the articles (or their meta namespace) and not represent an effective way for people to sort articles.

I am very strongly against a category scheme that is limited or sysops-only. I *want* my obscure sub-categories.

I've ALREADY stated that I want to just start small, at the top level, then phase-in voting to increase the number of categories and THEN consider opening it up further. Please do not mischaracterize what I stated - I DID NOT say that this would be something limited to only sysops. Voting includes everyone who is interested.

Also, how is anybody else going to know what the categories are? Person A creates a bunch of really obscure sub-categories for a time. Then moves onto other things. Not knowing about the work of person A, person B creates a bunch more very similar sub-categories in a similar area. Now there two very similar categories. Then person C does a sort based on person A's subcategories (assuming person C could guess what those might be).

This could get out of hand if we do not first devise a way for us to find out what different categories are. Different people will categorize things in different ways and soon nobody will be able to remember what syntax they used for a category. This happens all the time in badly created databases; Bay Area Rapid Transit, Bay Area Rapid Transit District, BART, bartd are all the same thing in the real world but to the database they are each different.

Category redirects would help here but before that we would have to establish naming conventions to minimize duplicates in the first place and maybe a flag on RC to indicate that somebody just categorized an article. Then there needs to be a centralized place for all categories to reside so they can be mangaged there.

How such a system would work needs to be made clear and we need people who are familiar with how the system works so that they can effectively manage such a system. A phased approach is needed - that is all.

This is adding a great deal of complexity to what we already have and exposes many non-database-oriented people to the complexities of database design so pardon me if I'm a bit weary about us just jumping-in head first on this.

KQ has already expressed many reservations about the ugly filtering issues that a category scheme raises. I'm just trying to make sure that if such a system were established that we do it right and minimize negative side-effects.

-- Daniel Mayer (aka mav)