Finished most of delegation except the first and last thing in the

[fspm_howto] / FreeSoftwareProjectManagementHOWTO.sgml

diff --git a/FreeSoftwareProjectManagementHOWTO.sgml b/FreeSoftwareProjectManagementHOWTO.sgml
index d41ae2b3b08491e4c4b0cc25141a13e52a4f9483..8ff98a7e8e5d2efefce5a99ac566d75c0228b196 100644 (file)
--- a/FreeSoftwareProjectManagementHOWTO.sgml
+++ b/FreeSoftwareProjectManagementHOWTO.sgml
@@ -1221,13 +1221,118 @@ pages for more information and options.
     <primary>fswd!developers</primary>
    </indexterm>
 
+  <para>
+   Once you have gotten the project started, you have gotten over the
+   most difficult hurdles in the development process of your
+   program. Laying a firm foundation is essential, but the development
+   process itself is equally important and provides 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.
+  </para>
+
+  <para>
+   The difference between free software development and propriety
+   software development is th 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
+   worry about. <emphasis>As the person leading development of a free
+   software project, you must harness the work of fellow developers by
+   making responsible decisions and by and by choosing not to make
+   decisions responsibly. You have to direct developers without being
+   overbearing or bossy. You need to strive to earn respect and never
+   forget to give it.</emphasis>
+  </para>
+
 <!-- Section2: delegation  -->
 
   <sect2 id="delegation">
    <title>Delegating Work</title>
+
+   <para>
+    By now, you've hypothetically followed me through the writing of a
+    piece of software, the creation of a website and a skeleton of
+    documentation and functionality and we've gone ahead and (as will
+    be discussed in <xref linkend="releasing">) released it to the
+    rest of the world. Times passes and people hopefully becoming
+    interested and people want to help and patches begin flowing in.
+   </para>
+
+   <para>
+    Like the parent of any child who grows up, it's now time to wince
+    and smile and do most difficult thing in any parents life: It's
+    time to let go.
+   </para>
+
+   <para>
+    Delegation is the politcal way of describing this process of
+    <quote>letting go.</quote> It is the process of handing
+    responsibility, and power, over aspects of your project to other
+    reponsible developers. It is difficult for anyone who has invested
+    a large deal of time and energy into a project but it essential
+    for the growth of any free software project. One person can only
+    do so much.
+   </para>
+
+   <para>
+    As your project progresses, you will notice people who put
+    signfigant 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
+    responsiblity to contact these people and to try and shift some of
+    the power and responsiblity of project maintainer toward
+    them. There are several easy weays you can do this:
+   </para>
+
+   <para>   
+    <itemizedlist>
+
+     <listitem>
+      <para>
+       <emphasis>Allow a larger group of people write access to your
+       CVS reponsitory and make real efforts towards rule by a
+       committee.</emphasis>
+      </para>
+     </listitem>
+
+     <listitem>
+      <para>
+       <emphasis>Publicly appoint someone as the release manager for a
+       specific release.</emphasis> A relase manager is usually
+       responsible for coordinating testing, encforcing a code freeze,
+       being responsible for stability and quality control, packaging
+       up the software, and placing it in the approrpriate 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
+       rejecting patches to somenoe 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>
+     </listitem>
+
+     <listitem>
+      <para>
+       <emphasis>Delegating control of an entire branch.</emphasis>
+      </para>
+     </listitem>
+
+    </itemizedlist>
+   </para>
+
+  </sect2>
+
+<!-- Section2: patching -->
+
+  <sect2 id="patching">
+   <title>Accepting and Rejecting Patches</title>
    <para></para>
   </sect2>
 
+
 <!-- Section2: branches  -->
 
   <sect2 id="branches">
@@ -1248,13 +1353,6 @@ pages for more information and options.
    <title>Avoiding the Code Cram Effect</title>
    <para></para>
   </sect2>
-
-<!-- Section2: patching -->
-
-  <sect2 id="patching">
-   <title>Accepting and Rejecting Patches</title>
-   <para></para>
-  </sect2>
  </sect1>
 
 <!-- Section1: users -->