By Jason Simms
Wesleyan University
jsimms@wesleyan.edu
Some of the CLAMP leadership asked me to write a reflection piece based on my experiences at MoodleMoot US 2015. I am more than happy to do so, as several issues arose that might pertain to CLAMP and our activities, or that at least our members might find interesting. I should note, however, that this writing is my own, meaning that anything expressed here may not reflect in any way the views or positions of CLAMP as a group.
What first struck me was the sheer scale of the event, which included brass bands, clowns, and magicians throughout the week. I was pleased, yet surprised, to see hundreds of attendees, a view that others shared as well. I had read ominous emails that the registration deadline had been extended a few times, and as such I was anticipating a thin crowd. Happily that was not the case, and presentation venues were regularly packed, indicating a robust interest in “All Things Moodle,” ranging from administration to design, and everything in between.
In fact, I was really surprised at the number of UX-themed presentations and sessions. While that may have been an artifact of geography, since many schools that have staff and resources devoted to UX seem to be located in that region, what is clear is that several people and institutions are devoting significant time to questions of design, interface, usability, accessibility, and related items. CLAMP might consider recommending design specifications or best practices that our members use along these lines, whether shared documentation, templates, tool discussion (e.g., Atto and text editor features), or even just ongoing discussions about how liberal arts institutions are working to address similar issues. This likely will only become more important as legal questions of not providing accessible content, such as having every course video and audio file subtitled, ensuring that LMS material is fully accessible to screen readers, and so on intensify. Our members might like a set of resources devoted to these and related topics.
On a similar note, Eric Merrill noted that few institutions share best practices related to network architecture or systems configuration outside of conferences. Many schools within CLAMP are of a similar scale in terms of enrollment, system demand, and overall resources, meaning that there is ripe possibility for information sharing in related areas, including DB tuning, load balancing, software versions and configuration (e.g., OS, Apache, PHP), etc. Some sort of repository with this information could be a valuable resource for member schools.
Some of the meta conversations that were happening throughout the week are worth discussing, too. During his opening keynote, Martin stated that long-term support (LTS) releases will happen every fourth release, starting with 2.7 (then 3.1, etc.). I asked him later about this decision, given that many CLAMP schools opt to deploy even-numbered releases for a variety of reasons, but mostly because when the summer upgrade cycle starts, those versions have been “in the wild” for several more months than the odd-numbered releases. Aside from the fact that he was apparently unaware of this, stating that southern hemisphere school tend to use even releases and northern schools tend to use odd releases (and in truth I can’t speak with firm data regarding that, only what I know from talking with CLMP attendees and others), he said that his goal was to have the first release that includes learning analytics and metrics, which should be 3.1, be an LTS version, because he does not want schools to choose to delay adoption of those features just to have an LTS version. (As an aside, learning analytics and metrics are clearly a focus for him personally, and seemingly for core as a consequence.) After 3.1, however, he said that he might be amenable to staggering LTS releases between even and odd versions. If this is important, then CLAMP should ensure that this discussion continues and that some formal plan is adopted along those lines. This will be less important to schools that are considering, or already do, provide a new Moodle version with each academic year, rendering the need for LTS less critical, though still important when considering patching and maintaining access to archival instances (e.g., for course backup/restore).
Another area of focus was the Moodle Association, a topic on which Martin provided additional details. In short, the Association would be tasked with determining priorities for Moodle development and ultimately hiring Moodle core to implement the changes. Membership in the Association would range between $100 and $10,000 (Australian dollars). My personal concern with this is that it is explicitly a “pay to play” model, wherein members who pay more money are given more votes, a model that closely mirrors, e.g., how the World Bank works. I am worried that this will enable larger partners and organizations to have an explicitly disproportionate voice in directing Moodle development, possibly “drowning out” smaller schools and groups. While on the one hand this may make sense from an economic standpoint for Moodle core, it is unclear what effect, if any, this will have on groups like CLAMP.
On the one hand, Martin was very positive about CLAMP joining the Association, and in speaking with representatives from CLAMP schools, most seemed to agree that doing so would probably be wise. Membership, Martin confirmed, can be informal, in that CLAMP doesn’t have to be an official organization (i.e., with formal 501(c)(3) status, or an actual incorporated entity) in order to join; we would just have to designate a point contact, and how we choose to organize as CLAMP would be up to us. On the other, however, he was explicit that he would prefer that CLAMP not exist, or perhaps more accurately, would not have to exist. His primary reasoning is that he would prefer Moodle core to be able to meet the needs of institutions like ours with a flexible product that would not require a separate build. And the reality is that CLAMP builds have been tracking closer to core over time.
As such, one possible direction of growth for the group would be to focus first on providing functionality that our members find useful through plugins, blocks, etc. that are extensible, rather than modifying or embedding in a forked core build; second, working as part of the Association to address enhancements, changes, and additions to core that are relevant to us and similar institutions; and third, to continue to contribute bug fixes through Tracker and documentation both to core and to our members. I believe personally that this would strengthen CLAMP’s role in Moodle development and engagement in general while also facilitating greater interaction with, and service to, our member institutions.