On 2/4/06, Sam Ruby <[EMAIL PROTECTED]> wrote: > This discussion would be a lot easier if it were of the form "here's > code that I would like to see at the ASF, and I'd like to participate > and make use of it in the following manner... independent of where the > code ends up". > > But as it stands, the discussion to date gives the appearance that a > number of people are more interested in where this code ends up than in > the code itself.
These were my thoughts exactly reading the earlier threads. It's amazing that everyone seems to accept that its a good idea and yet its stalled on the destination. FWIW, I thought Bill's explanation of how the destination was selected was great. So, is selecting the destination up front a bad idea? I don't see how it should ever matter unless the destination excludes someone (which is a different problem!) How about listing potential destinations, and reasons some aren't potential destinations? Then those that want to be involved can say so and the best destination can be selected on exit. It occurs to me that its not entirely certain whether ServiceMix will be a part of Geronimo, or a TLP anyway. The governance becomes entirely the responsibility of the incubator PMC until it graduates, or forms a PPMC as it decides to target becoming a TLP. Collaboration starts on [EMAIL PROTECTED] until a dev list is formed for the thing being incubated itself. As a step by step process, this would be: 1. proposal for new code (no matter how big or small) sent to [EMAIL PROTECTED] * Discussion of potential destinations (existing or new TLP) and reasons (discussion may have already occurred at other projects to evaluate this, like the Agila example above). * At least one member/officer champion is required. * Should specify whether it attempts to build a community around code (Mentors required), or send the code directly to a specified project's existing community (recent examples are the Maven subprojects, or commons-csv). 2. ASF-wide feedback on it, including appropriateness of destinations and possible additions 3. Vote to accept it. (I'm not sure what the metric on acceptance is here - is it three +1's from the PMC, vetoable, or majority?) 4. software grant sent, clas filed. 5. Once paperwork is confirmed by the champion, code can be imported. Champion role ends 6. IP clearance needs to be worked through in parallel with other work, and a top priority. If this is cleared and there was a known destination and no need to build a new community, then "graduation" to the project can proceed. I expect this should require a vote on [EMAIL PROTECTED] again and require binding votes from both the incubator and destination PMC. Last chance for people to oppose the destination. 7. If agreed goal is to try to build a new community, setup a dev list and move collaboration there. Everyone is welcome to come and take part. 8. If at some point the community decides it will be a TLP (this may have been at inception), a PPMC is established for governance. 9. At some point, there is sufficient stability in the project to graduate. If this is already determined to be to a TLP, then the normal resolution goes to the board. If the community decides there is another TLP they are best suited to, then they vote to go there as in step 6. If they don't agree, then they aren't ready :) I don't think this is drastically different to now, but having explicit steps with everyone having a chance to give feedback before aligning too much to one group might help. Feel free to pick holes in it :) - Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
