[DG: Teaching & Learning] Samigo Working Group: transition to a different workflow

[Keli Sato Amann]

Hello,
While most code contributions are managed by the core Sakai team, the Samigo Working Group (Tests & Quizzes) started a monthly call 3 years ago to review contributions, whether they be code or design proposals, from a user experience point of view. Karen and Lydia had commit privileges for Samigo and many of those fixes and features were referred to them.

Given the size and complexity of the tool, it seemed to make sense to have a dedicated meeting, as well as a dedicated mailing list for Samigo (samigo-team at collab.sakaiproject.org). However, with more members of the Sakai community becoming expert in Samigo and fewer people participating in a monthly call, the folks who showed up to our last call on Tuesday  discussed how we might move to have Samigo managed more like the rest of Sakai, but perhaps with a few best practices we've established. Notes are on confluence (https://confluence.sakaiproject.org/display/SAM/2014-07-01+Meeting+Notes), but here is a summary, which might be a good workflow for new contributions in general.

To propose a new feature or improvement for Tests & Quizzes, either at code or design stage, we propose the following:

Step 1. User review via T&L call? It would be nice to preserve an aspect of the Samigo call, which was to get feedback on proposed features from a variety of user and campus perspectives--will this be used, will it be confusing, etc. Getting feedback from T&L is not quite the same as a review by members of the Stanford UX group who are familiar with Samigo, but in other ways might be better, as the T&L community tends to have people who work with real users. If someone has a new feature that has represents a major change to users, perhaps they can attempt to get on the T&L agenda? I don't know if T&L had the bandwidth though--  Neal explained that a group focused on Lessons had split off of the main T&L group with separate calls. If a major Samigo features makes it to the T&L agenda, Stanford will try to attend. If no live review can be scheduled, I would at least send a note to pedagogy at collab.sakaiproject.org with a link to a demo or specs or JIRA issue. Feedback from this review could be used to improve the feature and make it more likely that its adoption would be supported, but is certainly no guarantee. I don't think this review would be required by the core team for adoption (see below) but it wouldn't hurt and would be good all around.

Step 2. Development review by core team. Neal explained how the rest of Sakai was managed, which was new to me, so I'll recap in case others aren't familiar. The Core team meets on Thursdays at 10 eastern, and its agenda is openly posted on an etherpad (URL circulated in email on dev list e.g. http://etherpad.ctools.org/p/rmmt-2014-06-19). Anyone can add an agenda item to this, and that person should attend the call to represent the issue. After it is presented, the issue is then discussed on the dev list in a more open way. We suggest Samigo issues could also be discussed in this manner (I'm pretty sure some are already).

The one thing that will not be easily replicated is the advocacy role that the SWG played. That is, to decide that certain workflows needed improvement, come up with a better design, get feedback, and try to get the necessary code changes made. This was how the new Samigo settings featured in Sakai 10 came about. That process was great for design but not great for implementation. We went into design with no guarantee that the coding would happen; although we had volunteers to implement, we ran out of time (most of which is in trunk, but only have of the redesign made it into 10). With fewer large schools that can provide BOTH the thought leadership and resources for a particular tool, I'm hoping the crowd-funded model that Josh Baron and T&L seems to be trying for Lessons will prove successful and might be a model for other initiatives.

BTW, we talked about retiring this samigo-team email list, since not many know about it. If we keep it, we recommend always cc'ing another list, such as pedagogy or sakai-dev, as I am doing here, since these lists get more traffic. However, if no one can voice a reason to maintain it, the samigo-team list might get retired in the next month.

Keli Amann
User Experience Specialist
Academic Computing Services, Stanford University