Nicola Ken Barozzi wrote:
When a project doesn't understand what to do, it creates proposals, and each "steal" from the other the best bitsBingo. The difference between the above and current practice is that projects create proposals, not individuals. Every line of code in Avalon was committed by somebody but is owned by everybody. Proposals should not be any different.
In other words, the creation of such internal forks is to be done based on consensus on the scope, visibility, and design direction of such an effort. This does not mean that there needs to be consensus of opinion on the viability of the design approach; merely that the idea merits exploration - even if the ultimate result is only to prove that it is indeed a dead end.
As long this code resides under the purview of an existing PMC, no separate voting or commit rights should be sanctioned for this code. Nor should vetoes be used after the fact to change the agreed upon scope of such an effort.
Separate code bases with separate communities should be separate projects. Independent of the size of the codebase, if the size of the community is only a few people, then it is not an ASF project. Such efforts can be pursued outside of the ASF, be pursued inside the Incubator, or be incorporated inside an existing community � as long as all participants in that larger community are treated as peers.
- Sam Ruby
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
