Almost anyone can contribute documentation to the Mozilla project. If you're interested in helping out, please read below on the different ways you can improve documentation at mozilla.org.
How to Contribute
Contributing documentation is fairly easy. You can contribute actual documentation, review existing documents and works-in-progress, or help organize and clean up existing documentation. In addition, old documentation should be constantly revisited to make sure it is still relevant and accurate. Here are more ways to help:
- When you learn something by asking questions and reading source code, consider writing a document describing what you've learned or expand the in-code comments to make it clearer. Other people will probably have the same questions that you did. Post your findings to a relevant newsgroup and get some feedback. When you're ready to publish your documentation on mozilla.org, ask for help getting your work checked in.
- Check for errors in existing documentation and report them—or better yet, fix them, too.
- If you discover that there is no document to cover something you'd like to learn, file a bug describing the document that's missing.
- Track the newsgroups for pearls of wisdom. Sometimes you might find an explanation that should be added to an existing document. If you notice the same questions being asked repeatedly, get them added to the FAQ.
- Check the list of open documentation bugs and pick something interesting to help fix.
Each bug in the Documentation product in Bugzilla belongs to one of three components, based on the intended audience of the document in question:
- Mozilla developer
- These documents most useful to people who work with the Mozilla code
itself. They include user manuals (such as the
nsCOMPtrUser's Manual) that document specific interfaces as well as documents describing how a developer might embed Mozilla in another product. This component can also cover comments in source code, especially those commented for LXR.
- Web Developer
- This component contains information about HTML, CSS, HTTP, etc. It is intended for content creators, web site administrators, system administrators and people using Mozilla as an application development platform. XUL documentation goes here because some content creators are writing XUL applications.
- Documentation reachable from Mozilla's Help menu as well as any on-site end-user support documentation.
Once a bug has been filed, someone needs to write or correct the documentation either check it into the mozilla.org website tree themselves or ask someone with the appropriate permissions to do it for them.
If you are writing for mozilla.org, try to follow our Style Guide. Many people read our site precisely because they can't yet use Mozilla, so make sure your document is readable on different browsers.
CVS is used to manage the documents on our web site. To submit changes to a current document you can either use CVS to check out the document and create a patch with cvs diff -u or you can click the "Edit this page" link at the bottom of the document you are changing to make a patch with Doctor.
Once you have a patch, submit the file to the owner of the document by attaching it to a Bugzilla bug report and asking the owner to review (and check in the changes, too, if you don't have access). If the document doesn't list its owner, click on the "Document History" link at the bottom of the page to see who has recently updated the page and ask them. If all else fails, mail firstname.lastname@example.org.
As with the source code, if you establish a track record of good work then you may be granted access to the repository, especially if you contribute documents and become their official owner and maintainer. To get access, you'll need to submit a CVS Contributor Form. Read mozilla.org Content and CVS for CVS information specific to our doc tree. The document Source Code Via CVS explains where to get a CVS client for your platform and has pointers to CVS documentation.
The reviewing requirements for mozilla.org documentation are very informal. We expect that you have the document owner's permission before checking in any major changes to it. We also recommend that you follow the guidelines set forth in the Documentation Style Guide. You can get a thorough HTML&CSS code review by asking fantasai to check over your document.
The review requirements on developer.mozilla.org are stricter. You must get fantasai's ok for the file location before checking in new files. All documents on devmo are expected to adhere to the rules in the Documentation Style Guide.
We are working on a copyright policy. In the future, we hope to institute a copyright policy that encourages information sharing, possibly like the Open Publication Licence or the Linux Documentation Project, in which authors retain their own copyright while extending blanket reproduction and distribution privileges (subject to certain conditions).
We are interested in hearing your opinions about this issue. Please post them to our documentation newsgroup.