Thank you Peter. I now think that I fully understand your issue with the current system.
Scott > -----Original Message----- > From: Peter Donald [mailto:[EMAIL PROTECTED]] > Sent: Friday, February 01, 2002 3:04 PM > To: Jakarta Commons Developers List > Subject: Re: Who Commits to What > > > On Thu, 31 Jan 2002 23:37, Ted Husted wrote: > > Peter Donald wrote: > > > If you want for Avalon to move all its components across > then there > > > is one thing that needs to be changed. Same thing as it was when > > > Commons was incepted, same thing I have been saying for ages. If > > > working with Avalon is not desired then nothing needs to > be changed. > > > > Perhaps you've answered this before, and I've missed it, but how is > > commit and voting rights different in the Commons than on any large > > Jakarta subproject? > > The number of committers, the level of interaction between > committers and the > ease of becoming a committer. > > Commons has a larger number of committers - the rate at which > new committers > are added is only going to increase as it grows. Lets assume > theres 25 > committers now - I would not be surprised to see that this > increased to 50 > within a year. So commons promotes quantity of committers. > > Committers don't have the requirement to interact with other commons > committers. It is a simple manner to get voted in when 90% of > the commons > group does not know the committer it doesn't matter. So > interaction is not an > important aspect of being a commons committer. > > Committers also have a very easy way to get in - all they > need to do is > submit a componet and voila! They are in. > > Compare this to any other project - large or not. I have no > idea on the > largest project (maybe TC?) so lets imagine it is TC. Even > including all the > current active committers in TC I suspect it would be far > less than Commons? > I suspect they all at least are aware of each other - even if > they are > segmented into TC3 vs TC4 (is that still true?). And I > suspect TC also > demands that the developers show a higher level of commitment > before being > nominated as committers. > > > When the code is donated to a subproject, all Committers to the > > subproject have equal responsiblity for its maintenance and > continued > > deveopment. > > Now thats an interesting perspective. The ecletic mix of > components and dev > styles is unlikely to engender central control > > > If it might fall to me to support something, then I should > have a say > > over what I may need to support. Unilateral vetos only apply to > > product changes, and must be justifiable. You can't veto a > release, or > > a plan, only real code or real documentation. A real veto > must provide > > real alternatives or present real technical problems, or it is not > > justifiable. If you don't believe me, ask Brian or Roy. > > It is easy enough to jig the system and come up with a "real" > reason to veto > something > > > AFAIK, there is no precedent for saying a Committer to > subproject can > > vote on this or that, but not on something else. Either the > Commons is > > a subproject or it isn't. > > Go read the jakarta docs again ;) It basically saids it is > decision to be > made by the subproject. > > > If we are going to change the voting rights in the Commons, then we > > should bite the bullet and propose it as a top-level ASF Project, > > why? > > > and > > perhaps ask the XML Commons to join us. The Commons could then have > > its own PMC, and parcel out the commit and voting rights any way it > > saw fit. > > Why not just sourceforge management scripts because that > would mean even less > work for this new PMC. > > -- > Cheers, > > Pete > > --------------------------------------------------- > "Marriage, Friends, Religon -- these are the demons > you must slay in order to suceed in business.." > -- Mr. Burns, The Simpsons > --------------------------------------------------- > > -- > To unsubscribe, e-mail: > <mailto:commons-dev-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
