On 3/22/07, <b class="gmail_sendername">Karsten Wade</b> &lt;<a href="mailto:kwade@redhat.com">kwade@redhat.com</a>&gt; wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Good idea.&nbsp;&nbsp;Having this discussion in the open makes sure we are all<br>working from a common ground.</blockquote><div><br>Absolutely. Thanks for replying! <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Such as, have a mapping of content to who owns it?&nbsp;&nbsp;Then issue an email<br>that is a diff or a patch?</blockquote><div><br>This was my thinking, yes. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
That&#39;s not a bad idea.&nbsp;&nbsp;It could get annoying, so maybe we need a way to<br>bundle up all the changes into one send, v. sending every time someone<br>saves a change to the wiki.</blockquote><div><br>Two ways that jump out at me. 
<br>(1) Do a batch run. So N days before a release, we run a script that makes one big diff per page and send it out to each respective maintainer.<br>(2) Have a Stable page version. So each change doesn&#39;t get a patch release, but once we have a reviewer/editor approve a set of changes, they move the Stable bit up to that version of the page.
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I think this stretches waaaaaay back to an old Red Hat Docs Team goal of<br>converting all the man pages to a DocBook format, and then work on
<br>improving them.<br><br>The main motivations I can think of are:<br><br>1. Provide useful, Fedora-specific content (man/info pages that only<br>appear in Fedora)<br>2. Make this content available in many ways (CLI, WUI, but if they were
<br>XML, they could appear in GNOME Yelp or KDE Help)<br>3. Contribute fixes back upstream to improve the state of all content<br><br>It is the latter that is truly the most interesting ... and also the<br>hardest to accomplish.
<br></blockquote></div><br>#3 Is really my end goal, I think. First, get all the documentation into some common format (DocBook, XML, a MySQL database), and then have some facilities to  export (and push changes) to various upstream and user interfaces. Web, GUI, CLI, etc. The more the better, so long as they serve a useful purpose.
<br><br>Of course, this is a big project that most be broken down into various, bite-sized steps.<br><br>-- <br>Michael Burns * Security Student<br>NET * Oregon State University