forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ferdinand Soethe <ferdin...@apache.org>
Subject Re: [Proposal] Refining our Development Process
Date Wed, 03 May 2006 22:02:28 GMT

[I'm sipping an excellent yeast brandy while typing this so please
 excuse if not everything makes perfect sense :-)]

Ross Gardler wrote:

> In open source projects there is a fourth type of user. This one sits
> somewhere between your type 1 and type 2, lets call them type "one and a
> half".

> These people are very technical and 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.

Thanks for adding that piece of info.
So what exactly is the difference between group 1 and 1.5?

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

> Agreed. The plugin system should make it possible to accomodate the type
> "one and a half" people. Just develop new experimental code as a plugin
> and leave it up to the adopters to choose whether to use it or not. This
> can work well, witness the fact that dispatcher work, in the main, did
> not affect users of core.

Hmm. So are these 1.5 people early adopters that are skilled and
interested to work with parts of a new release like Diwaker did by
implementing a dispatcher skin?

> Let me expand on that a little - new *feature* development is in a
> whiteboard plugin, or if this is not possible in a branch.

Thanks for adding that. I fully agree.

> Firstly:

> The strength of Open Source development is the many eyes concept. To 
> encourage people to ignore parts of the development we are removing 
> this.

Let's say we are simply trying to be realistic about this. As it is
people will opt out of certains discussions for lack of time, or
interest or other reasons.

By separating the (high volume) discussion of early development phases
from the rest of our discussions I hope that we'll be more focussed on
the important stuff. One of them being the discussion when a group
asks the project for comments or an internal release.

> We need to be very careful what we mean by "safely ignore". From a
>   quality perspective we cannot "safely ignore" since important issues
> may be missed.

I see it from a different perspective: Having that virtual space of
their own, will allow a group to make AND correct their own mistakes
which is an important part of the learning process.

If they follow the advice to discuss their concepts with the project
early, nothing is lost. If they don't, flaws will surface in the
internal release phase and they may have wasted some time in coding
something that will never make it into core. That also can be a
learning process.


> PMC oversight is requried to ensure that there are no legal issues with
> new code being developed. If we "safely ignore" development on some 
> aspect we are possibly ignoring critical issues.

True. This is one question we really need to monitor.

otoh the only people who can commit code are committers. And they should be
well aware of license issues. So the least we could expect from them
(us) is to ask unless a licensing situation is clear.

> That being said, the
> reality is that no single member of the PMC reads every single commit 
> message or email anyway. So again, I think the problem is in the 
> terminology rather than your intent.

Ok, but this part definitely needs refinement.

> Thirdly:

> It should be reinforced that if someone decides not to particpate in 
> development of a new feature within the whiteboard there opinions in 
> terms of arcitecture and design are still valid. One does not have to 
> contribute code to contribute to a development effort. We have seen that
> it can be upsetting for developers creating new code when they get 
> feedback that generates yet more work, but they get little in the way of
> code contributions. This is to be expected from the "one and a half" 
> people since they have a deep understanding of the core system and its
> direction, but little time to contribute to every part of development.

Thanks, can't stress that enough.


> However, even though everyone is entitled to an opinion, it does not 
> mean the whiteboard developers have to impelment it in line with that 
> opinion. If their itch is different then fair enough.

Let me add: Yes! You can still ignore and reject such 'parachuted'
advice, but you have to be pretty confident about the quality of your
design. Or else it will come back to haunt you during the internal
release discussions.

>>   - Stable code that is not mature enough not to break trunk

> You mean that *is* mature enough not to break trunk.

Correct. Thanks for catching this.

>>   - 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 preparedness to answer silly questions from people who try to
>>     flesh out documentation in the next stage.

> lets add:

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

+1

>>   The outcome of the application can be one of the following:

[...]

> OK, this is all fine and can be covered by a simple majority vote after
> discussing the proposal.

True.

My point here was that a postponement or rejection does
not mean that it cannot be used or worked on. It only means that it
will not become part of an official Forrest release that we all
support.

It's all about allowing space for spontaneous and creative development
within the project but outside of the official releases.

> I like it.

Thanks for your comments.

--
Ferdinand Soethe


Mime
View raw message