cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From hepabolu <>
Subject Re: [RT][long] Cocoon 3.0: the necessary mutation
Date Sun, 04 Dec 2005 08:58:06 GMT

I've read the post and all of your reactions (35 at this time). Although 
I cannot fathom the implications of most proposals, I'll try to 
summarize what I think you (and I) generally agree on:

Cocoon in its current form needs an extreme makeover/complete overhaul 
with the following keywords being the central focus:

- simplicity
- productivity
- fun/sexy

To expand on that:

Cocoon should be easy to use, in vary many different ways: easy start 
for newcomers, easy to build your own application with, easy to embed in 
other applications/frameworks, easy to understand.
I think productivity will automatically increase when simplicity is 
Cocoon should be fun and sexy. The fun factor is definitely tied to the 
simplicity and productivity factors. The easier and faster you can do 
something with Cocoon, the more fun it will be to use it. The sexiness 
come from being able to look at the latest developments, recognizing and 
integrating the good and throwing out the "one-night stands". In short: 
if Cocoon doesn't pick it up, it's not worth investigating it.

What all this means in terms of code, I have no idea, but I do know this:

- the current developer group needs to find a better balance between the 
current bunch of creative friends and a regular project team. Cocoon has 
become a beast because everybody could add code that was thought to be a 
fun feature or solved a personal frustration. If you want a simple, 
clean, lean and mean Cocoon machine, you need more of a project team 
that "judges the parts by looking at the whole" and gets everyone 
focused in the same direction.

- if you want Cocoon 3.0 you have to either turn Cocoon 2.2 into 3.0 or 
ditch it altogether. Cocoon 3.0 will never happen when 2.2 is around. 
Since there has been no release of 2.2 yet, you might want to skip that 

What this means to me is that in order to renew Cocoon, the community 
should renew itself. Before building the software, build a vision and 
make sure that everyone who wants to contribute knows what to do and 
which rules should be followed. Adjust the way the community works. Do 
we need a different organisation, more/other rules? All this only to 
allow creativity to flow, but in the right direction.

Don't venture of in technical discussions about the best solution to 
solve the problem, when the problem hasn't been defined properly and 
been agreed on by everyone. And don't write the solution and find the 
problem afterwards. We're capable of producing higher quality than that.

And of course write documentation. I've read the discussions: "you can't 
write documentation about something that's not there/still changing" and 
"you won't attract users when there is no documentation". To me 
documentation comes in cycles too: write early, write often and 
integrate the writing process in your development cycles.

Bye, Helma

View raw message