From Fedora Project Wiki

mNo edit summary
(updating to match the new wiki needs; removing suplerfluous anchor since the base anchor works to that effect)
Line 124: Line 124:
== Structure of a Wiki Page ==
== 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| DocsProject/WritingUsingTheWiki]] ; those rules are only required for content written to follow the procedures of the [[DocsProject| Fedora Documentation Project]] .
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 [[DocsProject| Fedora Documentation Project]].  Pages that are templates of standard content that are drawn into other pages may have a different structure.


1. The title of the page is a first-level headerSurround it with the single header markup symbols <code>=</code>:
{{admon/note|Header 1 (h1) deprecated for use in markup|The header 1 is defined by the page titleWhen making new or migrating pages, either re-nest or re-structure the page to have ''only'' header 2 and below.}}


<pre>= Title of Page =
* The title of the page is a first-level header.  It is created automatically from the page title.
* Sections are created using the equals symbols in pairs:
<pre>
== Header 2 ==
=== Header 3 ===
==== Header 4 ====
===== Don't do this, 5 levels of nesting means you need a new page or three =====
</pre>
</pre>
 
* The table of contents is automatically created and populated when the page grows big enough.
{{Template:Tip}} '''Exception''': Pages that are going to be '''always and only''' pulled in to another page using an <code>[[Inline()]  </code>-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.
* Anchors to sections are automatically created, with specific symbols used in place of punctuation and spaces:
 
<pre>
1. Under the <code>= Title of Page =</code> and before an <code>== Introduction ==</code> section, include a table of contents macro:
This page ==> This_page
 
This, that, and the other page ==> This.2C_that.2C_and_the_other_page
<pre>= Title of Page =
 
 
 
== Introduction ==
</pre>
</pre>


{{Template:Tip}} '''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.
{{Template:Tip}} '''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.
<pre>{{Anchor|Title_of_Section}}
== Title of Section ==</pre>
1. Important pages can be categorized by putting <code>CategoryFoo</code> at the bottom of the page under a horizontal rule.  Replace <code>Foo</code> with a category name such as <code>Documentation</code>.
<pre>----
[[Category:Documentation</pre>]]
{| style="message note"
|-
| An easy way to categorize a page is with the ''Make this page belong to category'' menu that appears on the Wiki edit page.
|}
{{Template:Tip}} '''Exception''': The pages in [[Docs/Beats| Docs/Beats]]  are '''source only''' and are not included in the [[CategoryDocs| 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''
{{Anchor|Quick_Tips}}
== Quick Tips ==
== Quick Tips ==



Revision as of 02:01, 27 May 2008

This page is a complete mess and is in the process of being MediaWikified by Ian Weller. Please have patience :)
Help:Editing from Mediawiki.org is a good source for markup help as you work on fixing broken markup from the migration. There is also a handy reference card image.

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.

  1. 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.
  2. 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
If you are interested in more general website maintenance, or wish to be part of the Fedora Websites team, please see the Websites page.

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. Use the Show preview button when editing a page to check your syntax.

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.

To watch any page on the wiki, after logging in, click the watch link in the tab bar at the top of a page. It should change to unwatch after it has finished. If a page has unwatch at the top, you are already watching that page. You can click unwatch to unwatch a page.

To receive emails for every edit, go to my preferences (at the top of the page by your name) and make sure to check the appropriate boxes in the User profile tab, under Email.

Using Special:Watchlist

Special:Watchlist (available by clicking my watchlist at the top of each page when you are logged in) displays pages you are currently watching. For more information on how to use this special page, please the manual page at Mediawiki.org.

Editing with Mediawiki

If you need help with syntax that is not listed here, the Mediawiki Help should contain it.

Basic Syntax

What you type What it looks like
'''bold text'''
bold text
''italics''
italics
'''''bold italics'''''
bold italics
<code>Monospace text</code>
Monospace text

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. Pages that are templates of standard content that are drawn into other pages may have a different structure.

Header 1 (h1) deprecated for use in markup
The header 1 is defined by the page title. When making new or migrating pages, either re-nest or re-structure the page to have only header 2 and below.
  • The title of the page is a first-level header. It is created automatically from the page title.
  • Sections are created using the equals symbols in pairs:
== Header 2 ==
=== Header 3 ===
==== Header 4 ====
===== Don't do this, 5 levels of nesting means you need a new page or three =====
  • The table of contents is automatically created and populated when the page grows big enough.
  • Anchors to sections are automatically created, with specific symbols used in place of punctuation and spaces:
This page ==> This_page
This, that, and the other page ==> This.2C_that.2C_and_the_other_page

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: WikiWords, 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 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, and are used in DocBook. 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:


What you type What you see
{{admon/note|A title|Here is more information about this tip, with information that
provides more insight into the informative title of the initial paragraph.}}
A title
Here is more information about this tip, with information that provides more insight into the informative title of the initial paragraph.

Indent the initial and second paragraph by one space, to ensure that the box aligns correctly.

These are the standard types of admonition:

What you type What you see
{{admon/note|This is a note|Informational paragraph
that tells more about what is going on.}}
This is a note
Informational paragraph that tells more about what is going on.
{{admon/tip|This is a tip|Informational paragraph
that tells more about what is going on.}}
This is a tip
Informational paragraph that tells more about what is going on.
{{admon/important|This is important|Informational paragraph
that tells more about what is going on.}}
This is important
Informational paragraph that tells more about what is going on.
{{admon/caution|This is a caution|Informational paragraph
that tells more about what is going on.}}
This is a caution
Informational paragraph that tells more about what is going on.
{{admon/warning|This is a warning|Informational paragraph
that tells more about what is going on.}}
This is a warning
Informational paragraph that tells more about what is going on.

Examples showing context for using these admonitions:

Cliffs can be very high
Wikipedia can vouch for this.
Standing away from cliff edges is a way to stay safe
For more information, read the cliffs(1) man page.
Keep your children away from the cliff edge to your right
Children move around quite a bit and can easily fall off. You should hold their hand.
You are getting near the cliff edge
As mentioned earlier, cliffs can be very high, and it would be bad to fall.
You are about to fall off the cliff
Move away as quickly as possible to avert falling.

Refer to the Fedora Documentation Guide for descriptions of the types of admonition: http://docs.fedoraproject.org/documentation-guide/en_US/sn-xml-admon.html

Marking Technical Terms

Use the code markup (<code&rt;) 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 monospace.

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.

Term Mark Up Formatted example
Names of GUI applications
 '''boldface''' 
Firefox
Files, directories
 <code>inline code tags</code> 
/usr/bin/firefox
Software packages
 <code>package name</code> 
firefox-1.2.3
User accounts
 <code>username</code> 
username
Other words that have a specific technical meaning
 <code>technical term</code> 
... the class org.dev108.someJava.classname ...
Graphical menus and menu items
 ''Menu name'' 
Applications > Internet > Firefox Web Browser
Other GUI or Web'UI interface element
 ''two single-ticks'' 
... click the Submit button ...
Inline command and daemons
 <code>command -option</code> <code>daemon</code>
grep httpd to find the PIDs of the running httpd processes.
Blocks of code, configuration files, etc.
 <pre>whitespace preserved< /pre> 
whitespace
    is preservered
  here
Inline pieces of code, configuration files, etc.
 <code>inline whitespace not preserved</code> 
... Next, modify the variables for set() in /path/to/org/dev108/classname ...
First term, glossary term
 ''term'' 
... Firefox is an example of a graphical user interface or GUI.
Keystrokes
 '''[Key]''' 
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 Help:Subpages and Help:Categories, 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 'FedoraWebsitesProject'.

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.