On 3/4/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote: > Yes we have many, many problems. > > Site > Is this really our top priority? Is maven 2 helping here? Is maven 1? I > have a distinct memory that commons was used as a practice ground pre > maven-1 to test maven's functionality in a real deployment. Are we about > to subject ourselves to this again? > Good point. Agree we want to keep this simple.
> Inactivity > Dormant has helped clarify the position. But are we willing to kick > [beanutils] and [dbcp] into dormant? Since all user requests and bugs > seem to have been ignored for many months, surely they are dormant? I > await the screams from the wider community... IMO this is our biggest problem and it has nothing to do with sites, list noise or how we are organized. Don't know how to solve it other than maybe trying a little collective prioritization. By that I mean that we maybe agree to focus together for a bit on the two that you mention above, for example. Don't know exactly how that might work, but its worth thinking about. > > CI > How does another thing to worry about help us. Why not focus on Gump? +1 - Gump works > > Commons as the solution > We're not. We're barely holding our head above water. Some better than others ;-) ... gulp, gasp... > > Leadership > Something Apache counsels against. Often however, the most successful > projects have a leader who drives the project forward and on occaisions > takes decisions. In commons we do have this, but only at the component > level. We feel unwilling, or are unable, or don't want, a cross commons > leader a lot of the time. > I don't know about that. We may have some differences of opinion, but usually when someone steps up with ideas to help make things better, we listen collectively. Like any apache project, we have to make decisions by consensus, but I hope no one feels like it is not possible to get anything done here. Put another way, the same "talk a little, do it and see if the community complains" attitude that allows us to move components along should work for the community stuff. The site build mess is a good example. It was painful a couple of years ago when we got the initial maven site working, but those who drove it (Mark, Tim and a few others) used JFDI and we all showed patience and respect for the doers. If what you mean is focussing efforts and developing action plans for all of commons, that is an interesting idea that I bet we could do the same way we do for the components. Maybe what you are suggesting below is that we are too "big" to do that for all of the commons and could be you are right, but I don't think we have ever really tried. The ComminsPeople Wiki page was a first step in that direction. Maybe now it is time to think about taking this a couple of steps further. > > My analysis is that its time for a bit more radical surgery. And I mean > splitting commons into smaller communities. Jakarta Xxx Components sets > the naming pattern. If we do this, then each new group will be small > enough to be able to take decisions by itself, for example on the site. > Do you really think the problem is taking decisions? I think our biggest challenge is growing and maintaining communities around all of the code and maintaining quality, consistency and responsiveness across all of the components. The only advantage to disaggregation for that is reduced list noise. But that also might reduces visibility / itch-generation. I also worry about fragmenting the relatively small active committer base and losing the economies of scale (common build and release process, for example - painful as it is to agree and make it work - saves time for all). Can you explain a little more what you see the other advantages of splitting things up to be? Thanks for bringing this stuff up. Phil --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
