Help:Wiki structure

Making wiki pages? Want to know how to name them in MediaWiki? This page tells you how we want the wiki structured, when it comes to creating new pages or moving around old content.

Consistency is good, it instills a sense of confidence in to the reader. These rules and the Help:Editing rules are designed to use MediaWiki features and match Fedora Project needs, while making life easier for contributors and readers.

Page naming
Use this for naming new pages and areas. Also use it for planning where to move nested content migrated from the old wiki.

General naming rules
These rules are for pages and sections.


 * Do not nest pages in sub-folders, e.g. Topic/FAQ
 * Exception: Sub-projects with existing ProjectName/ nesting may choose to continue using one-level of nesting.  All pages below that one level should be made to otherwise follow these rules
 * Use natural language naming (as opposed to nesting)
 * Use capital letters only for the initial word in a title or section title: "Like this"
 * Exceptions: Sub-project names, proper nouns, and the titles/chapters of formal, full documentation guides that are converting to XHTML/XML
 * Example: Join the Foo Project; Setting up USB boot media; FAQ on SELinux; Standing in the middle of the field.

End-user focused pages
These are pages focused on end-users of all levels, beginner to highly experienced. These are pages not specifically under a sub-project or SIG.


 * Name pages within a single, flat namespace; do not use directory-like hierarchies:
 * no : FedoraLiveCD/USBHowTo
 * yes : How to boot a live Fedora image from USB


 * Comprehensive guides (sets of pages linked together as a guide):
 * Guide Name - Chapter Name
 * Add each guide to a specific
 * For specific versions use F10 Guide Name - Chapter Name
 * Add these version specific guides to a version specific category, then add just that one category as a sub-category of

Project and SIG focused pages for contributors
These are pages focused on contributors who are working in one or more areas of Fedora. Some content may be end-user focused but belong within the project/SIG for reference.

The content here may be divided by one nesting level. Any further nesting needs to be squashed to the one sub-level with a natural language title. The best solution is to entirely rename without nesting, putting all pages in an appropriate Category:Foo Project category.


 * If pages are in a single nested level:
 * no : SIGs/ISV/Join
 * yes : ISV_SIG/Join
 * best : How_to_join_the_ISV_SIG
 * Content within the single nesting must be in a flat namespace with spaces
 * no : EPEL/PackageMaintainer/GenericJobDescription
 * yes : EPEL/FAQ
 * yes : EPEL/Package_Maintainer_Generic_Job_Description
 * best : Frequently_asked_questions_about_EPEL; Generic_job_description_for_package_maintainers

Namespaces
A MediaWiki namespace is a special word followed by a colon, that puts the content in a different naming area in the wiki.

Automatically searchable namespaces

 * Main:
 * FedoraProject: (default project)
 * Help:
 * Category:

User: namespace
The User: namespace is somewhere you can put drafts and other personal material that you do not want searched and indexed by engines like Google. For instance, the user jpublic can build any wiki materials as desired under User:Jpublic, using subpages. If you need to know what pages you've built under your personal User: namespace, use the Special:Prefixindex page.

Archive: namespace
Move old content to this namespace. This gets it out of the regular search index but keeps it available for future needs.

If you are archiving old content while renaming a set of pages, do not give the page a new, natural language name in the Archive: namespace. It should remain under its old name in the new namespace, to make it easier to find in historical contexts. For example, FooProject/Some/OldStuff moves to Archive:FooProject/Some/OldStuff.

Meeting: namespace
Use this namespace for naturally named pages related to project and SIG meetings. For example, Meeting:Docs IRC log 20080806.

Categories

 * Use as many categories as needed that make sense:
 * Category:SIGs Category:Meetings Category:EPEL
 * The category pages are the aggregation pages. Point to them prominently as the way to find all of something on a topic/within a category.
 * "To review a list of all docs currently in draft, refer to the Category:Draft Documentation."
 * "Useful end-user docs are found in the Category:Documentation."
 * "To learn more about the Documentation Project, refer to the Category:Docs Project.
 * New category names should follow the same natural language rules as individual pages but are usually plural:
 * Docs project meeting logs
 * Ambassadors in North America
 * 2009 events
 * Google Summer of Code activities