For committership, that is typical. Most PMCs allow a veto for adding new members to the PMC.
On Thu, Oct 3, 2013 at 10:48 AM, Joseph Schaefer <joe_schae...@yahoo.com> wrote: > 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 <aha...@adobe.com> wrote: > >> >> >> 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 >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
