We still haven't reached consensus on this issue and I think that we also mixed concerns in the previous threads. I see several issues on the table:
1) how to allow committers to innovate on core
Anything in *core* needs community support. This should not have a scratchpad IMO. Why? The API needs to be clean. The core is what you are saying will be supported no matter what. Therefore the core needs to reflect what the community is willing to support.
2) how to allow committers to innovate on non-core stuff
This is where I think a sandbox/scratchpad would work if the community wants it. Blocks are *additions* to cocoon that anyone can use if they choose to. By defining how to write blocks and set them up and incorporate them into your own projects, it makes it easier to maintain a clean system.
issue #1 & #2 -------------
So, I propose to try to cleanup the scratchpad as much as possible and see what's left, as for Nicola suggestion. Of course, help from the code authors will be *VERY* appreciated.
At that point, we'll decide whether to keep the scratchpad or not and, in case, create some policies about it.
Deal?
Sounds good.
