Rules and guidelines
From MozillaZine Knowledge Base
(Redirected from Rules)
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 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 and guidelines more closely.
Get some editing practice
Use the sandbox to play around with the wiki system.
Avoid superfluous information
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.
The knowledge base is a wiki. It doesn't support HTML or bbcode, it has its own markup language. If you're not used to wiki markup the formatting article is a useful primer.
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.
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.
To allow people to find information more easily, it is helpful to use categories when editing or creating articles.
Articles that apply to more than one application
Removing obsolete information
Information about obsolete versions (i.e, versions that are no longer supported and which haven't been updated in over a year) may be removed if it is long, confusing, or distracting if the corresponding information about current versions is present. However, a comment such as "Applies to Firefox since release 0.9" in articles about preferences is a good example of information that shouldn't be removed. It's very short, and the historical perspective can be useful.
Keep in mind that older operating systems (e.g., Windows 98/Me and Mac OS X 10.3) do not meet the requirements for current Mozilla applications and some outdated versions (e.g., SeaMonkey 1, Firefox 2 and Thunderbird 2) may still be popular for various reasons. Use common sense before removing information that may still be useful.
If you see a problem with an article you are encouraged to either fix the problem or add a comment in the article's discussion page. Nobody owns an article, they're collaborative efforts. The Request for comment, cleanup, update, and stub templates are meant to identify articles whose quality could be improved and to try to focus attention and resources on the article. The main difference is that the Request for comments template is used to request a review of an article when it's not clear what should be done.
If you go to Category:Articles_to_clean_up, Category:Articles_to_update, Category:Stub, and/or Category:Request_for_comments and click on Watch you'll be notified of any changes to that category. Each of those templates adds some text in a box to the article and adds it to one of those four categories.
These guidelines apply to support/issues articles (directing people how to fix a problem) and how-to articles that support articles use (such as Profile folder).
The MozillaZine Knowledge Base is intended to be used by both novice and advanced users. Because of that, here's a few things to keep in mind:
Articles should be written appropriately for the audience. This means that an article for a situation that could happen to a novice user or an article that describes steps that a novice user might want to take should be written at the level of a novice user. For example, a novice user will not likely know how to "set extensions.checkCompatibility to false" without us providing step-by-step instructions, whether directly in the article or via a link to another article. Conversely, articles that are written for situations that would only happen to more advanced users can assume that these users would know how to set preferences and do other somewhat advanced things.
In an article intended to be understood by novice users, if the only way to perform a task is technically involved, it should be marked as "Technical" or "Advanced" in the section header.
Keep technical explanations in articles intended for novice users to a minimum. If you feel it should be included, put it in a section called "Technical overview" or similar.
Helping users find the correct article
When similar articles exist and users might reasonably choose the incorrect article, provide links to the other articles in the introduction and contrast the current article to the other articles.
As a general rule, link to addons.mozilla.org (AMO) whenever possible instead of linking to the author's website or elsewhere, unless you have a good reason to use an alternate link.
Use the Knowledge Base changes page to announce new suggestions for changes that might affect other editors, such as creating a new category.
There is an 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 article's discussion page. If you have a deadlock (and it's 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