forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ferdinand Soethe <>
Subject Re: [Proposal] Refining our Development Process
Date Wed, 10 May 2006 08:57:47 GMT
Since the debate on this seems to have died down, I have changed and
extended some parts of this paper to address the points raised by
David and Ross.

Now I would like to invite all for a last round of refinement before I
put this to a vote on Friday.


Different Approaches to Development

There are two major approaches to software development represented in
the this project at the moment:

- the evolutionary coding approach where concepts are developed while
  coding and

- the classic approach of developing and discussing a concept in
  theory that is then coded and refinded.

Both approaches may have certain merits that I'm not about to
discuss here. Instead I like us acknowledge that both approaches
can help us develop Forrest and that we need to create an environment
where they can co-exist with each other and the needs of people who
are using Forrest.

Different Users

From a user's perspective. I can see at
least three different approaches:

1. Very Early Adopters (VEA) will be happy to always work with the latest
   unreleased version to try all the new features before
   they are even released.

   They have the skills to fix things if need to and accept the high
   cost of maintaining a site as a price for always having
   access to the latest features for themselves (or their clients).

1.5 Very technical people who are able to work on experimental
    parts of the code base where that code adds benefit to their project.
    However, they may not want to work with other experimental parts of the
    code base.

2. A second group, let's call them Early adopters (EA), is also
   prepared to try and use new features in their projects, but for some
   reason cannot run sites with a bleeding edge version.

   Typical reasons for this are:

   - Mission critical sites
   - clients that don't accept downtime
   - a limited budget to migrate projects along the stages of
     bleeding edge development or
   - lack of skills on the part of the EA,
     so that quick fixes of problems are not always possible.

3. A third group are users of released code (URC). For what ever
   reasons they are happy to use a released and documented version and
   have neither skill nor urge to use anything else.

As far as I can tell, we are currently doing ok for groups 1 and 3,
while group 2 is quite often unable to work with trunk in their
projects. As a result we are loosing valuable input and participation.

Different ways of Participation

Fortunately we are a community with very different backgrounds, which
are often reflected in the different development approaches
described earlier.

While some of us develop concepts through coding and re-factoring
code, others prefer to approach a question from an architects point of view.

I think that it is import to understand that this difference is not
always a matter of choice. Some people (like me) are simply to slow to
read and understand code to join the first camp while others lack the
patience (or ability) to think in concepts only.

We should design a development process that will allow both to
follow developments, to participate and contribute.

How to achieve all that?

My idea is actually quite simple and it basically extends the
white-board concept already in place.

I'll try to explain it in a few headlines:

1. Freedom of choice

  If a group of people get the itch to develop something for Forrest it
  should be up to them to choose the development method that works best
  for them.

2. Whiteboard

   Any new feature development is in a whiteboard plugin, or if this is
   not possible in a branch. It will not be integrated in trunk until
   it is internally released (will define that in a moment).

   Being in whiteboard means:

   - people are completely free in how they approach development, if and
     how they document it and how often they change their concepts.

   - they are encouraged to develop conceptual documentation early and
     discuss it with the whole of the project (to make sure everybody
     agrees with their architectural views) but there is no obligation to
     do so.

   - up to the point of internal release committers and other developers
     are welcome to but not expected to follow discussions on such a
     development or to involve themselves in the development process.

   - clear indicators (like '[WB]') in the subject line will help to
     tell group internal threads from normal project-wide discussion so
     that people can safely ignore group internal mails if they chose to
     do so.

   Whiteboard and Peer Review Priciples
   It's important to point out that this way of using the whiteboard
   is an attempt to deal with limited resources in a realistic way by
   allowing committers with limited time, to 'savely ignore' the
   discussions of early development stages and focus on paticipation
   in later stages (or when they are explicitly asked for an opinion).

   It does _not mean_ that all committers can or should ignore what's
   happening in the whiteboard. If time permits, peer review of
   whiteboard development is as desirable (and sometimes even more
   useful) as in later stages. Also, like today, peer reviewing
   whiteboard developments or discussions is not tied to an
   active involvelement in a feature development.

   Accepting that time is a limiting factor and people will (have to)
   opt out of peer reviewing certain whiteboard developments (as they
   today opt out of some discussion), it is important to notice the
   increased responsibilities of those committers participating in
   a whiteboard development (especially those committing code to the

   - Make sure that code you are committing is license compatible. If
     in doubt raise this concern to a project wide discussion.

   - Encourage participants to document their plans and ideas in well
     written, concise summaries and invite early project-wide feedback on it.

   - Pay attention to such papers from other whiteboard projects
     and make sure that interface and compatibility issues are
     addressed early on.

   In addition to all these safeguards documentation templates for
   whiteboard development should carry full information about the
   meaning of whiteboard status in Forrest.

3: Internal release

  When the group is satisfied with architecture, features and
  performance of their development they propose an 'internal release' to
  integrate their development into trunk (or move a plugIn out of the

  Minimum Requirements for internal release are:
  (this may need further discussion)

  - A well documented and stable architectural concept that the group is
    prepared to defend in a project wide discussion.

  - Stable code that is mature enough not to break trunk

  - Basic low level practical documentation
    = how to install
    = what will break / what needs to be done to migrate
    = how do I use its features

  - A suite of tests. For plugins that are well documented we have tests
    built into the documentation. That is if the docs have examples of all
    features, then doing "ant test" in the plugin directory will run the
    tests accordingly.    
  - A preparedness to answer silly questions from people who try to
    flesh out documentation in the next stage.

The outcome of the application can be one of the following (decided by
a Lazy approval [1] after discussing the proposal):

  - Acceptance

    The development is sound and complete and is considered to be a
    useful extension of Forrest that we are happy to support as part
    of Forrest. It will then be scheduled for the next release (see
    4. below).

  - Postponement

    The development is either incomplete or has other deficiencies
    (including poor design, performance etc.)

    It remains in whiteboard for improvement and can once again be
    proposed for internal release later on.

  - Rejection because the proposal violates basic design concepts, adds
    blinking text or is deemed useless by the project (add other

    It may remain in whiteboard for everybody to use or give it another

4. External Release

  Developments accepted in the internal release process should be
  scheduled for release as soon as possible.

  As a rule we should not wait to accumulate several features but aim
  to release each feature on its own so that users can familiarize
  themselves with and test each new feature as soon as possible.

  The idea is that integrating, testing and documenting an already
  well developed new feature will allow a great number of people to
  involve themselves (in integration, testing, documentation) and
  could perhaps become a subject for a Forrest Friday with many
  different tasks that can be worked on in parallel.

  I'd also like to see this develop as phases in the project year
  where many committers work together on a common goal and get familiar
  with each others work.

Ferdinand Soethe


View raw message