I volontari di MDN non hanno ancora tradotto questo articolo in Italiano. Registrati per tradurlo tu.
There are a couple of ways we track documentation issues in Bugzilla.
Note: This article is out of date; new material is in the process of being written to cover new processes for how we manage documentation. See How to help and Documentation planning and tracking for updated albeit incomplete information.
Engineering bugs that impact documentation
Bugs in the Mozilla project's Bugzilla database that impact documentation should be tagged with the
dev-doc-needed keyword. This is another great way to find items that may require documentation. When the required documentation changes have been made, the
dev-doc-needed keyword should be changed to
dev-doc-neededkeyword can be applied to bugs even before they're fixed; as a general rule, you should only actually write the documentation once they're fixed and landed on the tree.
As a general rule, your best bet is to avoid writing about something until the bug has been fixed, so that you know the issue is ready to be documented. If you decide to write about something once the bug is marked as fixed, you can set the bug's assignee to yourself to claim it.
Claiming a bug for documentation
If you decide to take on the job of documenting an issue marked as
dev-doc-needed, wait until the bug is fixed, then change the bug's assignee to yourself. That way, other writers will know who's handling it.
Other documentation issues
You'll also find requests for documentation filed under the Documentation Request component in Bugzilla. These are typically requests to create new documents, although sometimes they're requests for fixes to existing material as well. They may not necessarily correspond to engineering bugs (although sometimes they do).
"Firefox X for developers"
Each major release of Firefox has a corresponding page entitled "Firefox X for developers". Major changes that impact developers typically appear in definition lists, with the title of the corresponding article or section and a brief explanation of the change. Minor changes are listed as bullet points in a "Miscellaneous changes" section.
As a general rule, items listed on this page in definition lists are top-priority documentation items and should be documented as early as possible in the documentation cycle for the given release.
- Firefox 4 for developers
- Firefox 3.6 for developers
- Firefox 3.5 for developers
- Firefox 3 for developers
- Firefox 2 for developers
- Firefox 1.5 for developers
The Bugzilla "Whiteboard" field
We use the whiteboard field on Bugzilla to track the status of documentation for a bug.
||The writer(s) have requested information from the engineers and are awaiting a reply before documentation work can continue.|
||The documentation work is on hold pending the engineering work actually being complete and landing on the tree. This is generally used when a bug is fixed, but for whatever reason, the patch hasn't landed yet.|
||The documentation work is on hold until documentation work for the specified Gecko version is underway. We use this to help us filter out documentation that's lower priority due to being for some future release when we do Bugzilla queries.|
You should never delete anything from the whiteboard field that isn't one of these terms; the whiteboard is used by other teams too. Instead, add them, separated by commas, and delete them when they no longer apply.
Using the whiteboard properly lets the writers keep track of what's ready to document and what isn't. It also helps us track the priority of documentation issues; obviously, bugs for the current (or upcoming) release are generally more important than bugs for some future release.
A workflow example
Let's say a bug is filed, suggesting the addition of a new method,
foo(), to the
nsIBar interface. Hopefully, the person filing the bug will apply the
dev-doc-needed keyword, indicating that the bug will result in documentation requiring changes. Otherwise, eventually someone will do it. It might be a writer, it might be the engineer that will make the code changes, it might be some other interested party.
At this point, it comes onto your radar as a writer that looks for documentation bugs. You take a look at the bug, and see that it hasn't actually been fixed yet, so you leave it be for now.
Eventually, you notice that there's a patch and the bug's status is FIXED. At this point, you decide you'd like to write about this. So you set the bug's assignee to yourself, letting people know you're writing it (preferably with a comment saying so, for the benefit of people that don't realize you're a writer), and set to work.
After a while, you realize that the code isn't self-explanatory, or there's some other detail you need explained. So you send email to the engineer, or add a comment to the bug, asking your question or questions. Now, you're blocked pending the answer, so you add
doc-waiting-info to the whiteboard and find other work to do until you get a reply.
Once you get your reply (either by email, or as a follow-up comment on the bug itself), you remove the
doc-waiting-info term from the whiteboard and return to writing.
Once writing is complete, you change the
dev-doc-needed keyword to
dev-doc-complete. You should also comment in the bug, saying you've finished the documentation work, with URLs to the updated page or pages, including anchors if the change is in a specific section.