On 10/3/13 6:23 AM, "Marvin Humphrey" <mar...@rectangular.com> wrote:
>On Thu, Oct 3, 2013 at 12:09 AM, Alex Harui <aha...@adobe.com> wrote:
>> On 10/2/13 12:58 PM, "Marvin Humphrey" <mar...@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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
