Test Case for Yum document

[Karsten Wade]

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
////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/docs/attachments/20061218/6e1ab2fc/attachment.bin