You are not logged in.
Categories list
This is the current proposal of the ArchWiki categories structure. Please comment on it, and I will ammend the list as we go.
[Language]
--[by category]
----[About Arch] (General info, jargon dictionaries, FAQs, etc)
----[Getting and Installing] (Downloading and installing Arch)
----[Software] (Installing software, managing repos, packages, system configuration)
------[X Server]
------[Desktop environments]
------[Package management]
------ etc.etc.etc...
----[Hardware] (Installing drivers, troubleshooting, system configuration related to hardware devices) *2
------[Graphics] (Graphic cards, monitors)
------[Input devices] (Keyboards, mice, tablets)
------[Imaging] (Cameras, scanners)
------[Optical] (Setting up CD/DVD drives)
------[Storage] (Hard drives, RAID, EVM, etc)
------[Printers]
------[Sound]
------ etc.etc.etc...
------[i586]
------[x64]
------[Laptops]
----[Security] (Security, firewalling)
------ etc.etc.etc...
----[Networking] (Networking-specific hard/software administration)
------ etc.etc.etc...
----[Customizing]
------[Performance]
------[Tips and Tricks]
------ etc.etc.etc...
Following sections should introduce users to software and how to get help while using various apps, also to troubleshoot application-specific problems:
----[User's Guide] (Tasks carried out on day-to-day basis by avg. users)
------[Audio/Video] (Installing codecs should be in SysAdmin:Software, tho)
---------- etc.etc.etc...
------[Office] (Using office tools)
---------- etc.etc.etc...
------[Graphics]
---------- etc.etc.etc...
------[Internet]
---------- etc.etc.etc...
------[Emulators] *1
----------[Vmware Workstation]
----------[Vmware Server]
----------[Xen]
----------[Parallels]
----------[User Mode Linux]
----------[Wine]
----------[Win4lin]
----------[Dosbox]
----------[Dosemu]
----------[Mame]
----------[NES]
----------[Scummvm]
----------[Other]
------[Educational]
---------- etc.etc.etc...
------[Utilities]
------[Development]
----------[Software building]
----------[Arch development]
----------[Resources]
---------- etc.etc.etc...
------[Eye Candy]
--[by type]
----[FAQs]
----[howtos]
----[guidelines]
----[tutorials]
----[books] (see Page Templates Guide on ArchWiki for explanation of what 'books' are supposed to be.)
*1 Need to cut down the number of subcategories to at most 7. Choose 6 good emulators / emulator classes and one is reserved to 'other'.
*2 We need adjustments to cut the number of subcategories down to 7. However, this 7 subs rule may not apply to this (Hardware) category. What do you think?
ArchWiki site structure
Please also take a look at this thread:
http://bbs.archlinux.org/viewtopic.php?t=26593
This is a proposal to divide the whole of ArchWiki into readable articles, and tools used by wiki editors.
[root]
----[ArchWiki]
--------[Language 1]
------------[Categories]
--------[Language 2]
--------[Language 3]
--------[...]
----[ArchWiki Tools]
--------[Language 1]
------------
------------
------------[Stub articles]
------------[Translateme articles]
------------[Accuracy articles]
------------[Special Pages]
--------[Language 2]
--------[Language 3]
Offline
Possible sub-categories for Emulators category
-------[Emulators]
---------- [Multi-OS]
-------------- [Vmware]
------------------ [Workstation]
------------------ [Server]
------------------ installing vmware tools in an archlinux vm
-------------- [Xen]
-------------- [Parallels]
---------- [Linux]
-------------- [User Mode Linux]
---------- [Windows]
-------------- [Wine]
-------------- [Win4lin]
---------- [Dos]
-------------- [Dosbox]
-------------- [Dosemu]
---------- [Consoles]
-------------- [Mame]
-------------- [NES]
---------- [Other]
-------------- [Scummvm]
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Possible sub-categories for Emulators category
-------[Emulators]
---------- [Multi-OS]
-------------- [Vmware]
------------------ [Workstation]
------------------ [Server]
------------------ installing vmware tools in an archlinux vm
-------------- [Xen]
-------------- [Parallels]
---------- [Linux]
-------------- [User Mode Linux]
---------- [Windows]
-------------- [Wine]
-------------- [Win4lin]
---------- [Dos]
-------------- [Dosbox]
-------------- [Dosemu]
---------- [Consoles]
-------------- [Mame]
-------------- [NES]
---------- [Other]
-------------- [Scummvm]
IMHO, just put everything in the emulator category. Too many levels is silly when you're only ever going to get one article on most of those.
Offline
IMHO, just put everything in the emulator category. Too many levels is silly when you're only ever going to get one article on most of those.
Agreed... I would use:
-------[Emulators]
---------- [Vmware Workstation]
---------- [Vmware Server]
---------- [Xen]
---------- [Parallels]
---------- [User Mode Linux]
---------- [Wine]
---------- [Win4lin]
---------- [Dosbox]
---------- [Dosemu]
---------- [Mame]
---------- [NES]
---------- [Scummvm]
Alphabetized, of course 8)
Offline
Why don't you put this list in a wiki page of its own, for discussion and group editing?
I think its very well thought out, good work!
Dusty
Offline
Maybe "Boot Process" is a subcategory for "System Administration"?
Categories "by type" and "by category" are real or only virtual?
About WM:
KDE, GNOME, XFCE4, *box (fluxbox, openbox, blackbox), *wm (icewm, fvwm, twm, etc) and others?
What about different shells (bash, zsh and others)?
Offline
Maybe "Boot Process" is a subcategory for "System Administration"?
Categories "by type" and "by category" are real or only virtual?
Hmmm, let me put it this way.
Say, you have a tutorial about configuring Xorg. That article would belong to both:
1. [by type]-[tutorials]
2. [by category]-[System Administration]-[Software]-[XServer]
About WM:
KDE, GNOME, XFCE4, *box (fluxbox, openbox, blackbox), *wm (icewm, fvwm, twm, etc) and others? What about different shells (bash, zsh and others)?
I see a few problems with this tree:
1. When we are finished, we'll have lots and lots of categories that are called the same in most languages. For example, "KDE" category will be called "KDE" in any language. But it would be silly to call it "KDE (some language)" if you know you're already in the section dealing with that language.
2. We will have problems with the number and depth of categories, and category tree respectively. We must limit the maximum number of subcategories. I have suggested 7, as it is the max number of items that a human brain is considered to be able to process simultaneously. Therefore, you need 6 'sticky' items, and 1 called 'other'.
To account for tree depth problem (i.e, having to click more than 3~4 times before you reach your articles), I have thought of introducing Guides and Tutorials. Those are collections of related articles. For example, if you have many different articles on KDE, you just need to collect references to those articles into an article named "KDE Tutorial" or "KDE Guide". You may even collect more gudes and tutorials to form a "Desktop Environment Book". Therefore, I don't think stressing the tree with too many categories is actually necessary.
Offline
So do you think to name categories (e.g. Harware) in all languages the same name, when it can't be translated? But there is a problem with parent categories. For example, category Hardware will have number of parent categories as number of languages.
But I realize that nameing with Hardware (Lang) is silly. So what to do with it? I like idea of gentoo-wiki. It would be very nice if we use the same structure.
Now I uderstand idea of tutorials and books, thank you.
And another question. Where to put not fully translated articles and stub?
Offline
So do you think to name categories (e.g. Harware) in all languages the same name, when it can't be translated? But there is a problem with parent categories. For example, category Hardware will have number of parent categories as number of languages.
Uh. I don't quite understand you. Well, here's what I've thought about. Hardware doesn't need to be called the same in every language. For example, in Serbian, it would be called Хардвер. However, I see that some Germans call it the same Hardware. Anyway, if you look at the tree, you'll notice that the root of the tree is the [Language]. So, no. Hardware will not have many parents. Just [System Administration] parent. And there would also be multiple [Hardware] categories each in its own [System Administration] under its own language. That's the prob.
But I realize that nameing with Hardware (Lang) is silly. So what to do with it? I like idea of gentoo-wiki. It would be very nice if we use the same structure.
Now I uderstand idea of tutorials and books, thank you.
I have never been a user of Gentoo. I don't really like the gentoo-wiki. I prefer user-oriented wikis like the suse wiki, or some other.
And another question. Where to put not fully translated articles and stub?
Yes, that would be [translateme]. You put translatio where it's supposed to go, (appropriiate category, that is) and just mark it with {{translateme}} at the beginning, so people would know that those are incomplete. The question is, where do we put [translateme] category, and the like.
I was thinking maybe we need something like:
[ArchWiki]
----[Language]
--------[etc etc etc]
[ArchWiki Tools]
----[Stub]
----[Accuracy]
----[Translateme]
--------[ru]
--------[sr]
--------[de]
-------- etc
----[Templates]
----[etc etc etc]
Offline
I've never been user of Gentoo also , but I like their wiki. Yes, root of the tree is language, but now if 2 languages contain the same category (with the same names), wiki thinks that it's only one category. That's the problem (like you described with KDE). This problem solves easily if there were different domains for each language, but I don't know, how to solve it in our situation.
I think it's better to put not fully translated and stub into Language section. Because I think there is no sense in putting all the stub (written in different languages) in Wiki Tools, th same with not fully translated. At level of "by category" and "by type".
Offline
don't miss the non i686 sections ;-)
Offline
I think it's better to put not fully translated and stub into Language section. Because I think there is no sense in putting all the stub (written in different languages) in Wiki Tools, th same with not fully translated. At level of "by category" and "by type".
IMO, {{stub}} is reserved for english (i.e., original) articles that are incomplete. Translations that are incomplete should be marked {{translateme}} and placed into:
[ArchWiki Tools]
----[translateme]
--------[your language]
Offline
I think that users can write incomplete articles in their own language.
Another idea: omit section Software as it can contain only post installation tips (I think they are for installation category), package issues (section Package Management), Xserver (Section Xserver) and DE. Too many subcategories, I think.
And another one: omit Section System Administration, all of it subcategories become one level up.
Offline
I think that users can write incomplete articles in their own language.
Another idea: omit section Software as it can contain only post installation tips (I think they are for installation category), package issues (section Package Management), Xserver (Section Xserver) and DE. Too many subcategories, I think.
And another one: omit Section System Administration, all of it subcategories become one level up.
Yes. I agree. But those are not so numerous, IMO, and mixing with english articles in a single {{stub}} section is not much of a problem. But if you insist, I can add more language subcategories inside main [Stub] category. Translations are something else, because people who want to help with translation need to gather all language-specific pages into one place in order to find incomplete translations.
I removed the SysAdmin main category, upgrading all its children into full adult status. However, the purpose of SysAdmin was to divide administrative tasks (which supposedly require more knowledge and involvement) from User's Guide section, where day-to-day usage is explained rather than one-time fixes, hacks and tweaks. Although I've updated the tree to reflect cheer's opinion, I'd like more thoughts on this.
Making tree depth shallower is not the single most important priority.
Offline
To play devils advocate: Do we need a hiearchy at all. Too often, we force our data into a tree hierarchy, when some other organization would be more appropriate.
Hierarchical taxonomies of just about anything are usually problematic to maintain, except for the trivial perhaps. I think software engineering has gotten carried away with trees. I think hierarchies are good for front-end navigation, but should not serve as the only organization mechanism, especially internally.
I think it's far more important to get the wiki search fixed. I frequently use google to find material on the wiki because the wiki search rarely returns usable results.
There are Alternatives to Hierarchy. Many Wiki follow some sort of organic organization. Instead of a hierarchy of subjects and pages, they just have pages point to pages, and everything sort of works.
A slightly weaker (less strict) form of hierarchy is the semilattice. This is like the tree, but where higher-ups can share access to lower-downs.
The most generic arrangement of things is the Graph. Any and every structure can be conceived of as a graph. A graph just means: "A bunch of things, and the relationships between them." If you need a particular sort of arrows (for example, in your tree, you need arrows from higher-ups pointing to lower-downs,) you can choose between your undirected (no-arrows) and your directed (with arrows) graphs.
You could also be using Tags. You can think in terms of tables, and call it "relational." You can think about sets. Many of these arrangements are mappable to the other ones; They are just different expressions of the same basic things.
Offline
I think it's far more important to get the wiki search fixed. I frequently use google to find material on the wiki because the wiki search rarely returns usable results.
Aw, you're reading my thoughts there! (Hehe, just sold my soul to the devil. )
But that means we need much more powerful way to mark up our pages. Language tags, keywords, topic descriptions... With such markup, it won't be so hard even if we wanted a tree after all, because a script could auto-generate the tree structure using the markup.
Furthermore, I've already outlined a way of gathering pages into unified Tutorial pages and Book pages which are, in reality, just collections of references to lower-level pages -- containers, so to speak. If those can become true containers (e.g., you click "expand" to expand a referenced page INSIDE a Tutorial or a Book page, that would be even more elegant).
Have to warn you there: editing the pages should still remain an easy task for non-technical ppl. Too many tags and no templates would make it an unattractive task for many users.
Offline
Good too see Wiki again getting improved.
Markku
Offline
Category tree now has its own page on the Wiki
http://wiki.archlinux.org/index.php/Arc … egory_Tree
Take any further discussion to this page's talk page. Also, you may now edit the tree yourself.
Offline
To all users volunteering to recategorize wiki pages:
First, this is a top priority in reworking the wiki, so thank you very much for your help.
Second, you may find the following special pages of use when trying to find pages that need recategorizing:
http://wiki.archlinux.org/index.php/Spe … ecialpages
Specifically, these pages are likely to be useful:
http://wiki.archlinux.org/index.php/Special:Categories
http://wiki.archlinux.org/index.php/Special:Lonelypages
http://wiki.archlinux.org/index.php/Spe … categories
http://wiki.archlinux.org/index.php/Spe … rizedpages
http://wiki.archlinux.org/index.php/Spe … categories
Finally, the process of revising the category structure is a bit convoluted. The basic procedure is as follows:
1) Find a page you want to recategorize.
2) Determine what category you want this page to be in from the category tree linked above.
3) Edit the page and change the category of the page to point to the category parent above it.
4) IF this category is already a part of ArchWiki and has already been properly reparented, you are done. Otherwise, click the category link on the page you have edited to go to the category page. Edit this page's category line to point to the proper parent category. Repeat this step for the new category. The root of each page should be a language category.
If you come across any locked category pages that need editing, contact me (e-mail, PM, or IM is best) and I'll unlock them.
Dusty
Offline
Can I delete unused empty categories (for my language)?
Offline
Yes, deleting empty categories is good.
Dusty
Offline
Please take a look at this category:
http://wiki.archlinux.org/index.php/Category:English
It contains two subcategories:
1. Pages sorted by topic
2. Pages sorted by type
Every page shoud go into both 1 and 2
You do that by adding two lines, for example:
[[Category: XServer (English)]]
[[Category: HOWTOs (English)]]
into an article.
In the above example, XServer (English) belongs to Software (English), which belongs to System Administration (English), which in turn belongs to Pages sorted by topic.
HOWTOs (English) belongs to Pages sorted by type.
Subcategories in Pages sorted by type do not have any subcategories, so please keep that in mind.
Also, take a look at:
http://wiki.archlinux.org/index.php/Moving_pages_HOWTO
for a quick HOWTO on how to move pages.
Offline
I have created all subcategories within "System Administration (English)" category.
Volunteers may start moving pages there.
:!: Please note that each page has to be placed in both the topic and type categories.
For example, a HOWTO page about installing modem drivers should have following category assignments:
[[Category: Communication and network (English)]]
[[Category: HOWTOs (English)]]
Check out the following section:
Offline
Please take a look at this:
http://wiki.archlinux.org/index.php/Cat … d_by_topic
This is the new and revamped Pages sorted by topic page in English section of the ArchWiki. I will fix the subcategories in the same way, but I need your feedback pronto. I won't be waiting for long before I go on with the edits.
Offline