Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <4217A87B.4050401@apache.org>
Date: Sat, 19 Feb 2005 21:58:35 +0100
From: Sylvain Wallez <sylvain@apache.org>
Organization: Anyware Technologies
User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] How scripting made me hate java
References: <421079EF.7080204@apache.org> <4211A4D4.7020307@apache.org>
 <4211F9C8.1080507@nada.kth.se> <4212253E.2010106@apache.org>
 <4212805C.9060709@apache.org> <42130EBC.7030008@apache.org>
In-Reply-To: <42130EBC.7030008@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Carsten Ziegeler wrote:

<snip/>

> So, my opinion is we should just look at what people want to use, what 
> *we* thing is the best to have, combine those two and then: just do 
> it. The past showed that first discussing things lead to no code while 
> first coding somethings and then start a discussion based on the code 
> works very well. Even if the code is totally changed or removed, it 
> seems to be the better way.
>
> And this is what I'm currently trying to do: I'm doing a lot of 
> projects with Cocoon and I'm talking to many users of Cocoon. While 
> they use Cocoon in different areas, they all have the same problems 
> and even we - working with Cocoon for nearly 5 years now - have 
> similar problems. So I'm taking the feedback, add my own thoughts and 
> implement ideas to see where this may lead. With the current core we 
> have a good base to implement new things. It's our own code and we can 
> add new features like AOP or JMX support there without any problems.
> But if I have to discuss each and every feature with 20 people - 
> everyone having it's own ideas - I'm most times blocked: 5 people like 
> the idea, 3 people don't like the idea and so you're doomed.


I strongly disagree with your point of view: it's bad to do things on 
your own and then inform people of what you do when it's finished and 
committed. Sure, you may have no problem with other people deeply 
modifying your code afterwards, but you have to understand that not 
everybody feels the same and that people are respectful of other's work 
because of the time and energy it represents. Especially when that code 
comes from one of the core developers.

Now that doesn't mean everything should be discussed and voted, but that 
you need to inform people of the directions you want to take, the 
prototypes you want to try, etc.

Why so? First of all, we are a community, and not a group of individuals 
each working in their corner of a shared SVN repository. Understanding 
the commits flowing on the mailing list is easier if we know a bit what 
they're about beforehand.

Secondly, other people can bring you other point of views and other ways 
to tackle a problem and our collective brain is far more powerful than 
the sum of our invidual brains. Otherwise, why would we be involved in 
OSS projects?

And finally, even if you accept that your code is deeply refactored, 
this represents a lot of wasted energy for you and for others to 
understand and refactor afterwards rather than giving their inputs 
earlier. By knowing earlier, at least people will have the occasion to 
think about the problem and maybe understand what you do and why you do it.

And all this doesn't prevent "just do it": tell people that you *will* 
just do it rather than saying that you just *did* it. Community-wise, 
because that's where we have a problem also, this makes a big difference.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }