With society's increasing dependence on computing innovations---especially technologies that impact decision-making in fields such as healthcare, financial services, child welfare, hiring, safety, and policing---it is increasingly important for the future creators of these innovations to learn how technologies can potentially negatively impact people of different identities and backgrounds. Unfortunately, few universities offer courses designed specifically for Computer Science and Engineering students to explore the issues of diversity, equity and inclusion of computing innovations.

K-12 computing teachers need guidance on how to best implement student-centered practices for teaching programming, particularly in block-based programming environments (BBPEs) [10]. One way to provide such guidance to teachers is through Integrated Development Environment (IDE)-based learning analytics [4], which involves collecting data on students’ interactions with IDEs, translating them into meaningful information about students’ learning processes, and designing interventions that are grounded in such data. Most of the work on IDE-based learning analytics have focused on university-level introductory computer science courses (e.g., BlueJ [6]) that taught text-based programming languages. Specific to BBPEs, there has been significant analytics work with iSnap [7], which focused on offering intelligent tutoring to students based on their actions within the IDE. Little work, however, has been done on IDE-based learning analytics in Scratch [9]; prior work on Scratch learning analytics used clickstream data to characterize students’ programming abilities, which fails to fully capture students’ learning processes [3]. For K-12 teachers teaching with Scratch, collecting and analyzing data beyond clickstream (e.g., ProgSnap2 [8]) can provide more insight on student programming behaviors and how students learn to program with Scratch. Insight provided by a richer set of Scratch learning process data could empower teachers to design classroom interventions (e.g., feedback, scaffolds) to proactively respond to student needs; the use of Scratch learning analytics to inform the design of classroom interventions has not been thoroughly explored in IDE-based learning analytics [4].

Systems of power - such as structural racism, a system that upholds the ideology of white supremacy - are invisible and permeate our everyday lives and un/intentionally into our research. As these systems influence what counts as 'successful' work, CSEd researchers often have to assimilate ('whiten') themselves and their work into dominant ideals that uphold these structures. This workshop brings together aspiring and early-career CSEd researchers to critically examine and unpack the impacts of systems of power on ourselves and our research practices. Such examination is necessary to strive towards a critical consciousness in the field. We investigate critical questions like the following: What are systems of power? Who has the right to participate? Who has the right to exclude? We will use group-based activities that center historicities and 'outsider' knowledge to examine CSEd research practices and theories to answer these questions. We will draft a set of guidelines and recommendations available to the broader CSEd research community from the discussions and activities.

Computational thinking (CT) is a problem solving approach that is becoming prominent in educational settings. To help ease students into the world of programming, visual programming tools such as Scratch are used. Researchers are also developing various tools in an attempt to assess students' proficiency in thought processes that make up CT. However, current existing tools mainly utilize students' final code products when evaluating their demonstration of CT, losing their opportunity to understand students' actual learning and programming procedures. This work presents a logging methodology that records programming actions of students in the Scratch block coding environment to enable an in-depth analysis of students' programming process. With this logging methodology, we conducted a case study with introductory programmers to study how the logs of students' programming processes can provide insight into how they practice CT during programming.