FWIW, if we're still tallying votes, I vote for option 1. On Fri, May 1, 2009 at 2:34 PM, Eran Hammer-Lahav <e...@hueniverse.com>wrote:
> > That was not what I did. I was just explaining how this process works and I > clearly stated the need (and the full historical record) of getting to > decisions by consensus. This is for cases where everything else has failed. > We never had such a case so far and I doubt this will be one of them. If I > thought me or anyone else had more weight here I would not be spending my > entire day trying to convince people I'm right and engaging them. > > However, since this is a security issue with deployed software, if we > cannot reach a consensus, someone will have to make a decision. My bet is we > will not need it but if we do, that "someone" will be heavily weighted on > the side of those with running code at risk... But let's go back to the > discussion. I think we are making progress in communicating our positions. > > Let me repeat that: we make decisions by consensus, not votes. This is the > IETF process as well. > > EHL > > > -----Original Message----- > > From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf > > Of Krishna Sankar (ksankar) > > Sent: Friday, May 01, 2009 2:24 PM > > To: oauth@googlegroups.com > > Subject: [oauth] Re: Version Preference > > > > > > Eran, > > While you might be technically right, wielding the meritocracy > > badge forcefully is not the right thing to do, imho. > > > > While the folks who have contributed to the specs, obviously, > > have the knowledge and so their voices have more force per se (and > > should be respected - no doubt), the community that uses the spec has > > a > > voice too. And one doesn't have to be a permanent contributor to be > > heard and considered. There is a reason for this, if you care to think > > ... am leaving out philosophy, for now ... > > > > Also as we move to IETF, this will be more clear - I see that > > there are couple of e-mail on this, already in the IETF list, alluding > > to this fact. Even there, for now, it is OK, as the spec is not with > > IETF yet. > > Cheers > > <k/> > > > > |-----Original Message----- > > |From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf > > |Of Eran Hammer-Lahav > > |Sent: Friday, May 01, 2009 2:07 PM > > |To: oauth@googlegroups.com > > |Subject: [oauth] Re: Version Preference > > | > > | > > |On voting: this is not a democracy. Specs written by committee are > > |almost always a piece of shit. Our process is to build consensus as > > much > > |as possible, trying to get people to agree and when we don't try to > > |focus the conversation using actual technical arguments. At the end, > > if > > |there isn't a clear consensus, at least in this community, meritocracy > > |wins. This means that people who have contributed more and have > > "earned" > > |their seat at the table get to lead the way. But this is an extreme > > case > > |and I don't think we ever had to use it. > > | > > |The vote is just to get a sense where people are. It is not a way to > > |make decisions. At some point, Blaine or someone else will try to > > figure > > |out where people are, and write a short consensus proposal. Then we > > will > > |go through this again and see where we are. This sounds complicated > > but > > |it works pretty well. There are no hard rules for building consensus, > > |but we have been successful accomplishing it. > > | > > |--- > > | > > |As for your argument, I agree with you on the version of the > > |specification. I don't agree with you on the wire version. I don't > > think > > |they are the same at all. > > | > > |EHL > > | > > | > > | > > |> -----Original Message----- > > |> From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On > > Behalf > > |> Of Matt Sanford > > |> Sent: Friday, May 01, 2009 1:57 PM > > |> To: oauth@googlegroups.com > > |> Subject: [oauth] Re: Version Preference > > |> > > |> > > |> Well ... > > |> > > |> The argument from me was that there is a material change and > > that > > |> is the place of minor revisions. If this is an optional extension to > > |> the existing protocol we should not change the revision at all. If > > it > > |> is a minor change that requires a change to the base protocol rather > > |> than an extension document, I call that a revision. This seem > > logical > > |> enough to me but apparently I am in the minority, 1.0a it is then. > > |> As far as voting and discussion ... I was under the impression > > |that > > |> the 'Open' moniker sort of encouraged this. Must have been my > > |> confusion, I missed the early on discussions. I'll read back in the > > |> group some for more history. > > |> > > |> - Matt > > |> > > |> On May 1, 2009, at 1:44 PM, Jonathan Sergent wrote: > > |> > > |> > Let me additionally say that this discussion is dangerous and > > voting > > |> > is no way to design a protocol. What are the arguments in favor > > of > > |> > changing the version number, and what are the arguments against > > |> > changing it? I haven't personally seen any arguments in favor of > > |> > changing it that explained the rationale other than "of course you > > |> > should change it because you changed the version number on the > > |spec". > > |> > > > |> > > > > |> > > |> > > |> > > | > > | > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
