Roxbury Community College:
After introductions, we discussed a number of policy and technical concerns including:
1. Policies for maintaining old courses. Brandeis currently keeps all Moodle courses since 2006 on our production server, a practice that creates scalability issues. Wheaton is implementing a policy of maintaining separate instances for each of three years, and dropping the oldest instance in the fourth year, a practice that has its own share of scalability issues. The need to balance access to older courses (for both instructors and faculty) with space and staff considerations is a big concern (and exacerbated by the potential for compatibility issues when Moodle 2.0 is released).
2. Interfaces and feeds from student information systems to Moodle. Our group uses a widely disparate set of information systems — Banner, Peoplesoft, home-grown, Jenzabar — and the need to use course data to populate Moodle is a common factor. There are some open-source tools being used, some homegrown ones, and some folks are still populating and/or building courses by hand.
3. CLAMP. Regis and Wheaton are members of the Collaborative Liberal Arts Moodle Project, and there are some great tools and documentation being developed there (including the Moodle Liberal Arts edition).
4. The Moodle community. Going beyond CLAMP, the greater Moodle community offers both challenges and opportunities for us. The lack of a true dev team and the focus on Moodle 2.0 means that 1.9 developments and fixes are relatively stalled, but the distributed and talented experts in the community often provide solutions to problems quickly. Participation in the community (including the Moodle Tracker) often has the extra benefit of helping raise issues and problems that affect us to the top and get them more attention. The community also offers opportunities like Moodle Moots (including the virtual iMoot) that are worth investigating.
5. Moodle 2.0. The beta of Moodle 2.0 is due sometime this March (in theory), with a final release planned for this Summer. The features look impressive, but most of us are hesitant to upgrade on the initial release. There are also some concerns about what upgrading will do to current content (we know that themes, for example, are likely to break).
6. Demos. Brandeis briefly showed the Syllabus tool we implemented in our release, as well as the semester blocks and support enroll tools we’ve built.
There was lots of informal discussion of everything from release management to cloud computing.
It was agreed that there is definitely a benefit to having a local group to complement national groups like CLAMP and NITLE and the international Moodle community as a whole; while all groups can offer good spaces for asking questions, a local group offers more opportunities for hands-on demos and discussions. We’ve set up a BAMUG blog space for public discussion.
We also agreed that we do not want to be affiliated with Nercomp or other groups yet. Further, it was noted that, in spite of our geographic proximity, a two-hour meeting is almost too small a group to justify the drive for some folks; we’ve agreed that an all-day event would probably be better, as folks were already setting aside over half a day after travel time was included.
With that in mind, we want to plan an all-day BAMUG event. It will, of course, be free (as schools should be able to bring as many folks as are interested). Obviously, a full day’s commitment can be tough to manage, and we’d like to get a sense of what would be a good time for everyone. We’d also love to have some volunteers to lead discussions or run demonstrations, as well as a sense of what topics you’d like to discuss. Please drop me a line or feel free to leave a comment on the BAMUG blog with any thoughts you might have.