On 2/3/02 7:56 PM, "Paulo Gaspar" <[EMAIL PROTECTED]> wrote:
> Answer inline: > >> -----Original Message----- >> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] >> Sent: Sunday, February 03, 2002 11:11 PM >> >> On 2/3/02 4:21 PM, "Paulo Gaspar" <[EMAIL PROTECTED]> wrote: >> >>> Amazing work on HYPOTHETICAL situations. >> >> Well, it's a valid question given the governance model we are proposing. Still don't want to address that one, eh? >> >>> >>> To simplify again, I do not agree with the negation of that statement >>> either. Maybe the most balanced situation is the one we already have >>> ...until it is proved to be bad. >>> >>> Still learning here. >>> >>> I am only sure that I am not so sure that the rules of the game >>> should change. >>> =;o) >> >> Except we keep ignoring that we *did* change the rules if you grant me the >> model of Commons as a 'mini-Jakarta' : > > I do not think the Commons are a mini-Jakarta. > > >> - where the components map to the projects. >> - and the original 'three person committee' (that we never needed) was the >> PMC >> - the committer community is the individual component committers >> as a group >> >> If we kept the same model, we would have Commons as a 'organizing place' >> where we can bring bits of existing code and productize them, bring in new >> bits of code that we need, provide the sandbox for exploration and >> experimentation, and build a community of people interested in these kinds >> of things. > > The commons as an organizing place makes sense INSIDE Jakarta. Which is what it is. I never advocated anything different. > > >> However, in each case (except the sandbox), a component would >> have a defined >> set of committers that would be responsible for the direction and >> status of >> their component, and keep adding new committers and contributions and >> interest dictated. >> >> In our case, we did alter the model. It's sounds great - one for all and >> all for one - but I don't see that working out in practice. I am *not* >> suggesting it is a failure - we are still small enough that it has worked >> out well so far, but peter showed us one problem, and I expect that w/o >> addressing it, we are going to have to deal with it and like >> issues more and more often. > > I was seeing the problem longer ago from Peter's earlier remarks. He > did not have to throw that -1 to have my attention. > > However, the model that Costin finally made me understand might really > make sense. Maybe less rules really gives room to more creativity. > Maybe things really work out better as Costin says. He made me believe > so and I do not think I am able to explain it better than he did - and > I am not going to try, but you can go back and read it again if it > interests you. I certainly will. Costin has a lot of great insights. > > And, again, CVS allows us to rollback things if something goes wrong. Care to take that to the logical conclusion? PROPOSAL : Grant CVS read/write to anyone subscribed to the mail list. Make it automatic upon subscription to save root@ the time for configuration and the community time for voting. After all, any list subscriber is a community participant at that point. I'll start the voting with an confident -1 No thanks. > > Now, you are afraid that we are getting to big and that it will not > work so well in the future because of that. No - I think Jakarta is getting too big. But that's for another list. My problem with governance of commons is different. Very specific, and different. I hope commons grows to *hundreds* of well crafted, well documented, well supported components. >I think that you might be > right, but I also think that: > - It is still working well now as it is; > - We can fix it if/when the current rules don't cut it. My worry is that it will either be too hard to fix, or it will be too broken that we lost the chance to keep what great community spirit we have. Lets face the fact that the Apache model works. We are taking a risk with the commons model. I don't mind risks when I see an upside, which I don't now. > With software projects and organizations, a low level of bureaucracy > works better for the smaller ones and a higher level works better for > the larger ones. Nah. I don't buy it. I believe that smaller organizations always are more innovative, work faster and better, and produce more per contributor. It's like the old joke that the productivity of any meeting is inversely proportional the number of attendees. By specifically recognizing the contributors of each component through the designation of 'committer' that is determined by their peers ( rather than their ability to use vi, emacs, visualstudio, idea, jbuilder or edlin on the STATUS.html file), and giving them the right to choose what happens to their work-product, I believe that you get all the advantages of small, tight teams as well as the pride of having your contributions, no matter what they are, recognized by people who really are interested in the same subject. Don't get me wrong - so far, I think we have been very fortunate. I think all of the commons committers are great, committed people, and I wouldn't change any of the contents of the STATUS files (except for Peter in logging :) However, I see storm clouds on the horizon. > So, while we are small enough, less is more - lets keep the bureaucracy > lower until we really get too big. So on that basis, do you support the above proposal? > >> geir > > Have fun, > Paulo I used to, geir > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Be a giant. Take giant steps. Do giant things... -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
