Frankly, I think that the space-colon-space way of separating subcategories is clumsy. A simple colon (to take Wikipedia's example) would serve much better, and wouldn't result in confusing underscores in the URL. Adam Conover 17:12, 16 Feb 2004 (PST)
Latest explanation of why the Rules need changing
Things I want to change:
Get rid of the space-colon-space
- It's ugly, and it originates from a misunderstanding of the nature of colons. They are meant to mark a special Namespace. Any use of colons aside from this is confusing, as it makes people think there is another namespace when there isn't.
But, while doing this, don't just replace space-colon-spaces with subpages. Do not use subpages aside from a few exceptions.
- Wikipedia has found from long experience that Subpages are evil.
- Let articles determine their own context. Although you may think that an article only makes sense in a certain context, and that therefore it should be a subpage in a certain category, it may make sense in another context that you are unaware of.
- If an article needs to be moved to another context, it's much easier to just change what pages link to it, instead of moving the page to put it in another category. Also, multiple contexts are difficult and annoying to handle with Subpages.
Unless the term you wish to create a page for is a proper noun, do not capitalize second and subsequent words.
- This is also an established Wikipedia convention. Wikipedia:Naming_conventions_(capitalization)
- This is mainly because if you link to an article within running text, it looks unnatural and weird. If you wouldn't normally capitalize a word in (written) conversation, do not capitalize its page name.
Argh... here I was talking about how I thought Subpages may be OK for the Mozilla Knowledge Base, but I'm becoming increasingly convinced after reading through deliberations on the subject that Subpages are not a good idea except for a few specific instances, even though they are much better than the silly colon-space-colon. I'm going to write a better article above this one, but for what I said earlier continue reading below...
I think the space-colon-space model sucks as well, any attempt at creating a hierarchy of pages should be handled with subpages. Although I think that subpages are a horrible thing, they can occasionally come in handy on a Wiki with overlapping articles. Categories are created with a slash like this: /Sub-rules We don't want to use those colons, first of all because those aren't just manually created in Wikipedia, they are software-based namespaces for special purposes. That's not what we're doing here, we're trying to organize articles into categories. Our current method is far too unwieldly, the article names are painfully long. At least with the slash/categories model, you only have to type part of the full article name when you are inside one of the categories, with the colons you have to type the full article name all the time.
There is actually a meta-Wikipedia article on why using categories is bad for Wikipedia, but it's obvious that this approach is better than the colon approach, and I will now make the case as to why the Wikipedia objections do not apply to the Mozilla Knowledge Base, and the slash/category approach actually works the best.
- Accidental Linking is important.
- In Wikipedia, categories make Accidental Linking impossible, because nobody can know what category an article belongs in. Is Scientology a religion? A scam? A conspiracy theory? The answer is most likely all of the above, and the result is hundreds of fractured articles when we would best be served by one article, or a few articles linked to from a disambiguation page.
- The Mozilla Knowledge Base is different. In the Mozilla KB, there are a limited number of obvious categories. These are the different programs that we are writing about. When writing a FAQ for Mozilla Firebird, it makes sense to make it a different article from Mozilla Suite, Camino, etc. Although you could make disambiguation pages instead of categories, this isn't useful because every disambiguation page will have the same links, i.e. to one different article for each different program.
- We want to avoid useless duplication of articles
- In Wikipedia, endless duplication of articles is encouraged by a hierarchical hard-wired category scheme.
- In the Mozilla KB, there are certain obvious and vital duplications that we must have in the articles as long as we have multiple programs that we are supporting. When we answer the question, "how do you set up the Enigmail plugin", there should be a separate page for Mozilla Thunderbird and Mozilla Suite, we don't want to confuse people, but the articles should have the same logical name. How can they have the same name and not overlap? By being in different categories.
I do want to say, however, that I think that having categories of any kind beyond the obvious programs is bad for the same reasons that it is bad for Wikipedia. Ideally each program would have its own separate Knowledge Base Wiki, just as Wikipedia has different wiki's for each language, but they can link to the different languages that you can find the article in, and if you go to an article and there isn't a translation for your language, that is a good prompt to translate it or write a similar article in your other language. Howver, barring that, we can implement such a solution ourselves using the category system.
Categories beyond the separate programs defeat Accidental Linking, and are hard to remember and type. Instead of having a "FAQ" category, just have a FAQ page that links to the different questions that one might ask. Then I can merely write the logical link, "Deleting Mail", and if an article exists under that name, I'm in luck! I don't need to figure out whether it is a FAQ or a Hints & Tips or whatever.
If this sounds like a good plan to you folks, we should begin implementing it immediately, before this wiki grows too large to make it practical to change the linking strategy. --Nelson Pavlosky 15:27, 2 Mar 2004 (PST)
- if i want to add some stuff to the theme dev page, can i? or should i wait until we're done shuffling stuff around? also, several theme dev pages exist now, which one, if any, is the real one - which one should i work from?
- as for the categories and stuff, is this along the lines of what you envision: a Themes page about themes in general, which would link to Theme Development with links to Theme Tips; instead of a structure like: Themes/Development/Tips?
-Miahz 20:52, 5 Mar 2004 (PST)
The only thing I want to see happen is that it's easy to read the individual article titles. I'm going to put Nelson in charge of changing things for the better, and will unlock the front page so you guys can tweak. --jason
- are you open to changing the css layout to help fix that? i wouldn't mind hacking at it a little to see if we can get something a little more flexible. it's already busted in IE 5 anyway, so it could probably use a little reworking.
-Miahz 16:09, 5 Mar 2004 (PST)
- Actually, I lied. I don't think the Developers page should have ANY Categories, so it's not a perfect demonstration. I think that the different programs probably need Categories. However, this does get across my point that Categories are bad, and we should minimize their use.--Nelson Pavlosky 22:30, 3 Mar 2004 (PST)
General guideline: Whenever possible, please cut the article name to just its title, without a Category. Rely upon link pages to collect links that are all in the same category, so that if you change your mind you can just change the links without changing the name of the article. Also, people from other Wikis or websites can easily link to our article on, say, em vs. ex -- Nelson Pavlosky 21:22, 3 Mar 2004 (PST)
- what the heck is going on here? are people allowed to go around and make dramatic changes like this? i agree that "_:_" category separator is stupid, but i don't understand what you're doing with the categories themselves. there's now several copies of the Dev pages floating around. and i don't know about putting loose pages all in the root. things do need to be in categories. i wrote "em vs ex" specifically for the theme development page, and it is out of context anywhere else. how much harder is it to link to it if it's in dev/theme_development/? there will potentially be many small little pages about theme development that will be completely out of place and make no sense unless in a "theme development" category. and how do you handle title collision? if you intend for pages to be category-less, then you're gonna have to draw up some new guidelines for titles/page creation for people to follow from now on. existing pages shouldn't be automatically dumped into the new structure, because they weren't written for it, like "em vs ex." if you absolutely have to reorganize everything, then do just that - and don't touch the content while you're at it. it makes changes easier to track and back out if they're not all combined. i think this whole topic could use some discussion before a "standard" is settled upon. i've read your posts, and some of the meta-wiki articles about -pedia articles, and i'm still not sure what the best approach for this support knowledge base would be.
-Miahz 00:19, 4 Mar 2004 (PST)
I disagree with most of the Rules. Here's my breakdown of it:
- All link words should start with a capital letter.
Unless the term you wish to create a page for is a proper noun or is otherwise almost always capitalized, do not capitalize second and subsequent words. Initial capitalization does not matter, it is irrelevant. The Wiki software always capitalizes the first letter of an article's name.
- When possible, follow the existing categorical structure for new categories and pages.
When possible, remove the Categorical structure and use just the article title. Putting a category in the name doesn't really help us find it. If we do this right, a simple Search should turn up the article, or better yet just hitting "Go" will take you to the precise article you're looking for, because you don't need to know the Category it is in.
- Subcategories are shown off by using "space colon space" ( : )
Goodness no, that's the main thing we're fixing, use a "slash" (/) with no spaces.
- Good: Firefox : Tips : Profile
- Bad: Firefox:Tips :profile
Good: [[Firefox/Profile|Profile]] (when on a page relating to Firefox, just [[/Profile|Profile]]) Bad:[[Firefox : Tips : Profile]]
- When possible, use short page titles. This eases linkability and avoids the current layout bug of long titles overlapping the search box. There's no need for a link to include the entire grammatically complete form of a question, especially when two descriptive words would suffice. Following the example above:
- Application Name links should only use the App Name, not "Mozilla App Name" except the Suite, which should be linked to and called "Mozilla Suite", not "Mozilla", "Suite", "Seamonkey", or any other name.
- Layout issues or other things should use Gecko as the App Name. We need to work out what to use when something affects more than one app, or if we should just split them apart or use redirects.
When something affects more than one app in a way that it would be wasteful to split up the articles because they would be practically identical, dispose of the Categories, and just have the plain article title. Only split up the articles by App Category if confusion would result from a united page because the information does not really overlap.
Major Revision, October 2004
I've just done a thorough rewrite of the rules. They hadn't been touched since March of this year, and they were greatly out of synch with the conventions that people have generally been following, so I rewrote them to fall into line with what we contributors have actually been doing. Hope no one minds that I did this. It seemed necessary, and I don't really know why it hadn't been done by anyone sooner. Wintogreen 08:46, 26 Oct 2004 (PDT)