<snip/>

Hm... don't like this. The scratchpad would be to distant from the cocoon itself.

Yes, just like the Wiki docs are distant from the xdocs. Just like the Wiki, it could benefit from much wider participation.

agreed


<snip/>

Hm... don't understand why other rules should apply for the scratchpad than for the "core project"?

The core project's central rule is: only established committers can play. Nothing wrong with applying that to the scratchpad, if all you want to do is incubate code.

I'm thinking, why not discard that rule for the sandbox, and use it to
incubate *committers* as well as code?

Hm...


I mean - everyone can start a sourceforge project and see if it works out and later contribute/offer the code to the cocoon project.

Yes. Imagine if someone on cocoon-users started an umbrella project on SF for useful Cocoon snippets. Wouldn't this also be a logical place for alpha Cocoon stuff?

Well, depends if we still would have a scratchpad/sandbox at apache ;)


sandbox.cocoondev.org?

I think the scratchpad/sandbox should remain in the apache cvs!

:) Just throwing around ideas..

:)


But what I fear is that the relation to the cocoon project is much looser and less visible. People will tend to forget about this area even more. And opening the scratchpad to a wider audience means more people and (at least) *could* result in even a bigger mess. And this is not because of the people but due to the nature the scratchpad code. It's code that is not yet ready for prime time and that usually was started as a one man show. It is not felt as community code therefor has a much higher probability to end up as dead code.

The only difference that I see is that this mess will not be inside the cocoon repo.

If the relation would not matter.. Why did everyone put/kept the stuff in scratchpad and did not move it over to cocoon-apps?

I see the scratchpad a little like a blackboard - the only thing we have to do is to wipe it out from time to time ;)
--
Torsten




Reply via email to