What would removal of the Scratchpad force on the community?
* More controlled innovation. Instead of anybody using it as their personal playground, it would force the development to be more in the face of the community.
Hence schecoon would have been shot down in flames, as people -1'ed it on the syntax.
;P All revolutionary ideas are like that. What would likely have happened is that the interested parties would have incubated it elsewhere--perhaps on SourceForge. Knowing the authors' temporament as they stuck with it, they would have kept in constant contact.
At a later time when everybody "got it", it would most likely have been incorporated into the main trunk like it is now.
* Better concept of exactly what is in Cocoon. After not being active for a while and comming back, I don't even recognize the project. How many of the current developers know *all* of what is in the CVS archive?
Why would anyone not interested look in the scratchpad?
Which is exactly the point.
* If the community doesn't want to support it, move it someplace else. IOW if the community doesn't want some code in the main trunk it is for a very good reason. The proposing developer would be encouraged to incubate the project elsewhere.
Playgrounds *have* to exist. The question is, do they happen in the scratchpad or on someone's hard disk. At least in the scratchpad, there is a chance of half-baked code inspiring others, and forming a nucleus for further development.
Or on SourceForge? It would be actually more healthy for this project if there were a bunch of projects that depended on it and incorporated themselves into it. Right now we have rampant inbreeding and bloating of the project.
I agree, there is a real problem in that scratchpad code tends to hang around in limbo forever, never accepted nor rejected.
So how about assigning each scratchpad module a "lease"; being a predefined period (say 3 months) after which the code's presence in CVS must be reviewed. When the lease expires, a vote is held, and the code either becomes official, or is rejected, or has the lease renewed.
For every unit of alpha-quality code (block, scratchpad segment), we could have a status file (as Tony Collen suggested) indicating things like: - code owners (cocoon-dev is not the owner yet) - description (eg links to mailing list discussions) - lease expiry
Managed inclusion rather than exclusion.
Playgrounds/Scratchpads etc. have a set of challenges surrounding them that not everyone is aware of. How do you manage CVS access? It may be that someone has a great idea that needs some incubation, but they have not proven themselves for Cocoon CVS access rights yet. Do you grant it to them? What happens when you have people making comments like "my new module" or "my code does this"? That is a subtle anti-community sentiment that builds when there is a "scratchpad" section in a greater CVS archive. These issues need to be dealt with as they are more damaging than bad code in the CVS.
If anything is in Cocoon's CVS archive it MUST have community ownership, and community support.
If you want to dedicate another CVS archive or a SourceForge account to incubating these things, that would be a better ideal IMNSHO.
