As part of redesigning our introductory programming sequence, the University of Washington removed formal prerequisites from each course, allowing students to self-select into whichever course they believe best fits their experience level. To help facilitate these choices, we developed a guided self-placement tool that offers course recommendations based on students' previous experience and confidence with course topics. In this report, we describe the design and implementation of the self-placement tool and reflect on its first years of use. The tool has been effective, with most students reporting that they used the tool, followed its recommendation, and are confident in their enrollment decision. The rates of students switching or dropping courses within the introductory sequence have been low. In addition, results from a preliminary interview study show that all students who followed the tool's recommendation believed the suggested course was the right choice. Most students who opted for a different course were influenced by external factors, largely related to their confidence in the course content and perception of course difficulty levels. We conclude by reflecting on what we have learned so far and laying out next steps.

Teachers are essential to equitably broadening participation in computing in schools, but the creation of CS teacher education pathways faces many challenges. In this experience report, we share the many political, administrative, institutional, and sustainability barriers our institution faced in creating a secondary CS pre-service pathway. Throughout, we discuss the particular design choices we made in order to center equity and justice, both in the content of the program, but also in its structure, policies, and resources, which were often in tension with state standards and policies. We also describe our experience teaching and supporting the inaugural cohort of graduates as well as the graduates' experiences, which revealed tension between utopian and dystopian futures of computing and their role in helping students navigate them. We end with a reflection on key factors that we believe led to its successful first year launch, including leadership, interdisciplinarity, capacity, timing, and funding, and on sustainability concerns, including tuition subsidy and instructional capacity.

Concerns about academic misconduct are nearly ubiquitous among educators, and are especially prevalent in computer science. However most conversations relating to misconduct focus on how students cheat, how to detect when they do, and how to discipline offenders. This emphasis on "detect and punish" can have severe negative consequences, including toxic classroom cultures, adversarial student-staff relationships, and massive mental and emotional workloads for instructors. In this panel, we examine possible root causes for misconduct in CS courses and advocate for shifting the narrative to focus on designing and delivering courses that discourage misconduct by being inclusive and supportive to all students. We also offer concrete suggestions for approaches to reduce mis-conduct through non-punitive means.

Motivated by the need to develop equitable and just computer science education, we implemented a resubmission policy. We ran a large-scale, end-of-term survey of all students across two large introductory CS courses asking about their reasons for resubmission. Though some students were motivated primarily by grades, many responses suggested intrinsic motivation. We interviewed 9 students and found that in our competitive program, resubmissions take the pressure off the need to submit work that earns a perfect grade the first time. However, our findings suggest that resubmissions alone can't create space for equity and belonging.

Reliable and valid exams are a crucial part of both sound research design and trustworthy assessment of student knowledge. Assessing and addressing item bias is a crucial step in building a validity argument for any assessment instrument. Despite calls for valid assessment tools in CS, item bias is rarely investigated. What kinds of item bias might appear in conventional CS1 exams? To investigate this, we examined responses to a final exam in a large CS1 course. We used differential item functioning (DIF) methods and specifically investigated bias related to binary gender and year of study. Although not a published assessment instrument, the exam had a similar format to many exams in higher education and research: students are asked to trace code and write programs, using paper and pencil. One item with significant DIF was detected on the exam, though the magnitude was negligible. This case study shows how to detect DIF items so that future researchers and practitioners can do these analyses.

Design is a distinct discipline with its own practices, tools, professions, and areas of scholarship. However, practitioners from other fields often leverage aspects of design in their own work, leading to subfields like engineering design and architecture design that are neither wholly design nor wholly the intersecting discipline. Similarly, design and computing are known to intersect in educational contexts. Unfortunately, we do not yet have a clear understanding of how to characterize the kinds of design that may accompany computing topics, resulting in challenges to teaching and learning. This gap is particularly prevalent in K-12 computing education, where design is often used to promote student engagement but rarely studied as its own disciplinary phenomenon. Toward the goal of better understanding the nature and role of design in computing education, this article motivates and describes two qualitative, exploratory analyses of how design skills manifest in popular K-12 computing education curricula and activities. We find evidence to suggest two types of design within existing computing education curricula and standards: nondisciplinary problem-space design , which deals with defining software requirements, and disciplinary program-space design , which deals with choosing how best to meet those requirements. We find that these two types of computing design may exist independently, but they often overlap, creating an intriguing intersection of discipline-specific computing design educational activity. Finally, we discuss the practical implications of proceeding with research and educational practice in light of these results, highlighting the need for further exploration into the unique overlap of design and computing education.