Finished the first draft of the HOWTO --AND-- spelled check the entire

Author: mako
Date: 2001/03/27 03:28:56
Finished the first draft of the HOWTO --AND-- spelled check the entire
thing. Every section should be filled in. A final read through and
something that describes how webserves and ftp servers should have the
necessary bandwidth before a program is released.

diff --git a/FreeSoftwareDevelopmentHOWTO.sgml b/FreeSoftwareDevelopmentHOWTO.sgml
index ad8e78fca92668f97ad78843d822a183b00189c9..e81b8337c97debe808b16ae8581484c694941f36 100644 (file)
--- a/FreeSoftwareDevelopmentHOWTO.sgml
+++ b/FreeSoftwareDevelopmentHOWTO.sgml
@@ -58,8 +58,8 @@
    </indexterm>
 
   <para>
    </indexterm>
 
   <para>

-   For various reasons, this realease has been codenamed the
-   <emphasis>homade yogurt</emphasis> release.
+   For various reasons, this release has been code-named the
+   <emphasis>homemade yogurt</emphasis> release.

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


@@ -69,7 +69,7 @@
   </para>
 
   <para>
   </para>
 
   <para>

-   Skimming through Freshmeat provides mountains of reasons for this
+   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
    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


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

-   write a beautiful, relevent piece of software and follow every
+   write a beautiful, relevant piece of software and follow every

    instruction in this HOWTO and your software may still not make
    it. Sometimes life is like that. However, I'll go out a limb and
    say that if you write a great, relevant pieces of software and
    instruction in this HOWTO and your software may still not make
    it. Sometimes life is like that. However, I'll go out a limb and
    say that if you write a great, relevant pieces of software and


@@ -265,7 +265,7 @@
    <para>
     <emphasis>Karl Fogel</emphasis>, the author of <emphasis>Open
     Source Development with CVS</emphasis> published by the Coriolis
    <para>
     <emphasis>Karl Fogel</emphasis>, the author of <emphasis>Open
     Source Development with CVS</emphasis> published by the Coriolis

-    Open Press. Larges parts of the book are available <ulink
+    Open Press. Large parts of the book are available <ulink

     url="http://cvsbook.red-bean.com">on the web</ulink>. 225 pages of
     the book are available under the GPL and constitute the best
     tutorial on CVS I have ever seen. The rest of the book covers,
     url="http://cvsbook.red-bean.com">on the web</ulink>. 225 pages of
     the book are available under the GPL and constitute the best
     tutorial on CVS I have ever seen. The rest of the book covers,


@@ -284,7 +284,7 @@
    </para>
    <para>
     Also providing support and material, and inspiration for this
    </para>
    <para>
     Also providing support and material, and inspiration for this

-    HOWTO is Eric S. Raymond for his prolific, consitent, and
+    HOWTO is Eric S. Raymond for his prolific, consistent, and

     carefully crafted arguments, to Lawrence Lessig for reminding me
     of the importance of Free Software and to every user and developer
     involved with the <ulink url="http://www.debian.org">Debian
     carefully crafted arguments, to Lawrence Lessig for reminding me
     of the importance of Free Software and to every user and developer
     involved with the <ulink url="http://www.debian.org">Debian


@@ -292,13 +292,13 @@
     to practice Free Software advocacy and to make a difference, a
     place to learn from those how have been involved with the movement
     much longer than I, and an proof of a Free Software project that
     to practice Free Software advocacy and to make a difference, a
     place to learn from those how have been involved with the movement
     much longer than I, and an proof of a Free Software project that

-    <emphasis>definately, definately works</emphasis>.
+    <emphasis>definitely, definitely works</emphasis>.

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

-    up. Stallman provided the philosphical basis that attracts me to
+    up. Stallman provided the philosophical basis that attracts me to

     Free Software and that drives me towards writing a document to
     make sure it succeeds. RMS can always be emailed at <email>rms
     (at) gnu (dot) org</email>.
     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>.


@@ -364,7 +364,7 @@
   </para>
 
   <para>
   </para>
 
   <para>

-   Starting a project also involves a dilemna that you as a developer
+   Starting a project also involves a dilemma that you as a developer

    must try and deal with. No potential user for your program will be
    interested by a program that doesn't work. Simultaneously, the
    development process that you want to employ holds involvement of
    must try and deal with. No potential user for your program will be
    interested by a program that doesn't work. Simultaneously, the
    development process that you want to employ holds involvement of


@@ -375,7 +375,7 @@
   <para>
    It is in these dangerous initial moments that anyone working to
    start a free software project must strike a balance. One of the
   <para>
    It is in these dangerous initial moments that anyone working to
    start a free software project must strike a balance. One of the

-   most important ways that omeone trying to start a project can work
+   most important ways that someone trying to start a project can work

    towards this balance is by establishing a framework for the
    development process through some of the ways mentioned in this
    section.
    towards this balance is by establishing a framework for the
    development process through some of the ways mentioned in this
    section.


@@ -392,16 +392,16 @@
     already have an idea for a project in mind. Chances are pretty
     good, it fills a gap by doing something that no other free
     software process does or or does it in a way that is unique
     already have an idea for a project in mind. Chances are pretty
     good, it fills a gap by doing something that no other free
     software process does or or does it in a way that is unique

-    enought to necessitate a seperate project.
+    enough to necessitate a separate project.

    </para>
 
    <sect3 id=identifyidea>
    </para>
 
    <sect3 id=identifyidea>

-    <title>Indentify and articulate your idea</title>
+    <title>Identify and articulate your idea</title>

     <para>
      Eric S. Raymond writes about how free software projects start in
      his paper, "The Cathedral and the Bazaar" which comes as required
     <para>
      Eric S. Raymond writes about how free software projects start in
      his paper, "The Cathedral and the Bazaar" which comes as required

-     reading for any free softare development. You can find it <ulink
-     url="http://www.tuxedo.org/!esr/writings/cathedral-bazaar/">online
+     reading for any free software development. You can find it <ulink
+     url="http://www.tuxedo.org/~esr/writings/cathedral-bazaar/">online

      </ulink>.
     </para>
 
      </ulink>.
     </para>
 


@@ -415,7 +415,7 @@
 
     <para>
      If you have an idea for a program in mind, chances are good that
 
     <para>
      If you have an idea for a program in mind, chances are good that

-     it it is targetting a specific problem or itch you want to see
+     it it is targeting a specific problem or itch you want to see

      scratched. <emphasis>This idea is the project. Articulate it
      clearly. Write it out. Describe the problem you will attack in
      detail. The success of your project in tackling a particular
      scratched. <emphasis>This idea is the project. Articulate it
      clearly. Write it out. Describe the problem you will attack in
      detail. The success of your project in tackling a particular


@@ -433,7 +433,7 @@
      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
      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 definately interested in seeing it
+     scratches your itch, you are definitely interested in seeing it

      implemented in code. But, because one hacker coding alone fails
      to qualify as a free software development effort, you need to ask
      yourself the question: <emphasis>Is anybody else
      implemented in code. But, because one hacker coding alone fails
      to qualify as a free software development effort, you need to ask
      yourself the question: <emphasis>Is anybody else


@@ -442,11 +442,12 @@
 
     <para>
      Sometimes the answer is <emphasis>no</emphasis>. If you want to
 
     <para>
      Sometimes the answer is <emphasis>no</emphasis>. If you want to

-     write a set of scripts to sort <emphasis>your</emphasis> MP3
-     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>
-     MP3s, a free software project might fill a useful gap.
+     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.

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


@@ -490,8 +491,8 @@
         provides <quote>News for Nerds: Stuff that Matters,</quote>
         which usually includes discussion of free software, open
         source, technology, and geek culture new and events. It is
         provides <quote>News for Nerds: Stuff that Matters,</quote>
         which usually includes discussion of free software, open
         source, technology, and geek culture new and events. It is

-        not unusual for an particularly sexy develpment effort to be
-        announced here so it definately worth checking.</para>
+        not unusual for an particularly sexy development effort to be
+        announced here so it definitely worth checking.</para>

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


@@ -499,7 +500,7 @@
         <term>SourceForge:</term>
         <listitem>
         <para><ulink url="http://sourceforge.net">SourceForge</ulink>
         <term>SourceForge:</term>
         <listitem>
         <para><ulink url="http://sourceforge.net">SourceForge</ulink>

-        houses and facilitates a growning number of open source and
+        houses and facilitates a growing number of open source and

         free software projects, SourceForge is quickly becoming a
         nexus and an necessary stop for free software
         developers. SourceForge's <ulink
         free software projects, SourceForge is quickly becoming a
         nexus and an necessary stop for free software
         developers. SourceForge's <ulink


@@ -509,8 +510,8 @@
         embarking on a new free software project. SourceForge also
         provides a at <ulink
         url="http://sourceforge.net/snippet/">Code Snippet
         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 reusuable chunks of
-        code in an array of langauges which can come in useful in any
+        Library</ulink> which contains useful reusable chunks of
+        code in an array of languages which can come in useful in any

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


@@ -520,7 +521,7 @@
         <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 powwerful web searches that may
+        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
         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


@@ -535,7 +536,7 @@
     <sect4 id=evalhow>
      <title>Deciding to Proceed</title>
      <para>
     <sect4 id=evalhow>
      <title>Deciding to Proceed</title>
      <para>

-      Once you have successfull charted the terrain and have an idea
+      Once you have successful charted the terrain and have an idea

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


@@ -559,7 +560,7 @@
       development for many developers but it is essential. It is easy
       to become fired up by and idea and be caught up in the momentum
       and excitement of a new project. It is often extremely difficult
       development for many developers but it is essential. It is easy
       to become fired up by and idea and be caught up in the momentum
       and excitement of a new project. It is often extremely difficult

-      but it is important that any free software developer rememeber
+      but it is important that any free software developer remember

       that the best interests of the of the free software community
       and the quickest way to accomplish ones own project's goals and
       the goals of similar project can often be accomplished by
       that the best interests of the of the free software community
       and the quickest way to accomplish ones own project's goals and
       the goals of similar project can often be accomplished by


@@ -588,21 +589,21 @@
 
     <para>
      Any discussion of licenses is also sure to generate at least a
 
     <para>
      Any discussion of licenses is also sure to generate at least a

-     small flamewar as there are strong feelings that some free
+     small flame war as there are strong feelings that some free

      software licenses are better than other free software
      licenses. This discussion also brings up the question of
      <quote>Open Source Software</quote> and the debate around
      <quote>Open Source Software</quote> and <quote>Free
      Software</quote>. However, because I've written the Free Software
      Development HOWTO and not the Open Source Development HOWTO, my
      software licenses are better than other free software
      licenses. This discussion also brings up the question of
      <quote>Open Source Software</quote> and the debate around
      <quote>Open Source Software</quote> and <quote>Free
      Software</quote>. However, because I've written the Free Software
      Development HOWTO and not the Open Source Development HOWTO, my

-     own allegiences in this argument are out in the open.
+     own allegiances in this argument are out in the open.

     </para>
 
     <para>
      In attempting to reach a middle ground, I recommend picking any
      license that conforms to the <ulink
      url="http://www.debian.org/social_contract">Debian Free Software
     </para>
 
     <para>
      In attempting to reach a middle ground, I recommend picking any
      license that conforms to the <ulink
      url="http://www.debian.org/social_contract">Debian Free Software

-     Guidlines</ulink>. Examples of these licenses are the
+     Guidelines</ulink>. Examples of these licenses are the

      <acronym>GPL</acronym>, the <acronym>BSD</acronym>, and the
      Artistic License. Conforming to the definition of Free Software
      offered by Richard Stallman in <ulink
      <acronym>GPL</acronym>, the <acronym>BSD</acronym>, and the
      Artistic License. Conforming to the definition of Free Software
      offered by Richard Stallman in <ulink


@@ -611,7 +612,7 @@
      uphold,<quote> users' freedom to run, copy, distribute, study,
      change and improve the software.</quote> There are other licenses
      as well but sticking with a more common license will offer the
      uphold,<quote> users' freedom to run, copy, distribute, study,
      change and improve the software.</quote> There are other licenses
      as well but sticking with a more common license will offer the

-     advantage of immediate recognition and undestanding.
+     advantage of immediate recognition and understanding.

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


@@ -679,7 +680,7 @@
       <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 seperate
+       the license with the source and binary in a separate

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


@@ -754,11 +755,11 @@ for details.
      Please, please, please, place your software under some
      license. It may not seem important, and to you, it may not be,
      but licenses are important. For a piece of software to be
      Please, please, please, place your software under some
      license. It may not seem important, and to you, it may not be,
      but licenses are important. For a piece of software to be

-     included in the Debian GNU/Linux distrobution, it must have a
+     included in the Debian GNU/Linux distribution, it must have a

      license that fits the <ulink
      url="http://www.debian.org/social_contract">Debian Free Software
      Guidelines</ulink>. If you have no license, your program can be
      license that fits the <ulink
      url="http://www.debian.org/social_contract">Debian Free Software
      Guidelines</ulink>. If you have no license, your program can be

-     distributed in part of Debian until you rerelease it under a free
+     distributed in part of Debian until you re-release it under a free

      license. Please save yourself and others trouble by releasing the
      first version of your software with a clear license.
     </para>
      license. Please save yourself and others trouble by releasing the
      first version of your software with a clear license.
     </para>


@@ -811,12 +812,12 @@ for details.
        Whether you plan on having a split development model (as
        described in <xref linkend="branches">) or only one version
        released at a time, my experience with several free software
        Whether you plan on having a split development model (as
        described in <xref linkend="branches">) or only one version
        released at a time, my experience with several free software

-       projects and with the Debian project has taught me taht use of
+       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
        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 frusterated with the lack of
+       an older version until they get so frustrated with the lack of

        development and progress that they complain. If you never
        release an odd minor version but only release even ones, nobody
        is hurt, and less people are confused.
        development and progress that they complain. If you never
        release an odd minor version but only release even ones, nobody
        is hurt, and less people are confused.


@@ -832,7 +833,7 @@ for details.
       achievable goal, wine is released every three weeks. Wine does
       this by versioning their releases in Year Month Day format where
       each release might be labeled <quote>wine-XXXXXXXX</quote> where
       achievable goal, wine is released every three weeks. Wine does
       this by versioning their releases in Year Month Day format where
       each release might be labeled <quote>wine-XXXXXXXX</quote> where

-      the version from Janurary 04, 2000 would be
+      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.
       </para>
       <quote>wine-20000104</quote>. For certain projects, Year Month
       Day format can make a lot of sense.
       </para>


@@ -842,7 +843,7 @@ for details.
     <varlistentry>
      <term>Mozilla milestones:</term>
      <listitem>
     <varlistentry>
      <term>Mozilla milestones:</term>
      <listitem>

-      <para>When one considers Netscape 6 and verdor versions, the
+      <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
       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


@@ -851,15 +852,15 @@ for details.
 
       <para>
        Mozilla's development structure has historically been made up
 
       <para>
        Mozilla's development structure has historically been made up

-       of milestones. From teh beginning of the mozilla project, the
+       of milestones. From the beginning of the mozilla project, the

        goals of the project in the order and degree to which they were
        to be achieved were charted out on a series of <ulink
        url="http://www.mozilla.org/roadmap.html">road
        goals of the project in the order and degree to which they were
        to be achieved were charted out on a series of <ulink
        url="http://www.mozilla.org/roadmap.html">road

-       maps</ulink>. Major points and achievements along this roadmaps
+       maps</ulink>. Major points and achievements along this road-maps

        were marked as milestones. Therefore, mozilla was built and
        distributed nightly as "nightly builds" but on a day when the
        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 roadmap had been reached, that
-       particular build was marked as a milstone release.
+       goals of a milestone on the road-map had been reached, that
+       particular build was marked as a milestone release.

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


@@ -887,7 +888,7 @@ for details.
     necessary for the survival of your project. You will learn later
     in <xref linkend="releasing"> that you must always release
     something that is usable. <emphasis>A piece of software without
     necessary for the survival of your project. You will learn later
     in <xref linkend="releasing"> that you must always release
     something that is usable. <emphasis>A piece of software without

-    documentation is not usuable.</emphasis>
+    documentation is not usable.</emphasis>

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


@@ -932,7 +933,7 @@ for details.
 
     <para>
      It is also possible to write man pages using DocBook SGML and
 
     <para>
      It is also possible to write man pages using DocBook SGML and

-     convert them into man pages. Because manpages are so simple, I
+     convert them into man pages. Because man pages are so simple, I

      have not been able to follow this up but would love help from
      anyone who can give me more information on how exactly this is
      done.
      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.


@@ -940,14 +941,14 @@ for details.
    </sect3>
 
    <sect3>
    </sect3>
 
    <sect3>

-    <title>Command line accessable documentation</title>
+    <title>Command line accessible documentation</title>

 
     <para>
      Most users will expect the most basic amount of documentation to
 
     <para>
      Most users will expect the most basic amount of documentation to

-     be easily availabe from the command line. For few programs should
+     be easily available from the command line. For few programs should

      then documentation extend for more than one screen (24 or 25
      lines) but it should cover the basic usage, a brief (one or two
      then documentation extend for more than one screen (24 or 25
      lines) but it should cover the basic usage, a brief (one or two

-     sentance) description of the program, a list of commands, all the
+     sentence) description of the program, a list of commands, all the

      major options, and 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:
      major options, and 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:


@@ -993,7 +994,7 @@ pages for more information and options.
 
     <para>
      It has become a GNU convention to make this information
 
     <para>
      It has become a GNU convention to make this information

-     accessable with the <quote>-h</quote> and the
+     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
      <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


@@ -1006,7 +1007,7 @@ pages for more information and options.
      In addition to man pages and online help, there are certain files
      where people will look to documentation, especially in any
      package containing source code. In a source distribution, most of
      In addition to man pages and online help, there are certain files
      where people will look to documentation, especially in any
      package containing source code. In a source distribution, most of

-     these files can be stored in a the root directery of the source
+     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>. These files include:
     </para>
      distribution or in a subdirectory of the root called
      <quote>doc</quote> or <quote>Documentation</quote>. These files include:
     </para>


@@ -1018,7 +1019,7 @@ pages for more information and options.
        <listitem>
        <para>
          A document containing all the basic installation,
        <listitem>
        <para>
          A document containing all the basic installation,

-         compiliation, and even basic use instructions that make up
+         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
          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


@@ -1033,7 +1034,7 @@ pages for more information and options.
        <listitem>
        <para>
          The INSTALL file should be much shorter than the INSTALL file
        <listitem>
        <para>
          The INSTALL file should be much shorter than the INSTALL file

-         and should quicly and concisely describe how to build and
+         and should quickly and concisely describe how to build and

          install the program. Usually an install simply instructs the
          user to run ./configure; make; make install and touches on
          any unusual options that may be necessary. More advanced
          install the program. Usually an install simply instructs the
          user to run ./configure; make; make install and touches on
          any unusual options that may be necessary. More advanced


@@ -1055,13 +1056,13 @@ pages for more information and options.
          software project should include. A changelog is simple the
          file that, as its name would imply, logs or documents the
          changes to a program. The most simple way to do a changelog
          software project should include. A changelog is simple the
          file that, as its name would imply, logs or documents the
          changes to a program. The most simple way to do a changelog

-         is to simply keep a file with teh source code for your
+         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
          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 signifigant upgrade.
+         wait for a more significant upgrade.

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


@@ -1078,7 +1079,7 @@ pages for more information and options.
          are asked a question or see a question on a mailing list two
          or more times, add it the question (and its answer) to your
          FAQs. FAQs are more optional than the files listed above but
          are asked a question or see a question on a mailing list two
          or more times, add it the question (and its answer) to your
          FAQs. FAQs are more optional than the files listed above but

-         they can save your time, increase useability, and decrease
+         they can save your time, increase usability, and decrease

          headaches on all sides.
         </para>
        </listitem>
          headaches on all sides.
         </para>
        </listitem>


@@ -1150,7 +1151,7 @@ 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 spotlit as a more effective compression medium. I now make
+     the spot-lit as a more effective compression medium. I now make

      all my releases available in both gzip'ed and bzip2'ed formats.
     </para>
 
      all my releases available in both gzip'ed and bzip2'ed formats.
     </para>
 


@@ -1163,9 +1164,9 @@ pages for more information and options.
      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
      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 specificed libraries and
+     against a specified system with specified libraries and

      distributed in tar.gz format as well. <emphasis>Remember: While
      distributed in tar.gz format as well. <emphasis>Remember: While

-     these binaries packages are nice, geting the source packaged and
+     these binaries packages are nice, getting the source packaged and

      released should always be your priority. Other can and will do
      the the binary packages for you.</emphasis>
     </para>
      released should always be your priority. Other can and will do
      the the binary packages for you.</emphasis>
     </para>


@@ -1181,7 +1182,7 @@ 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 accessable via <acronym>FTP</acronym> or
+        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
         <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


@@ -1228,7 +1229,7 @@ pages for more information and options.
    process itself is equally important and provides an equal number of
    opportunities for failure. In the next two sections, I will and
    cover running a project by discussing how to maintain a project
    process itself is equally important and provides an equal number of
    opportunities for failure. In the next two sections, I will and
    cover running a project by discussing how to maintain a project

-   rhough interactions with developers and with users.
+   rough interactions with developers and with users.

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


@@ -1245,7 +1246,7 @@ pages for more information and options.
    The major difference between free software development and propriety
    software development is the developer base. As the leader of a free
    software project, you need to attract and keep developers in a way
    The major difference between free software development and propriety
    software development is the developer base. As the leader of a free
    software project, you need to attract and keep developers in a way

-   that leaders of proprietary software projects sipmly don't have to
+   that leaders of proprietary software projects simply don't have to

    worry about. <emphasis>As the person leading development of a free
    software project, you must harness the work of fellow developers by
    making responsible decisions and by and by choosing not to make
    worry about. <emphasis>As the person leading development of a free
    software project, you must harness the work of fellow developers by
    making responsible decisions and by and by choosing not to make


@@ -1275,9 +1276,9 @@ pages for more information and options.
    </para>
 
    <para>
    </para>
 
    <para>

-    Delegation is the politcal way of describing this process of
+    Delegation is the political way of describing this process of

     <quote>letting go.</quote> It is the process of handing some of
     <quote>letting go.</quote> It is the process of handing some of

-    the responsibility and power over your project to other reponsible
+    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
     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


@@ -1289,13 +1290,13 @@ pages for more information and options.
 
    <para>
     As your project progresses, you will notice people who are putting
 
    <para>
     As your project progresses, you will notice people who are putting

-    signfigant amounts of time and effort into your project. These
+    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
     will be the people submitting the most patches, posting most on
     the mailing lists, engaging in long email discussions. It is your

-    responsiblity to contact these people and to try and shift some of
-    the power and responsiblity of your position as the project's
+    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
     maintainer onto them (if they want it). There are several easy

-    weays you can do this:
+    ways you can do this:

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


@@ -1307,17 +1308,17 @@ pages for more information and options.
      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
      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

-     judgement and for recognizing solutions that are maintainable and
-     are not. In a sentance: <emphasis>Keep an eye out for other
+     judgment and for recognizing solutions that are maintainable and
+     are not. In a sentence: <emphasis>Keep an eye out for other

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

-     to start or good sources of inspiriation:
+     to start or good sources of inspiration:

     </para>
  
     <sect4>
      <title>Allow a larger group of people write access to your CVS
     </para>
  
     <sect4>
      <title>Allow a larger group of people write access to your CVS

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

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


@@ -1334,15 +1335,15 @@ pages for more information and options.
       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
       is an extreme example of rule by committee. At current count,
       more than 700 developers have full responsibility for certain
       aspects of the projects. All these developers can upload into

-      the main ftp servers, and vote on major issues. Direction for
+      the main FTP servers, and vote on major issues. Direction for

       the project is determined by the project <ulink
       url="http://www.debian.org/social_contract">social
       contract</ulink> and a <ulink
       url="http://www.debian.org/devel/constitution">constitution</ulink>. To
       facilitate this system, there are special teams (i.e. the
       install team, the Japanese language team) and a technical
       the project is determined by the project <ulink
       url="http://www.debian.org/social_contract">social
       contract</ulink> and a <ulink
       url="http://www.debian.org/devel/constitution">constitution</ulink>. To
       facilitate this system, there are special teams (i.e. the
       install team, the Japanese language team) and a technical

-      committee and a project lead. There is a project lead as well
-      but the lead's main responsiblity is to, <quote>Appoint
+      committee and a project lead. There is a project leader as well
+      but the leader's main responsibility is to, <quote>Appoint

       Delegates or delegate decisions to the Technical
       Committee.</quote>
      </para>
       Delegates or delegate decisions to the Technical
       Committee.</quote>
      </para>


@@ -1352,7 +1353,7 @@ pages for more information and options.
       project will not (at least initially), their example is
       helpful. Debian's idea of a project who lead who can do
       <emphasis>nothing</emphasis> but delegate can serve as a
       project will not (at least initially), their example is
       helpful. Debian's idea of a project who lead who can do
       <emphasis>nothing</emphasis> but delegate can serve as a

-      charicature of how a project can involve and empower a huge
+      caricature of how a project can involve and empower a huge

       number of developers and grow to a huge size.
      </para>
 
       number of developers and grow to a huge size.
      </para>
 


@@ -1363,16 +1364,16 @@ pages for more information and options.
        specific release.</title>
 
      <para>
        specific release.</title>
 
      <para>

-      A relase manager is usually responsible for coordinating
-      testing, encforcing a code freeze, being responsible for
+      A release manager is usually responsible for coordinating
+      testing, enforcing a code freeze, being responsible for

       stability and quality control, packaging up the software, and
       stability and quality control, packaging up the software, and

-      placing it in the approrpriate places to be downloaded.
+      placing it in the appropriate places to be downloaded.

      </para>
 
      <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>
 
      <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 somenoe else. It is a good way of very
+      rejecting patches to 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 a break.
      </para>
       clearly defining a chunk of work on the project as belonging to
       a certain person and its a great way of giving yourself a break.
      </para>


@@ -1386,16 +1387,16 @@ pages for more information and options.
       else to be the the head of a branch. If you like focusing your
       energy on development releases and the implementation of new
       features, had total control over the stable releases to a
       else to be the the head of a branch. If you like focusing your
       energy on development releases and the implementation of new
       features, had total control over the stable releases to a

-      well-suiteded developer.
+      well-suited developer.

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

-      The author of linux, Linus Torvalds, came out and crowned Alan
+      The author of Linux, Linus Torvalds, came out and crowned Alan

       Cox as <quote>the man for stable kernels.</quote> All patches
       for stable kernels go to Alan and, if Linus were to be taken
       Cox as <quote>the man for stable kernels.</quote> All patches
       for stable kernels go to Alan and, if Linus were to be taken

-      away from work on linux for any reason, Alan Cox would be more
+      away from work on Linux for any reason, Alan Cox would be more

       than suited to fill his role as the acknowledged heir to the
       than suited to fill his role as the acknowledged heir to the

-      linux maintainership.
+      Linux maintainership.

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


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

-    <title>Technical judgement</title>
+    <title>Technical judgment</title>

 
     <para>
      In <emphasis>Open Source Development with CVS</emphasis>, Karl
 
     <para>
      In <emphasis>Open Source Development with CVS</emphasis>, Karl


@@ -1423,11 +1424,11 @@ pages for more information and options.
      linkend="chooseproject">) and the ability to recognize,
      facilitate, and direct <quote>evolution</quote> of a free
      software program so that the program can grow and change and
      linkend="chooseproject">) and the ability to recognize,
      facilitate, and direct <quote>evolution</quote> of a free
      software program so that the program can grow and change and

-     incorporate functionatlity that was orignally unforseen but avoid
+     incorporate functionality that was originally unforeseen but avoid

      digressions that might expand the scope of the program too much
      and result and push the project towards an early death under its
      digressions that might expand the scope of the program too much
      and result and push the project towards an early death under its

-     own weight and unweildiness. These are the criteria that you as a
-     project mainatiner should take into account each time you recieve
+     own weight and unwieldiness. These are the criteria that you as a
+     project maintainer should take into account each time you receive

      a patch.
     </para>
 
      a patch.
     </para>
 


@@ -1454,13 +1455,13 @@ pages for more information and options.
     </para>
 
     <para>
     </para>
 
     <para>

-     The answers to these questions are never straighforward and its
+     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
      than you do. However, if you feel that that the answer to either
      very possible (and even likely) that the person who submitted the
      patch may feel differently about the answer to those questions
      than you do. However, if you feel that that the answer to either

-     of those questions is <quote>no,</quote> it is your responsiblity
+     of those questions is <quote>no,</quote> it is your responsibility

      to reject the change. If you fail to do this, the project will
      to reject the change. If you fail to do this, the project will

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

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


@@ -1469,14 +1470,14 @@ pages for more information and options.
 
     <para>
      Rejecting patches is probably the most difficult and the most
 
     <para>
      Rejecting patches is probably the most difficult and the most

-     sesnative job that the maintainer of any free software project
+     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
      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

-     powertrip or being overly bossy or possesive of a community-based
+     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):
     </para>
      project. I recommend that you keep three major facts in mind when
      rejecting patches (or other changes):
     </para>


@@ -1490,7 +1491,7 @@ pages for more information and options.
       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
       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  definately be accepted  and some that you  feel are so off
+      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.
       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.


@@ -1512,12 +1513,12 @@ pages for more information and options.
      <para>
       Especially towards the beginning, you will find that many
       changes are difficult to implement, introduce new bugs, or have
      <para>
       Especially towards the beginning, you will find that many
       changes are difficult to implement, introduce new bugs, or have

-      other techincal problems. Try to see past these. Especially with
+      other technical problems. Try to see past these. Especially with

       added functionality, good ideas do not always come from good
       coders. Technical merit is a valid reason to postpone the
       application of a patch but it is not always a good reason to
       reject a change outright. Even small changes are worth the
       added functionality, good ideas do not always come from good
       coders. Technical merit is a valid reason to postpone the
       application of a patch but it is not always a good reason to
       reject a change outright. Even small changes are worth the

-      effort of working with the submittor to iron out bugs and
+      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
       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


@@ -1542,7 +1543,7 @@ pages for more information and options.
       It is your responsibility to first justify your action to not
       incorporate their change clearly and concisely. Then thank
       them. Let them know that you a appreciate their help and feel
       It is your responsibility to first justify your action to not
       incorporate their change clearly and concisely. Then thank
       them. Let them know that you a appreciate their help and feel

-      horrible that you can't incorproate their change. Let them know
+      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
       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


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

-    <xref linkend="delegatebranch">. These alluses attest to the fact
+    <xref linkend="delegatebranch">. These alludes attest to the fact

     to some of the ways that multiple branches can affect your
     software. Branches can let you avoid (to some extent) some of the
     problems around rejecting patches (as described in <xref
     to some of the ways that multiple branches can affect your
     software. Branches can let you avoid (to some extent) some of the
     problems around rejecting patches (as described in <xref


@@ -1584,14 +1585,14 @@ pages for more information and options.
     features are rejected or put on hold under the development kernel
     is released as the new stable branch and major development begins
     again on the development branch. Bug fixes and small changes that
     features are rejected or put on hold under the development kernel
     is released as the new stable branch and major development begins
     again on the development branch. Bug fixes and small changes that

-    are unlikely to have any large negative reprocussion are
+    are unlikely to have any large negative repercussions are

     incorporated into the stable branch also to the development
     branch.
    </para>
 
    <para>
     Linux's model is an extreme one. On many projects, there is no
     incorporated into the stable branch also to 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 ot
+    need to have two versions always 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,


@@ -1600,8 +1601,8 @@ pages for more information and options.
     transition from unstable to stable. There are few projects whose
     size would necessitate a system like Debian but their use of
     branches helps demonstrate how they can be used to balance
     transition from unstable to stable. There are few projects whose
     size would necessitate a system like Debian but their use of
     branches helps demonstrate how they can be used to balance

-    consitent and effective development with the need to make regular
-    and useable releases.
+    consistent and effective development with the need to make regular
+    and usable releases.

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


@@ -1620,7 +1621,7 @@ pages for more information and options.
         but it contains gigabytes of software in over 5000 packages
         compiled for a 5-6 different architectures. Two is a good
         number. Too many branches will confuse your users (I can't
         but it contains gigabytes of software in over 5000 packages
         compiled for a 5-6 different architectures. Two is a good
         number. Too many branches will confuse your users (I can't

-        count how many times I had to describe debian's system when it
+        count how many times I had to describe Debian's system when it

         only had 2 and sometimes 3 branches!), potential developers
         and even yourself. Branches can help but they come at a cost
         so use them very sparingly.
         only had 2 and sometimes 3 branches!), potential developers
         and even yourself. Branches can help but they come at a cost
         so use them very sparingly.


@@ -1632,10 +1633,10 @@ pages for more information and options.
       <term>Make sure that all your different branches are explained</term>
       <listitem>
        <para>
       <term>Make sure that all your different branches are explained</term>
       <listitem>
        <para>

-        As I mentioned in the preceeding paragraph, different branches
+        As I mentioned in the preceding paragraph, different branches

         <emphasis>will</emphasis> confuse your users. Do everything
         you can to avoid this by clearly explaining the different
         <emphasis>will</emphasis> confuse your users. Do everything
         you can to avoid this by clearly explaining the different

-        branches in a promenant page on your website and in a Readme
+        branches in a prominent page on your website and in a Readme

         file in the <acronym>FTP</acronym> or <acronym>HTTP</acronym>
         directory.
        </para>
         file in the <acronym>FTP</acronym> or <acronym>HTTP</acronym>
         directory.
        </para>


@@ -1656,7 +1657,7 @@ pages for more information and options.
         If you are going to do branches, especially early on, keep in
         mind that people are conditioned to understand the terms
         <quote>stable</quote> and <quote>development</quote> and you
         If you are going to do branches, especially early on, keep in
         mind that people are conditioned to understand the terms
         <quote>stable</quote> and <quote>development</quote> and you

-        probaly can't go wrong with this simple and common division of
+        probably can't go wrong with this simple and common division of

         branches.
        </para>
       </listitem>
         branches.
        </para>
       </listitem>


@@ -1668,7 +1669,7 @@ pages for more information and options.
        <para>
         Like a lot of document, this should probably should go without
         saying but experience has taught me that it's not always
        <para>
         Like a lot of document, this should probably should go without
         saying but experience has taught me that it's not always

-        obvious to people. It's a good idea to physicall split up
+        obvious to people. It's a good idea to physically split up

         different branches in different directories or directory trees
         on your <acronym>FTP</acronym> or <acronym>HTTP</acronym>
         site. Linux accomplishes this by having all the v2.2 and a
         different branches in different directories or directory trees
         on your <acronym>FTP</acronym> or <acronym>HTTP</acronym>
         site. Linux accomplishes this by having all the v2.2 and a


@@ -1681,7 +1682,7 @@ pages for more information and options.
         <quote>frozen</quote> to point to which ever distribution (by
         name) is in whatever stage. Both methods work and their are
         others. In any case, it is important that different branches
         <quote>frozen</quote> to point to which ever distribution (by
         name) is in whatever stage. Both methods work and their are
         others. In any case, it is important that different branches

-        are always available, are accessable from consistent
+        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.
         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.


@@ -1716,14 +1717,14 @@ pages for more information and options.
 
     <para>
      Freeze come in two major forms. A <quote>feature freeze</quote>
 
     <para>
      Freeze come in two major forms. A <quote>feature freeze</quote>

-     is a period when no signifigant functionality is added to a
+     is a period when no significant functionality is added to a

      program. It is a period where established functionality (even
      skeletons of barely working functionality) can be improved and
      perfected. It is a period where bugs are fixed. This type of
      freeze is usually applied some period (a month or two) before a
      release. It is easy to push a release back as you wait for
      <quote>one more feature</quote> and a freeze helps to avoid this
      program. It is a period where established functionality (even
      skeletons of barely working functionality) can be improved and
      perfected. It is a period where bugs are fixed. This type of
      freeze is usually applied some period (a month or two) before a
      release. It is easy to push a release back as you wait for
      <quote>one more feature</quote> and a freeze helps to avoid this

-     situation by drawing the much neede line in the sand. It gives
+     situation by drawing the much needed line in the sand. It gives

      developers room they need to get a program ready for release.
     </para>
 
      developers room they need to get a program ready for release.
     </para>
 


@@ -1733,7 +1734,7 @@ pages for more information and options.
      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
      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 preceeds a release. Most released
+     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>
      software is in what could be interpreted as a sort of high
      level<quote>code freeze.</quote>
     </para>


@@ -1754,8 +1755,8 @@ pages for more information and options.
      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
      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 codebase
-     but for technical, political, and philisophical reasons,
+     XEmacs. Both emacsen are based on an almost identical code-base
+     but for technical, political, and philosophical reasons,

      development was split into two projects which now compete with
      each other.
     </para>
      development was split into two projects which now compete with
      each other.
     </para>


@@ -1790,40 +1791,533 @@ pages for more information and options.
   </indexterm>
 
   <para>
   </indexterm>
 
   <para>

-   If you've worked your way up to here, congratuatlions, you are
-   nearing the end of this document. This final section touches upon 
+   If you've worked your way up to here, congratulations, you are
+   nearing the end of this document. This final section describes some
+   of the situations in which you, in your capacity as project
+   maintainer, will be interacting with users and gives some
+   suggestions on how these situations might be handled effectively.

   </para>
 
   </para>
 

+  <para>
+   Interacting with users is difficult. In our discussion of
+   interaction with developers, the underlying assumption is that in a
+   free software project, a project maintainer must constantly strive to
+   attract and keep developers who can easily leave at any time.
+  </para>
+
+  <para>
+   Users in the free software community are different than users in
+   the world of proprietary software and they should be treated
+   differently. Some ways in which the groups differ significantly
+   follow:
+  </para>
+
+  <para>
+   <itemizedlist>
+
+    <listitem>
+     <para>The lines between users and developers are blurred in ways
+     that is totally foreign to any proprietary development
+     model. Your users are often your developers and vice
+     versa.</para>
+    </listitem>
+
+    <listitem>
+     <para>In the free software world, you are often your users only
+     choice. Because there is such an emphasis on not replicating the
+     work of others in the free software community and because the
+     element of competition present in the propriety software model is
+     absent (or at least in an extremely different form) in the free
+     software development model your users will probably be the only
+     project that does what you do (or at least the only one that does
+     what you do in the way that you do it). This means your
+     responsiveness to your users is even more important in that in
+     the proprietary world.</para>
+    </listitem>
+
+    <listitem>
+     <para>In an almost paradoxical situation, free software projects
+     have less immediate or dire consequences for ignoring their
+     users--it is often easier to do. Because you don't usually need
+     to compete with another product in the free software model,
+     chances are good that you will not be scrambling to gain the
+     features of the competitor's newest program. This means that your
+     development process will have to be directed either internally,
+     by your users or both.</para>
+    </listitem>
+   </itemizedlist>
+  </para>
+
+  <para>
+   Trying to tackle this unique situation can only be done
+   indirectly. Developers and maintainers need to listen to users and
+   to try and be as responsive as possible. A solid knowledge of the
+   situation recounted above is any free software developers best tool
+   for shifting his development or leadership style to fit the unique
+   process of free software development. This chapters will try and
+   introduce some of the more difficult or important points in any
+   projects interactions with users and give some hints on how to
+   tackle these.
+  </para>

 
 <!-- Section2: testing -->
 
   <sect2 id="testing">
    <title>Testing and Testers</title>
 
 <!-- Section2: testing -->
 
   <sect2 id="testing">
    <title>Testing and Testers</title>

-   <para></para>
+
+   <para>
+    In addition to your users being your developers, they are also
+    (and perhaps more commonly) your testers. Before I get flamed, I
+    should rephrase my sentence: <emphasis>some</emphasis> users are
+    your testers.
+   </para>
+
+   <para>
+    It is important that this distinction be made early on because not
+    all of your users wants to be testers. Many users want to use
+    stable software and don't care if they don't have the newest
+    greatest software with the latest and greatest features. These
+    users except a stable, tested piece of software with major or
+    obvious bugs worked out or openly declared and will be angry if
+    they find themselves in a testing position. This is yet another
+    way in which a split development model (as mentioned in <xref
+    linkend="branches">) might come in handy.
+   </para>
+
+   <sect3>
+    <title>Automated testing</title>
+    <para>
+     For many programs, many common and 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 and not very good at finding errors,
+     even major ones, that were 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
+     using 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
+     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.
+    </para>
+   </sect3>
+
+   <sect3>
+    <title>Testing by testers</title>
+    <para>
+     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.
+    </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.
+    </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:
+    </para>
+
+    <para>
+     <itemizedlist>
+
+      <listitem>
+       <para><emphasis>Make things simple for your testers.</emphasis>
+       Your testers are doing you a favor so make it as easy as
+       possible. This means that you should be careful to package your
+       software in a way that is easy to find, unpack, install, and
+       uninstall. This also means you should explain what you are
+       looking for to each tester and make the means for reporting
+       bugs simple and well established. The key is to provide as much
+       structure as possible to make your tester's job easy and
+       maintain as much flexibility as possible for those that want to
+       do things a little differently.</para>
+      </listitem>
+
+      <listitem>
+       <para><emphasis>Be responsive to your testers.</emphasis> When
+       your testers submit bugs, respond to them and respond
+       quickly. Even if you are only responding to tell them that the
+       bug has already been fixed, quick and consistent response make
+       them feel like their work is heard, important, and
+       appreciated.</para>
+      </listitem>
+
+      <listitem>
+       <para><emphasis>Thank your testers.</emphasis> Thank them
+       personally each time they send you patch. Thank them publicly
+       in the documentation and the about section of your program. You
+       appreciate your testers and your program would not be possible
+       without their help. Make sure they know and pat them on the
+       back by making sure the rest of the world knows it too. It will
+       be appreciated more than you expected.</para>
+      </listitem>
+
+     </itemizedlist>
+    </para>
+   </sect3>

   </sect2>
 
 <!-- Section2: support  -->
 
   <sect2 id="support">
    <title>Setting up a Support Infrastructure</title>
   </sect2>
 
 <!-- Section2: support  -->
 
   <sect2 id="support">
    <title>Setting up a Support Infrastructure</title>

-   <para></para>
+
+   <para>
+    While testing is important, the large part of your interactions
+    and responsibility to your users falls under the category of
+    support. The best way to make sure your users are adequately
+    supported in using your program is to set up a good infrastructure
+    for this purpose so that your developers and users help each other
+    and less of the burden falls on you while people get quicker and
+    better responses to their questions. This infrastructure comes in
+    several forms:
+   </para>
+
+   <sect3>
+    <title>Documentation</title>
+    <para>
+     It should not come as any surprise that the key element to any
+     support infrastructure is good documentation. This topic was
+     large covered in <xref linkend="documentation"> and will not be
+     repeated here.
+    </para>
+   </sect3>
+
+   <sect3>
+    <title>Mailing lists</title>
+    <para>
+     Aside from documentation, effective mailing lists will be your
+     greatest tool in supporting user support. Running a mailing list
+     well is more complicated than installing mailing list software
+     onto a machine. 
+    </para>
+
+    <sect4>
+     <title>Separate lists</title>
+     
+     <para>
+      A good idea is too separate your user and development mailing
+      lists (perhaps into project-user@host and project-devel@host)
+      and enforce the division. If people post a development question
+      onto -user, politely ask them to repost it onto -devel and vise
+      versa. Subscribe yourself to both groups and encourage primarily
+      developers to do the same.
+     </para>
+
+     <para>
+      This system provides so that no one person is stuck doing all of
+      the support work and works so that users learn more about the
+      program, they can help new users with their questions.
+     </para>
+    </sect4>
+
+    <sect4>
+     <title>Choose mailing list software well</title>
+     <para>
+      Please don't make the selection of mailing list software
+      lightly. Please consider easy accessibility by users without a
+      lot of technical experience so you want to be as easy as
+      possible. Web accessibility to an archive of the list is also
+      important.
+     </para>
+
+     <para>
+      The two biggest free software mailing list programs are <ulink
+      url="http://www.greatcircle.com/majordomo/">majordomo</ulink>
+      and <ulink url="http://www.list.org/">GNU Mailman</ulink>. A
+      long time advocate of majordomo, I would now recommend any
+      project choose GNU Mailman. It fulfills the criteria listed above
+      and makes it easier to do. It provides a good mailing list
+      program for a free software project maintainer as opposed to a
+      good mailing list application for a mailing list administrator.
+     </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.
+     </para>
+    </sect4>
+   </sect3>
+
+   <sect3>
+    <title>Other support ideas</title>
+
+    <para>
+     A mailing list and accessible documentation all you can do to set
+     up good user support infrastructure. Be creative. If you stumble
+     across something works well, email me and I'll include it here in
+     the HOWTO.
+    </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.
+    </para>
+    </sect4>
+
+    <sect4>
+     <title>Bug management software</title>
+     <para>
+      For many large software projects, use of bug management software
+      is essential to keep track of which bugs have been fixed, which
+      bugs have not been fixed, and which bugs are being fixed by
+      which people. Debian uses the <ulink
+      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
+      has spawned a sub-project resulting in a bug tracking system
+      called <ulink
+      url="http://www.mozilla.org/projects/bugzilla/">bugzilla</ulink>.
+     </para>
+
+     <para>
+      These systems (and others like them) can be unwieldy so
+      developers should be careful to not spend more time on the bug
+      tracking system than on the bugs or the projects themselves. If
+      a project continues to grow, use of a bug tracking system can
+      provide an easy standard way for users and testers to report
+      bugs and for developers and maintainers to fix them in an
+      orderly fashion.
+     </para>
+    </sect4>
+   </sect3>

   </sect2>
 
   </sect2>
 

-<!-- Section2: releasing  -->
+<!-- Section2: releasing -->

 
   <sect2 id="releasing">
    <title>Releasing Your Program</title>
 
   <sect2 id="releasing">
    <title>Releasing Your Program</title>

-   <para></para>
+
+   <para>
+    As mentioned earlier in the HOWTO, the first rule or 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
+    to simply gloss over it next time they see a new version
+    announced. Half-working software, if useful, will intrigue people,
+    whet their appetites for the version to come, and encourage them
+    to join the development process.
+   </para>
+
+   <sect3>
+    <title>When to release</title>
+
+    <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
+     is complete enough to be usable and incomplete enough to allow
+     for flexibility and imagination by your future developers. It's
+     not an easy decision. Ask for help on a local Linux User Group
+     mailing list or from a group of developer friends.
+    </para>
+
+    <para>
+     One tactic is to first do an <quote>alpha</quote> or
+     <quote>beta</quote> release as described below in <xref
+     linkend="alphabeta">. However, most of the guidelines described
+     above still apply.
+    </para>
+
+    <para>
+     <emphasis>When you feel in your gut it is time and you feel
+     you've weighed the situation well several times, cross your
+     fingers and take the plunge.</emphasis>
+   </para>
+   </sect3>
+
+   <sect3>
+    <title>How to release</title>
+
+    <para>
+     If you've followed the guidelines described in this HOWTO up
+     until this point, the mechanics of doing a release are going to
+     be the easy part of releasing. If you have set up a consistent
+     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.
+    </para>
+   </sect3>
+
+   <sect3 id="alphabeta">
+    <title>Alpha, beta, and development releases</title>
+
+    <para>
+     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
+     they are worth.
+    </para>
+
+    <para>
+     <variablelist>
+
+      <varlistentry>
+       <term>alpha releases</term>
+       <listitem>
+       <para>
+         Alpha releases are expected to be unstable, perhaps a little
+         unsafe, but definitely usable. Alpha versions should have
+         full functionality and limited testing. They can have known
+         bugs and kinks that have yet to be worked out. Before sure to
+         keep in mind that <emphasis>alpha releases are still
+         releases</emphasis> and people are not going to be expecting
+         a nightly build from the CVS source. An alpha should work and
+         have minimal testing and bug fixing already finished.
+        </para>
+       </listitem>
+      </varlistentry>
+
+      <varlistentry>
+       <term>beta releases</term>
+       <listitem>
+       <para>
+         Beta releases are general expected to be usable and
+         slightly unstable, although definitely
+         <emphasis>not</emphasis> unsafe. Beta releases usually
+         preclude a full release by under a month. They can contain
+         small known bugs but no major ones. All major functionality
+         should be fully implemented although the exact mechanics can
+         still be worked out. Beta releases are great tool to whet the
+         appetites of potential users by giving them a very
+         realistic view of where your project is going in the very
+         near future and can help keep interest by giving people
+         <emphasis>something.</emphasis>
+        </para>
+       </listitem>
+      </varlistentry>
+
+      <varlistentry>
+       <term>development releases</term>
+       <listitem>
+       <para>
+         Development release is much more vague term than
+         <quote>alpha</quote> or <quote>beta</quote>. I usually choose
+         to reserve the term for discussion of a development
+         branch. There are other ways to use the term. So many in
+         fact, that I feel the term has been cheapened. The popular
+         window manager <ulink
+         url="http://www.enlightenment.org">Enlightenment</ulink> has
+         released <emphasis>nothing but</emphasis> development
+         releases. Most often, the term is used to describe releases
+         that are not even to alpha or beta stages though and if I
+         were to release a pre-alpha release in order to keep interest
+         in my project live, this is probably how I would have to label
+         it.
+        </para>
+       </listitem>
+      </varlistentry>
+
+     </variablelist>
+
+    </para>
+   </sect3>

   </sect2>
 
 <!-- Section2: announcing  -->
 
   <sect2 id="announcing">
    <title>Announcing Your Project</title>
   </sect2>
 
 <!-- Section2: announcing  -->
 
   <sect2 id="announcing">
    <title>Announcing Your Project</title>

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

 
 

+   <para>
+    Well, you've done it. You've (at least for the purposes of this
+    HOWTO) designed, built, and released your free software
+    project. All that is left is for you to tell the world so they
+    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
+    radar screen.
+   </para>
+
+   <sect3>
+    <title>Mailing lists and USENET</title>
+    <para>
+     Email is still the way that most people on the Internet get their
+     information. Its a good idea to send a message announcing your
+     program to any relevant mailing list you know of and any relevant
+     USENET discussion group. Karl Fogel recommends that use you
+     simple subject describing the fact that the message is an
+     announcement, the name of the program, the version, and a
+     half-line long description of its functionality. This way, any
+     interested user or developer will be immediately attracted to
+     your announcement. Fogel's example looks like:
+    </para>
+
+    <screen>Subject: ANN: aub 1.0, a program to assemble USENET binaries</screen>
+
+    <para>
+     The rest of the email should describe the programs functionality
+     quickly and concisely in no more than two paragraphs and should
+     provide links to the projects webpage and direct links to
+     downloads for those that want it right away.
+    </para>
+
+    <para>
+     You should repeat this announcement process consistently in the
+     same locations for each subsequent release.
+    </para>
+   </sect3>
+
+   <sect3>
+    <title>freshmeat.net</title>
+    <para>
+     Mentioned earlier in <xref linkend="evalwhere">, in today's free
+     software community, announcements of your project on freshmeat
+     are almost more important than announcements on mailing list
+     announcements.
+    </para>
+
+    <para>
+     Visit the <ulink url="http://freshmeat.net">freshmeat
+     website</ulink> or their <ulink
+     url="http://freshmeat.net/add-project/">submit project
+     page</ulink> to post your project on their site and in their
+     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
+     interesting new releases).
+    </para>
+
+    <para>
+     Once you've finished this...
+    </para>

 
 

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

 </sect1>
 
 </article>
 </sect1>
 
 </article>

diff --git a/FreeSoftwareProjectManagementHOWTO.sgml b/FreeSoftwareProjectManagementHOWTO.sgml
index ad8e78fca92668f97ad78843d822a183b00189c9..e81b8337c97debe808b16ae8581484c694941f36 100644 (file)
--- a/FreeSoftwareProjectManagementHOWTO.sgml
+++ b/FreeSoftwareProjectManagementHOWTO.sgml
@@ -58,8 +58,8 @@
    </indexterm>
 
   <para>
    </indexterm>
 
   <para>

-   For various reasons, this realease has been codenamed the
-   <emphasis>homade yogurt</emphasis> release.
+   For various reasons, this release has been code-named the
+   <emphasis>homemade yogurt</emphasis> release.

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


@@ -69,7 +69,7 @@
   </para>
 
   <para>
   </para>
 
   <para>

-   Skimming through Freshmeat provides mountains of reasons for this
+   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
    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


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

-   write a beautiful, relevent piece of software and follow every
+   write a beautiful, relevant piece of software and follow every

    instruction in this HOWTO and your software may still not make
    it. Sometimes life is like that. However, I'll go out a limb and
    say that if you write a great, relevant pieces of software and
    instruction in this HOWTO and your software may still not make
    it. Sometimes life is like that. However, I'll go out a limb and
    say that if you write a great, relevant pieces of software and


@@ -265,7 +265,7 @@
    <para>
     <emphasis>Karl Fogel</emphasis>, the author of <emphasis>Open
     Source Development with CVS</emphasis> published by the Coriolis
    <para>
     <emphasis>Karl Fogel</emphasis>, the author of <emphasis>Open
     Source Development with CVS</emphasis> published by the Coriolis

-    Open Press. Larges parts of the book are available <ulink
+    Open Press. Large parts of the book are available <ulink

     url="http://cvsbook.red-bean.com">on the web</ulink>. 225 pages of
     the book are available under the GPL and constitute the best
     tutorial on CVS I have ever seen. The rest of the book covers,
     url="http://cvsbook.red-bean.com">on the web</ulink>. 225 pages of
     the book are available under the GPL and constitute the best
     tutorial on CVS I have ever seen. The rest of the book covers,


@@ -284,7 +284,7 @@
    </para>
    <para>
     Also providing support and material, and inspiration for this
    </para>
    <para>
     Also providing support and material, and inspiration for this

-    HOWTO is Eric S. Raymond for his prolific, consitent, and
+    HOWTO is Eric S. Raymond for his prolific, consistent, and

     carefully crafted arguments, to Lawrence Lessig for reminding me
     of the importance of Free Software and to every user and developer
     involved with the <ulink url="http://www.debian.org">Debian
     carefully crafted arguments, to Lawrence Lessig for reminding me
     of the importance of Free Software and to every user and developer
     involved with the <ulink url="http://www.debian.org">Debian


@@ -292,13 +292,13 @@
     to practice Free Software advocacy and to make a difference, a
     place to learn from those how have been involved with the movement
     much longer than I, and an proof of a Free Software project that
     to practice Free Software advocacy and to make a difference, a
     place to learn from those how have been involved with the movement
     much longer than I, and an proof of a Free Software project that

-    <emphasis>definately, definately works</emphasis>.
+    <emphasis>definitely, definitely works</emphasis>.

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

-    up. Stallman provided the philosphical basis that attracts me to
+    up. Stallman provided the philosophical basis that attracts me to

     Free Software and that drives me towards writing a document to
     make sure it succeeds. RMS can always be emailed at <email>rms
     (at) gnu (dot) org</email>.
     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>.


@@ -364,7 +364,7 @@
   </para>
 
   <para>
   </para>
 
   <para>

-   Starting a project also involves a dilemna that you as a developer
+   Starting a project also involves a dilemma that you as a developer

    must try and deal with. No potential user for your program will be
    interested by a program that doesn't work. Simultaneously, the
    development process that you want to employ holds involvement of
    must try and deal with. No potential user for your program will be
    interested by a program that doesn't work. Simultaneously, the
    development process that you want to employ holds involvement of


@@ -375,7 +375,7 @@
   <para>
    It is in these dangerous initial moments that anyone working to
    start a free software project must strike a balance. One of the
   <para>
    It is in these dangerous initial moments that anyone working to
    start a free software project must strike a balance. One of the

-   most important ways that omeone trying to start a project can work
+   most important ways that someone trying to start a project can work

    towards this balance is by establishing a framework for the
    development process through some of the ways mentioned in this
    section.
    towards this balance is by establishing a framework for the
    development process through some of the ways mentioned in this
    section.


@@ -392,16 +392,16 @@
     already have an idea for a project in mind. Chances are pretty
     good, it fills a gap by doing something that no other free
     software process does or or does it in a way that is unique
     already have an idea for a project in mind. Chances are pretty
     good, it fills a gap by doing something that no other free
     software process does or or does it in a way that is unique

-    enought to necessitate a seperate project.
+    enough to necessitate a separate project.

    </para>
 
    <sect3 id=identifyidea>
    </para>
 
    <sect3 id=identifyidea>

-    <title>Indentify and articulate your idea</title>
+    <title>Identify and articulate your idea</title>

     <para>
      Eric S. Raymond writes about how free software projects start in
      his paper, "The Cathedral and the Bazaar" which comes as required
     <para>
      Eric S. Raymond writes about how free software projects start in
      his paper, "The Cathedral and the Bazaar" which comes as required

-     reading for any free softare development. You can find it <ulink
-     url="http://www.tuxedo.org/!esr/writings/cathedral-bazaar/">online
+     reading for any free software development. You can find it <ulink
+     url="http://www.tuxedo.org/~esr/writings/cathedral-bazaar/">online

      </ulink>.
     </para>
 
      </ulink>.
     </para>
 


@@ -415,7 +415,7 @@
 
     <para>
      If you have an idea for a program in mind, chances are good that
 
     <para>
      If you have an idea for a program in mind, chances are good that

-     it it is targetting a specific problem or itch you want to see
+     it it is targeting a specific problem or itch you want to see

      scratched. <emphasis>This idea is the project. Articulate it
      clearly. Write it out. Describe the problem you will attack in
      detail. The success of your project in tackling a particular
      scratched. <emphasis>This idea is the project. Articulate it
      clearly. Write it out. Describe the problem you will attack in
      detail. The success of your project in tackling a particular


@@ -433,7 +433,7 @@
      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
      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 definately interested in seeing it
+     scratches your itch, you are definitely interested in seeing it

      implemented in code. But, because one hacker coding alone fails
      to qualify as a free software development effort, you need to ask
      yourself the question: <emphasis>Is anybody else
      implemented in code. But, because one hacker coding alone fails
      to qualify as a free software development effort, you need to ask
      yourself the question: <emphasis>Is anybody else


@@ -442,11 +442,12 @@
 
     <para>
      Sometimes the answer is <emphasis>no</emphasis>. If you want to
 
     <para>
      Sometimes the answer is <emphasis>no</emphasis>. If you want to

-     write a set of scripts to sort <emphasis>your</emphasis> MP3
-     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>
-     MP3s, a free software project might fill a useful gap.
+     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.

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


@@ -490,8 +491,8 @@
         provides <quote>News for Nerds: Stuff that Matters,</quote>
         which usually includes discussion of free software, open
         source, technology, and geek culture new and events. It is
         provides <quote>News for Nerds: Stuff that Matters,</quote>
         which usually includes discussion of free software, open
         source, technology, and geek culture new and events. It is

-        not unusual for an particularly sexy develpment effort to be
-        announced here so it definately worth checking.</para>
+        not unusual for an particularly sexy development effort to be
+        announced here so it definitely worth checking.</para>

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


@@ -499,7 +500,7 @@
         <term>SourceForge:</term>
         <listitem>
         <para><ulink url="http://sourceforge.net">SourceForge</ulink>
         <term>SourceForge:</term>
         <listitem>
         <para><ulink url="http://sourceforge.net">SourceForge</ulink>

-        houses and facilitates a growning number of open source and
+        houses and facilitates a growing number of open source and

         free software projects, SourceForge is quickly becoming a
         nexus and an necessary stop for free software
         developers. SourceForge's <ulink
         free software projects, SourceForge is quickly becoming a
         nexus and an necessary stop for free software
         developers. SourceForge's <ulink


@@ -509,8 +510,8 @@
         embarking on a new free software project. SourceForge also
         provides a at <ulink
         url="http://sourceforge.net/snippet/">Code Snippet
         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 reusuable chunks of
-        code in an array of langauges which can come in useful in any
+        Library</ulink> which contains useful reusable chunks of
+        code in an array of languages which can come in useful in any

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


@@ -520,7 +521,7 @@
         <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 powwerful web searches that may
+        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
         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


@@ -535,7 +536,7 @@
     <sect4 id=evalhow>
      <title>Deciding to Proceed</title>
      <para>
     <sect4 id=evalhow>
      <title>Deciding to Proceed</title>
      <para>

-      Once you have successfull charted the terrain and have an idea
+      Once you have successful charted the terrain and have an idea

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


@@ -559,7 +560,7 @@
       development for many developers but it is essential. It is easy
       to become fired up by and idea and be caught up in the momentum
       and excitement of a new project. It is often extremely difficult
       development for many developers but it is essential. It is easy
       to become fired up by and idea and be caught up in the momentum
       and excitement of a new project. It is often extremely difficult

-      but it is important that any free software developer rememeber
+      but it is important that any free software developer remember

       that the best interests of the of the free software community
       and the quickest way to accomplish ones own project's goals and
       the goals of similar project can often be accomplished by
       that the best interests of the of the free software community
       and the quickest way to accomplish ones own project's goals and
       the goals of similar project can often be accomplished by


@@ -588,21 +589,21 @@
 
     <para>
      Any discussion of licenses is also sure to generate at least a
 
     <para>
      Any discussion of licenses is also sure to generate at least a

-     small flamewar as there are strong feelings that some free
+     small flame war as there are strong feelings that some free

      software licenses are better than other free software
      licenses. This discussion also brings up the question of
      <quote>Open Source Software</quote> and the debate around
      <quote>Open Source Software</quote> and <quote>Free
      Software</quote>. However, because I've written the Free Software
      Development HOWTO and not the Open Source Development HOWTO, my
      software licenses are better than other free software
      licenses. This discussion also brings up the question of
      <quote>Open Source Software</quote> and the debate around
      <quote>Open Source Software</quote> and <quote>Free
      Software</quote>. However, because I've written the Free Software
      Development HOWTO and not the Open Source Development HOWTO, my

-     own allegiences in this argument are out in the open.
+     own allegiances in this argument are out in the open.

     </para>
 
     <para>
      In attempting to reach a middle ground, I recommend picking any
      license that conforms to the <ulink
      url="http://www.debian.org/social_contract">Debian Free Software
     </para>
 
     <para>
      In attempting to reach a middle ground, I recommend picking any
      license that conforms to the <ulink
      url="http://www.debian.org/social_contract">Debian Free Software

-     Guidlines</ulink>. Examples of these licenses are the
+     Guidelines</ulink>. Examples of these licenses are the

      <acronym>GPL</acronym>, the <acronym>BSD</acronym>, and the
      Artistic License. Conforming to the definition of Free Software
      offered by Richard Stallman in <ulink
      <acronym>GPL</acronym>, the <acronym>BSD</acronym>, and the
      Artistic License. Conforming to the definition of Free Software
      offered by Richard Stallman in <ulink


@@ -611,7 +612,7 @@
      uphold,<quote> users' freedom to run, copy, distribute, study,
      change and improve the software.</quote> There are other licenses
      as well but sticking with a more common license will offer the
      uphold,<quote> users' freedom to run, copy, distribute, study,
      change and improve the software.</quote> There are other licenses
      as well but sticking with a more common license will offer the

-     advantage of immediate recognition and undestanding.
+     advantage of immediate recognition and understanding.

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


@@ -679,7 +680,7 @@
       <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 seperate
+       the license with the source and binary in a separate

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


@@ -754,11 +755,11 @@ for details.
      Please, please, please, place your software under some
      license. It may not seem important, and to you, it may not be,
      but licenses are important. For a piece of software to be
      Please, please, please, place your software under some
      license. It may not seem important, and to you, it may not be,
      but licenses are important. For a piece of software to be

-     included in the Debian GNU/Linux distrobution, it must have a
+     included in the Debian GNU/Linux distribution, it must have a

      license that fits the <ulink
      url="http://www.debian.org/social_contract">Debian Free Software
      Guidelines</ulink>. If you have no license, your program can be
      license that fits the <ulink
      url="http://www.debian.org/social_contract">Debian Free Software
      Guidelines</ulink>. If you have no license, your program can be

-     distributed in part of Debian until you rerelease it under a free
+     distributed in part of Debian until you re-release it under a free

      license. Please save yourself and others trouble by releasing the
      first version of your software with a clear license.
     </para>
      license. Please save yourself and others trouble by releasing the
      first version of your software with a clear license.
     </para>


@@ -811,12 +812,12 @@ for details.
        Whether you plan on having a split development model (as
        described in <xref linkend="branches">) or only one version
        released at a time, my experience with several free software
        Whether you plan on having a split development model (as
        described in <xref linkend="branches">) or only one version
        released at a time, my experience with several free software

-       projects and with the Debian project has taught me taht use of
+       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
        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 frusterated with the lack of
+       an older version until they get so frustrated with the lack of

        development and progress that they complain. If you never
        release an odd minor version but only release even ones, nobody
        is hurt, and less people are confused.
        development and progress that they complain. If you never
        release an odd minor version but only release even ones, nobody
        is hurt, and less people are confused.


@@ -832,7 +833,7 @@ for details.
       achievable goal, wine is released every three weeks. Wine does
       this by versioning their releases in Year Month Day format where
       each release might be labeled <quote>wine-XXXXXXXX</quote> where
       achievable goal, wine is released every three weeks. Wine does
       this by versioning their releases in Year Month Day format where
       each release might be labeled <quote>wine-XXXXXXXX</quote> where

-      the version from Janurary 04, 2000 would be
+      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.
       </para>
       <quote>wine-20000104</quote>. For certain projects, Year Month
       Day format can make a lot of sense.
       </para>


@@ -842,7 +843,7 @@ for details.
     <varlistentry>
      <term>Mozilla milestones:</term>
      <listitem>
     <varlistentry>
      <term>Mozilla milestones:</term>
      <listitem>

-      <para>When one considers Netscape 6 and verdor versions, the
+      <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
       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


@@ -851,15 +852,15 @@ for details.
 
       <para>
        Mozilla's development structure has historically been made up
 
       <para>
        Mozilla's development structure has historically been made up

-       of milestones. From teh beginning of the mozilla project, the
+       of milestones. From the beginning of the mozilla project, the

        goals of the project in the order and degree to which they were
        to be achieved were charted out on a series of <ulink
        url="http://www.mozilla.org/roadmap.html">road
        goals of the project in the order and degree to which they were
        to be achieved were charted out on a series of <ulink
        url="http://www.mozilla.org/roadmap.html">road

-       maps</ulink>. Major points and achievements along this roadmaps
+       maps</ulink>. Major points and achievements along this road-maps

        were marked as milestones. Therefore, mozilla was built and
        distributed nightly as "nightly builds" but on a day when the
        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 roadmap had been reached, that
-       particular build was marked as a milstone release.
+       goals of a milestone on the road-map had been reached, that
+       particular build was marked as a milestone release.

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


@@ -887,7 +888,7 @@ for details.
     necessary for the survival of your project. You will learn later
     in <xref linkend="releasing"> that you must always release
     something that is usable. <emphasis>A piece of software without
     necessary for the survival of your project. You will learn later
     in <xref linkend="releasing"> that you must always release
     something that is usable. <emphasis>A piece of software without

-    documentation is not usuable.</emphasis>
+    documentation is not usable.</emphasis>

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


@@ -932,7 +933,7 @@ for details.
 
     <para>
      It is also possible to write man pages using DocBook SGML and
 
     <para>
      It is also possible to write man pages using DocBook SGML and

-     convert them into man pages. Because manpages are so simple, I
+     convert them into man pages. Because man pages are so simple, I

      have not been able to follow this up but would love help from
      anyone who can give me more information on how exactly this is
      done.
      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.


@@ -940,14 +941,14 @@ for details.
    </sect3>
 
    <sect3>
    </sect3>
 
    <sect3>

-    <title>Command line accessable documentation</title>
+    <title>Command line accessible documentation</title>

 
     <para>
      Most users will expect the most basic amount of documentation to
 
     <para>
      Most users will expect the most basic amount of documentation to

-     be easily availabe from the command line. For few programs should
+     be easily available from the command line. For few programs should

      then documentation extend for more than one screen (24 or 25
      lines) but it should cover the basic usage, a brief (one or two
      then documentation extend for more than one screen (24 or 25
      lines) but it should cover the basic usage, a brief (one or two

-     sentance) description of the program, a list of commands, all the
+     sentence) description of the program, a list of commands, all the

      major options, and 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:
      major options, and 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:


@@ -993,7 +994,7 @@ pages for more information and options.
 
     <para>
      It has become a GNU convention to make this information
 
     <para>
      It has become a GNU convention to make this information

-     accessable with the <quote>-h</quote> and the
+     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
      <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


@@ -1006,7 +1007,7 @@ pages for more information and options.
      In addition to man pages and online help, there are certain files
      where people will look to documentation, especially in any
      package containing source code. In a source distribution, most of
      In addition to man pages and online help, there are certain files
      where people will look to documentation, especially in any
      package containing source code. In a source distribution, most of

-     these files can be stored in a the root directery of the source
+     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>. These files include:
     </para>
      distribution or in a subdirectory of the root called
      <quote>doc</quote> or <quote>Documentation</quote>. These files include:
     </para>


@@ -1018,7 +1019,7 @@ pages for more information and options.
        <listitem>
        <para>
          A document containing all the basic installation,
        <listitem>
        <para>
          A document containing all the basic installation,

-         compiliation, and even basic use instructions that make up
+         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
          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


@@ -1033,7 +1034,7 @@ pages for more information and options.
        <listitem>
        <para>
          The INSTALL file should be much shorter than the INSTALL file
        <listitem>
        <para>
          The INSTALL file should be much shorter than the INSTALL file

-         and should quicly and concisely describe how to build and
+         and should quickly and concisely describe how to build and

          install the program. Usually an install simply instructs the
          user to run ./configure; make; make install and touches on
          any unusual options that may be necessary. More advanced
          install the program. Usually an install simply instructs the
          user to run ./configure; make; make install and touches on
          any unusual options that may be necessary. More advanced


@@ -1055,13 +1056,13 @@ pages for more information and options.
          software project should include. A changelog is simple the
          file that, as its name would imply, logs or documents the
          changes to a program. The most simple way to do a changelog
          software project should include. A changelog is simple the
          file that, as its name would imply, logs or documents the
          changes to a program. The most simple way to do a changelog

-         is to simply keep a file with teh source code for your
+         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
          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 signifigant upgrade.
+         wait for a more significant upgrade.

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


@@ -1078,7 +1079,7 @@ pages for more information and options.
          are asked a question or see a question on a mailing list two
          or more times, add it the question (and its answer) to your
          FAQs. FAQs are more optional than the files listed above but
          are asked a question or see a question on a mailing list two
          or more times, add it the question (and its answer) to your
          FAQs. FAQs are more optional than the files listed above but

-         they can save your time, increase useability, and decrease
+         they can save your time, increase usability, and decrease

          headaches on all sides.
         </para>
        </listitem>
          headaches on all sides.
         </para>
        </listitem>


@@ -1150,7 +1151,7 @@ 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 spotlit as a more effective compression medium. I now make
+     the spot-lit as a more effective compression medium. I now make

      all my releases available in both gzip'ed and bzip2'ed formats.
     </para>
 
      all my releases available in both gzip'ed and bzip2'ed formats.
     </para>
 


@@ -1163,9 +1164,9 @@ pages for more information and options.
      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
      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 specificed libraries and
+     against a specified system with specified libraries and

      distributed in tar.gz format as well. <emphasis>Remember: While
      distributed in tar.gz format as well. <emphasis>Remember: While

-     these binaries packages are nice, geting the source packaged and
+     these binaries packages are nice, getting the source packaged and

      released should always be your priority. Other can and will do
      the the binary packages for you.</emphasis>
     </para>
      released should always be your priority. Other can and will do
      the the binary packages for you.</emphasis>
     </para>


@@ -1181,7 +1182,7 @@ 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 accessable via <acronym>FTP</acronym> or
+        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
         <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


@@ -1228,7 +1229,7 @@ pages for more information and options.
    process itself is equally important and provides an equal number of
    opportunities for failure. In the next two sections, I will and
    cover running a project by discussing how to maintain a project
    process itself is equally important and provides an equal number of
    opportunities for failure. In the next two sections, I will and
    cover running a project by discussing how to maintain a project

-   rhough interactions with developers and with users.
+   rough interactions with developers and with users.

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


@@ -1245,7 +1246,7 @@ pages for more information and options.
    The major difference between free software development and propriety
    software development is the developer base. As the leader of a free
    software project, you need to attract and keep developers in a way
    The major difference between free software development and propriety
    software development is the developer base. As the leader of a free
    software project, you need to attract and keep developers in a way

-   that leaders of proprietary software projects sipmly don't have to
+   that leaders of proprietary software projects simply don't have to

    worry about. <emphasis>As the person leading development of a free
    software project, you must harness the work of fellow developers by
    making responsible decisions and by and by choosing not to make
    worry about. <emphasis>As the person leading development of a free
    software project, you must harness the work of fellow developers by
    making responsible decisions and by and by choosing not to make


@@ -1275,9 +1276,9 @@ pages for more information and options.
    </para>
 
    <para>
    </para>
 
    <para>

-    Delegation is the politcal way of describing this process of
+    Delegation is the political way of describing this process of

     <quote>letting go.</quote> It is the process of handing some of
     <quote>letting go.</quote> It is the process of handing some of

-    the responsibility and power over your project to other reponsible
+    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
     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


@@ -1289,13 +1290,13 @@ pages for more information and options.
 
    <para>
     As your project progresses, you will notice people who are putting
 
    <para>
     As your project progresses, you will notice people who are putting

-    signfigant amounts of time and effort into your project. These
+    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
     will be the people submitting the most patches, posting most on
     the mailing lists, engaging in long email discussions. It is your

-    responsiblity to contact these people and to try and shift some of
-    the power and responsiblity of your position as the project's
+    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
     maintainer onto them (if they want it). There are several easy

-    weays you can do this:
+    ways you can do this:

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


@@ -1307,17 +1308,17 @@ pages for more information and options.
      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
      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

-     judgement and for recognizing solutions that are maintainable and
-     are not. In a sentance: <emphasis>Keep an eye out for other
+     judgment and for recognizing solutions that are maintainable and
+     are not. In a sentence: <emphasis>Keep an eye out for other

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

-     to start or good sources of inspiriation:
+     to start or good sources of inspiration:

     </para>
  
     <sect4>
      <title>Allow a larger group of people write access to your CVS
     </para>
  
     <sect4>
      <title>Allow a larger group of people write access to your CVS

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

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


@@ -1334,15 +1335,15 @@ pages for more information and options.
       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
       is an extreme example of rule by committee. At current count,
       more than 700 developers have full responsibility for certain
       aspects of the projects. All these developers can upload into

-      the main ftp servers, and vote on major issues. Direction for
+      the main FTP servers, and vote on major issues. Direction for

       the project is determined by the project <ulink
       url="http://www.debian.org/social_contract">social
       contract</ulink> and a <ulink
       url="http://www.debian.org/devel/constitution">constitution</ulink>. To
       facilitate this system, there are special teams (i.e. the
       install team, the Japanese language team) and a technical
       the project is determined by the project <ulink
       url="http://www.debian.org/social_contract">social
       contract</ulink> and a <ulink
       url="http://www.debian.org/devel/constitution">constitution</ulink>. To
       facilitate this system, there are special teams (i.e. the
       install team, the Japanese language team) and a technical

-      committee and a project lead. There is a project lead as well
-      but the lead's main responsiblity is to, <quote>Appoint
+      committee and a project lead. There is a project leader as well
+      but the leader's main responsibility is to, <quote>Appoint

       Delegates or delegate decisions to the Technical
       Committee.</quote>
      </para>
       Delegates or delegate decisions to the Technical
       Committee.</quote>
      </para>


@@ -1352,7 +1353,7 @@ pages for more information and options.
       project will not (at least initially), their example is
       helpful. Debian's idea of a project who lead who can do
       <emphasis>nothing</emphasis> but delegate can serve as a
       project will not (at least initially), their example is
       helpful. Debian's idea of a project who lead who can do
       <emphasis>nothing</emphasis> but delegate can serve as a

-      charicature of how a project can involve and empower a huge
+      caricature of how a project can involve and empower a huge

       number of developers and grow to a huge size.
      </para>
 
       number of developers and grow to a huge size.
      </para>
 


@@ -1363,16 +1364,16 @@ pages for more information and options.
        specific release.</title>
 
      <para>
        specific release.</title>
 
      <para>

-      A relase manager is usually responsible for coordinating
-      testing, encforcing a code freeze, being responsible for
+      A release manager is usually responsible for coordinating
+      testing, enforcing a code freeze, being responsible for

       stability and quality control, packaging up the software, and
       stability and quality control, packaging up the software, and

-      placing it in the approrpriate places to be downloaded.
+      placing it in the appropriate places to be downloaded.

      </para>
 
      <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>
 
      <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 somenoe else. It is a good way of very
+      rejecting patches to 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 a break.
      </para>
       clearly defining a chunk of work on the project as belonging to
       a certain person and its a great way of giving yourself a break.
      </para>


@@ -1386,16 +1387,16 @@ pages for more information and options.
       else to be the the head of a branch. If you like focusing your
       energy on development releases and the implementation of new
       features, had total control over the stable releases to a
       else to be the the head of a branch. If you like focusing your
       energy on development releases and the implementation of new
       features, had total control over the stable releases to a

-      well-suiteded developer.
+      well-suited developer.

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

-      The author of linux, Linus Torvalds, came out and crowned Alan
+      The author of Linux, Linus Torvalds, came out and crowned Alan

       Cox as <quote>the man for stable kernels.</quote> All patches
       for stable kernels go to Alan and, if Linus were to be taken
       Cox as <quote>the man for stable kernels.</quote> All patches
       for stable kernels go to Alan and, if Linus were to be taken

-      away from work on linux for any reason, Alan Cox would be more
+      away from work on Linux for any reason, Alan Cox would be more

       than suited to fill his role as the acknowledged heir to the
       than suited to fill his role as the acknowledged heir to the

-      linux maintainership.
+      Linux maintainership.

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


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

-    <title>Technical judgement</title>
+    <title>Technical judgment</title>

 
     <para>
      In <emphasis>Open Source Development with CVS</emphasis>, Karl
 
     <para>
      In <emphasis>Open Source Development with CVS</emphasis>, Karl


@@ -1423,11 +1424,11 @@ pages for more information and options.
      linkend="chooseproject">) and the ability to recognize,
      facilitate, and direct <quote>evolution</quote> of a free
      software program so that the program can grow and change and
      linkend="chooseproject">) and the ability to recognize,
      facilitate, and direct <quote>evolution</quote> of a free
      software program so that the program can grow and change and

-     incorporate functionatlity that was orignally unforseen but avoid
+     incorporate functionality that was originally unforeseen but avoid

      digressions that might expand the scope of the program too much
      and result and push the project towards an early death under its
      digressions that might expand the scope of the program too much
      and result and push the project towards an early death under its

-     own weight and unweildiness. These are the criteria that you as a
-     project mainatiner should take into account each time you recieve
+     own weight and unwieldiness. These are the criteria that you as a
+     project maintainer should take into account each time you receive

      a patch.
     </para>
 
      a patch.
     </para>
 


@@ -1454,13 +1455,13 @@ pages for more information and options.
     </para>
 
     <para>
     </para>
 
     <para>

-     The answers to these questions are never straighforward and its
+     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
      than you do. However, if you feel that that the answer to either
      very possible (and even likely) that the person who submitted the
      patch may feel differently about the answer to those questions
      than you do. However, if you feel that that the answer to either

-     of those questions is <quote>no,</quote> it is your responsiblity
+     of those questions is <quote>no,</quote> it is your responsibility

      to reject the change. If you fail to do this, the project will
      to reject the change. If you fail to do this, the project will

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

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


@@ -1469,14 +1470,14 @@ pages for more information and options.
 
     <para>
      Rejecting patches is probably the most difficult and the most
 
     <para>
      Rejecting patches is probably the most difficult and the most

-     sesnative job that the maintainer of any free software project
+     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
      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

-     powertrip or being overly bossy or possesive of a community-based
+     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):
     </para>
      project. I recommend that you keep three major facts in mind when
      rejecting patches (or other changes):
     </para>


@@ -1490,7 +1491,7 @@ pages for more information and options.
       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
       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  definately be accepted  and some that you  feel are so off
+      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.
       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.


@@ -1512,12 +1513,12 @@ pages for more information and options.
      <para>
       Especially towards the beginning, you will find that many
       changes are difficult to implement, introduce new bugs, or have
      <para>
       Especially towards the beginning, you will find that many
       changes are difficult to implement, introduce new bugs, or have

-      other techincal problems. Try to see past these. Especially with
+      other technical problems. Try to see past these. Especially with

       added functionality, good ideas do not always come from good
       coders. Technical merit is a valid reason to postpone the
       application of a patch but it is not always a good reason to
       reject a change outright. Even small changes are worth the
       added functionality, good ideas do not always come from good
       coders. Technical merit is a valid reason to postpone the
       application of a patch but it is not always a good reason to
       reject a change outright. Even small changes are worth the

-      effort of working with the submittor to iron out bugs and
+      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
       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


@@ -1542,7 +1543,7 @@ pages for more information and options.
       It is your responsibility to first justify your action to not
       incorporate their change clearly and concisely. Then thank
       them. Let them know that you a appreciate their help and feel
       It is your responsibility to first justify your action to not
       incorporate their change clearly and concisely. Then thank
       them. Let them know that you a appreciate their help and feel

-      horrible that you can't incorproate their change. Let them know
+      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
       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


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

-    <xref linkend="delegatebranch">. These alluses attest to the fact
+    <xref linkend="delegatebranch">. These alludes attest to the fact

     to some of the ways that multiple branches can affect your
     software. Branches can let you avoid (to some extent) some of the
     problems around rejecting patches (as described in <xref
     to some of the ways that multiple branches can affect your
     software. Branches can let you avoid (to some extent) some of the
     problems around rejecting patches (as described in <xref


@@ -1584,14 +1585,14 @@ pages for more information and options.
     features are rejected or put on hold under the development kernel
     is released as the new stable branch and major development begins
     again on the development branch. Bug fixes and small changes that
     features are rejected or put on hold under the development kernel
     is released as the new stable branch and major development begins
     again on the development branch. Bug fixes and small changes that

-    are unlikely to have any large negative reprocussion are
+    are unlikely to have any large negative repercussions are

     incorporated into the stable branch also to the development
     branch.
    </para>
 
    <para>
     Linux's model is an extreme one. On many projects, there is no
     incorporated into the stable branch also to 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 ot
+    need to have two versions always 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,


@@ -1600,8 +1601,8 @@ pages for more information and options.
     transition from unstable to stable. There are few projects whose
     size would necessitate a system like Debian but their use of
     branches helps demonstrate how they can be used to balance
     transition from unstable to stable. There are few projects whose
     size would necessitate a system like Debian but their use of
     branches helps demonstrate how they can be used to balance

-    consitent and effective development with the need to make regular
-    and useable releases.
+    consistent and effective development with the need to make regular
+    and usable releases.

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


@@ -1620,7 +1621,7 @@ pages for more information and options.
         but it contains gigabytes of software in over 5000 packages
         compiled for a 5-6 different architectures. Two is a good
         number. Too many branches will confuse your users (I can't
         but it contains gigabytes of software in over 5000 packages
         compiled for a 5-6 different architectures. Two is a good
         number. Too many branches will confuse your users (I can't

-        count how many times I had to describe debian's system when it
+        count how many times I had to describe Debian's system when it

         only had 2 and sometimes 3 branches!), potential developers
         and even yourself. Branches can help but they come at a cost
         so use them very sparingly.
         only had 2 and sometimes 3 branches!), potential developers
         and even yourself. Branches can help but they come at a cost
         so use them very sparingly.


@@ -1632,10 +1633,10 @@ pages for more information and options.
       <term>Make sure that all your different branches are explained</term>
       <listitem>
        <para>
       <term>Make sure that all your different branches are explained</term>
       <listitem>
        <para>

-        As I mentioned in the preceeding paragraph, different branches
+        As I mentioned in the preceding paragraph, different branches

         <emphasis>will</emphasis> confuse your users. Do everything
         you can to avoid this by clearly explaining the different
         <emphasis>will</emphasis> confuse your users. Do everything
         you can to avoid this by clearly explaining the different

-        branches in a promenant page on your website and in a Readme
+        branches in a prominent page on your website and in a Readme

         file in the <acronym>FTP</acronym> or <acronym>HTTP</acronym>
         directory.
        </para>
         file in the <acronym>FTP</acronym> or <acronym>HTTP</acronym>
         directory.
        </para>


@@ -1656,7 +1657,7 @@ pages for more information and options.
         If you are going to do branches, especially early on, keep in
         mind that people are conditioned to understand the terms
         <quote>stable</quote> and <quote>development</quote> and you
         If you are going to do branches, especially early on, keep in
         mind that people are conditioned to understand the terms
         <quote>stable</quote> and <quote>development</quote> and you

-        probaly can't go wrong with this simple and common division of
+        probably can't go wrong with this simple and common division of

         branches.
        </para>
       </listitem>
         branches.
        </para>
       </listitem>


@@ -1668,7 +1669,7 @@ pages for more information and options.
        <para>
         Like a lot of document, this should probably should go without
         saying but experience has taught me that it's not always
        <para>
         Like a lot of document, this should probably should go without
         saying but experience has taught me that it's not always

-        obvious to people. It's a good idea to physicall split up
+        obvious to people. It's a good idea to physically split up

         different branches in different directories or directory trees
         on your <acronym>FTP</acronym> or <acronym>HTTP</acronym>
         site. Linux accomplishes this by having all the v2.2 and a
         different branches in different directories or directory trees
         on your <acronym>FTP</acronym> or <acronym>HTTP</acronym>
         site. Linux accomplishes this by having all the v2.2 and a


@@ -1681,7 +1682,7 @@ pages for more information and options.
         <quote>frozen</quote> to point to which ever distribution (by
         name) is in whatever stage. Both methods work and their are
         others. In any case, it is important that different branches
         <quote>frozen</quote> to point to which ever distribution (by
         name) is in whatever stage. Both methods work and their are
         others. In any case, it is important that different branches

-        are always available, are accessable from consistent
+        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.
         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.


@@ -1716,14 +1717,14 @@ pages for more information and options.
 
     <para>
      Freeze come in two major forms. A <quote>feature freeze</quote>
 
     <para>
      Freeze come in two major forms. A <quote>feature freeze</quote>

-     is a period when no signifigant functionality is added to a
+     is a period when no significant functionality is added to a

      program. It is a period where established functionality (even
      skeletons of barely working functionality) can be improved and
      perfected. It is a period where bugs are fixed. This type of
      freeze is usually applied some period (a month or two) before a
      release. It is easy to push a release back as you wait for
      <quote>one more feature</quote> and a freeze helps to avoid this
      program. It is a period where established functionality (even
      skeletons of barely working functionality) can be improved and
      perfected. It is a period where bugs are fixed. This type of
      freeze is usually applied some period (a month or two) before a
      release. It is easy to push a release back as you wait for
      <quote>one more feature</quote> and a freeze helps to avoid this

-     situation by drawing the much neede line in the sand. It gives
+     situation by drawing the much needed line in the sand. It gives

      developers room they need to get a program ready for release.
     </para>
 
      developers room they need to get a program ready for release.
     </para>
 


@@ -1733,7 +1734,7 @@ pages for more information and options.
      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
      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 preceeds a release. Most released
+     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>
      software is in what could be interpreted as a sort of high
      level<quote>code freeze.</quote>
     </para>


@@ -1754,8 +1755,8 @@ pages for more information and options.
      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
      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 codebase
-     but for technical, political, and philisophical reasons,
+     XEmacs. Both emacsen are based on an almost identical code-base
+     but for technical, political, and philosophical reasons,

      development was split into two projects which now compete with
      each other.
     </para>
      development was split into two projects which now compete with
      each other.
     </para>


@@ -1790,40 +1791,533 @@ pages for more information and options.
   </indexterm>
 
   <para>
   </indexterm>
 
   <para>

-   If you've worked your way up to here, congratuatlions, you are
-   nearing the end of this document. This final section touches upon 
+   If you've worked your way up to here, congratulations, you are
+   nearing the end of this document. This final section describes some
+   of the situations in which you, in your capacity as project
+   maintainer, will be interacting with users and gives some
+   suggestions on how these situations might be handled effectively.

   </para>
 
   </para>
 

+  <para>
+   Interacting with users is difficult. In our discussion of
+   interaction with developers, the underlying assumption is that in a
+   free software project, a project maintainer must constantly strive to
+   attract and keep developers who can easily leave at any time.
+  </para>
+
+  <para>
+   Users in the free software community are different than users in
+   the world of proprietary software and they should be treated
+   differently. Some ways in which the groups differ significantly
+   follow:
+  </para>
+
+  <para>
+   <itemizedlist>
+
+    <listitem>
+     <para>The lines between users and developers are blurred in ways
+     that is totally foreign to any proprietary development
+     model. Your users are often your developers and vice
+     versa.</para>
+    </listitem>
+
+    <listitem>
+     <para>In the free software world, you are often your users only
+     choice. Because there is such an emphasis on not replicating the
+     work of others in the free software community and because the
+     element of competition present in the propriety software model is
+     absent (or at least in an extremely different form) in the free
+     software development model your users will probably be the only
+     project that does what you do (or at least the only one that does
+     what you do in the way that you do it). This means your
+     responsiveness to your users is even more important in that in
+     the proprietary world.</para>
+    </listitem>
+
+    <listitem>
+     <para>In an almost paradoxical situation, free software projects
+     have less immediate or dire consequences for ignoring their
+     users--it is often easier to do. Because you don't usually need
+     to compete with another product in the free software model,
+     chances are good that you will not be scrambling to gain the
+     features of the competitor's newest program. This means that your
+     development process will have to be directed either internally,
+     by your users or both.</para>
+    </listitem>
+   </itemizedlist>
+  </para>
+
+  <para>
+   Trying to tackle this unique situation can only be done
+   indirectly. Developers and maintainers need to listen to users and
+   to try and be as responsive as possible. A solid knowledge of the
+   situation recounted above is any free software developers best tool
+   for shifting his development or leadership style to fit the unique
+   process of free software development. This chapters will try and
+   introduce some of the more difficult or important points in any
+   projects interactions with users and give some hints on how to
+   tackle these.
+  </para>

 
 <!-- Section2: testing -->
 
   <sect2 id="testing">
    <title>Testing and Testers</title>
 
 <!-- Section2: testing -->
 
   <sect2 id="testing">
    <title>Testing and Testers</title>

-   <para></para>
+
+   <para>
+    In addition to your users being your developers, they are also
+    (and perhaps more commonly) your testers. Before I get flamed, I
+    should rephrase my sentence: <emphasis>some</emphasis> users are
+    your testers.
+   </para>
+
+   <para>
+    It is important that this distinction be made early on because not
+    all of your users wants to be testers. Many users want to use
+    stable software and don't care if they don't have the newest
+    greatest software with the latest and greatest features. These
+    users except a stable, tested piece of software with major or
+    obvious bugs worked out or openly declared and will be angry if
+    they find themselves in a testing position. This is yet another
+    way in which a split development model (as mentioned in <xref
+    linkend="branches">) might come in handy.
+   </para>
+
+   <sect3>
+    <title>Automated testing</title>
+    <para>
+     For many programs, many common and 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 and not very good at finding errors,
+     even major ones, that were 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
+     using 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
+     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.
+    </para>
+   </sect3>
+
+   <sect3>
+    <title>Testing by testers</title>
+    <para>
+     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.
+    </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.
+    </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:
+    </para>
+
+    <para>
+     <itemizedlist>
+
+      <listitem>
+       <para><emphasis>Make things simple for your testers.</emphasis>
+       Your testers are doing you a favor so make it as easy as
+       possible. This means that you should be careful to package your
+       software in a way that is easy to find, unpack, install, and
+       uninstall. This also means you should explain what you are
+       looking for to each tester and make the means for reporting
+       bugs simple and well established. The key is to provide as much
+       structure as possible to make your tester's job easy and
+       maintain as much flexibility as possible for those that want to
+       do things a little differently.</para>
+      </listitem>
+
+      <listitem>
+       <para><emphasis>Be responsive to your testers.</emphasis> When
+       your testers submit bugs, respond to them and respond
+       quickly. Even if you are only responding to tell them that the
+       bug has already been fixed, quick and consistent response make
+       them feel like their work is heard, important, and
+       appreciated.</para>
+      </listitem>
+
+      <listitem>
+       <para><emphasis>Thank your testers.</emphasis> Thank them
+       personally each time they send you patch. Thank them publicly
+       in the documentation and the about section of your program. You
+       appreciate your testers and your program would not be possible
+       without their help. Make sure they know and pat them on the
+       back by making sure the rest of the world knows it too. It will
+       be appreciated more than you expected.</para>
+      </listitem>
+
+     </itemizedlist>
+    </para>
+   </sect3>

   </sect2>
 
 <!-- Section2: support  -->
 
   <sect2 id="support">
    <title>Setting up a Support Infrastructure</title>
   </sect2>
 
 <!-- Section2: support  -->
 
   <sect2 id="support">
    <title>Setting up a Support Infrastructure</title>

-   <para></para>
+
+   <para>
+    While testing is important, the large part of your interactions
+    and responsibility to your users falls under the category of
+    support. The best way to make sure your users are adequately
+    supported in using your program is to set up a good infrastructure
+    for this purpose so that your developers and users help each other
+    and less of the burden falls on you while people get quicker and
+    better responses to their questions. This infrastructure comes in
+    several forms:
+   </para>
+
+   <sect3>
+    <title>Documentation</title>
+    <para>
+     It should not come as any surprise that the key element to any
+     support infrastructure is good documentation. This topic was
+     large covered in <xref linkend="documentation"> and will not be
+     repeated here.
+    </para>
+   </sect3>
+
+   <sect3>
+    <title>Mailing lists</title>
+    <para>
+     Aside from documentation, effective mailing lists will be your
+     greatest tool in supporting user support. Running a mailing list
+     well is more complicated than installing mailing list software
+     onto a machine. 
+    </para>
+
+    <sect4>
+     <title>Separate lists</title>
+     
+     <para>
+      A good idea is too separate your user and development mailing
+      lists (perhaps into project-user@host and project-devel@host)
+      and enforce the division. If people post a development question
+      onto -user, politely ask them to repost it onto -devel and vise
+      versa. Subscribe yourself to both groups and encourage primarily
+      developers to do the same.
+     </para>
+
+     <para>
+      This system provides so that no one person is stuck doing all of
+      the support work and works so that users learn more about the
+      program, they can help new users with their questions.
+     </para>
+    </sect4>
+
+    <sect4>
+     <title>Choose mailing list software well</title>
+     <para>
+      Please don't make the selection of mailing list software
+      lightly. Please consider easy accessibility by users without a
+      lot of technical experience so you want to be as easy as
+      possible. Web accessibility to an archive of the list is also
+      important.
+     </para>
+
+     <para>
+      The two biggest free software mailing list programs are <ulink
+      url="http://www.greatcircle.com/majordomo/">majordomo</ulink>
+      and <ulink url="http://www.list.org/">GNU Mailman</ulink>. A
+      long time advocate of majordomo, I would now recommend any
+      project choose GNU Mailman. It fulfills the criteria listed above
+      and makes it easier to do. It provides a good mailing list
+      program for a free software project maintainer as opposed to a
+      good mailing list application for a mailing list administrator.
+     </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.
+     </para>
+    </sect4>
+   </sect3>
+
+   <sect3>
+    <title>Other support ideas</title>
+
+    <para>
+     A mailing list and accessible documentation all you can do to set
+     up good user support infrastructure. Be creative. If you stumble
+     across something works well, email me and I'll include it here in
+     the HOWTO.
+    </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.
+    </para>
+    </sect4>
+
+    <sect4>
+     <title>Bug management software</title>
+     <para>
+      For many large software projects, use of bug management software
+      is essential to keep track of which bugs have been fixed, which
+      bugs have not been fixed, and which bugs are being fixed by
+      which people. Debian uses the <ulink
+      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
+      has spawned a sub-project resulting in a bug tracking system
+      called <ulink
+      url="http://www.mozilla.org/projects/bugzilla/">bugzilla</ulink>.
+     </para>
+
+     <para>
+      These systems (and others like them) can be unwieldy so
+      developers should be careful to not spend more time on the bug
+      tracking system than on the bugs or the projects themselves. If
+      a project continues to grow, use of a bug tracking system can
+      provide an easy standard way for users and testers to report
+      bugs and for developers and maintainers to fix them in an
+      orderly fashion.
+     </para>
+    </sect4>
+   </sect3>

   </sect2>
 
   </sect2>
 

-<!-- Section2: releasing  -->
+<!-- Section2: releasing -->

 
   <sect2 id="releasing">
    <title>Releasing Your Program</title>
 
   <sect2 id="releasing">
    <title>Releasing Your Program</title>

-   <para></para>
+
+   <para>
+    As mentioned earlier in the HOWTO, the first rule or 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
+    to simply gloss over it next time they see a new version
+    announced. Half-working software, if useful, will intrigue people,
+    whet their appetites for the version to come, and encourage them
+    to join the development process.
+   </para>
+
+   <sect3>
+    <title>When to release</title>
+
+    <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
+     is complete enough to be usable and incomplete enough to allow
+     for flexibility and imagination by your future developers. It's
+     not an easy decision. Ask for help on a local Linux User Group
+     mailing list or from a group of developer friends.
+    </para>
+
+    <para>
+     One tactic is to first do an <quote>alpha</quote> or
+     <quote>beta</quote> release as described below in <xref
+     linkend="alphabeta">. However, most of the guidelines described
+     above still apply.
+    </para>
+
+    <para>
+     <emphasis>When you feel in your gut it is time and you feel
+     you've weighed the situation well several times, cross your
+     fingers and take the plunge.</emphasis>
+   </para>
+   </sect3>
+
+   <sect3>
+    <title>How to release</title>
+
+    <para>
+     If you've followed the guidelines described in this HOWTO up
+     until this point, the mechanics of doing a release are going to
+     be the easy part of releasing. If you have set up a consistent
+     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.
+    </para>
+   </sect3>
+
+   <sect3 id="alphabeta">
+    <title>Alpha, beta, and development releases</title>
+
+    <para>
+     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
+     they are worth.
+    </para>
+
+    <para>
+     <variablelist>
+
+      <varlistentry>
+       <term>alpha releases</term>
+       <listitem>
+       <para>
+         Alpha releases are expected to be unstable, perhaps a little
+         unsafe, but definitely usable. Alpha versions should have
+         full functionality and limited testing. They can have known
+         bugs and kinks that have yet to be worked out. Before sure to
+         keep in mind that <emphasis>alpha releases are still
+         releases</emphasis> and people are not going to be expecting
+         a nightly build from the CVS source. An alpha should work and
+         have minimal testing and bug fixing already finished.
+        </para>
+       </listitem>
+      </varlistentry>
+
+      <varlistentry>
+       <term>beta releases</term>
+       <listitem>
+       <para>
+         Beta releases are general expected to be usable and
+         slightly unstable, although definitely
+         <emphasis>not</emphasis> unsafe. Beta releases usually
+         preclude a full release by under a month. They can contain
+         small known bugs but no major ones. All major functionality
+         should be fully implemented although the exact mechanics can
+         still be worked out. Beta releases are great tool to whet the
+         appetites of potential users by giving them a very
+         realistic view of where your project is going in the very
+         near future and can help keep interest by giving people
+         <emphasis>something.</emphasis>
+        </para>
+       </listitem>
+      </varlistentry>
+
+      <varlistentry>
+       <term>development releases</term>
+       <listitem>
+       <para>
+         Development release is much more vague term than
+         <quote>alpha</quote> or <quote>beta</quote>. I usually choose
+         to reserve the term for discussion of a development
+         branch. There are other ways to use the term. So many in
+         fact, that I feel the term has been cheapened. The popular
+         window manager <ulink
+         url="http://www.enlightenment.org">Enlightenment</ulink> has
+         released <emphasis>nothing but</emphasis> development
+         releases. Most often, the term is used to describe releases
+         that are not even to alpha or beta stages though and if I
+         were to release a pre-alpha release in order to keep interest
+         in my project live, this is probably how I would have to label
+         it.
+        </para>
+       </listitem>
+      </varlistentry>
+
+     </variablelist>
+
+    </para>
+   </sect3>

   </sect2>
 
 <!-- Section2: announcing  -->
 
   <sect2 id="announcing">
    <title>Announcing Your Project</title>
   </sect2>
 
 <!-- Section2: announcing  -->
 
   <sect2 id="announcing">
    <title>Announcing Your Project</title>

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

 
 

+   <para>
+    Well, you've done it. You've (at least for the purposes of this
+    HOWTO) designed, built, and released your free software
+    project. All that is left is for you to tell the world so they
+    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
+    radar screen.
+   </para>
+
+   <sect3>
+    <title>Mailing lists and USENET</title>
+    <para>
+     Email is still the way that most people on the Internet get their
+     information. Its a good idea to send a message announcing your
+     program to any relevant mailing list you know of and any relevant
+     USENET discussion group. Karl Fogel recommends that use you
+     simple subject describing the fact that the message is an
+     announcement, the name of the program, the version, and a
+     half-line long description of its functionality. This way, any
+     interested user or developer will be immediately attracted to
+     your announcement. Fogel's example looks like:
+    </para>
+
+    <screen>Subject: ANN: aub 1.0, a program to assemble USENET binaries</screen>
+
+    <para>
+     The rest of the email should describe the programs functionality
+     quickly and concisely in no more than two paragraphs and should
+     provide links to the projects webpage and direct links to
+     downloads for those that want it right away.
+    </para>
+
+    <para>
+     You should repeat this announcement process consistently in the
+     same locations for each subsequent release.
+    </para>
+   </sect3>
+
+   <sect3>
+    <title>freshmeat.net</title>
+    <para>
+     Mentioned earlier in <xref linkend="evalwhere">, in today's free
+     software community, announcements of your project on freshmeat
+     are almost more important than announcements on mailing list
+     announcements.
+    </para>
+
+    <para>
+     Visit the <ulink url="http://freshmeat.net">freshmeat
+     website</ulink> or their <ulink
+     url="http://freshmeat.net/add-project/">submit project
+     page</ulink> to post your project on their site and in their
+     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
+     interesting new releases).
+    </para>
+
+    <para>
+     Once you've finished this...
+    </para>

 
 

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

 </sect1>
 
 </article>
 </sect1>
 
 </article>