forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <cross...@apache.org>
Subject Re: [Proposal] Refining our Development Process
Date Thu, 11 May 2006 06:06:42 GMT
Ferdinand Soethe wrote:
> 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.

When you do, please change the Subject line so that
it explictly says "whiteboard". There are many other
aspects that have not been addressed by this proposal,
so it does not apply to other development (non-whiteboard).
http://forrest.apache.org/guidelines.html#development
e.g. define how we add new functionality to plugins that
have already emerged from the whiteboard and how to
maintain a trunk that is "always usable".

Another thing that i would like to say up front is that
i find myself repeating stuff said in the last major
discussions. I would encourage people to read this
whole thread:
[A]
 [Proposal] Development process and a stable trunk
 http://marc.theaimsgroup.com/?t=112504310100005

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

What is it that stops group 2 from operating?
Why can't they use a particular SVN revision number
of trunk that they know works?

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

As i said in the recent discussion, "whiteboard" is already
in the "trunk". I think that you mean "move out of whiteboard".
See other comments at the end of this email.

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

Tim, and all other respondents, raised some very
important concerns in the previous proposal [A].

We already know that many people do not use a sensible
subject line for their email messages. So trying to
get them to add a prefix will be difficult too.

Another issue is that discussions often fork into
some very important new general topic and people
do not change the subject line. So important topics
will tend to be ignored.

Another issue is that prefixes will enable people
to automatically filter mail out-of-sight. This would
lead to a fragmented community.

If we just continually encourage the use of descriptive
email Subject lines and new ones for new topics,
then the main aim of your proposal is accomplished.
So there is no need to explictly talk about ignoring
some topics.

As Ross said in [A], one can peek into the first
posting of a thread, and then follow it or not.

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

I, for one, am not prepared to add the concept of
"safely ignore" to our project guidelines. It totally
goes against the Apache projects' PMC oversight principles.

People can make up their own mind about what they follow
and what they don't follow. I don't see a need to explictly
sanction the ignoring of topics. KISS.

>    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
>    whiteboard):
>
>    - 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
>   whiteboard).
> 
>   Minimum Requirements for internal release are:
>   (this may need further discussion)

Also needs to gain "community". If the code is a
one-person affair then we will get into trouble.
I suppose that an actual Vote would express that,
because +1 also indicates a willingness to assist.

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

It should be stressed that stuff should move out of
the whiteboard as soon as possible (similar to how
branches should merge ASAP). Don't stay there until
it is complete.

What level of functionality is required? Just basic
i presume.

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

Using "Lazy approval" is intended for the normal
development process, i.e. just do it, and if someone
raises a alarm bell then we backtrack/fix/decide.
This encourages efficient development and is used
as often as possible.

With your proposed change of process i do not see how
it will work.

Using lazy approval makes it hard to get the beast
back into the whiteboard in the case of "Postponement"
or "Rejection".

>   - 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
>     reasons).
> 
>     It may remain in whiteboard for everybody to use or give it another
>     try.
> 
> 
> 
> 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
> 
> [1] http://forrest.apache.org/guidelines.html#approvals

There are some other things that need considering ...

There is already a concept about "deployed" plugins
and "released" plugins. I cannot see where this is
defined in our docs.

Also we haven't yet defined a process for official releases
of plugins as separate from the release of a whole package
of trunk (e.g. forrest-0.7) which includes all plugins
(including whiteboard) in their current state. Official
releases of any product requires a PMC vote.

That leads to another problem with the current proposal.
When it comes time for a release of Forrest (e.g. 0.8)
then the PMC needs to vote on what is packaged with that
release. Currently that includes $FORREST_HOME/whiteboard/.
PMC members who have not been watching what is happening
would have difficulty with voting.

I wondered earlier in this thread if whiteboard should
be moved outside of our trunk. That might solve some
problems, but there are other factors against doing it.

-David

Mime
View raw message