added information into the bibliography on the cvs book's new version

[fspm_howto] / FreeSoftwareProjectManagementHOWTO.sgml

diff --git a/FreeSoftwareProjectManagementHOWTO.sgml b/FreeSoftwareProjectManagementHOWTO.sgml
index cf8747365a054230e12072d8f546c80b0b5aab60..65317f4bb055c2ee66017917beb7a21f49448338 100644 (file)
--- a/FreeSoftwareProjectManagementHOWTO.sgml
+++ b/FreeSoftwareProjectManagementHOWTO.sgml
@@ -19,6 +19,12 @@
   </author>
 
   <revhistory>
   </author>
 
   <revhistory>

+   <revision>
+    <revnumber>v0.3.2</revnumber>
+    <date>15 April 2002</date>
+   <authorinitials>bch</authorinitials>
+   </revision>
+

    <revision>
     <revnumber>v0.3.1</revnumber>
     <date>18 June 2001</date>
    <revision>
     <revnumber>v0.3.1</revnumber>
     <date>18 June 2001</date>


@@ -124,7 +130,7 @@
    <title>Copyright Information</title>
 
    <para>
    <title>Copyright Information</title>
 
    <para>

-    This document is copyrighted (c) 2000 Benjamin (Mako) Hill and is
+    This document is copyrighted (c) 2000 Benjamin "Mako" Hill and is

     distributed under the terms of the <citetitle>GNU Free
     Documentation License</citetitle>.
    </para>
     distributed under the terms of the <citetitle>GNU Free
     Documentation License</citetitle>.
    </para>


@@ -239,19 +245,23 @@
     In this version I have the pleasure of acknowledging:
    </para>
 
     In this version I have the pleasure of acknowledging:
    </para>
 

-   <para>
-    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>Fellow Debian developer Martin Michlmayr and Vivek
+   Venugopalan who sent me information and links to extremely
+   interesting articles. I've added both to the bibliography and I've
+   added information from each into the HOWTO. Thanks to Andrew Shugg
+   who pointed out several errors in the document. Also, a big thanks
+   to Sung Wook Her (AKA RedBaron) who is doing the first translation
+   of the HOWTO into Korean. I've been happy to see that people have
+   enjoyed and benefited from the HOWTO so far.</para>

 
    <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.
+    Older thanks that I don't want to take out yet include: 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>
    </para>
 
    <para>


@@ -282,7 +292,7 @@
     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
     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
+    importance of Free Software. Additionally, 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
     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


@@ -296,7 +306,7 @@
     Above all, I want to thank <emphasis>Richard Stallman</emphasis>
     for his work at the Free Software Foundation and for never giving
     up. Stallman provides and articulates the philosophical basis that
     Above all, I want to thank <emphasis>Richard Stallman</emphasis>
     for his work at the Free Software Foundation and for never giving
     up. Stallman provides and articulates the philosophical basis that

-    attracts me to free software and that drives me towards writing a
+    attracts me to free software and that drives me toward writing a

     document to make sure it succeeds. RMS can always be emailed at
     <email>rms (at) gnu (dot) org</email>.
    </para>
     document to make sure it succeeds. RMS can always be emailed at
     <email>rms (at) gnu (dot) org</email>.
    </para>


@@ -334,12 +344,13 @@
    </para>
 
    <para>
    </para>
 
    <para>

-    However, this HOWTO is still young and I have to yet to be
-    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
-    hesitate to contact me at: <email>mako@debian.org</email>.
+    I've been contacted by a reader who promises a translation into
+    Korean. However, this HOWTO is still young and other than the
+    promise of Korean, 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 hesitate to
+    contact me at: <email>mako@debian.org</email>.

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


@@ -357,7 +368,7 @@
   <para>
    With very little argument, the beginning is the most difficult
    period in a project's life to do successful free software project
   <para>
    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
+   management. 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.
    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.


@@ -374,7 +385,7 @@
    It is in these dangerous initial moments that anyone working to
    start a free software project must try and strike a balance along
    these lines. One of the most important ways that someone trying to
    It is in these dangerous initial moments that anyone working to
    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
+   start a project can work toward this balance is by establishing a

    solid framework for the development process through some of the
    suggestions mentioned in this section.
   </para>
    solid framework for the development process through some of the
    suggestions mentioned in this section.
   </para>


@@ -388,7 +399,7 @@
    <para>
     If you are reading this document, there's a good chance you
     already have an idea for a project in mind. Chances are also
    <para>
     If you are reading this document, there's a good chance you
     already have an idea for a project in mind. Chances are also

-    pretty good that it fills a percieved gap by doing something that
+    pretty good that it fills a perceived 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.
     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.


@@ -575,7 +586,7 @@
 
      <para>
       For many developers this may be the single most difficult aspect
 
      <para>
       For many developers this may be the single most difficult aspect

-      of free software project managment, but it is an essential one. It is
+      of free software project management, 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
       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


@@ -601,7 +612,7 @@
     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
     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
+    article</ulink>. His article is short and definitely worth looking

     over quickly.
    </para>
 
     over quickly.
    </para>
 


@@ -631,8 +642,8 @@
     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
     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
+    supposedly worth it. While you probably can't afford a company like
+    this, you can afford to learn from their existence and think a

     little bit about the name you are giving your project because it
     <emphasis>does</emphasis> matter.
    </para>
     little bit about the name you are giving your project because it
     <emphasis>does</emphasis> matter.
    </para>


@@ -687,7 +698,12 @@
      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
      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.
+     <acronym>BSD</acronym>, and the Artistic License. As ESR mentions
+     in his his HOWTO<xref linkend="esrhowto">, don't write your own
+     license if at all possible. The three licenses I mention all have
+     long interpretive traditions. They are also definitely free
+     software (and can therefore be distributed as part of Debian and
+     in other places that permit the transfer of free software).

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


@@ -698,8 +714,12 @@
      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>
      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.
+     but sticking with a more well-known license will offer the
+     advantage of immediate recognition and understanding.  Many
+     people write three or four sentences in a COPYING file and assume
+     that they have written a free software license--as my long
+     experience with the debian-legal mailing professes, this is very
+     often not the case.

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


@@ -723,6 +743,21 @@
      some, it is a major drawback.
     </para>
 
      some, it is a major drawback.
     </para>
 

+    <para>
+     Many people write three or four sentences in a COPYING file and
+     assume that they have written a free software license--as my long
+     experience with the debian-legal mailing professes, this is very
+     often not the case. It may not protect you, it may not protect
+     your software, and it may make things very difficult for people
+     that want to use your software but who pay a lot of attention to
+     the subtle legal points of licenses. If you are passionate about
+     a home-brewed license, run it by either people at <ulink
+     url="http://www.opensource.org">OSI</ulink> or the <ulink
+     url="mailto:debian-devel@lists.debian.org">debian-legal mailing
+     list</ulink> first protect yourself from unanticipated
+     side-effects of your license.
+    </para>
+

     <para>
      The three major licenses can be found at the following locations:
     </para>
     <para>
      The three major licenses can be found at the following locations:
     </para>


@@ -766,6 +801,17 @@
     <para>
      <itemizedlist>
      
     <para>
      <itemizedlist>
      

+      <listitem>
+       <para>Make yourself or the FSF the copyright holder for the
+       work. In a few rare cases, you might want to make a sponsoring
+       organization (if it's big and powerful enough) the copyright
+       holder instead. Doing this is as simple as putting the name in
+       the blank when you modify the notice of copyright
+       below. Contrary to popular belief, you don't need to file with
+       any organization. The notice alone is enough to copyright your
+       work.</para>
+      </listitem>
+

       <listitem>
        <para>If at all possible, attach and distribute a full copy of
        the license with the source and binary by including a separate
       <listitem>
        <para>If at all possible, attach and distribute a full copy of
        the license with the source and binary by including a separate


@@ -889,14 +935,14 @@ for details.
     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
     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
+    coherent 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
     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
+    Linux kernel and a 2.4.11, 2.2.12, and 1.2.12 without knowing

     anything about any of the releases.
    </para>
 
     anything about any of the releases.
    </para>
 


@@ -949,7 +995,7 @@ for details.
      <term>Wine version numbering:</term>
      <listitem>
       <para>Because of the unusual nature of wine's development where
      <term>Wine version numbering:</term>
      <listitem>
       <para>Because of the unusual nature of wine's development where

-      the not-emulator is constantly improving but not working towards
+      the not-emulator is constantly improving but not working toward

       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
       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


@@ -979,7 +1025,7 @@ for details.
        <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
        <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
+       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>
        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>


@@ -1192,7 +1238,7 @@ pages for more information and options.
        <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
        <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
+       responsible 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
        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


@@ -1238,23 +1284,67 @@ pages for more information and options.
    <sect3>
     <title>Other documentation hints</title>
 
    <sect3>
     <title>Other documentation hints</title>
 

-    <para>
-     All your documentation should be in plaintext, or, in cases where
-     it is on your website primarily, in HTML. Everyone can cat a
-     file, everyone has a pager, (almost) everyone can render
-     HTML. <emphasis>You are welcome to distribute information in PDF,
-     PostScript, RTF, or any number of other widely used formats but
-     this information must also be available in plaintext or HTML or
-     people will be very angry at you.</emphasis>
-    </para>
+    <itemizedlist>
+     <listitem>
+      <para>
+        All your documentation should be in plaintext, or, in cases
+        where it is on your website primarily, in HTML. Everyone can
+        cat a file, everyone has a pager, (almost) everyone can render
+        HTML. <emphasis>You are welcome to distribute information in
+        PDF, PostScript, RTF, or any number of other widely used
+        formats but this information must also be available in
+        plaintext or HTML or people will be very angry at
+        you.</emphasis> In my opinion, info falls into this category
+        as well. There is plenty of great GNU documentation that
+        people simply don't read because it only in info. And this
+        <emphasis>does</emphasis> make people angry. It's not a
+        question of superior formats; it is a question of
+        accessability and the status quo plays a huge role in this
+        determination.
+      </para>
+     </listitem>
+
+     <listitem>
+      <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>
+     </listitem>
+
+     <listitem>
+      <para>Unless your software is particular to a non-English
+      language (a Japanese language editor for example), please
+      distribute it with English language documentation. If you don't
+      speak English or not not confident in your skills, ask a friend
+      for help. Like it or not, fair or unfair, <emphasis>English is
+      the language of free software</emphasis>. However, this does not
+      mean you should limit your documentation to only English. If you
+      speak another language, distribute translations of documentation
+      with your software if you have the time and energy to do
+      so. They will invariably be useful to someone.</para>
+     </listitem>
+
+     <listitem>
+      <para>
+       Finally, <emphasis>please spell-check your
+       documentation.</emphasis> Misspellings in documentation are
+       bugs. I'm very guilty of committing this error and it's
+       extremely easy to do. If English is not your first language,
+       have a native speaker look over or edit your documentation or
+       web pages. Poor spelling or grammar goes a long way to making
+       your code look unprofessional. In code comments, this type of
+       thing is less important but in man pages and web pages these
+       mistakes are not acceptable.
+      </para>
+     </listitem>
+
+    </itemizedlist>
+

 
 

-    <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>
 


@@ -1271,6 +1361,20 @@ pages for more information and options.
     may remind a developer of something they may have forgotten.
    </para>
 
     may remind a developer of something they may have forgotten.
    </para>
 

+   <sect3>
+    <title>Package File Names</title> 
+    <para>
+     I agree with ESR when he says that: <quote> It's helpful to
+     everybody if your archive files all have GNU-like names --
+     all-lower-case alphanumeric stem prefix, followed by a dash,
+     followed by a version number, extension, and other
+     suffixes.</quote> There is more info (including lots of examples
+     of what <emphasis>not</emphasis> to do in his <citetitle>Software
+     Release Practices HOWTO</citetitle> which is included in this
+     HOWTO's bibliography and can be found through the LDP.
+    </para>
+   </sect3>
+

    <sect3>
     <title>Package formats</title>
     <para>
    <sect3>
     <title>Package formats</title>
     <para>


@@ -1318,7 +1422,7 @@ pages for more information and options.
      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
      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
+     Mac OS 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.
      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.


@@ -1327,8 +1431,10 @@ pages for more information and options.
     <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
     <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.
+     I think it falls outside the scope of this document and already
+     has its own HOWTOs. Most notably is the <citetitle>CVS Best
+     Practices HOWTO</citetitle><xref linkend="cvsbestpractices">
+     which I've included in the attached bibliography.

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


@@ -1353,7 +1459,7 @@ pages for more information and options.
         <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
         <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
+        will receive many requests for downloads around releases so

         make sure that the server you choose has adequate bandwidth.
        </para>
       </listitem>
         make sure that the server you choose has adequate bandwidth.
        </para>
       </listitem>


@@ -1468,7 +1574,7 @@ pages for more information and options.
 
    <para>
     In a bit of a disclaimer, delegation need not mean rule by
 
    <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
+    committee. 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
     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


@@ -1498,13 +1604,13 @@ pages for more information and options.
      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
      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
+     toward them.</emphasis> The following ideas might be good places

      to start or good sources of inspiration:
     </para>
  
     <sect4>
      <title>Allow a larger group of people to have write access to your CVS
      to start or good sources of inspiration:
     </para>
  
     <sect4>
      <title>Allow a larger group of people to have write access to your CVS

-     repository and make real efforts towards rule by a
+     repository and make real efforts toward rule by a

      committee</title>
 
      <para>
      committee</title>
 
      <para>


@@ -1599,6 +1705,29 @@ pages for more information and options.
     to you by other developers.
    </para>
 
     to you by other developers.
    </para>
 

+   <sect3>
+    <title>Encouraging Good Patching</title>
+
+    <para>As the person managing or maintaining the project, you
+    aren't the person who is going to be making a lot of
+    patches. However, it's worth knowing about ESR's section on
+    <citetitle>Good Patching Practice</citetitle> in the
+    <citetitle>Software Release Practices HOWTO</citetitle><xref
+    linkend="esrhowto">. I don't agree with ESR's claim that most ugly
+    or undocumented patches are probably worth throwing out at first
+    sight--this just hasn't been my experience, especially when
+    dealing with bug fixes that often don't come in the form of
+    patches at all. Of course, this doesn't mean that I
+    <emphasis>like</emphasis> getting poorly done patches. If you get
+    ugly -e patches, if you get totally undocumented patches, and
+    especially if they are anything more than trivial bug-fixes, it
+    might be worth judging the patch by some of the criteria in ESR's
+    HOWTO and then throwing people the link to the document so they
+    can do it the <quote>right way.</quote>
+    </para>
+
+   </sect3>
+

    <sect3>
     <title>Technical judgment</title>
 
    <sect3>
     <title>Technical judgment</title>
 


@@ -1626,7 +1755,7 @@ pages for more information and options.
       <listitem>
        <para>The necessity to avoid digressions that might expand the
        scope of the program too much and result and push the project
       <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
+       toward an early death under its own weight and

        unwieldiness.</para>
       </listitem>
 
        unwieldiness.</para>
       </listitem>
 


@@ -1697,8 +1826,8 @@ pages for more information and options.
       difficult decisions to a development mailing list where they can
       be discussed and debated. There will be some patches (bug fixes,
       etc.) which will definitely be accepted and some that you feel
       difficult decisions to a development mailing list where they can
       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
+      are so off base that they do not even merit further
+      discussion. It is those that fall into the gray area between

       these two groups that might merit a quick forward to a mailing
       list.
      </para>
       these two groups that might merit a quick forward to a mailing
       list.
      </para>


@@ -1717,7 +1846,7 @@ pages for more information and options.
     <sect4>
      <title>Technical issues are not always good justification</title>
      <para>
     <sect4>
      <title>Technical issues are not always good justification</title>
      <para>

-      Especially towards the beginning of your project's life, you
+      Especially toward 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
       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


@@ -2073,7 +2202,7 @@ pages for more information and options.
     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 of your
     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 of your

-    users</emphasis> (those who explicityly volunteer) are your
+    users</emphasis> (those who explicitly volunteer) are your

     testers.
    </para>
 
     testers.
    </para>
 


@@ -2082,7 +2211,7 @@ pages for more information and options.
     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
     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
+    expect 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.
     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.


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

-     CVS comes with a bourne shell script called sanity.sh that is
+     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
      use of these scripts may not be helpful, there is a host of other
      worth looking at. Debian uses a program called lintian that
      checks Debian packages for all of the most common errors. While
      use of these scripts may not be helpful, there is a host of other


@@ -2192,7 +2321,7 @@ pages for more information and options.
      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
      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:
+     some tried and true tactics that can applied toward this end:

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


@@ -2269,7 +2398,7 @@ pages for more information and options.
     </para>
    </sect3>
 
     </para>
    </sect3>
 

-   <sect3>
+   <sect3 id="mailinglists">

     <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


@@ -2322,7 +2451,7 @@ pages for more information and options.
      <para>
       There are other things you want to take into consideration in
       setting up your list. If it is possible to gate your mailing
      <para>
       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
+      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.
       making them accessible on the web, you will please some users
       and work to make the support infrastructure slightly more
       accessible.


@@ -2361,7 +2490,7 @@ 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
       url="http://www.mozilla.org/projects/bugzilla/">bugzilla</ulink>
       has spawned a sub-project resulting in a bug tracking system
       called <ulink
       url="http://www.mozilla.org/projects/bugzilla/">bugzilla</ulink>


@@ -2578,26 +2707,35 @@ pages for more information and options.
    </para>
 
    <sect3>
    </para>
 
    <sect3>

-    <title>Mailing lists and USENET</title>
+    <title>Mailing lists and Usenet</title>
+
+    <para>Announce your software on Usenet's <ulink
+    url="news:comp.os.linux.announce">comp.os.linux.announce</ulink>. If
+    you only announce your software in two places, have it be c.o.l.a
+    and freshmeat.</para>
+

     <para>
     <para>

-     Email is still the way that most people on the Internet get their
-     information. Its a good idea to send a message announcing your
-     program to any relevant mailing list you know of and any relevant
-     USENET discussion group. Karl Fogel recommends that use you
-     simple subject describing the fact that the message is an
-     announcement, the name of the program, the version, and a
-     half-line long description of its functionality. This way, any
-     interested user or developer will be immediately attracted to
-     your announcement. Fogel's example looks like:
+     However, email is still the way that most people on the Internet
+     get their information. Its a good idea to send a message
+     announcing your program to any relevant mailing list you know of
+     and any other relevant Usenet discussion groups.</para>
+
+    <para>Karl Fogel recommends that use you simple subject
+     describing the fact that the message is an announcement, the name
+     of the program, the version, and a half-line long description of
+     its functionality. This way, any interested user or developer
+     will be immediately attracted to your announcement. Fogel's
+     example looks like:

     </para>
 
     </para>
 

-    <screen>Subject: ANN: aub 1.0, a program to assemble USENET binaries</screen>
+    <screen>Subject: ANN: aub 1.0, a program to assemble Usenet binaries</screen>

 
     <para>
      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
 
     <para>
      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 to try it right away.
+     downloads for those that want to try it right away. This form
+     will work for both Usenet and mailing list posts.

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


@@ -2625,6 +2763,20 @@ pages for more information and options.
      interesting new releases).
     </para>
    </sect3>
      interesting new releases).
     </para>
    </sect3>

+
+   <sect3>
+    <title>Project Mailing List</title>
+
+    <para>If you've gone ahead and created mailing lists for your
+    project, you should always announce new versions on these
+    lists. I've found that for many projects, users request a very
+    low-volume announce only mailing list to be notified when new
+    versions are released. freshmeat.net now allows users to subscribe
+    to a particular project so they receive emails every time a new
+    version is announced through their system. It's free and it can
+    stand in for an announce-only mailing list. In my opinion, it
+    can't hurt.</para>
+   </sect3>

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


@@ -2652,7 +2804,7 @@ pages for more information and options.
      <abstract>
       <para>
        Fogel's <quote>guide to using CVS in the free software
      <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
+       world</quote> is much more than its subtitle. 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
        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


@@ -2663,6 +2815,10 @@ pages for more information and options.
        important and useful. Please check it or buy it if you can and
        are seriously interested in running a free software project.
       </para>
        important and useful. Please check it or buy it if you can and
        are seriously interested in running a free software project.
       </para>

+
+      <para>In May of 2003, the entire book under the GPL. You can
+      find the full text of the book <ulink
+      url="http://cvsbook.red-bean.com/">here</ulink>.</para>

      </abstract>
     </biblioset>
    </biblioentry>
      </abstract>
     </biblioset>
    </biblioentry>


@@ -2688,7 +2844,7 @@ pages for more information and options.
        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
        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 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
        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


@@ -2738,7 +2894,7 @@ pages for more information and options.
   </bibliodiv>
 
   <bibliodiv>
   </bibliodiv>
 
   <bibliodiv>

-   <title>Web-Accessable Resources</title>
+   <title>Web-Accessible Resources</title>

 
    <para>
     This is a list of the web resources pertaining to this HOWTO that
 
    <para>
     This is a list of the web resources pertaining to this HOWTO that


@@ -2750,9 +2906,90 @@ pages for more information and options.
 
    <para>
     I'd recommend that any free software developer (or potential one)
 
    <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.
+    skim through these sites because they have each have a lot to say.

    </para>
 
    </para>
 

+
+   <biblioentry>
+    <biblioset>
+     <author>
+      <surname>Dafermos</surname>
+      <firstname>George</firstname>
+      <othername>N</othername>
+     </author>
+
+     <title><ulink url="http://firstmonday.org/issues/issue6_11/dafermos/">Management and Virtual Decentralized Networks: The Linux Project</ulink></title>
+
+     <abstract>
+      <para>Since the paper includes its own abstract, I thought I
+      would include it here verbatim:</para>
+
+      <para><blockquote><para>This paper examines the latest of
+       paradigms - the Virtual Network(ed) Organisation - and whether
+       geographically dispersed knowledge workers can virtually
+       collaborate for a project under no central
+       planning. Co-ordination, management and the role of knowledge
+       arise as the central areas of focus. The Linux Project and its
+       development model are selected as a case of analysis and the
+       critical success factors of this organisational design are
+       identified. The study proceeds to the formulation of a
+       framework that can be applied to all kinds of virtual
+       decentralised work and concludes that value creation is
+       maximized when there is intense interaction and uninhibited
+       sharing of information between the organisation and the
+       surrounding community. Therefore, the potential success or
+       failure of this organisational paradigm depends on the degree
+       of dedication and involvement by the surrounding
+       community.</para></blockquote></para>
+
+      <para>This paper was referred to me in my capacity as author of
+      this HOWTO and I was very impressed. It's written by a graduate
+      student in management and I think it succeeds at evaluating the
+      Linux project as an example of a new paradigm in management--one
+      that <emphasis>you</emphasis> will be be placing yourself at the
+      center of in your capacity as maintainer of a free software
+      project.</para>
+
+      <para>As a developer trying to control an application and guide
+      it to success in the free software world, I'm not sure how
+      useful Dafermos's argument is. It does however, provide a
+      theoretical justification for my HOWTO--free software project
+      management <emphasis>is</emphasis> a different creature than
+      proprietary software project management. If you are interested
+      in the conceptual and theoretical ways that free software
+      project management differs from other types of management, this
+      is a great paper to read. If this paper answers questions of
+      <quote>how?</quote>, Dafermos answers the (more difficult to
+      defend) questions of <quote>why?</quote> and does a very good
+      job.</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>
+

    <biblioentry>
     <biblioset>
      <author>
    <biblioentry>
     <biblioset>
      <author>


@@ -2775,8 +3012,8 @@ pages for more information and options.
       <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:
       <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
+       starting a project, testing, documentation, organizing a team and
+       leadership, and several other topics. While more opinionated 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.
        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.


@@ -2791,27 +3028,69 @@ pages for more information and options.
     </biblioset>
    </biblioentry>
 
     </biblioset>
    </biblioentry>
 

-   <biblioentry>
+   <biblioentry id="esrhowto">

     <biblioset>
      <author>
     <biblioset>
      <author>

-      <surname>Gabriel</surname>
-      <firstname>Richard</firstname>
+      <surname>Raymond</surname>
+      <firstname>Eric</firstname>
+      <othername>Steven</othername>

      </author>
      </author>

-     
-     <title><ulink
-     url="http://www.jwz.org/doc/worse-is-better.html">The Rise of
-     <quote>Worse is Better</quote></ulink></title>
+
+     <title><ulink url="http://www.tldp.org/HOWTO/Software-Release-Practice-HOWTO/index.html">Software Release Practice HOWTO</ulink></title>

 
      <abstract>
 
      <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>
+
+      <para>At first glance, ESR's release practice HOWTO seems to
+      share a lot of terrain with this document. Upon closer
+      examination, the differences become apparent but they are
+      closely related. His document, read in conjunction with mine,
+      will give a reader a good picture of how to go about managing a
+      project. ESR's HOWTO goes into a bit more detail on how to write
+      and what languages to write in. He tends to give more specific
+      instructions and checklists (<quote>name this file this, not
+      this</quote>) while this HOWTO speaks more conceptually. There
+      are several sections that are extremely similar. It's also
+      <emphasis>much</emphasis> shorter.</para>
+
+      <para>My favorite quote from his HOWTO is: <quote>"Managing a
+      project well when all the participants are volunteers presents
+      some unique challenges. This is too large a topic to cover in a
+      HOWTO.</quote> Oh really? Perhaps I just do a poor job.</para>
+     </abstract>
+
+    </biblioset>
+   </biblioentry>
+
+
+   <biblioentry id="cvsbestpractices">
+    <biblioset>
+     <author>
+      <surname>Venugopalan</surname>
+      <firstname>Vivek</firstname>
+     </author>
+
+     <title><ulink url="http://www.magic-cauldron.com/cm/cvs-bestpractices/index.html">CVS Best Practices</ulink></title>
+
+     <abstract>
+
+      <para>Venugopalan provides one of the best essays on
+      effective use of CVS that I've come across. It is written for
+      people who already have a good knowledge of CVS. In the chapter
+      on branching, he describes when and how to branch but gives no
+      information on what CVS commands you should use to do this. This
+      is fine (technical CVS HOWTO have been written) but CVS newbies
+      will want to spend some time with Fogel's reference before they
+      will find this one very useful.</para>
+
+      <para>Venugopalan creates checklists of things to do before,
+      after, and around releases. It's definitely worth a read through
+      as most of his ideas will save tons of developer head aches over
+      any longer period of time.</para>
+

      </abstract>
     </biblioset>
    </biblioentry>
      </abstract>
     </biblioset>
    </biblioentry>

+

   </bibliodiv>
 
   <bibliodiv>
   </bibliodiv>
 
   <bibliodiv>


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

-    I have spent a huge amount of time on advogato and I've gone
+    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
     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
+    skimming through these links can be helpful 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.
     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.


@@ -2838,7 +3117,7 @@ pages for more information and options.
     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
     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.
+    relevant articles here with short descriptions that I've written.

    </para>
 
 
    </para>
 
 


@@ -2860,7 +3139,7 @@ pages for more information and options.
       <para>
        Touching mostly on programming practice (as most articles on
        the subject usually do), the article talks a little about
       <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
+       project management (<quote>Use it!</quote>) and a bit about

        communication within a free software project.
       </para>
      </abstract>
        communication within a free software project.
       </para>
      </abstract>


@@ -2943,7 +3222,7 @@ pages for more information and options.
      <abstract>
       <para>
        While the article is little more than a question, reading the
      <abstract>
       <para>
        While the article is little more than a question, reading the

-       answers to this question offered by advogato's readers can
+       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
        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


@@ -2972,7 +3251,7 @@ pages for more information and options.
      <abstract>
       <para>
        This document was written as a response to <ulink
      <abstract>
       <para>
        This document was written as a response to <ulink

-       url="http://www.advogato.org/article/72.html">another advogato
+       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
        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


@@ -2992,11 +3271,10 @@ pages for more information and options.
       <surname>Moorman</surname>
       <firstname>Jacob</firstname>
      </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>
-     
+
+     <title><ulink url="http://www.advogato.org/article/72.html">Importance of
+     Non-Developer Supporters in Free Software</ulink><title></title>
+

      <publisher>
       <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
      </publisher>
      <publisher>
       <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
      </publisher>


@@ -3049,16 +3327,16 @@ pages for more information and options.
      <publisher>
       <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
      </publisher>
      <publisher>
       <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
      </publisher>

-     <pubdate>Februrary 28, 2000</pubdate>
+     <pubdate>February 28, 2000</pubdate>

     
      <abstract>
       <para>
     
      <abstract>
       <para>

-       In this article, David Allen challengs the whole
+       In this article, David Allen challenges 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
        <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.
+       of version numbering.

       </para>
      </abstract>
     </biblioset>
       </para>
      </abstract>
     </biblioset>


@@ -3096,14 +3374,14 @@ pages for more information and options.
   </docinfo>
   <title>GNU Free Documentation License</title>
 
   </docinfo>
   <title>GNU Free Documentation License</title>
 

-  <sect1 id="fdl-preamble">
+  <simplesect 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
     <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
+      commercially or non-commercially. 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.
       preserves for the author and publisher a way to get credit for
       their work, while not being considered responsible for
       modifications made by others.


@@ -3126,8 +3404,8 @@ pages for more information and options.
       printed book. We recommend this License principally for works
       whose purpose is instruction or reference.
     </para>
       printed book. We recommend this License principally for works
       whose purpose is instruction or reference.
     </para>

-  </sect1>
-  <sect1 id="fdl-section1">
+  </simplesect>
+  <simplesect id="fdl-simplesect1">

     <title>1. APPLICABILITY AND DEFINITIONS</title>
     <para id="fdl-document">
       This License applies to any manual or other work that contains a
     <title>1. APPLICABILITY AND DEFINITIONS</title>
     <para id="fdl-document">
       This License applies to any manual or other work that contains a


@@ -3216,14 +3494,14 @@ pages for more information and options.
       most prominent appearance of the work's title, preceding the
       beginning of the body of the text.
     </para>
       most prominent appearance of the work's title, preceding the
       beginning of the body of the text.
     </para>

-  </sect1>
+  </simplesect>

     
     

-  <sect1 id="fdl-section2">
+  <simplesect 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
     <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
+      commercially or non-commercially, 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
       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


@@ -3239,9 +3517,9 @@ pages for more information and options.
       You may also lend copies, under the same conditions stated
       above, and you may publicly display copies.
     </para>
       You may also lend copies, under the same conditions stated
       above, and you may publicly display copies.
     </para>

-    </sect1>
+    </simplesect>

     
     

-  <sect1 id="fdl-section3">
+  <simplesect id="fdl-section3">

     <title>3. COPYING IN QUANTITY</title>
     <para>
       If you publish printed copies of the <link
     <title>3. COPYING IN QUANTITY</title>
     <para>
       If you publish printed copies of the <link


@@ -3294,9 +3572,9 @@ pages for more information and options.
       redistributing any large number of copies, to give them a chance
       to provide you with an updated version of the Document.
     </para>
       redistributing any large number of copies, to give them a chance
       to provide you with an updated version of the Document.
     </para>

-    </sect1>
+    </simplesect>

     
     

-  <sect1 id="fdl-section4">
+  <simplesect id="fdl-section4">

     <title>4. MODIFICATIONS</title>
     <para>
       You may copy and distribute a <link
     <title>4. MODIFICATIONS</title>
     <para>
       You may copy and distribute a <link


@@ -3543,9 +3821,9 @@ pages for more information and options.
       assert or imply endorsement of any <link
       linkend="fdl-modified">Modified Version </link>.
     </para>
       assert or imply endorsement of any <link
       linkend="fdl-modified">Modified Version </link>.
     </para>

-  </sect1>
+  </simplesect>

     
     

-  <sect1 id="fdl-section5">
+  <simplesect id="fdl-section5">

     <title>5. COMBINING DOCUMENTS</title>
     <para>
       You may combine the <link linkend="fdl-document">Document</link>
     <title>5. COMBINING DOCUMENTS</title>
     <para>
       You may combine the <link linkend="fdl-document">Document</link>


@@ -3579,9 +3857,9 @@ pages for more information and options.
       and any sections entitled <quote>Dedications</quote>.  You must
       delete all sections entitled <quote>Endorsements.</quote>
     </para>
       and any sections entitled <quote>Dedications</quote>.  You must
       delete all sections entitled <quote>Endorsements.</quote>
     </para>

-    </sect1>
+    </simplesect>

     
     

-  <sect1 id="fdl-section6">
+  <simplesect id="fdl-section6">

     <title>6. COLLECTIONS OF DOCUMENTS</title>
     <para>
       You may make a collection consisting of the <link
     <title>6. COLLECTIONS OF DOCUMENTS</title>
     <para>
       You may make a collection consisting of the <link


@@ -3600,9 +3878,9 @@ pages for more information and options.
       follow this License in all other respects regarding verbatim
       copying of that document.
     </para>
       follow this License in all other respects regarding verbatim
       copying of that document.
     </para>

-    </sect1>
+    </simplesect>

     
     

-  <sect1 id="fdl-section7">
+  <simplesect id="fdl-section7">

     <title>7. AGGREGATION WITH INDEPENDENT WORKS</title>
     <para>
       A compilation of the <link
     <title>7. AGGREGATION WITH INDEPENDENT WORKS</title>
     <para>
       A compilation of the <link


@@ -3624,9 +3902,9 @@ pages for more information and options.
       aggregate. Otherwise they must appear on covers around the whole
       aggregate.
     </para>
       aggregate. Otherwise they must appear on covers around the whole
       aggregate.
     </para>

-    </sect1>
+    </simplesect>

     
     

-  <sect1 id="fdl-section8">
+  <simplesect id="fdl-section8">

     <title>8. TRANSLATION</title>
     <para>
       Translation is considered a kind of modification, so you may
     <title>8. TRANSLATION</title>
     <para>
       Translation is considered a kind of modification, so you may


@@ -3643,9 +3921,9 @@ pages for more information and options.
       translation and the original English version of this License,
       the original English version will prevail.
     </para>
       translation and the original English version of this License,
       the original English version will prevail.
     </para>

-    </sect1>
+    </simplesect>

     
     

-  <sect1 id="fdl-section9">
+  <simplesect id="fdl-section9">

     <title>9. TERMINATION</title>
     <para>
       You may not copy, modify, sublicense, or distribute the <link
     <title>9. TERMINATION</title>
     <para>
       You may not copy, modify, sublicense, or distribute the <link


@@ -3657,9 +3935,9 @@ pages for more information and options.
       License will not have their licenses terminated so long as such
       parties remain in full compliance.
     </para>
       License will not have their licenses terminated so long as such
       parties remain in full compliance.
     </para>

-    </sect1>
+    </simplesect>

     
     

-  <sect1 id="fdl-section10">
+  <simplesect id="fdl-section10">

     <title>10. FUTURE REVISIONS OF THIS LICENSE</title>
     <para>
       The <ulink type="http"
     <title>10. FUTURE REVISIONS OF THIS LICENSE</title>
     <para>
       The <ulink type="http"


@@ -3684,53 +3962,7 @@ pages for more information and options.
       you may choose any version ever published (not as a draft) by
       the Free Software Foundation.
     </para>
       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>
+  </simplesect>

 </appendix>  
 
 </article>
 </appendix>  
 
 </article>