[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ A ] [ next ]
Bug reports should be filed to the Debian Documentation Project List, [email protected]
if the particular document is not packaged as a Debian package. If a BTS entry
for the package exists, you are highly encouraged to file a bug to the package.
It is recommended to send translation-related bugs against the particular
packagename-LANG package instead of the source package
itself.
Please avoid sending bug reports (or requests) to the document maintainers directly. Maintainers are already subscribed to the BTS and sending them the bugs directly only increases that chances that the mail might get lost (forgotten, deleted accidentally) if the maintainer is managing a big mailbox [10] Also, your requests and suggestions might be lost if the document switches maintainers (due to inactivity, lack of time or any other reason).
Also, please do not send bugs regarding documentation to the debian-doc mailing list unless you want to discuss some issue before submitting a bug report. After all, the Bug Tracking system is better suited to track bugs (it was designed for that). You can, using the BTS, receive a report when the bug is fixed and a new document version is released.
Documentation maintainers and active authors should be subscribed to the Bug Tracking System for the source packages that generate the documentation (if they are not packaging the documents themselves). Translators must be subscribed to the BTS for the translated package versions.
You can use the PTS
to subscribe to debian packages when you are not the maintainer.
The bug report should follow standard Debian bug style (see the BTS documentation).
In order to clarify the types of report, use of following words at the start of the subject line is encouraged.
policy: policy compliance issues
errata: errata information on document content
patch: errata or additional information with patch
request: request for additional information or clarification
...
Any bug report which falls into "request" must be filed with "priority: wishlist".
Bug reporters are encouraged to provide the diff file to the source files such as SGML or XML but the diff file to the generated plain text file is accepted by the document maintainers as an alternative. This means that users do not have to learn SGML to submit changes to our documents. When creating diff files, please use "-u" option. [11]
If you are not sure on how to make diff files, please submit bugs indicating clearly the location of the errata (usually citing text in the document). Otherwise it's more difficult for documentation maintainers to determine what exactly needs to be fixed.
FIXME: This is a proposal to use the WNPP also for documentation
You can make use of the WNPP to ask for
documentation on a specific topic that you think it's needed. Document
maintainers can also use the WNPP to submit information on documentation under
development or that it's going to be orphaned.
The following tags of the WNPP are appropriate for this task:
O: as the package equivalent, this means that the author intents to orphan a given set of documentation.
ITA: as the package equivalent, this means that the author intents to adopt a given set of documentation.
RFD (Request for Documentation): a user that detects that a given document (manual or other) on a given topic is not yet available on the DDP can ask for it using this tag. DDP members will give priority when deciding which documents need to be written to requests on a given document by a number of users.
ITD (Intend to Document): a documentation maintainer that is going to start writting a document. The use of the WNPP for avoids people duplicating effort writing the same documentation.
ITT (Intend to Translate): a translator is going to start translating a document. As above, this tries to prevent duplicate efforts.
Usually a RFP changes into a ITD when someone starts working on the document. When closed it means that the document has been created and is available in the DDP. It will keep this way until it's orphaned (O) and a new maintainer (ITA) appears again. The same would happen for translations of the document into any given language. Thus, a normal document would follow the documentation process shown below:
RFD---->ITD----->(document maintained/updated)------->O
| ^ |
| | |
| (first commit)----ITA<-------
|
---> ITT ---> (translation update) ---->O
^ |
| |
(first commit)----ITA<-------
[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ A ] [ next ]
Debian Documentation Policy (DRAFT)
[email protected]