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 }
