On Mon, 2006-12-18 at 19:58 +0300, John Babich wrote: > Team Members: > > Here is a test case for updating the yum guide, "Managing Software with Yum". [snip bug] > The current approach is to file a bug report with bugzilla. > Should we continue with this approach? Yes, although in this case you might skip that since you are involved as a maintainer for that guide. However, the value of using bugzilla extends to other people who find this bug, maybe in a mirror version or old copy. The existence of the bug report can be helpful in resolving that. > Do we correct the wiki version instead and then apply the > fixes to the DocBook version? The wiki page is located at > http://fedoraproject.org/wiki/Docs/Drafts/SoftwareManagementGuide/YumProxy Once a bug has been filed, the writer researches the bug. Assuming a fix is required, the fix is applied to the *source*. Then the source is used to rebuild the document, which is published again. In the case of this guide, the source is XML in CVS. For the release notes, the source is the Wiki. *However*, because of the complexity and lossiness of conversion from the Wiki, for the release notes we are fixing it in the Wiki _and_ manually fixing the same spot in the XML. I think we would all agree that if you find a bug in your own work, or in a work you are a permitted contributor for, you don't need to file the bug. The only reason to file is if you need a conversation (on record) with people about a fix, etc. For example, the correction in the documentation might be a poor fix where the application in question really needs to be fixed. So, you might start up a bug report about the problem in the document, drag in the application maintainer, and then eventually reassign the bug to that person to fix in the application. Then they can reassign the bug back to the writer to note the fix in the documentation. Clear as mud? > This is a real example. I am in the process of documenting the > work flow and really would like feedback on this. Go ahead and roll it out as you come up with it (http://fedoraproject.org/wiki/DocsProject/WorkFlow) and we'll watch to see if there are any missing pieces in the workflow. - Karsten -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-docs-list mailing list fedora-docs-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-docs-list
