.png){kind=small}
The Fedora Project Wiki has a very low barrier to entry for editors. However, there can be a small learning curve when beginning to use wiki, and we have a number of guidelines that all editors should follow. This page provides those guidelines and a few tips to help you get going.
This document is divided in three parts: gaining edit access, basic wiki editing, and more advanced editing.
Gaining Edit Access
In order to avoid malicious users defacing the Fedora Project Wiki, we have had to restrict edit access a little. To gain edit access to the wiki, you must follow a few simple steps. Anyone can gain edit access.
- Familiarize yourself with the information on this page and the pages that it links to. Basic guidelines that should be followed throughout the wiki are covered here. Failure to follow these guidelines creates unnecessary work for other volunteers and may result in revocation of editing privileges.
- Complete the Contributor License Agreement through the Fedora Account System. Signing the CLA gives the Fedora Project the ability to license your contributions to the wiki under the Open Publication License 1.0 without options. This assures that your contributions will remain forever Free for the community to use, modify, and redistribute, just like the Fedora distribution. See our Legal section for more information. Follow the instructions at http://fedoraproject.org/wiki/Infrastructure/AccountSystem/CLAHowTo
Information on writing new formal Fedora documentation using the wiki is available from Writing Wiki Documentation.
Guidelines
There are a few simple points you should follow as you make changes to the wiki. Below are some examples. In general, be courteous and use common sense. Defying these guidelines and causing problems are a good way to get your edit privileges revoked. If you have questions, you can ask on #fedora-websites on freenode.
Introduce yourself
Before you start editing any page, kindly introduce yourself by adding your information to your wiki page. After you have registered your name in the wiki, you automatically have a personal wiki page located at http://fedoraproject.org/wiki/User:<username>, where <username> is replaced by your Fedora Account System account name. You can also easily get to your wiki page by clicking your username in the top right-hand corner of each page of the wiki.
For examples, take a look at some wiki pages of our contributors.
Make sure you mention at least your email address and, if you are on IRC often, your IRC nick and channels you are often in.
Always watch pages that you create or edit
It is important that you follow changes to pages you create or edit, so you can coordinate with others working in the wiki content. Wiki editors usually add notes to the pages to convey information to each other as part of working together, and it helps to keep track of these changes.
You can find the watch link in the tab bar at the top of a page when you are logged in.
Be Bold
Be bold while editing changes. Wiki changes are tracked and can be reverted when necessary. This doesn't mean you should be reckless especially when making large changes to key documents.
For more information on being bold, take a look at the be bold editing guideline on Wikipedia.
Avoid unnecessary edits of pages that discuss legal issues
These pages have been carefully written, and the words chosen carefully. When changing these documents, it is usually best to ask for review before applying changes. You can contact the Fedora Advisory Board for assistance.
Do not provide details of forbidden items
Do not add any information that violates the law. Remember that the Fedora Project is an entity in the United States, and is governed by its laws. Avoid linking to or adding information about software that is not free and open source or that is legally encumbered. If you think you have a special exception, bring it to the attention of the Websites team for discussion. See the ForbiddenItems page for examples of items that should be avoided.
Bring questions to the Websites team for discussion. If needed, they can get the official word.
Be careful when editing key guides or pages
Large and important guides, such as the Packaging Guidelines , are generally managed by a specific individual or small group. It is best to work with them when you feel that changes are needed.
Important pages, like the FedoraMain or Download pages, are the first thing that many visitors see. Changes to such pages should generally be left to experienced contributors. If you feel that something on such a page should be altered, bring the issue to the Websites team for discussion.
Do not edit pages just to edit pages
Senseless edits should be avoided. Making an alteration to a page just to put your name in the edit log is unacceptable. There are plenty of pages (most of them, in fact) that have real errors that can be corrected. Instead of making pointless edits, such as removing or adding whitespace or changing links from fedoraproject.org to www.fedoraproject.org (the former is preferred), try finding errors in spelling, grammar or punctuation that can be corrected. Also, when correcting a small error, mark "This is a minor edit" using the appropriate checkbox before you save it.
Avoid renaming pages or moving content without coordination
Wiki pages are generally referred to and linked to from various other locations. It is important that you coordinate with the appropriate groups before moving content or renaming existing pages. It would be better to avoid doing that without strong rationale. If you wish to discuss moving a particular item, bring your questions to the ["Websites"] team.
Follow the ideals that Fedora holds important
For example, try to remain desktop-neutral and user-friendly, especially for non-technical users who are new to Linux and to Fedora. Users may use GNOME, KDE, the console, or some other environment. Try to keep that in mind when writing instructions. Make sure that Fedora's devotion to free and open source technology is also represented properly.
Sign your attachments
When you attach a file to a wiki page, you should create a detached signature with your GPG key. Some file formats, such as RPM packages, support GPG keys, in which case you do not need to create a detached signature -- a signature in the file will be enough. A detached signature can be attached to the page alongside the original attachment, or can be included in the page itself.
GPG signatures allow others who download your file to verify that it came from you and has not been modified or corrupted. They do not violate your privacy in any way, they simply allow others to have confidence in the origin of your files.
Images and simple documents are safe to leave without a signature, but there would be no harm in adding one anyway to verify that you were the author.
If you do not have a GPG key or want to learn more, see the ["Cryptography"] page.
Review your changes for errors
Whether you are a skilled writer, or your English skills are not strong, invite someone else to review. Well-written documents are important to Fedora's image. Even the best writers are prone to typos or other errors. Take a moment to review your changes to catch small errors.
Fedora is a community
When writing content, for the wiki or elsewhere, remember that Fedora is a community. We operate as one, unified group, moving towards common goals. We do not need to distinguish one group or class against another. For example, there is no need to distinguish between contributors who work for Red Hat and those who do not. All contributors are part of the same community. There will be cases where classification is necessary, but it can be avoided otherwise.
If you aren't sure about something, feel free to ask
Other community members will be happy to assist you. The #fedora-websites channel on freenode is the perfect place to discuss the wiki or other Fedora websites.
Watch Your Pages, and Other Ones, Too
Two details make a Wiki successful as an open content collaboration tool. First is being able to watch content you are responsible for, to make certain it stays true to its mission. Second is being able to watch other content develop, grow, and occasionally need your help.
There are several good ways to watch or subscribe to a page:
1. Direct your RSS reader to draw from http://fedoraproject.org/wiki. It should be fed the appropriate RSS file. 1. Add the regular expression for the document(s) on which you are working in your UserPreferences under Subscribed wiki pages. For example, these expressions watch three documents:
Docs/Drafts/AdministrationGuide.* Docs/Draft/Glossary.* Docs/Drafts/DesktopUserGuide.*
This expression watches all changes in the draft area:
Docs/Drafts.*
This expression watches all changes in the DocsProject pages, including the Docs and Docs/Drafts namespaces:
Docs.*
Editing with MoinMoin
The online help can be a valuable resource when learning how to edit wiki pages. By reviewing these help pages, you may learn some neat new tricks. You should review them at least once, and they will always be there as a quick reference when you are editing pages. You can ask questions about editing on #fedora-websites on freenode.net .
Structure of a Wiki Page
This section describes the common structure of a Wiki page. Follow these guidelines for every Wiki page. There are additional rules used for formal Fedora documentation, covered in DocsProject/WritingUsingTheWiki ; those rules are only required for content written to follow the procedures of the Fedora Documentation Project .
1. The title of the page is a first-level header. Surround it with the single header markup symbols =:
= Title of Page =
Exception: Pages that are going to be always and only pulled in to another page using an [[Inline()] -type macro do not start with a first-level header. The structure of these non-modular sub-pages is dependent on their parent, starting at the nested level of the parent document.
1. Under the = Title of Page = and before an == Introduction == section, include a table of contents macro:
= Title of Page = == Introduction ==
Exception: You do not need to include a table of contents if the page is short enough that it does not need scrolling to read it in a browser opened to 700 pixels high.
Exception: The point of the table of contents is to make it easier for the reader. If the table of contents gets in the way of a good reading experience, remove it.
1. Key sections can use an anchor for prettier linking. Using the section title as the anchor with underscores makes for an easy to read URL. Regardless of the style you use, be consistent throughout the document.
{{Anchor|Title_of_Section}}
== Title of Section ==
1. Important pages can be categorized by putting CategoryFoo at the bottom of the page under a horizontal rule. Replace Foo with a category name such as Documentation.
---- [[Category:Documentation
]]
| An easy way to categorize a page is with the Make this page belong to category menu that appears on the Wiki edit page. |
Exception: The pages in Docs/Beats are source only and are not included in the CategoryDocs pages because they are not intended to show up as a search result for documentation. If a page is a source for content and is not itself canonical or otherwise the URL that people go to find this information, then do not include it in a category. Another example is any content under a personal NameSpace.
1. More to come
Quick Tips
These are the basic things that you need to know to edit this Wiki.
| For more information on drafting documentation on the Wiki, refer to Writing Wiki Documentation . |
Learn by Example
Among the better ways to learn how to edit the wiki is reviewing the code of existing pages. This is very easy to do:
1. Find a page whose source you would like to view. 1. In the Navigation bar, find the combo box that reads 'More Actions:' and click on it. 1. Select the 'Show Raw Text' option.
The wiki will display the plaintext form of that page. This is particularly valuable for learning some of the clever tricks used by wiki editors ahead of you. Those 'clever tricks' are valuable, as they allow you to do unique, interesting, and powerful things you might not have thought were possible. You might try this on pages like FedoraMain.
Linking
Linking is perhaps the simplest and the trickiest thing in MoinMoin. The simplest form of linking involves wiki names. Wiki names are two or more capitalized words combined. When you use a WikiName, there is no need to use any special markup. A link will be created automatically.
In order to avoid a link being created when you don't want it to be, you'll have to come up with some clever trickery. The simplest way is to put two backticks between the WikiWords, like this: Wiki, which safely "breaks" the wiki's routine of automatically linking the word. If you need to link to a subpage or to a page that isn't a wiki name, you can use a syntax like Words A Subpage of Project or simply ["Pagename"] .
Avoid putting links to other websites within paragraphs of text. Instead, explain the website in your text, and write the URL for the link on a separate line. This ensures that the URL is still readable when the page is printed or converted into another format. For example:
Check the Fedora Documentation Website for the latest version of this document before you begin. [http://docs.fedoraproject.org/]
For more on this, see HelpOnLinking.
Lists
Both numbered lists and bulleted lists are simple and useful. See HelpOnLists for details on how to use them.
Tables
Tables can be very tricky, because they may not behave like you expect. Wide tables are particularly troublesome, because they will expand beyond their boundaries when viewed in smaller browser windows. The best advice is to only use tables when necessary. When dealing with large numbers of small records, they can save a lot of space. Just test thoroughly when you use them. Remember that others may be using smaller resolutions than you do. For more information, see HelpOnTables.
Notes, Tips, and Other Admonitions
These are collectively known as admonitions. To make a paragraph into an admonition, enter two pipes at both the beginning and end of the paragraph, make the title bodl face, start the title with the appropriate icon, and include more information in a secondary paragraph:
{| style="message note"
|-
| Here is more information about this tip, with information that provides more insight into the informative title of the initial paragraph.
|}
| Here is more information about this tip. |
Indent the initial and second paragraph by one space, to ensure that the box aligns correctly.
These are the standard types of admonition:
This is the Note icon 
This is the Tip icon 
This is the Important icon 
This is the Caution icon 
This is the Warning icon
Examples showing context for using these admonitions:
| Cliffs can be very high
|
| Standing away from cliff edges is a way to stay safe
|
 Keep your children away from that cliff edge
|
 You are getting near the cliff edge
|
| You are about to fall off the cliff
|
Refer to the Fedora Documentation Guide for descriptions of the types of admonition:
http://fedora.redhat.com/participate/documentation-guide/s1-xml-admon.html
Marking Technical Terms
Use backticks () to mark the names of applications, files, directories, software packages, user accounts, and other words that have a specific technical meaning. This displays the marked words as .
Use two single-quotes () to mark the names of menu items and other elements of the graphical interface. This displays the marked words in italic.
Names of GUI applications
bold face boldface
Firefox
Files, directories
single backticks monospace font/usr/bin/firefox
Software packages
single backticks monospace fontfirefox-1.2.3
User accounts
single backticks monospace fontusername
Other words that have a specific technical meaning
single backticks monospace fontsomeJava.classname
Inline content from a configuration file, programlisting, etc.
single backticks monospace font... Next, change the DefaultIcon setting in /etc/httpd/conf/httpd.conf to ...
Graphical menus and menu items
two single-ticks italic
Applications > Internet > Firefox Web Browser
Other GUI or Web UI interface element
two single-ticks italic
... click the Submit button ...
First term, glossary term
two single-ticks italic
... Firefox is an example of a graphical user interface or GUI.
Inline command and daemons
3 brackets monospace fontgrep httpd to find the PIDs of the running httpd processes.
Keystrokes
[Key] [bold brackets]
Press the [Enter] key ...
For example:
The <code>thunderbird</code> package installs the '''Mozilla Thunderbird''' e-mail application. To start '''Thunderbird''', select: ''Applications > Internet > Thunderbird Email''.
Which produces:
The thunderbird package installs the Mozilla Thunderbird e-mail application. To start Thunderbird, select: Applications > Internet > Thunderbird Email.
Writing Example Commands
Example commands are one or more commands set apart from the body of the explanation. Do not use prompt symbols or any other content that shows machine name, user, directory, etc. (which are details set in the $PS1 environment variable.)
Enclose any example command in triple brackets, with the command on the first line of the triple brackets, and the closing triple brackets on a line by themselves:
#!html
<pre>
{{{su -c "yum install awesome-application"
}}}
Enter the <code>root</code> password when prompted.
Which produces:
su -c "yum install awesome-application"
Enter the root password when prompted.
Many commands require root privileges. The reader should not be logged into their system as root, and so you must specify either su -c or su - when explaining such commands.
If the command requires elements to be quoted, nesting should be " ", with the single quote marks surrounded by one containing set of double quote marks. For example:
su -c "command -o 'Some Text' -file 'More text' foo/bar"
If you need to have a series of commands or su -c is not responding as expected, have the user switch to root and warn the user to return to a normal user shell afterward.
su -
Password:
service food stop
cp /etc/foo.d/foo.conf /etc/foo.d/foo.conf.backup
vi /etc/foo.d/foo.conf
food --test-config
...
service food start
exit
Try it Out Yourself
Try new things in the Fedora Wiki Sandbox . It is also a good place to see lots small samples at work.
Creating New Pages in the Wiki
The Fedora Project Wiki is large, and so there is a need to maintain a proper hierarchy and organization. The best way to learn about these is to review SubPages and HelpOnCategories, and then to review the existing layout of the wiki.
Redundant names (such as /Foo/FooBar/FooBarGrue) should be avoided. Remember that including 'Fedora' in the page name is redundant. Major Fedora projects do not need to have 'Project' in their page names, either. For example, the Fedora Websites Project has its page named 'Websites', not 'Fedora
For the most part, pages should be grouped as subpages by the projects or programs they are part of. Categories will generally be created for different projects and programs, and should be created sparingly. Most pages you create should be part of a category, and many should also have appropriate tags. If you are thinking about creating a new category or tag, please ask the ["Websites"] team for advice first.
If you have questions, feel free to ask the ["Websites"] team.
Important Pages
Key pages, such as Main Page, should be edited sparingly. Changes to such pages should generally be discussed on the mailing lists or on IRC before being applied. Some parts of the wiki may have different permissions. For example, the DocsProject has a section for the creation of new documentation which is restricted a bit more than the rest of the wiki. In order to gain edit access to such pages, you may have to complete additional steps. You can usually find instructions on those pages.
Getting Help
If ever you have questions about editing the Fedora Project wiki, or if you need help, please feel free to contact the Websites team. They have an IRC channel (#fedora-websites on freenode) and a mailing list (fedora-websites-list) that are both effective for getting the answers you need.
If you would like to do a lot of editing on the wiki, you should consider joining the Websites team.