Le Mercredi, 24 sep 2003, � 23:08 Europe/Zurich, Stefano Mazzocchi a �crit :
On Wednesday, Sep 24, 2003, at 20:34 Europe/Rome, Timothy Larson wrote:

<lots-of-snips cause="agree"/>


The above suggests one simple, but really important thing:

the block 'health' metadata should *NOT* be included in the block, but should be looked up from a centralized 'weather reporter' part of the block librarian.

Yes - and maybe we shouldn't impose too much structure on this weather report, just require that block providers have one "block status" documentation page, where they tell people about contract stability, API stability, future plans, active contributors and the like.


If this is somewhat narrative rather than checkboxes, users should be able to get a feel of how seriously the block authors take their work, and not finding the expected info will be a sufficiently bad sign.

...The best way to judge is to make a vote.

And the vote should not, in any circumstance, make the block being voted bad if the vote doesn't pass.

So, the answer to

3) is the community healthy?

is misposed. I would like to have somethign a little less judging: something like

3) is the cocoon community officially supporting this block?

Agreed.


The risk is to come up with something which is not really meaningful. Because "official support" doesn't really mean anything.

Agreed as well. I still like "supported", meaning that the community cares for a particular component.


Many projects use also "contributed" to mean that a piece of software is distributed along with the main code but comes from outside.

How about "supported", "contributed", "experimental" and "deprecated" blocks?

Here are some suggested examples with blocks that I know (more or less) about:

"supported":
Considered part of the "mainstream use" of Cocoon and supported as such, documented, tested before each release: axis, batik, chaperon, cron, databases, fop, hsqldb, html, itext, jfor, lucene, mail, portal, velocity, woody


"contributed":
Either one-man shows, outside contributions with no broad community support or samples with no additional functionality: deli, midi, qdox, linotype, petstore


"experimental":
Either wild experiments, or use experimental technologies, or waiting for feedback: slop,stx,eventcache,scratchpad,asciiart


"deprecated":
Not recommended for new projects, support will likely go away: xmlform

Please don't flame on particular classifications at this point, I'm just trying to get the idea across ;-)

-Bertrand

Reply via email to