On Thu, 2004-08-19 at 10:04, Karsten Wade wrote: > Besides, I put out the ver. 2 of the process doc the other day, so I'm > waiting for feedback. :) > http://people.redhat.com/kwade/fedora-docs/process-docs/fedora-docs-process-en.html If you want a fast, Emacs based entry, read the Quick Start... Need a link to the quick start ... or a statement its tba Know what documents are in progress; refer to bug 129807 Need more? If you are going to (ab)use the bug system, at least document how its going to be used. Ditto with 129784 One of the reasons for using Emacs is that it is capable of indenting the code according to the DTD. DTD's aren't fashion or style statements. No such thing as indenting in a DTD. If this project is going to use non-xml tools for diff generation, admit it as a shortcoming and apologise :-) If you do not have usable Web space, look for willing hosting partners in the project, who can build and host your beta documents. controversial recommendation? open +1. I'll host it. Maybe also Brad? Less sure about the XML. My principle has always been keep the source to yourself until you're ready? Issue of two people concurrently making mods? XML patches are (IMHO) better against a finished document? Comments yes, but that can be against html. Spell check all files. How, if emacs is used? spellcheck in xml I haven't done. (Or is that obvious?) Verify that all sections have an id so all HTML files generated have static filenames. Disagree. Overboard | unnecessary IMHO. Chunking is currently at sect1 level. Verify the HTML Output: Redundant, since its not the authors html that will be used. If we can't trust the toolchain to generate good links .... +1 on editor outline tasks. General. How about a list of links (appendix)? Not mentioned: Managing revisionss (fc2 vs fc3 etc) Should be in author section? I like it. regards DaveP -- Regards DaveP. XSLT&Docbook FAQ http://www.dpawson.co.uk/xsl
