* a whole bunch of small changes, centered in the introduction

[fspm_howto] / FreeSoftwareProjectManagementHOWTO.sgml

diff --git a/FreeSoftwareProjectManagementHOWTO.sgml b/FreeSoftwareProjectManagementHOWTO.sgml
index 96b8dd146551bc05cec7247714f71b53d5fdd9b3..e94255cef2519ed02a2451d4f89137f45dbac546 100644 (file)
--- a/FreeSoftwareProjectManagementHOWTO.sgml
+++ b/FreeSoftwareProjectManagementHOWTO.sgml
@@ -5,84 +5,88 @@
 <!-- Header -->
 
  <artheader>
 <!-- Header -->
 
  <artheader>

-  <title>Free Software Development HOWTO</title>
-
+  <title>Free Software Project Management HOWTO</title>
+  

   <author>
   <author>

-     <firstname>Benjamin</firstname>
-     <othername>Mako</othername>
-     <surname>Hill</surname>
-     <affiliation>
-        <address>
-           <email>mako@debian.org</email>
-
-        </address>
-     </affiliation>
+   <firstname>Benjamin</firstname>
+   <othername>"Mako"</othername>
+   <surname>Hill</surname>
+   <affiliation>
+    <address>
+      <email>mako@debian.org</email>
+    </address>
+   </affiliation>

   </author>
 
   </author>
 

-   <revhistory>
-      <revision>
-         <revnumber>v0.01</revnumber>
-         <date>25 March 2001</date>
-         <authorinitials>bch</authorinitials>
-          <revremark>
-         Initial Release
-         </revremark>
-      </revision>
-   </revhistory>
+  <revhistory>
+   <revision>
+    <revnumber>v0.3</revnumber>
+    <date>5 May 2001</date>
+    <authorinitials>bch</authorinitials>
+   </revision>
+
+   <revision>
+    <revnumber>v0.2.1</revnumber>
+    <date>10 April 2001</date>
+    <authorinitials>bch</authorinitials>
+   </revision>
+
+   <revision>
+    <revnumber>v0.2</revnumber>
+    <date>8 April 2001</date>
+    <authorinitials>bch</authorinitials>
+   </revision>
+
+   <revision>
+    <revnumber>v0.01</revnumber>
+    <date>27 March 2001</date>
+    <authorinitials>bch</authorinitials>
+    <revremark>Initial Release</revremark>
+   </revision>
+  </revhistory>

 
   <abstract>
 
   <abstract>

-    <indexterm>
-      <primary>fswd</primary>
-    </indexterm>
-
-    <para>
-     This HOWTO is designed for people with experience in programming
-     and some skills in managing a software project but who are new to
-     the world of Free Software. This document is meant to act as a
-     guide to the non-technical aspects of programming and was written
-     to act as a crash course in the people skills that aren't taught
-     to commercial coders but that can make or break a free software
-     project.
-    </para>
+   <indexterm>
+    <primary>fswd</primary>
+   </indexterm>
+   
+   <para>
+    This HOWTO is designed for people with experience in programming
+    and some skills in managing a software project but who are new to
+    the world of free software. This document is meant to act as a
+    guide to the non-technical aspects of free software project
+    management and was written to be a crash course in the people
+    skills that aren't taught to commercial coders but that can make
+    or break a free software project.
+   </para>

   </abstract>
   </abstract>

-
+  

  </artheader>
 
 <!-- Section1: intro -->
 
  <sect1 id="intro">
  </artheader>
 
 <!-- Section1: intro -->
 
  <sect1 id="intro">

-   <title>Introduction</title>
-
-   <indexterm>
-    <primary>fswd!introduction</primary>
-   </indexterm>
-
-  <para>
-   For various reasons, this release has been code-named the
-   <emphasis>homemade yogurt</emphasis> release.
-  </para>
-
-  <para>
-   New code names will appear as per industry standard
-   guidelines to emphasize the state-of-the-art-ness of this
-   document.
-  </para>
-
+  <title>Introduction</title>
+  
+  <indexterm>
+   <primary>fswd!introduction</primary>
+  </indexterm>
+  

   <para>
    Skimming through freshmeat.net provides mountains of reasons for this
    HOWTO's existence--the Internet is littered with excellently
   <para>
    Skimming through freshmeat.net provides mountains of reasons for this
    HOWTO's existence--the Internet is littered with excellently

-   written and useful programs that have faded away into the Universe
-   of Free Software Forgottenness. This dismal scene made me ask
+   written and useful programs that have faded away into the universe
+   of free software forgottenness. This dismal scene made me ask

    myself, "Why?"
   </para>
 
   <para>
    myself, "Why?"
   </para>
 
   <para>

-   This HOWTO tries to do a lot of thing (probably too many), but it
+   This HOWTO tries to do a lot of things (probably too many), but it

    can't answer that question and won't attempt it. What this HOWTO
    will attempt to do is give your Free Software project a fighting
    can't answer that question and won't attempt it. What this HOWTO
    will attempt to do is give your Free Software project a fighting

-   chance-an edge. If you write a piece of crap that no one is
-   interested in, you can read this HOWTO until you recite it in your
-   sleep and your project will probably fail. Then again, you can
+   chance--an edge. If you write a piece of crap that no one is
+   interested in, you can read this HOWTO until you can recite it in
+   your sleep and your project will probably fail. Then again, you can

    write a beautiful, relevant piece of software and follow every
    instruction in this HOWTO and your software may still not make
    it. Sometimes life is like that. However, I'll go out a limb and
    write a beautiful, relevant piece of software and follow every
    instruction in this HOWTO and your software may still not make
    it. Sometimes life is like that. However, I'll go out a limb and


@@ -95,15 +99,11 @@
    A lot of the information in this HOWTO is best called common
    sense. Of course, as any debate on interfaces will prove, what is
    common sense to some programmers proves totally unintuitive to
    A lot of the information in this HOWTO is best called common
    sense. Of course, as any debate on interfaces will prove, what is
    common sense to some programmers proves totally unintuitive to

-   others. After explaining bites and pieces of this HOWTO to Free
-   Software developers on several occasions, I realized that that
-   writing this HOWTO might provide a useful resource and a forum for
+   others. After explaining bits and pieces of this HOWTO to Free
+   Software developers on several occasions, I realized that writing
+   this HOWTO might provide a useful resource and a forum for

    programmers to share ideas about what has and has not worked for
    programmers to share ideas about what has and has not worked for

-   them. 
-  </para>
-
-  <para>
-
+   them.

   </para>
 
   <para>
   </para>
 
   <para>


@@ -119,41 +119,19 @@
 
    <para>
     This document is copyrighted (c) 2000 Benjamin (Mako) Hill and is
 
    <para>
     This document is copyrighted (c) 2000 Benjamin (Mako) Hill and is

-    distributed under the terms of the Linux Documentation Project
-    (LDP) license, stated below.
-   </para>
-
-   <para>
-    Unless otherwise stated, Linux HOWTO documents are
-    copyrighted by their respective authors. Linux HOWTO documents may
-    be reproduced and distributed in whole or in part, in any medium
-    physical or electronic, as long as this copyright notice is
-    retained on all copies. Commercial redistribution is allowed and
-    encouraged; however, the author would like to be notified of any
-    such distributions.
-   </para>
-
-   <para>
-    All translations, derivative works, or aggregate works
-    incorporating any Linux HOWTO documents must be covered under this
-    copyright notice. That is, you may not produce a derivative work
-    from a HOWTO and impose additional restrictions on its
-    distribution. Exceptions to these rules may be granted under
-    certain conditions; please contact the Linux HOWTO coordinator at
-    the address given below.
-   </para>
-
-   <para>
-    In short, we wish to promote dissemination of this
-    information through as many channels as possible. However, we do
-    wish to retain copyright on the HOWTO documents, and would like to
-    be notified of any plans to redistribute the HOWTOs.
+    distributed under the terms of the <citetitle>GNU Free
+    Documentation License</citetitle>.

    </para>
 
    </para>
 

-   <para>
-    If you have any questions, please contact 
-    <email>linux-howto@metalab.unc.edu</email>
-   </para>
+    <para>
+     Permission is granted to copy, distribute and/or modify this
+     document under the terms of the <link
+     linkend="fdl"><citetitle>GNU Free Documentation
+     License</citetitle></link>, Version 1.1 or any later version
+     published by the Free Software Foundation with no Invariant
+     Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy
+     of the license can be found in <xref linkend="fdl">.
+    </para>

   </sect2>
 
 <!-- Section2: disclaimer -->
   </sect2>
 
 <!-- Section2: disclaimer -->


@@ -163,11 +141,12 @@
 
    <para>
     No liability for the contents of this documents can be accepted.
 
    <para>
     No liability for the contents of this documents can be accepted.

-    Use the concepts, examples and other content at your own risk.
-    As this is a new edition of this document, there may be errors
-    and inaccuracies, that may of course be damaging to your system.
-    Proceed with caution, and although this is highly unlikely,
-    the author(s) do not take any responsibility for that.
+    Use the concepts, examples and other content at your own risk.  As
+    this is a new edition of this document, there may be errors and
+    inaccuracies, that may of course be damaging to your project (and
+    potentially your system).  Proceed with caution, and although this
+    is highly unlikely, the author(s) does not take any responsibility
+    for that.

    </para>
 
    <para>
    </para>
 
    <para>


@@ -182,10 +161,6 @@
     as endorsements.
    </para>
 
     as endorsements.
    </para>
 

-   <para>
-    You are strongly recommended to take a backup of your system 
-    before major installation and backups at regular intervals.
-   </para>

   </sect2>
 
 <!-- Section2: newversions-->
   </sect2>
 
 <!-- Section2: newversions-->


@@ -193,22 +168,18 @@
   <sect2 id="newversions">
    <title>New Versions</title>
 
   <sect2 id="newversions">
    <title>New Versions</title>
 

-    <indexterm>
-     <primary>(your index root)!news on</primary>
-    </indexterm>
-

    <para>
    <para>

-    This is the initial release. It is written to be released to
-    developers for critique and brainstorming and submitted to
-    Hampshire College for academic credit. Please keep in mind that
-    this version of the HOWTO is still in an infant stage and will be
-    revised extensively before it hits the LDP.
+    This version is the part of the third pre-release cycle of this
+    HOWTO. It is written to be released to developers for critique and
+    brainstorming. Please keep in mind that this version of the HOWTO
+    is still in an infant stage and will continue to be revised
+    extensively.

    </para>
 
    <para>
     The latest version number of this document should always be listed
    </para>
 
    <para>
     The latest version number of this document should always be listed

-    on <ulink url="http://people.debian.org/~mako/">my webpage at
-    Debian</ulink>.
+    on <ulink url="http://yukidoke.org/~mako/projects/howto">the projects
+    homepage </ulink> hosted by <ulink url="http://yukidoke.org">yukidoke.org.</ulink>

    </para>
 
    <para>
    </para>
 
    <para>


@@ -218,35 +189,35 @@
 
    <para>
    <itemizedlist>
 
    <para>
    <itemizedlist>

+

     <listitem>
      <para>
     <listitem>
      <para>

-      <ulink url="http://people.debian.org/~mako/howto/fswd-howto.html">HTML</ulink>.
+      <ulink url="http://yukidoke.org/~mako/projects/howto/FreeSoftwareProjectManagement-HOWTO/t1.html">HTML</ulink>.

      </para>
     </listitem>
 
      </para>
     </listitem>
 

+

     <listitem>
      <para>
     <listitem>
      <para>

-       <ulink URL="http://people.debian.org/~mako/howto/fswd-howto.txt">plain text</ulink>.
+      <ulink url="http://yukidoke.org/~mako/projects/howto/FreeSoftwareProjectManagement-HOWTO.html">HTML (single page)</ulink>.

      </para>
     </listitem>
 
     <listitem>
      <para>
      </para>
     </listitem>
 
     <listitem>
      <para>

-      <ulink url="http://people.debian.org/~mako/howto/fswd-howto.US.ps.gz">compressed 
-       postscript (US letter format)</ulink>.
+      <ulink URL="http://yukidoke.org/~mako/projects/howto/FreeSoftwareProjectManagement-HOWTO.txt">plain text</ulink>.

      </para>
     </listitem>
 
     <listitem>
      <para>
      </para>
     </listitem>
 
     <listitem>
      <para>

-      <ulink url="http://people.debian.org/~mako/howto/fswd-howto.UF.ps.gz">compressed 
-       postscript (Universal format / 8.27x11in; 210x279mm)</ulink>.
+      <ulink url="http://yukidoke.org/~mako/projects/howto/FreeSoftwareProjectManagement-HOWTO.ps.gz">Compressed postscript</ulink>.

      </para>
     </listitem>
 
     <listitem>
      <para>
      </para>
     </listitem>
 
     <listitem>
      <para>

-      <ulink url="http://people.debian.org/~mako/howto/fswd-howto.sgml">SGML source</ulink>.
+      <ulink url="http://yukidoke.org/~mako/projects/howto/FreeSoftwareProjectManagement-HOWTO.sgml.gz">Compressed SGML source</ulink>.

      </para>
     </listitem>
    </itemizedlist>
      </para>
     </listitem>
    </itemizedlist>


@@ -263,45 +234,65 @@
    </para>
 
    <para>
    </para>
 
    <para>

-    <emphasis>Karl Fogel</emphasis>, the author of <emphasis>Open
-    Source Development with CVS</emphasis> published by the Coriolis
-    Open Press. Large parts of the book are available <ulink
+    Anyone who gave me an idea for a better name and everyone who
+    assured me that a <citetitle>Project Management HOWTO</citetitle>
+    didn't necessary sound corporate.
+   </para>
+
+   <para>
+    Josh Crawford, Andy King, and Jaime Davila who all read through
+    this in entirety and gave me feedback that has helped me make
+    changes and improvements to this document. I can't thank you guys
+    enough for your help. An extra <quote>Thank You</quote> goes to
+    Andy King who who read through this several times and submitted
+    patches to make life easier for me.
+   </para>
+
+   <para>
+    Karl Fogel, the author of <citetitle>Open Source Development with
+    CVS</citetitle> published by the Coriolis Open Press. Large parts
+    of his book are available <ulink

     url="http://cvsbook.red-bean.com">on the web</ulink>. 225 pages of
     the book are available under the GPL and constitute the best
     url="http://cvsbook.red-bean.com">on the web</ulink>. 225 pages of
     the book are available under the GPL and constitute the best

-    tutorial on CVS I have ever seen. The rest of the book covers,
-    "the challenges and philosophical issues inherent in running an
-    Open Source project using CVS." The book does a good job of
-    covering some of the subjects brought up in this HOWTO and much
+    tutorial on CVS I've ever seen. The rest of the book covers,
+    <quote>the challenges and philosophical issues inherent in running
+    an Open Source project using CVS.</quote> The book does a good job
+    of covering some of the subjects brought up in this HOWTO and much

     more. <ulink url="http://cvsbook.red-bean.com">The book's
     website</ulink> has information on ordering the book and provides
     more. <ulink url="http://cvsbook.red-bean.com">The book's
     website</ulink> has information on ordering the book and provides

-    several translations of the chapters on CVS. I you are seriously
-    interested in running a Free Software project, you want this book.
+    several translations of the chapters on CVS. If you are seriously
+    interested in running a Free Software project, you want this
+    book. I tried to mention Fogel in sections of this HOWTO where I
+    knew I was borrowing directly from his ideas. If I missed any, I'm
+    sorry. I'll try and have those fixed in future versions.

    </para>
    
    <para>
     Karl Fogel can be reached at <email>kfogel (at) red-bean (dot)
     com</email>
    </para>
    </para>
    
    <para>
     Karl Fogel can be reached at <email>kfogel (at) red-bean (dot)
     com</email>
    </para>

+

    <para>
    <para>

-    Also providing support and material, and inspiration for this
-    HOWTO is Eric S. Raymond for his prolific, consistent, and
-    carefully crafted arguments, to Lawrence Lessig for reminding me
-    of the importance of Free Software and to every user and developer
-    involved with the <ulink url="http://www.debian.org">Debian
-    Project</ulink>. The project has provided me with a home, a place
-    to practice Free Software advocacy and to make a difference, a
-    place to learn from those how have been involved with the movement
-    much longer than I, and an proof of a Free Software project that
-    <emphasis>definitely, definitely works</emphasis>.
+    Also providing support material, and inspiration for this HOWTO is
+    Eric S. Raymond for his prolific, consistent, and carefully
+    crafted arguments and Lawrence Lessig for reminding me of the
+    importance of Free Software. Additionaly, I want to thank every
+    user and developer involved with the <ulink
+    url="http://www.debian.org">Debian Project</ulink>. The project
+    has provided me with a home, a place to practice free software
+    advocacy, a place to make a difference, a place to learn from
+    those who have been involved with the movement much longer than I,
+    and proof of a free software project that definitely, definitely
+    works.

    </para>
 
    <para>
     Above all, I want to thank <emphasis>Richard Stallman</emphasis>
     for his work at the Free Software Foundation and for never giving
    </para>
 
    <para>
     Above all, I want to thank <emphasis>Richard Stallman</emphasis>
     for his work at the Free Software Foundation and for never giving

-    up. Stallman provided the philosophical basis that attracts me to
-    Free Software and that drives me towards writing a document to
-    make sure it succeeds. RMS can always be emailed at <email>rms
-    (at) gnu (dot) org</email>.
+    up. Stallman provides and articulates the philosophical basis that
+    attracts me to free software and that drives me towards writing a
+    document to make sure it succeeds. RMS can always be emailed at
+    <email>rms (at) gnu (dot) org</email>.

    </para>
 
   </sect2>
    </para>
 
   </sect2>


@@ -312,14 +303,16 @@
    <title>Feedback</title>
 
    <para>
    <title>Feedback</title>
 
    <para>

-    Feedback is most certainly welcome for this document. Without your
-    submissions and input, this document wouldn't exist. Something
-    missing? Don't hesitate to contact me and to write a chapter. I
-    want this document to be as much a product of the Free Software
-    development process that it heralds and I think its ultimate
-    success will be rooted in this fact. Please send your additions,
-    comments and criticisms to the following email address :
-    <email>mako@debian. org</email>.
+    Feedback is always and most certainly welcome for this
+    document. Without your submissions and input, this document
+    wouldn't exist. Do you feel that something is missing? Don't
+    hesitate to contact me to have me write a chapter, section, or
+    subsection or to write one yourself. I want this document to be a
+    product of the Free Software development process that it heralds
+    and I believe that its ultimate success will be rooted in its
+    ability to do this. Please send your additions, comments, and
+    criticisms to the following email address:
+    <email>mako@debian.org</email>.

    </para>
    </sect2>
 
    </para>
    </sect2>
 


@@ -331,11 +324,12 @@
    <para>
     I know that not everyone speaks English. Translations are nice and
     I'd love for this HOWTO to gain the kind of international reach
    <para>
     I know that not everyone speaks English. Translations are nice and
     I'd love for this HOWTO to gain the kind of international reach

-    afforded by a translated version.
+    afforded by translated versions.

    </para>
    </para>

+

    <para>
     However, this HOWTO is still young and I have to yet to be
    <para>
     However, this HOWTO is still young and I have to yet to be

-    contacted about a translation so English is all that is
+    contacted about a translation so English is all that is currently

     available. If you would like to help with or do a translation, you
     will gain my utmost respect and admiration and you'll get to be
     part of a cool process. If you are at all interested, please don't
     available. If you would like to help with or do a translation, you
     will gain my utmost respect and admiration and you'll get to be
     part of a cool process. If you are at all interested, please don't


@@ -355,30 +349,28 @@
     <primary>fswd!starting</primary>
    </indexterm>
   <para>
     <primary>fswd!starting</primary>
    </indexterm>
   <para>

-   With very little argument, starting a project is most difficult
-   part of successful free software development. Laying a firm
-   foundation for your project will determine whether your project
-   flourishes or withers away and dies. It is also the subject that is
-   of most immediate interest to anyone reading this document as a
-   tutorial.
+   With very little argument, the beginning is the most difficult
+   period in a project's life to do successful free software project
+   managment. Laying a firm foundation will determine whether your
+   project flourishes or withers away and dies. It is also the subject
+   that is of most immediate interest to anyone reading this document
+   as a tutorial.

   </para>
 
   <para>
   </para>
 
   <para>

-   Starting a project also involves a dilemma that you as a developer
-   must try and deal with. No potential user for your program will be
-   interested by a program that doesn't work. Simultaneously, the
-   development process that you want to employ holds involvement of
-   users as essential to the process of the development that will
-   realize this working software.
+   Starting a project involves a dilemma that you as a developer must
+   try and deal with: no potential user for your program is interested
+   in a program that doesn't work, while the development process that
+   you want to employ holds involvement of users as imperative.

   </para>
 
   <para>
    It is in these dangerous initial moments that anyone working to
   </para>
 
   <para>
    It is in these dangerous initial moments that anyone working to

-   start a free software project must strike a balance. One of the
-   most important ways that someone trying to start a project can work
-   towards this balance is by establishing a framework for the
-   development process through some of the ways mentioned in this
-   section.
+   start a free software project must try and strike a balance along
+   these lines. One of the most important ways that someone trying to
+   start a project can work towards this balance is by establishing a
+   solid framework for the development process through some of the
+   suggestions mentioned in this section.

   </para>
 
 
   </para>
 
 


@@ -389,39 +381,52 @@
 
    <para>
     If you are reading this document, there's a good chance you
 
    <para>
     If you are reading this document, there's a good chance you

-    already have an idea for a project in mind. Chances are pretty
-    good, it fills a gap by doing something that no other free
-    software process does or or does it in a way that is unique
-    enough to necessitate a separate project.
+    already have an idea for a project in mind. Chances are also
+    pretty good that it fills a percieved gap by doing something that
+    no other free software project does or by doing something in a way
+    that is unique enough to necessitate a brand new piece of
+    software.

    </para>
 
    <sect3 id=identifyidea>
     <title>Identify and articulate your idea</title>
     <para>
      Eric S. Raymond writes about how free software projects start in
    </para>
 
    <sect3 id=identifyidea>
     <title>Identify and articulate your idea</title>
     <para>
      Eric S. Raymond writes about how free software projects start in

-     his paper, "The Cathedral and the Bazaar" which comes as required
-     reading for any free software development. You can find it <ulink
-     url="http://www.tuxedo.org/~esr/writings/cathedral-bazaar/">online
-     </ulink>.
+     his essay, <ulink
+     url="http://www.tuxedo.org/~esr/writings/cathedral-bazaar/"><quote>The
+     Cathedral and the Bazaar,</quote></ulink> which comes as required
+     reading for any free software developer. It is available online .

     </para>
 
     <para>
     </para>
 
     <para>

-     In "The Cathedral and Bazaar," Raymond tells us that:
-     <emphasis>Every good work of software starts by scratching a
-     developers itch.</emphasis> Raymond now widely accepted
+     In <quote>The Cathedral and the Bazaar,</quote> Raymond tells us
+     that: <quote>every good work of software starts by scratching
+     a developers itch.</quote> Raymond's now widely accepted

      hypothesis is that new free software programs are written, first
      and foremost, to solve a specific problem facing the developer.
     </para>
 
     <para>
      If you have an idea for a program in mind, chances are good that
      hypothesis is that new free software programs are written, first
      and foremost, to solve a specific problem facing the developer.
     </para>
 
     <para>
      If you have an idea for a program in mind, chances are good that

-     it it is targeting a specific problem or itch you want to see
-     scratched. <emphasis>This idea is the project. Articulate it
-     clearly. Write it out. Describe the problem you will attack in
-     detail. The success of your project in tackling a particular
-     problem will be tied to your ability to identify that problem
-     early on. Find out exactly what it is that you want your project
-     to do.</emphasis>
+     it targets a specific problem or <quote>itch</quote> you want to
+     see scratched. <emphasis>This idea is the project.</emphasis>
+     Articulate it clearly. Write it out. Describe the problem you
+     will attack in detail. The success of your project in tackling a
+     particular problem will be tied to your ability to identify that
+     problem clearly early on. Find out exactly what it is that you
+     want your project to do.
+    </para>
+
+    <para>
+     Monty Manley articulates the importance of this initial step in
+     an essay, <quote><ulink
+     url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing
+     Projects the Open Source Way.</ulink></quote> As the next section
+     will show, there is <emphasis>a lot</emphasis> of work that needs
+     to be done before software is even ready to be coded. Manley
+     says, <quote>Beginning an OSS project properly means that a
+     developer must, first and foremost, avoid writing code too
+     soon!</quote>

     </para>
    </sect3>
 
     </para>
    </sect3>
 


@@ -429,103 +434,109 @@
     <title>Evaluate your idea</title>
 
     <para>
     <title>Evaluate your idea</title>
 
     <para>

-     In evaluating your idea, you need to ask yourself questions.
-     Before you move any further into this HOWTO, you need to
-     determine if the free software development model really is the
-     right one for your project. Obviously, since the program
-     scratches your itch, you are definitely interested in seeing it
-     implemented in code. But, because one hacker coding alone fails
-     to qualify as a free software development effort, you need to ask
-     yourself the question: <emphasis>Is anybody else
-     interested?</emphasis>
+     In evaluating your idea, you need to first ask yourself a few
+     questions.  This should happen before you move any further
+     through this HOWTO. Ask yourself: <emphasis>Is the free software
+     development model really the right one for your
+     project?</emphasis>
+    </para>
+
+    <para>
+     Obviously, since the program scratches your itch, you are
+     definitely interested in seeing it implemented in code. But,
+     because one hacker coding in solitude fails to qualify as a free
+     software development effort, you need to ask yourself a second
+     question: <emphasis>Is anybody else interested?</emphasis>

     </para>
 
     <para>
     </para>
 
     <para>

-     Sometimes the answer is <emphasis>no</emphasis>. If you want to
-     write a set of scripts to sort <emphasis>your</emphasis>
-     <acronym>MP3</acronym> collection on your machine, maybe the free
-     software development model is not the best one to
-     choose. However, if you want to write a set of scripts to sort
-     <emphasis>anyone's</emphasis> <acronym>MP3</acronym>s, a free
-     software project might fill a useful gap.
+     Sometimes the answer is a simple <quote>no.</quote> If you want
+     to write a set of scripts to sort <emphasis>your</emphasis>
+     <acronym>MP3</acronym> collection on <emphasis>your</emphasis>
+     machine, <emphasis>maybe</emphasis> the free software development
+     model is not the best one to choose. However, if you want to
+     write a set of scripts to sort <emphasis>anyone's</emphasis>
+     <acronym>MP3</acronym>s, a free software project might fill a
+     useful gap.

     </para>
 
     <para>
     </para>
 
     <para>

-     Luckily, The Internet is a place so big and diverse that, chances
-     are, there is someone, somewhere, who shares your interests and
-     how feels the same itch. It is the fact that there are so many
-     people with so many similar needs and desires that introduces the
-     second major question: <emphasis>Has somebody already had your
-     idea or a reasonably similar one?</emphasis>
+     Luckily, the Internet is a place so big and so diverse that,
+     chances are, there is someone, somewhere, who shares your
+     interests and who feels the same <quote>itch.</quote> It is the
+     fact that there are so many people with so many similar needs and
+     desires that introduces the third major question: <emphasis>Has
+     somebody already had your idea or a reasonably similar
+     one?</emphasis>

     </para>
 
      <sect4 id=evalwhere>
       <title>Finding Similar Projects</title>
 
      <para>
     </para>
 
      <sect4 id=evalwhere>
       <title>Finding Similar Projects</title>
 
      <para>

-      There are places you can go on the web to try and answer this
-      question. If you have experience with the free software
-      community, you are probably already familiar with all of these
-      sites. All of the resources listed bellow offer searching of
+      There are places you can go on the web to try and answer the
+      question above. If you have experience with the free software
+      community, you are probably already familiar with many of these
+      sites. All of the resources listed below offer searching of

       their databases:
      </para>
 
      <para>
      <variablelist>
        <varlistentry>
       their databases:
      </para>
 
      <para>
      <variablelist>
        <varlistentry>

-        <term>freshmeat.net:</term>
+        <term>freshmeat.net</term>

         <listitem>
         <listitem>

-        <para><ulink url="http://freshmeat.net">freshmeat</ulink>
+        <para><ulink url="http://freshmeat.net">freshmeat.net</ulink>

         describes itself as, <quote>the Web's largest index of Linux
         and Open Source software</quote> and its reputation along
         describes itself as, <quote>the Web's largest index of Linux
         and Open Source software</quote> and its reputation along

-        these lines remains unquestioned. If you can't find it on
-        freshmeat, its doubtful that you'll find it indexed anywhere
-        else.</para>
+        these lines is totally unparalleled and unquestioned. If you
+        can't find it on freshmeat, its doubtful that you (or anyone
+        else) will find it at all.</para>

         </listitem>
        </varlistentry>
 
        <varlistentry>
         </listitem>
        </varlistentry>
 
        <varlistentry>

-        <term>Slashdot:</term>
+        <term>Slashdot</term>

         <listitem>
         <para><ulink url="http://slashdot.org">Slashdot</ulink>
         <listitem>
         <para><ulink url="http://slashdot.org">Slashdot</ulink>

-        provides <quote>News for Nerds: Stuff that Matters,</quote>
+        provides <quote>News for Nerds. Stuff that matters,</quote>

         which usually includes discussion of free software, open
         which usually includes discussion of free software, open

-        source, technology, and geek culture new and events. It is
-        not unusual for an particularly sexy development effort to be
-        announced here so it definitely worth checking.</para>
+        source, technology, and geek culture news and events. It is
+        not unusual for a particularly sexy development effort to be
+        announced here, so it is definitely worth checking.</para>

         </listitem>
        </varlistentry>
 
        <varlistentry>
         </listitem>
        </varlistentry>
 
        <varlistentry>

-        <term>SourceForge:</term>
+        <term>SourceForge</term>

         <listitem>
         <para><ulink url="http://sourceforge.net">SourceForge</ulink>
         houses and facilitates a growing number of open source and
         <listitem>
         <para><ulink url="http://sourceforge.net">SourceForge</ulink>
         houses and facilitates a growing number of open source and

-        free software projects, SourceForge is quickly becoming a
-        nexus and an necessary stop for free software
+        free software projects. It is also quickly becoming a nexus
+        and a necessary stop for free software

         developers. SourceForge's <ulink
         url="http://sourceforge.net/softwaremap/trove_list.php">software
         map</ulink> and <ulink url="http://sourceforge.net/new/"> new
         developers. SourceForge's <ulink
         url="http://sourceforge.net/softwaremap/trove_list.php">software
         map</ulink> and <ulink url="http://sourceforge.net/new/"> new

-        releases</ulink> pages. should be necessary stops before
+        release</ulink> pages should be necessary stops before

         embarking on a new free software project. SourceForge also
         embarking on a new free software project. SourceForge also

-        provides a at <ulink
+        provides a <ulink

         url="http://sourceforge.net/snippet/">Code Snippet
         url="http://sourceforge.net/snippet/">Code Snippet

-        Library</ulink> which contains useful reusable chunks of
-        code in an array of languages which can come in useful in any
+        Library</ulink> which contains useful reusable chunks of code
+        in an array of languages which can come in useful in any

         project.</para>
         </listitem>
        </varlistentry>
 
        <varlistentry>
         project.</para>
         </listitem>
        </varlistentry>
 
        <varlistentry>

-        <term>Google and Google's Linux Search:</term>
+        <term>Google and Google's Linux Search</term>

         <listitem>
         <para><ulink url="http://www.google.com">Google</ulink> and
         <ulink url="http://www.google.com/linux"> Google's Linux
         <listitem>
         <para><ulink url="http://www.google.com">Google</ulink> and
         <ulink url="http://www.google.com/linux"> Google's Linux

-        Search</ulink>, provide powerful web searches that may
-        reveal people working on similar projects. It is not a
-        catalog of software or news like freshmeat or Slashdot, but
-        it is worth checking before you begin pouring your effort
-        into a redundant project.</para>
+        Search</ulink>, provides powerful web searches that may reveal
+        people working on similar projects. It is not a catalog of
+        software or news like freshmeat or Slashdot, but it is worth
+        checking to make sure you aren't pouring your effort into a
+        redundant project.</para>

         </listitem>
        </varlistentry>
 
         </listitem>
        </varlistentry>
 


@@ -536,52 +547,112 @@
     <sect4 id=evalhow>
      <title>Deciding to Proceed</title>
      <para>
     <sect4 id=evalhow>
      <title>Deciding to Proceed</title>
      <para>

-      Once you have successful charted the terrain and have an idea
-      bout what kinds of similar free software projects exist, every
+      Once you have successfully charted the terrain and have an idea
+      about what kinds of similar free software projects exist, every

       developer needs to decide whether to proceed with their own
       project. It is rare that a new project seeks to accomplish a
       developer needs to decide whether to proceed with their own
       project. It is rare that a new project seeks to accomplish a

-      goal that is not similar to related to the goal of another
-      project. Anyone starting a new project needs to ask themselves:
-      <emphasis>Will the new project be duplicating work done by
-      another project? Will the new project be competing for
+      goal that is not at all similar or related to the goal of
+      another project. Anyone starting a new project needs to ask
+      themselves: <quote>Will the new project be duplicating work done
+      by another project? Will the new project be competing for

       developers with an existing project? Can the goals of the new
       project be accomplished by adding functionality to an existing
       developers with an existing project? Can the goals of the new
       project be accomplished by adding functionality to an existing

-      project?</emphasis>
+      project?</quote>

      </para>
 
      <para>
      </para>
 
      <para>

-      If the answer to any of these questions is yes, try to contact
-      the developer of the existing project in question and see if he
-      or she might be willing to collaborate with you.
+      If the answer to any of these questions is <quote>yes,</quote>
+      try to contact the developer of the existing project(s) in
+      question and see if he or she might be willing to collaborate
+      with you.

      </para>
 
      <para>
      </para>
 
      <para>

-      This may be the single most difficult aspect of free software
-      development for many developers but it is essential. It is easy
-      to become fired up by and idea and be caught up in the momentum
-      and excitement of a new project. It is often extremely difficult
-      but it is important that any free software developer remember
-      that the best interests of the of the free software community
-      and the quickest way to accomplish ones own project's goals and
-      the goals of similar project can often be accomplished by
-      <emphasis>not</emphasis> starting a new project.
+      For many developers this may be the single most difficult aspect
+      of free software project managment, but it is an essential one. It is
+      easy to become fired up by an idea and get caught up in the
+      momentum and excitement of a new project. It is often extremely
+      difficult to do, but it is important that any free software
+      developer remembers that the best interests of the free software
+      community and the quickest way to accomplish your own project's
+      goals and the goals of similar projects can often be
+      accomplished by <emphasis>not</emphasis> starting a new
+      development effort.

      </para>
 
     </sect4>
    </sect3>
   </sect2>
 
      </para>
 
     </sect4>
    </sect3>
   </sect2>
 

+<!-- Section2: naming-->
+
+  <sect2 id="naming">
+   <title>Naming your project</title>
+
+   <para>
+    While there are plenty of projects that fail with descriptive
+    names and plenty that succeed without them, I think naming your
+    project is worth giving a bit of thought. Leslie Orchard tackles
+    this issue in an <ulink
+    url="http://www.advogato.org/article/67.html">Advogato
+    article</ulink>. His article is short and definately worth looking
+    over quickly.
+   </para>
+
+   <para>
+    The synopsis is that Orchard recommends you pick a name where,
+    after hearing the name, many users or developers will both:
+   </para>
+
+   <para>
+    <itemizedlist>
+     <listitem>
+      <para>Know what the project does.</para>
+     </listitem>
+     <listitem>
+      <para>Remember it tomorrow.</para>
+     </listitem>
+    </itemizedlist>
+   </para>
+
+   <para>
+    Humorously, Orchard's project, <quote>Iajitsu,</quote> does
+    neither. It is probably unrelated that development has effectively
+    frozen since the article was written.
+   </para>
+
+   <para>
+    He makes a good point though. There are companies whose only job
+    is to make names for pieces of software. They make
+    <emphasis>ridiculous</emphasis> amount of money doing it and are
+    supposedly worth it. While you probably can't aford a company like
+    this, you can afford to learn from their existance and think a
+    little bit about the name you are giving your project because it
+    <emphasis>does</emphasis> matter.
+   </para>
+
+   <para>
+    If there is a name you really want but it doesn't fit Orchard's
+    criteria, you can still go ahead. I thought <quote>gnubile</quote>
+    was one of the best I'd heard for a free software project ever and
+    I still talk about it long after I've stopped using the
+    program. However, if you can be flexible on the subject, listen to
+    Orchard's advice. It might help you.
+   </para>
+  </sect2>
+

 <!-- Section2: licensing-->
 
   <sect2 id="licensing">
    <title>Licensing your Software</title>
    
    <para>
 <!-- Section2: licensing-->
 
   <sect2 id="licensing">
    <title>Licensing your Software</title>
    
    <para>

-    On one level, the difference between a piece of free software and
-    a piece of propriety software is the license. A license helps both
-    you as the developer by protecting your legal rights to your
-    software and helps demonstrate to those who wish to help you or
-    your project that they are encouraged to join.
+    On one (somewhat simplistic) level, the difference between a piece
+    of free software and a piece of propriety software is the
+    license. A license helps you as the developer by protecting your
+    legal rights to have your software distributed under your terms
+    and helps demonstrate to those who wish to help you or your
+    project that they are encouraged to join.

    </para>
    
    <sect3 id="chooselicense">
    </para>
    
    <sect3 id="chooselicense">


@@ -590,29 +661,39 @@
     <para>
      Any discussion of licenses is also sure to generate at least a
      small flame war as there are strong feelings that some free
     <para>
      Any discussion of licenses is also sure to generate at least a
      small flame war as there are strong feelings that some free

-     software licenses are better than other free software
-     licenses. This discussion also brings up the question of
-     <quote>Open Source Software</quote> and the debate around
-     <quote>Open Source Software</quote> and <quote>Free
-     Software</quote>. However, because I've written the Free Software
-     Development HOWTO and not the Open Source Development HOWTO, my
-     own allegiances in this argument are out in the open.
+     software licenses are better than others. This discussion also
+     brings up the question of <quote>Open Source Software</quote> and
+     the debate over the terms <quote>Open Source Software</quote> and
+     <quote>Free Software</quote>. However, because I've written the
+     Free Software Project Management HOWTO and not the Open Source
+     Software Project Management HOWTO, my own allegiances in this
+     argument are in the open.

     </para>
 
     <para>
     </para>
 
     <para>

-     In attempting to reach a middle ground, I recommend picking any
+     In attempting to reach a middle ground through diplomacy without
+     sacrificing my own philosophy, I will recommend picking any

      license that conforms to the <ulink
      url="http://www.debian.org/social_contract">Debian Free Software
      license that conforms to the <ulink
      url="http://www.debian.org/social_contract">Debian Free Software

-     Guidelines</ulink>. Examples of these licenses are the
-     <acronym>GPL</acronym>, the <acronym>BSD</acronym>, and the
-     Artistic License. Conforming to the definition of Free Software
-     offered by Richard Stallman in <ulink
-     url="http://www.gnu.org/philosophy/free-sw.html">The Free
-     Software Definition</ulink>, any of these licenses will
-     uphold,<quote> users' freedom to run, copy, distribute, study,
-     change and improve the software.</quote> There are other licenses
-     as well but sticking with a more common license will offer the
-     advantage of immediate recognition and understanding.
+     Guidelines</ulink>. Originally compiled by the Debian project
+     under Bruce Perens, the <acronym>DFSG</acronym> forms the first
+     version of the <ulink
+     url="http://www.opensource.org/docs/definition_plain.html">Open
+     Source Definition.</ulink> Examples of free licenses given by the
+     <acronym>DFSG</acronym> are the <acronym>GPL</acronym>, the
+     <acronym>BSD</acronym>, and the Artistic License.
+    </para>
+
+    <para>
+     Conforming to the definition of free software offered by Richard
+     Stallman in <ulink
+     url="http://www.gnu.org/philosophy/free-sw.html"><quote>The Free
+     Software Definition</quote></ulink>, any of these licenses will
+     uphold, <quote>users' freedom to run, copy, distribute, study,
+     change and improve the software.</quote> There are plenty of
+     other licenses that also conform to the <acronym>DFSG</acronym>
+     but sticking with a more well-known license will offer the advantage
+     of immediate recognition and understanding.

     </para>
 
     <para>
     </para>
 
     <para>


@@ -627,17 +708,17 @@
      <acronym>GPL</acronym>. Created and protected by the Free
      Software Foundation and the GNU Project, the
      <acronym>GPL</acronym> is the license for the Linux kernel,
      <acronym>GPL</acronym>. Created and protected by the Free
      Software Foundation and the GNU Project, the
      <acronym>GPL</acronym> is the license for the Linux kernel,

-     GNOME, Emacs, and the majority of Linux software. Its an easy
-     choice but I believe it is a good one. <emphasis>However, there
-     is a viral aspect to the <acronym>GPL</acronym>that prevents the
-     mixture of <acronym>GPL</acronym>'ed code with
-     non-<acronym>GPL</acronym>'ed code. To many people (myself
-     included), this is a benefit, but to some, it is a major
-     drawback.</emphasis>
+     GNOME, Emacs, and the vast majority of GNU/Linux software. It's
+     the obvious choice but I also believe it is a good one. Any BSD
+     fanatic will urge you to remember that there is a viral aspect to
+     the <acronym>GPL</acronym> that prevents the mixture of
+     <acronym>GPL</acronym>'ed code with non-<acronym>GPL</acronym>'ed
+     code. To many people (myself included), this is a benefit, but to
+     some, it is a major drawback.

     </para>
 
     <para>
     </para>
 
     <para>

-     The three major license can be found at the following locations:
+     The three major licenses can be found at the following locations:

     </para>
 
     <para>
     </para>
 
     <para>


@@ -659,9 +740,9 @@
     </para>
 
     <para>
     </para>
 
     <para>

-     <emphasis>In all cases, please read through any license before
-     your release your software. As the developer, you can't afford
-     any license surprises.</emphasis>
+     <emphasis>In any case, please read through any license before
+     your release your software under it. As the primary developer,
+     you can't afford any license surprises.</emphasis>

     </para>
    </sect3>
 
     </para>
    </sect3>
 


@@ -671,25 +752,25 @@
     <para>
      The text of the <acronym>GPL</acronym> offers <ulink
      url="http://www.gnu.org/copyleft/gpl.html#SEC4">a good
     <para>
      The text of the <acronym>GPL</acronym> offers <ulink
      url="http://www.gnu.org/copyleft/gpl.html#SEC4">a good

-     description</ulink> of mechanics of applying a license to a piece
-     of software. A checklist for applying a license would include:
+     description of the mechanics of applying a license</ulink> to a
+     piece of software. My quick checklist for applying a license
+     includes:

     </para>
 
     <para>
     </para>
 
     <para>

-    <orderedlist>
+     <itemizedlist>
+     

       <listitem>
       <listitem>

-

        <para>If at all possible, attach and distribute a full copy of
        <para>If at all possible, attach and distribute a full copy of

-       the license with the source and binary in a separate
+       the license with the source and binary by including a separate

        file.</para>
        file.</para>

-

       </listitem>
       </listitem>

-      <listitem>

 
 

+      <listitem>

        <para>At the top of each source file in your program, attach a
        <para>At the top of each source file in your program, attach a

-       notice of copyright and information on where the full license
-       can be found. The <acronym>GPL</acronym> recommends that each
-       file begin with:</para>
+       notice of copyright and include information on where the full
+       license can be found. The <acronym>GPL</acronym> recommends
+       that each file begin with:</para>

 
        <screen>
 <emphasis>one line to give the program's name and an idea of what it does.</emphasis>
 
        <screen>
 <emphasis>one line to give the program's name and an idea of what it does.</emphasis>


@@ -712,19 +793,18 @@ Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
 
        <para>
         The <acronym>GPL</acronym> goes on to recommend attaching
 
        <para>
         The <acronym>GPL</acronym> goes on to recommend attaching

-        information on contacting you (the author) via email or
-        physical mail.
+        information on methods for contacting you (the author) via
+        email or physical mail.

       </para>
       </para>

-

       </listitem>
       </listitem>

-      <listitem>

 
 

+      <listitem>

        <para>
         The <acronym>GPL</acronym> continues and suggests that if your
        <para>
         The <acronym>GPL</acronym> continues and suggests that if your

-        program runs in an interactive mode, you should have the
-        program output a notice each time it enters interactive mode
-        that includes a message like this one that points to more
-        information about the programs licensing:
+        program runs in an interactive mode, you should write the
+        program to output a notice each time it enters interactive
+        mode that includes a message like this one that points to full
+        information about the programs license:

        </para>
 
        <screen>
        </para>
 
        <screen>


@@ -734,34 +814,37 @@ type `show w'.  This is free software, and you are welcome
 to redistribute it under certain conditions; type `show c' 
 for details.
        </screen>
 to redistribute it under certain conditions; type `show c' 
 for details.
        </screen>

-

       </listitem>
       </listitem>

+

       <listitem>
        <para>Finally, it might be helpful to include a
       <listitem>
        <para>Finally, it might be helpful to include a

-       <quote>copyright disclaimer</quote> with the program from an
-       employer or a school if you work as a programmer or if it seems
-       like your employer or school might be able to make an argument
-       for ownership of your code.</para>
+       <quote>copyright disclaimer</quote> from an employer or a
+       school if you work as a programmer or if it seems like your
+       employer or school might be able to make an argument for
+       ownership of your code later on. These aren't often needed but
+       there are plenty of free software developers who have gotten
+       into trouble and wish they'd asked for one.</para>

       </listitem>
 
       </listitem>
 

-     </orderedlist>
-     </para>    
+     </itemizedlist>
+    </para>    

    </sect3>
 
    <sect3 id="licensewarning">
     <title>Final license warning</title>
 
     <para>
    </sect3>
 
    <sect3 id="licensewarning">
     <title>Final license warning</title>
 
     <para>

-     Please, please, please, place your software under some
-     license. It may not seem important, and to you, it may not be,
-     but licenses are important. For a piece of software to be
-     included in the Debian GNU/Linux distribution, it must have a
-     license that fits the <ulink
-     url="http://www.debian.org/social_contract">Debian Free Software
-     Guidelines</ulink>. If you have no license, your program can be
-     distributed in part of Debian until you re-release it under a free
-     license. Please save yourself and others trouble by releasing the
-     first version of your software with a clear license.
+     Please, please, please, place your software under
+     <emphasis>some</emphasis> license. It may not seem important, and
+     to you it may not be, but licenses <emphasis>are</emphasis>
+     important. For a piece of software to be included in the Debian
+     GNU/Linux distribution, it must have a license that fits the
+     <ulink url="http://www.debian.org/social_contract">Debian Free
+     Software Guidelines</ulink>. If your software has no license, it
+     can not be distributed as a package in Debian until you
+     re-release it under a free license. Please save yourself and
+     others trouble by releasing the first version of your software
+     with a clear license.

     </para>
 
    </sect3>
     </para>
 
    </sect3>


@@ -772,40 +855,69 @@ for details.
 
   <sect2 id="chooseversioning">
    <title>Choosing a Method of Version Numbering</title>
 
   <sect2 id="chooseversioning">
    <title>Choosing a Method of Version Numbering</title>

+

    <para>
    <para>

-    <emphasis>The most important thing about a system of numbering is
-    that there is one.</emphasis> It may seem pedantic to emphasize
-    this point but you'd be surprised at the number of scripts and
-    small programs that pop up without any version number. 
+    <emphasis>The most important thing about a system of version
+    numbering is that there is one.</emphasis> It may seem pedantic to
+    emphasize this point but you'd be surprised at the number of
+    scripts and small programs that pop up without any version number
+    at all.

    </para>
 
    <para>
     <emphasis>The second most important thing about a system of
     numbering is that the numbers always go up.</emphasis> Automatic
    </para>
 
    <para>
     <emphasis>The second most important thing about a system of
     numbering is that the numbers always go up.</emphasis> Automatic

-    versioning systems and people's sense of order in the universe
-    will fall apart if version numbers don't rise. It doesn't
+    version tracking systems and people's sense of order in the
+    universe will fall apart if version numbers don't rise. It doesn't

     <emphasis>really</emphasis> matter if 2.1 is a big jump and
     2.0.005 is a small jump but it does matter that 2.1 is more recent
     than 2.0.005.
    </para>
 
    <para>
     <emphasis>really</emphasis> matter if 2.1 is a big jump and
     2.0.005 is a small jump but it does matter that 2.1 is more recent
     than 2.0.005.
    </para>
 
    <para>

-    Follow these two rules and you will not go wrong. Still there are
-    several versioning system that are well known, useful, and that
-    might be worth looking into before you release your first version.
+    Follow these two simple rules and you will not go (too)
+    wrong. Beyond this, the most common technique seems to be the
+    <quote>major level,</quote> <quote>minor level,</quote>
+    <quote>patch level</quote> version numbering scheme. Whether you
+    are familiar with the name or not, you interact with it all the
+    time. The first number is the major number and it signifies major
+    changes or rewrites. The second number is the minor number and it
+    represents added or tweaked functionality on top of a largely
+    coherant structure. The third number is the patch number and it
+    usually will only refer to releases fixing bugs.
+   </para>
+
+   <para>
+    The widespread use of this scheme is why I know the nature and
+    relative degree in the differences between a 2.4.12 release of the
+    Linux kernel and a 2.4.11, 2.2.12, and 1.2.12 without knowning
+    anything about any of the releases.
+   </para>
+
+   <para>
+    You can bend or break these rules, and people do. But beware, if
+    you choose to, someone will get annoyed, assume you don't know,
+    and try and educate you, probably not nicely. I always follow this
+    method and I implore you to do so as well.
+   </para>
+   
+   <para>
+    There are several version numbering systems that are well known,
+    useful, and that might be worth looking into before you release
+    your first version.

    </para>
 
    <variablelist>
     <varlistentry>
      <term>Linux kernel version numbering:</term>
      <listitem>
    </para>
 
    <variablelist>
     <varlistentry>
      <term>Linux kernel version numbering:</term>
      <listitem>

-      <para>The Linux kernel uses a versioning system where the any
-      minor odd minor version number refers to an development or
-      testing release and any even minor version number refers to a
-      stable version. Under this system, 2.1 and 2.3 kernels were and
-      always will be development and testing kernels and 2.0, 2.2. and
-      2.4 kernels are all production code with a higher degree of
-      stability.
+      <para>The Linux kernel uses a versioning system where any odd
+      minor version number refers to an development or testing release
+      and any even minor version number refers to a stable
+      version. Think about it for a second. Under this system, 2.1 and
+      2.3 kernels were and always will be development or testing
+      kernels and 2.0, 2.2. and 2.4 kernels are all production code
+      with a higher degree of stability and more testing.

      </para>
 
       <para>
      </para>
 
       <para>


@@ -814,64 +926,68 @@ for details.
        released at a time, my experience with several free software
        projects and with the Debian project has taught me that use of
        Linux's version numbering system is worth taking into
        released at a time, my experience with several free software
        projects and with the Debian project has taught me that use of
        Linux's version numbering system is worth taking into

-       consideration. In Debian, all minor versions are stable
-       distributions (2.0, 2.1, etc). However, many people assume that
-       2.1 is an unstable or development version and continue to use
-       an older version until they get so frustrated with the lack of
-       development and progress that they complain. If you never
-       release an odd minor version but only release even ones, nobody
-       is hurt, and less people are confused.
+       consideration. In Debian, <emphasis>all</emphasis> minor
+       versions are stable distributions (2.0, 2.1, etc). However,
+       many people assume that 2.1 is an unstable or development
+       version and continue to use an older version until they get so
+       frustrated with the lack of development progress that they
+       complain and figure the system out. If you never release an odd
+       minor version but only release even ones, nobody is hurt, and
+       less people are confused. It's an idea worth taking into
+       consideration.

       </para>
       </para>

-

      </listitem>
     </varlistentry>
      </listitem>
     </varlistentry>

+

     <varlistentry>
      <term>Wine version numbering:</term>
      <listitem>
       <para>Because of the unusual nature of wine's development where
     <varlistentry>
      <term>Wine version numbering:</term>
      <listitem>
       <para>Because of the unusual nature of wine's development where

-      it constantly improving but not working towards any immediately
-      achievable goal, wine is released every three weeks. Wine does
-      this by versioning their releases in Year Month Day format where
-      each release might be labeled <quote>wine-XXXXXXXX</quote> where
-      the version from January 04, 2000 would be
-      <quote>wine-20000104</quote>. For certain projects, Year Month
-      Day format can make a lot of sense.
+      the not-emulator is constantly improving but not working towards
+      any immediately achievable goal, wine is released every three
+      weeks. Wine does this by labeling their releases in <quote>Year
+      Month Day</quote> format where each release might be labeled
+      <quote>wine-XXXXXXXX</quote> where the version from January 04,
+      2000 would be <quote>wine-20000104</quote>. For certain
+      projects, <quote>Year Month Day</quote> format can make a lot of
+      sense.

       </para>
       </para>

-

      </listitem>
     </varlistentry>
      </listitem>
     </varlistentry>

+

     <varlistentry>
      <term>Mozilla milestones:</term>
      <listitem>
       <para>When one considers Netscape 6 and vendor versions, the
       mozilla's project development structure is one of the most
     <varlistentry>
      <term>Mozilla milestones:</term>
      <listitem>
       <para>When one considers Netscape 6 and vendor versions, the
       mozilla's project development structure is one of the most

-      complex free software model available. Their version numbering
-      has reflected the unique situation in which it is
+      complex free software models available. The project's version
+      numbering has reflected the unique situation in which it is

       developed.
       </para>
 
       <para>
       developed.
       </para>
 
       <para>

-       Mozilla's development structure has historically been made up
-       of milestones. From the beginning of the mozilla project, the
-       goals of the project in the order and degree to which they were
-       to be achieved were charted out on a series of <ulink
-       url="http://www.mozilla.org/roadmap.html">road
-       maps</ulink>. Major points and achievements along this road-maps
-       were marked as milestones. Therefore, mozilla was built and
-       distributed nightly as "nightly builds" but on a day when the
-       goals of a milestone on the road-map had been reached, that
-       particular build was marked as a milestone release.
+       Mozilla's version numbering structure has historically been
+       made up of milestones. From the beginning of the mozilla
+       project, the goals of the project in the order and degree to
+       which they were to be achieved were charted out on a series of
+       <ulink url="http://www.mozilla.org/roadmap.html">road
+       maps</ulink>. Major points and achievements along these
+       road-maps were marked as milestones. Therefore, although
+       mozilla was built and distributed nightly as <quote>nightly
+       builds,</quote> on a day when the goals of a milestone on the
+       road-map had been reached, that particular build was marked as
+       a <quote>milestone release.</quote>

       </para>
 
       <para>
        While I haven't seen this method employed in any other projects
        to date, I like the idea and think that it might have value in
       </para>
 
       <para>
        While I haven't seen this method employed in any other projects
        to date, I like the idea and think that it might have value in

-       any testing or development branch of a large free application
-       under heavy development.
+       any testing or development branch of a large application under
+       heavy development.

       </para>
       </para>

-

      </listitem>
     </varlistentry>
      </listitem>
     </varlistentry>

+

    </variablelist>
   </sect2>
 
    </variablelist>
   </sect2>
 


@@ -882,29 +998,29 @@ for details.
 
    <para>
     A huge number of otherwise fantastic free software applications
 
    <para>
     A huge number of otherwise fantastic free software applications

-    have withered because their author was the only person who knew
-    how to use them well. Even if your program is written primarily
-    for a techno-savvy group of users, documentation is helpful and
-    necessary for the survival of your project. You will learn later
-    in <xref linkend="releasing"> that you must always release
-    something that is usable. <emphasis>A piece of software without
-    documentation is not usable.</emphasis>
+    have withered and died because their author was the only person
+    who knew how to use them fully. Even if your program is written
+    primarily for a techno-savvy group of users, documentation is
+    helpful and even necessary for the survival of your project. You
+    will learn later in <xref linkend="releasing"> that you should
+    always release something that is usable. <emphasis>A piece of
+    software without documentation is not usable.</emphasis>

    </para>
 
    <para>
    </para>
 
    <para>

-    There are lots of ways to document your project and lots of
-    different people to document for. The idea of documentation the
-    code itself to help facilitate development by a large community is
-    vital but is outside the scope of this HOWTO. This being the case,
-    this section deals mostly useful tactics for user-directed
-    documentation.
+    There are lots of different people you should document for and
+    there are lots of ways to document your project. <emphasis>The
+    importance of documentation in source code to help facilitate
+    development by a large community is vital</emphasis> but it falls
+    outside the scope of this HOWTO. This being the case, this section
+    deals with useful tactics for user-directed documentation.

    </para>
 
    <para>
     A combination of tradition and necessity has resulted in a
    </para>
 
    <para>
     A combination of tradition and necessity has resulted in a

-    semi-regular system method of documentation in most free software
+    semi-regular system of documentation in most free software

     projects that is worth following. Both users and developers expect
     projects that is worth following. Both users and developers expect

-    to be able to get documentation in several ways and its essential
+    to be able to get documentation in several ways and it's essential

     that you provide the information they are seeking in a form they
     can read if your project is ever going to get off the
     ground. People have come to expect:
     that you provide the information they are seeking in a form they
     can read if your project is ever going to get off the
     ground. People have come to expect:


@@ -914,17 +1030,17 @@ for details.
     <title>Man pages</title> 
 
     <para>Your users will want to be able to type <quote>man
     <title>Man pages</title> 
 
     <para>Your users will want to be able to type <quote>man

-    foo</quote> end up with a nicely formatted man page highlighting
-    the basic use of their application. Make sure that before you
-    release your program, you've planned for this.
+    yourprojectname</quote> end up with a nicely formatted man page
+    highlighting the basic use of your application. Make sure that
+    before you release your program, you've planned for this.

     </para>
 
     <para>
      Man pages are not difficult to write. There is excellent
     </para>
 
     <para>
      Man pages are not difficult to write. There is excellent

-     documentation on the man page process available through the
-     <quote>The Linux Man-Page-HOWTO</quote> available through the
-     Linux Documentation project <acronym>(LDP)</acronym> written by
-     Jens Schweikhardt. It is available <ulink
+     documentation on the man page writing process available through
+     the <quote>The Linux Man-Page-HOWTO</quote> which is available
+     through the Linux Documentation project <acronym>(LDP)</acronym>
+     and is written by Jens Schweikhardt. It is available <ulink

      url="http://www.schweikhardt.net/man_page_howto.html">from
      Schweikhardt's site</ulink> or <ulink
      url="http://www.linuxdoc.org/HOWTO/mini/Man-Page.html">from the
      url="http://www.schweikhardt.net/man_page_howto.html">from
      Schweikhardt's site</ulink> or <ulink
      url="http://www.linuxdoc.org/HOWTO/mini/Man-Page.html">from the


@@ -932,11 +1048,11 @@ for details.
     </para>
 
     <para>
     </para>
 
     <para>

-     It is also possible to write man pages using DocBook SGML and
-     convert them into man pages. Because man pages are so simple, I
-     have not been able to follow this up but would love help from
-     anyone who can give me more information on how exactly this is
-     done.
+     It is also possible to write man pages using DocBook
+     SGML. Because man pages are so simple and the DocBook method
+     relatively new, I have not been able to follow this up but would
+     love help from anyone who can give me more information on how
+     exactly how this is done.

     </para>
    </sect3>
 
     </para>
    </sect3>
 


@@ -944,12 +1060,13 @@ for details.
     <title>Command line accessible documentation</title>
 
     <para>
     <title>Command line accessible documentation</title>
 
     <para>

-     Most users will expect the most basic amount of documentation to
-     be easily available from the command line. For few programs should
-     then documentation extend for more than one screen (24 or 25
-     lines) but it should cover the basic usage, a brief (one or two
-     sentence) description of the program, a list of commands, all the
-     major options, and a pointer to more in-depth documentation for
+     Most users will expect some basic amount of documentation to be
+     easily available from the command line. For few programs should
+     this type of documentation extend for more than one screen (24 or
+     25 lines) but it should cover the basic usage, a brief (one or
+     two sentence) description of the program, a list of the commands
+     with explanations, as well as all the major options (also with
+     explanations), plus a pointer to more in-depth documentation for

      those who need it. The command line documentation for Debian's
      apt-get serves as an excellent example and a useful model:
     </para>
      those who need it. The command line documentation for Debian's
      apt-get serves as an excellent example and a useful model:
     </para>


@@ -993,38 +1110,39 @@ pages for more information and options.
     </screen>
 
     <para>
     </screen>
 
     <para>

-     It has become a GNU convention to make this information
+     It has become a GNU convention to make this type of information

      accessible with the <quote>-h</quote> and the
      <quote>--help</quote> options. Most GNU/Linux users will expect
      to be able to retrieve basic documentation these ways so if you
      accessible with the <quote>-h</quote> and the
      <quote>--help</quote> options. Most GNU/Linux users will expect
      to be able to retrieve basic documentation these ways so if you

-     choose to use different method, be prepared for the flames and
-     for the fallout that may result.
+     choose to use different methods, be prepared for the flames and
+     fallout that may result.

     </para>
    </sect3>
     </para>
    </sect3>

+

    <sect3>
     <title>Files users will expect</title>
     <para>
    <sect3>
     <title>Files users will expect</title>
     <para>

-     In addition to man pages and online help, there are certain files
-     where people will look to documentation, especially in any
+     In addition to man pages and command-line help, there are certain
+     files where people will look for documentation, especially in any

      package containing source code. In a source distribution, most of
      package containing source code. In a source distribution, most of

-     these files can be stored in a the root directory of the source
+     these files can be stored in the root directory of the source

      distribution or in a subdirectory of the root called
      distribution or in a subdirectory of the root called

-     <quote>doc</quote> or <quote>Documentation</quote>. These files include:
+     <quote>doc</quote> or <quote>Documentation.</quote> Common files
+     in these places include:

     </para>
     </para>

+

     <para>
      <variablelist>
       <varlistentry>
        <term>README or Readme</term>
 
        <listitem>
     <para>
      <variablelist>
       <varlistentry>
        <term>README or Readme</term>
 
        <listitem>

-       <para>
-         A document containing all the basic installation,
-         compilation, and even basic use instructions that make up
-         the bare minimum information needed to get the program up and
-         running. A README is not your chance to be verbose but needs
-         to be concise and effective. An ideal README is at least 30
-         lines long and more no more than 250.
-        </para>
+       <para>A document containing all the basic installation,
+       compilation, and even basic use instructions that make up the
+       bare minimum information needed to get the program up and
+       running. A README is not your chance to be verbose but should
+       be concise and effective. An ideal README is at least 30 lines
+       long and more no more than 250.</para>

        </listitem>
 
       </varlistentry>
        </listitem>
 
       </varlistentry>


@@ -1032,38 +1150,47 @@ pages for more information and options.
        <term>INSTALL or Install</term>
 
        <listitem>
        <term>INSTALL or Install</term>
 
        <listitem>

-       <para>
-         The INSTALL file should be much shorter than the INSTALL file
-         and should quickly and concisely describe how to build and
-         install the program. Usually an install simply instructs the
-         user to run ./configure; make; make install and touches on
-         any unusual options that may be necessary. More advanced
-         users can usually avoid them but it's good practice to at
-         least glance at the file to understand what can be
-         expected. For most relatively standard install procedures and
-         for most programs, INSTALL files are as short as possible are
-         rarely over 100 lines.
-        </para>
+       <para>The INSTALL file should be much shorter than the README
+       file and should quickly and concisely describe how to build
+       and install the program. Usually an INSTALL file simply
+       instructs the user to run <quote>./configure; make; make
+       install</quote> and touches on any unusual options or actions
+       that may be necessary. For most relatively standard install
+       procedures and for most programs, INSTALL files are as short
+       as possible and are rarely over 100 lines.</para>
+       </listitem>
+
+      </varlistentry>
+      <varlistentry>
+       <term>CHANGELOG, Changelog, ChangeLog, or changelog</term>
+
+       <listitem>
+       <para>A CHANGELOG is a simple file that every well-managed
+       free software project should include. A CHANGELOG is simple
+       the file that, as its name implies, logs or documents the
+       changes you make to your program. The most simple way to
+       maintain a CHANGELOG is to simply keep a file with the source
+       code for your program and add a section to the top of the
+       CHANGELOG with each release describing what has been changed,
+       fixed, or added to the program. It's a good idea to post the
+       CHANGELOG onto the website as well because it can help people
+       decide whether they want or need to upgrade to a newer version
+       or wait for a more significant improvement.</para>

        </listitem>
 
       </varlistentry>
       <varlistentry>
        </listitem>
 
       </varlistentry>
       <varlistentry>

-       <term>Changelog, ChangeLog, CHANGELOG, or changelog</term>
+       <term>NEWS</term>

 
        <listitem>
 
        <listitem>

-       <para>
-         A changelog is a simple file that every well-managed free
-         software project should include. A changelog is simple the
-         file that, as its name would imply, logs or documents the
-         changes to a program. The most simple way to do a changelog
-         is to simply keep a file with the source code for your
-         program and add a section to the top of the changelog with
-         each release describing what has been, changed, fixed, or
-         added to the program. It's a good idea to post the changelog
-         onto the website as well because it can help people decide
-         whether they want or need to upgrade to a newer version or
-         wait for a more significant upgrade.
-        </para>
+       <para>A NEWS file and a ChangeLog are similar. Unlike a
+       CHANGELOG, a NEWS file is not typically updated with new
+       versions. Whenever new features are added, the developer
+       responisble will make a note in the NEWS file. NEWS files
+       should not have to be changed before a release (they should be
+       kept up to date all along) but it's usually a good idea to
+       check first anyway because often developers just forget to
+       keep them as current as they should.</para>

        </listitem>
 
       </varlistentry>
        </listitem>
 
       </varlistentry>


@@ -1071,17 +1198,15 @@ pages for more information and options.
        <term><acronym>FAQ</acronym></term>
 
        <listitem>
        <term><acronym>FAQ</acronym></term>
 
        <listitem>

-       <para>
-         For those of you that don't already
-         know. <acronym>FAQ</acronym> stands for Frequently Asked
-         Questions and the file is a collection of exactly that. FAQs
-         are not difficult to make. Simply make a policy that if you
-         are asked a question or see a question on a mailing list two
-         or more times, add it the question (and its answer) to your
-         FAQs. FAQs are more optional than the files listed above but
-         they can save your time, increase usability, and decrease
-         headaches on all sides.
-        </para>
+       <para>For those of you that don't already know,
+       <acronym>FAQ</acronym> stands for Frequently Asked Questions
+       and a FAQ is a collection of exactly that. FAQs are not
+       difficult to make. Simply make a policy that if you are asked
+       a question or see a question on a mailing list two or more
+       times, add the question (and its answer) to your FAQ. FAQs are
+       more optional than the files listed above but they can save
+       your time, increase usability, and decrease headaches on all
+       sides.</para>

        </listitem>
 
       </varlistentry>
        </listitem>
 
       </varlistentry>


@@ -1090,33 +1215,23 @@ pages for more information and options.
    </sect3>
 
    <sect3>
    </sect3>
 
    <sect3>

-    <title>Website</title>
+    <title>Website</title> 

     <para>
     <para>

-     It's only a sort of an issue of documentation but a good website
+     It's only indirectly an issue of documentation but a good website

      is quickly becoming an essential part of any free software
      is quickly becoming an essential part of any free software

-     project. Your website should provide access to documentation (in
-     <acronym>HTML</acronym> if possible). It should also include a
-     section for news and events around your program and a section
+     project. Your website should provide access to your documentation
+     (in <acronym>HTML</acronym> if possible). It should also include
+     a section for news and events around your program and a section

      that details the process of getting involved with development or
      that details the process of getting involved with development or

-     testing and creates an open invitation. It should also supply
-     links to any mailing lists, similar websites, and directly to all
-     the available ways of downloading your software.
+     testing and make an open invitation. It should also supply links
+     to any mailing lists, similar websites, and provide a direct link
+     to all the available ways of downloading your software.

     </para>
    </sect3>
 
    <sect3>
     <title>Other documentation hints</title>
 
     </para>
    </sect3>
 
    <sect3>
     <title>Other documentation hints</title>
 

-    <para>
-     It doesn't hurt to distribute any documentation for your program
-     from your website or anywhere else (FAQs etc) with the
-     program. Make a FAQ by cutting and posting common questions and
-     answers from a mailing list or your own email. Then, don't
-     hesitate through this in the programs tarball. If people don't
-     need it, they will delete it. I can repeat it over and over:
-     <emphasis>Too much documentation is not a sin.</emphasis>
-    </para>
-

     <para>
      All your documentation should be in plaintext, or, in cases where
      it is on your website primarily, in HTML. Everyone can cat a
     <para>
      All your documentation should be in plaintext, or, in cases where
      it is on your website primarily, in HTML. Everyone can cat a


@@ -1126,6 +1241,14 @@ pages for more information and options.
      this information must also be available in plaintext or HTML or
      people will be very angry at you.</emphasis>
     </para>
      this information must also be available in plaintext or HTML or
      people will be very angry at you.</emphasis>
     </para>

+
+    <para>
+     It doesn't hurt to distribute any documentation for your program
+     from your website (FAQs etc) with your program. Don't hesitate to
+     throw any of this in the program's tarball. If people don't need
+     it, they will delete it. I can repeat it over and over:
+     <emphasis>Too much documentation is not a sin.</emphasis>
+    </para>

    </sect3>
   </sect2>
 
    </sect3>
   </sect2>
 


@@ -1136,9 +1259,10 @@ pages for more information and options.
    <para>
     Many of the remaining issues surrounding the creation of a new
     free software program fall under what most people describe as
    <para>
     Many of the remaining issues surrounding the creation of a new
     free software program fall under what most people describe as

-    common sense actions. Still, they are worth noting briefly in
-    hopes that they may remind a developer of something they may have
-    forgotten.
+    common sense issues. Its often said that software engineering is
+    90 percent common sense combined with 10 percent specialized
+    knowledge. Still, they are worth noting briefly in hopes that they
+    may remind a developer of something they may have forgotten.

    </para>
 
    <sect3>
    </para>
 
    <sect3>


@@ -1151,30 +1275,65 @@ pages for more information and options.
      source code is always available in tar'ed and gzip'ed format
      (.tar.gz). UNIX compress (.Z) has gone out of style and
      usefulness and faster computers have brought bzip2 (.bz2) into
      source code is always available in tar'ed and gzip'ed format
      (.tar.gz). UNIX compress (.Z) has gone out of style and
      usefulness and faster computers have brought bzip2 (.bz2) into

-     the spot-lit as a more effective compression medium. I now make
-     all my releases available in both gzip'ed and bzip2'ed formats.
+     the spot-light as a more effective compression medium. I now make
+     all my releases available in both gzip'ed and bzip2'ed tarballs.

     </para>
 
     <para>
     </para>
 
     <para>

-     Binary packages are largely distribution specific. You can build
-     binary packages against a current version of a major
+     Binary packages should always be distribution specific. If you
+     can build binary packages against a current version of a major

      distribution, you will only make your users happy. Try to foster
      distribution, you will only make your users happy. Try to foster

-     relationships with users or developers of large distribution to
-     develop a system for consistent binary packages. It's often a
-     good idea to provide RedHat <acronym>RPM</acronym>'s (.rpm),
-     Debian deb's (.deb) and source <acronym>RPM</acronym>'s
-     <acronym>SRPM</acronym>'s. Binary packages can also be compiled
-     against a specified system with specified libraries and
-     distributed in tar.gz format as well. <emphasis>Remember: While
-     these binaries packages are nice, getting the source packaged and
-     released should always be your priority. Other can and will do
+     relationships with users or developers of large distributions to
+     develop a system for the consistent creation of binary
+     packages. It's often a good idea to provide RedHat
+     <acronym>RPM</acronym>'s (.rpm), Debian deb's (.deb) and source
+     <acronym>RPM</acronym>'s <acronym>SRPM</acronym>'s if
+     possible. Remember: <emphasis>While these binaries packages are
+     nice, getting the source packaged and released should always be
+     your priority. Your users or fellow developers can and will do

      the the binary packages for you.</emphasis>
     </para>
    </sect3>
 
      the the binary packages for you.</emphasis>
     </para>
    </sect3>
 

+   <sect3>
+    <title>Version control systems</title>
+
+    <para>
+     A version control system can make a lot of these problems of
+     packaging (and a lot of other problems mentioned in this HOWTO)
+     less problematic. If you are using *NIX, CVS is your best bet. I
+     recommend Karl Fogel's book on the subject (and the <ulink
+     url="http://cvsbook.red-bean.com/">posted HTML version</ulink>)
+     wholeheartedly.
+    </para>
+
+    <para>
+     CVS or not, you should probably invest some time into learning
+     about a version control system because it provides an automated
+     way of solving many of the problems described by this HOWTO.  I
+     am not aware of any free version control systems for Windows or
+     MacOS but I know that CVS clients exist for both
+     platforms. Websites like <ulink
+     url="http://sourceforge.net">SourceForge</ulink> do a great job
+     as well with a nice, easy-to-use web interface to CVS.
+    </para>
+
+    <para>
+     I'd love to devote more space in this HOWTO to CVS because I love
+     it (I even use CVS to keep versions straight on this HOWTO!) but
+     I think it falls outside the scope of this document and should have
+     (already has) its own HOWTO.
+    </para>
+
+   </sect3>
+

    <sect3>
     <title>Useful tidbits and presentation hints</title>
 
    <sect3>
     <title>Useful tidbits and presentation hints</title>
 

+    <para>
+     Other useful hints include:
+    </para>
+

     <para>
      <itemizedlist>
 
     <para>
      <itemizedlist>
 


@@ -1182,12 +1341,14 @@ pages for more information and options.
        <para>
         <emphasis>Make sure that your program can always be found in a
         single location.</emphasis> Often this means that you have a
        <para>
         <emphasis>Make sure that your program can always be found in a
         single location.</emphasis> Often this means that you have a

-        single directory accessible via <acronym>FTP</acronym> or
-        <acronym>HTTP</acronym> where the newest version will be
-        quickly recognized. One effective technique is a provide a
-        symlink called <quote>projectname-latest</quote> that is
-        always pointing to the most recent released or development
-        version of your free software project.
+        single directory accessible via <acronym>FTP</acronym> or the
+        web where the newest version can be quickly recognized. One
+        effective technique is a provide a symlink called
+        <quote>yourprojectname-latest</quote> that is always pointing
+        to the most recent released or development version of your
+        free software application. Keep in mind that this location
+        will recieve many requests for downloads around releases so
+        make sure that the server you choose has adequate bandwidth.

        </para>
       </listitem>
 
        </para>
       </listitem>
 


@@ -1196,10 +1357,10 @@ pages for more information and options.
         <emphasis>Make sure that there is a consistent email address
         for bug reports.</emphasis> It's usually a good idea to make
         this something that is NOT your primary email address like
         <emphasis>Make sure that there is a consistent email address
         for bug reports.</emphasis> It's usually a good idea to make
         this something that is NOT your primary email address like

-        projectname@host or projectname-bugs@host. This way if you
-        ever decide to hand over maintainership or if your email
-        address changes, you simply need to change where this email
-        address forwards to. It also will allow for more than one
+        yourprojectname@host or yourprojectname-bugs@host. This way,
+        if you ever decide to hand over maintainership or if your
+        email address changes, you simply need to change where this
+        email address forwards. It also will allow for more than one

         person to deal with the influx of mail that is created if your
         project becomes as huge as you hope it will.
        </para>
         person to deal with the influx of mail that is created if your
         project becomes as huge as you hope it will.
        </para>


@@ -1207,7 +1368,6 @@ pages for more information and options.
 
      </itemizedlist>
     </para>
 
      </itemizedlist>
     </para>

-

    </sect3>
   </sect2>
  </sect1>
    </sect3>
   </sect2>
  </sect1>


@@ -1223,13 +1383,14 @@ pages for more information and options.
   </indexterm>
 
   <para>
   </indexterm>
 
   <para>

-   Once you have gotten the project started, you have gotten over the
+   Once you have gotten your project started, you have overcome the

    most difficult hurdles in the development process of your
    program. Laying a firm foundation is essential, but the development
    most difficult hurdles in the development process of your
    program. Laying a firm foundation is essential, but the development

-   process itself is equally important and provides an equal number of
-   opportunities for failure. In the next two sections, I will and
-   cover running a project by discussing how to maintain a project
-   rough interactions with developers and with users.
+   process itself is equally important and provides just as many
+   opportunities for failure. In the next two sections, I will
+   describe running a project by discussing how to maintain a
+   development effort through interactions with developers and with
+   users.

   </para>
 
   <para>
   </para>
 
   <para>


@@ -1243,16 +1404,16 @@ pages for more information and options.
   </para>
 
   <para>
   </para>
 
   <para>

-   The major difference between free software development and propriety
-   software development is the developer base. As the leader of a free
-   software project, you need to attract and keep developers in a way
-   that leaders of proprietary software projects simply don't have to
-   worry about. <emphasis>As the person leading development of a free
-   software project, you must harness the work of fellow developers by
-   making responsible decisions and by and by choosing not to make
-   decisions responsibly. You have to direct developers without being
-   overbearing or bossy. You need to strive to earn respect and never
-   forget to give it.</emphasis>
+   The major difference between free software development and
+   propriety software development is the developer base. As the leader
+   of a free software project, you need to attract and keep developers
+   in a way that leaders of proprietary software projects simply don't
+   have to worry about. <emphasis>As the person leading development of
+   a free software project, you must harness the work of fellow
+   developers by making responsible decisions and by responsibly
+   choosing not to make decisions. You have to direct developers
+   without being overbearing or bossy. You need to strive to earn
+   respect and never forget to give it out.</emphasis>

   </para>
 
 <!-- Section2: delegation  -->
   </para>
 
 <!-- Section2: delegation  -->


@@ -1262,8 +1423,8 @@ pages for more information and options.
 
    <para>
     By now, you've hypothetically followed me through the early
 
    <para>
     By now, you've hypothetically followed me through the early

-    writing of a piece of software, the creation of a website and
-    system of documentation and and we've gone ahead and (as will be
+    programming of a piece of software, the creation of a website and
+    system of documentation, and we've gone ahead and (as will be

     discussed in <xref linkend="releasing">) released it to the rest
     of the world. Times passes, and if things go well, people become
     interested and want to help. The patches begin flowing in.
     discussed in <xref linkend="releasing">) released it to the rest
     of the world. Times passes, and if things go well, people become
     interested and want to help. The patches begin flowing in.


@@ -1271,45 +1432,64 @@ pages for more information and options.
 
    <para>
     <emphasis>Like the parent of any child who grows up, it's now time
 
    <para>
     <emphasis>Like the parent of any child who grows up, it's now time

-    to wince and smile and do most difficult thing in any parents
+    to wince, smile and do most difficult thing in any parents

     life: It's time to let go.</emphasis>
    </para>
 
    <para>
     Delegation is the political way of describing this process of
     <quote>letting go.</quote> It is the process of handing some of
     life: It's time to let go.</emphasis>
    </para>
 
    <para>
     Delegation is the political way of describing this process of
     <quote>letting go.</quote> It is the process of handing some of

-    the responsibility and power over your project to other responsible
-    and involved developers. It is difficult for anyone who has
-    invested a large deal of time and energy into a project but it
-    essential for the growth of any free software project. One person
-    can only do so much. <emphasis>A free software project is nothing
-    without the involvement of a group of developers. A group of
-    developers can only be maintained through respectful and
-    responsible leadership and delegation.</emphasis>
+    the responsibility and power over your project to other
+    responsible and involved developers. It is difficult for anyone
+    who has invested a large deal of time and energy into a project
+    but it essential for the growth of any free software project. One
+    person can only do so much. A free software project is nothing
+    without the involvement of <emphasis>a group</emphasis> of
+    developers. A group of developers can only be maintained through
+    respectful and responsible leadership and delegation.

    </para>
 
    <para>
     As your project progresses, you will notice people who are putting
     significant amounts of time and effort into your project. These
     will be the people submitting the most patches, posting most on
    </para>
 
    <para>
     As your project progresses, you will notice people who are putting
     significant amounts of time and effort into your project. These
     will be the people submitting the most patches, posting most on

-    the mailing lists, engaging in long email discussions. It is your
-    responsibility to contact these people and to try and shift some of
-    the power and responsibility of your position as the project's
-    maintainer onto them (if they want it). There are several easy
-    ways you can do this:
+    the mailing lists, and engaging in long email discussions. It is
+    your responsibility to contact these people and to try and shift
+    some of the power and responsibility of your position as the
+    project's maintainer onto them (if they want it). There are
+    several easy ways you can do this:
+   </para>
+
+   <para>
+    In a bit of a disclaimer, delegation need not mean rule by
+    comittee. In many cases it does and this has been proven to
+    work. In other cases this has created problems. <ulink
+    url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing
+    Projects the Open Source Way</ulink> argues that <quote>OSS
+    projects do best when one person is the clear leader of a team and
+    makes the big decisions (design changes, release dates, and so
+    on).</quote> I think this often true but would urge developers to
+    consider the ideas that the project leader need not be the
+    project's founder and that these important powers need not all rest
+    with one person but that a release manager may be different than a
+    lead developer. These situations are tricky politically so
+    be careful and make sure it's necessary before you go around
+    empowering people.

    </para>
 
    <sect3>
     <title>How to delegate</title>
  
     <para>
    </para>
 
    <sect3>
     <title>How to delegate</title>
  
     <para>

-     Like anything, its easier to see how others delegate than to do
-     it yourself. You may find that other developers seem even more
-     experienced or knowledgeable than you. Your job as a maintainer
-     does not mean you have to have to be the best or the
-     brightest. It means you need are responsible for showing good
-     judgment and for recognizing solutions that are maintainable and
-     are not. In a sentence: <emphasis>Keep an eye out for other
+     You may find that other developers seem even more experienced or
+     knowledgeable than you. Your job as a maintainer does not mean
+     you have to be the best or the brightest. It means you
+     are responsible for showing good judgment and for
+     recognizing which solutions are maintainable and which are not. 
+    </para>
+    <para>
+     Like anything, its easier to watch others delegate than to do it
+     yourself. In a sentence: <emphasis>Keep an eye out for other

      qualified developers who show an interest and sustained
      involvement with your project and try and shift responsibility
      towards them.</emphasis> The following ideas might be good places
      qualified developers who show an interest and sustained
      involvement with your project and try and shift responsibility
      towards them.</emphasis> The following ideas might be good places


@@ -1317,7 +1497,7 @@ pages for more information and options.
     </para>
  
     <sect4>
     </para>
  
     <sect4>

-     <title>Allow a larger group of people write access to your CVS
+     <title>Allow a larger group of people to have write access to your CVS

      repository and make real efforts towards rule by a
      committee</title>
 
      repository and make real efforts towards rule by a
      committee</title>
 


@@ -1333,26 +1513,25 @@ pages for more information and options.
      <para>
       The <ulink url="http://www.debian.org/"> Debian Project</ulink>
       is an extreme example of rule by committee. At current count,
      <para>
       The <ulink url="http://www.debian.org/"> Debian Project</ulink>
       is an extreme example of rule by committee. At current count,

-      more than 700 developers have full responsibility for certain
-      aspects of the projects. All these developers can upload into
-      the main FTP servers, and vote on major issues. Direction for
-      the project is determined by the project <ulink
+      more than 700 developers have full responsibility for
+      aspects of the project. All these developers can upload into
+      the main FTP server, and vote on major issues. Direction for
+      the project is determined by the project's <ulink

       url="http://www.debian.org/social_contract">social
       contract</ulink> and a <ulink
       url="http://www.debian.org/devel/constitution">constitution</ulink>. To
       facilitate this system, there are special teams (i.e. the
       url="http://www.debian.org/social_contract">social
       contract</ulink> and a <ulink
       url="http://www.debian.org/devel/constitution">constitution</ulink>. To
       facilitate this system, there are special teams (i.e. the

-      install team, the Japanese language team) and a technical
-      committee and a project lead. There is a project leader as well
-      but the leader's main responsibility is to, <quote>Appoint
-      Delegates or delegate decisions to the Technical
-      Committee.</quote>
+      install team, the Japanese language team) as well as a technical
+      committee and a project leader. The leader's main responsibility
+      is to, <quote>appoint delegates or delegate decisions to the
+      Technical Committee.</quote>

      </para>
 
      <para>
       While both of these projects operate on a scale that your
       project will not (at least initially), their example is
      </para>
 
      <para>
       While both of these projects operate on a scale that your
       project will not (at least initially), their example is

-      helpful. Debian's idea of a project who lead who can do
-      <emphasis>nothing</emphasis> but delegate can serve as a
+      helpful. Debian's idea of a project leader who can do
+      <emphasis>nothing</emphasis> but delegate serves as a

       caricature of how a project can involve and empower a huge
       number of developers and grow to a huge size.
      </para>
       caricature of how a project can involve and empower a huge
       number of developers and grow to a huge size.
      </para>


@@ -1361,7 +1540,7 @@ pages for more information and options.
 
     <sect4 id="releasemanager">
      <title>Publicly appoint someone as the release manager for a
 
     <sect4 id="releasemanager">
      <title>Publicly appoint someone as the release manager for a

-       specific release.</title>
+       specific release</title>

 
      <para>
       A release manager is usually responsible for coordinating
 
      <para>
       A release manager is usually responsible for coordinating


@@ -1373,20 +1552,21 @@ pages for more information and options.
      <para>
       This use of the release manager is a good way to give yourself a
       break and to shift the responsibility for accepting and
      <para>
       This use of the release manager is a good way to give yourself a
       break and to shift the responsibility for accepting and

-      rejecting patches to someone else. It is a good way of very
+      rejecting patches onto someone else. It is a good way of very

       clearly defining a chunk of work on the project as belonging to
       clearly defining a chunk of work on the project as belonging to

-      a certain person and its a great way of giving yourself a break.
+      a certain person and its a great way of giving yourself room to
+      breath.

      </para>
     </sect4>
 
     <sect4 id="delegatebranch">
      </para>
     </sect4>
 
     <sect4 id="delegatebranch">

-     <title>Delegate control of an entire branch.</title>
+     <title>Delegate control of an entire branch</title>

      <para>
       If your project chooses to have branches (as described in <xref
       linkend="branches">), it might be a good idea to appoint someone
       else to be the the head of a branch. If you like focusing your
       energy on development releases and the implementation of new
      <para>
       If your project chooses to have branches (as described in <xref
       linkend="branches">), it might be a good idea to appoint someone
       else to be the the head of a branch. If you like focusing your
       energy on development releases and the implementation of new

-      features, had total control over the stable releases to a
+      features, hand total control over the stable releases to a

       well-suited developer.
      </para>
 
       well-suited developer.
      </para>
 


@@ -1408,7 +1588,7 @@ pages for more information and options.
    <title>Accepting and Rejecting Patches</title>
    <para>
     This HOWTO has already touched on the fact that as the maintainer
    <title>Accepting and Rejecting Patches</title>
    <para>
     This HOWTO has already touched on the fact that as the maintainer

-    of a free software project, one of primary and most important
+    of a free software project, one of your primary and most important

     responsibilities will be accepting and rejecting patches submitted
     to you by other developers.
    </para>
     responsibilities will be accepting and rejecting patches submitted
     to you by other developers.
    </para>


@@ -1419,21 +1599,41 @@ pages for more information and options.
     <para>
      In <emphasis>Open Source Development with CVS</emphasis>, Karl
      Fogel makes a convincing argument that the most important things
     <para>
      In <emphasis>Open Source Development with CVS</emphasis>, Karl
      Fogel makes a convincing argument that the most important things

-     to keep in mind are a firm knowledge of the scope of your program
-     (that's the <quote>idea</quote> I talked about in <xref
-     linkend="chooseproject">) and the ability to recognize,
-     facilitate, and direct <quote>evolution</quote> of a free
-     software program so that the program can grow and change and
-     incorporate functionality that was originally unforeseen but avoid
-     digressions that might expand the scope of the program too much
-     and result and push the project towards an early death under its
-     own weight and unwieldiness. These are the criteria that you as a
-     project maintainer should take into account each time you receive
-     a patch.
+     to keep in mind when rejecting or accepting patches are:
+    </para>
+
+    <para>
+     <itemizedlist>
+
+      <listitem>
+       <para>A firm knowledge of the scope of your program (that's the
+       <quote>idea</quote> I talked about in <xref linkend="chooseproject">);</para>
+      </listitem>
+      
+      <listitem>
+       <para>The ability to recognize, facilitate, and direct
+       <quote>evolution</quote> of your program so that the program
+       can grow and change and incorporate functionality that was
+       originally unforeseen;</para>
+      </listitem>
+
+      <listitem>
+       <para>The necessity to avoid digressions that might expand the
+       scope of the program too much and result and push the project
+       towards an early death under its own weight and
+       unwieldiness.</para>
+      </listitem>
+
+     </itemizedlist>
+    </para>
+
+    <para>
+     These are the criteria that you as a project maintainer should
+     take into account each time you receive a patch.

     </para>
 
     <para>
     </para>
 
     <para>

-     Fogel elaborates on this again and states the <quote>the
+     Fogel elaborates on this and states the <quote>the

      questions to ask yourself when considering whether to implement
      (or approve) a change are:</quote>
     </para>
      questions to ask yourself when considering whether to implement
      (or approve) a change are:</quote>
     </para>


@@ -1457,11 +1657,11 @@ pages for more information and options.
     <para>
      The answers to these questions are never straightforward and its
      very possible (and even likely) that the person who submitted the
     <para>
      The answers to these questions are never straightforward and its
      very possible (and even likely) that the person who submitted the

-     patch may feel differently about the answer to those questions
+     patch may feel differently about the answer to these questions

      than you do. However, if you feel that that the answer to either
      of those questions is <quote>no,</quote> it is your responsibility
      to reject the change. If you fail to do this, the project will
      than you do. However, if you feel that that the answer to either
      of those questions is <quote>no,</quote> it is your responsibility
      to reject the change. If you fail to do this, the project will

-     become unwieldy and unmaintainable and will ultimately fail.
+     become unwieldy and unmaintainable and many ultimately fail.

     </para>
    </sect3>
 
     </para>
    </sect3>
 


@@ -1469,32 +1669,32 @@ pages for more information and options.
     <title>Rejecting patches</title>
 
     <para>
     <title>Rejecting patches</title>
 
     <para>

-     Rejecting patches is probably the most difficult and the most
-     sensitive job that the maintainer of any free software project
-     has to face. But sometimes it has to be done. I mentioned earlier
-     (in <xref linkend="developers"> and in <xref
-     linkend="delegation">) that any developer needs to try and
-     balance your responsibility and power to make what you think are
-     the best technical decisions with the fact that you will lose
-     support from other developers if you seem like you are on a
-     power trip or being overly bossy or possessive of a community-based
-     project. I recommend that you keep three major facts in mind when
-     rejecting patches (or other changes):
+     Rejecting patches is probably the most difficult and sensitive
+     job that the maintainer of any free software project has to
+     face. But sometimes it has to be done. I mentioned earlier (in
+     <xref linkend="developers"> and in <xref linkend="delegation">)
+     that you need to try and balance your responsibility and power to
+     make what you think are the best technical decisions with the
+     fact that you will lose support from other developers if you seem
+     like you are on a power trip or being overly bossy or possessive
+     of the community's project. I recommend that you keep these three
+     major concepts in mind when rejecting patches (or other changes):

     </para>
 
     <sect4>
      <title>Bring it to the community</title>
      <para>
     </para>
 
     <sect4>
      <title>Bring it to the community</title>
      <para>

-      One of the best ways of justifying  a decision to reject a patch
-      and working  to  not seem like  you  keep an  iron grip  on your
-      project is by  not making the  decision  alone at all. It  might
-      make  sense  to  turn over  larger  proposed  changes  or more
+      One of the best ways of justifying a decision to reject a patch
+      and working to not seem like you keep an iron grip on your
+      project is by not making the decision alone at all. It might
+      make sense to turn over larger proposed changes or more

       difficult decisions to a development mailing list where they can
       difficult decisions to a development mailing list where they can

-      be discussed. There will be some patches (bug fixes, etc.) which
-      will  definitely be accepted  and some that you  feel are so off
-      base that they do not even merit further discussion. It is those
-      that fall into the grey area between these two groups that might
-      merit a quick forward to a mailing list.
+      be discussed and debated. There will be some patches (bug fixes,
+      etc.) which will definitely be accepted and some that you feel
+      are so offbase that they do not even merit further
+      discussion. It is those that fall into the grey area between
+      these two groups that might merit a quick forward to a mailing
+      list.

      </para>
 
      <para>
      </para>
 
      <para>


@@ -1502,28 +1702,29 @@ pages for more information and options.
       maintainer you are worried about making the best decision for
       the project, for the project's users and developers, and for
       yourself as a responsible project leader. Turning things over to
       maintainer you are worried about making the best decision for
       the project, for the project's users and developers, and for
       yourself as a responsible project leader. Turning things over to

-      an email list will demonstrate your own responsible and
+      an email list will demonstrate your own responsibility and

       responsive leadership as it tests and serves the interests of
       your software's community.
      </para>
     </sect4>
 
     <sect4>
       responsive leadership as it tests and serves the interests of
       your software's community.
      </para>
     </sect4>
 
     <sect4>

-     <title>Technical issues is not always good justification</title>
+     <title>Technical issues are not always good justification</title>

      <para>
      <para>

-      Especially towards the beginning, you will find that many
-      changes are difficult to implement, introduce new bugs, or have
-      other technical problems. Try to see past these. Especially with
-      added functionality, good ideas do not always come from good
-      coders. Technical merit is a valid reason to postpone the
-      application of a patch but it is not always a good reason to
-      reject a change outright. Even small changes are worth the
-      effort of working with the developer submitting the patch to iron out bugs and
-      incorporate the change if you thing you think it seems like a
-      good addition to your project. The effort on your part will work
-      to make your project a community project and it will pull a new
-      or less experienced developer onto your project and even teach
-      them something that might help them in their next patch.
+      Especially towards the beginning of your project's life, you
+      will find that many changes are difficult to implement,
+      introduce new bugs, or have other technical problems. Try to see
+      past these. Especially with added functionality, good ideas do
+      not always come from good programmers. Technical merit is a
+      valid reason to postpone an application of a patch but it is not
+      always a good reason to reject a change outright. Even small
+      changes are worth the effort of working with the developer
+      submitting the patch to iron out bugs and incorporate the change
+      if you think it seems like a good addition to your project. The
+      effort on your part will work to make your project a community
+      project and it will pull a new or less experienced developer
+      into your project and even teach them something that might help
+      them in making their next patch.

      </para>
     </sect4>
 
      </para>
     </sect4>
 


@@ -1540,18 +1741,18 @@ pages for more information and options.
      </para>
 
      <para>
      </para>
 
      <para>

-      It is your responsibility to first justify your action to not
+      It is your responsibility to first justify your choice to not

       incorporate their change clearly and concisely. Then thank
       them. Let them know that you a appreciate their help and feel
       horrible that you can't incorporate their change. Let them know
       that you look forward to their staying involved and you hope
       that the next patch or idea meshes better with your project
       incorporate their change clearly and concisely. Then thank
       them. Let them know that you a appreciate their help and feel
       horrible that you can't incorporate their change. Let them know
       that you look forward to their staying involved and you hope
       that the next patch or idea meshes better with your project

-      because you appreciate their work and want to see it in the
-      project. If you have ever had a patch rejected that put a large
-      deal of time, thought, and energy into, you remember how it
-      feels and it feels bad. Keep this in mind when you have to let
-      someone down. It's never easy but you need to do everything you
-      have to make it as not-unpleasant as possible.
+      because you appreciate their work and want to see it in your
+      application. If you have ever had a patch rejected after putting
+      a large deal of time, thought, and energy into it, you remember
+      how it feels and it feels bad. Keep this in mind when you have
+      to let someone down. It's never easy but you need to do
+      everything you can to make it as not-unpleasant as possible.

      </para>
     </sect4>
    </sect3>
      </para>
     </sect4>
    </sect3>


@@ -1565,41 +1766,41 @@ pages for more information and options.
    <para>
     The idea of stable and development branches has already been
     described briefly in <xref linkend="chooseversioning"> and in
    <para>
     The idea of stable and development branches has already been
     described briefly in <xref linkend="chooseversioning"> and in

-    <xref linkend="delegatebranch">. These alludes attest to the fact
-    to some of the ways that multiple branches can affect your
-    software. Branches can let you avoid (to some extent) some of the
-    problems around rejecting patches (as described in <xref
-    linkend="patching">) by allowing you to temporarily compromise the
-    stability of your project without affected those users who need
-    that stability.
+    <xref linkend="delegatebranch">. These allusions attest to some of
+    the ways that multiple branches can affect your software. Branches
+    can let you avoid (to some extent) some of the problems around
+    rejecting patches (as described in <xref linkend="patching">) by
+    allowing you to temporarily compromise the stability of your
+    project without affecting those users who need that stability.

    </para>
 
    <para>
     The most common way of branching your project is to have one
    </para>
 
    <para>
     The most common way of branching your project is to have one

-    branch that is stable and one that is development. This is the
+    branch that is stable and one that is for development. This is the

     model followed by the Linux kernel that is described in <xref
     model followed by the Linux kernel that is described in <xref

-    linkend="chooseversioning">. In this model, there is always one
-    branch that is stable and always one that is in
-    development. Before any new release, the development branch goes
-    into a <quote>feature freeze</quote> where major changes and added
-    features are rejected or put on hold under the development kernel
-    is released as the new stable branch and major development begins
-    again on the development branch. Bug fixes and small changes that
-    are unlikely to have any large negative repercussions are
-    incorporated into the stable branch also to the development
+    linkend="chooseversioning">. In this model, there is
+    <emphasis>always</emphasis> one branch that is stable and always
+    one that is in development. Before any new release, the
+    development branch goes into a <quote>feature freeze</quote> as
+    described in <xref linkend="freezing"> where major changes and
+    added features are rejected or put on hold under the development
+    kernel is released as the new stable branch and major development
+    resumes on the development branch. Bug fixes and small changes
+    that are unlikely to have any large negative repercussions are
+    incorporated into the stable branch as well as the development

     branch.
    </para>
 
    <para>
     branch.
    </para>
 
    <para>

-    Linux's model is an extreme one. On many projects, there is no
-    need to have two versions always available. It may make sense to
+    Linux's model provides an extreme example. On many projects, there is no
+    need to have two versions constantly available. It may make sense to

     have two versions only near a release. The Debian project has
     historically made both a stable and an unstable distribution
     available but has expanded to this to include: stable, unstable,
     testing, experimental, and (around release time) a frozen
     distribution that only incorporates bug fixes during the
     transition from unstable to stable. There are few projects whose
     have two versions only near a release. The Debian project has
     historically made both a stable and an unstable distribution
     available but has expanded to this to include: stable, unstable,
     testing, experimental, and (around release time) a frozen
     distribution that only incorporates bug fixes during the
     transition from unstable to stable. There are few projects whose

-    size would necessitate a system like Debian but their use of
+    size would necessitate a system like Debian's but this use of

     branches helps demonstrate how they can be used to balance
     consistent and effective development with the need to make regular
     and usable releases.
     branches helps demonstrate how they can be used to balance
     consistent and effective development with the need to make regular
     and usable releases.


@@ -1616,30 +1817,26 @@ pages for more information and options.
      <varlistentry>
       <term>Minimize the number of branches</term>
       <listitem>
      <varlistentry>
       <term>Minimize the number of branches</term>
       <listitem>

-       <para>
-        Debian may be able to make good use of four or five branches
-        but it contains gigabytes of software in over 5000 packages
-        compiled for a 5-6 different architectures. Two is a good
-        number. Too many branches will confuse your users (I can't
-        count how many times I had to describe Debian's system when it
-        only had 2 and sometimes 3 branches!), potential developers
-        and even yourself. Branches can help but they come at a cost
-        so use them very sparingly.
-       </para>
+       <para>Debian may be able to make good use of four or five
+       branches but it contains gigabytes of software in over 5000
+       packages compiled for 5-6 different architectures. For you,
+       two is probably a good ceiling. Too many branches will confuse
+       your users (I can't count how many times I had to describe
+       Debian's system when it only had 2 and sometimes 3 branches!),
+       potential developers and even yourself. Branches can help but
+       they come at a cost so use them very sparingly.</para>

       </listitem>
      </varlistentry>
 
      <varlistentry>
       <term>Make sure that all your different branches are explained</term>
       <listitem>
       </listitem>
      </varlistentry>
 
      <varlistentry>
       <term>Make sure that all your different branches are explained</term>
       <listitem>

-       <para>
-        As I mentioned in the preceding paragraph, different branches
-        <emphasis>will</emphasis> confuse your users. Do everything
-        you can to avoid this by clearly explaining the different
-        branches in a prominent page on your website and in a Readme
-        file in the <acronym>FTP</acronym> or <acronym>HTTP</acronym>
-        directory.
-       </para>
+       <para>As I mentioned in the preceding paragraph, different
+       branches <emphasis>will</emphasis> confuse your users. Do
+       everything you can to avoid this by clearly explaining the
+       different branches in a prominent page on your website and in a
+       README file in the <acronym>FTP</acronym> or
+       web directory.</para>

 
        <para>
         I might also recommend against a mistake that I think Debian
 
        <para>
         I might also recommend against a mistake that I think Debian


@@ -1654,7 +1851,7 @@ pages for more information and options.
        </para>
 
        <para>
        </para>
 
        <para>

-        If you are going to do branches, especially early on, keep in
+        If you are going to use branches, especially early on, keep in

         mind that people are conditioned to understand the terms
         <quote>stable</quote> and <quote>development</quote> and you
         probably can't go wrong with this simple and common division of
         mind that people are conditioned to understand the terms
         <quote>stable</quote> and <quote>development</quote> and you
         probably can't go wrong with this simple and common division of


@@ -1666,27 +1863,25 @@ pages for more information and options.
      <varlistentry>
       <term>Make sure all your branches are always available</term>
       <listitem>
      <varlistentry>
       <term>Make sure all your branches are always available</term>
       <listitem>

-       <para>
-        Like a lot of document, this should probably should go without
-        saying but experience has taught me that it's not always
-        obvious to people. It's a good idea to physically split up
-        different branches in different directories or directory trees
-        on your <acronym>FTP</acronym> or <acronym>HTTP</acronym>
-        site. Linux accomplishes this by having all the v2.2 and a
-        v2.3 subdirectory where it is immediately obvious (after you
-        know their version numbering scheme) which directory is the
-        most recent stable and the current development
-        releases. Debian accomplishes this by naming all their
-        distribution by name and then changing symlinks named
-        <quote>stable,</quote> <quote>unstable</quote> and
-        <quote>frozen</quote> to point to which ever distribution (by
-        name) is in whatever stage. Both methods work and their are
-        others. In any case, it is important that different branches
-        are always available, are accessible from consistent
-        locations, and that different branches are clearly
-        distinguished from each other so your users know exactly what
-        they want to be downloading and where to get it.
-       </para>
+       <para>Like a lot of this document, this should probably should
+       go without saying but experience has taught me that it's not
+       always obvious to people. It's a good idea to physically split
+       up different branches into different directories or directory
+       trees on your <acronym>FTP</acronym> or web site. Linux
+       accomplishes this by having kernels in a v2.2 and a v2.3
+       subdirectory where it is immediately obvious (after you know
+       their version numbering scheme) which directory is for the most
+       recent stable and the current development releases. Debian
+       accomplishes this by naming all their distribution with names
+       (i.e. woody, potato, etc.) and then changing symlinks named
+       <quote>stable,</quote> <quote>unstable</quote> and
+       <quote>frozen</quote> to point to which ever distribution (by
+       name) is in whatever stage. Both methods work and there are
+       others. In any case, it is important that different branches
+       are always available, are accessible from consistent locations,
+       and that different branches are clearly distinguished from each
+       other so your users know exactly what they want and where to
+       get it.</para>

       </listitem>
      </varlistentry>
 
       </listitem>
      </varlistentry>
 


@@ -1698,16 +1893,19 @@ pages for more information and options.
 <!-- Section2: otherdev -->
 
   <sect2 id="otherdev">
 <!-- Section2: otherdev -->
 
   <sect2 id="otherdev">

-   <title>Other Development issues</title>
+   <title>Other Project Management issues</title>

    <para>
    <para>

-    There are more issues around surrounding interaction with
-    developers in a free software project that I can touch on in great
-    detail in a HOWTO of this size. Please don't hesitate to contact
-    me if you see any major omissions. Other smaller issues that are
-    worth mentioning are:
+    There are more issues surrounding interaction with developers in a
+    free software project that I can not touch on in great detail in a
+    HOWTO of this size and scope. Please don't hesitate to contact me if you see
+    any major omissions.

    </para>
 
    </para>
 

-   <sect3>
+   <para>
+     Other smaller issues that are worth mentioning are:
+   </para>
+
+   <sect3 id="freezing">

     <title>Freezing</title>
     <para>
      For those projects that choose to adopt a split development model
     <title>Freezing</title>
     <para>
      For those projects that choose to adopt a split development model


@@ -1716,7 +1914,7 @@ pages for more information and options.
     </para>
 
     <para>
     </para>
 
     <para>

-     Freeze come in two major forms. A <quote>feature freeze</quote>
+     Freezes come in two major forms. A <quote>feature freeze</quote>

      is a period when no significant functionality is added to a
      program. It is a period where established functionality (even
      skeletons of barely working functionality) can be improved and
      is a period when no significant functionality is added to a
      program. It is a period where established functionality (even
      skeletons of barely working functionality) can be improved and


@@ -1731,43 +1929,44 @@ pages for more information and options.
     <para>
      The second type of freeze is a <quote>code freeze</quote> which
      is much more like a released piece of software. Once a piece of
     <para>
      The second type of freeze is a <quote>code freeze</quote> which
      is much more like a released piece of software. Once a piece of

-     software has entered a code freeze, all changes to the code are
-     frowned upon and only changes that fix known bugs are
-     permitted. This type of freeze usually follows a <quote>feature
-     freeze</quote> and directly precedes a release. Most released
-     software is in what could be interpreted as a sort of high
-     level<quote>code freeze.</quote>
+     software has entered a <quote>code freeze,</quote> all changes to
+     the code are discouraged and only changes that fix known bugs
+     are permitted. This type of freeze usually follows a
+     <quote>feature freeze</quote> and directly precedes a
+     release. Most released software is in what could be interpreted
+     as a sort of high level <quote>code freeze.</quote>

     </para>
 
     <para>
     </para>
 
     <para>

-     Even you do not choose to appoint a release manager (<xref
+     Even if you never choose to appoint a release manager (<xref

      linkend="releasemanager">), you will have an easier time
      justifying the rejection or postponement of patches (<xref
      linkend="releasemanager">), you will have an easier time
      justifying the rejection or postponement of patches (<xref

-     linkend="patching"> before a release with a publicly stated
+     linkend="patching">) before a release with a publicly stated

      freeze in effect.
     </para>
    </sect3>
      freeze in effect.
     </para>
    </sect3>

+  </sect2>

 
 

-   <sect3>
-    <title>Forking</title>
+   <sect2>
+    <title>Forks</title>

     <para>
     <para>

-     Forks are the most extreme interpretation of a branch. A fork is
-     when a group of developers takes code from a free software
-     project and actually starts a brand new free software
-     project. The most famous example of a fork is Emacs and
-     XEmacs. Both emacsen are based on an almost identical code-base
-     but for technical, political, and philosophical reasons,
-     development was split into two projects which now compete with
-     each other.
+     I wasn't sure about how I would deal with forking in this
+     document (or if I would deal with forking at all). A fork is when
+     a group of developers takes code from a free software project and
+     actually starts a brand new free software project with it. The
+     most famous example of a fork was between Emacs and XEmacs. Both
+     emacsen are based on an identical code-base but for technical,
+     political, and philosophical reasons, development was split into
+     two projects which now compete with each other.

     </para>
 
     <para>
      The short version of the fork section is, <emphasis>don't do
      them.</emphasis> Forks force developers to choose one project to
     </para>
 
     <para>
      The short version of the fork section is, <emphasis>don't do
      them.</emphasis> Forks force developers to choose one project to

-     work with, cause nasty political divisions, redundancy of work.
-     Luckily, usually the threat of the fork is enough to scare the
-     maintainer or maintainers of a project into changing the way they
-     run their project to avoid it.
+     work with, cause nasty political divisions, and redundancy of
+     work.  Luckily, usually the threat of the fork is enough to scare
+     the maintainer or maintainers of a project into changing the way
+     they run their project.

     </para>
 
     <para>
     </para>
 
     <para>


@@ -1778,7 +1977,6 @@ pages for more information and options.
      absolutely unresolvable, I recommend Fogel's book as a good place
      to start.
     </para>
      absolutely unresolvable, I recommend Fogel's book as a good place
      to start.
     </para>

-   </sect3>

   </sect2>
  </sect1>
 
   </sect2>
  </sect1>
 


@@ -1794,7 +1992,7 @@ pages for more information and options.
    If you've worked your way up to here, congratulations, you are
    nearing the end of this document. This final section describes some
    of the situations in which you, in your capacity as project
    If you've worked your way up to here, congratulations, you are
    nearing the end of this document. This final section describes some
    of the situations in which you, in your capacity as project

-   maintainer, will be interacting with users and gives some
+   maintainer, will be interacting with users. It gives some

    suggestions on how these situations might be handled effectively.
   </para>
 
    suggestions on how these situations might be handled effectively.
   </para>
 


@@ -1806,10 +2004,10 @@ pages for more information and options.
   </para>
 
   <para>
   </para>
 
   <para>

-   Users in the free software community are different than users in
-   the world of proprietary software and they should be treated
-   differently. Some ways in which the groups differ significantly
-   follow:
+   Users in the free software community are different than developers
+   and are also different than users in the world of proprietary
+   software and they should be treated differently than either
+   group. Some ways in which the groups differ significantly follow:

   </para>
 
   <para>
   </para>
 
   <para>


@@ -1823,27 +2021,27 @@ pages for more information and options.
     </listitem>
 
     <listitem>
     </listitem>
 
     <listitem>

-     <para>In the free software world, you are often your users only
+     <para>In the free software world, you are often your users' only

      choice. Because there is such an emphasis on not replicating the
      work of others in the free software community and because the
      element of competition present in the propriety software model is
      absent (or at least in an extremely different form) in the free
      choice. Because there is such an emphasis on not replicating the
      work of others in the free software community and because the
      element of competition present in the propriety software model is
      absent (or at least in an extremely different form) in the free

-     software development model your users will probably be the only
-     project that does what you do (or at least the only one that does
-     what you do in the way that you do it). This means your
-     responsiveness to your users is even more important in that in
-     the proprietary world.</para>
+     software development model, you will probably be the only project
+     that does what you do (or at least the only one that does what
+     you do in the way that you do it). This means your responsiveness
+     to your users is even more important than in the proprietary
+     software world.</para>

     </listitem>
 
     <listitem>
      <para>In an almost paradoxical situation, free software projects
     </listitem>
 
     <listitem>
      <para>In an almost paradoxical situation, free software projects

-     have less immediate or dire consequences for ignoring their
-     users--it is often easier to do. Because you don't usually need
-     to compete with another product in the free software model,
-     chances are good that you will not be scrambling to gain the
-     features of the competitor's newest program. This means that your
-     development process will have to be directed either internally,
-     by your users or both.</para>
+     have less immediate or dire consequences for ignoring their users
+     altogether. It is also often easier to do. Because you don't
+     usually need to compete with another product, chances are good
+     that you will not be scrambling to gain the features of your
+     competitor's newest program. This means that your development
+     process will have to be directed either internally, by a
+     commitment to your users, or through both.</para>

     </listitem>
    </itemizedlist>
   </para>
     </listitem>
    </itemizedlist>
   </para>


@@ -1852,9 +2050,9 @@ pages for more information and options.
    Trying to tackle this unique situation can only be done
    indirectly. Developers and maintainers need to listen to users and
    to try and be as responsive as possible. A solid knowledge of the
    Trying to tackle this unique situation can only be done
    indirectly. Developers and maintainers need to listen to users and
    to try and be as responsive as possible. A solid knowledge of the

-   situation recounted above is any free software developers best tool
+   situation recounted above is any free software developer's best tool

    for shifting his development or leadership style to fit the unique
    for shifting his development or leadership style to fit the unique

-   process of free software development. This chapters will try and
+   process of free software project management. This chapters will try and

    introduce some of the more difficult or important points in any
    projects interactions with users and give some hints on how to
    tackle these.
    introduce some of the more difficult or important points in any
    projects interactions with users and give some hints on how to
    tackle these.


@@ -1868,44 +2066,102 @@ pages for more information and options.
    <para>
     In addition to your users being your developers, they are also
     (and perhaps more commonly) your testers. Before I get flamed, I
    <para>
     In addition to your users being your developers, they are also
     (and perhaps more commonly) your testers. Before I get flamed, I

-    should rephrase my sentence: <emphasis>some</emphasis> users are
-    your testers.
+    should rephrase my sentence: <emphasis>some of your
+    users</emphasis> (those who explicityly volunteer) are your
+    testers.

    </para>
 
    <para>
     It is important that this distinction be made early on because not
    </para>
 
    <para>
     It is important that this distinction be made early on because not

-    all of your users wants to be testers. Many users want to use
-    stable software and don't care if they don't have the newest
-    greatest software with the latest and greatest features. These
-    users except a stable, tested piece of software with major or
-    obvious bugs worked out or openly declared and will be angry if
-    they find themselves in a testing position. This is yet another
-    way in which a split development model (as mentioned in <xref
-    linkend="branches">) might come in handy.
+    all of your users want to be testers. Many users want to use
+    stable software and don't care if they don't have the newest,
+    greatest software with the latest, greatest features. These users
+    except a stable, tested piece of software without major or obvious
+    bugs and will be angry if they find themselves testing. This is
+    yet another way in which a split development model (as mentioned
+    in <xref linkend="branches">) might come in handy.
+   </para>
+
+   <para>
+     <quote><ulink
+     url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing
+     Projects the Open Source Way</ulink></quote> describes what a
+     good test should look for:

    </para>
 
    </para>
 

+   <variablelist>
+    <varlistentry>
+     <term>Boundary conditions</term>
+
+     <listitem>
+      <para>Maximum buffer lengths, data conversions, upper/lower
+      boundary limits, and so on.</para>
+     </listitem>
+
+    </varlistentry>
+    <varlistentry>
+     <term>Inappropriate behavior</term>
+
+     <listitem>
+      <para>Its a good idea to find out what a program will do if a
+      user hands it a value it isn't expecting, hits the wrong button,
+      etc. Ask yourself a bunch of <quote>what if</quote> questions
+      and think of anything that <emphasis>might</emphasis> fail or
+      <emphasis>might</emphasis> go wrong and find out what your
+      program would do in those cases.</para>
+     </listitem>
+
+    </varlistentry>
+    <varlistentry>
+     <term>Graceful failure</term>
+
+     <listitem>
+      <para>The answer to a number of the <quote>what if</quote>
+      questions above is probably <quote>failure</quote> which is
+      often the only answer. Now make sure that it happens
+      nicely. Make sure that when it crashes, there is some indication
+      of why it crashed or failed so that the user or developer
+      understands whats going on.</para>
+     </listitem>
+
+    </varlistentry>
+
+    <varlistentry>
+     <term>Standards conformance</term>
+
+     <listitem>
+      <para>If possible, make sure your programs conforms to
+      standards. If it's interactive, don't be too creative with
+      interfaces. If it is non-interactive, make sure it communicates
+      over appropriate and established channels with other programs
+      and with the rest of the system.</para>
+     </listitem>
+
+    </varlistentry>
+   </variablelist>
+

    <sect3>
     <title>Automated testing</title>
     <para>
    <sect3>
     <title>Automated testing</title>
     <para>

-     For many programs, many common and mistakes can be caught by
+     For many programs, many common mistakes can be caught by

      automated means. Automated tests tend to be pretty good at
      catching errors that you've run into several times before or
      automated means. Automated tests tend to be pretty good at
      catching errors that you've run into several times before or

-     something you just forget and not very good at finding errors,
-     even major ones, that were totally unforeseen.
+     the things you just forget. They are not very good at finding
+     errors, even major ones, that are totally unforeseen.

     </para>
 
     <para>
      CVS comes with a bourne shell script called sanity.sh that is
      worth looking at. Debian uses a program called lintian that
      checks Debian packages for all of the most common errors. While
     </para>
 
     <para>
      CVS comes with a bourne shell script called sanity.sh that is
      worth looking at. Debian uses a program called lintian that
      checks Debian packages for all of the most common errors. While

-     using these scripts may not be possible, there is a host of other
+     use of these scripts may not be helpful, there is a host of other

      sanity checking software on the net that may be applicable (feel
      sanity checking software on the net that may be applicable (feel

-     free to email any recommendations). None of these will create a
-     bug-free release but they will avoid at least some major
+     free to email me any recommendations). None of these will create
+     a bug-free release but they will avoid at least some major

      oversights. Finally, if your programs become a long term
      endeavor, you will find that there are certain errors that you
      tend to make over and over. Start a collection of scripts that
      oversights. Finally, if your programs become a long term
      endeavor, you will find that there are certain errors that you
      tend to make over and over. Start a collection of scripts that

-     check for these errors to help prevent them in the future.
+     check for these errors to help keep them out of future releases.

     </para>
    </sect3>
 
     </para>
    </sect3>
 


@@ -1915,68 +2171,76 @@ pages for more information and options.
      For any program that depends on user interactivity, many bugs
      will only be uncovered through testing by users actually clicking
      the keys and pressing the mouse buttons. For this you need
      For any program that depends on user interactivity, many bugs
      will only be uncovered through testing by users actually clicking
      the keys and pressing the mouse buttons. For this you need

-     testers and as many testers as possible.
+     testers and as many as possible.

     </para>
 
     <para>
      The most difficult part of testing is finding testers. It's
      usually a good tactic to post a message to a relevant mailing
      list or news group announcing a specific proposed release date
     </para>
 
     <para>
      The most difficult part of testing is finding testers. It's
      usually a good tactic to post a message to a relevant mailing
      list or news group announcing a specific proposed release date

-     and outline the functionality of the program. If you put some
-     time into the announcement, you are sure to get a few bites.
+     and outlining the functionality of your program. If you put some
+     time into the announcement, you are sure to get a few responses.

     </para>
 
     <para>
     </para>
 
     <para>

-     The second most difficult part of testing is keeping your testers
-     and keeping them actively involved in the testing
-     process. Fortunately, there are some tried and true tactics that
-     can applied towards this end:
+     The second most difficult part of testing is
+     <emphasis>keeping</emphasis> your testers and keeping them
+     actively involved in the testing process. Fortunately, there are
+     some tried and true tactics that can applied towards this end:

     </para>
 
     <para>
     </para>
 
     <para>

-     <itemizedlist>
+     <variablelist>

 
 

-      <listitem>
-       <para><emphasis>Make things simple for your testers.</emphasis>
-       Your testers are doing you a favor so make it as easy as
-       possible. This means that you should be careful to package your
-       software in a way that is easy to find, unpack, install, and
-       uninstall. This also means you should explain what you are
-       looking for to each tester and make the means for reporting
-       bugs simple and well established. The key is to provide as much
-       structure as possible to make your tester's job easy and
-       maintain as much flexibility as possible for those that want to
-       do things a little differently.</para>
-      </listitem>
+      <varlistentry>
+       <term>Make things simple for your testers</term>
+       <listitem>
+       <para>Your testers are doing you a favor so make it as easy as
+       possible for them. This means that you should be careful to
+       package your software in a way that is easy to find, unpack,
+       install, and uninstall. This also means you should explain
+       what you are looking for to each tester and make the means for
+       reporting bugs simple and well established. The key is to
+       provide as much structure as possible to make your testers'
+       jobs easy and to maintain as much flexibility as possible for
+       those that want to do things a little differently.</para>
+       </listitem>
+      </varlistentry>

 
 

-      <listitem>
-       <para><emphasis>Be responsive to your testers.</emphasis> When
-       your testers submit bugs, respond to them and respond
-       quickly. Even if you are only responding to tell them that the
-       bug has already been fixed, quick and consistent response make
-       them feel like their work is heard, important, and
-       appreciated.</para>
-      </listitem>
+      <varlistentry>
+       <term>Be responsive to your testers</term>
+       <listitem>
+       <para>When your testers submit bugs, respond to them and
+       respond quickly. Even if you are only responding to tell them
+       that the bug has already been fixed, quick and consistent
+       responses make them feel like their work is heard, important,
+       and appreciated.</para>
+       </listitem>
+      </varlistentry>

 
 

-      <listitem>
-       <para><emphasis>Thank your testers.</emphasis> Thank them
-       personally each time they send you patch. Thank them publicly
-       in the documentation and the about section of your program. You
-       appreciate your testers and your program would not be possible
-       without their help. Make sure they know and pat them on the
-       back by making sure the rest of the world knows it too. It will
-       be appreciated more than you expected.</para>
-      </listitem>
+      <varlistentry>
+       <term>Thank your testers</term>
+       <listitem>
+       <para>Thank them personally each time they send you
+       patch. Thank them publicly in the documentation and the about
+       section of your program. You appreciate your testers and your
+       program would not be possible without their help. Make sure
+       they know it. Publicly, pat them on the back to make sure the rest of
+       the world knows it too. It will be appreciated more than you
+       expected.</para>
+       </listitem>

 
 

-     </itemizedlist>
+      </varlistentry>
+     </variablelist>

     </para>
     </para>

+

    </sect3>
   </sect2>
 
 <!-- Section2: support  -->
 
   <sect2 id="support">
    </sect3>
   </sect2>
 
 <!-- Section2: support  -->
 
   <sect2 id="support">

-   <title>Setting up a Support Infrastructure</title>
+   <title>Setting up Support Infrastructure</title>

 
    <para>
     While testing is important, the large part of your interactions
 
    <para>
     While testing is important, the large part of your interactions


@@ -1984,9 +2248,9 @@ pages for more information and options.
     support. The best way to make sure your users are adequately
     supported in using your program is to set up a good infrastructure
     for this purpose so that your developers and users help each other
     support. The best way to make sure your users are adequately
     supported in using your program is to set up a good infrastructure
     for this purpose so that your developers and users help each other

-    and less of the burden falls on you while people get quicker and
-    better responses to their questions. This infrastructure comes in
-    several forms:
+    and less of the burden falls on you. This way, people will also
+    get quicker and better responses to their questions. This
+    infrastructure comes in several major forms:

    </para>
 
    <sect3>
    </para>
 
    <sect3>


@@ -1994,7 +2258,7 @@ pages for more information and options.
     <para>
      It should not come as any surprise that the key element to any
      support infrastructure is good documentation. This topic was
     <para>
      It should not come as any surprise that the key element to any
      support infrastructure is good documentation. This topic was

-     large covered in <xref linkend="documentation"> and will not be
+     largely covered in <xref linkend="documentation"> and will not be

      repeated here.
     </para>
    </sect3>
      repeated here.
     </para>
    </sect3>


@@ -2003,9 +2267,9 @@ pages for more information and options.
     <title>Mailing lists</title>
     <para>
      Aside from documentation, effective mailing lists will be your
     <title>Mailing lists</title>
     <para>
      Aside from documentation, effective mailing lists will be your

-     greatest tool in supporting user support. Running a mailing list
+     greatest tool in providing user support. Running a mailing list

      well is more complicated than installing mailing list software
      well is more complicated than installing mailing list software

-     onto a machine. 
+     onto a machine.

     </para>
 
     <sect4>
     </para>
 
     <sect4>


@@ -2016,14 +2280,14 @@ pages for more information and options.
       lists (perhaps into project-user@host and project-devel@host)
       and enforce the division. If people post a development question
       onto -user, politely ask them to repost it onto -devel and vise
       lists (perhaps into project-user@host and project-devel@host)
       and enforce the division. If people post a development question
       onto -user, politely ask them to repost it onto -devel and vise

-      versa. Subscribe yourself to both groups and encourage primarily
-      developers to do the same.
+      versa. Subscribe yourself to both groups and encourage all
+      primarily developers to do the same.

      </para>
 
      <para>
       This system provides so that no one person is stuck doing all of
       the support work and works so that users learn more about the
      </para>
 
      <para>
       This system provides so that no one person is stuck doing all of
       the support work and works so that users learn more about the

-      program, they can help new users with their questions.
+      program, they can help newer users with their questions.

      </para>
     </sect4>
 
      </para>
     </sect4>
 


@@ -2031,8 +2295,8 @@ pages for more information and options.
      <title>Choose mailing list software well</title>
      <para>
       Please don't make the selection of mailing list software
      <title>Choose mailing list software well</title>
      <para>
       Please don't make the selection of mailing list software

-      lightly. Please consider easy accessibility by users without a
-      lot of technical experience so you want to be as easy as
+      impulsively. Please consider easy accessibility by users without
+      a lot of technical experience so you want to be as easy as

       possible. Web accessibility to an archive of the list is also
       important.
      </para>
       possible. Web accessibility to an archive of the list is also
       important.
      </para>


@@ -2042,18 +2306,20 @@ pages for more information and options.
       url="http://www.greatcircle.com/majordomo/">majordomo</ulink>
       and <ulink url="http://www.list.org/">GNU Mailman</ulink>. A
       long time advocate of majordomo, I would now recommend any
       url="http://www.greatcircle.com/majordomo/">majordomo</ulink>
       and <ulink url="http://www.list.org/">GNU Mailman</ulink>. A
       long time advocate of majordomo, I would now recommend any

-      project choose GNU Mailman. It fulfills the criteria listed above
-      and makes it easier to do. It provides a good mailing list
-      program for a free software project maintainer as opposed to a
-      good mailing list application for a mailing list administrator.
+      project choose GNU Mailman. It fulfills the criteria listed
+      above and makes it easier. It provides a good mailing
+      list program for a free software project maintainer as opposed
+      to a good mailing list application for a mailing list
+      administrator.

      </para>
 
      <para>
      </para>
 
      <para>

-      There are other things you want to take in setting up your
-      list. If it is possible to gate your mailing lists to USENET and
-      provide them in digest form as well as making them accessible on
-      the web, you will please some users and work to make the support
-      infrastructure slightly more accessible.
+      There are other things you want to take into consideration in
+      setting up your list. If it is possible to gate your mailing
+      lists to USENET and provide it in digest form as well as
+      making them accessible on the web, you will please some users
+      and work to make the support infrastructure slightly more
+      accessible.

      </para>
     </sect4>
    </sect3>
      </para>
     </sect4>
    </sect3>


@@ -2062,19 +2328,20 @@ pages for more information and options.
     <title>Other support ideas</title>
 
     <para>
     <title>Other support ideas</title>
 
     <para>

-     A mailing list and accessible documentation all you can do to set
-     up good user support infrastructure. Be creative. If you stumble
-     across something works well, email me and I'll include it here in
-     the HOWTO.
+     A mailing list and accessible documentation are far from all you
+     can do to set up good user support infrastructure. Be
+     creative. If you stumble across something that works well, email me
+     and I'll include it here.

     </para>
     </para>

+

     <sect4>
      <title>Make your self accessible</title>
      <para>
     <sect4>
      <title>Make your self accessible</title>
      <para>

-      You can not put to few methods to access you. If you hang out in
-      an <acronym>IRC</acronym> channel, don't hesitate to list in
-      your projects documentation. List email and snail mail
-      addresses, or ways to reach you via <acronym>ICQ</acronym>,
-      <acronym>AIM</acronym>, or Jabber.
+      You can not list too few methods to reach you. If you hang out
+      in an <acronym>IRC</acronym> channel, don't hesitate to list it
+      in your projects documentation. List email and snailmail
+      addresses, and ways to reach you via <acronym>ICQ</acronym>,
+      <acronym>AIM</acronym>, or Jabber if they apply.

     </para>
     </sect4>
 
     </para>
     </sect4>
 


@@ -2088,10 +2355,11 @@ pages for more information and options.
       url="http://bugs.debian.org">Debian Bug Tracking System</ulink>
       (<acronym>BTS</acronym>) although it may not be best choice for
       every project (it seems to currently be buckling under its own
       url="http://bugs.debian.org">Debian Bug Tracking System</ulink>
       (<acronym>BTS</acronym>) although it may not be best choice for
       every project (it seems to currently be buckling under its own

-      weight. As well as a damn good web browser, the mozilla project
+      weight) As well as a damn good web browser, the mozilla project

       has spawned a sub-project resulting in a bug tracking system
       called <ulink
       has spawned a sub-project resulting in a bug tracking system
       called <ulink

-      url="http://www.mozilla.org/projects/bugzilla/">bugzilla</ulink>.
+      url="http://www.mozilla.org/projects/bugzilla/">bugzilla</ulink>
+      which has become extremely possible and which I like a lot.

      </para>
 
      <para>
      </para>
 
      <para>


@@ -2099,9 +2367,9 @@ pages for more information and options.
       developers should be careful to not spend more time on the bug
       tracking system than on the bugs or the projects themselves. If
       a project continues to grow, use of a bug tracking system can
       developers should be careful to not spend more time on the bug
       tracking system than on the bugs or the projects themselves. If
       a project continues to grow, use of a bug tracking system can

-      provide an easy standard way for users and testers to report
-      bugs and for developers and maintainers to fix them in an
-      orderly fashion.
+      provide an easy standard avenue for users and testers to report
+      bugs and for developers and maintainers to fix them and track
+      them in an orderly fashion.

      </para>
     </sect4>
    </sect3>
      </para>
     </sect4>
    </sect3>


@@ -2113,14 +2381,14 @@ pages for more information and options.
    <title>Releasing Your Program</title>
 
    <para>
    <title>Releasing Your Program</title>
 
    <para>

-    As mentioned earlier in the HOWTO, the first rule or releasing is,
+    As mentioned earlier in the HOWTO, the first rule of releasing is,

     <emphasis>release something useful.</emphasis> Non-working or
     not-useful software will not attract anyone to your
     <emphasis>release something useful.</emphasis> Non-working or
     not-useful software will not attract anyone to your

-    project. People will be turned off of your project and be likely
+    project. People will be turned off of your project and will be likely

     to simply gloss over it next time they see a new version
     announced. Half-working software, if useful, will intrigue people,
     to simply gloss over it next time they see a new version
     announced. Half-working software, if useful, will intrigue people,

-    whet their appetites for the version to come, and encourage them
-    to join the development process.
+    whet their appetites for versions to come, and encourage them to
+    join the development process.

    </para>
 
    <sect3>
    </para>
 
    <sect3>


@@ -2129,11 +2397,12 @@ pages for more information and options.
     <para>
      Making the decision to release your software for the first time
      is an incredibly important and incredibly stressful decision. But
     <para>
      Making the decision to release your software for the first time
      is an incredibly important and incredibly stressful decision. But

-     it needs to be done. My advice is to try and make something that
+     it needs to  done. My advice is to try and make something that

      is complete enough to be usable and incomplete enough to allow
      is complete enough to be usable and incomplete enough to allow

-     for flexibility and imagination by your future developers. It's
-     not an easy decision. Ask for help on a local Linux User Group
-     mailing list or from a group of developer friends.
+     for flexibility and room for imagination by your future
+     developers. It's not an easy decision. Ask for help on a local
+     Linux User Group mailing list or from a group of developer
+     friends.

     </para>
 
     <para>
     </para>
 
     <para>


@@ -2144,10 +2413,45 @@ pages for more information and options.
     </para>
 
     <para>
     </para>
 
     <para>

-     <emphasis>When you feel in your gut it is time and you feel
+     <emphasis>When you feel in your gut that it is time and you feel

      you've weighed the situation well several times, cross your
      fingers and take the plunge.</emphasis>
    </para>
      you've weighed the situation well several times, cross your
      fingers and take the plunge.</emphasis>
    </para>

+
+    <para>
+     After you've released for the first time, knowing when to release
+     becomes less stressful, but just as difficult to gauge. I like
+     the criteria offered by Robert Krawitz in his article, <ulink
+     url="http://www.advogato.org/article/196.html"><quote>Free
+     Software Project Management</quote></ulink> for maintaining a
+     good release cycle. He recommends that you ask yourself,
+     <quote>does this release...</quote>
+    </para>
+
+    <para>
+     <itemizedlist>
+      <listitem>
+       <para>Contain sufficient new functionality or bug fixes to be
+       worth the effort.</para>
+      </listitem>
+
+      <listitem>
+       <para>Be spaced sufficiently far apart to allow the user time
+       to work with the latest release.</para>
+      </listitem>
+
+      <listitem>
+       <para>Be sufficiently functional so that the user can get work
+       done (quality).</para>
+      </listitem>
+     </itemizedlist>
+    </para>
+
+    <para>
+     If the answer is yes to all of these questions, its probably time
+     for a release. If in doubt, remember that asking for advice can't
+     hurt.
+    </para>

    </sect3>
 
    <sect3>
    </sect3>
 
    <sect3>


@@ -2156,12 +2460,12 @@ pages for more information and options.
     <para>
      If you've followed the guidelines described in this HOWTO up
      until this point, the mechanics of doing a release are going to
     <para>
      If you've followed the guidelines described in this HOWTO up
      until this point, the mechanics of doing a release are going to

-     be the easy part of releasing. If you have set up a consistent
+     be the easy part of releasing. If you have set up consistent

      distribution locations and the other infrastructure described in
      distribution locations and the other infrastructure described in

-     the preceding sections, releasing should be as simple as
-     building the package, checking it once over, and uploading it
-     into the appropriate place and then reflecting the release on
-     your website.
+     the preceding sections, releasing should be as simple as building
+     the package, checking it once over, and uploading it into the
+     appropriate place and then making your website reflect the
+     change.

     </para>
    </sect3>
 
     </para>
    </sect3>
 


@@ -2172,66 +2476,76 @@ pages for more information and options.
      When contemplating releases, it worth considering the fact that
      not every release needs to be a full numbered release. Software
      users are accustomed to pre-releases but you must be careful to
      When contemplating releases, it worth considering the fact that
      not every release needs to be a full numbered release. Software
      users are accustomed to pre-releases but you must be careful to

-     label these releases accurately or they cause more problems then
+     label these releases accurately or they will cause more problems then

      they are worth.
     </para>
 
      they are worth.
     </para>
 

+    <para>
+     The observation is often made that many free software developers
+     seem to be confused about the release cycle. <quote><ulink
+     url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing
+     Projects the Open Source Way</ulink></quote> suggests that you memorize
+     the phrase, <quote>Alpha is not Beta. Beta is not Release</quote>
+     and I'd agree that tis is a probably a good idea.
+    </para>
+

     <para>
      <variablelist>
 
       <varlistentry>
        <term>alpha releases</term>
        <listitem>
     <para>
      <variablelist>
 
       <varlistentry>
        <term>alpha releases</term>
        <listitem>

-       <para>
-         Alpha releases are expected to be unstable, perhaps a little
-         unsafe, but definitely usable. Alpha versions should have
-         full functionality and limited testing. They can have known
-         bugs and kinks that have yet to be worked out. Before sure to
-         keep in mind that <emphasis>alpha releases are still
-         releases</emphasis> and people are not going to be expecting
-         a nightly build from the CVS source. An alpha should work and
-         have minimal testing and bug fixing already finished.
-        </para>
+       <para>Alpha software is feature-complete but sometimes only
+       partially functional.</para>
+
+       <para>Alpha releases are expected to be unstable, perhaps a
+       little unsafe, but definitely usable. They
+       <emphasis>can</emphasis> have known bugs and kinks that have
+       yet to be worked out. Before releasing an alpha, be sure to
+       keep in mind that <emphasis>alpha releases are still
+       releases</emphasis> and people are not going to be expecting a
+       nightly build from the CVS source. An alpha should work and
+       have minimal testing and bug fixing already finished.</para>

        </listitem>
       </varlistentry>
 
       <varlistentry>
        <term>beta releases</term>
        <listitem>
        </listitem>
       </varlistentry>
 
       <varlistentry>
        <term>beta releases</term>
        <listitem>

-       <para>
-         Beta releases are general expected to be usable and
-         slightly unstable, although definitely
-         <emphasis>not</emphasis> unsafe. Beta releases usually
-         preclude a full release by under a month. They can contain
-         small known bugs but no major ones. All major functionality
-         should be fully implemented although the exact mechanics can
-         still be worked out. Beta releases are great tool to whet the
-         appetites of potential users by giving them a very
-         realistic view of where your project is going in the very
-         near future and can help keep interest by giving people
-         <emphasis>something.</emphasis>
-        </para>
+       <para>Beta software is feature-complete and functional, but is
+       in the testing cycle and still has a few bugs left to be
+       ironed out.</para>
+
+       <para>Beta releases are general expected to be usable and
+       slightly unstable, although definitely <emphasis>not
+       unsafe.</emphasis> Beta releases usually preclude a full
+       release by under a month. They can contain small known bugs
+       but no major ones. All major functionality should be fully
+       implemented although the exact mechanics can still be worked
+       out. Beta releases are great tool to whet the appetites of
+       potential users by giving them a very realistic view of where
+       your project is going to be in the very near future and can
+       help keep interest by giving people
+       <emphasis>something.</emphasis></para>

        </listitem>
       </varlistentry>
 
       <varlistentry>
        <term>development releases</term>
        <listitem>
        </listitem>
       </varlistentry>
 
       <varlistentry>
        <term>development releases</term>
        <listitem>

-       <para>
-         Development release is much more vague term than
-         <quote>alpha</quote> or <quote>beta</quote>. I usually choose
-         to reserve the term for discussion of a development
-         branch. There are other ways to use the term. So many in
-         fact, that I feel the term has been cheapened. The popular
-         window manager <ulink
-         url="http://www.enlightenment.org">Enlightenment</ulink> has
-         released <emphasis>nothing but</emphasis> development
-         releases. Most often, the term is used to describe releases
-         that are not even to alpha or beta stages though and if I
-         were to release a pre-alpha release in order to keep interest
-         in my project live, this is probably how I would have to label
-         it.
-        </para>
+       <para><quote>Development release</quote> is much a more vague
+       term than <quote>alpha</quote> or <quote>beta</quote>. I
+       usually choose to reserve the term for discussion of a
+       development branch although there are other ways to use the
+       term. So many in fact, that I feel the term has been
+       cheapened. The popular window manager <ulink
+       url="http://www.enlightenment.org">Enlightenment</ulink> has
+       released <emphasis>nothing but</emphasis> development
+       releases. Most often, the term is used to describe releases
+       that are not even alpha or beta and if I were to release a
+       pre-alpha version of a piece of software in order to keep
+       interest in my project alive, this is probably how I would
+       have to label it.</para>

        </listitem>
       </varlistentry>
 
        </listitem>
       </varlistentry>
 


@@ -2253,7 +2567,7 @@ pages for more information and options.
     know to come and try it out and hopefully jump on board with
     development. If everything is in order as described above, this
     will be a quick and painless process. A quick announcement is all
     know to come and try it out and hopefully jump on board with
     development. If everything is in order as described above, this
     will be a quick and painless process. A quick announcement is all

-    that it takes to put yourself on the free software communities
+    that it takes to put yourself on the free software community's

     radar screen.
    </para>
 
     radar screen.
    </para>
 


@@ -2277,7 +2591,7 @@ pages for more information and options.
      The rest of the email should describe the programs functionality
      quickly and concisely in no more than two paragraphs and should
      provide links to the projects webpage and direct links to
      The rest of the email should describe the programs functionality
      quickly and concisely in no more than two paragraphs and should
      provide links to the projects webpage and direct links to

-     downloads for those that want it right away.
+     downloads for those that want to try it right away.

     </para>
 
     <para>
     </para>
 
     <para>


@@ -2291,35 +2605,1128 @@ pages for more information and options.
     <para>
      Mentioned earlier in <xref linkend="evalwhere">, in today's free
      software community, announcements of your project on freshmeat
     <para>
      Mentioned earlier in <xref linkend="evalwhere">, in today's free
      software community, announcements of your project on freshmeat

-     are almost more important than announcements on mailing list
-     announcements.
+     are almost more important than announcements on mailing lists.

     </para>
 
     <para>
     </para>
 
     <para>

-     Visit the <ulink url="http://freshmeat.net">freshmeat
+     Visit the <ulink url="http://freshmeat.net">freshmeat.net

      website</ulink> or their <ulink
      url="http://freshmeat.net/add-project/">submit project
      website</ulink> or their <ulink
      url="http://freshmeat.net/add-project/">submit project

-     page</ulink> to post your project on their site and in their
+     page</ulink> to post your project onto their site and into their

      database. In addition to a large website, freshmeat provides a
      daily newsletter that highlights all the days releases and
      database. In addition to a large website, freshmeat provides a
      daily newsletter that highlights all the days releases and

-     reaches a huge audience (I skim it every night for any
+     reaches a huge audience (I personally skim it every night for any

      interesting new releases).
     </para>
      interesting new releases).
     </para>

-
-    <para>
-     Once you've finished this...
-    </para>
-
-    <para>
-     Congratulations. You've now the maintainer of an active free
-     software project. Good luck and feel free to stay in touch with
-     me about your experiences. I'd love to incorporate them into this
-     HOWTO.
-    </para>

    </sect3>
   </sect2>
 </sect1>
 
    </sect3>
   </sect2>
 </sect1>
 

+ <bibliography>
+
+  <bibliodiv>
+   <title>Printed Books</title>
+
+   <biblioentry>
+    <biblioset>
+     <author>
+      <surname>Fogel</surname>
+      <firstname>Karl</firstname>
+     </author>
+     
+     <title>Open Source Development with CVS</title>
+     
+     <publisher>
+      <publishername>Coriolois Open Press</publishername>
+     </publisher>
+     <pubdate>1999</pubdate>
+
+     <isbn>1-57610-490-7</isbn>
+
+     <abstract>
+      <para>
+       Fogel's <quote>guide to using CVS in the free software
+       world</quote> is much more than its subitle. In the publisher's
+       own words: <quote><emphasis>Open Source Development with
+       CVS</emphasis> is one of the first books available that teaches
+       you development and implementation of Open Source
+       software.</quote> It also includes the best reference and
+       tutorial to CVS I have ever seen. It is the book that was
+       <emphasis>so good</emphasis> that it prompted me to write this
+       HOWTO because I thought the role it tried to serve was so
+       important and useful. Please check it or buy it if you can and
+       are seriously interested in running a free software project.
+      </para>
+     </abstract>
+    </biblioset>
+   </biblioentry>
+
+   <biblioentry
+    <biblioset>
+     <author>
+      <surname>Lessig</surname>
+      <firstname>Lawrence</firstname>
+     </author>
+
+     <title>Code and Other Laws of Cyberspace</title>
+     
+     <publisher>
+      <publishername>Basic Books</publishername>
+     </publisher>
+     <pubdate>2000</pubdate>
+     
+     <isbn>0-465-03913-8</isbn>
+
+     <abstract>
+      <para>
+       While it only briefly talks about free software (and does it by
+       tiptoeing around the free software/open source issue with the
+       spineless use of the term <quote>open code</quote> that only a
+       laywer could coin), Lessig's book is brilliant. Written by a
+       lawyer, it talks about how regulation on the Internet is not
+       done with law, but with the code itself and how the nature of
+       the code will determine the nature of future freedoms. In
+       addition to being a quick and enjoyable read, it gives some
+       cool history and describes how we <emphasis>need</emphasis>
+       free software in a way more powerfully than anything I've read
+       outside of <ulink
+       url="http://www.gnu.org/philosophy/right-to-read.html">RMS's
+       <quote>Right to Read.</quote></ulink>
+      </para>
+     </abstract>
+    </biblioset>
+   </biblioentry>
+   
+   <biblioentry>
+    <biblioset>
+     <author>
+      <surname>Raymond</surname>
+      <firstname>Eric</firstname>
+     </author>
+     
+     <title>The Cathedral and the Bazaar</title>
+     <subtitle>Musings on Linux and Open Source by an Accidental Revolutionary</subtitle>
+     
+     <publisher>
+      <publishername>O'Reilly</publishername>
+     </publisher>
+     <pubdate>1999</pubdate>
+    
+     <isbn>1-56592-724-9</isbn>
+     <abstract>
+      <para>
+       Although I have to honestly say that I am not the ESR fan that
+       I used to be, this book proved invaluable in getting me where I
+       am today. The essay that gives the book its title does a good
+       job of sketching the free software process and does an an
+       amazing job of making an argument for free software/open source
+       development as a road to better software. The rest of the book
+       has other of ESR's articles, which for the most part are posted
+       on his website. Still, it's nice thing to own in hard copy and
+       something that every free software/open source hacker should
+       read.
+      </para>
+     </abstract>
+    </biblioset>
+   </biblioentry>
+  </bibliodiv>
+
+  <bibliodiv>
+   <title>Web-Accessable Resources</title>
+
+   <para>
+    This is a list of the web resources pertaining to this HOWTO that
+    I've found most helpful in compiling this information. If you know
+    of others that would help, please don't hesitate to email me at
+    <email>mako@debian.org</email> and we can look into getting it
+    added to the list and represented in the HOWTO.
+   </para>
+
+   <para>
+    I'd recommend that any free software developer (or potential one)
+    skim through these sites becaue they have each have a lot to say.
+   </para>
+
+   <biblioentry>
+    <biblioset>
+     <author>
+      <surname>Manley</surname>
+      <firstname>Montey</firstname>
+     </author>
+     
+     <title><ulink
+     url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing
+     Projects the Open Source Way</ulink></title>
+     
+     <publisher>
+      <publishername><ulink
+      url="http://www.linuxprogramming.com">Linux
+      Programming</ulink></publishername>
+     </publisher>
+     <pubdate>Oct 31, 2000</pubdate>
+
+     <abstract>
+      <para>
+       In one of the better articles on the subject that I've read,
+       Monty sums up some of the major points I touch on including:
+       starting a project, testing, documenation, organizing a team and
+       leadership, and several other topics. While more opiniated that
+       I try to be, I think its an important article that I found very
+       helpful in writing this HOWTO. I've tried to cite him in
+       the places where I borrowed from him most.
+      </para>
+
+      <para>
+       I have problems much of this piece and I recommend you read
+       <xref linkend="krawitz"> at the same time you read Monty's
+       article for a good critique.
+      </para>
+     </abstract>
+    </biblioset>
+   </biblioentry>
+
+   <biblioentry>
+    <biblioset>
+     <author>
+      <surname>Gabriel</surname>
+      <firstname>Richard</firstname>
+     </author>
+     
+     <title><ulink
+     url="http://www.jwz.org/doc/worse-is-better.html">The Rise of
+     <quote>Worse is Better</quote></ulink></title>
+
+     <abstract>
+      <para>
+       A well written article although I think the title may have
+       confused as many people as the rest of the essay helped. It
+       offers a good description of how to design programs that will
+       succeed and stay maintainable as they grow.
+      </para>
+     </abstract>
+    </biblioset>
+   </biblioentry>
+  </bibliodiv>
+
+  <bibliodiv>
+   <title>Advogato Articles</title>
+
+   <para>
+    I've found that one of the best resources that any free software
+    developer has at his or her disposal is Advogato.org. If you haven't
+    yet had a chance to visit <ulink url="http://www.advogato.org">the
+    website</ulink>, do.
+   </para>
+
+   <para>
+    I have spent a huge amount of time on advogato and I've gone
+    through and provided links to the articles that I think might be
+    of particular interest to anyone reading this HOWTO. I think that
+    skimming through these links can be helfpul and I promise that if
+    you do, you'll learn a lot. You will learn that my idea of how a
+    free software project should be run is not the
+    <emphasis>only</emphasis> idea. I think that's important.
+   </para>
+
+   <para>
+    If nothing else, there is <emphasis>way</emphasis> more
+    information on that website than I could ever fit into, or
+    reference from this HOWTO. I have listed what I think are the most
+    relavant articles here with short descriptions that I've written.
+   </para>
+
+
+   <biblioentry>
+    <biblioset>
+     <author>
+      <surname>Hindle</surname>
+      <firstname>Stephen</firstname>
+     </author>
+     
+     <title><ulink url="http://www.advogato.org/article/262.html">'Best Practices' for Open Source?</ulink></title>
+     
+     <publisher>
+      <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
+     </publisher>
+     <pubdate>March 21, 2001</pubdate>
+
+     <abstract>
+      <para>
+       Touching mostly on programming practice (as most articles on
+       the subject usually do), the article talks a little about
+       project managment (<quote>Use it!</quote>) and a bit about
+       communication within a free software project.
+      </para>
+     </abstract>
+    </biblioset>
+   </biblioentry>
+
+   <biblioentry>
+    <biblioset>
+     <author>
+      <surname>Cohen</surname>
+      <firstname>Bram</firstname>
+     </author>
+     
+     <title><ulink
+     url="http://www.advogato.org/article/258.html"></ulink>How to
+     Write Maintainable Code</title>
+     
+     <publisher>
+      <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
+     </publisher>
+     <pubdate>March 15, 2001</pubdate>
+     
+     <abstract>
+      <para>
+       This article touches upon the "writing maintainable code"
+       discussion that I try hard to avoid in my HOWTO. It's one of
+       the better (and most diplomatic) articles on the subject that
+       I've found.
+      </para>
+     </abstract>
+    </biblioset>
+   </biblioentry>
+   <biblioentry id="krawitz">
+    <biblioset>
+     <author>
+      <surname>Krawitz</surname>
+      <firstname>Robert</firstname>
+     </author>
+     
+     <title><ulink url="http://www.advogato.org/article/196.html">Free
+     Source Project Management</ulink></title>
+     
+     <publisher>
+      <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
+     </publisher>
+     <pubdate>November 4, 2000</pubdate>
+    
+     <abstract>
+      <para>
+       This article made me happy because it challenged many of the
+       problems that I had with Monty's article on <ulink
+       url="http://www.linuxprogramming.com">LinuxProgramming</ulink>. The
+       author argues that Monty calls simply for the application of
+       old (proprietary software) project management techniques in
+       free software projects instead of working to come up with
+       something new. I found his article to be extremely well thought
+       out and I think it's an essential read for any free software
+       project manager.
+      </para>
+     </abstract>
+    </biblioset>
+   </biblioentry>
+
+   <biblioentry>
+    <biblioset>
+     <author>
+      <surname>Martins</surname>
+      <firstname>Lalo</firstname>
+     </author>
+     
+     <title><ulink url="http://www.advogato.org/article/128.html">Ask
+     the Advogatos: why do Free Software projects
+     fail?</ulink></title>
+     
+     <publisher>
+      <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
+     </publisher>
+     <pubdate>July 20, 2000</pubdate>
+
+     <abstract>
+      <para>
+       While the article is little more than a question, reading the
+       answers to this question offered by advogato's readers can
+       help. In a lot of ways, this HOWTO acts as my answer to the
+       questions posed in this article but there are others, many of
+       which might take issue with whats is in this HOWTO. It's worth
+       checking out.
+      </para>
+     </abstract>
+    </biblioset>
+   </biblioentry>
+
+   <biblioentry>
+    <biblioset>
+     <author>
+      <surname>Burley</surname>
+      <firstname>David</firstname>
+     </author>
+     
+     <title><ulink
+     url="http://www.advogato.org/article/107.html">In-Roads to Free
+     Software Development</ulink></title>
+     
+     <publisher>
+      <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
+     </publisher>
+     <pubdate>June 14, 2000</pubdate>
+    
+     <abstract>
+      <para>
+       This document was written as a response to <ulink
+       url="http://www.advogato.org/article/72.html">another advogato
+       article</ulink>. Although not about running a project, this
+       describes some of the ways that you can get started with free
+       software development without starting a project. I think this
+       is an important article. If you are interested in becoming
+       involved with free software, this article showcases some of the
+       ways that you can do this without actually starting a project
+       (something that I hope this HOWTO has demonstrated is not to be
+       taken lightly).
+      </para>
+     </abstract>
+    </biblioset>
+   </biblioentry>
+
+   <biblioentry>
+    <biblioset>
+     <author>
+      <surname>Moorman</surname>
+      <firstname>Jacob</firstname>
+     </author>
+     
+     <title><ulink
+     url="http://www.advogato.org/article/72.html"></ulink>Importance
+     of Non-Developer Supporters in Free Software</title>
+     
+     <publisher>
+      <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
+     </publisher>
+     <pubdate>April 16, 2000</pubdate>
+    
+     <abstract>
+      <para>
+       Moorman's is a short article but it brings up some good
+       points. The comment reminding developers to thank their testers
+       and end-users is invaluable and oft-forgotten.
+      </para>
+     </abstract>
+    </biblioset>
+   </biblioentry>
+
+   <biblioentry>
+    <biblioset>
+     <author>
+      <surname>Orchard</surname>
+      <firstname>Leslie</firstname>
+     </author>
+     
+     <title><ulink url="http://www.advogato.org/article/67.html">On
+     Naming an Open Source Project</ulink></title>
+     
+     <publisher>
+      <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
+     </publisher>
+     <pubdate>April 12, 2000</pubdate>
+    
+     <abstract>
+      <para>
+       I didn't even have a section on project naming in this HOWTO
+       (See <xref linkend="naming">) until Leslie Orchard's article
+       reminded me of it. Thanks to Leslie for writing this article!
+      </para>
+     </abstract>
+    </biblioset>
+   </biblioentry>
+
+   <biblioentry>
+    <biblioset>
+     <author>
+      <surname>Allen</surname>
+      <firstname>David</firstname>
+     </author>
+     
+     <title><ulink url="http://www.advogato.org/article/40.html">Version Numbering Madness</ulink></title>
+     
+     <publisher>
+      <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
+     </publisher>
+     <pubdate>Februrary 28, 2000</pubdate>
+    
+     <abstract>
+      <para>
+       In this article, David Allen challengs the whole
+       <quote>Major.Minor.Patch</quote> version numbering scheme. Its
+       good to read this as you read <xref
+       linkend="chooseversioning">. I liked the article and it
+       describes some of the projects that I bring up in my discussion
+       of verion numbering.
+      </para>
+     </abstract>
+    </biblioset>
+   </biblioentry>
+
+  </bibliodiv>
+ </bibliography>
+
+<!--  
+     The GNU Free Documentation License 1.1 in DocBook
+     Markup by Eric Baudais <baudais@okstate.edu>
+     Maintained by the GNOME Documentation Project
+     http://developer.gnome.org/projects/gdp
+     Version: 1.0.1
+     Last Modified: Nov 16, 2000
+-->
+
+<appendix id="fdl">
+  <docinfo>
+    <releaseinfo>
+      Version 1.1, March 2000
+    </releaseinfo>
+    <copyright>
+      <year>2000</year><holder>Free Software Foundation, Inc.</holder>
+    </copyright>
+    <legalnotice id="fdl-legalnotice">
+      <para>
+       <address>Free Software Foundation, Inc. <street>59 Temple Place, 
+        Suite 330</street>, <city>Boston</city>, <state>MA</state>  
+        <postcode>02111-1307</postcode>  <country>USA</country></address> 
+       Everyone is permitted to copy and distribute verbatim copies of this 
+        license document, but changing it is not allowed.
+      </para>
+    </legalnotice>
+  </docinfo>
+  <title>GNU Free Documentation License</title>
+
+  <sect1 id="fdl-preamble">
+    <title>0. PREAMBLE</title>
+    <para>
+      The purpose of this License is to make a manual, textbook, or
+      other written document <quote>free</quote> in the sense of
+      freedom: to assure everyone the effective freedom to copy and
+      redistribute it, with or without modifying it, either
+      commercially or noncommercially. Secondarily, this License
+      preserves for the author and publisher a way to get credit for
+      their work, while not being considered responsible for
+      modifications made by others.
+    </para>
+    
+    <para>
+      This License is a kind of <quote>copyleft</quote>, which means
+      that derivative works of the document must themselves be free in
+      the same sense. It complements the GNU General Public License,
+      which is a copyleft license designed for free software.
+    </para>
+    
+    <para>
+      We have designed this License in order to use it for manuals for
+      free software, because free software needs free documentation: a
+      free program should come with manuals providing the same
+      freedoms that the software does. But this License is not limited
+      to software manuals; it can be used for any textual work,
+      regardless of subject matter or whether it is published as a
+      printed book. We recommend this License principally for works
+      whose purpose is instruction or reference.
+    </para>
+  </sect1>
+  <sect1 id="fdl-section1">
+    <title>1. APPLICABILITY AND DEFINITIONS</title>
+    <para id="fdl-document">
+      This License applies to any manual or other work that contains a
+      notice placed by the copyright holder saying it can be
+      distributed under the terms of this License. The
+      <quote>Document</quote>, below, refers to any such manual or
+      work. Any member of the public is a licensee, and is addressed
+      as <quote>you</quote>.
+    </para>
+    
+    <para id="fdl-modified">
+      A <quote>Modified Version</quote> of the Document means any work
+      containing the Document or a portion of it, either copied
+      verbatim, or with modifications and/or translated into another
+      language.
+    </para>
+       
+    <para id="fdl-secondary">
+      A <quote>Secondary Section</quote> is a named appendix or a
+      front-matter section of the <link
+      linkend="fdl-document">Document</link> that deals exclusively
+      with the relationship of the publishers or authors of the
+      Document to the Document's overall subject (or to related
+      matters) and contains nothing that could fall directly within
+      that overall subject. (For example, if the Document is in part a
+      textbook of mathematics, a Secondary Section may not explain any
+      mathematics.)  The relationship could be a matter of historical
+      connection with the subject or with related matters, or of
+      legal, commercial, philosophical, ethical or political position
+      regarding them.
+    </para>
+
+    <para id="fdl-invariant">
+      The <quote>Invariant Sections</quote> are certain <link
+      linkend="fdl-secondary"> Secondary Sections</link> whose titles
+      are designated, as being those of Invariant Sections, in the
+      notice that says that the <link
+      linkend="fdl-document">Document</link> is released under this
+      License.
+    </para>
+    
+    <para id="fdl-cover-texts">
+      The <quote>Cover Texts</quote> are certain short passages of
+      text that are listed, as Front-Cover Texts or Back-Cover Texts,
+      in the notice that says that the <link
+      linkend="fdl-document">Document</link> is released under this
+      License.
+    </para>
+       
+    <para id="fdl-transparent">
+      A <quote>Transparent</quote> copy of the <link
+      linkend="fdl-document"> Document</link> means a machine-readable
+      copy, represented in a format whose specification is available
+      to the general public, whose contents can be viewed and edited
+      directly and straightforwardly with generic text editors or (for
+      images composed of pixels) generic paint programs or (for
+      drawings) some widely available drawing editor, and that is
+      suitable for input to text formatters or for automatic
+      translation to a variety of formats suitable for input to text
+      formatters. A copy made in an otherwise Transparent file format
+      whose markup has been designed to thwart or discourage
+      subsequent modification by readers is not Transparent.  A copy
+      that is not <quote>Transparent</quote> is called
+      <quote>Opaque</quote>.
+    </para>
+    
+    <para>
+      Examples of suitable formats for Transparent copies include
+      plain ASCII without markup, Texinfo input format, LaTeX input
+      format, SGML or XML using a publicly available DTD, and
+      standard-conforming simple HTML designed for human
+      modification. Opaque formats include PostScript, PDF,
+      proprietary formats that can be read and edited only by
+      proprietary word processors, SGML or XML for which the DTD
+      and/or processing tools are not generally available, and the
+      machine-generated HTML produced by some word processors for
+      output purposes only.
+    </para>
+    
+    <para id="fdl-title-page">
+      The <quote>Title Page</quote> means, for a printed book, the
+      title page itself, plus such following pages as are needed to
+      hold, legibly, the material this License requires to appear in
+      the title page. For works in formats which do not have any title
+      page as such, <quote>Title Page</quote> means the text near the
+      most prominent appearance of the work's title, preceding the
+      beginning of the body of the text.
+    </para>
+  </sect1>
+    
+  <sect1 id="fdl-section2">
+    <title>2. VERBATIM COPYING</title>
+    <para>
+      You may copy and distribute the <link
+      linkend="fdl-document">Document</link> in any medium, either
+      commercially or noncommercially, provided that this License, the
+      copyright notices, and the license notice saying this License
+      applies to the Document are reproduced in all copies, and that
+      you add no other conditions whatsoever to those of this
+      License. You may not use technical measures to obstruct or
+      control the reading or further copying of the copies you make or
+      distribute. However, you may accept compensation in exchange for
+      copies. If you distribute a large enough number of copies you
+      must also follow the conditions in <link
+      linkend="fdl-section3">section 3</link>.
+    </para>
+    
+    <para>
+      You may also lend copies, under the same conditions stated
+      above, and you may publicly display copies.
+    </para>
+    </sect1>
+    
+  <sect1 id="fdl-section3">
+    <title>3. COPYING IN QUANTITY</title>
+    <para>
+      If you publish printed copies of the <link
+      linkend="fdl-document">Document</link> numbering more than 100,
+      and the Document's license notice requires <link
+      linkend="fdl-cover-texts">Cover Texts</link>, you must enclose
+      the copies in covers that carry, clearly and legibly, all these
+      Cover Texts: Front-Cover Texts on the front cover, and
+      Back-Cover Texts on the back cover. Both covers must also
+      clearly and legibly identify you as the publisher of these
+      copies. The front cover must present the full title with all
+      words of the title equally prominent and visible. You may add
+      other material on the covers in addition. Copying with changes
+      limited to the covers, as long as they preserve the title of the
+      <link linkend="fdl-document">Document</link> and satisfy these
+      conditions, can be treated as verbatim copying in other
+      respects.
+    </para>
+    
+    <para>
+      If the required texts for either cover are too voluminous to fit
+      legibly, you should put the first ones listed (as many as fit
+      reasonably) on the actual cover, and continue the rest onto
+      adjacent pages.
+    </para>
+    
+    <para>
+      If you publish or distribute <link
+      linkend="fdl-transparent">Opaque</link> copies of the <link
+      linkend="fdl-document">Document</link> numbering more than 100,
+      you must either include a machine-readable <link
+      linkend="fdl-transparent">Transparent</link> copy along with
+      each Opaque copy, or state in or with each Opaque copy a
+      publicly-accessible computer-network location containing a
+      complete Transparent copy of the Document, free of added
+      material, which the general network-using public has access to
+      download anonymously at no charge using public-standard network
+      protocols. If you use the latter option, you must take
+      reasonably prudent steps, when you begin distribution of Opaque
+      copies in quantity, to ensure that this Transparent copy will
+      remain thus accessible at the stated location until at least one
+      year after the last time you distribute an Opaque copy (directly
+      or through your agents or retailers) of that edition to the
+      public.
+    </para>
+    
+    <para>
+      It is requested, but not required, that you contact the authors
+      of the <link linkend="fdl-document">Document</link> well before
+      redistributing any large number of copies, to give them a chance
+      to provide you with an updated version of the Document.
+    </para>
+    </sect1>
+    
+  <sect1 id="fdl-section4">
+    <title>4. MODIFICATIONS</title>
+    <para>
+      You may copy and distribute a <link
+      linkend="fdl-modified">Modified Version</link> of the <link
+      linkend="fdl-document">Document</link> under the conditions of
+      sections <link linkend="fdl-section2">2</link> and <link
+      linkend="fdl-section3">3</link> above, provided that you release
+      the Modified Version under precisely this License, with the
+      Modified Version filling the role of the Document, thus
+      licensing distribution and modification of the Modified Version
+      to whoever possesses a copy of it. In addition, you must do
+      these things in the Modified Version:
+    </para>
+    
+    <itemizedlist mark="opencircle">
+      <listitem>
+       <formalpara>
+         <title>A</title>
+         <para>
+           Use in the <link linkend="fdl-title-page">Title
+           Page</link> (and on the covers, if any) a title distinct
+           from that of the <link
+           linkend="fdl-document">Document</link>, and from those of
+           previous versions (which should, if there were any, be
+           listed in the History section of the Document). You may
+           use the same title as a previous version if the original
+           publisher of that version gives permission.
+         </para>
+       </formalpara>
+      </listitem>
+      
+      <listitem>
+       <formalpara>
+         <title>B</title>
+         <para>
+           List on the <link linkend="fdl-title-page">Title
+           Page</link>, as authors, one or more persons or entities
+           responsible for authorship of the modifications in the
+           <link linkend="fdl-modified">Modified Version</link>,
+           together with at least five of the principal authors of
+           the <link linkend="fdl-document">Document</link> (all of
+           its principal authors, if it has less than five).
+         </para>
+       </formalpara>
+      </listitem>
+      
+      <listitem>
+       <formalpara>
+         <title>C</title>
+         <para>
+           State on the <link linkend="fdl-title-page">Title
+           Page</link> the name of the publisher of the <link
+           linkend="fdl-modified">Modified Version</link>, as the
+           publisher.
+         </para>
+       </formalpara>
+      </listitem>
+      
+      <listitem>
+       <formalpara>
+         <title>D</title>
+         <para>
+           Preserve all the copyright notices of the <link
+           linkend="fdl-document">Document</link>.
+         </para>
+       </formalpara>
+      </listitem>
+      
+      <listitem>
+       <formalpara>
+         <title>E</title>
+         <para>
+           Add an appropriate copyright notice for your modifications
+           adjacent to the other copyright notices.
+         </para>
+       </formalpara>
+      </listitem>
+      
+      <listitem>
+       <formalpara>
+         <title>F</title>
+         <para>
+           Include, immediately after the copyright notices, a
+           license notice giving the public permission to use the
+           <link linkend="fdl-modified">Modified Version</link> under
+           the terms of this License, in the form shown in the
+           Addendum below.
+         </para>
+       </formalpara>
+      </listitem>
+      
+      <listitem>
+       <formalpara>
+         <title>G</title>
+         <para>
+           Preserve in that license notice the full lists of <link
+           linkend="fdl-invariant"> Invariant Sections</link> and
+           required <link linkend="fdl-cover-texts">Cover
+           Texts</link> given in the <link
+           linkend="fdl-document">Document's</link> license notice.
+         </para>
+       </formalpara>
+      </listitem>
+      
+      <listitem>
+       <formalpara>
+         <title>H</title>
+         <para>
+           Include an unaltered copy of this License.
+         </para>
+       </formalpara>
+      </listitem>
+      
+      <listitem>
+       <formalpara>
+         <title>I</title>
+         <para>
+           Preserve the section entitled <quote>History</quote>, and
+           its title, and add to it an item stating at least the
+           title, year, new authors, and publisher of the <link
+           linkend="fdl-modified">Modified Version </link>as given on
+           the <link linkend="fdl-title-page">Title Page</link>.  If
+           there is no section entitled <quote>History</quote> in the
+           <link linkend="fdl-document">Document</link>, create one
+           stating the title, year, authors, and publisher of the
+           Document as given on its Title Page, then add an item
+           describing the Modified Version as stated in the previous
+           sentence.
+         </para>
+       </formalpara>
+      </listitem>
+      
+      <listitem>
+       <formalpara>
+         <title>J</title>
+         <para>
+           Preserve the network location, if any, given in the <link
+           linkend="fdl-document">Document</link> for public access
+           to a <link linkend="fdl-transparent">Transparent</link>
+           copy of the Document, and likewise the network locations
+           given in the Document for previous versions it was based
+           on. These may be placed in the <quote>History</quote>
+           section.  You may omit a network location for a work that
+           was published at least four years before the Document
+           itself, or if the original publisher of the version it
+           refers to gives permission.
+         </para>
+       </formalpara>
+      </listitem>
+      
+      <listitem>
+       <formalpara>
+         <title>K</title>
+         <para>
+           In any section entitled <quote>Acknowledgements</quote> or
+           <quote>Dedications</quote>, preserve the section's title,
+           and preserve in the section all the substance and tone of
+           each of the contributor acknowledgements and/or
+           dedications given therein.
+         </para>
+       </formalpara>
+      </listitem>
+      
+      <listitem>
+       <formalpara>
+         <title>L</title>
+         <para>
+           Preserve all the <link linkend="fdl-invariant">Invariant
+           Sections</link> of the <link
+           linkend="fdl-document">Document</link>, unaltered in their
+           text and in their titles.  Section numbers or the
+           equivalent are not considered part of the section titles.
+         </para>
+       </formalpara>
+      </listitem>
+      
+      <listitem>
+       <formalpara>
+         <title>M</title>
+         <para>
+           Delete any section entitled
+           <quote>Endorsements</quote>. Such a section may not be
+           included in the <link linkend="fdl-modified">Modified
+           Version</link>.
+         </para>
+       </formalpara>
+      </listitem>
+      
+      <listitem>
+       <formalpara>
+         <title>N</title>
+         <para>
+           Do not retitle any existing section as
+           <quote>Endorsements</quote> or to conflict in title with
+           any <link linkend="fdl-invariant">Invariant
+           Section</link>.
+         </para>
+       </formalpara>
+      </listitem>
+    </itemizedlist>
+    
+    <para>
+      If the <link linkend="fdl-modified">Modified Version</link>
+      includes new front-matter sections or appendices that qualify as
+      <link linkend="fdl-secondary">Secondary Sections</link> and
+      contain no material copied from the Document, you may at your
+      option designate some or all of these sections as invariant. To
+      do this, add their titles to the list of <link
+      linkend="fdl-invariant">Invariant Sections</link> in the
+      Modified Version's license notice.  These titles must be
+      distinct from any other section titles.
+    </para>
+    
+    <para>
+      You may add a section entitled <quote>Endorsements</quote>,
+      provided it contains nothing but endorsements of your <link
+      linkend="fdl-modified">Modified Version</link> by various
+      parties--for example, statements of peer review or that the text
+      has been approved by an organization as the authoritative
+      definition of a standard.
+    </para>
+    
+    <para>
+      You may add a passage of up to five words as a <link
+      linkend="fdl-cover-texts">Front-Cover Text</link>, and a passage
+      of up to 25 words as a <link
+      linkend="fdl-cover-texts">Back-Cover Text</link>, to the end of
+      the list of <link linkend="fdl-cover-texts">Cover Texts</link>
+      in the <link linkend="fdl-modified">Modified Version</link>.
+      Only one passage of Front-Cover Text and one of Back-Cover Text
+      may be added by (or through arrangements made by) any one
+      entity. If the <link linkend="fdl-document">Document</link>
+      already includes a cover text for the same cover, previously
+      added by you or by arrangement made by the same entity you are
+      acting on behalf of, you may not add another; but you may
+      replace the old one, on explicit permission from the previous
+      publisher that added the old one.
+    </para>
+    
+    <para>
+      The author(s) and publisher(s) of the <link
+      linkend="fdl-document">Document</link> do not by this License
+      give permission to use their names for publicity for or to
+      assert or imply endorsement of any <link
+      linkend="fdl-modified">Modified Version </link>.
+    </para>
+  </sect1>
+    
+  <sect1 id="fdl-section5">
+    <title>5. COMBINING DOCUMENTS</title>
+    <para>
+      You may combine the <link linkend="fdl-document">Document</link>
+      with other documents released under this License, under the
+      terms defined in <link linkend="fdl-section4">section 4</link>
+      above for modified versions, provided that you include in the
+      combination all of the <link linkend="fdl-invariant">Invariant
+      Sections</link> of all of the original documents, unmodified,
+      and list them all as Invariant Sections of your combined work in
+      its license notice.
+    </para>
+    
+    <para>
+      The combined work need only contain one copy of this License,
+      and multiple identical <link linkend="fdl-invariant">Invariant
+      Sections</link> may be replaced with a single copy. If there are
+      multiple Invariant Sections with the same name but different
+      contents, make the title of each such section unique by adding
+      at the end of it, in parentheses, the name of the original
+      author or publisher of that section if known, or else a unique
+      number. Make the same adjustment to the section titles in the
+      list of Invariant Sections in the license notice of the combined
+      work.
+    </para>
+    
+    <para>
+      In the combination, you must combine any sections entitled
+      <quote>History</quote> in the various original documents,
+      forming one section entitled <quote>History</quote>; likewise
+      combine any sections entitled <quote>Acknowledgements</quote>,
+      and any sections entitled <quote>Dedications</quote>.  You must
+      delete all sections entitled <quote>Endorsements.</quote>
+    </para>
+    </sect1>
+    
+  <sect1 id="fdl-section6">
+    <title>6. COLLECTIONS OF DOCUMENTS</title>
+    <para>
+      You may make a collection consisting of the <link
+      linkend="fdl-document">Document</link> and other documents
+      released under this License, and replace the individual copies
+      of this License in the various documents with a single copy that
+      is included in the collection, provided that you follow the
+      rules of this License for verbatim copying of each of the
+      documents in all other respects.
+    </para>
+    
+    <para>
+      You may extract a single document from such a collection, and
+      dispbibute it individually under this License, provided you
+      insert a copy of this License into the extracted document, and
+      follow this License in all other respects regarding verbatim
+      copying of that document.
+    </para>
+    </sect1>
+    
+  <sect1 id="fdl-section7">
+    <title>7. AGGREGATION WITH INDEPENDENT WORKS</title>
+    <para>
+      A compilation of the <link
+      linkend="fdl-document">Document</link> or its derivatives with
+      other separate and independent documents or works, in or on a
+      volume of a storage or distribution medium, does not as a whole
+      count as a <link linkend="fdl-modified">Modified Version</link>
+      of the Document, provided no compilation copyright is claimed
+      for the compilation.  Such a compilation is called an
+      <quote>aggregate</quote>, and this License does not apply to the
+      other self-contained works thus compiled with the Document , on
+      account of their being thus compiled, if they are not themselves
+      derivative works of the Document.  If the <link
+      linkend="fdl-cover-texts">Cover Text</link> requirement of <link
+      linkend="fdl-section3">section 3</link> is applicable to these
+      copies of the Document, then if the Document is less than one
+      quarter of the entire aggregate, the Document's Cover Texts may
+      be placed on covers that surround only the Document within the
+      aggregate. Otherwise they must appear on covers around the whole
+      aggregate.
+    </para>
+    </sect1>
+    
+  <sect1 id="fdl-section8">
+    <title>8. TRANSLATION</title>
+    <para>
+      Translation is considered a kind of modification, so you may
+      distribute translations of the <link
+      linkend="fdl-document">Document</link> under the terms of <link
+      linkend="fdl-section4">section 4</link>. Replacing <link
+      linkend="fdl-invariant"> Invariant Sections</link> with
+      translations requires special permission from their copyright
+      holders, but you may include translations of some or all
+      Invariant Sections in addition to the original versions of these
+      Invariant Sections. You may include a translation of this
+      License provided that you also include the original English
+      version of this License. In case of a disagreement between the
+      translation and the original English version of this License,
+      the original English version will prevail.
+    </para>
+    </sect1>
+    
+  <sect1 id="fdl-section9">
+    <title>9. TERMINATION</title>
+    <para>
+      You may not copy, modify, sublicense, or distribute the <link
+      linkend="fdl-document">Document</link> except as expressly
+      provided for under this License. Any other attempt to copy,
+      modify, sublicense or distribute the Document is void, and will
+      automatically terminate your rights under this License. However,
+      parties who have received copies, or rights, from you under this
+      License will not have their licenses terminated so long as such
+      parties remain in full compliance.
+    </para>
+    </sect1>
+    
+  <sect1 id="fdl-section10">
+    <title>10. FUTURE REVISIONS OF THIS LICENSE</title>
+    <para>
+      The <ulink type="http"
+      url="http://www.gnu.org/fsf/fsf.html">Free Software
+      Foundation</ulink> may publish new, revised versions of the GNU
+      Free Documentation License from time to time. Such new versions
+      will be similar in spirit to the present version, but may differ
+      in detail to address new problems or concerns. See <ulink
+      type="http"
+      url="http://www.gnu.org/copyleft">http://www.gnu.org/copyleft/</ulink>.
+    </para>
+    
+    <para>
+      Each version of the License is given a distinguishing version
+      number. If the <link linkend="fdl-document">Document</link>
+      specifies that a particular numbered version of this License
+      <quote>or any later version</quote> applies to it, you have the
+      option of following the terms and conditions either of that
+      specified version or of any later version that has been
+      published (not as a draft) by the Free Software Foundation. If
+      the Document does not specify a version number of this License,
+      you may choose any version ever published (not as a draft) by
+      the Free Software Foundation.
+    </para>
+  </sect1>
+
+  <sect1 id="fdl-using">
+    <title>Addendum</title>
+    <para>
+      To use this License in a document you have written, include a copy of
+      the License in the document and put the following copyright and
+      license notices just after the title page:
+    </para>
+    
+    <blockquote>
+      <para>
+       Copyright &copy; YEAR YOUR NAME.
+      </para>
+      <para>
+       Permission is granted to copy, distribute and/or modify this
+       document under the terms of the GNU Free Documentation
+       License, Version 1.1 or any later version published by the
+       Free Software Foundation; with the <link
+       linkend="fdl-invariant">Invariant Sections</link> being LIST
+       THEIR TITLES, with the <link
+       linkend="fdl-cover-texts">Front-Cover Texts</link> being LIST,
+       and with the <link linkend="fdl-cover-texts">Back-Cover
+       Texts</link> being LIST.  A copy of the license is included in
+       the section entitled <quote>GNU Free Documentation
+       License</quote>.
+      </para>
+    </blockquote>
+      
+    <para>
+      If you have no <link linkend="fdl-invariant">Invariant
+      Sections</link>, write <quote>with no Invariant Sections</quote>
+      instead of saying which ones are invariant.  If you have no
+      <link linkend="fdl-cover-texts">Front-Cover Texts</link>, write
+      <quote>no Front-Cover Texts</quote> instead of
+      <quote>Front-Cover Texts being LIST</quote>; likewise for <link
+      linkend="fdl-cover-texts">Back-Cover Texts</link>.
+    </para>
+    
+    <para>
+      If your document contains nontrivial examples of program code,
+      we recommend releasing these examples in parallel under your
+      choice of free software license, such as the <ulink type="http"
+      url="http://www.gnu.org/copyleft/gpl.html"> GNU General Public
+      License</ulink>, to permit their use in free software.
+    </para>
+  </sect1>
+</appendix>  
+

 </article>
 
 <!-- Keep this comment at the end of the file
 </article>
 
 <!-- Keep this comment at the end of the file