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 Sun, 05 Jul 2015 04:30:11 GMT
As it has been established in the "Veto! Veto?" thread that with procedural
issues a bit more is required than the generic statements in the Code of
Conduct and other pages describing the Apache Way.
Especially if a project wants to deviate from the general rule of a simple
majority voting for specific aspects  - think off changing the direction or
goal of the project, or e.g. every registered contributor (iCLA filed) has
a vote with respect of onboarding new PMC Members - this must be
incorporated in the bylaws of a project.

And these deviation must be checked against what the ASF states as its core
values.

That individuals regard bylaws as evil, doesn't make it less necessary.
Those who are at the good end of the stick never find such a necessity.
Bylaws exist to decribe the elements of due process.

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 Sun, Jul 5, 2015 at 4:47 AM, Roman Shaposhnik <roman@shaposhnik.org>
wrote:

> On Sat, Jul 4, 2015 at 4:12 PM, Benson Margulies <bimargulies@gmail.com>
> wrote:
> > In fact, I told at least one podling that bylaws are a faint smell of
> > trouble -- if you have enough conflict to feel the need to write down
> > the rules, you might do better working out the reason for the conflict
> > than writing down the rules.
>
> Just as Benson I'm writing this as somebody who mentored a whole
> bunch of podlings: early per-project bylawas are a sure sign of trouble
> in my book. Its the same issue as the community that runs a vote for
> every little thing imaginable.
>
> Both tend to create minorities and really get in the way of true consensus
> long term.
>
> Thanks,
> Roman.
>

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