Return-Path: Mailing-List: contact community-help@apache.org; run by ezmlm Delivered-To: mailing list community@apache.org Received: (qmail 32116 invoked from network); 9 Nov 2002 00:02:40 -0000 Received: from icarus.apache.org (63.251.56.143) by daedalus.apache.org with SMTP; 9 Nov 2002 00:02:40 -0000 Received: (qmail 56386 invoked by uid 1059); 9 Nov 2002 00:02:39 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 9 Nov 2002 00:02:39 -0000 Date: Fri, 8 Nov 2002 16:02:39 -0800 (PST) From: "Craig R. McClanahan" To: community@apache.org Subject: Re: Rules for Revolutionaries In-Reply-To: <3DCC4D57.5090807@apache.org> Message-ID: <20021108155454.X52613-100000@icarus.apache.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: localhost 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Fri, 8 Nov 2002, Stefano Mazzocchi wrote: > Date: Fri, 08 Nov 2002 23:48:39 +0000 > From: Stefano Mazzocchi > Reply-To: community@apache.org > To: community@apache.org > Subject: Re: Rules for Revolutionaries > > Costin Manolache wrote: > > In my personal opinion they are just redundant :-) > > > > The rule that matter is that the community control the code and the name > > - a majority vote in the community can decide ultimately what happens. > > Agreed. At the same time, I would love to see something written down > about 'how the ASF guidelines are'. They might not be binding, just > recommendations, but I think this will help a lot communities becaue > these guidelines are distilled after years of try/fail cycles (and lot > of pain!) > A slightly more formal way to do this would be to explicitly canonicalize "Apache Way" policies like this at the apache.org level, and these automatically become the default policies for any Apache project unless that project deliberately (perhaps within some limits TBD) chooses to operate differently. The requirement for following these (or specializing them) would be an explicit part of a new project's charter. Essentially, this would be a generlization of the way Jakarta projects deal with coding style conventions -- there's a default (from the original Sun coding standards) that is the assumed standard unless a different choice is explicitly made and documented for a particular subproject. The same principle can be applied recursively -- instead of subclasses formally inheriting methods and instance variables (with the option to override), projects and subprojects formally inherit culture and standards unless they explicitly choose to override :-). I'd bet many people perceive that Apache actually works this way; let's just make that perception into reality. Craig