[sakai2-tcc] Override Votes

Mon Nov 15 20:07:59 PST 2010

Summary:

Agreed, as Anthony mentioned. There was a vote for the inclusion of the
Nakamura hybrid + provider + login patches. This was turned down on it's
first pass through with 3 parts with only 3 +1 votes. [1]

This went to Roll Call and only got one YES [2], however, many people on the
list said that they would be receptive of just the providers and login
patches from SAK-17222 & SAK-17223 being included in 2.8. [3]

 3)  would TCC members object to leaving in place the hybrid patches added
to login and providers?  Assuming the patches do no harm (they are off by
default) they should stay in 2.8 in order to simplify adding hybrid (an
indie) to their build if it is not included in the release.

SAK-17222 <http://jira.sakaiproject.org/browse/SAK-17222>
SAK-17223 <http://jira.sakaiproject.org/browse/SAK-17223>

This is what this current ROLE call vote was about that passed with 12 YES
(After it went to vote and got a number of +1s). [4]

The providers part (SAK-17222) didn't seem like a problem to me. We already
have 12 "providers" available in providers, some better supported than
others. Perhaps this could be cleaned up but these are all mostly optional
and this one won't do anything unless you set up the properties. So I didn't
have any problem with SAK-17222. Lance also answered and resolved a number
of issues during the process and fixed some subtasks related to this issue.

The login peice (SAK-17223) was disabled by default, and easy to control via
properties. This was a filter for the hybrid if included (which it isn't by
default)

These 2 pieces just seemed easier to include by default to force someone to
recompile these 2 modules IF a solid Sakai 3 was available before 2.9. The
hybrid tool would still be something someone would have to build themselves,
include as an indie or wait to see if it's included in 2.9. Perhaps placing
/hybrid in it in /svn rather than /contrib was premature, but if it's not in
the build it's just a minor thing (there's a lot that's still in /svn/ that
probably should be cleaned)

The hybrid piece does up the new REST endpoints at "sakai-hybrid". Some in
the original (and in the new voting) did question this and found this point
valid. However I'm not if entitybroker would have been able to easily
accomplish this, "especially" if intention was to make it backward
compatible with older versions of Sakai. Though contrib, even iClicker has
it's own "/iclicker" endpoints for function and authentication (which it
still seems to use for us even though entitybroker interfaces exist in
2.6+). This was tough convincing our ops team at Michigan to accept another
way to authenticate, and we locked it down to on campus only.

I believe the discussion for the best way to promote and expose various end
points now and in the future will be very important, but wasn't part of this
specific Roll Call.

I agree with John that more time should have been spent figuring out why the
votes were still -1 or NO's rather than just passing along with a majority.

Hope these are all right, please correct any mistakes.

[1]
http://sakai-project-mail-list-archives.1343168.n2.nabble.com/sakai2-tcc-VOTE-<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>
on-inclusion-of-S3-Nakamura-Hybrid-work-in-2-8-td5580060.html<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>
[2]
http://collab.sakaiproject.org/pipermail/sakai2-tcc/2010-October/000567.html
[3]
http://sakai-project-mail-list-archives.1343168.n2.nabble.com/sakai2-tcc-VOTE-on-inclusion-of-S3-Nakamura-Hybrid-work-in-2-8-tp5580060p5591462.html
[4]
http://collab.sakaiproject.org/pipermail/sakai2-tcc/2010-November/000625.html
<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>
 On Mon, Nov 15, 2010 at 9:11 PM, Anthony Whyte <arwhyte at umich.edu> wrote:

> 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
> >
> >
>
>
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20101115/0cdd69d8/attachment-0001.html 