community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre Smits <pierre.sm...@gmail.com>
Subject Re: Incubating, Graduating & Code of conduct @ The ASF (spin-off of Better specifying....)
Date Mon, 06 Jul 2015 09:38:58 GMT
The latest posting by Jan proves the point of the necessity of good
per-project bylaws when it comes to deviating from the generic guidelines
of the ASF.

Bylaws define the parameters of how processes are be executed within a
project, when it comes to the procedural aspects. His example given,
regarding the lifetime employment of PMC members shows that a definitive
description of how onboarding and ofboarding of PMC Members takes place in
the project could have saved it a lot of time and trouble.

The incubation process is the right place to thing about these aspects as
mentors of can could provide the insights and experience in order to avoid
creating either bylaw elements that are either to vague to apply or to
complex to uphold that will lead to (unnecessary and avoidable) heated
discussions that hurt the project more than they do good.

Best regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Mon, Jul 6, 2015 at 12:24 PM, jan i <jani@apache.org> wrote:

> On 6 July 2015 at 11:10, Pierre Smits <pierre.smits@gmail.com> 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, limiting
> voting etc,
> I know what a PITA project bylaws can be.
>
> We fought for about 6 month to get the bylaws changed, to something there
> 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 PMC no
> longer
> are active.
>
> 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.
>
> rgds
> jan I.
>
>
> >
> > Best regards,
> >
> >
> > Pierre Smits
> >
> > *ORRTIZ.COM <http://www.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 ─îibej <brane@apache.org> 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 SAMOA
> > > > 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 not
> > > 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
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message