Reviving this thread. I've invited others to join in as well.
As a reminder, the proposed changes are here:
http://mail-archives.apache.org/mod_mbox/incubator-general/201310.mbox/%3cC
e743d6a.14a96%25aha...@adobe.com%3e
And my goal is not just to fix up the voting doc, but to try to define a
def
Really, Greg? Can't you tell you're not using the same
language I am, but I'm using the actual documentation?
Please see
http://www.apache.org/foundation/glossary#ConsensusApproval
and see how it jives with what you are saying. Personnel
votes are always subject to veto, even committership, when
On Oct 3, 2013 12:52 PM, "Joseph Schaefer" wrote:
>...
> e.g. how to vote properly
> on personnel issues, and that should entirely suffice. Even Greg
> doesn't seem to know what consensus voting means in this context,
Really, Joe? Why did you throw that in? I know what consensus voting is. I
also
On Fri, Oct 4, 2013 at 9:55 AM, Alex Harui wrote:
> Who is permitted to vote is, to some extent, a community-specific thing.
> However, the basic rule is that only PMC members have binding votes, and
> all others are either discouraged from voting (to keep the noise down) or
> else have their vote
IMO none of the new glossary entries are worth doing.
Procedural votes are votes about bylaws and other rules
which you will apply to self-govern, so they deserve
an appropriate treatment. "Discouraged from voting" is
perhaps too harsh a sentiment, what we want those people to
know is their opinion
OK, here is my next offering. The patch form is at [1]
Some notes:
-This offering has 3 new entries to glossary.html as well.
-I was very tempted to move the Veto sections from Voting.html to Glossary
and merge the Consensus Gauging through Silence section from Voting into
Glossary.
-I am also t
On 10/3/13 9:51 AM, "Joseph Schaefer" wrote:
>The definitions are in a glossary somewhere, the more
>we denormalize the locations of our common understandings
>the harder it will be to maintain sanity over discussions.
OK, found the glossary. I will try to leverage it more in the next
revision
On 10/3/13 8:48 AM, "Joseph Schaefer" 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.
Hmm. Maybe I'm reaching too far, but my hope was to put in this document a
definition of consensus and a
The definitions are in a glossary somewhere, the more
we denormalize the locations of our common understandings
the harder it will be to maintain sanity over discussions.
Projects don't need to be encouraged to write their own
bylaws, most don't bother and that's proper. We don't need
to spell ev
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 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
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 wrote:
>
>
> On 10/3/13 6:23 AM, "Marvin Humphrey" wrote:
>
>> On Thu, Oct 3, 2013 at 12:09 AM, Alex Harui w
On 10/3/13 6:23 AM, "Marvin Humphrey" wrote:
>On Thu, Oct 3, 2013 at 12:09 AM, Alex Harui wrote:
>> On 10/2/13 12:58 PM, "Marvin Humphrey" wrote:
>
>>> Rather than a "rewrite", I suggest proposing small, incremental,
>>>reversible
>>> changes. Governance is easy to mess up.
>>
>> Well, "smal
On Thu, Oct 3, 2013 at 12:09 AM, Alex Harui wrote:
> On 10/2/13 12:58 PM, "Marvin Humphrey" 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
> di
On 10/2/13 12:58 PM, "Marvin Humphrey" wrote:
>On Wed, Oct 2, 2013 at 11:35 AM, Alex Harui wrote:
>> I would like to propose a rewrite of [1] by borrowing heavily from [2]
>>but
>> making sure to emphasize that projects are allowed to have different
>>rules
>> for all of them (or is the code-c
On Wed, Oct 2, 2013 at 3:30 PM, sebb wrote:
>> That's a really interesting perspective: governance rules as code, that can
>> be unit tested. Heh I like that.
>
> And how does one test that code is working correctly?
http://en.wikipedia.org/wiki/Cyc
30 years and going strong!
Thanks,
Roman.
P.
On 2 October 2013 21:34, Alex Karasulu wrote:
> On Wed, Oct 2, 2013 at 11:58 PM, Marvin Humphrey
> wrote:
>
>> On Wed, Oct 2, 2013 at 11:35 AM, Alex Harui wrote:
>> > I would like to propose a rewrite of [1] by borrowing heavily from [2]
>> but
>> > making sure to emphasize that projects are all
On Wed, Oct 2, 2013 at 11:58 PM, Marvin Humphrey wrote:
> On Wed, Oct 2, 2013 at 11:35 AM, Alex Harui wrote:
> > I would like to propose a rewrite of [1] by borrowing heavily from [2]
> but
> > making sure to emphasize that projects are allowed to have different
> rules
> > for all of them (or is
On Wed, Oct 2, 2013 at 11:35 AM, Alex Harui wrote:
> I would like to propose a rewrite of [1] by borrowing heavily from [2] but
> making sure to emphasize that projects are allowed to have different rules
> for all of them (or is the code-commit veto required for all projects).
> Any objections to
On Wed, Oct 2, 2013 at 11:11 AM, Roy T. Fielding wrote:
> It isn't out of date. It is just plain wrong. It does not reflect any
> of our projects, but rather presents an incomplete summary based on
> someone's personal experience. It is difficult to do better than that
> without having a univer
On 10/2/13 11:11 AM, "Roy T. Fielding" wrote:
>On Oct 2, 2013, at 10:20 AM, Alex Harui wrote:
>> On 10/2/13 10:09 AM, "Doug Cutting" wrote:
>>
>>>In my tour of the internet since my last post and your reply, it does
>> appear that most Apache-related information indicates that committer
>> vo
On Oct 2, 2013, at 10:20 AM, Alex Harui wrote:
> On 10/2/13 10:09 AM, "Doug Cutting" wrote:
>
>> On Wed, Oct 2, 2013 at 9:49 AM, Alex Harui wrote:
>>> To me, agreeing on "the norm" is not the same as policy, especially
>>> policy
>>> that does not allow for exceptions.
>>
>> I agree. Establish
On Wed, Oct 2, 2013 at 10:20 AM, Alex Harui wrote:
> I'm not sure I understand the
> difference between "consensus" and "unanimous consensus". Your thoughts?
The difference seems to be the quorum requirement of 3 +1 votes in the
case of "consensus" but not in "unanimous consensus".
They use "un
On 10/2/13 10:09 AM, "Doug Cutting" wrote:
>On Wed, Oct 2, 2013 at 9:49 AM, Alex Harui wrote:
>> To me, agreeing on "the norm" is not the same as policy, especially
>>policy
>> that does not allow for exceptions.
>
>I agree. Establishing whether there is a norm is a useful first step.
> That'
On Wed, Oct 2, 2013 at 9:49 AM, Alex Harui wrote:
> To me, agreeing on "the norm" is not the same as policy, especially policy
> that does not allow for exceptions.
I agree. Establishing whether there is a norm is a useful first step.
That's what I'm trying to take. Thus far I've seen noone di
Hi Doug,
Sorry to be so picky, but my ultimate goal here is to save time for my
project and all future graduating projects by avoiding as much thrashing
on this kind of issue as possible.
To me, agreeing on "the norm" is not the same as policy, especially policy
that does not allow for exceptions
On Tue, Oct 1, 2013 at 11:13 PM, Alex Harui wrote:
> The thread on members@ was titled "Committer Qualifications". I asked a
> question about the -1 vote on 9/7/13 and the reply I got was that
> committer voting does not have vetoes, and the document at [1] also seems
> to say that.
I followed u
(Apologies if you get this twice. I'm having email issues)
Doug,
The thread on members@ was titled "Committer Qualifications". I asked a
question about the -1 vote on 9/7/13 and the reply I got was that
committer voting does not have vetoes, and the document at [1] also seems
to say that.
The d
Lots of people on this list are also on members@, and, so far, none have
objected to my statements. If this continues, it would indicate a lack of
controversy.
Doug
On Oct 1, 2013 7:36 PM, "Justin Mclean" wrote:
> Hi,
>
> > I don't find the discussion on members@ that comes to this conclusion.
>
Hi,
> I don't find the discussion on members@ that comes to this conclusion. If
> you cannot see members@ how do you know this?
I was informed by a member on Flex private and here [1] which you already
responded to.
Thanks,
Justin
1. http://markmail.org/thread/chfagblj72cv7zrt
-
I don't find the discussion on members@ that comes to this conclusion. If
you cannot see members@ how do you know this?
Doug
On Oct 1, 2013 6:06 PM, "Justin Mclean" wrote:
> Hi,
>
> > I see no discrepancy between the documents you cite. The first says
> > that committer votes are by consensus,
Hi,
> I see no discrepancy between the documents you cite. The first says
> that committer votes are by consensus, the second says that
> "procedural" votes are by majority, but doesn't define procedural and
> there's no implication that it includes committer votes.
There was conversation on mem
On Tue, Oct 1, 2013 at 3:34 PM, Justin Mclean wrote:
> The whole reason this come about is because it's unclear what voting rules
> are the default when voting someone in as committer. See [1] (consensus) and
> [2] (majority). If -1 is a veto or not is sort of important thing to know,
> and wh
Martijn Dashorst wrote:
> On Tue, Oct 1, 2013 at 5:28 PM, Ross Gardler
> wrote:
> >
> > +1 to Marvin's "I hope that most projects won't bother" although there
> > needs to be something a little more than a blank piece of paper.
> >
> > The best approach, IMHO, is to simply make it official that t
Hi,
Thanks for the feedback, it's interesting to see that some project don't have
bylaws.
The whole reason this come about is because it's unclear what voting rules are
the default when voting someone in as committer. See [1] (consensus) and [2]
(majority). If -1 is a veto or not is sort of i
On Tue, Oct 1, 2013 at 8:59 AM, Martijn Dashorst
wrote:
> At Wicket we didn't bother to pick bylaws and from what I have seen in
> other communities we are better for it.
A huge +1 to that! Apache Bigtop falls into the very same category -- we'll
get real bylaws when we really need them (hopefull
On Tue, Oct 1, 2013 at 5:28 PM, Ross Gardler wrote:
> +1 to Marvin's "I hope that most projects won't bother" although there
> needs to be something a little more than a blank piece of paper.
>
> The best approach, IMHO, is to simply make it official that the project
> adopts the same byelaws as p
+1 to Marvin's "I hope that most projects won't bother" although there
needs to be something a little more than a blank piece of paper.
The best approach, IMHO, is to simply make it official that the project
adopts the same byelaws as project x, y or z. Pick an established project
that has a minim
On Tue, Oct 1, 2013 at 7:50 AM, Jordan Zimmerman
wrote:
> Wow. I missed that. I'll work omit for Curator. I'd like to see the grad doc
> updated to mention this.
I hope that most projects won't bother. We need rules because we need a
framework to resolve disagreements, but bylaws are really hard
Wow. I missed that. I'll work omit for Curator. I'd like to see the grad doc
updated to mention this.
Jordan Zimmerman
> On Sep 30, 2013, at 9:21 PM, Justin Mclean wrote:
>
> Hi,
>
>> I reckon that this is one of the initial steps of becoming a
>> top-level project (TLP)
Hi,
> I reckon that this is one of the initial steps of becoming a
> top-level project (TLP). See the board resolution that created
> your TLP: "hereby is tasked with the creation of a set of bylaws to ..."
Thanks for clearing that up. Yes it was mentioned in the resolution, we should
get to it
Justin Mclean wrote:
> Hi,
>
> Looks like one of the things that fell between the cracks when Apache Flex
> become a top level project was drafting up and accepting a set of bylaws.
>
> I see nothing about bylaws on the incubator website, including here [1] where
> I would expect it to be.
>
>
Hi,
Looks like one of the things that fell between the cracks when Apache Flex
become a top level project was drafting up and accepting a set of bylaws.
I see nothing about bylaws on the incubator website, including here [1] where I
would expect it to be.
Should the process on this page be upd
42 matches
Mail list logo
