[sakai2-tcc] Override Votes

Mon Nov 15 18:11:07 PST 2010

Hybrid inclusion in 2.8 was a regular vote initiated at the request of Lance Speelmon.  See

http://sakai-project-mail-list-archives.1343168.n2.nabble.com/sakai2-tcc-VOTE-on-inclusion-of-S3-Nakamura-Hybrid-work-in-2-8-td5580060.html

So only three override votes but they have been interspersed between regular voting on 2.8 capabilities so conflation of the two types is quite easy.

Anth

On Nov 15, 2010, at 8:53 PM, Aaron Zeckoski wrote:

> Didn't we have at least one other override vote (for including hybrid
> in sakai 2.8) or am I remembering wrong? (or was that simply -1
> voted?)
> I had it in my head that we had more of these.
> 
> Also, what you say might be true but from my perspective there was not
> enough effort in any of the cases to find a way to resolve it without
> an overriding vote being called. Just my opinion and perspective of
> course. Maybe there is some communication happening off list which I
> am not seeing or something. Or perhaps the timetables are too
> compressed so there is not enough time for people to properly go
> through some cycles or perhaps something else.
> 
> -AZ
> 
> On Mon, Nov 15, 2010 at 7:45 PM, Anthony Whyte <arwhyte at umich.edu> wrote:
>> We have had three override votes to date:
>> 
>> Captcha support
>> Notification preferences
>> Retention of hybrid patches to login and providers
>> 
>> In each case supra-majorities were easily obtained in order to sustain the override so we are not talking here of deeply controversial issues for which the TCC could not find general agreement.
>> 
>> Adding captcha support was initially opposed by a single TCC member.  Notification preferences initially received a couple -1 votes as did retention of the hybrid patches to login and providers.  Attempts were initiated to answer the objections in an effort to achieve consensus.  Overrides were then initiated, and in my case at least as an initiator, only after weighing carefully whether or not a 2/3 super majority could be obtained.  I for one, have no wish to waste time on frivolous voting.
>> 
>> Perhaps, as John writes, an override vote represents a failure of the group and is indicative of a dysfunctional meritocracy.  I don't see it that way (yet).  Rather I see us emerging out of a long period in the history of Sakai where folks complained regularly that no one appeared willing to make decisions (at least publicly) or to do so in a manner considered timely.  Now we find ourselves making decisions and doing so with a certain dispatch.  I suppose it's all a bit disruptive but contrary to what some have written I see it on balance as a good thing.  The decisions may prove right, they may prove wrong but at least we are now beyond the point of wondering who decides what, when and how.
>> 
>> I expect that 2.9 will see less in the way of overrides, especially if we commence the planning process in early 2011 instead of allowing it to lag until after the annual conference as has occurred in years past.
>> 
>> Cheers,
>> 
>> Anth
>> 
>> 
>> 
>> On Nov 15, 2010, at 6:37 PM, Steve Swinsburg wrote:
>> 
>>> I agree, I don't particularly like the override votes.
>>> 
>>> We should instead try to address the concerns rather than overriding, as each member has an equal vote.
>>> 
>>> That said, what are the outstanding concerns with this particular inclusion? I think Lance did a good job of addressing everything.
>>> 
>>> cheers,
>>> Steve
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 16/11/2010, at 10:15 AM, John A. Lewis wrote:
>>> 
>>>> I also have some concern about the Override Votes, mostly in that I
>>>> think we may be doing them too quickly, and therefore too often. (I also
>>>> think some folks may be voting -1 on things a bit too quickly and
>>>> strenuously, which may also be causing the large number of Override
>>>> Votes, but I'm getting ahead of myself.)
>>>> 
>>>> In other similar groups that I've worked with using Apache-style voting
>>>> roles, the goal has been to work toward getting a -1 voter to change
>>>> their vote to at least a 0. The main way to do this has either been to
>>>> address their specific concerns (e.g. change the code so that it
>>>> addresses a specific objection that caused their -1 vote) or to convince
>>>> them -- hopefully with logic :) -- that their concern is
>>>> incorrect/unfounded/exaggerated/etc. These would sometimes turn into
>>>> multi-week discussions with multiple revisions of the thing under
>>>> consideration, all in order to get the entire group to a point of
>>>> consensus where the -1 votes would all turn into at least 0 votes, if
>>>> not into +1 votes.
>>>> 
>>>> We should regard the need for an Override Vote as a failure of the
>>>> group. One way or the other, we should be working the issue at hand so
>>>> that we can get everyone onto the same page -- either eliminating all
>>>> the -1 votes or getting a large number of -1 votes. Going to an Override
>>>> Vote and having it pass means we are telling the dissenters that they
>>>> are being unreasonable and we are not interested in their objections to
>>>> the issue anymore. Doing this once or twice a year might be fine if
>>>> we've truly exhausted the attempt at consensus -- doing this repeatedly
>>>> will mean we have a dysfunctional meritocracy and need to revisit the
>>>> makeup of the voting members.
>>>> 
>>>> I am as guilty as anyone (and probably more than most) at bowing to
>>>> expediency in these matters. In the case of the hybrid-mode code
>>>> changes, I scanned the objections that JF documented so well, I scanned
>>>> Lance's response to them, and it looked to me like there was good faith
>>>> work going on to address them. So I was willing to vote +1 for the code,
>>>> and I was willing to vote YES on the Override. But if someone else, who
>>>> is paying way more attention to the details than I am, thinks there are
>>>> still some issues to be addressed, then we ought to keep working the
>>>> issue until their concerns are assuaged. In hindsight, I think I should
>>>> have noted NO on this Override, and perhaps on the others as well. Not
>>>> because I don't want the changes (I very much want Sakai 2 to be
>>>> completely supportive of Hybrid mode), but because I should support the
>>>> right of someone else (who is watching the details more closely than I
>>>> am) to block the issue with their -1 until they are able to get on board.
>>>> 
>>>> This does mean that voting -1 is a powerful statement, and (as Uncle Ben
>>>> says) with great power comes great responsibility. We do need to make
>>>> sure we are only using a -1 vote for things we genuinely find
>>>> objectionable. If the rest of the group seems supportive of something
>>>> and one finds that thing merely distasteful, the correct vote is 0 with
>>>> appropriate concerns stated (which the group should still take to heart
>>>> and try to address).
>>>> 
>>>> All that said, we are a new group and these are the learning experiences
>>>> that we have to go through. So ultimately, I think this is healthy as
>>>> long as we continue to self-evaluate and grow and adapt to provide the
>>>> best stewardship of this project that we can.
>>>> 
>>>> What do others think?
>>>> 
>>>> 
>>>> On 11/15/2010 01:07 PM, Aaron Zeckoski wrote:
>>>>> Does no one else here see a problem with the fact that 2 of the people
>>>>> most involved with the core of the Sakai 2 codebase voted against this
>>>>> code change and yet it still went in?
>>>>> 
>>>>> It seems like the override thing is being used far too much for my
>>>>> comfort. Whatever happened to actually addressing concerns? Instead we
>>>>> are just ignoring them and proceeding like they don't matter. I mean,
>>>>> if I am just going to be overridden whenever I express concerns then I
>>>>> am thinking my time is better spent elsewhere.
>>>> _______________________________________________
>>>> sakai2-tcc mailing list
>>>> sakai2-tcc at collab.sakaiproject.org
>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>> 
>>> _______________________________________________
>>> sakai2-tcc mailing list
>>> sakai2-tcc at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>> 
>>> 
>> 
>> 
>> _______________________________________________
>> sakai2-tcc mailing list
>> sakai2-tcc at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>> 
>> 
> 
> 
> 
> -- 
> Aaron Zeckoski - Software Engineer - http://tinyurl.com/azprofile
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3829 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20101115/b1717fad/attachment.bin 