Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 96719 invoked from network); 11 Dec 2005 12:19:25 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 11 Dec 2005 12:19:25 -0000 Received: (qmail 20425 invoked by uid 500); 11 Dec 2005 12:19:23 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 20401 invoked by uid 500); 11 Dec 2005 12:19:23 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 20390 invoked by uid 99); 11 Dec 2005 12:19:23 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 11 Dec 2005 04:19:23 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [195.188.213.7] (HELO smtp-out4.blueyonder.co.uk) (195.188.213.7) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 11 Dec 2005 04:19:22 -0800 Received: from knossos.elmet ([82.38.65.173]) by smtp-out4.blueyonder.co.uk with Microsoft SMTPSVC(5.0.2195.6713); Sun, 11 Dec 2005 12:19:56 +0000 Subject: Re: [all] Together, and bricks apart From: robert burrell donkin To: Jakarta Commons Developers List In-Reply-To: <31cc37360512021800t45f25037q441824059c962cc1@mail.gmail.com> References: <438E4FC9.80503@btopenworld.com> <55afdc850511301738n1d8d6dbay37133043e4fe95b1@mail.gmail.com> <16d6c6200511301929m21cd894bjc20f5f964681a422@mail.gmail.com> <8a81b4af0511302009i79c5b924p5554490c1adad87@mail.gmail.com> <438E9F61.1070607@ops.co.at> <8a81b4af0512020055x4ffea341p2b68f163b795e66@mail.gmail.com> <16d6c6200512021035y7844fe2i4682690d6c49b0de@mail.gmail.com> <31cc37360512021800t45f25037q441824059c962cc1@mail.gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-aKrCw4Q3fH66MtW5jBtF" Date: Sun, 11 Dec 2005 12:19:09 +0000 Message-Id: <1134303549.5187.127.camel@knossos.elmet> Mime-Version: 1.0 X-Mailer: Evolution 2.0.1-1mdk X-OriginalArrivalTime: 11 Dec 2005 12:19:56.0116 (UTC) FILETIME=[32623140:01C5FE4D] X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N --=-aKrCw4Q3fH66MtW5jBtF Content-Type: text/plain Content-Transfer-Encoding: quoted-printable (sorry for this being very late and out of sequence: blueyonder has been v poor all week) On Fri, 2005-12-02 at 21:00 -0500, Henri Yandell wrote:=20 > On 12/2/05, Martin Cooper wrote: >=20 > > IMO, what this tells us is the Commons isn't scaling, and that doesn't > > surprise me at all. In the "old days", there were a *lot* fewer compone= nts. > > Right now, I count 35 components in Proper and 9 more active components= in > > the Sandbox (excluding the ones Henri is about to make dormant). That i= s a > > lot of stuff! Very few people, if any, are going to keep tabs on all of= it, > > and most are likely to only track a handful, if that. > > > > When Commons was much smaller, the community was much more integrated, = in > > that there was more overlap between the pieces (people-wise, not code-w= ise), > > and so we all watched each others' backs. We're no longer in that state= . > > > > The inability to scale, is, in my opinion, an issue the ASF as a whole = is > > also facing. Unfortunately, as with Commons, I don't have any good idea= s. > > Other than to consciously stop growing, that is, but that doesn't appea= r to > > be a popular direction. >=20 > [long reply...sorry] >=20 > Yep. It's my belief that Commons represents the ASF in microcosm, +1 > So how can we rejuvenate a community without the mantra that we don't > have focus? >=20 > a) Work together. I don't mean that in a hippy peacenik way. I mean > actually work together. We need to get a plan for the future of each > component and then form groups attacking each target, but not at the > same time. >=20 > So Lang 2.2 might be held up because 3 of us need to work on > Collections 2.2. Etc. i think i understand what you're getting at but see it a little differently. IIRC when the commons experiment was first started, jakarta still used the old hierarchical organization with deep nesting and an elected pmc. the rules reflect this: commons was a microcosm of jakarta with each component being a mini-sub-project. the main difference being the experimental feature was allowed existing committers to self-nominate. this was very controversial at the time. 1 most of those who have been here a while now appreciate that this original design is wrong. the price of being part of the commons is that we are evaluated collectively: bad press, failure to respond to users or problems with oversight involving any component effects all.=20 2 the voting system here specified in the charter is at odds with way the ASF is now organized. the only votes which are binding upon the ASF are those cast by pmc'er and all pmc'ers should be entitled to vote.=20 so why do i think that changing the voting system is important? well, it isn't (by itself) but IMHO the vision in this part of the charter is now at odds with how most the old hands think the commons is best managed. at the every least, it's not an accurate description of the way that commons works now. the charter also permeates into the culture of new committers: it's just about the only documentation on committership that we have.=20 i would to see the current voting rules simply eliminated: replaced by the use of the ones for jakarta as a whole. AFAIK these are not stated anywhere concisely but are simple: only votes by pmc'er can be binding on the ASF. no official action can be approved without 3 +1's by pmc'ers. in the short term, this is going to increase the stress on our critical human infrastructure (and decrease the fun) but it will force the changes that will be needed to scale in the long term. we need to change the culture to break down the lines between components for important decisions. we'll probably also need to invest in more automation and documentation.=20 in the medium term, though, i think that fixing the commons will release energy. - robert --=-aKrCw4Q3fH66MtW5jBtF Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBDnBk91TNOdbExPeIRAiK3AKCOmNSREwEa59ETwFBiewmELkvv1wCdFnwy WhBnNsdjtfkY2V0aZjThKag= =Vw6O -----END PGP SIGNATURE----- --=-aKrCw4Q3fH66MtW5jBtF--