incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joseph Schaefer <joe_schae...@yahoo.com>
Subject Re: Apache project bylaws
Date Thu, 03 Oct 2013 15:48:52 GMT
Good Lord man all you need to add is a one-sentence
statement that personnel votes are consensus votes not
procedural (simple majority) votes.

On Oct 3, 2013, at 11:40 AM, Alex Harui <aharui@adobe.com> wrote:

> 
> 
> On 10/3/13 6:23 AM, "Marvin Humphrey" <marvin@rectangular.com> wrote:
> 
>> On Thu, Oct 3, 2013 at 12:09 AM, Alex Harui <aharui@adobe.com> wrote:
>>> On 10/2/13 12:58 PM, "Marvin Humphrey" <marvin@rectangular.com> wrote:
>> 
>>>> Rather than a "rewrite", I suggest proposing small, incremental,
>>>> reversible
>>>> changes.  Governance is easy to mess up.
>>> 
>>> Well, "small, incremental" was hard to do given the significantly
>>> different information this document must now convey.
>> 
>> I appreciate the labor you've put in, but what we have here is akin to a
>> big patch on highly sensitive mission-critical code for which there are no
>> tests.  I hope we can find a less costly way to integrate your efforts.
> It is a big patch for sure, but I'm not sure I agree with equating it to
> code.  It is probably always going to be "just words" and I'm not sure you
> can create tests.  I think even laws don't have tests, they only have to
> survive the reviews of the approvers and are always subject to revision
> later.  But hopefully the reviewers will think through whether the things
> they thought were "right" about the old version are retained and whether
> the things that were "wrong" have been removed, and new content appears to
> be "right".
> 
>> 
>>> I tried to keep as
>>> much as possible yet incorporate feedback from Doug and Roy.
>> 
>> Even if it was "wrong", people have been quoting from that document,
>> referencing it and following its guidance for a long time.  I'm quite
>> irritated that something "wrong" has persisted for so long and has been
>> used
>> so many times as the basis for settling disputes.
>> 
>> My take is that if that fundamental a document is "wrong", something is
>> dreadfully "wrong" with how hard-won wisdom gets handed down at the ASF.
>> 
>> Let's step back for a moment and reassess what we're trying to accomplish.
>> We're starting with a voting document which is apparently "wrong" and
>> trying
>> to make it quasi-authoritative.  But when we're finished turd polishing,
>> there
>> will still be no boundaries demarcating where the authoritative stuff
>> begins
>> and ends.
>> 
>> We have this problem with the Incubator website, too.  It started off with
>> buckets of poorly-thought-through text scooped out of mailing lists and
>> dumped
>> into version control.  Years later, certain portions of it have been
>> carefully
>> wordsmithed or even negotiated under high heat; as a result, making a
>> minor
>> change has the potential to obliterate a great deal of other people's hard
>> work.  But from just looking at the surface, you can't tell what's
>> garbage and
>> what's crucial.
>> 
>> Personally, I'm not eager to spend a lot of cycles negotiating large
>> revisions
>> to highly-utilized governance documentation under such a flawed regime.
>> I'd
>> rather that we limit ourselves to small tweaks, or if we're going to go
>> all
>> out, draw up a set of default bylaws which will in the future be set off
>> from
>> other documentation and subject to review-then-commit by some governing
>> body
>> charged with oversight.
> Some good points in there.  I know you want to revise the incubator site
> and I wish you well on your efforts to do so because I agree it needs it.,
> However I just want to change this one document, and it shouldn't require
> the restructuring of a site, so I want to separate the two efforts,
> although maybe this effort will influence yours.
> 
> So how about this:  I will go all out and rewrite this one document so it
> will demarcate what is authoritative and what isn't.  And I will try to
> make it clear that the goal of the document is to define a set of default
> by-laws.  And I will retain the entirety of the old document for
> historical reference.  To do so, I will insert the rewrite at the
> beginning of the document after I get lazy consensus on the following text
> which will go at the very beginning.
> 
> 	This document is under revision.  The original can be found here
> 	(#link_to_original_further_down).  All decision based on the
> 	original document remain valid and the original document remains
>        valid until further notice.  The text color of the original
> 	document has been changed to (brown) to help delineate the
> 	boundaries of the original content.
> 
> All authoritative sections will be demarcated with:
> 
> 	--this section is authoritative--
> 
> And end with:
> 
> 	--end of authoritative section--
> 
> My understanding is that only the code-modification and release voting
> approval type is authoritative.  Please correct me if I'm wrong.
> 
> 
>> 
>>> Below is my
>>> proposed version, and below it is the svn diff in case that makes it
>>> easier to see what changed.  Most of the changes were made at the
>>> beginning.
>> 
>> The formatting of the diff is messed up because of line wrapping by your
>> email
>> client.  Please take the time to present such a costly-to-review patch in
>> a
>> way which accommodates your potential reviewers.  I suggest posting a
>> link to
>> a persistent paste created using <https://paste.apache.org>.
> And with the above disclaimer, instead of using paste.a.o, I propose to
> revise this document using CMS and/or SVN.  That way we can track changes,
> and I can use color and other HTML features to show changes, and you can
> use your favorite tools to see the patch as well, although the first
> commit will just look like a giant insert.  And yes, I will push these
> revisions live via commit-then-review since they are under disclaimer,
> although you can certainly convince me to just leave them on the stage.
> 
> But don't panic, I won't commit anything until I get 72-hour lazy
> consensus on the disclaimer.
> 
> -Alex
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message