On rare occasions, I’ll get inspired to write up some aspect of my pedagogy for publication. The last time I did so, apparently, was way back in 2008, when I wrote about an experimental first-year seminar on digital storytelling (“Digital Storytelling as a Gateway to Computer Science”). Granted, I think about doing so way more than I actually do so, but with time constraints and so many other things vying for my attention and energy, it doesn’t often get past the idea stage.
I’m super passionate about the work I’ve been doing for some time now with academic civic engagement collaborations in computer science (ACE in CS), and have felt strongly for quite some time that I should disseminate this work, somehow, to a wider audience. I also wanted some way to engage with discussions around the ethical aspects of ACE in CS — and in particular, present alternatives to the usual “drop-in development” projects, where computer science students produce something for a community partner (as opposed to with a community partner) and then leave the partner to fend for themselves.
Between 2017 and 2020, over three academic years, three separate computer science Comps teams collaborated with the Northfield Union of Youth to co-create an online attendance-tracking system. The experience transformed the way I think about, and practice, ACE in CS, and in particular gave me the opportunity to experiment with an alternate, multi-year, multi-team approach to both Comps (capstone) projects and civic engagement collaborations. In “A Case Study of a Multi-Year Community-Engaged Capstone in Computer Science”, published earlier this month as a Project with Promise in the Journal of Higher Education Outreach and Engagement 26(1), my former collaborator at Carleton’s Center for Community and Civic Engagement (CCCE), Emily Oliver, and I describe the project in detail, tying it in to the current literature on transformational civic engagement practices. We hope that it can serve as a model to other institutions hoping to engage in more ethical, sustainable, iterative, and collaborative civic engagement projects.
Here are four of my favorite takeaway points from the article. Hopefully they will give you enough of a taste to go and read the whole thing. 🙂
- Relationship-building is multi-faceted, ongoing, and decentralized. The collaboration with the Union of Youth was actually initiated by a student, who attended a panel presentation of community organizations, heard them describe the need for better attendance tracking, and thought “maybe CS could help.” The student came to talk to me, I looped in the CCCE and met with the organization’s director, and the rest is history. Or, more honestly, that’s when the hard work of relationship- and trust-building really began! Every new year in the project brings new discussions and negotiations, new ways of working (as new students and new staff join the project, and others leave), new goals, and new priorities. The collaboration only works when everyone is invested and everyone has a say in the path and the outcomes.
- Multi-year projects allow students to more authentically engage in iterative development processes. While we weren’t 100% sure the first year that we’d continue the project for at least one more year, it was enough of a possibility that it freed the students from trying to achieve perfection. The students had room to try out an implementation, knowing that if it wasn’t quite right, it would be modified by next year’s team. And as it turned out, the first year team’s implementation contained a fatal flaw borne out of missing some nuance of the organization’s workflow. The first year’s implementation ended up being the rough draft for the second year team’s implementation, and this freed up the second year team to overhaul the existing implementation. When the second year team’s implementation had some security and privacy flaws, the third year team’s implementation used that as a starting point to shore up the existing system. This is the type of development process students who go on to software development positions will engage in, so this multi-year project prepares them well for that future.
- Iterative development benefits the community partner, too. As we state in the paper:
The time within each iteration of Comps, and between iterations of Comps, gave the partners space to reflect on their own goals and how these goals were and were not reflected in the current software product. This reflection, along with the need to provide somewhat frequent feedback to students on their design iterations, helped the partners better recognize and articulate their needs—including, and especially, needs that were not apparent at the start of the project…
- “A long term partnership allows for a focus on process, instead of only on outcomes.” Project onboarding occurs more gradually in a multi-year, collaborative project. Rather than the community partner(s) bearing the burden of framing out the project for students, the partner serves as a guide to the students. The students combined this guidance with their own observations of the organization, and used this to co-frame the solution with the community partner. Similarly, we learned the benefits of having a strong peer mentorship model between the teams, with one student from the previous year serving as the mentor and contact person for the next year’s project team. Each year, we learned more about what worked and what didn’t from a personnel standpoint, and refined our processes accordingly. Ultimately, this also led to more trust between all of the parties.
Next academic year, I’ll get to experience a different role — one of my Comps projects continues a ACE in CS project started this year by one of my departmental colleagues. I’m eager to apply the lessons described in the paper in continuing that collaboration, and eager to see what additional lessons crop up, too!
Have you collaborated with community partners? I’d love to hear your experiences in the comments.
This is what a computer scientist looks like 