cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] Rules for adding blocks and functionality?
Date Wed, 26 Oct 2005 19:58:16 GMT
Upayavira wrote:

>Bertrand Delacretaz wrote:

>> Sounds good, and as a first step this could be our own contrib directory.
>No it wouldn't, because we wouldn't agree what should go there.
I think we could agree about some of the existing blocks, but never 
mind. But we are not forced to continue to have sloopy rules for how to 
adding functionality, a contrib directory could be useful for new blocks 
that not have any community support yet or that are outside our main scope.

>suggestion is to, as you did with the samples, leave all blocks as they
>are, and start _hightlighting_ the ones we consider to be best
>practices. Then, after some extended period if time we may decide to
>purge the ones that have not received any highlighting, but highlighting
>core blocks works much better than deprecating old blocks that people
>may be using.
>(And by way of recommendation of this approach :-) this is the approach
>that Buddhists throughout the centuries used to deal with teachings that
>had grown stale. They didn't say "that is a bad teaching", they said,
>"hey, we've got a higher teaching".)
>So, basically, until we've got blocks functioning, and have had them so
>for _some_ time, we should do nothing more than highlighting and marking
>up with meta-data for our blocks. Our blocks system and block repository
>is going to create a new organism (which, yes, could well want a contrib
>group elsewhere such as Niclas suggested), but I want to allow for that
>organism to grow, well, organically :-)
Sound good. The important point IMO is that we start to be explicit 
about our priorities in some way. And highlighting might be easier to do 
than removing.


View raw message