Guys,
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
increased.
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
entirely.
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
