Rules and guidelines

From MozillaZine Knowledge Base

Revision as of 08:26, 18 May 2007; view current revision
←Older revision | Newer revision→

Welcome, new and existing editors! Your contributions of Mozilla-related knowledge are most welcome, and you don't need to be an “expert” to help out. In particular, if you have come to the Knowledge Base from the forums after having a question answered or a problem solved, you are encouraged to write up anything that you learnt there, even if you didn’t fully understand why the solution works.

The main rules are:

  • Don't create a edit war. Nobody "owns" a article, you're collaborating with other editors. That can take some getting used to. Use the discussion page for the article to discuss any issues. If necessary, use the other editors Talk page or send them a private message if they have an account on the Mozillazine forums.
  • Don't publicly share your username/password (it creates "de facto" anonymous user editing).
  • Use common sense.

Don’t feel daunted by the sections below; although it helps if you follow them, there will always be other editors willing to tidy up your contributions if you don’t have the time to read all the guidelines in the links below. The important thing is getting your contributions here in the first place! Of course, if you’re planning on becoming a regular contributor then you should try to follow the rules more closely.


Get some editing practice

Use the sandbox to play around with the wiki system.

Editing courtesy

  • Any time you edit a page, please add a short comment in the "Summary" field about the change you made. This makes it easier for others to see what has changed. Importantly, it can help make it easier for us to distinguish Knowledge Base vandalism from legitimate contributions.
  • Document reasons for potentially controversial changes on the Talk pages.
  • Accept changes to your entries in a spirit of helpfulness; experienced editors will often make changes to ensure that an article conforms to the rules. Of course, discussion relating to the changes is welcome on the corresponding Talk pages.
  • If you find yourself wanting to change an entry back to an earlier revision, ask yourself if the current version had a useful purpose, and whether it really is necessary to change it back.
  • If someone consistently makes certain types of mistakes or formatting quirks, consider placing a message in their User Talk page.

Avoid superfluous information

  • In Knowledge Base articles, please do not insert signatures, links to sites that are not related to Mozilla products, or other superfluous information. If you want to give a link to your own personal website, for example, then put it in your User page, not in the article. In short, if the information or link is not directly related to the topic of the article, then don't include it in the article.
  • Of course, signatures are welcome and helpful in the Talk pages, so please do use them there.

Creating new articles

Before you create a new article in the Knowledge Base, check to see if the topic hasn't already been covered somewhere. Do a search and browse the relevant articles. You don't want to waste your time by adding information that already exists.

Please read and follow the article naming conventions when creating new articles or moving existent ones. You don't have to read that if you only edit existing pages.

To actually create the new article, visit the Sandbox and create a link to your proposed article, such as [[My new article]]. Preview the Sandbox page, and then click on the link. This will take you to the (currently empty) page for your article, where you can add your content.

Style guidelines

Please have a look at In-house style. We're trying to give the Knowledge Base a uniform look, and you can help by following these guidelines as much as possible.

Categorizing articles

To allow people to find information more easily, it is helpful to use categories when editing or creating articles.

Dispute resolution

Use the knowledge base changes page to announce new suggestions for changes that might effect other editors, such as creating a new category.

There is a unapproved working draft of a dispute resolution process. The main reason why there has been no attempt to formally approve a dispute resolution process is (so far) we've managed to avoid any editing wars. Most disputes are resolved using the articles discussion page. If you have a deadlock (and its not over something inconsequential or petty) you can formally request comments using the Request for comments template. That might help you develop a consensus or provide the outside perspective needed to resolve the dispute.

Talking to authority