<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">
<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 -->
<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">
<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 -->
projects / fspm_howto / commitdiff