On Tuesday, Sep 23, 2003, at 08:38 Europe/Rome, Nicola Ken Barozzi wrote:
Stefano Mazzocchi wrote:
I fear one-man-shows.
May I guess where this fear comes from... Avalon? ;-)
yeah
I have the same fear.
At the same time, we need 'sort-of incubation' practices for blocks, as it is impractical to think that a cocoon committer would develop his/her code outside and submit it only when there is a community around a block.
Yes, I agree.
This is why I had proposed to keep scratchpad blocks in the scratchpad and not mix them with released ones. This makes one-man shows easier to do and more difficult to manage.
Agreed.
At the same time, I want to avoid the "move things around" dance that happens when something 'matures'.
As 'maturity' is not a black/white process (there is no point in time where a community turns into maturity, it's just a feeling)
Instead of associating 'maturity levels' to the actual location of a block, I would state that as a 'label' attached to it, a label that the block deployer reacts to and prompt the user for action in case the block is not considered "final" by the community.
That would:
1) keep the freedom to initiate as many blocks developers want
2) avoid the 'move things around' CVS dance
3) allow easy and mechanizable checking of which blocks are considered "stamped" by the cocoon community.
so, the only thing left is to define how you get those blocks "stamped", but I think it would just require a community vote with a majority.
Such "stamping" should be done thru the use of a digital certificate so that the block deployer can say "this is a block certified by the cocoon community as final".
the block system will work effectively *ONLY* if there is strong cross-pollination between blocks and if the cocoon community keeps strong oversight over what happens.
this hasn't been so for many blocks so far and I see this as a potential problem.
It's just the beginning. I would suggest to:
1) keep the voting system and responsibility over blocks as now, that is
open to all Cocoon committers
+1, I would just suggest, for 2.2, that all blocks that want "certification" are required to obtain this thru a vote. And, before the certification can happen, a few things must be done, mostly, community diversity checking and documentation availability.
2) make a scratchpad-incubaton-callitwhatyouwant directory or even better CVS module where alpha blocks or features are done
-1 on this, as for the cvs-dance argument above.
3) partition commit acces like this: 1) only core cocoon committers can commit to the core 2) all committers have access to Lenya, Forrest and Blocks
+1
(when/is Forrest going to actually move?)
don't know the status of this
-- Stefano.
