I agree that we should all get to voice our ideas, but using a voting system wouldn't work. I agree with a "moderated" approach where core members do oversee the final decision, but they should also listen to the community. Otherwise they will just push them away and the protocol will die off. Like Eran has said none of the authors have used the meritocracy hammer, but eventually someone needs to make the final choice. Hopefully we can come to a common ground in our discussions and the core authors won't need to take action.
On Fri, May 1, 2009 at 4:24 PM, Krishna Sankar (ksankar) <ksan...@cisco.com>wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
