[dropping all the cross posts, keeping it on community] On Mon, 2004-01-12 at 20:19, Andrew C. Oliver wrote:
> Solution: > > * Disband the incubator. ... > * A project must have at least sponsoring MEMBER willing to go join the > project and help them adopt the voting rules, document legal issues by > performing an audit This will be even more of a bottleneck. There aren't that many members who are willing or able (time wise) to perform an audit. Or even to join another project. In the incubator, the project itself and one or more 'mentors' keep track of the project status in a status file. This lists the points that need to be in order, with a completion date. > * A project's acceptance is governed by a PMC accepting it There are examples of why this doesn't work. > or the members voting to create a TLP. Currently the board takes care of this. What's wrong with that? > This should be ratified by the board who should > have veto power. After a fullblown membership vote? > * To propose the vote a project must prove that all CLAs are turned in and a > license audit has been performed under the supervision of the said > sponsoring member/members. Sounds like the paperwork that is now required to be done and documented during incubation. > * prior to the project's acceptance into Apache it has no Apache status > (legal/otherwise). I suppose we could give it a candidate logo. Right now, projects are indeed hosted under incubator.apache.org. They will probably get a 'incubating' logo (if/when someone produces it) while there. Currently it has to be noted on their webpage. > This: > > * Protects the foundation As does the incubator. > * Makes the responsible people responsible and less "help" from the peanut > gallery. > * Makes members responsible. The members that have the interest, and some the time, are already trying to help out in the incubator. There are never enough though. > * Gives the "acceptance" to the project and the people accepting it. No > more tricameral votes. > > Issues: > > What about how things were before?? The incubator sought to solve what was > essentially a communication issue via more process. I suspect it was also > created (I read this in emails by some of its proponents and Sam replied > "that¹s not what I voted for as a board member" or something to that effect) > originally as a flood gate to slow or prevent the growth of Apache. I think > the communication issue (about oversight) has been solved. In fact I rather > thing we've gone a little too far in the other direction. Some projects are > just lazy and haven't done their auditing. Other projects are more > vigilant. I think this is normal. What could be done about it I don't know > for sure but the incubator doesn't further that, maybe the PMCization thing > did, but I think moving the responsibility down the latter will do more, > then some manner of accountability (dirty word I know in a volunteer > organization). Have you reviewed the incubation process lately? It is a lot closer to what you propose than you might think. > The incubator was also supposed to help projects obtain their base > resources. What is really needed here is a request tracker for the > infrastructure project (which should become more of a project and less of > well what it is but that is a rant for another day). The incubator merely helps the projects obtain their base resources. What the infrastructure team could do to optimize their own process is beyond this discussion. Sander --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
