This is long overdue, but I finally sat down and processed through the course feedback we got last semester for our class on FOSS development. This post mostly consists of notes I want to remember for next time, but they're public because... why not?

First, there were some things we didn't have control over. An 8am start time for a computer science class? Yeah, not the most popular thing. (Though one student did like it!) Similarly, our course management system (dictated by the university) is nobody's favorite thing. And our computer lab was not set up for groupwork -- it was set up in a giant "X" shape with individual computer stations, and our interpreting team (Jess and Mo!) had to run circles around the entire room to go from student to student.

I'd love to have more control over our physical space and... uh, temporal time? (Honestly, for this class, it's practically a studio course, so I'd rather meet once for a 3-hour work session than for 1.5 hours twice a week at 8am.) But sometimes that's not an option.

I personally wish we'd had the bandwidth to discuss more current events in the FOSS world. We spent all our time focusing on the projects students were working on in class, with occasional mentions of how this or that lined up with an external community's release schedule or conference timeline or whatnot, but being able to drop in asides of "today, on LWN, I read..." would have been a nice extra touch. That having been said, I was so overwhelmed during my first semester teaching at RIT that I'm totally fine with this not having been my first priority.

I also have one note about emphasizing a "high level view of open source communities before jumping into work," which - I don't recall if that was in appreciation of what we did and/or a request for more of it, but that's something I want to iterate on being deliberate about next time around, too.

Similarly, we got high marks as instructors in terms of giving feedback, and doing so in ways that were incredibly tailored to their projects (which is what one does in a studio course). Students also enjoyed being able to choose their own projects, which is a central part of the course design (at least for me). Seriously, the number of student notes I have staring at me saying that kind of thing with multiple exclamation points and phrases like "SO AWESOME" is... pretty substantial. Learning how to find and scope and recalibrate on your own project is a hard skill that's not often taught in universities, and they recognized that as a valuable skill -- plus, as one student put it, "it allows students to work on a project they have motivation to work on."

Students appreciated the repeated emphasis on stand-up presentations and getting feedback on speaking skills. Their presentations did noticeably improve during the course of the semester. Similarly, they thanked us for forcing them to write blog posts and critically analyze their own interactions with FOSS community upstreams. This is in reference to a homework variant where they had to submit a conversational artifact -- an IRC transcript, an email exchange, a github comment thread, etc. -- and their analysis of what happened in it. I like that homework variant as well, and probably will keep it.

We did get asked to be more explicit about our preferred means of communication. We gave students a lot of options as to how they could contact us, but they didn't know which ones we wanted them to use -- the answer was really "any of the ones we said you could use" or "you could have asked us which was fastest," but it would also be easy to just list them in order of preference in the syllabus, so that's a reminder to me to make things more explicit when I can, so students don't even have to ask. Similarly, our office hours were extremely well-attended (we held office hours as an open FOSS work time) and there was a request for more opportunities for 1:1 meetings. Our response: "yes, you can always ask us for that, and people did ask - and get - that during the semester." But again, making-explicit more is never a bad thing; it's the reason I put a lot of thought into having text about disability accommodations, "if you're having trouble with housing/food/finances, please let me know so I can help," etc. in my syllabi, because even just asking can be extra work.

I grinned at one comment, which was about our use of Google apps for some aspects of the course -- because "it's not Free Software." True! We had them all upload their slides into a shared Google Slide deck for sprint presentations, to make fast work of transitioning between presentations. We also had things like presentation sign-ups on a Google Doc. Could we have used Beamer and github? Yes. Would it have taken more time for everyone to climb that learning curve? Probably. Would I like to have a completely FOSS stack for this course? Yes. Do we have those tools right now, in usable state to pick up and go with (given the time Steve and I had as faculty to prepare)? Not at the moment. When there's a good FOSS alternative, I'll use it. Until that time, I'm willing to make the compromise of using infrastructure that is ready-to-go so students have more time to work on their FOSS projects instead of learning new infrastructure simply to use FOSS software for presentation slide decks.

All in all, I thought it was a pretty good first run for the course redesign. I'd like to teach this course again and iterate on it -- I need to find a better way to keep course materials online and easily findable/editable for the future. If anyone has suggestions on how to do that, I'd love them; I've been thinking about porting as many of my course materials to, say, github pages (or similar) as possible, but struggle with the bandwidth to think about how to do that well -- so if anyone wants a curricular design related semi-tech/semi-content project, let me know!