7 Community-Engaged Learning & CIS3750
CONTENT
- A Brief History of CIS3750
- Pre-CIS3750 Timeline
- CIS3750 Timeline
- Post-CIS3750 Timeline
SLIDE DECKS
Some of the material presented in this chapter will be discussed in class. It is your responsibility to ensure you cover all the concepts presented both in class and in this textbook.
Community-engaged learning (CEL) is a major component of CIS3750, and it is used to help achieve some of the major, minor, and foundational learning outcomes that were described in earlier chapters. It also provides students with a real-world opportunity and a semester-long project that has the potential to make a difference in the community.
Sadly, the combination of CEL & computer science does not seem to be the norm. While it is used extensively in other domains (e.g. the social sciences), it seems to be lacking in undergraduate computer science classrooms.
A Brief History of CIS3750
Before we explore the specifics of a community-engaged CIS3750 classroom in greater detail, it makes some sense to understand the history of the course a little better.
Prior to 2012, students of the course would be tasked with mastering the learning objectives of the course while developing a video game. Specifically, they would be provided with a set of things the system needed to do (called requirements) that they would have to categorize and prioritize to ensure they had some sense of internal consistency and logic while meeting the needs of the client/user (represented by the professor).
Given the size and scope of such a project, teams would be designated to tackle certain elements of the design. For example, one team might focus on the database design and API implementation, another might focus on building the user interface, while another might develop the code that provides the background functionality of the system. Ultimately, students would need to master communication within and between these teams to develop the system by the end of the semester.
In 2012, CIS3750 became a community-engaged classroom for the first time. Working with partners from the Guelph-Wellington Food Round Table and the Food Access Working Group, students spent the semester exploring a potential solution to food insecurity while mastering the learning outcomes of the course. This included learning about food insecurity from the community partner, and better understanding the unique needs of the emergency food providers (e.g. the food banks and food pantries). Ultimately, this allowed the class to develop a list of requirements, build a plan of action, and implement their solution.
It’s important to note that the introduction of CEL did not change the learning outcomes of the course. However, the introduction of a community partner did affect how the course was delivered and the type of solution that was developed. In particular:
- the community partner replaced the professor as the client/user of the system being developed,
- the community partner provided a complimentary set of knowledge specific to the challenge that would be used to guide the development of a solution,
- the professor no longer provided the system requirements; instead, these were generated by the students through careful consultation with the community partner,
- the teaching team expanded to include the professor, teaching assistants, and community partners,
- the roles and responsibilities of each of the course players (i.e. student, teaching assistant, professor, community partner, and the intended users of the system) needed to be formalized, and
- the timeline for the course grew to include extracurricular periods prior to the moment when students stepped into the classroom, and extending well beyond when the students completed the learning outcomes of the course.
Note: while the community partner is part of the teaching team, they are not responsible for grading course deliverables. They do, however, provide feedback to the rest of the teaching team. Further, in some cases the client and the user may, in fact, be one and the same, however, this has not been the typical case for CIS3750.
While the learning objectives of the course have not changed, the introduction of CEL to CIS3750 requires that the course instructor begins working with the community partner months in advance of students stepping through the door of the classroom. It also often means that the course instructor will continue working with students and their community partners for months (and in some cases, years) after the course concludes. As such, the course timeline actually includes a:
- Pre-CIS3750 timeline,
- CIS3750 timeline, and
- Post-CIS3750 timeline.
We’ll explore each of these timelines in the following paragraphs.
Pre-CIS3750 Timeline
The course actually begins with a set of meetings to select the most appropriate community partner approximately four to six months before the first day of class. Here, the word appropriate is not meant as a judgment on the particular community group, or their particular challenge, but instead a measure of how well their challenge might map to the learning outcomes and goals of the course.
For example, one of the key goals of CIS3750 is that students will be able to communicate effectively within and between teams to develop a functioning prototype by the end of the semester. This means that at a minimum the community partner’s challenge must be of sufficient scope to require several teams to work together to solve it. A simple website that has no server-side functionality or database won’t fit the bill.
During each of the initial meetings with a potential community partner, the course instructor provides:
- a brief description of the course,
- a simplified list of the key learning outcomes,
- a list of the course deliverables, a description of how the community partner could/should be involved in those deliverables, and
- examples of successful projects from previous iterations of the class.
During this time, the community partner is:
- encouraged to ask any question to ensure they fully understand the scope and context of the course and learning outcomes, and
- are asked to describe their challenge in as much detail as possible.
This process is often repeated for several potential community partners before one is selected (based on the alignment of their challenge to the learning outcomes of the course). Once a community partner and project have been identified, the months leading up to the first day of class are spent working to
- understand the community partner’s challenge in even greater detail,
- align the elements of the challenge to the learning outcomes of the class,
- identify partner responsibilities, and
- establish and manage partner expectations.
Understanding the community partner’s challenge is a critical stage of the process, and extremely helpful during the learning outcome alignment process. In some cases, this requires several meetings and site visits to contextualize the challenge and determine a sense of its scope. It’s also during this time that a common lexicon is or should be established.
Similar to the software design process, open communication with the community partner is absolutely essential to ensure that the challenge is presented to the class correctly. Further, this stage often proceeds in an iterative fashion, with the community partner updating and correcting any misconceptions or misunderstandings.
Once the community partner’s project has been adequately defined, time is devoted to aligning the elements of the challenge to the learning outcomes of the class. While the community partner doesn’t necessarily take part in the alignment process itself, they are kept informed about the process so that they remain connected to the course. It’s also necessary during these stages to develop a set of responsibilities for the various parties, which may include classroom visits, data provisions, and depending on the community partner and challenge, intellectual property rights.
Working with community partners to identify and understand an appropriate class project, aligning it to the learning outcomes of the class, setting responsibilities and managing expectations represents a significant investment in course prep time; one that is in addition to the typical prep required for any class.
CIS3750 Timeline
When you first step into the CIS3750 classroom, you can be guaranteed that many months of work have already gone into the course. This includes a significant amount of time that has been contributed by the community partner – identifying the specific challenge, collecting or developing materials and resources related to the challenge, and organizing volunteers to join us in class.
Of course, as much as it would be great to have our community partner present in all of our classes, that isn’t feasible given the demands of their jobs. Regardless, during the semester you will have several face-to-face points of contact with the community partner. This will include at minimum:
- A first class visit (usually within the first full week of lectures) where the community partner will present their challenge to you, and answer any questions you might have. We will learn about asking good questions in a later chapter.
- During the paper prototyping lab demo, typically held around the seventh week of the semester. Here you will test the assumptions of your potential solution, and learn whether or not you’ve developed a solution that is logical to the client and user.
- During the wireframing prototyping lab demo, where you will show off a more complete prototype that captures navigation, and some aesthetic elements of the design. This is typically held during the ninth week of the semester.
- During the final lab demo, typically held during the eleventh week of the semester, you will show off your final prototype.
You may also want to set up a class Slack channel, a Google Document or Sheet, a shared Microsoft OneDrive folder, a Facebook Group, or some other communication and information-sharing tool that can be shared with and used by the community partner. Since our community partners may not be as computer savvy or familiar with the available technology, it’s always best to ask them how they might want to communicate. It’s also important to find out how they expect to receive information (e.g. from one point of contact per class, one point of contact per team, or individually), and how you can expect responses (e.g. within an hour, a day, a week).
Finally, the introduction of community-engaged learning does not change the course learning outcomes that were previously described.
Post-CIS3750 Timeline
Despite the best intentions of many of the students, it is very unlikely that a full solution to the community partner’s challenge will be implemented completely by the end of the semester. That is, you shouldn’t expect to launch your solution once the course comes to an end.
Instead, if students are interested, the project can be brought closer to completion outside of the CIS3750 classroom. In many cases, students do this while earning course credit in one or both of the independent study courses available to computer science students: CIS4900, and CIS4910. In other special cases, the community partner may provide funding to hire undergraduate assistants to implement and test the product that was prototyped in the class. In other cases, community members might donate enough money to help support further development.
In all of these scenarios, it is necessary to continue dialogue with the community partner to ensure they are aware of the state of the system, the resources needed to complete the project, any unexpected hurdles or challenges, and the expected timeline.
“CIS3750 showed me that life as a software developer does not have to be about making the latest social media website or generating profits through user data. It opened my eyes to a section of society that is underserved by our industry, a place where even a weekend of work could change the day-to-day for so many.”
CIS3750 Alumnus