[sakai2-tcc] Assignments 2

Matthew Jones matthew at longsight.com
Wed Mar 6 10:37:21 PST 2013


I'm not going to either agree or disagree without more research, I just
think this is an important decision that should be made. The last gap
analysis I've seen was done in 2011, I don't know empirically how much
better A2 is on performance or if it works better with the back button.
This may not make it worth the effort at all to switch.

I just hate seeing all of these feature requests come up (some of them
filled by Longsight) for Assignment if there's a possibility that it's
going to be finally deprecated in a year. Sure that means double the work
but it's also time we could be spending doing something else more useful.

We know Assignment 1 has long term architectural problems and Assignment 2
was originally created with the goals of addressing these problems. (
https://confluence.sakaiproject.org/display/MGT/Assignments+2 )

I wasn't around in 2006 when that happened, but I'm guessing that's because
it was too difficult to fix them in Assignment, so it's not going to be any
easier today. A lot of money/time went into this effort looking at the
commits and people who worked on both tools. This seems really similar to
OAE in some respects. However like OAE both tools (Assignment and CLE)
continued having active development and fell so far out of parity that the
intended replacement was never completed. In Assignment 2's case it should
have been in 2009-2010 when commits to Assignment were on the downturn.

But it's 2013 now and maybe too late to consider a replacement anymore. The
big things that still persist as really needing to be fixed in Assignment 1
are the session state (which Chuck believes would take a few weeks to fix)
and the data model (so the either the XML is only de-serialized when an
individual Assignment is selected or all of this broken up into a new data
model without any XML). In Mega Sites Assignment performs slow, but so do
any legacy tools that still store data as XML (as mentioned by David), so
the problem isn't unique to Assignments, but is improved by A2. In smaller
courses this isn't that big of a problem, but the future seems to be moving
away for that. Maybe we can just put up a big sticker that Sakai shouldn't
be used for MOOC's?

There's also the multiple revision feature of A2 which is nice, and some
might argue a forced storing of grades in Gradebook, which limits
confusion. (A integration built for A2)

I'm not for or against either way, I know working on either side (Fixing
the problems with A1 or filling the gaps in A2) will take time, though
don't know which one would take *more* time. If the TCC decides that A2
will *never* be a replacement for Assignment, that's fine with me, it
should just be renamed to the IU Assignment tool, or something as not to
imply any future replacement to others inside and outside the community
(external vendors especially). Calling anything 2 or 3 seems like it was a
bad idea all around. ;)


On Wed, Mar 6, 2013 at 8:31 AM, Charles Severance <csev at umich.edu> wrote:

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20130306/29f535bf/attachment.html 


More information about the sakai2-tcc mailing list