Major readthrough. Major changes, and minor additions. More than I can

Author: mako
Date: 2001/04/09 05:39:03
Major readthrough. Major changes, and minor additions. More than I can
list here.

This is version v0.2 of the HOWTO with substantial changes over the
last release.

diff --git a/FreeSoftwareDevelopmentHOWTO.sgml b/FreeSoftwareDevelopmentHOWTO.sgml
index 19375fdddc7799fc93c913c28af61659010665aa..d85158d685b630b3e837b5f4fd936ca9b9f2c88e 100644 (file)
--- a/FreeSoftwareDevelopmentHOWTO.sgml
+++ b/FreeSoftwareDevelopmentHOWTO.sgml
@@ -43,7 +43,7 @@
     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 development
     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 development

-    and was written to act as a crash course in the people skills that
+    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>
     aren't taught to commercial coders but that can make or break a
     free software project.
    </para>


@@ -63,8 +63,8 @@
   <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>
 
    myself, "Why?"
   </para>
 


@@ -186,17 +186,17 @@
     </indexterm>
 
    <para>
     </indexterm>
 
    <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 is the second pre-release of this HOWTO. 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 gets publicized widely.

    </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://people.debian.org/~mako/projects/howto">the projects
+    homepage </ulink> hosted by Debian.

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


@@ -228,7 +228,7 @@
 
     <listitem>
      <para>
 
     <listitem>
      <para>

-      <ulink url="http://people.debian.org/~mako/projects/howto/FreeSoftwareDevelopment-HOWTO.ps.gz">compressed postscript</ulink>.
+      <ulink url="http://people.debian.org/~mako/projects/howto/FreeSoftwareDevelopment-HOWTO.ps.gz">Compressed postscript</ulink>.

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


@@ -262,11 +262,11 @@
     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
     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

-    several translations of the chapters on CVS. I you are seriously
+    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
     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, and I'll try and have those fixed in future versions.
+    sorry. I'll try and have those fixed in future versions.

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


@@ -277,14 +277,14 @@
    <para>
     Also providing support material, and inspiration for this HOWTO is
     Eric S. Raymond for his prolific, consistent, and carefully
    <para>
     Also providing support material, and inspiration for this HOWTO is
     Eric S. Raymond for his prolific, consistent, and carefully

-    crafted arguments, Lawrence Lessig for reminding me of the
+    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
     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
+    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 how have been involved with the movement much longer than I,
     advocacy, a place to make a difference, a place to learn from
     those how have been involved with the movement much longer than I,

-    and proof of a Free Software project that definitely, definitely
+    and proof of a free software project that definitely, definitely

     works.
    </para>
 
     works.
    </para>
 


@@ -292,7 +292,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 towards 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>


@@ -311,9 +311,10 @@
     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
     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 this
-    fact. Please send your additions, comments and criticisms to the
-    following email address : <email>mako@debian. org</email>.
+    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>
 


@@ -325,7 +326,7 @@
    <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>
 
    <para>


@@ -350,19 +351,18 @@
     <primary>fswd!starting</primary>
    </indexterm>
   <para>
     <primary>fswd!starting</primary>
    </indexterm>
   <para>

-   With very little argument, the beginning is most difficult part of
-   successful free software development. Laying a firm foundation will
-   determine whether your project flourishes or withers away and
+   With very little argument, the beginning is the most difficult part
+   of successful free software development. 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>
    Starting a project involves a dilemma that you as a developer must
    dies. It is also the subject that is of most immediate interest to
    anyone reading this document as a tutorial.
   </para>
 
   <para>
    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. Simultaneously, the development
-   process that you want to employ holds involvement of users as
-   prerequisit to working software.
+   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>
   </para>
 
   <para>


@@ -382,27 +382,28 @@
 
    <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 in a percieved gap by doing something that no other
-    free software process does or by doing something in a way the 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, <quote>The Cathedral and the Bazaar,</quote> which
-     comes as required reading for any free software development. It
-     is available <ulink
+     his essay, <quote>The Cathedral and the Bazaar,</quote> which
+     comes as required reading for any free software developer. It is
+     available <ulink

      url="http://www.tuxedo.org/~esr/writings/cathedral-bazaar/">online
      </ulink>.
     </para>
 
     <para>
      In <quote>The Cathedral and the Bazaar,</quote> Raymond tells us
      url="http://www.tuxedo.org/~esr/writings/cathedral-bazaar/">online
      </ulink>.
     </para>
 
     <para>
      In <quote>The Cathedral and the Bazaar,</quote> Raymond tells us

-     that: <emphasis>Every good work of software starts by scratching
-     a developers itch.</emphasis> Raymond's now widely accepted
+     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>
      hypothesis is that new free software programs are written, first
      and foremost, to solve a specific problem facing the developer.
     </para>


@@ -410,23 +411,24 @@
     <para>
      If you have an idea for a program in mind, chances are good that
      it targets a specific problem or <quote>itch</quote> you want to
     <para>
      If you have an idea for a program in mind, chances are good that
      it targets a specific problem or <quote>itch</quote> you want to

-     see scratched. 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.
+     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>
     </para>
 
     <para>

-     Monty Manley articles the importance of this initial step in an
-     essay, <ulink
+     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
      url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing

-     Projects the Open Source Way.</ulink> As the next section will
-     show, there is <emphasis>a lot</emphasis> of work that needs to
-     be done before software is ready for release. Manley says,
-     <quote>Beginning an OSS project properly means that a developer
-     must, first and foremost, avoid writing code too soon!</quote>
+     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>
 


@@ -435,24 +437,29 @@
 
     <para>
      In evaluating your idea, you need to first ask yourself a few
 
     <para>
      In evaluating your idea, you need to first ask yourself a few

-     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 in solitude
-     fails to qualify as a free software development effort, you need
-     to ask yourself the question: <emphasis>Is anybody else
-     interested?</emphasis>
+     questions.  This should happen before you move any further
+     through this HOWTO. Ask yourself: <emphasis>Is the free software
+     development model really is the right one for your
+     project?</emphasis>

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

-     Sometimes the answer is a simple <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.
+     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>
+     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>


@@ -460,7 +467,7 @@
      chances are, there is someone, somewhere, who shares your
      interests and how feels the same <quote>itch.</quote> It is the
      fact that there are so many people with so many similar needs and
      chances are, there is someone, somewhere, who shares your
      interests and how 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 second major question: <emphasis>Has
+     desires that introduces the third major question: <emphasis>Has

      somebody already had your idea or a reasonably similar
      one?</emphasis>
     </para>
      somebody already had your idea or a reasonably similar
      one?</emphasis>
     </para>


@@ -471,7 +478,7 @@
      <para>
       There are places you can go on the web to try and answer the
       question above. If you have experience with the free software
      <para>
       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 all of these
+      community, you are probably already familiar with many of these

       sites. All of the resources listed bellow offer searching of
       their databases:
      </para>
       sites. All of the resources listed bellow offer searching of
       their databases:
      </para>


@@ -479,19 +486,19 @@
      <para>
      <variablelist>
        <varlistentry>
      <para>
      <variablelist>
        <varlistentry>

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

         <listitem>
         <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
         these lines is totally unparalleled and unquestioned. If you
         can't find it on freshmeat, its doubtful that you (or anyone
         <listitem>
         <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
         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 anywhere.</para>
+        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>
         provides <quote>News for Nerds: Stuff that Matters,</quote>
         <listitem>
         <para><ulink url="http://slashdot.org">Slashdot</ulink>
         provides <quote>News for Nerds: Stuff that Matters,</quote>


@@ -503,7 +510,7 @@
        </varlistentry>
 
        <varlistentry>
        </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


@@ -512,26 +519,26 @@
         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
         provides a at <ulink
         url="http://sourceforge.net/snippet/">Code Snippet
         Library</ulink> which contains useful reusable chunks of code
         embarking on a new free software project. SourceForge also
         provides a at <ulink
         url="http://sourceforge.net/snippet/">Code Snippet
         Library</ulink> which contains useful reusable chunks of code

-        in an array of languaqges which can come in useful in any
+        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>, 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 to make sure you aren't pouring your effort into a
+        redundant project.</para>

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


@@ -542,16 +549,16 @@
     <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 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
+      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

       project?</quote>
      </para>
 
       project?</quote>
      </para>
 


@@ -563,15 +570,16 @@
      </para>
 
      <para>
      </para>
 
      <para>

-      This may be the single most difficult aspect of free software
-      development for many developers but it is an essential one. It
-      is easy to become fired up by an idea and be caught up in the
+      For many developers this may be the single most difficult aspect
+      of free software development but it is an essential one. It is
+      easy to become fired up by an idea and be 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 remember that the best interests of the free software
       momentum and excitement of a new project. It is often extremely
       difficult to do but, it is important that any free software
       developer remember that the best interests 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.
+      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>
      </para>
 
     </sect4>


@@ -586,50 +594,52 @@
    <para>
     While there are plenty of projects that fail with descriptive
     names and plenty that succeed without them, I think naming your
    <para>
     While there are plenty of projects that fail with descriptive
     names and plenty that succeed without them, I think naming your

-    project is wroth giving a little bit of thought. Leslie Orchard
-    tackles this issue in a n <ulink
-    url="http://www.advogato.org/article/67.html">advogato
-    article</ulink>. The article is short and probably worth looking
+    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>
     over quickly.
    </para>
 
    <para>

-    The very short version is that Orchard recommends that you should
-    pick a name where, after hearing the name, many users or
-    developers will:
+    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>
 
    <para>
     <itemizedlist>
      <listitem>

-      <para>You will know what the project does.</para>
+      <para>Know what the project does.</para>

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

-      <para>You will remember it tomorrow.</para>
+      <para>Remember it tomorrow.</para>

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

-    Humorously, Orchard's project, Iajitsu, does neither (and
-    development is effectively frozen since the article was written).
+    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>
    </para>
 
    <para>

-    There is a point though. There are companies who only job is to
-    make names for pieces of software. They make
-    <emphasis>ridiculous</emphasis> amount of money doing it and they
-    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.
+    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>
    </para>
 
    <para>

-    If there is a name you really want, go ahead. I though
-    <quote>gnubile</quote> was one of the best names ever and I still
-    talk about it, long after I've stopped using the program. If you
-    can flexible on the subject, listen to Orchard's advice. It might
-    even help you.
+    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 flexible on the subject, listen to
+    Orchard's advice. It might help you.

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


@@ -655,7 +665,7 @@
      small flame war as there are strong feelings that some free
      software licenses are better than others. This discussion also
      brings up the question of <quote>Open Source Software</quote> and
      small flame war as there are strong feelings that some free
      software licenses are better than others. This discussion also
      brings up the question of <quote>Open Source Software</quote> and

-     the debate around <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 Development HOWTO and not the Open Source
      Development HOWTO, my own allegiances in this argument are in the
      <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 in the


@@ -664,26 +674,27 @@
 
     <para>
      In attempting to reach a middle ground through diplomacy without
 
     <para>
      In attempting to reach a middle ground through diplomacy without

-     sacrificing my own philosophy, I recommend picking any license
-     that conforms to the <ulink
+     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
      Guidelines</ulink>. Originally compiled by the Debian project
      url="http://www.debian.org/social_contract">Debian Free Software
      Guidelines</ulink>. Originally compiled by the Debian project

-     under Bruce Perens, the <acronym>DFSG</acronym> form the first
-     version of the Open Source definition. Examples of free licenses
-     given by the <acronym>DFSG</acronym> are the
-     <acronym>GPL</acronym>, the <acronym>BSD</acronym>, and the
-     Artistic License. 
+     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>
     </para>
 
     <para>

-     Conforming to the definition of Free Software offered by Richard
+     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
      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,
+     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>
      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 common license will offer the advantage
+     but sticking with a more well-known license will offer the advantage

      of immediate recognition and understanding.
     </para>
 
      of immediate recognition and understanding.
     </para>
 


@@ -702,14 +713,14 @@
      GNOME, Emacs, and the vast majority of GNU/Linux software. It's
      the obvious choice but I believe it is a good one. Any BSD
      fanatic will urge you to remember that there is a viral aspect to
      GNOME, Emacs, and the vast majority of GNU/Linux software. It's
      the obvious choice but I 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
+     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>
      <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>

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


@@ -732,8 +743,8 @@
 
     <para>
      <emphasis>In any case, please read through any license before
 
     <para>
      <emphasis>In any case, please read through any license before

-     your release your software. As the primary developer, you can't
-     afford any license surprises.</emphasis>
+     your release your software under it. As the primary developer,
+     you can't afford any license surprises.</emphasis>

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


@@ -752,15 +763,15 @@
      
       <listitem>
        <para>If at all possible, attach and distribute a full copy of
      
       <listitem>
        <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>
       </listitem>
 
       <listitem>
        <para>At the top of each source file in your program, attach a
        file.</para>
       </listitem>
 
       <listitem>
        <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>


@@ -783,8 +794,8 @@ 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>
       </listitem>
 
       </para>
       </listitem>
 


@@ -793,8 +804,8 @@ Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
         The <acronym>GPL</acronym> continues and suggests that if your
         program runs in an interactive mode, you should write the
         program to output a notice each time it enters interactive
         The <acronym>GPL</acronym> continues and suggests that if your
         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 more
-        information about the programs licensing:
+        mode that includes a message like this one that points to full
+        information about the programs license:

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


@@ -808,12 +819,12 @@ for details.
 
       <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 later on. Its often needed but there
-       are plenty of free software developers who have gotten into
-       trouble and wish they had attained one.</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>
 
      </itemizedlist>
       </listitem>
 
      </itemizedlist>


@@ -824,17 +835,17 @@ for details.
     <title>Final license warning</title>
 
     <para>
     <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 <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 you have no license, your program 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.
+     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>


@@ -865,15 +876,16 @@ for details.
    </para>
 
    <para>
    </para>
 
    <para>

-    Beyond this, the most common technique seems to be the
-    <quote>major level</quote>, <quote>minor level</quote>,
+    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
     <quote>patch level</quote> version numbering scheme. Whether you

-    are familiar with it or not, you interact with it all the
+    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
     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 bug fixes.
+    usually will only refer to releases fixing bugs.

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


@@ -884,17 +896,16 @@ for details.
    </para>
 
    <para>
    </para>
 
    <para>

-    You can bend or break these rules, and people do. Beware, if you
-    choose to, someone will get annoyed, assume you don't know, and
-    try and educate you. I always follow this method and I implore you
-    to do so as well.
+    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>

- 
+   

    <para>
    <para>

-    Follow these two simple rules and you will not go (too)
-    wrong. Still, there are several version numbering systems that are
-    well known, useful, and that might be worth looking into before
-    you release your first version.
+    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>
    </para>
 
    <variablelist>


@@ -916,14 +927,15 @@ 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
-       progress development 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
-       worth taking into consideration.
+       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>
      </listitem>
     </varlistentry>
       </para>
      </listitem>
     </varlistentry>


@@ -934,11 +946,12 @@ for details.
       <para>Because of the unusual nature of wine's development where
       the not-emulator is constantly improving but not working towards
       any immediately achievable goal, wine is released every three
       <para>Because of the unusual nature of wine's development where
       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 Year Month
-      Day format where each release might be labeled
+      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
       <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.
+      projects, <quote>Year Month Day</quote> format can make a lot of
+      sense.

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


@@ -948,8 +961,8 @@ for details.
      <listitem>
       <para>When one considers Netscape 6 and vendor versions, the
       mozilla's project development structure is one of the most
      <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>
 
       developed.
       </para>
 


@@ -960,17 +973,18 @@ for details.
        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
        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, 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.
+       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>
      </listitem>
     </varlistentry>
       </para>
      </listitem>
     </varlistentry>


@@ -995,13 +1009,12 @@ for details.
    </para>
 
    <para>
    </para>
 
    <para>

-    There are lots of different people for whom to document and
-    therefore there are lots of ways to document your
-    project. <emphasis>The importance of ocumentation in source code
-    to help facilitate development by a large community is vital but
-    it falls outside the scope of this HOWTO.</emphasis> 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>
    </para>
 
    <para>


@@ -1018,17 +1031,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

-    projectname</quote> end up with a nicely formatted man page
-    highlighting the basic use of yourapplication. Make sure that
+    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
     before you release your program, you've planned for this.
     </para>
 
     <para>
      Man pages are not difficult to write. There is excellent

-     documentation on the man page writing 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


@@ -1036,11 +1049,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 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 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>
 


@@ -1053,8 +1066,8 @@ for details.
      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
      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, all the major options (also with
-     explanations), and a pointer to more in-depth documentation for
+     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>


@@ -1102,8 +1115,8 @@ pages for more information and options.
      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>
 


@@ -1115,8 +1128,8 @@ pages for more information and options.
      package containing source code. In a source distribution, most of
      these files can be stored in a the root directory of the source
      distribution or in a subdirectory of the root called
      package containing source code. In a source distribution, most of
      these files can be stored in a the root directory of the source
      distribution or in a subdirectory of the root called

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

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


@@ -1128,9 +1141,9 @@ pages for more information and options.
        <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
        <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>
+       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>


@@ -1143,30 +1156,27 @@ pages for more information and options.
        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
        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. More advanced users can usually avoid
-       INSTALL files but it's good practice to at least glance at one
-       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>
+       that may be necessary. For most relatively standard install
+       procedures and for most programs, INSTALL files are as short
+       as possible are rarely over 100 lines.</para>

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

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

 
        <listitem>
 
        <listitem>

-       <para>A changelog is a simple file that every well-managed
-       free software project should include. A changelog is simple
+       <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
        the file that, as its name implies, 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>
+       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>
        </listitem>
 
       </varlistentry>


@@ -1174,13 +1184,14 @@ pages for more information and options.
        <term>NEWS</term>
 
        <listitem>
        <term>NEWS</term>
 
        <listitem>

-       <para>A NEWS file and a ChangeLog are similar. A news file is
-       not typically sorted by version but just whenever new features
-       are added, the developer responisble will make a note in the
-       NEWS file. NEWS files should not have to 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 people
-       just forget to keep them as current as they should.</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>


@@ -1188,15 +1199,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 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 it 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>
+       <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>


@@ -1207,32 +1218,21 @@ pages for more information and options.
    <sect3>
     <title>Website</title> 
     <para>
    <sect3>
     <title>Website</title> 
     <para>

-     It's only idirectly 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's documentation. 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 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
-     provide a direct link to all the available ways of downloading
-     your software.
+     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
+     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


@@ -1242,6 +1242,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
+     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>
 


@@ -1252,9 +1260,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 issues. 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>


@@ -1267,26 +1276,56 @@ 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. Your users or fellow
-     developers can and will do the the binary packages for
-     you.</emphasis>
+     relationships with users or developers of large distributiosn 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>
+
+   <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
+     (already has) its own HOWTO.

     </para>
     </para>

+

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


@@ -1303,15 +1342,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. Keep in mind that this
-        location will recieve many requests for downloads around
-        releases so make sure that the server you choose for this
-        purpose has adequate bandwidth.
+        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>
 


@@ -1320,44 +1358,17 @@ 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. It also will allow for more than one person
-        to deal with the influx of mail that is created if your
+        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>
       </listitem>
 
      </itemizedlist>
     </para>
         project becomes as huge as you hope it will.
        </para>
       </listitem>
 
      </itemizedlist>
     </para>

-
-    <para>
-     A version control system can make a lot of these problems of
-     packaging (and a lot of other problems mentioned in this HOWTO)
-     much easier. 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 introduced into this HOWTO.
-     I am not aware of any free version control systems for windows or
-     mac 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 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 version straight on this HOWTO!) but I
-     think it falls outside the scope of this document and should/has
-     already have its own HOWTO written about it.
-    </para>

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


@@ -1376,10 +1387,11 @@ pages for more information and options.
    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
    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

-   process itself is equally important and provides quite a few
-   opportunities for failure. In the next two sections, I will cover
-   running a project by discussing how to maintain a project through
-   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>


@@ -1413,7 +1425,7 @@ pages for more information and options.
    <para>
     By now, you've hypothetically followed me through the early
     programming of a piece of software, the creation of a website and
    <para>
     By now, you've hypothetically followed me through the early
     programming of a piece of software, the creation of a website and

-    system of documentation and and we've gone ahead and (as will be
+    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.


@@ -1421,48 +1433,48 @@ 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. 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.
+    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
    </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 been the death of a project. <ulink
+    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
     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

-    projects founder and that these important powers need not all rest
-    in one person but that a release manager may be different than a
-    lead developer. These situations are tricky politically though so
-    be careful and make sure this is necessary before you go around
+    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>
 
     empowering people.
    </para>
 


@@ -1472,8 +1484,8 @@ pages for more information and options.
     <para>
      You may find that other developers seem even more experienced or
      knowledgeable than you. Your job as a maintainer does not mean
     <para>
      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
+     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>
      recognizing which solutions are maintainable and which are not. 
     </para>
     <para>


@@ -1486,7 +1498,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>
 


@@ -1502,9 +1514,9 @@ 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
+      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
       the project is determined by the project's <ulink
       url="http://www.debian.org/social_contract">social
       contract</ulink> and a <ulink


@@ -1512,7 +1524,7 @@ pages for more information and options.
       facilitate this system, there are special teams (i.e. the
       install team, the Japanese language team) as well as a technical
       committee and a project leader. The leader's main responsibility
       facilitate this system, there are special teams (i.e. the
       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
+      is to, <quote>appoint delegates or delegate decisions to the

       Technical Committee.</quote>
      </para>
 
       Technical Committee.</quote>
      </para>
 


@@ -1529,7 +1541,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


@@ -1541,7 +1553,7 @@ 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
       a certain person and its a great way of giving yourself room to
       breath.
       clearly defining a chunk of work on the project as belonging to
       a certain person and its a great way of giving yourself room to
       breath.


@@ -1549,7 +1561,7 @@ pages for more information and options.
     </sect4>
 
     <sect4 id="delegatebranch">
     </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
      <para>
       If your project chooses to have branches (as described in <xref
       linkend="branches">), it might be a good idea to appoint someone


@@ -1577,7 +1589,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>


@@ -1622,7 +1634,7 @@ pages for more information and options.
     </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>


@@ -1646,11 +1658,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>
 


@@ -1658,17 +1670,16 @@ 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>
     </para>
 
     <sect4>


@@ -1679,11 +1690,12 @@ pages for more information and options.
       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
       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

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


@@ -1700,20 +1712,20 @@ 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, 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 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 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
-      making 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>
 


@@ -1736,9 +1748,9 @@ pages for more information and options.
       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
       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 after putting a
-      large deal of time, thought, and energy into it, you remember
+      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.
       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.


@@ -1767,21 +1779,22 @@ pages for more information and options.
     The most common way of branching your project is to have one
     branch that is stable and one that is for development. This is the
     model followed by the Linux kernel that is described in <xref
     The most common way of branching your project is to have one
     branch that is stable and one that is for development. This is the
     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> 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>
-    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
+    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>
+    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,
     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,


@@ -1807,8 +1820,8 @@ pages for more information and options.
       <listitem>
        <para>Debian may be able to make good use of four or five
        branches but it contains gigabytes of software in over 5000
       <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. For you,
-       two is probably a good number. Too many branches will confuse
+       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
        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


@@ -1823,8 +1836,8 @@ pages for more information and options.
        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
        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>
+       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


@@ -1854,12 +1867,12 @@ pages for more information and options.
        <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
        <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 in different directories or directory
-       trees on your <acronym>FTP</acronym> or <acronym>HTTP</acronym>
-       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
+       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
        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


@@ -1868,8 +1881,8 @@ pages for more information and options.
        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
        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>
+       other so your users know exactly what they want and where to
+       get it.</para>

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


@@ -1885,7 +1898,7 @@ pages for more information and options.
    <para>
     There are more issues surrounding interaction with developers in a
     free software project that I can not touch on in great detail in a
    <para>
     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. Please don't hesitate to contact me if you see
+    HOWTO of this size and scope. Please don't hesitate to contact me if you see

     any major omissions.
    </para>
 
     any major omissions.
    </para>
 


@@ -1917,19 +1930,19 @@ 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>
      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
     </para>
 
     <para>
      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="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>


@@ -1937,11 +1950,11 @@ pages for more information and options.
    <sect3>
     <title>Forking</title>
     <para>
    <sect3>
     <title>Forking</title>
     <para>

-     Forks are the most extreme version of a branch. A fork is
+     Forks are like the most extreme version 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
      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
+     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.
      but for technical, political, and philosophical reasons,
      development was split into two projects which now compete with
      each other.


@@ -1950,10 +1963,10 @@ pages for more information and options.
     <para>
      The short version of the fork section is, <emphasis>don't do
      them.</emphasis> Forks force developers to choose one project to
     <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 and redundancy of
+     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
      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.
+     they run their project.

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


@@ -2009,7 +2022,7 @@ 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
      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


@@ -2024,12 +2037,12 @@ pages for more information and options.
     <listitem>
      <para>In an almost paradoxical situation, free software projects
      have less immediate or dire consequences for ignoring their users
     <listitem>
      <para>In an almost paradoxical situation, free software projects
      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 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 a commitment to your users or by both.</para>
+     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>


@@ -2054,27 +2067,27 @@ 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> of your
-    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
     all of your users want to be testers. Many users want to use
    </para>
 
    <para>
     It is important that this distinction be made early on because not
     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 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.
+    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>
    </para>
 
    <para>

-     <ulink
+     <quote><ulink

      url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing
      url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing

-     Projects the Open Source Way</ulink> describes what a good test
-     should look for in each module:
+     Projects the Open Source Way</ulink></quote> describes what a
+     good test should look for:

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


@@ -2082,10 +2095,8 @@ pages for more information and options.
      <term>Boundary conditions</term>
 
      <listitem>
      <term>Boundary conditions</term>
 
      <listitem>

-      <para>
-       Maximum buffer lengths, data conversions, upper/lower boundary
-       limits, and so on.
-      </para>
+      <para>Maximum buffer lengths, data conversions, upper/lower
+      boundary limits, and so on.</para>

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


@@ -2093,14 +2104,12 @@ pages for more information and options.
      <term>Inappropriate behavior</term>
 
      <listitem>
      <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 what if questions and think of
-       anything that <emphasis>might</emphasis> fail or
-       <emphasis>might</emphasis> go wrong and find out what program
-       would do in that case.
-      </para>
+      <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>
      </listitem>
 
     </varlistentry>


@@ -2108,14 +2117,12 @@ pages for more information and options.
      <term>Graceful failure</term>
 
      <listitem>
      <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>
+      <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>
      </listitem>
 
     </varlistentry>


@@ -2124,13 +2131,11 @@ pages for more information and options.
      <term>Standards conformance</term>
 
      <listitem>
      <term>Standards conformance</term>
 
      <listitem>

-      <para>
-       If possible, make sure your programs conforms to
-       standards. 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>
+      <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>
      </listitem>
 
     </varlistentry>


@@ -2142,22 +2147,22 @@ pages for more information and options.
      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
      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

-     something you just forget. They are 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

-     use of these scripts may not be possible, there is a host of
-     other 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
+     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
+     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>
 


@@ -2167,22 +2172,22 @@ 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>


@@ -2198,7 +2203,7 @@ pages for more information and options.
        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'
        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 maintain as much flexibility as possible for
+       jobs easy and to maintain as much flexibility as possible for

        those that want to do things a little differently.</para>
        </listitem>
       </varlistentry>
        those that want to do things a little differently.</para>
        </listitem>
       </varlistentry>


@@ -2221,7 +2226,7 @@ pages for more information and options.
        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
        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. Pat them on the back to make sure the rest of
+       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>
        the world knows it too. It will be appreciated more than you
        expected.</para>
        </listitem>


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

-      This system provides that no one person is stuck doing all of
+      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 newer users with their questions.
      </para>
       the support work and works so that users learn more about the
       program, they can help newer users with their questions.
      </para>


@@ -2303,18 +2308,19 @@ pages for more information and options.
       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
       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 so. It provides a good mailing
+      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>
       list program for a free software project maintainer as opposed
       to a good mailing list application for a mailing list
       administrator.
      </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>


@@ -2325,18 +2331,18 @@ pages for more information and options.
     <para>
      A mailing list and accessible documentation are far from all you
      can do to set up good user support infrastructure. Be
     <para>
      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 works well, email me
-     and I'll include it here in the HOWTO.
+     creative. If you stumble across something that works well, email me
+     and I'll include it here.

     </para>
 
     <sect4>
      <title>Make your self accessible</title>
      <para>
     </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>
 


@@ -2350,12 +2356,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
       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>

-      which has become extremely possible and which I like quite a
-      bit.
+      which has become extremely possible and which I like a lot.

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


@@ -2363,7 +2368,7 @@ 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
+      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>
       bugs and for developers and maintainers to fix them and track
       them in an orderly fashion.
      </para>


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

-    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,
     whet their appetites for versions to come, and encourage them to
     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 versions to come, and encourage them to


@@ -2393,7 +2398,7 @@ 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
      for flexibility and room for imagination by your future
      developers. It's not an easy decision. Ask for help on a local
      is complete enough to be usable and incomplete enough to allow
      for flexibility and room for imagination by your future
      developers. It's not an easy decision. Ask for help on a local


@@ -2409,7 +2414,7 @@ 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>


@@ -2460,8 +2465,8 @@ pages for more information and options.
      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
      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.
+     appropriate place and then making your website reflect the
+     change.

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


@@ -2472,15 +2477,15 @@ 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>
 
     <para>
      The observation is often made that many free software developers
      they are worth.
     </para>
 
     <para>
      The observation is often made that many free software developers

-     seem to be confused about the release cycle.  <ulink
+     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
      url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing

-     Projects the Open Source Way</ulink> suggests that you memorize
+     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>
      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>


@@ -2495,14 +2500,13 @@ pages for more information and options.
        partially functional.</para>
 
        <para>Alpha releases are expected to be unstable, perhaps a
        partially functional.</para>
 
        <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
-       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>
+       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>
 
        </listitem>
       </varlistentry>
 


@@ -2510,7 +2514,8 @@ pages for more information and options.
        <term>beta releases</term>
        <listitem>
        <para>Beta software is feature-complete and functional, but is
        <term>beta releases</term>
        <listitem>
        <para>Beta software is feature-complete and functional, but is

-       in the testing cycle and still has a few bugs in it.</para>
+       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
 
        <para>Beta releases are general expected to be usable and
        slightly unstable, although definitely <emphasis>not


@@ -2520,8 +2525,8 @@ pages for more information and options.
        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
        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
+       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>
        <emphasis>something.</emphasis></para>
        </listitem>
       </varlistentry>


@@ -2529,7 +2534,7 @@ pages for more information and options.
       <varlistentry>
        <term>development releases</term>
        <listitem>
       <varlistentry>
        <term>development releases</term>
        <listitem>

-       <para><quote>Development release</quote> is much more vague
+       <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 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


@@ -2538,10 +2543,10 @@ pages for more information and options.
        url="http://www.enlightenment.org">Enlightenment</ulink> has
        released <emphasis>nothing but</emphasis> development
        releases. Most often, the term is used to describe releases
        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 version of a piece of software in order
-       to keep interest in my project live, this is probably how I
-       would have to label it.</para>
+       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>
 


@@ -2563,7 +2568,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>
 


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

-     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>
    </sect3>
      interesting new releases).
     </para>
    </sect3>


@@ -2641,17 +2646,17 @@ pages for more information and options.
 
      <abstract>
       <para>
 
      <abstract>
       <para>

-       Fogel's <quote>Guide to using CVS in the free software
-       world</quote> is much more than its subitle. In the publishers
+       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
        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 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 information it helped distribute was so important
-       and useful. Please check it or by if you can and are seriously
-       interested in running a free software project.
+       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>
       </para>
      </abstract>
     </biblioset>


@@ -2677,14 +2682,15 @@ pages for more information and options.
       <para>
        While it only briefly talks about free software (and does it by
        tiptoeing around the free software/open source issue with the
       <para>
        While it only briefly talks about free software (and does it by
        tiptoeing around the free software/open source issue with the

-       term <quote>open code</quote>), Lessig 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 future
-       freedoms. In addition to being a quick and enjoyable read, it
-       gives some cool history describes how we
-       <emphasis>need</emphasis> free software in a way more
-       powerfully than anything I've read (outside of <ulink
+       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>
        url="http://www.gnu.org/philosophy/right-to-read.html">RMS's
        <quote>Right to Read.</quote></ulink>
       </para>


@@ -2713,12 +2719,13 @@ pages for more information and options.
        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
        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 sketching the free software process and does an an amazing
-       of job of making an argument for free software/open source
-       development as making better software. The rest of the book has
-       other articles, for the most part posted on his website, but
-       it's nice thing to own in hard copy and something every free
-       software/open source hacker should read.
+       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>
       </para>
      </abstract>
     </biblioset>


@@ -2729,16 +2736,16 @@ pages for more information and options.
    <title>Web-Accessable Resources</title>
 
    <para>
    <title>Web-Accessable Resources</title>
 
    <para>

-    This is a list of the resources pertaining to this HOWTO that I've
-    found most helpful in compiling this information. If you have
-    more, please don't hesitate to email me at
+    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
     <email>mako@debian.org</email> and we can look into getting it

-    added on the list.
+    added to the list and represented in the HOWTO.

    </para>
 
    <para>
     I'd recommend that any free software developer (or potential one)
    </para>
 
    <para>
     I'd recommend that any free software developer (or potential one)

-    skim through these sites becaue they have a lot to say.
+    skim through these sites becaue they have each have a lot to say.

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


@@ -2763,14 +2770,17 @@ 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, orgazing a team and
+       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
        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 and that I've tried to cite it in
-       the places where I borrowed from it most. I have problems with
-       much of the things written in the piece and I recommend you
-       read <xref linkend="krawitz"> at the same time you read Monty's
-       article.
+       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>
       </para>
      </abstract>
     </biblioset>


@@ -2790,9 +2800,9 @@ pages for more information and options.
      <abstract>
       <para>
        A well written article although I think the title may have
      <abstract>
       <para>
        A well written article although I think the title may have

-       confused as many people as it helped. It offers a good
-       description of how to design programs that will succeed and
-       stay maintainable as they grow.
+       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>
       </para>
      </abstract>
     </biblioset>


@@ -2804,26 +2814,26 @@ pages for more information and options.
 
    <para>
     I've found that one of the best resources that any free software
 
    <para>
     I've found that one of the best resources that any free software

-    developer has at his or her disposal is the advogato. If you
-    haven't yet had a chance to visit <ulink
-    url="http://www.advogato.org">the website</ulink>, do.
+    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>
    </para>
 
    <para>

-    I have spent a lot of time on advogato and I've gone through and
-    provided links to the articles that I think are of particular
-    interest to anyone reading this HOWTO. I think that looking
-    through these is important. I promise that 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 about how such a
-    project can be done. I think that's great.
+    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
    </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.
+    relavant articles here with short descriptions that I've written.

    </para>
 
 
    </para>
 
 


@@ -2871,8 +2881,9 @@ pages for more information and options.
      <abstract>
       <para>
        This article touches upon the "writing maintainable code"
      <abstract>
       <para>
        This article touches upon the "writing maintainable code"

-       discussion that I try hard to avoid in my discussion. It's one
-       of the better articles on the subject that I've found.
+       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>
       </para>
      </abstract>
     </biblioset>


@@ -2897,11 +2908,12 @@ pages for more information and options.
        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
        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 argues simply for the application of
-       old project management techniques to free software projects
-       instead of working with something new. I found his article to
-       be extremely well thought out and I think its an essential read
-       for any project manager.
+       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>
       </para>
      </abstract>
     </biblioset>


@@ -2926,10 +2938,11 @@ 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

-       answer to this question can help. In a lot of ways, this HOWTO
-       acts as my answer to the question posed in this article but
-       there are others, many of which might take issue with whats in
-       this HOWTO. It's worth checking out.
+       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>
       </para>
      </abstract>
     </biblioset>


@@ -2957,11 +2970,12 @@ pages for more information and options.
        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
        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. I think this is an important article. If
-       you are interested to become 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).
+       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>
       </para>
      </abstract>
     </biblioset>


@@ -3010,9 +3024,9 @@ pages for more information and options.
     
      <abstract>
       <para>
     
      <abstract>
       <para>

-       I didn't even have a section on naming in this HOWTO (See <xref
-       linkend="naming">) until Leslie Orchard's article reminded me
-       of it. Thanks to Leslie for writing this article! 
+       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>
       </para>
      </abstract>
     </biblioset>


@@ -3035,10 +3049,11 @@ pages for more information and options.
      <abstract>
       <para>
        In this article, David Allen challengs the whole
      <abstract>
       <para>
        In this article, David Allen challengs the whole

-       <quote>Major.Minor.Patch</quote> versioning 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.
+       <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>
       </para>
      </abstract>
     </biblioset>

diff --git a/FreeSoftwareProjectManagementHOWTO.sgml b/FreeSoftwareProjectManagementHOWTO.sgml
index 19375fdddc7799fc93c913c28af61659010665aa..d85158d685b630b3e837b5f4fd936ca9b9f2c88e 100644 (file)
--- a/FreeSoftwareProjectManagementHOWTO.sgml
+++ b/FreeSoftwareProjectManagementHOWTO.sgml
@@ -43,7 +43,7 @@
     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 development
     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 development

-    and was written to act as a crash course in the people skills that
+    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>
     aren't taught to commercial coders but that can make or break a
     free software project.
    </para>


@@ -63,8 +63,8 @@
   <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>
 
    myself, "Why?"
   </para>
 


@@ -186,17 +186,17 @@
     </indexterm>
 
    <para>
     </indexterm>
 
    <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 is the second pre-release of this HOWTO. 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 gets publicized widely.

    </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://people.debian.org/~mako/projects/howto">the projects
+    homepage </ulink> hosted by Debian.

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


@@ -228,7 +228,7 @@
 
     <listitem>
      <para>
 
     <listitem>
      <para>

-      <ulink url="http://people.debian.org/~mako/projects/howto/FreeSoftwareDevelopment-HOWTO.ps.gz">compressed postscript</ulink>.
+      <ulink url="http://people.debian.org/~mako/projects/howto/FreeSoftwareDevelopment-HOWTO.ps.gz">Compressed postscript</ulink>.

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


@@ -262,11 +262,11 @@
     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
     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

-    several translations of the chapters on CVS. I you are seriously
+    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
     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, and I'll try and have those fixed in future versions.
+    sorry. I'll try and have those fixed in future versions.

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


@@ -277,14 +277,14 @@
    <para>
     Also providing support material, and inspiration for this HOWTO is
     Eric S. Raymond for his prolific, consistent, and carefully
    <para>
     Also providing support material, and inspiration for this HOWTO is
     Eric S. Raymond for his prolific, consistent, and carefully

-    crafted arguments, Lawrence Lessig for reminding me of the
+    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
     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
+    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 how have been involved with the movement much longer than I,
     advocacy, a place to make a difference, a place to learn from
     those how have been involved with the movement much longer than I,

-    and proof of a Free Software project that definitely, definitely
+    and proof of a free software project that definitely, definitely

     works.
    </para>
 
     works.
    </para>
 


@@ -292,7 +292,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 towards 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>


@@ -311,9 +311,10 @@
     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
     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 this
-    fact. Please send your additions, comments and criticisms to the
-    following email address : <email>mako@debian. org</email>.
+    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>
 


@@ -325,7 +326,7 @@
    <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>
 
    <para>


@@ -350,19 +351,18 @@
     <primary>fswd!starting</primary>
    </indexterm>
   <para>
     <primary>fswd!starting</primary>
    </indexterm>
   <para>

-   With very little argument, the beginning is most difficult part of
-   successful free software development. Laying a firm foundation will
-   determine whether your project flourishes or withers away and
+   With very little argument, the beginning is the most difficult part
+   of successful free software development. 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>
    Starting a project involves a dilemma that you as a developer must
    dies. It is also the subject that is of most immediate interest to
    anyone reading this document as a tutorial.
   </para>
 
   <para>
    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. Simultaneously, the development
-   process that you want to employ holds involvement of users as
-   prerequisit to working software.
+   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>
   </para>
 
   <para>


@@ -382,27 +382,28 @@
 
    <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 in a percieved gap by doing something that no other
-    free software process does or by doing something in a way the 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, <quote>The Cathedral and the Bazaar,</quote> which
-     comes as required reading for any free software development. It
-     is available <ulink
+     his essay, <quote>The Cathedral and the Bazaar,</quote> which
+     comes as required reading for any free software developer. It is
+     available <ulink

      url="http://www.tuxedo.org/~esr/writings/cathedral-bazaar/">online
      </ulink>.
     </para>
 
     <para>
      In <quote>The Cathedral and the Bazaar,</quote> Raymond tells us
      url="http://www.tuxedo.org/~esr/writings/cathedral-bazaar/">online
      </ulink>.
     </para>
 
     <para>
      In <quote>The Cathedral and the Bazaar,</quote> Raymond tells us

-     that: <emphasis>Every good work of software starts by scratching
-     a developers itch.</emphasis> Raymond's now widely accepted
+     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>
      hypothesis is that new free software programs are written, first
      and foremost, to solve a specific problem facing the developer.
     </para>


@@ -410,23 +411,24 @@
     <para>
      If you have an idea for a program in mind, chances are good that
      it targets a specific problem or <quote>itch</quote> you want to
     <para>
      If you have an idea for a program in mind, chances are good that
      it targets a specific problem or <quote>itch</quote> you want to

-     see scratched. 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.
+     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>
     </para>
 
     <para>

-     Monty Manley articles the importance of this initial step in an
-     essay, <ulink
+     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
      url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing

-     Projects the Open Source Way.</ulink> As the next section will
-     show, there is <emphasis>a lot</emphasis> of work that needs to
-     be done before software is ready for release. Manley says,
-     <quote>Beginning an OSS project properly means that a developer
-     must, first and foremost, avoid writing code too soon!</quote>
+     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>
 


@@ -435,24 +437,29 @@
 
     <para>
      In evaluating your idea, you need to first ask yourself a few
 
     <para>
      In evaluating your idea, you need to first ask yourself a few

-     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 in solitude
-     fails to qualify as a free software development effort, you need
-     to ask yourself the question: <emphasis>Is anybody else
-     interested?</emphasis>
+     questions.  This should happen before you move any further
+     through this HOWTO. Ask yourself: <emphasis>Is the free software
+     development model really is the right one for your
+     project?</emphasis>

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

-     Sometimes the answer is a simple <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.
+     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>
+     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>


@@ -460,7 +467,7 @@
      chances are, there is someone, somewhere, who shares your
      interests and how feels the same <quote>itch.</quote> It is the
      fact that there are so many people with so many similar needs and
      chances are, there is someone, somewhere, who shares your
      interests and how 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 second major question: <emphasis>Has
+     desires that introduces the third major question: <emphasis>Has

      somebody already had your idea or a reasonably similar
      one?</emphasis>
     </para>
      somebody already had your idea or a reasonably similar
      one?</emphasis>
     </para>


@@ -471,7 +478,7 @@
      <para>
       There are places you can go on the web to try and answer the
       question above. If you have experience with the free software
      <para>
       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 all of these
+      community, you are probably already familiar with many of these

       sites. All of the resources listed bellow offer searching of
       their databases:
      </para>
       sites. All of the resources listed bellow offer searching of
       their databases:
      </para>


@@ -479,19 +486,19 @@
      <para>
      <variablelist>
        <varlistentry>
      <para>
      <variablelist>
        <varlistentry>

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

         <listitem>
         <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
         these lines is totally unparalleled and unquestioned. If you
         can't find it on freshmeat, its doubtful that you (or anyone
         <listitem>
         <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
         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 anywhere.</para>
+        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>
         provides <quote>News for Nerds: Stuff that Matters,</quote>
         <listitem>
         <para><ulink url="http://slashdot.org">Slashdot</ulink>
         provides <quote>News for Nerds: Stuff that Matters,</quote>


@@ -503,7 +510,7 @@
        </varlistentry>
 
        <varlistentry>
        </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


@@ -512,26 +519,26 @@
         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
         provides a at <ulink
         url="http://sourceforge.net/snippet/">Code Snippet
         Library</ulink> which contains useful reusable chunks of code
         embarking on a new free software project. SourceForge also
         provides a at <ulink
         url="http://sourceforge.net/snippet/">Code Snippet
         Library</ulink> which contains useful reusable chunks of code

-        in an array of languaqges which can come in useful in any
+        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>, 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 to make sure you aren't pouring your effort into a
+        redundant project.</para>

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


@@ -542,16 +549,16 @@
     <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 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
+      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

       project?</quote>
      </para>
 
       project?</quote>
      </para>
 


@@ -563,15 +570,16 @@
      </para>
 
      <para>
      </para>
 
      <para>

-      This may be the single most difficult aspect of free software
-      development for many developers but it is an essential one. It
-      is easy to become fired up by an idea and be caught up in the
+      For many developers this may be the single most difficult aspect
+      of free software development but it is an essential one. It is
+      easy to become fired up by an idea and be 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 remember that the best interests of the free software
       momentum and excitement of a new project. It is often extremely
       difficult to do but, it is important that any free software
       developer remember that the best interests 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.
+      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>
      </para>
 
     </sect4>


@@ -586,50 +594,52 @@
    <para>
     While there are plenty of projects that fail with descriptive
     names and plenty that succeed without them, I think naming your
    <para>
     While there are plenty of projects that fail with descriptive
     names and plenty that succeed without them, I think naming your

-    project is wroth giving a little bit of thought. Leslie Orchard
-    tackles this issue in a n <ulink
-    url="http://www.advogato.org/article/67.html">advogato
-    article</ulink>. The article is short and probably worth looking
+    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>
     over quickly.
    </para>
 
    <para>

-    The very short version is that Orchard recommends that you should
-    pick a name where, after hearing the name, many users or
-    developers will:
+    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>
 
    <para>
     <itemizedlist>
      <listitem>

-      <para>You will know what the project does.</para>
+      <para>Know what the project does.</para>

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

-      <para>You will remember it tomorrow.</para>
+      <para>Remember it tomorrow.</para>

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

-    Humorously, Orchard's project, Iajitsu, does neither (and
-    development is effectively frozen since the article was written).
+    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>
    </para>
 
    <para>

-    There is a point though. There are companies who only job is to
-    make names for pieces of software. They make
-    <emphasis>ridiculous</emphasis> amount of money doing it and they
-    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.
+    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>
    </para>
 
    <para>

-    If there is a name you really want, go ahead. I though
-    <quote>gnubile</quote> was one of the best names ever and I still
-    talk about it, long after I've stopped using the program. If you
-    can flexible on the subject, listen to Orchard's advice. It might
-    even help you.
+    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 flexible on the subject, listen to
+    Orchard's advice. It might help you.

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


@@ -655,7 +665,7 @@
      small flame war as there are strong feelings that some free
      software licenses are better than others. This discussion also
      brings up the question of <quote>Open Source Software</quote> and
      small flame war as there are strong feelings that some free
      software licenses are better than others. This discussion also
      brings up the question of <quote>Open Source Software</quote> and

-     the debate around <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 Development HOWTO and not the Open Source
      Development HOWTO, my own allegiances in this argument are in the
      <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 in the


@@ -664,26 +674,27 @@
 
     <para>
      In attempting to reach a middle ground through diplomacy without
 
     <para>
      In attempting to reach a middle ground through diplomacy without

-     sacrificing my own philosophy, I recommend picking any license
-     that conforms to the <ulink
+     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
      Guidelines</ulink>. Originally compiled by the Debian project
      url="http://www.debian.org/social_contract">Debian Free Software
      Guidelines</ulink>. Originally compiled by the Debian project

-     under Bruce Perens, the <acronym>DFSG</acronym> form the first
-     version of the Open Source definition. Examples of free licenses
-     given by the <acronym>DFSG</acronym> are the
-     <acronym>GPL</acronym>, the <acronym>BSD</acronym>, and the
-     Artistic License. 
+     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>
     </para>
 
     <para>

-     Conforming to the definition of Free Software offered by Richard
+     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
      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,
+     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>
      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 common license will offer the advantage
+     but sticking with a more well-known license will offer the advantage

      of immediate recognition and understanding.
     </para>
 
      of immediate recognition and understanding.
     </para>
 


@@ -702,14 +713,14 @@
      GNOME, Emacs, and the vast majority of GNU/Linux software. It's
      the obvious choice but I believe it is a good one. Any BSD
      fanatic will urge you to remember that there is a viral aspect to
      GNOME, Emacs, and the vast majority of GNU/Linux software. It's
      the obvious choice but I 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
+     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>
      <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>

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


@@ -732,8 +743,8 @@
 
     <para>
      <emphasis>In any case, please read through any license before
 
     <para>
      <emphasis>In any case, please read through any license before

-     your release your software. As the primary developer, you can't
-     afford any license surprises.</emphasis>
+     your release your software under it. As the primary developer,
+     you can't afford any license surprises.</emphasis>

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


@@ -752,15 +763,15 @@
      
       <listitem>
        <para>If at all possible, attach and distribute a full copy of
      
       <listitem>
        <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>
       </listitem>
 
       <listitem>
        <para>At the top of each source file in your program, attach a
        file.</para>
       </listitem>
 
       <listitem>
        <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>


@@ -783,8 +794,8 @@ 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>
       </listitem>
 
       </para>
       </listitem>
 


@@ -793,8 +804,8 @@ Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
         The <acronym>GPL</acronym> continues and suggests that if your
         program runs in an interactive mode, you should write the
         program to output a notice each time it enters interactive
         The <acronym>GPL</acronym> continues and suggests that if your
         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 more
-        information about the programs licensing:
+        mode that includes a message like this one that points to full
+        information about the programs license:

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


@@ -808,12 +819,12 @@ for details.
 
       <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 later on. Its often needed but there
-       are plenty of free software developers who have gotten into
-       trouble and wish they had attained one.</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>
 
      </itemizedlist>
       </listitem>
 
      </itemizedlist>


@@ -824,17 +835,17 @@ for details.
     <title>Final license warning</title>
 
     <para>
     <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 <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 you have no license, your program 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.
+     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>


@@ -865,15 +876,16 @@ for details.
    </para>
 
    <para>
    </para>
 
    <para>

-    Beyond this, the most common technique seems to be the
-    <quote>major level</quote>, <quote>minor level</quote>,
+    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
     <quote>patch level</quote> version numbering scheme. Whether you

-    are familiar with it or not, you interact with it all the
+    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
     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 bug fixes.
+    usually will only refer to releases fixing bugs.

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


@@ -884,17 +896,16 @@ for details.
    </para>
 
    <para>
    </para>
 
    <para>

-    You can bend or break these rules, and people do. Beware, if you
-    choose to, someone will get annoyed, assume you don't know, and
-    try and educate you. I always follow this method and I implore you
-    to do so as well.
+    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>

- 
+   

    <para>
    <para>

-    Follow these two simple rules and you will not go (too)
-    wrong. Still, there are several version numbering systems that are
-    well known, useful, and that might be worth looking into before
-    you release your first version.
+    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>
    </para>
 
    <variablelist>


@@ -916,14 +927,15 @@ 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
-       progress development 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
-       worth taking into consideration.
+       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>
      </listitem>
     </varlistentry>
       </para>
      </listitem>
     </varlistentry>


@@ -934,11 +946,12 @@ for details.
       <para>Because of the unusual nature of wine's development where
       the not-emulator is constantly improving but not working towards
       any immediately achievable goal, wine is released every three
       <para>Because of the unusual nature of wine's development where
       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 Year Month
-      Day format where each release might be labeled
+      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
       <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.
+      projects, <quote>Year Month Day</quote> format can make a lot of
+      sense.

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


@@ -948,8 +961,8 @@ for details.
      <listitem>
       <para>When one considers Netscape 6 and vendor versions, the
       mozilla's project development structure is one of the most
      <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>
 
       developed.
       </para>
 


@@ -960,17 +973,18 @@ for details.
        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
        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, 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.
+       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>
      </listitem>
     </varlistentry>
       </para>
      </listitem>
     </varlistentry>


@@ -995,13 +1009,12 @@ for details.
    </para>
 
    <para>
    </para>
 
    <para>

-    There are lots of different people for whom to document and
-    therefore there are lots of ways to document your
-    project. <emphasis>The importance of ocumentation in source code
-    to help facilitate development by a large community is vital but
-    it falls outside the scope of this HOWTO.</emphasis> 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>
    </para>
 
    <para>


@@ -1018,17 +1031,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

-    projectname</quote> end up with a nicely formatted man page
-    highlighting the basic use of yourapplication. Make sure that
+    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
     before you release your program, you've planned for this.
     </para>
 
     <para>
      Man pages are not difficult to write. There is excellent

-     documentation on the man page writing 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


@@ -1036,11 +1049,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 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 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>
 


@@ -1053,8 +1066,8 @@ for details.
      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
      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, all the major options (also with
-     explanations), and a pointer to more in-depth documentation for
+     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>


@@ -1102,8 +1115,8 @@ pages for more information and options.
      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>
 


@@ -1115,8 +1128,8 @@ pages for more information and options.
      package containing source code. In a source distribution, most of
      these files can be stored in a the root directory of the source
      distribution or in a subdirectory of the root called
      package containing source code. In a source distribution, most of
      these files can be stored in a the root directory of the source
      distribution or in a subdirectory of the root called

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

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


@@ -1128,9 +1141,9 @@ pages for more information and options.
        <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
        <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>
+       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>


@@ -1143,30 +1156,27 @@ pages for more information and options.
        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
        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. More advanced users can usually avoid
-       INSTALL files but it's good practice to at least glance at one
-       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>
+       that may be necessary. For most relatively standard install
+       procedures and for most programs, INSTALL files are as short
+       as possible are rarely over 100 lines.</para>

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

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

 
        <listitem>
 
        <listitem>

-       <para>A changelog is a simple file that every well-managed
-       free software project should include. A changelog is simple
+       <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
        the file that, as its name implies, 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>
+       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>
        </listitem>
 
       </varlistentry>


@@ -1174,13 +1184,14 @@ pages for more information and options.
        <term>NEWS</term>
 
        <listitem>
        <term>NEWS</term>
 
        <listitem>

-       <para>A NEWS file and a ChangeLog are similar. A news file is
-       not typically sorted by version but just whenever new features
-       are added, the developer responisble will make a note in the
-       NEWS file. NEWS files should not have to 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 people
-       just forget to keep them as current as they should.</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>


@@ -1188,15 +1199,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 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 it 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>
+       <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>


@@ -1207,32 +1218,21 @@ pages for more information and options.
    <sect3>
     <title>Website</title> 
     <para>
    <sect3>
     <title>Website</title> 
     <para>

-     It's only idirectly 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's documentation. 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 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
-     provide a direct link to all the available ways of downloading
-     your software.
+     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
+     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


@@ -1242,6 +1242,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
+     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>
 


@@ -1252,9 +1260,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 issues. 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>


@@ -1267,26 +1276,56 @@ 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. Your users or fellow
-     developers can and will do the the binary packages for
-     you.</emphasis>
+     relationships with users or developers of large distributiosn 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>
+
+   <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
+     (already has) its own HOWTO.

     </para>
     </para>

+

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


@@ -1303,15 +1342,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. Keep in mind that this
-        location will recieve many requests for downloads around
-        releases so make sure that the server you choose for this
-        purpose has adequate bandwidth.
+        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>
 


@@ -1320,44 +1358,17 @@ 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. It also will allow for more than one person
-        to deal with the influx of mail that is created if your
+        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>
       </listitem>
 
      </itemizedlist>
     </para>
         project becomes as huge as you hope it will.
        </para>
       </listitem>
 
      </itemizedlist>
     </para>

-
-    <para>
-     A version control system can make a lot of these problems of
-     packaging (and a lot of other problems mentioned in this HOWTO)
-     much easier. 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 introduced into this HOWTO.
-     I am not aware of any free version control systems for windows or
-     mac 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 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 version straight on this HOWTO!) but I
-     think it falls outside the scope of this document and should/has
-     already have its own HOWTO written about it.
-    </para>

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


@@ -1376,10 +1387,11 @@ pages for more information and options.
    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
    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

-   process itself is equally important and provides quite a few
-   opportunities for failure. In the next two sections, I will cover
-   running a project by discussing how to maintain a project through
-   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>


@@ -1413,7 +1425,7 @@ pages for more information and options.
    <para>
     By now, you've hypothetically followed me through the early
     programming of a piece of software, the creation of a website and
    <para>
     By now, you've hypothetically followed me through the early
     programming of a piece of software, the creation of a website and

-    system of documentation and and we've gone ahead and (as will be
+    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.


@@ -1421,48 +1433,48 @@ 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. 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.
+    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
    </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 been the death of a project. <ulink
+    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
     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

-    projects founder and that these important powers need not all rest
-    in one person but that a release manager may be different than a
-    lead developer. These situations are tricky politically though so
-    be careful and make sure this is necessary before you go around
+    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>
 
     empowering people.
    </para>
 


@@ -1472,8 +1484,8 @@ pages for more information and options.
     <para>
      You may find that other developers seem even more experienced or
      knowledgeable than you. Your job as a maintainer does not mean
     <para>
      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
+     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>
      recognizing which solutions are maintainable and which are not. 
     </para>
     <para>


@@ -1486,7 +1498,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>
 


@@ -1502,9 +1514,9 @@ 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
+      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
       the project is determined by the project's <ulink
       url="http://www.debian.org/social_contract">social
       contract</ulink> and a <ulink


@@ -1512,7 +1524,7 @@ pages for more information and options.
       facilitate this system, there are special teams (i.e. the
       install team, the Japanese language team) as well as a technical
       committee and a project leader. The leader's main responsibility
       facilitate this system, there are special teams (i.e. the
       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
+      is to, <quote>appoint delegates or delegate decisions to the

       Technical Committee.</quote>
      </para>
 
       Technical Committee.</quote>
      </para>
 


@@ -1529,7 +1541,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


@@ -1541,7 +1553,7 @@ 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
       a certain person and its a great way of giving yourself room to
       breath.
       clearly defining a chunk of work on the project as belonging to
       a certain person and its a great way of giving yourself room to
       breath.


@@ -1549,7 +1561,7 @@ pages for more information and options.
     </sect4>
 
     <sect4 id="delegatebranch">
     </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
      <para>
       If your project chooses to have branches (as described in <xref
       linkend="branches">), it might be a good idea to appoint someone


@@ -1577,7 +1589,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>


@@ -1622,7 +1634,7 @@ pages for more information and options.
     </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>


@@ -1646,11 +1658,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>
 


@@ -1658,17 +1670,16 @@ 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>
     </para>
 
     <sect4>


@@ -1679,11 +1690,12 @@ pages for more information and options.
       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
       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

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


@@ -1700,20 +1712,20 @@ 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, 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 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 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
-      making 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>
 


@@ -1736,9 +1748,9 @@ pages for more information and options.
       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
       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 after putting a
-      large deal of time, thought, and energy into it, you remember
+      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.
       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.


@@ -1767,21 +1779,22 @@ pages for more information and options.
     The most common way of branching your project is to have one
     branch that is stable and one that is for development. This is the
     model followed by the Linux kernel that is described in <xref
     The most common way of branching your project is to have one
     branch that is stable and one that is for development. This is the
     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> 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>
-    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
+    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>
+    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,
     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,


@@ -1807,8 +1820,8 @@ pages for more information and options.
       <listitem>
        <para>Debian may be able to make good use of four or five
        branches but it contains gigabytes of software in over 5000
       <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. For you,
-       two is probably a good number. Too many branches will confuse
+       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
        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


@@ -1823,8 +1836,8 @@ pages for more information and options.
        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
        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>
+       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


@@ -1854,12 +1867,12 @@ pages for more information and options.
        <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
        <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 in different directories or directory
-       trees on your <acronym>FTP</acronym> or <acronym>HTTP</acronym>
-       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
+       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
        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


@@ -1868,8 +1881,8 @@ pages for more information and options.
        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
        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>
+       other so your users know exactly what they want and where to
+       get it.</para>

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


@@ -1885,7 +1898,7 @@ pages for more information and options.
    <para>
     There are more issues surrounding interaction with developers in a
     free software project that I can not touch on in great detail in a
    <para>
     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. Please don't hesitate to contact me if you see
+    HOWTO of this size and scope. Please don't hesitate to contact me if you see

     any major omissions.
    </para>
 
     any major omissions.
    </para>
 


@@ -1917,19 +1930,19 @@ 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>
      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
     </para>
 
     <para>
      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="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>


@@ -1937,11 +1950,11 @@ pages for more information and options.
    <sect3>
     <title>Forking</title>
     <para>
    <sect3>
     <title>Forking</title>
     <para>

-     Forks are the most extreme version of a branch. A fork is
+     Forks are like the most extreme version 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
      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
+     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.
      but for technical, political, and philosophical reasons,
      development was split into two projects which now compete with
      each other.


@@ -1950,10 +1963,10 @@ pages for more information and options.
     <para>
      The short version of the fork section is, <emphasis>don't do
      them.</emphasis> Forks force developers to choose one project to
     <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 and redundancy of
+     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
      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.
+     they run their project.

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


@@ -2009,7 +2022,7 @@ 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
      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


@@ -2024,12 +2037,12 @@ pages for more information and options.
     <listitem>
      <para>In an almost paradoxical situation, free software projects
      have less immediate or dire consequences for ignoring their users
     <listitem>
      <para>In an almost paradoxical situation, free software projects
      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 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 a commitment to your users or by both.</para>
+     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>


@@ -2054,27 +2067,27 @@ 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> of your
-    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
     all of your users want to be testers. Many users want to use
    </para>
 
    <para>
     It is important that this distinction be made early on because not
     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 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.
+    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>
    </para>
 
    <para>

-     <ulink
+     <quote><ulink

      url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing
      url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing

-     Projects the Open Source Way</ulink> describes what a good test
-     should look for in each module:
+     Projects the Open Source Way</ulink></quote> describes what a
+     good test should look for:

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


@@ -2082,10 +2095,8 @@ pages for more information and options.
      <term>Boundary conditions</term>
 
      <listitem>
      <term>Boundary conditions</term>
 
      <listitem>

-      <para>
-       Maximum buffer lengths, data conversions, upper/lower boundary
-       limits, and so on.
-      </para>
+      <para>Maximum buffer lengths, data conversions, upper/lower
+      boundary limits, and so on.</para>

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


@@ -2093,14 +2104,12 @@ pages for more information and options.
      <term>Inappropriate behavior</term>
 
      <listitem>
      <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 what if questions and think of
-       anything that <emphasis>might</emphasis> fail or
-       <emphasis>might</emphasis> go wrong and find out what program
-       would do in that case.
-      </para>
+      <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>
      </listitem>
 
     </varlistentry>


@@ -2108,14 +2117,12 @@ pages for more information and options.
      <term>Graceful failure</term>
 
      <listitem>
      <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>
+      <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>
      </listitem>
 
     </varlistentry>


@@ -2124,13 +2131,11 @@ pages for more information and options.
      <term>Standards conformance</term>
 
      <listitem>
      <term>Standards conformance</term>
 
      <listitem>

-      <para>
-       If possible, make sure your programs conforms to
-       standards. 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>
+      <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>
      </listitem>
 
     </varlistentry>


@@ -2142,22 +2147,22 @@ pages for more information and options.
      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
      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

-     something you just forget. They are 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

-     use of these scripts may not be possible, there is a host of
-     other 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
+     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
+     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>
 


@@ -2167,22 +2172,22 @@ 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>


@@ -2198,7 +2203,7 @@ pages for more information and options.
        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'
        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 maintain as much flexibility as possible for
+       jobs easy and to maintain as much flexibility as possible for

        those that want to do things a little differently.</para>
        </listitem>
       </varlistentry>
        those that want to do things a little differently.</para>
        </listitem>
       </varlistentry>


@@ -2221,7 +2226,7 @@ pages for more information and options.
        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
        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. Pat them on the back to make sure the rest of
+       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>
        the world knows it too. It will be appreciated more than you
        expected.</para>
        </listitem>


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

-      This system provides that no one person is stuck doing all of
+      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 newer users with their questions.
      </para>
       the support work and works so that users learn more about the
       program, they can help newer users with their questions.
      </para>


@@ -2303,18 +2308,19 @@ pages for more information and options.
       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
       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 so. It provides a good mailing
+      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>
       list program for a free software project maintainer as opposed
       to a good mailing list application for a mailing list
       administrator.
      </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>


@@ -2325,18 +2331,18 @@ pages for more information and options.
     <para>
      A mailing list and accessible documentation are far from all you
      can do to set up good user support infrastructure. Be
     <para>
      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 works well, email me
-     and I'll include it here in the HOWTO.
+     creative. If you stumble across something that works well, email me
+     and I'll include it here.

     </para>
 
     <sect4>
      <title>Make your self accessible</title>
      <para>
     </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>
 


@@ -2350,12 +2356,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
       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>

-      which has become extremely possible and which I like quite a
-      bit.
+      which has become extremely possible and which I like a lot.

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


@@ -2363,7 +2368,7 @@ 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
+      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>
       bugs and for developers and maintainers to fix them and track
       them in an orderly fashion.
      </para>


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

-    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,
     whet their appetites for versions to come, and encourage them to
     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 versions to come, and encourage them to


@@ -2393,7 +2398,7 @@ 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
      for flexibility and room for imagination by your future
      developers. It's not an easy decision. Ask for help on a local
      is complete enough to be usable and incomplete enough to allow
      for flexibility and room for imagination by your future
      developers. It's not an easy decision. Ask for help on a local


@@ -2409,7 +2414,7 @@ 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>


@@ -2460,8 +2465,8 @@ pages for more information and options.
      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
      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.
+     appropriate place and then making your website reflect the
+     change.

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


@@ -2472,15 +2477,15 @@ 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>
 
     <para>
      The observation is often made that many free software developers
      they are worth.
     </para>
 
     <para>
      The observation is often made that many free software developers

-     seem to be confused about the release cycle.  <ulink
+     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
      url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing

-     Projects the Open Source Way</ulink> suggests that you memorize
+     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>
      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>


@@ -2495,14 +2500,13 @@ pages for more information and options.
        partially functional.</para>
 
        <para>Alpha releases are expected to be unstable, perhaps a
        partially functional.</para>
 
        <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
-       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>
+       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>
 
        </listitem>
       </varlistentry>
 


@@ -2510,7 +2514,8 @@ pages for more information and options.
        <term>beta releases</term>
        <listitem>
        <para>Beta software is feature-complete and functional, but is
        <term>beta releases</term>
        <listitem>
        <para>Beta software is feature-complete and functional, but is

-       in the testing cycle and still has a few bugs in it.</para>
+       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
 
        <para>Beta releases are general expected to be usable and
        slightly unstable, although definitely <emphasis>not


@@ -2520,8 +2525,8 @@ pages for more information and options.
        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
        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
+       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>
        <emphasis>something.</emphasis></para>
        </listitem>
       </varlistentry>


@@ -2529,7 +2534,7 @@ pages for more information and options.
       <varlistentry>
        <term>development releases</term>
        <listitem>
       <varlistentry>
        <term>development releases</term>
        <listitem>

-       <para><quote>Development release</quote> is much more vague
+       <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 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


@@ -2538,10 +2543,10 @@ pages for more information and options.
        url="http://www.enlightenment.org">Enlightenment</ulink> has
        released <emphasis>nothing but</emphasis> development
        releases. Most often, the term is used to describe releases
        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 version of a piece of software in order
-       to keep interest in my project live, this is probably how I
-       would have to label it.</para>
+       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>
 


@@ -2563,7 +2568,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>
 


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

-     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>
    </sect3>
      interesting new releases).
     </para>
    </sect3>


@@ -2641,17 +2646,17 @@ pages for more information and options.
 
      <abstract>
       <para>
 
      <abstract>
       <para>

-       Fogel's <quote>Guide to using CVS in the free software
-       world</quote> is much more than its subitle. In the publishers
+       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
        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 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 information it helped distribute was so important
-       and useful. Please check it or by if you can and are seriously
-       interested in running a free software project.
+       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>
       </para>
      </abstract>
     </biblioset>


@@ -2677,14 +2682,15 @@ pages for more information and options.
       <para>
        While it only briefly talks about free software (and does it by
        tiptoeing around the free software/open source issue with the
       <para>
        While it only briefly talks about free software (and does it by
        tiptoeing around the free software/open source issue with the

-       term <quote>open code</quote>), Lessig 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 future
-       freedoms. In addition to being a quick and enjoyable read, it
-       gives some cool history describes how we
-       <emphasis>need</emphasis> free software in a way more
-       powerfully than anything I've read (outside of <ulink
+       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>
        url="http://www.gnu.org/philosophy/right-to-read.html">RMS's
        <quote>Right to Read.</quote></ulink>
       </para>


@@ -2713,12 +2719,13 @@ pages for more information and options.
        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
        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 sketching the free software process and does an an amazing
-       of job of making an argument for free software/open source
-       development as making better software. The rest of the book has
-       other articles, for the most part posted on his website, but
-       it's nice thing to own in hard copy and something every free
-       software/open source hacker should read.
+       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>
       </para>
      </abstract>
     </biblioset>


@@ -2729,16 +2736,16 @@ pages for more information and options.
    <title>Web-Accessable Resources</title>
 
    <para>
    <title>Web-Accessable Resources</title>
 
    <para>

-    This is a list of the resources pertaining to this HOWTO that I've
-    found most helpful in compiling this information. If you have
-    more, please don't hesitate to email me at
+    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
     <email>mako@debian.org</email> and we can look into getting it

-    added on the list.
+    added to the list and represented in the HOWTO.

    </para>
 
    <para>
     I'd recommend that any free software developer (or potential one)
    </para>
 
    <para>
     I'd recommend that any free software developer (or potential one)

-    skim through these sites becaue they have a lot to say.
+    skim through these sites becaue they have each have a lot to say.

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


@@ -2763,14 +2770,17 @@ 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, orgazing a team and
+       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
        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 and that I've tried to cite it in
-       the places where I borrowed from it most. I have problems with
-       much of the things written in the piece and I recommend you
-       read <xref linkend="krawitz"> at the same time you read Monty's
-       article.
+       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>
       </para>
      </abstract>
     </biblioset>


@@ -2790,9 +2800,9 @@ pages for more information and options.
      <abstract>
       <para>
        A well written article although I think the title may have
      <abstract>
       <para>
        A well written article although I think the title may have

-       confused as many people as it helped. It offers a good
-       description of how to design programs that will succeed and
-       stay maintainable as they grow.
+       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>
       </para>
      </abstract>
     </biblioset>


@@ -2804,26 +2814,26 @@ pages for more information and options.
 
    <para>
     I've found that one of the best resources that any free software
 
    <para>
     I've found that one of the best resources that any free software

-    developer has at his or her disposal is the advogato. If you
-    haven't yet had a chance to visit <ulink
-    url="http://www.advogato.org">the website</ulink>, do.
+    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>
    </para>
 
    <para>

-    I have spent a lot of time on advogato and I've gone through and
-    provided links to the articles that I think are of particular
-    interest to anyone reading this HOWTO. I think that looking
-    through these is important. I promise that 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 about how such a
-    project can be done. I think that's great.
+    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
    </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.
+    relavant articles here with short descriptions that I've written.

    </para>
 
 
    </para>
 
 


@@ -2871,8 +2881,9 @@ pages for more information and options.
      <abstract>
       <para>
        This article touches upon the "writing maintainable code"
      <abstract>
       <para>
        This article touches upon the "writing maintainable code"

-       discussion that I try hard to avoid in my discussion. It's one
-       of the better articles on the subject that I've found.
+       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>
       </para>
      </abstract>
     </biblioset>


@@ -2897,11 +2908,12 @@ pages for more information and options.
        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
        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 argues simply for the application of
-       old project management techniques to free software projects
-       instead of working with something new. I found his article to
-       be extremely well thought out and I think its an essential read
-       for any project manager.
+       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>
       </para>
      </abstract>
     </biblioset>


@@ -2926,10 +2938,11 @@ 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

-       answer to this question can help. In a lot of ways, this HOWTO
-       acts as my answer to the question posed in this article but
-       there are others, many of which might take issue with whats in
-       this HOWTO. It's worth checking out.
+       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>
       </para>
      </abstract>
     </biblioset>


@@ -2957,11 +2970,12 @@ pages for more information and options.
        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
        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. I think this is an important article. If
-       you are interested to become 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).
+       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>
       </para>
      </abstract>
     </biblioset>


@@ -3010,9 +3024,9 @@ pages for more information and options.
     
      <abstract>
       <para>
     
      <abstract>
       <para>

-       I didn't even have a section on naming in this HOWTO (See <xref
-       linkend="naming">) until Leslie Orchard's article reminded me
-       of it. Thanks to Leslie for writing this article! 
+       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>
       </para>
      </abstract>
     </biblioset>


@@ -3035,10 +3049,11 @@ pages for more information and options.
      <abstract>
       <para>
        In this article, David Allen challengs the whole
      <abstract>
       <para>
        In this article, David Allen challengs the whole

-       <quote>Major.Minor.Patch</quote> versioning 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.
+       <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>
       </para>
      </abstract>
     </biblioset>

diff --git a/TODO b/TODO
index fdb954db77343943e72c01795000ec57e22206ee..c5f5401fedc3278d2b3fa67c875ef813398c6034 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,11 +1,3 @@
 ============================================
 == TODO - Free Software Development HOWTO ==
 ============================================
 ============================================
 == TODO - Free Software Development HOWTO ==
 ============================================

-
-* A paragraph on CVS and other version control systems. Maybe
-  something on sourcesafe which is for windows (I don't know if its
-  free software). (Andy King)
-
-* I need to do a final read through because v0.01 has a lot of
-  gramatical errors but not really any spelling errors. A read out of
-  a printed copy may make that kind of checking a lot easier. (Jaime)
\ No newline at end of file