On Wed, 12 Nov 2003, Greg Stein wrote:
> Take things like Hivemind, Jelly, and whatstheotherone. In the list that > Stephen posted recently, he labeled these as "should be TLPs." What the > *heck* are they doing way down in J-C if they are TLP material? How could > Hivemind grow to become a framework while sitting in Commons without > anybody really saying, "wow. that needs to move." Hivemind and Math are still in the sandbox, so now is the correct time for people to be saying 'wow. that needs to move.'. Jelly is in Commons 'proper', but has not yet released so now is also the right time for that. Hivemind are putting together a proposal to be an SLP [what is the term for this, S for Second] within Jakarta. > There is a "sandbox" which is labeled as some kind of playground for ASF > committers to monkey in. That is wrong. It is a part of the Jakarta Commons Charter that it is an incubation area. > *Anything* in the ASF CVS > repository is owned by the ASF and requires the *SAME* oversight as larger > projects like Tomcat, httpd, or Cocoon. Label the sandbox all you want as No argument here. Being watchful over legalities in the sandbox is an essential role of the J-Commons community. > "unofficial" or "being worked on until it 'graduates'" or whatever. The > simple fact is that the mechanism encourages single committers to go wild > under the banner of the ASF. It is less managed than Incubation and I agree that as Incubator matures the J-Commons-Sandbox needs to get more restrictive to be more negative towards larger concepts. I'm not sure Jelly or Math would have been developed elsewhere under such a concept, but maybe Hivemind would have been developed under the incubator rather than in sandbox. Effectively as Incubator matures, the sandbox will become more and more a back door. > The J-C development list is apparently so trafficked that individuals > cannot really keep up with it. I keep up happily with the parts I consider myself involved in. I've no interest in Jelly/Hivemind/some of the others and so filter them out then delete later. > To retain proper oversight, that must be > broken down and partitioned into manageable chunks. Quite doable. But the Agreed. Even knowing that every component on the J-C list has a PMC member is not enough to ensure that it has oversight. What if there is only one member paying attention to one component and that person is on vacation, or focusing attention elsewhere. Even if there were 4 out of 5 PMC'ers on the component, how do you ensure those 4 are paying attention to what the other 1 is doing. > PMC is still responsible, as a whole, for every chunk that is produced. No > matter how you might partition the *mailing lists*, that total amount of > traffic is still present. Then throw in all the other Jakarta traffic. > Then try to say that a group of a couple dozen people are directing *ALL* > of that effort. It just isn't believable. > > The problem is that it has to be beyond believable. We have to be able to > stand up in a court and say "the PMC told those committers to do that." > There can't be a question about it. "Someone on the PMC was aware of it and had the opportunity to veto it" is where I would currently say we are. Though the veto is after the action. > Putting "one member from each (sub-)sub-project onto the PMC" is getting > there, but that still feels like the individual, rather than the PMC, is > managing the project. It seems like a typical people problem. There are too many people for the shallow management structure that ASF like, there is also a small amount of energy for management in a structure like ASF. The only solution so far has been to remove people by creating more TLPs. Another solution would be to instill more bureacracy and internal reports inside Jakarta that filter upwards to be summarised to board. Effectively turning the newsletter into a charter-mandated report tree. > Is it just me? Maybe. But as a Director, I'm supposed to be able to review Only in that you're the one who has to have the complete oversight or trust in oversight. > All that said, I can also state that it could be fairly said some of the > other PMCs might not be providing enough information either. In fact, that > has been raised here, "well, yah, but are you getting reports from the > httpd docs group?" Otherwise stated as, "but they suck, so we can too!" :-) > My point is that I may be unfairly focused on Jakarta. But I get to do I agree that it needs the focus as the biggest blind-side to you. The biggest part of the 'reports from httpd docs group' question is really 'so show us how it's meant to be'. > of the projects under it. And J-C is one of those, and is arguably one the > *most* active projects within Jakarta, yet it almost has an extra "layer" > between it and the PMC -- it effectively has its own charter and rules and > other policies. There have been threats of a J-C "sub PMC" which have > (thankfully) been shot down. The bullets missed ;) PMC members who work in J-Commons are going to become a de-facto sub-committee I suspect. In the same way that 2 committers on Jakarta Turbine [random name] are effectively the sub-committee there. Hen
