Return-Path: X-Original-To: apmail-community-dev-archive@minotaur.apache.org Delivered-To: apmail-community-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 8ED4F18249 for ; Mon, 6 Jul 2015 12:10:13 +0000 (UTC) Received: (qmail 13693 invoked by uid 500); 6 Jul 2015 12:10:08 -0000 Delivered-To: apmail-community-dev-archive@community.apache.org Received: (qmail 13404 invoked by uid 500); 6 Jul 2015 12:10:08 -0000 Mailing-List: contact dev-help@community.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@community.apache.org Delivered-To: mailing list dev@community.apache.org Received: (qmail 13393 invoked by uid 99); 6 Jul 2015 12:10:08 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Jul 2015 12:10:08 +0000 Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 8759C1A0335 for ; Mon, 6 Jul 2015 12:10:07 +0000 (UTC) Received: by wiclp1 with SMTP id lp1so19093320wic.0 for ; Mon, 06 Jul 2015 05:10:06 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.142.209 with SMTP id ry17mr15311623wjb.5.1436184606176; Mon, 06 Jul 2015 05:10:06 -0700 (PDT) Received: by 10.28.6.131 with HTTP; Mon, 6 Jul 2015 05:10:06 -0700 (PDT) In-Reply-To: References: <559A338D.4060300@apache.org> Date: Mon, 6 Jul 2015 14:10:06 +0200 Message-ID: Subject: Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....) From: jan i To: "dev@community.apache.org" Content-Type: multipart/alternative; boundary=089e0122ecb8487bde051a33c9a1 --089e0122ecb8487bde051a33c9a1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Monday, July 6, 2015, sebb wrote: > On 6 July 2015 at 10:24, jan i > wrote: > > On 6 July 2015 at 11:10, Pierre Smits > wrote: > > > >> Thank you, Branko. I feel (somewhat) sorry for you, when I read your > >> statement of being disgusted by the viewpoint of others on the matter.= I > >> hope you recover from it soon. > >> > > > > Having been (and still be) in a project that have strong bylaws, limiti= ng > > voting etc, > > I know what a PITA project bylaws can be. > > > > We fought for about 6 month to get the bylaws changed, to something the= re > > was > > total consensus about. The problem was that the bylaws could only be > changed > > with 2/3 +1 of all PMC, which is quite hard to reach when 1/2 of the PM= C > no > > longer > > are active. > > As I recall, the main problem was that the local project bylaws had > been badly drafted, and were not clear, so needed to be changed. the bylaws was very clear and understandable but drafted in a time where LABS was a active project. > > > > Bylaws can in some special cases help a project, but really should not = be > > necesary. If > > our bylaws and policies are unprecise we should do something centrally > and > > not remedy > > this problem in 200 projects. > > Indeed. Had the local project bylaws not existed, I suspect there > would have been no problem in the case to which Jan refers. Correct actually LABS is a good example of a project where the bylaws are not needed. rgds jan i > > > rgds > > jan I. > > > > > >> > >> Best regards, > >> > >> > >> Pierre Smits > >> > >> *ORRTIZ.COM * > >> Services & Solutions for Cloud- > >> Based Manufacturing, Professional > >> Services and Retail & Trade > >> http://www.orrtiz.com > >> > >> On Mon, Jul 6, 2015 at 10:51 AM, Branko =C4=8Cibej > wrote: > >> > >> > On 04.07.2015 18:34, Pierre Smits wrote: > >> > > Having done a cursory review of the incubator reports to the board > for > >> > > this year (January till May/June 2015), I found that only the SAMO= A > >> > > podling reported working on a project set of bylaws, which without > >> > > knowing details could encompass and/or incorporate the code of > conduct. > >> > > >> > I find myself disgusted by this widespread assumption that each > project > >> > needs its own bylaws. WTF for? Are not ASF policies and practices > enough > >> > for everyone? What sort of bylaws could you possibly invent that are > >> > both a useful extension of these policies and practices /and/ are no= t > >> > applicable to other projects? > >> > > >> > Per-project bylaws are just a tool for fragmenting the ASF community= , > in > >> > other words, they're a bad idea; paper-shuffling at its most useless= . > >> > > >> > -- Brane > >> > > >> > --=20 Sent from My iPad, sorry for any misspellings. --089e0122ecb8487bde051a33c9a1--