[sakai2-tcc] [Building Sakai] Assignments 2

Wed Mar 6 09:54:40 PST 2013

Assignments 2 faces a couple of challenges.  First, its developer footprint is a narrow one.  Second, institutional support is overwhelmingly concentrated within a single institution and has been so for years.  Indiana has contributed 96% of all assignment 2 commits since early work began on the tool in 2006. [1]  No doubt percentage figure is a bit inflated by patch contributions handled by Indiana but I think the conclusion a safe one that no organization has truly "stepped up" (as Megan put it) to share assignment 2 development work with Indiana.

A narrow developer footprint and single institution support (Michigan) has also been a hallmark of the assignment tool.  However, a wider organizational footprint is now discernible among the committer traffic.  Michigan's share of development activities now amounts to under 74% of all commits.  Since 2011 its share of the workload is beginning to assume a more natural profile, one consistent with what one ought to expect to see in a community source initiative.

That said, assignment commits have dropped by over half between 2011-2012, a change in effort which undoubtedly plays into the perception held by some that support for assignment is waning.  Still, Lancs, Oxford, IU, UCT, UDL, UPMC, UPV, Flying Kite, Longsight, Samoo and Unicon in addition to Michigan have all contributed to assignment development/maintenance in 2012.  Irrespective of any particular shortcomings in the tool, community support for it is considerably more diverse than is the case for assignment 2--a clear advantage along with its "core" status in any conversation regarding replacement or calls for refactoring.

Assignment 2 has likewise seen a decline in commit activity since the heady days of 2008-2010, indeed, a rather steep one.  Most likely it reflects Indiana's comfort level with the tool.  For it to the supplant the assignment tool in the core build--as was originally envisioned--a considerable injection of active community support is at a minimum required.  If others expect Indiana alone to respond to calls for assignment 2-related improvements or to somehow shepherd it to core status they need to rethink their assumptions as the days of single institution support for key CLE capabilities is fast drawing to a close.

Anth

[1] Assignment trunk commits 2006 - 2013
Year	     Commits	     UMich	       Percent
2006	154	137	88.96%
2007	349	288	82.52%
2008	172	106	61.63%
2009	178	151	84.83%
2010	159	114	71.70%
2011	156	95	60.90%
2012	75	31	41.33%
2013	10	2	20.00%
TOTAL	1253	924	73.74%

[2] Asssignment2 trunk commits 2006-2013
Year	      Commits	       IU	      Percent
2006	73	73	100.00%
2007	66	66	100.00%
2008	695	639	91.94%
2009	433	433	100.00%
2010	239	235	98.33%
2011	80	77	96.25%
2012	43	43	100.00%
2013	4	4	100.00%
TOTAL	1633	1570	96.14%

On Mar 6, 2013, at 12:04 PM, May, Megan Marie wrote:

> *sigh*    I think Matt raised an excellent discussion topic.  There was 1 thing that was very clear at last year's BOF at the conference.    People thought it was a waste of resources that there were two assignments tools and the sentiment of that very large group was that Assignments2 should be where the community goes.  
> 
> I'm troubled by some of your assertions below:  
> 
> (a)  The issue is that community has a resource issue.  There are minimal resources working on the CLE as it is and a lot of the work is institutionally driven.    Let's not make developers into villains because they can't be everything to everyone all the time. 
> (b)  I'd argue this is an issue of the past.  IU implemented A2 alongside A1 and there was a utility written that imported the assignments from A1 to A2.  I'd also argue that Profile2 also did a good job of this.   This seems to be a lesson the community has learned from.   
> (c)  I think that this is an unfair representation of what could happen.  There are a lot of other scenarios that could be painted - these happen to be very negative ones. 
> (d)  This concern is in the way these 'replacements' were approached in the past.   Looking at Profile 2 I think we've gotten better. 
> 
> While things in the past haven't always gone smoothly, I like to think that community has started to evolve.  Let's not be afraid of new tools because we're scared of past mistakes.     
> 
> Megan
> 
> 
> 
> -----Original Message-----
> From: sakai-dev-bounces at collab.sakaiproject.org [mailto:sakai-dev-bounces at collab.sakaiproject.org] On Behalf Of Charles Severance
> Sent: Wednesday, March 06, 2013 8:32 AM
> To: dev sakai
> Cc: sakai2-tcc Committee
> Subject: [Building Sakai] Assignments 2
> 
> Matt,
> 
> I strongly disagree with the notion that we should replace Assignments with Assignments 2.  Every time in the past we have gone from X to X2 it has been a painful experience for several reasons:
> 
> (a) The school that purports to be behind X2 turns out to be less committed to supporting the communities needs than the school supporting X1 once issues are raised with X2.  They are willing to fix things their local users find in the product but generally never have resources to fix problems other schools find.
> 
> (b) We never get a real conversion - a few schools either hack up a conversion or decide to abandon the old data - this might be fine for a few adopters making local tradeoffs  - but unacceptable for code in trunk for all 300 adopters
> 
> (c) There is never feature parity - ever.   The few schools using X2 like the additional features and so they turn a blind eye towards what is missing and are not motivated to reach feature parity once they have switched and told their users "too bad" regarding missing functionality.   The schools using X2 are happy to compromise because for some reason they prefer the new.
> 
> (d) Given that X2 is in a few places things like performance or scaling issues are seldom identified until we we drop X2 in trunk and folks upgrade and wake up with a surprised look on their face the first week of the semester when it all goes pear-shaped.   At that moment, the "fans" of X2 seem to vanish and are unwilling to fix the problems that crop up.
> 
> Believe me, if we set our minds to it, we could fix the state-related problems in Assignments 1 in a few weeks as long as folks were wiling to do a complete and thorough QA / regression test of the code.   We would have multi-tab capabilities - and eliminate these ghostly bugs that come from weird click patterns.   And it would take a month.   If we went to A2, it would take at least a year before the pain was over.  And smart schools would delay upgrade to our next release, waiting for the brave few to work out the kinks of A2.  It is like a poison pill for our next release when we are trying very hard to get more schools close to the current release and make it easier to keep up with latest releases.
> 
> If we don't have the resources / energy to QA state-rlated changes to A1 - then we absolutely do not have the resources to bring the A2 code to the level of A1 and build a seamless transition.
> 
> Those who like Assignments 2 can run it - lets not regress trunk.  Lets not make things much worse because we are afraid to fix a bug.  If we break core functionality - it is one way to force resources to be invested - but it is a bad way to do it.
> 
> /Chuck
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> 
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> 
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20130306/fe3f0861/attachment.html 