2024 SIGCSE BoF

2024 SIGCSE BoF #

At the 2024 SIGCSE Technical Symposium we presented a Birds of a Feather session on community-based service learning in order to share ideas and begin building a community of practice. Participants discussed concerns and challenges regarding community-based service learning, and shared wisdom and insights gained from teaching such courses. Below is a summary of the discussions during the BoF.

Concerns about implementing community-based projects #

  • Identifying projects/partners:

    • Where to start in locating potential partners/resources to aid in this. Some institutions have community-engaged coordinators (project scouts).
    • Ensuring the community partner was committed to the process and has appropriate expectations.
    • The project scope matches the available time; usually a single term.
    • Understanding the partner’s technical capabilities: Their role in technical decision making, being a supportive resource for student teams, and dealing with post-completion maintenance.

  • Institutional concerns:

    • Faculty buy-in
    • Departmental buy-in:
      • Learning goals can be achieved via community-engaged service learning.
      • Project continuation over multiple semesters, especially in the case where the lead faculty member is not present in subsequent semester(s).

  • Project concerns:

    • Faculty time commitment.
    • Ability to meet functional requirements in the time allotted.
    • Ability to meet non-functional requirements (e.g. cybersecurity) for a production/deployed system.
    • Student capabilities

Some “what I wish I knew before starting a project” pearls/insights #

  • Pre-semester preparation:

    • How to vet both potential partners and projects. Everyone needs to be very realistic about what can be accomplished in the time allotted. While student success can be very uplifting, student failure is very disheartening.
    • How create a stable project environment:
      • A project “contract”
      • Backup contact person if needed
      • Promised level of responsiveness
      • Agreed upon project scope (no, or at least controlled project scope creep, or “surprise” new requirements)
      • Managing partner expectations. Failure (i.e. incomplete software) is an option, the software produced is free, as in “free kittens,” and is the expectation to deliver a prototype or production software.
      • Partner is both a “client” and a partner in the educational process. Students are neither (unpaid) interns, nor employees.
      • An unambiguous project deliverable: a prototype or production software. Is there a maintenance plan, and a deployment strategy?
      • Is this a multi-semester project? If so, what is the plan for project hand off and continuation? (Same faculty member - same course, different faculty member - same course, etc.)

  • Running the project:

    • Agreed upon vocabulary, especially when the project partner lacks an appropriate technical liaison.
    • Educating students on how to behave professionally.
    • Managing the unfortunate scenario of a student skills - project needs mismatch. This is especially true with requirements engineering.
    • Dealing with the vagaries of student behavior: they can drop the class, disappear, fall ill, temporarily focus on other classes, etc.
    • Student team construction/composition. This includes team size (4-6 seems to work well), how formed (instructor assigned/self selected), role assignment (instructor assigned/self selected).
    • Role of the faculty instructor: completely hands-off, or jumps in where/when needed (e.g. requirements engineering)
    • Aligning the software development calendar with the academic calendar.
    • Leverage the social good aspect of the project in a positive way.
    • Assess (hopefully consistent) student effort rather than project outcomes. Have an assessment plan and clearly communicate this to students.
    • Illuminate the hidden curriculum. For example, one may need to teach students how to work in a team (and perform different roles in a team) rather than simply assume they already know how to do this.
    • Managing/overseeing the team-partner relationship and the faculty member-partner relationship. One team member (team lead) and one faculty member works best.

  • Project status after the term concludes:

    • Strategies for incomplete software development:
      • Paid internship for student(s)
      • Student volunteer their labor
    • Software maintenance (there are multiple approaches, including the to be avoided, “it falls to the instructor” default).