Blogs (1) >>

Papers describe an educational research project, classroom experience, teaching technique, curricular initiative, or pedagogical tool in the computing content domain. All papers submitted to the SIGCSE TS should be original work that complies with the ACM authorship policies. SIGCSE TS considers papers in three distinct tracks, each with their own unique expectations. See further details below.

Paper Tracks

Please ensure that you submit your paper to the correct paper track by reading the the Reviewing Guidelines. Papers will be reviewed for the track they are submitted to and will not be moved between tracks. Any submissions made to more than one track will be desk rejected from both tracks.

  • Computing Education Research. The primary purpose of Computing Education Research (CER) papers is to advance what is known about the teaching and learning of computing. CER papers are reviewed relative to the clarity of the research questions posed, the relevance of the work in light of prior literature and theory, the soundness of the methods to address the questions posed, and the overall contribution. Both qualitative and quantitative research is welcomed, as are replication studies and papers that present null or negative results.

  • Experience Reports and Tools. The primary purpose of Experience Reports and Tools (ERT) papers is observational in nature, and ERT papers should carefully describe the development and use of a computing education approach or tool, the context of its use including the formative data collected, and provide a rich reflection on what did or didn’t work, and why. ERT contributions should be motivated by prior literature and should highlight the novelty of the experience or tool presented. ERT papers differ from CER papers in that they frame their contributions to enable adoption by other practitioners, rather than focusing on the generalizability or transferability of findings, or threats to validity.

  • Position and Curricula Initiative. The primary purpose of Position and Curricula Initiative (PCI) papers is to present a coherent argument about a computing education topic, including, but not limited to curriculum or program design, practical and social issues facing computing educators, and critiques of existing practices. PCI papers should substantiate their claims using evidence in the form of thorough literature reviews, analysis of secondary data collected by others, or another appropriate rhetorical approach. In contrast to CER papers, PCI papers need not present original data or adhere to typical qualitative or quantitative research methods. PCI papers differ from ERT papers in that they do not necessarily report on individual experiences, programs or tools, but rather they may focus on broader concerns to the community.

Papers submitted to all tracks should address one or more computing content topic. Authors will be asked to select between 3 and 7 topics from this list at the time of submission. Papers deemed outside the scope of symposium by the program chairs will be desk rejected without review.

Authors submitting work to SIGCSE TS 2025 are responsible for complying with all applicable conference authorship policies and those articulated by ACM. If you have questions about any of these policies, please contact program@sigcse2025.sigcse.org for clarification prior to submission.

ACM has made a commitment to collect ORCiD IDs from all published authors (https://authors.acm.org/author-resources/orcid-faqs). All authors on each submission must have an ORCiD ID (https://orcid.org/register) in order to complete the submission process. Please make sure to get your ORCiD ID in advance of submitting your work.

Presentation Modality

Papers at SIGCSE TS 2025 can be presented either in-person using a traditional paper session or online via a limited number of synchronous Zoom session with Q/A. The online zoom presenters will be scheduled to present synchronously during the conference days just like the in-person presenters. Authors of accepted submissions must commit to one of these two presentation modalities in a timely manner to facilitate conference planning: due to additional costs, there will be a limited number of rooms set up with cameras and the necessary zoom session licenses. Registration rates for online presenters are likely to be comparable to those for in-person attendees and higher than that of online-only attendees, which will help offset the additional costs of supporting online presentation. Further instructions and information will be provided in acceptance notifications. Pre-recorded videos will NOT be required.

Accepted Papers

Title
A Case Study of Elementary Teachers’ Enactment of an NGSS-Aligned Computer Science Lesson: Verbal Support of Science, Engineering, Mathematics, and Computer Science IntegrationK12
Papers
Accelerating Accurate Assignment Authoring Using Solution-Generated Autograders
Papers
Accessibility Insights from Student's Software Engineering Projects
Papers
A Conceptual Metaphor Analysis of Recursion in a CS1 Course
Papers
A Course-based Undergraduate Research Experience (CURE) Focused Broadly on Research Methods in Computer ScienceMSI
Papers
A critical approach to ChatGPT: an experience in SQL learning
Papers
Addressing the Computer Science Teacher Shortage: A Case Study of Wisconsin Public High SchoolsK12
Papers
Aiming towards Abstraction: Does Algorithmic-Pattern-Oriented Instruction Promote the Teaching of Abstraction?
Papers
AI Technicians: Developing Rapid Occupational Training Methods for a Competitive AI Workforce
Papers
A Multi-Institutional Assessment of Oral Exams in Software Courses
Papers
Analysis of Generative AI Policies in Computing Course Syllabi
Papers
Analyzing Pedagogical Quality and Efficiency of LLM Responses with TA Feedback to Live Student Questions
Papers
An Analysis of Students' Testing Processes in CS1
Papers
An Automated Approach to Recommending Relevant Worked Examples for Programming Problems
Papers
An Evidence-Based Curriculum Initiative for Hardware Reverse Engineering EducationGlobal
Papers
An Explainable Model for AI-Generated Pseudocode Detection in Online High School Programming CoursesK12
Papers
An MS in CS for non-CS Majors: A Ten Year Retrospective
Papers
Approachable Machine Learning Education: A Spiral Pedagogy Approach with Experiential Learning
Papers
ASCI: AI-Smart Classroom Initiative
Papers
ASM Visualizer: a Learning Tool for Assembly Programming
Papers
A Student-Led Association for Computing Education: A Two-Year Experience Report
Papers
Auto-grading in Computing Education: Perceptions and Use
Papers
A Window into Data Apprenticeship: Developing an Integrated Work-Training Curriculum for Novice Adults
Papers
Bridging Disciplines: Integrating Computer Science and Social Studies in Rural Middle SchoolsK12
Papers
Bridging Novice Programmers and LLMs with InteractivityGlobalCCMSI
Papers
Bridging the community college cybersecurity classroom and workplace with the CyberSim LabCC
Papers
BugSpotter: Automated Generation of Code Debugging Exercises
Papers
Building Teacher and Community Networks for Sustainable Middle School Computer Science Education: Experiences from Two Pairs of TeachersK12
Papers
Building the AnonTool Pipeline: Providing CS Education For Rural K-12 SchoolsK12
Papers
Can a Free Tool in an Ebook Platform, Searchable Question Bank, and Summer Workshop Help Instructors Adopt Peer Instruction?
Papers
Can GPT Help? Supporting Teachers to Brainstorm Customized Instructional Scratch ProjectsK12
Papers
Case Study 2: Mapping between an E-Voting Curriculum and the DHS/NSA CAE Knowledge Units
Papers
ChatGPT for Accessibility Remediation in Software Engineering Projects
Papers
Circle of Life: Microworld Project at the end of CS1Global
Papers
Code Interviews: Design and Evaluation of a More Authentic Assessment for Introductory Programming Assignments
Papers
Comparing the Impact of Strict and Flexible Deadline Policies
Papers
Compiler-Integrated, Conversational AI for Debugging CS1 Programs
Papers
Connecting the Dots: Intersectionality, Active Learning, and Classroom Climate in Introductory Computer Science Courses
Papers
Construction and Preliminary Validation of a Dynamic Programming Concept Inventory
Papers
Coordinate: A Virtual Classroom Management Tool For Large Computer Science Courses Using Discord
Papers
Creating a Quantum Programming Course from Scratch: A Complete Idiot’s Guide
Papers
CryptoEL: A Novel Experiential Learning Tool for Enhancing K-12 Cryptography EducationK12
Papers
CS Concepts and Contextual Factors in Integrated Computing Activities in U.S. SchoolsK12
Papers
Curriculum for a Comprehensive Statewide In-Service CS Teacher Training ProgramK12
Papers
Cybersecurity Study Programs: What's in a Name?Global
Papers
“Debugging: From Art to Science” A Case Study on a Debugging Course and Its Impact on Student Performance and Confidence
Papers
Design and Evaluation of an AI-Assisted Grading Tool for Introductory Programming Assignments: An Experience Report
Papers
Designing Courses for Liberal Arts and Sciences Students Contextualized around Artistic Expression and Social Justice
Papers
Designing LLM-Resistant Programming Assignments: Insights and Strategies for CS Educators
Papers
Developing Computing Lessons for Rural High School StudentsK12
Papers
Developing Interest, Skills and Professional Dispositions in Computing and Engineering through a Multidisciplinary Enrichment Program for High School StudentsGlobalK12
Papers
Diagnosable Code Duplication in Introductory ProgrammingGlobal
Papers
Diary study as an educational tool: An experience report from an HCI course
Papers
Does Reducing Curricular Complexity Impact Student Success in Computer Science?
Papers
'Do I Have to Take This Class?': A Review of Ethics Requirements in Computer Science Curricula
Papers
dpvis: A Visual and Interactive Learning Tool for Dynamic Programming
Papers
Drafter: A Python Library for Full-Stack Web Development in CS1Global
Papers
Educator Experiences with Automated Marking of Programming Assessments in a Computer Graphics-based Design CourseGlobal
Papers
Embedding Executable Code in Programming Slideshows: Design Considerations and Field Tests for Interactive Code PlaygroundsGlobal
Papers
Emotions and Self-Efficacy of Undergraduate Computing and Engineering Students: A Systematic Literature Review
Papers
Engaging K-12 Students with Flow-Based Music Programming: An Experience Report on Its Impact on Teaching and LearningK12
Papers
Engaging Students from Under-Represented Groups to Pursue Graduate School in Computer Science and Engineering
Papers
Enhancing CS1 education through experiential learning with robotics projectsGlobal
Papers
Enhancing Cybersecurity Education using Scoring Engines: A Practical Approach to Hands-On Learning and FeedbackGlobal
Papers
Enhancing Cybersecurity Education with Artificial Intelligence Content
Papers
Enhancing Student Performance Prediction In CS1 Via In-Class CodingOnlineCC
Papers
Enhancing University Curricula with Integrated AI Ethics Education: A Comprehensive ApproachMSI
Papers
Evaluating GPT for use in K-12 Block Based CS Instruction Using a Transpiler and Prompt EngineeringK12
Papers
Evaluating Language Models for Generating and Judging Programming FeedbackGlobal
Papers
Evaluation of Systems Programming Exercises through Tailored Static AnalysisOnline
Papers
Examining Teamwork: Evaluating Individual Contributions in Collaborative Software Engineering Projects
Papers
Expanding the Horizons of Autograding: Innovative Questions at UBC
Papers
Experience Report on Using LANTERN in Teaching Relational Query ProcessingOnlineGlobal
Papers
Experience Report: Physical Models of Java InheritanceK12
Papers
Experience Report: Using Narratives to Teach Responsible Computing in the U.S. and NigeriaGlobal
Papers
Experience Report: Using the FABRIC Testbed to teach a Graduate Computer Networking courseOnlineGlobal
Papers
Experiences using Service Learning in Computer ScienceCCK12
Papers
Exploring Critical CS Teacher Education Program Design Through a Science and Technology Studies ApproachK12
Papers
Exploring Different Specifications Grading Policies
Papers
Exploring Sense of Belonging for CS Majors with Direct vs Competitive Admission Pathways
Papers
Exploring Student Reactions to LLM-Generated Feedback on Explain in Plain English Problems
Papers
Exploring the Adaptability and Usefulness of Git-Truck for Assessing Software Capstone Project Development
Papers
Exploring the Humanistic Role of Computer Science Teaching Assistants across Diverse Institutions
Papers
Exploring the Impact of Quizzes Interleaved with Write-Code Tasks in Elementary-Level Visual ProgrammingGlobalK12
Papers
ezFS: A Pedagogical Linux File System
Papers
Facilitating Student's Learning Transfer in a Database Programming Class
Papers
Faith to Move Mountains: Black Women in Computing Education
Papers
Fears and Confidence amongst Incarcerated Adult CS1 Students
Papers
Feasibility Study of Augmenting Teaching Assistants with AI for CS1 Teaching
Papers
Fostering and Understanding Diverse Interpersonal Connections in a Massive Online CS1 CourseGlobal
Papers
Grading for Equity in a Hyflex Compiler Design Course
Papers
How a Small College Can Make a Big Impact on High School CSK12
Papers
How Effective and Efficient are Student-Written Software Tests?
Papers
How Novices Use Program Visualizations to Understand Code that Manipulates Data Tables
Papers
iFlow - An Interactive Max-Flow Min-Cut Algorithms Visualizer
Papers
"I'm not sure, but...": Expert Practices that Enable Effective Code Comprehension in Data Science
Papers
Implementation of a Cryptocurrency Elective Course
Papers
Implementing Standards-Focused Professional Development for Middle School CS Teachers: An Experience ReportK12
Papers
Improving Agile Retrospectives through Metacognitive ScaffoldingGlobal
Papers
Improving AI in CS1: Leveraging Human Feedback for Better Learning
Papers
Improving the Representation of Undergraduate Women in Cybersecurity: A Literature Review
Papers
Improving Undergraduate Computing Engagement with Computing Fellows Across Disciplines
Papers
Incentivizing Good Programming Practices: The Impact of Early Program Submission on Student Course and Exam Performance
Papers
In-class Coding Exercises as a Mechanism to Inform Early Intervention in Programming CoursesOnlineCC
Papers
Instructor-Written Hints as Automated Test Suite Quality Feedback
Papers
Integrating a CS+Social Science Project into STEM and non-STEM High School CoursesK12
Papers
Integrating Small Language Models with Retrieval-Augmented Generation in Computing Education: Key Takeaways, Setup, and Practical Insights
Papers
Integrating Socially Responsible Computing through Direct Community Engagement in CS2 to Promote Hispanic/Latino Student RetentionMSI
Papers
Integrating Soft Skills Training into your Course through a Collaborative Activity
Papers
Interventions for Increasing Belonging and Inclusion in Undergraduate Computer Science Classrooms
Papers
Introducing Computational Thinking and Computer Science Instruction to Preservice Science and Math TeachersK12
Papers
Introducing K-12 Teachers to Computer Science Education through an Online Micro-credential: An Experience ReportK12
Papers
Investigating the Capabilities of Generative AI in Solving Data Structures, Algorithms, and Computability Problems
Papers
Investigating the Presence and Development of Student Instructor Preferences in a Large-Scale CS1 Course
Papers
Investigating the Use of Productive Failure as a Design Paradigm for Learning Introductory Python Programming
Papers
Iterative Design of a Teaching Assistant Training Program in Computer Science Using the Agile MethodGlobal
Papers
Jupyter Analytics: A Toolkit for Collecting, Analyzing, and Visualizing Distributed Student Activity in Jupyter NotebooksGlobal
Papers
K12 Computer Science Teachers’ Attitudes Toward a Foundational Assumption of EthnocomputingK12
Papers
KernelVM: Teaching Linux Kernel Programming through a Browser-Based Virtual MachineOnline
Papers
Large Language Models in Computer Science Education: A Systematic Literature Review
Papers
Larger than Life In-Class Demonstrations for Introductory Machine Learning
Papers
Leveraging Undergraduate Perspectives to Redefine AI Literacy
Papers
Literature Mapping: A Scaffolded, Low-Overhead, Opt-in Undergraduate Research Experience
Papers
Live But Not Active: Minimal Effect with Passive Live Coding
Papers
Live Coding Prompts Engagement, But Not Necessarily GradesGlobal
Papers
LLM-Driven Feedback for Enhancing Conceptual Design Learning in Database Systems CoursesOnline
Papers
Mathematical underpinnings of algorithms via in-class activities
Papers
Measuring Test Anxiety of Two Computerized Exam Approaches
Papers
Measuring the Impact of Distractors on Student Learning Gains while Using Proof Blocks
Papers
Midterm Exam Outliers Efficiently Highlight Potential Cheaters on Programming Assignments
Papers
Models of Mastery Learning for Computing Education
Papers
Moving What's in the CS Curriculum Forward: A Proposition to Address Ten Wicked Curricular Issues
Papers
Needs-Supportive Teaching Interventions in an Intro Computer Science Course: Exploring Impacts on Student Motivation and AchievementOnlineGlobal
Papers
NeuRL: A Standalone No-Code Web-Based Agent Environment to Explore Neural Networks and Reinforcement Learning CC
Papers
On Teaching Novices Code Comprehension Strategies by Utilizing Large Language Models Within Assessments
Papers
Opening Digital Doors: Early Lessons in Software Accessibility for K-8 StudentsK12
Papers
Our journey towards a diverse computing program: what worked, where we are, and what we have learned.
Papers
Peer Code Review Methods: An Experience Report from a Data Structures and Algorithms CourseGlobal
Papers
PhysioML: A Web-Based Tool for Machine Learning Education with Real-Time Physiological Data
Papers
Practical Cybersecurity Education: A Course Model Using Experiential Learning TheoryGlobal
Papers
Preparing K-8 Teachers to Teach and Infuse Computer Science Across All SubjectsK12
Papers
Principles of the Internet – Model Lessons for Lower Secondary School: Experience ReportK12
Papers
Programming Self-Efficacy in CS: Adding Four Areas of Validity to the Steinhorst InstrumentOnline
Papers
Quantitative Evaluation of using Large Language Models and Retrieval-Augmented Generation in Computer Science Education
Papers
RAD: A Framework to Support Youth in Critiquing AIK12
Papers
Reflecting on Practices to Integrate Socially Responsible Computing in Introductory Computer Science CoursesMSI
Papers
Reflections on Teaching Algorithm Courses
Papers
Relational Database Courses with CodeRunner in Moodle: Extending SQL Programming Assignments to Client-Server Database EnginesGlobal
Papers
Retention Teaching Assistants for Supporting Student Performance in Introductory-level Computing Classes
Papers
RISE Stars: An Experience Report on a Cohort of Black Freshmen Women in Computing
Papers
Rooted in the Collective: A Culturally Situated Artificial Intelligence (AI) Education Workshop For Urban Farmers
Papers
Satisfactory for all: supporting mastery learning with human-in-the-loop assessments in a discrete mathematics course
Papers
SENSAI: Large Language Models as Applied Cybersecurity Tutors
Papers
Sister Circles: An Intersectional Method in Computing EducationMSI
Papers
Sprint to Inclusion: Embedding Accessibility Sprint in a Software Engineering Course
Papers
Strengthening Workforce Education: Excellence in Programming Securely (SWEEPS)
Papers
Student-AI Teaming in a CS0 Assignment
Papers
Student Application Trends for Teaching Assistant Positions
Papers
Student Perceptions of the Help Resource Landscape
Papers
Students' Thoughts on Discrete Mathematics: Insights for Practice and Implications for Future Research
Papers
Students' Use of GitHub Copilot for Working with Large Code Bases
Papers
Student Utilization of Metacognitive Strategies in Solving Dynamic Programming Problems
Papers
Supporting Inclusive Computing: A Graduate Course to Prepare Future FacultyOnline
Papers
TA Bot Report: AI Assistants in CS1 Save Students Homework Time and Reduce Demands on Staff. (Now What?)
Papers
Tackling the Gender Gap in Cybersecurity EducationK12
Papers
Teacher Decisions and Perspectives in Scratch TIPP&SEE ImplementationK12
Papers
Teaching Cloud Infrastructure and Scalable Application Deployment in an Undergraduate Computer Science Program
Papers
Teaching Computing to K-12 Emergent Bilinguals: Identified Challenges and OpportunitiesK12
Papers
Teaching Our Teacher Assistants to Thrive: A Reflexive, Inclusive Approach to Scalable Undergraduate Education
Papers
Teaching Program Decomposition in CS1: A Conceptual Framework for Improved Code Quality
Papers
Tensor-Viz:Visualizing GPU Programming in AI CoursesMSI
Papers
The Impact of Group Discussion and Formation on Student Performance: An Experience Report in a Large CS1 Course
Papers
The Intersectional Experience of Black Girl High School Students in Advanced Placement Computer ScienceK12
Papers
The Rural CS+Agriculture Alliance Research Practitioner Partnership: Experience Report
Papers
TIPS for Students! A Fair and Equitable Way to Require, Motivate and Reward Creativity and Student-initiated ActivitiesMSI
Papers
Tool-Assisted Learning of Computational ReductionsOnlineGlobal
Papers
Toolkit for Educators of Data Science: Using physical computing to support data science education in the classroom.K12
Papers
Towards a More Inclusive Curriculum: Opportunities for Broadening and Diversifying Computing Ethics Education
Papers
Towards a Quantitative Competency Model for CS1 via Five-Channel Learning Sequences
Papers
Towards Integrating Behavior-Driven Development in Mobile Development: An Experience ReportOnline
Papers
Towards s’more connected coding campsGlobalK12
Papers
TrainYourSnakeAI: A Novel Tool to Teach Reinforcement Learning to Middle School StudentsK12
Papers
Undergraduate Computing Tutors' Perceptions of their Roles, Stressors, and Barriers to Effectiveness
Papers
Understanding the Impact of Using Generative AI Tools in a Database Course
Papers
Understanding the prevalence of a microaggression in CS and its influence on students' self-efficacy, belonging, and persistenceMSI
Papers
Ungrading as a Pedagogy for Teaching Qualitative Research Methods in Computing
Papers
Unlocking Potential with Generative AI Instruction: Investigating Mid-level Software Development Student Perceptions, Behavior, and AdoptionMSI
Papers
Unlocking Student Potential With TA-Bot: Timely Submissions and Improved Code Style
Papers
Variation in Engagement Behaviors among Student-Centered Pedagogies
Papers
VisOpt – Visualization of Compiler Optimizations for Computer Science EducationGlobal
Papers
What Can Computer Science Educators Learn From the Failures of Top-Down Pedagogy?Global
Papers
"Why is my code slow?" Efficiency Bugs in Student Code
Papers

Deadlines and Submission

Papers submitted to SIGCSE TS 2025 follow a two-step submission process. The first step requires that authors submit all paper metadata and a plain text abstract in EasyChair no later than Sunday, 14 July 2024. This data is used to allow reviewers to bid on potential papers to maximize the match of reviewer expertise to paper content. To help the bidding and reviewing process, please submit an abstract that is as close to the finished version as possible. The Program Chairs reserve the right to desk reject abstracts that do not contain content that can help a reviewer during bidding.

The second step of the paper submission process is to upload the final anonymized PDF of the full paper for review. This must be completed no later than Sunday, 21 July 2024. Authors who fail to submit an abstract by the first deadline will not be permitted to submit a full PDF.

Important Dates

Abstact Due Date Sunday, 14 July 2024
Abstract Due Time 23:59 AoE (Anywhere on Earth, UTC-12h)
Due Date Sunday, 21 July 2024
Due Time 23:59 AoE (Anywhere on Earth, UTC-12h)
Submission Limits 6 pages + 1 page only for references
Notification to Authors    Monday 30 September 2024 tentative
Submission Link https://easychair.org/conferences/?conf=sigcsets2025
Session Duration 15 minutes

Authors should carefully choose the appropriate track and review the authorship policies. Authors may also find it useful to read the Instructions for Reviewers and the Review Forms to understand how their submissions will be reviewed. Also note that when submitting, you will need to provide between 3-7 related topics from the Topics list under Info.

Abstracts

All papers must have a plain-text abstract of up to 250 words. Abstracts should not contain subheadings or citations. The abstract should be submitted in EasyChair along with paper metadata, and the same text should be included in the PDF version of the full paper at the appropriate location.

Submission Templates

SIGCSE TS 2025 is NOT participating in the new ACM TAPS workflow, template, and production system.

All paper submissions must be in English and formatted using the 2-column ACM SIG Conference Proceedings format and US letter size pages (8.5x11 inch or 215.9 x 279.4mm).

Here is a Sample Paper Submission with Notes that has some notes/tips and shows the required sections.

Page Limits: Papers are limited to a maximum of 6 pages of body content (including all titles, author information, abstract, main text, tables and illustrations, acknowledgements, and supplemental material). One additional page may be included which contains only references. If included, appendix materials MUST NOT be present on the optional references page.

MS Word Authors: Please use the interim Word template provided by ACM.

LaTeX Authors:

  • Overleaf provides a suitable two-column sig conference proceedings template.
  • Please do not use the anonymous document class option, as counter-intuitive as that sounds. We’d like to ensure that author blocks appear in the submission, and that option removes them.
  • Other LaTeX users may alternatively use the ACM Primary template, adding the “sigconf” format option in the documentclassto obtain the 2-column format. (ACM has recently changed the ACM template and we have not yet had a chance to verify that the new version works correctly.)
  • NOTE: The default LaTeX template text shows appendix materials following the references. SIGCSE TS 2025 does not permit appendices on the optional page allotted for references. Authors must include all relevant content within the 6 body pages of the paper. References are the ONLY thing that can be added on page 7.

Requirements for Double Anonymous Review Process: At the time of submission all entries must include blank space for all anonymous author information (or anonymized author name, institution, location, and email address), followed by an abstract, keywords, CCS Concepts, placeholders for the ACM Reference Format and copyright blocks, and references. For anonymized submissions, all blank space necessary for all author information must be reserved under the Title, or fully anonymized text can take its place (e.g. 4 lines containing Author1, Author1Institution, Author1Location, anon1@university.edu). In addition, please leave enough blank space for what you intend to include for Acknowledgements but do not include the text, especially names and granting agencies and grant numbers. Acknowledgements should be included in the first 6 pages.

Other requirements: Please provide a separate block for each author, including name, email, institution, location, and country, even if authors share an institution.

Desk Rejects: Papers that do not adhere to page limits or formatting requirements will be desk rejected without review.

Accessibility: SIGCSE TS 2025 authors are strongly encouraged to prepare submissions using these templates in such a manner that the content is widely accessible to potential reviewers, track chairs, and readers. Please see these resources for preparing an accessible submission.

Double Anonymized Review

Authors must submit ONLY an anonymized version of the paper. The goal of the anonymized version is to, as much as possible, provide the author(s) of the paper with an unbiased review. The anonymized version must have ALL mentions of the authors removed (including author’s names and affiliation plus identifying information within the body of the paper such as websites or related publications). However, authors are reminded to leave sufficient space in the submitted manuscripts to accommodate author information either at the beginning or end of the paper. LaTeX/Overleaf users are welcome to use the anonymous option, but are reminded that sufficient room must exist in the 6 body pages to include all author blocks when that option is removed. Authors may choose to use placeholder text in the author information block, but we encourage authors to use obviously anonymized placeholders like “Author 1”, “Affiliation 1”, etc.

Self-citations need not be removed if they are worded so that the reviewer doesn’t know if the writer is citing themselves. That is, instead of writing “We reported on our first experiment in 2017 in a previous paper [1]”, the writer might write “In 2017, an initial experiment was done in this area as reported in [1].

As per ACM guidelines, authors may distribute a preprint of their work on ArXiv.org. However, to ensure the anonymity of the process, we ask that you not publish your work until after you receive the accept/reject notice. If particular aspects of your paper require earlier distribution of the preprint, please consider changing the title and abstract so that reviewers do not inadvertently discover your identity.

Submissions to the Papers tracks are reviewed with the dual-anonymous review process. The reviewers and meta-reviewers (i.e. associate program chairs or APCs) are unaware of the author identities, and reviewers and APCs are anonymous to each other and to the authors.

The reviewing process includes a discussion phase after initial reviews have been posted. During this time, the reviewers and APC can examine all reviews and privately discuss the strengths and weaknesses of the work in an anonymous manner through EasyChair. Following discussion, the APC shall draft a meta-review that holistically captures the group position on the paper, incorporating views raised in the reviews and during the discussion phase.

The SIGCSE TS 2025 review process does not have a rebuttal period for authors to respond to comments, and all acceptance decisions are final.

ACM Policies

By submitting your article to an ACM Publication, you are hereby acknowledging that you and your co-authors are subject to all ACM Publications Policies, including ACM’s new Publications Policy on Research Involving Human Participants and Subjects (https://www.acm.org/publications/policies/research-involving-human-participants-and-subjects). Alleged violations of this policy or any ACM Publications Policy will be investigated by ACM and may result in a full retraction of your paper, in addition to other potential penalties, as per ACM Publications Policy. Please see the Authorship Policies page for details.

ACM has made a commitment to collect ORCiD IDs from all published authors (https://authors.acm.org/author-resources/orcid-faqs). All authors on each submission must have an ORCiD ID (https://orcid.org/register) in order to complete the submission process. Please make sure to get your ORCiD ID in advance of submitting your work. (If EasyChair does not request the ORCiD ID for your coauthors, you do not need to find a way to enter one.)

Be aware of reviewing guidelines for each track

Once submitted, a paper will not be moved between the three paper tracks. If your paper does not fit with the reviewing criteria below for the track that you chose, it is probable that it will receive lower scores.

Authors should check the following review guidelines to see in which track their paper best fits.

There are three different paper types at SIGCSE TS : Computing Education Research (CER), Experience Reports and Tools (ERT), and Position and Curricula Initiative (PCI). Reviewers are assigned to a specific paper track (e.g. a reviewer in the CER track will only be assigned to review papers in that track). This is to avoid confusion and for reviewers to get familiar with the guidelines for their specific paper track.

All papers will be considered relative to criteria for motivation, use of prior/related work, approach, evidence, contribution/impact, and presentation. Each track has guidance about how reviewers should consider these criteria relative to the goal of the track, and each paper must be evaluated using the criteria for the track to which it is submitted.

The following table illustrates how to interpret the review criteria for each of the three tracks of papers. For convenience, you may also download a PDF copy of the paper review criteria.

Criteria Computing Education Research (CER) Experience Reports & Tools (ERT) Position & Curricula Initiative (PCI)
Motivation

Evaluate the submissions clarity of purpose and alignment with the scope of the SIGCSE TS.

  • The submission provides a clear motivation for the work.
  • The submission states a set of clear Research Questions or Specific Aims/Goals.
  • The submission provides a clear motivation for the work.
  • Objectives or goals of the experience report are clearly stated, with an emphasis on contextual factors that help readers interpret the work.
  • ERT submissions need not be framed around a set of research questions or theoretical frameworks.
  • The submission provides a clear motivation for the work.
  • Objectives or goals of the position or curricula initiative are clearly stated, and speak to issues beyond a single course or experience
  • Submissions focused on curricula, programs, or degrees should describe the motivating context before the new initiative was undertaken.
  • PCI papers may or may not ground the work in theory or research questions.
Prior and Related Work

Evaluate the use of prior literature to situate the work, highlight its novelty, and interpret its results.

  • Discussion of prior and related work (e.g., theories, recent empirical findings, curricular trends) to contextualize and motivate the research is adequate
  • The relationship between prior work and the current study is clearly stated
  • The work leverages theory where appropriate.
  • Discussion of prior and related work to contextualize and motivate the experience report is adequate
  • The relationship between prior work and the experience or tool is clearly stated
  • Discussion of prior and related work to contextualize and motivate the position or initiative is adequate
  • The relationship between prior work and the proposed initiative or position is clearly stated
Approach

Evaluate the transparency and soundness of the approach used in the submission relative to its goals.

  • Study methods and data collection processes are transparent and clearly described.
  • The methodology described is a valid/sound way to answer the research questions posed or address the aims of the study identified by the authors.
  • The submission provides enough detail to support replication of the methods.
  • For tool focused papers: Is the design of the tool appropriate for its stated goals? Is the context of its deployment clearly described?
  • For experience report papers: Is the experience sufficiently described to understand how it was designed/executed and who the target learner populations were?
  • For all papers: To what extent does the paper provide reasonable mechanisms of formative assessment about the experience or tool?
  • The submission uses an appropriate mechanism to present and defend its stated position or curriculum proposal (this may include things like a scoping review, secondary data analysis, program evaluation, among others).
  • As necessary, the approach used is clearly described.
  • PCI papers leveraging a literature-driven argument need not necessarily use a systematic review format, though it may be appropriate for certain types of claims.
Evidence

Evaluate the extent to which the submission provides adequate evidence to support its claims.

  • The analysis & results are clearly presented and aligned with the research questions/goals.
  • Qualitative or quantitative data is interpreted appropriately.
  • Missing or noisy data is addressed.
  • Claims are well supported by the data presented.
  • The threats to validity and/or study limitations are clearly stated
  • The submission provides rich reflection on what did or didn’t work, and why
  • Evidence presented in ERT papers is often descriptive or narrative in format, and may or may not be driven by explicit motivating questions.
  • Claims about the experience or tool are sufficiently scoped within the bounds of the evidence presented.
  • PCI papers need not present original data collection, but may leverage other forms of scholarly evidence to support the claims made.
  • Evidence presented is sufficient for defending the position or curriculum initiative
  • Claims should be sufficiently scoped relative to the type of evidence presented.
Contribution & Impact

Evaluate the overall contribution to computing education made by this submission.

  • All CER papers should advance our knowledge of computing education
  • Quantitative research should discuss generalizability or transferability of findings beyond the original context.
  • Qualitative research should add deeper understanding about a specific context or problem
  • For novel projects, the contribution beyond prior work is explained
  • For replications, the contribution includes a discussion on the implications of the new results–even if null or negative–when compared to prior work
  • Why the submission is of interest to SIGCSE community is clearly explained
  • The work enables adoption by other practitioners
  • The work highlights the novelty of the experience or tool presented
  • The implications for future work/use are clearly stated
  • The work presents a coherent argument about a computing education topic, including, but not limited to curriculum or program design, practical and social issues facing computing educators, and critiques of existing practices
  • The submission offers new insights about broader concerns to the computing education community or offers guidance for adoption of new curricular approaches.
Presentation

Evaluate the writing quality with respect to expectations for publication, allowing for only minor revisions prior to final submission.

  • The presentation (writing, graphs, or diagrams) is clear
  • Overall flow and organization are appropriate
  • The presentation (writing, graphs, or diagrams) is clear
  • Overall flow and organization are appropriate
  • The presentation (writing, graphs, or diagrams) is clear
  • Overall flow and organization are appropriate

Example papers

There are many resources for writing high quality papers for submission to the SIGCSE Technical Symposium. We encourage authors to read and evaluate papers from a prior SIGCSE Technical Symposium, especially those designated as best papers, which were selected both due to content and high quality reporting.

Here are the best papers from SIGCSE TS 2023 as examples that showcase the difference between the three paper tracks.

Computing Education Research (CER)

  • Geoffrey L. Herman, Shan Huang, Peter A. Peterson, Linda Oliva, Enis Golaszewski, and Alan T. Sherman. 2023. Psychometric Evaluation of the Cybersecurity Curriculum Assessment. In Proceedings of the 54th ACM Technical Symposium on Computer Science Education V. 1 (SIGCSE 2023). Association for Computing Machinery, New York, NY, USA, 228–234. https://dl.acm.org/doi/10.1145/3545945.3569762

  • Rachel Harred, Tiffany Barnes, Susan R. Fisk, Bita Akram, Thomas W. Price, and Spencer Yoder. 2023. Do Intentions to Persist Predict Short-Term Computing Course Enrollments: A Scale Development, Validation, and Reliability Analysis. In Proceedings of the 54th ACM Technical Symposium on Computer Science Education V. 1 (SIGCSE 2023). Association for Computing Machinery, New York, NY, USA, 1062–1068. https://dl.acm.org/doi/10.1145/3545945.3569875

  • Eric J. Mayhew and Elizabeth Patitsas. 2023. Critical Pedagogy in Practice in the Computing Classroom. In Proceedings of the 54th ACM Technical Symposium on Computer Science Education V. 1 (SIGCSE 2023). Association for Computing Machinery, New York, NY, USA, 1076–1082. https://dl.acm.org/doi/10.1145/3545945.3569840

Experience Reports and Tools (ERT)

  • Bailey Flanigan, Ananya A. Joshi, Sara McAllister, and Catalina Vajiac. 2023. CS-JEDI: Required DEI Education, by CS PhD Students, for CS PhD Students. In Proceedings of the 54th ACM Technical Symposium on Computer Science Education V. 1 (SIGCSE 2023). Association for Computing Machinery, New York, NY, USA, 87–93. https://dl.acm.org/doi/10.1145/3545945.3569733
  • Gloria Ashiya Katuka, Yvonika Auguste, Yukyeong Song, Xiaoyi Tian, Amit Kumar, Mehmet Celepkolu, Kristy Elizabeth Boyer, Joanne Barrett, Maya Israel, and Tom McKlin. 2023. A Summer Camp Experience to Engage Middle School Learners in AI through Conversational App Development. In Proceedings of the 54th ACM Technical Symposium on Computer Science Education V. 1 (SIGCSE 2023). Association for Computing Machinery, New York, NY, USA, 813–819. https://dl.acm.org/doi/10.1145/3545945.3569864
  • Lisa Zhang, Bogdan Simion, Michael Kaler, Amna Liaqat, Daniel Dick, Andi Bergen, Michael Miljanovic, and Andrew Petersen. 2023. Embedding and Scaling Writing Instruction Across First- and Second-Year Computer Science Courses. In Proceedings of the 54th ACM Technical Symposium on Computer Science Education V. 1 (SIGCSE 2023). Association for Computing Machinery, New York, NY, USA, 610–616. https://dl.acm.org/doi/10.1145/3545945.3569729

Position and Curricula Initiative (PCI)

  • Brett A. Becker, Paul Denny, James Finnie-Ansley, Andrew Luxton-Reilly, James Prather, and Eddie Antonio Santos. 2023. Programming Is Hard - Or at Least It Used to Be: Educational Opportunities and Challenges of AI Code Generation. In Proceedings of the 54th ACM Technical Symposium on Computer Science Education V. 1 (SIGCSE 2023). Association for Computing Machinery, New York, NY, USA, 500–506. https://dl.acm.org/doi/10.1145/3545945.3569759
  • Muwei Zheng, Nathan Swearingen, Steven Mills, Croix Gyurek, Matt Bishop, and Xukai Zou. 2023. Case Study: Mapping an E-Voting Based Curriculum to CSEC2017. In Proceedings of the 54th ACM Technical Symposium on Computer Science Education V. 1 (SIGCSE 2023). Association for Computing Machinery, New York, NY, USA, 514–520. https://dl.acm.org/doi/10.1145/3545945.3569811

Additional Resources

Below, we list additional resources that you may find useful as you write your papers, especially computing education research papers.

Language Editing Assistance

ACM has partnered with International Science Editing (ISE) to provide language editing services to ACM authors. ISE offers a comprehensive range of services for authors including standard and premium English language editing, as well as illustration and translation services. Editing services are at author expense and do not guarantee publication of a manuscript.

Additional details are in the instructions for authors.

Getting ready

  • Read over the tab called “Choosing a Track” to be certain that you have chosen the appropriate track for submission of your paper. Refer to the track descriptions on the About tab
  • Make sure that all authors have obtained an ORCiD identifier. These identifiers may be required for paper submission.
  • Check the author list carefully now and review with your co-authors. The authors on the submission must be the same as the authors on the final version of the work (assuming the work is accepted). Authors may not be added or removed after submission and must also appear in the same order as in the submission.
  • Identify at least one author who is willing to review for the symposium. Have that author or those authors sign up to review at https://tinyurl.com/review-sigcse25. (If they’ve done so already, there is no need to fill out the form a second time.) Researchers listed as co-authors on three or more submissions must volunteer to review. (Undergraduate co-authors are exempt from this requirement.)
  • Download the appropriate template. Check this Sample Paper Submission with Notes that has some notes/tips and shows the required sections.
  • Review the additional resources for the track.
  • Review the instructions for reviewers and the review forms to see what reviewers will be looking for in your submission.
  • Look at the list of topics in the Info menu on this site or on EasyChair and pick 3-7 appropriate topics for your submission. This helps in matching reviewers’ expertise with submissions and is different from the next item.
  • Make certain that you have entered CCS concepts in your paper by choosing them from the ACM Computing Classification System site.
  • Look at the EasyChair submission page to make sure you’ll be prepared to fill everything out. Note that you are permitted to update your submission until the deadline, so it is fine to put draft information there as you get ready.

The abstract on EasyChair

Note: EasyChair does not let you save incomplete submission forms. Please fill out all of the fields in one sitting and save them. After that, you can continue to update the information in the fields and your submission until the deadline.

  • Select the appropriate paper track for your paper
  • Submit a 250-word abstract by 11:59 p.m. AOE, Sunday, 14 July 2024.
  • IMPORTANT: as you enter the author names in EasyChair consider the order. Author lists can NOT be modified (this includes add/remove/reorder)

The paper on EasyChair

This page captures the reviewing policies of the papers tracks at SIGCSE TS. Please email the Program Chairs at program@sigcse2025.sigcse.org with comments or questions.

There are three different paper types at SIGCSE TS : Computing Education Research (CER), Experience Reports and Tools (ERT), and Position and Curricula Initiative (PCI). When authors submit a paper, they have to select to submit to one of the three different types of papers.

Timeline

Reviewing Phase Start Date End Date
Bidding Monday, 15 July 2024 Thursday, 1 August 2024
Reviewing Monday, 5 August 2024 Wednesday, 21 August 2024
Discussion & Recommendations   Thursday, 22 August 2024   Thursday, 29 August 2024

Note: Associate Program Chair (APC) Recommendation and Meta-Review Deadline: 11:59 p.m. Friday, 30 August 2024 anywhere on earth (AOE)

EasyChair

The review process for SIGCSE TS 2025 will be done using the EasyChair submission system (https://easychair.org/my/conference?conf=sigcsets2025) .

Preparing to Bid in EasyChair

Reviewers will be invited to join/login into EasyChair. Once you have accepted your invitation, you should update your profile, select topics you are most qualified to review, and identify conflicts of interest.

Selecting topics: Select SIGCSE TS 2025 > Conference > My topics from the menu and select at about five topics you are most qualified to review. Please select no more than seven topics; more topics make it harder for the EasyChair system to make a good set of matches.

Conflicts of interest: Reviewers also identify their Conflicts of Interest by selecting SIGCSE TS 2025 > Conference > My Conflicts.

Reviewing in EasyChair

To review a paper.

Select “PC member (Paper - Experience Reports and Tools)” in the SIGCSE TS 2025 area

  • Log in to EasyChair.
  • In the EasyChair menu, select “My Recent Roles”
  • Select your PC member role in the SIGCSE TS 2025 area
  • Select Reviews > Assigned to Me
  • Click on the Adobe PDF icon that corresponds to the paper. Doing so will give you access to the paper.
  • Make sure you’ve looked over the review criteria.
  • Click on the “Information” link (the I in a blue circle) associated with the paper.
  • Click on “Add Review” in the upper-right-hand corner
  • Enter your answers in a text editor or word processor. (EasyChair times out.)
  • Copy your answers over to EasyChair.

To update your review.

  • Select Reviews > Assigned to Me
  • Click on the appropriate link in the “Update Review” column.

You might also want to click on “Show Reviews”, where you can see other reviews and comments, update your review, and add a comment.

Roles in the Review Process

  • Reviewers write reviews of their assigned submissions, evaluating them against the review criteria.
  • Associate Program Chairs (APCs) write meta-review for their assigned submissions and provide a recommendation (accept/reject) and feedback to the Program Chairs.
  • Program Chairs make the final decisions on the program based on recommendations from the APCs (for papers) and from track chairs (for other tracks).

SIGCSE TS has three Program Chairs, each of whom serves a two-year term. Nominations for Program Chairs are solicited by the SIGCSE TS steering committee, which makes recommendations to the SIGCSE Board. Program Chairs are appointed by the SIGCSE board.

The Program Chairs invite and appoint the Reviewers and APCs. The number of submissions per Reviewer/APC depends on the number of volunteers and the size of the submissions pool.

The goals is for each paper submission to receive at least three reviews and a meta-review. All reviews are submitted through the submission system. In EasyChair, Reviewers are considered “Ordinary PC members” and APCs are considered “Senior PC members”.

Paper Reviewing Guidelines (CER, ERT, and PCI)

There are three different paper types at SIGCSE TS : Computing Education Research (CER), Experience Reports and Tools (ERT), and Position and Curricula Initiative (PCI). Reviewers are assigned to a specific paper track (e.g. a reviewer in the CER track will only be assigned to review papers in that track). This is to avoid confusion and for reviewers to get familiar with the guidelines for their specific paper track.

All papers will be considered relative to criteria for motivation, use of prior/related work, approach, evidence, contribution/impact, and presentation. Each track has guidance about how reviewers should consider these criteria relative to the goal of the track, and each paper must be evaluated using the criteria for the track to which it is submitted. A paper will not be moved between the three paper tracks.

The following table illustrates how to interpret the review criteria for each of the three tracks of papers. Please refer to this table to help better understand the emphases or characteristics of the track for which you will be reviewing. For convenience, you may also download a PDF copy of the paper review criteria.

Criteria Computing Education Research (CER) Experience Reports & Tools (ERT) Position & Curricula Initiative (PCI)
Motivation

Evaluate the submissions clarity of purpose and alignment with the scope of the SIGCSE TS.

  • The submission provides a clear motivation for the work.
  • The submission states a set of clear Research Questions or Specific Aims/Goals.
  • The submission provides a clear motivation for the work.
  • Objectives or goals of the experience report are clearly stated, with an emphasis on contextual factors that help readers interpret the work.
  • ERT submissions need not be framed around a set of research questions or theoretical frameworks.
  • The submission provides a clear motivation for the work.
  • Objectives or goals of the position or curricula initiative are clearly stated, and speak to issues beyond a single course or experience
  • Submissions focused on curricula, programs, or degrees should describe the motivating context before the new initiative was undertaken.
  • PCI papers may or may not ground the work in theory or research questions.
Prior and Related Work

Evaluate the use of prior literature to situate the work, highlight its novelty, and interpret its results.

  • Discussion of prior and related work (e.g., theories, recent empirical findings, curricular trends) to contextualize and motivate the research is adequate
  • The relationship between prior work and the current study is clearly stated
  • The work leverages theory where appropriate.
  • Discussion of prior and related work to contextualize and motivate the experience report is adequate
  • The relationship between prior work and the experience or tool is clearly stated
  • Discussion of prior and related work to contextualize and motivate the position or initiative is adequate
  • The relationship between prior work and the proposed initiative or position is clearly stated
Approach

Evaluate the transparency and soundness of the approach used in the submission relative to its goals.

  • Study methods and data collection processes are transparent and clearly described.
  • The methodology described is a valid/sound way to answer the research questions posed or address the aims of the study identified by the authors.
  • The submission provides enough detail to support replication of the methods.
  • For tool focused papers: Is the design of the tool appropriate for its stated goals? Is the context of its deployment clearly described?
  • For experience report papers: Is the experience sufficiently described to understand how it was designed/executed and who the target learner populations were?
  • For all papers: To what extent does the paper provide reasonable mechanisms of formative assessment about the experience or tool?
  • The submission uses an appropriate mechanism to present and defend its stated position or curriculum proposal (this may include things like a scoping review, secondary data analysis, program evaluation, among others).
  • As necessary, the approach used is clearly described.
  • PCI papers leveraging a literature-driven argument need not necessarily use a systematic review format, though it may be appropriate for certain types of claims.
Evidence

Evaluate the extent to which the submission provides adequate evidence to support its claims.

  • The analysis & results are clearly presented and aligned with the research questions/goals.
  • Qualitative or quantitative data is interpreted appropriately.
  • Missing or noisy data is addressed.
  • Claims are well supported by the data presented.
  • The threats to validity and/or study limitations are clearly stated
  • The submission provides rich reflection on what did or didn’t work, and why
  • Evidence presented in ERT papers is often descriptive or narrative in format, and may or may not be driven by explicit motivating questions.
  • Claims about the experience or tool are sufficiently scoped within the bounds of the evidence presented.
  • PCI papers need not present original data collection, but may leverage other forms of scholarly evidence to support the claims made.
  • Evidence presented is sufficient for defending the position or curriculum initiative
  • Claims should be sufficiently scoped relative to the type of evidence presented.
Contribution & Impact

Evaluate the overall contribution to computing education made by this submission.

  • All CER papers should advance our knowledge of computing education
  • Quantitative research should discuss generalizability or transferability of findings beyond the original context.
  • Qualitative research should add deeper understanding about a specific context or problem
  • For novel projects, the contribution beyond prior work is explained
  • For replications, the contribution includes a discussion on the implications of the new results–even if null or negative–when compared to prior work
  • Why the submission is of interest to SIGCSE community is clearly explained
  • The work enables adoption by other practitioners
  • The work highlights the novelty of the experience or tool presented
  • The implications for future work/use are clearly stated
  • The work presents a coherent argument about a computing education topic, including, but not limited to curriculum or program design, practical and social issues facing computing educators, and critiques of existing practices
  • The submission offers new insights about broader concerns to the computing education community or offers guidance for adoption of new curricular approaches.
Presentation

Evaluate the writing quality with respect to expectations for publication, allowing for only minor revisions prior to final submission.

  • The presentation (writing, graphs, or diagrams) is clear
  • Overall flow and organization are appropriate
  • The presentation (writing, graphs, or diagrams) is clear
  • Overall flow and organization are appropriate
  • The presentation (writing, graphs, or diagrams) is clear
  • Overall flow and organization are appropriate

Review Process Steps

Step 1: Authors submit Abstracts of Papers

Authors submit a title and abstract one week prior to the full paper deadline. Authors are allowed to revise their title, abstract, and other information before the full paper submission deadline.

Step 2: Reviewers and APCs Bid for Papers

Reviewers and APCs select topics they feel most qualified to review. This helps the system prioritize papers.

Reviewers and APCs are then asked to select a set of papers for which they have sufficient expertise (we call this “bidding”). The Program Chairs assign papers based on these bids. The purpose of bidding is NOT to express interest in papers you want to read. It is to express your expertise and eligibility for fairly evaluating the work. These are subtly but importantly different purposes. We ask reviewers and APCs to select more papers than they plan to review so that we can best ensure that every paper has at least three reviewers.

  • Make sure to specify all of your Conflicts of Interest.
  • Bid on all of the papers you believe you have sufficient expertise to review.
  • Do NOT bid on papers about topics, techniques, or methods that you oppose.

Step 3: Authors submit Full Papers

Submissions of the full papers are due one week after the abstracts are due. As indicated in the Instructions for Authors, submissions are supposed to be sufficiently anonymous so that the reviewer cannot determine the identity or affiliation of the authors. The main purpose of the anonymous reviewing process is to reduce the influence of potential (positive or negative) biases on reviewers’ assessments. You should be able to review the work without knowing the authors or their affiliations. Do not try to find out the identity of authors. When in doubt, please contact the Program Chairs.

Step 4: Program Chairs Decide on Desk Rejects

The Program Chairs will quickly review each paper submission to determine whether it violates anonymization requirements, length restrictions, or plagiarism policies. Authors of desk-rejected papers will be notified immediately. The Program Chairs may not catch every issue. If you see something during the review process that you believe should be desk rejected, contact the Program Chairs at program@sigcse2025.sigcse.org before you write a review. The Program Chairs will make the final judgment about whether something is a violation, and give you guidance on whether and if so how to write a review. Note that Program Chairs with conflicts of interest are excluded from deciding on desk-rejected papers, leaving the decision to the other Program Chairs.

Step 5: Program Chairs Assign Reviewers and APCs

Based on the bids and their judgment, the Program Chairs will collaboratively assign at least three Reviewers and one APC (meta-reviewer) for each paper submission. The Program Chairs will be advised by the submission system assignment algorithm, which depends on all bids being high quality. For the reviewer assignments to be fair and good, the reviewer bids should only be based on expertise and eligibility. Interest alone is not sufficient for bidding to review a paper. Reviewing assignments can only be made by a Program Chair without a conflict of interest.

Step 6a: Reviewers Review Papers

Assigned Reviewers submit their anonymous reviews by the review deadline, reviewing each of their assigned submissions against the Paper Reviewing Guidelines (CER, ERT, and PCI). We strongly recommend that you prepare your rationale in a separate document; EasyChair has been known to time out.

Note that Reviewers must NOT include accept or reject decisions in their review text. (They will indicate accept/reject recommendations separately.)

Due to the internal and external (publication) deadlines, we generally cannot give reviewers or APCs extensions. Note that reviewers, meta-reviewers, and Program Chairs with conflicts cannot see any of the reviews of the papers for which they have conflicts of interest during this process.

Step 6b: APCs and Program Chairs Monitor Review Progress

APCs and Program Chairs periodically check in to ensure that progress is being made. If needed, reminders are emailed to the reviewers with the expectations and timelines. If needed, the Program Chairs recruit emergency reviewers if any of the submissions do not have a sufficient number of reviews, if there is lots of variability in the reviews, or if an expert review is needed.

Step 7: Discussion between Reviewers and APCs

The discussion period provides the opportunity for the Reviewers and the APCs to discuss the reviews and reach an agreement on the quality of the submission relative to the expectations for the track to which it was submitted. The APCs are expected to take leadership role and moderate the discussion. Reviewers are expected to engage in the discussion when prompted by other Reviewers and/or by the APCs by using the Comments feature of EasyChair.

During the discussion period, Reviewers are able to revise their reviews but are NOT required to do so. It is important that at no point Reviewers feel forced to change their reviews, scores, or viewpoints in this process. The APC can disagree with the reviewers and communicate this to the Program Chairs if needed. Everyone is asked to do the following:

  • Read all the reviews of all papers assigned (and re-read your own reviews).
  • Engage in a discussion about sources of disagreement.
  • Use the Paper Reviewing Guidelines (CER, ERT and PCI) to guide your discussions.
  • Be polite, friendly, and constructive at all times.
  • Be responsive and react as soon as new information comes in.
  • Remain open to other reviewers shifting your judgments.
  • Explicitly state any clarifying questions that could change your evaluation of the paper

At the end of the discussion period, the APCs should have enough feedback so that they can make a recommendation for acceptance or rejection to the Program Chairs. This recommendation should be based on their own reading of the reviews and discussion, not simply on the overall score.

Step 8: APCs Write Meta-Reviews

Toward the end of the discussion period, APCs use the reviews, the discussion, and their own evaluation of the submission to write a meta-review and a recommendation for the Program Chairs. A meta-review should summarize the key strengths and weaknesses of the submission, in light of the Paper Reviewing Guidelines (CER, ERT, and PCI) and explain how these led to their recommendation decision. APCs are encouraged to also include their review/feedback in the meta-review. The summary and explanation should help the authors in revising their work where appropriate. The meta-review must constructively summarize all reviews and the discussion as well as summarize any open questions and doubts. A generic meta-review (“After long discussion, the reviewers decided that the paper is not up to standards, and therefore rejected the paper”) is not sufficient.

APCs do not include their recommendation for acceptance or rejection of a paper in their meta-review because they only see a small portion of the submitted papers. Instead, the APCs are asked to make a recommendation of accept or reject to the Program Chairs via the submission system. If however, the Reviewers had differing views and a consensus could not be reached, then the APC captures the essence of all reviews and leaves their recommendation as neutral, and the submission is then further discussed by the Program Chairs.

Recommendations should NOT be based only on scores. For example, an APC may decide to recommend rejection for a paper with three weak accepts, but recommend acceptance for a paper with two accepts and one strong reject (or vice versa)

Step 9: Program Chairs Make Decisions & Notify Authors

Before announcing decisions, the Program Chairs go through all the submissions and read all the reviews and meta-reviews to ensure clarity and consistency with the review process and its criteria as possible. This is done via synchronous meetings of the Program Chairs. APCs are consulted if needed. The Chairs make decisions based on recommendations and their own expertise as well as a desire to provide an appropriately varied program.

The Program Chairs then notify all authors of the decisions about their papers via the submission system.

Step 10: Evaluation

The Evaluation Chairs send out surveys to authors, reviewers, and APCs. Please take the time to respond to these surveys, as they inform processes and policies for future SIGCSE Technical Symposia.

The Program Chairs also request feedback from the APCs on the quality of reviews as a metric to be used for future invitations to review for the SIGCSE Technical Symposium.

We will do our best to identify a small set of exceptional reviewers who will receive reviewing awards at the symposium.

Conflicts of Interest

SIGCSE TS takes conflicts of interest, both real and perceived, quite seriously. The conference adheres to the ACM conflict of interest policy (https://www.acm.org/publications/policies/conflict-of-interest) as well as the SIGCSE conflict of interest policy (https://sigcse.org/policies/COI.html). These state that a paper submitted to the SIGCSE TS is a conflict of interest for an individual if at least one of the following is true:

  • The individual is a co-author of the paper
  • A student of the individual is a co-author of the paper
  • The individual identifies the paper as a conflict of interest, i.e., that the individual does not believe that they can provide an impartial evaluation of the paper.

The following policies apply to conference organizers:

  • The Program Chairs are not allowed to submit to any track.
  • The chairs of any track are not allowed to submit to that specific track.
  • All other conference organizers are allowed to submit to any track.
  • All reviewers (PC members) and meta-reviewers (APC members) are allowed to submit to any track.

No reviewer, meta-reviewer, or chair with a conflict of interest in the paper will be included in any evaluation, discussion, or decision about the paper. It is the responsibility of the reviewers, meta-reviewers, and chairs to declare their conflicts of interest throughout the process. The corresponding actions are outlined below for each relevant step of the reviewing process. It is the responsibility of the chairs to ensure that no reviewer or meta-reviewer is assigned a role in the review process for any paper for which they have a conflict of interest.

Recalcitrant Reviewers

Reviewers who don’t submit reviews, have reviews with limited constructive feedback, do not engage effectively in the discussion phase, or submit inappropriate reviews will be removed from the reviewer list (as per SIGCSE policy). Recalcitrant reviewers will be informed of their removal from the reviewer list. Reviewers with repeated offenses (two within a three-year period) will be removed from SIGCSE reviewing for three years.

These are some of the more common questions (and categories of questions) the Program Chairs have received. Please look over these questions in advance of reviewing. If you have a question not covered here (or even if you have a question about the questions covered here), please reach out to the program chairs at program@sigcse2025.sigcse.org.

Anonymity

General principle: We expect authors to make a good-faith effort to make their papers anonymous. We will not reject papers because it is possible with some sleuthing to discover their authors. If you do discover the authors’ identities, do your best to ignore them.

I was looking up aspects of this paper on the Web and found a copy of the paper on ArXiV (or other online archive) with the authors’ names listed. Does this break anonymity?
No. ACM Policy indicates that authors may submit works under review to online archives.
I see the name “Trovato” in the header of the document. Is this the name of one of the authors, thereby breaking anonymity?
No. “Trovato” is one of the default names in the ACM LaTeX template. You can feel free to ignore the name.
The name of the institution is mentioned in the text of the paper. Does this break anonymity?
Yes. Do your best to review the paper as if you did not know the authors and include a confidential comment in your review indicating this issue.
The name of the project is mentioned in the text of the paper. When I searched for the project on the Web so that I could better understand it, I discovered who the authors were.
Ideally, the authors should have anonymized the name of the project. Do your best to review the paper as if you did not know the authors and include a confidential comment in your review indicating this issue.

Human Subject Protection

General principle: We expect members of our community to follow high standards for the protection of human subjects. In particular, All authors submitting to SIGCSE TS are responsible for adhering to the ACM Publications Policy on Research Involving Human Participants and Subjects.

However, different countries and different institutions have different policies or interpretations of policies. For example, US policies recently changed to exempt normal classroom activities as long as they do not affect student learning. Different institutions have interpreted that exemption in multiple ways and have different processes for obtaining that exemption.

In general, reviewers should assume that authors are telling the truth when they indicate that a study is exempt from review by the local IRB/ethics board. Nonetheless, if a reviewer has any concern about human subjects protection in a study, they should reach out to their APC and the Program Chairs.

The paper includes a study of students but indicates that “the work does not directly involve human participants”. Is that okay?
A study that involves students might be exempt from review, but it does involve human participants. Please reach out to your APC and the Program Chairs so that we can clarify this issue. Then review the paper as if the work is acceptable.
The authors note that the project is exempt from review, but I have trouble believing that. It certainly wouldn’t be at my institution.
Policies vary between countries and their interpretation varies between institutions. Nonetheless, if you are worried, please reach out to your APC and the Program Chairs so that we can clarify this issue. Then review the paper as if the work is acceptable.
I am concerned that this study could cause harm to the participants.
Please reach out to your APC and the Program Chairs.

Plagiarism, including self plagiarism

I am concerned that this paper is too close to another paper I have seen (or am reviewing).
Please reach out to your APC and the Program Chairs so that we can explore the issue.Then review the paper as if the work is acceptable. Note that authors can (confidentially) tell the Program Chairs about potential overlaps between papers and it is the Program Chairs’ responsibility to determine whether such overlaps are acceptable.
The running header for this paper appears to be for an earlier iteration of the SIGCSE Technical Symposium. I am concerned that this work may be recycled.
Authors are certainly permitted to update and resubmit papers that were not accepted. Authors have also been known to reuse prior submissions as a template. In some such cases, they neglect to update the header. We find that these are the most common reasons we see headers that indicate a prior conference. However, if you are concerned that the content is recycled from an accepted paper, please reach out to your APC and the Program Chairs.

Generative AI

Projects involving generative AI
The authors built a system using data that they did not generate. They do not seem to have obtained permission to do so. What should I do?
SIGCSE TS requires that authors obtain permission to use other people’s data and to explicitly indicate this in the acknowledgements section. Please reach out to your APC and the Program Chairs so that we can clarify this issue. Then review the paper as if the work is acceptable.
Authors’ use of generative AI
I believe that the authors used ChatGPT, Google Translate, or other tool in writing this paper. However, they have not acknowledged this use.
ACM policy permits authors to use generative AI tools but requires that they acknowledge the use of such tools. Please reach out to your APC and the Program Chairs so that we can clarify this issue. Then review the paper as if the work is acceptable. You may also indicate your concerns in the review, but please clarify that your concerns did not affect your overall rating (unless the tools led to poor writing).
I am worried that some of the references are fake, perhaps generated by a tool.
Please reach out to your APC and the Program Chairs ASAP. Then review the paper as if the work is acceptable.
Reviewers’ use of generative AI

Please refer to the general AI policies for some background.

May I use ChatGPT or other Generative AI tool to write my reviews?
No. It is a violation of ACM policies to feed the authors’ text into an online tool.
Can I use the Google “Help Me Write” tool, Microsoft writing tools, Grammarly, or other similar software?
Yes.
I’m worried that some text in this paper plagiarizes text from elsewhere. May I use TurnItIn or similar software to check?
No. If you have such concerns, please reach out to your APC and the Program Chairs.

Track choice

This paper was submitted to XXX but I think it belongs in YYY.
We do not switch papers between tracks. Please review the paper according to the criteria of the track the authors selected. You may certainly raise your concern about choice of track during the discussion and you can also include a comment in the confidential notes to the Program Chairs.

Concerns about other reviewers

I think another reviewer’s comments are overly harsh.
Please mention that during the discussion. (Please be polite in doing so.) If the other reviewer does not respond, reach out to the APC.
I think another reviewer’s reviews were generated by ChatGPT or other tool.
Please reach out to your APC or the Program Chairs. Do not accuse another reviewer directly.
I am concerned that another reviewer’s comments are inappropriate.
If you are comfortable doing so, please mention that during the discussion. If not, please reach out to the APC or the Program Chairs, who can then raise the issue with the other reviewer.

The approximate text from the review form follows.

Note that not all reviewer responses are available to authors.

Common Introductory Fields

Summary: Please provide a brief summary of the submission, its audience, and its main point(s), with respect to the review criteria of this track. Refer to the Table on the SIGCSE TS 2025 website (i.e., Instructions for Reviewers) to familiarize yourself with the review criteria for the appropriate track: (1) Computing Education Research, (2) Experience Reports and Tools, and (3) Position and Curricula Initiatives.

Familiarity: Rate your personal familiarity with the topic area of this submission in relation to your research or practical experience.

  • None - I have never reviewed or written a paper or otherwise have experience in this area
  • Low - I have read papers or otherwise have slight experience in this area
  • Medium - I have reviewed papers or otherwise have some experience in this area
  • High - I have written and reviewed papers or otherwise have moderate experience in this area
  • Expert - I have written and reviewed many papers or otherwise have extensive experience in this area

Computing Education Research

Motivation (CER): Evaluate the submission’s clarity of purpose and alignment with the scope of the SIGCSE TS.

  • The submission provides a clear motivation for the work.
  • The submission states a set of clear Research Questions or Specific Aims/Goals.

Prior and Related Work (CER): Evaluate the use of prior literature to situate the work, highlight its novelty, and interpret its results.

  • Discussion of prior and related work (e.g., theories, recent empirical findings, curricular trends) to contextualize and motivate the research is adequate.
  • The relationship between prior work and the current study is clearly stated.
  • The work leverages theory where appropriate.

Approach (CER): Evaluate the transparency and soundness of the approach used in the submission relative to its goals.

  • Study methods and data collection processes are transparent and clearly described.
  • The methodology described is a valid/sound way to answer the research questions posed or address the aims of the study identified by the authors.
  • The submission provides enough detail to support replication of the methods.

Evidence (CER): Evaluate the extent to which the submission provides adequate evidence to support its claims.

  • The analysis & results are clearly presented and aligned with the research questions/goals.
  • Qualitative or quantitative data is interpreted appropriately.
  • Missing or noisy data is addressed.
  • Claims are well supported by the data presented.
  • The threats to validity and/or study limitations are clearly stated.

Contribution & Impact (CER): Evaluate the overall contribution to computing education made by this submission.

  • All CER papers should advance our knowledge of computing education.
  • Quantitative research should discuss generalizability or transferability of findings beyond the original context.
  • Qualitative research should add deeper understanding about a specific context or problem.
  • For novel projects, the contribution beyond prior work is explained.
  • For replications, the contribution includes a discussion on the implications of the new results–even if null or negative–when compared to prior work.

Presentation (CER): Evaluate the writing quality with respect to expectations for publication, allowing for only minor revisions prior to final submission.

  • The presentation (e.g., writing, grammar, graphs, diagrams) is clear.
  • Overall flow and organization are appropriate.

Experience Reports and Tools

Motivation (ERT) Evaluate the submission’s clarity of purpose and alignment with the scope of the SIGCSE TS.

  • The submission provides a clear motivation for the work.
  • Objectives or goals of the experience report are clearly stated, with an emphasis on contextual factors that help readers interpret the work.
  • ERT submissions need NOT be framed around a set of research questions or theoretical frameworks.

Prior and Related Work (ERT) Evaluate the use of prior literature to situate the work, highlight its novelty, and interpret its results.

  • Discussion of prior and related work to contextualize and motivate the experience report is adequate.
  • The relationship between prior work and the experience or tool is clearly stated.

Approach (ERT): Evaluate the transparency and soundness of the approach used in the submission relative to its goals.

  • For tool-focused papers: Is the design of the tool appropriate for its stated goals? Is the context of its deployment clearly described?
  • For experience report papers: Is the experience sufficiently described to understand how it was designed/executed and who the target learner populations were?
  • For all papers: To what extent does the paper provide reasonable mechanisms of formative assessment about the experience or tool?

Evidence (ERT): Evaluate the extent to which the submission provides adequate evidence to support its claims.

  • The submission provides rich reflection on what did or didn’t work, and why.
  • Evidence presented in ERT papers is often descriptive or narrative in format, and may or may not be driven by explicit motivating questions.
  • ERT papers may include small-scale studies, but they need not be statistically significant.
  • Claims about the experience or tool are sufficiently scoped within the bounds of the evidence presented.

Contribution & Impact (ERT): Evaluate the overall contribution to computing education made by this submission.

  • Why the submission is of interest to SIGCSE community is clearly explained.
  • The work enables adoption by other practitioners.
  • The work highlights the novelty of the experience or tool presented.
  • The implications for future work/use are clearly stated.

Presentation (ERT): Evaluate the writing quality with respect to expectations for publication, allowing for only minor revisions prior to final submission.

  • The presentation (e.g., writing, grammar, graphs, diagrams) is clear.
  • Overall flow and organization are appropriate.

Position Papers and Curricular Initiatives

Motivation (PCI): Evaluate the submission’s clarity of purpose and alignment with the scope of the SIGCSE TS.

  • The submission provides a clear motivation for the work.
  • Objectives or goals of the position or curricula initiative are clearly stated, and speak to issues beyond a single course or experience.
  • Submissions focused on curricula, programs, or degrees should describe the motivating context before the new initiative was undertaken.
  • PCI papers may or may not ground the work in theory or research questions.

Prior and Related Work (PCI): Evaluate the use of prior literature to situate the work, highlight its novelty, and interpret its results.

  • Discussion of prior and related work to contextualize and motivate the position or initiative is adequate.
  • The relationship between prior work and the proposed initiative or position is clearly stated.

Approach (PCI): Evaluate the transparency and soundness of the approach used in the submission relative to its goals.

  • The submission uses an appropriate mechanism to present and defend its stated position or curriculum proposal (this may include things like a scoping review, secondary data analysis, program evaluation, among others).
  • As necessary, the approach used is clearly described.
  • PCI papers leveraging a literature-driven argument need not necessarily use a systematic review format, though it may be appropriate for certain types of claims.

Evidence (PCI): Evaluate the extent to which the submission provides adequate evidence to support its claims.

  • PCI papers need not present original data collection, but may leverage other forms of scholarly evidence to support the claims made.
  • Evidence presented is sufficient for defending the position or curriculum initiative.
  • Claims should be sufficiently scoped relative to the type of evidence presented.

Contribution & Impact (PCI) Evaluate the overall contribution to computing education made by this submission.

  • The work presents a coherent argument about a computing education topic, including, but not limited to curriculum or program design, practical and social issues facing computing educators, and critiques of existing practices.
  • The submission offers new insights about broader concerns to the computing education community or offers guidance for adoption of new curricular approaches.

Presentation (PCI): Evaluate the writing quality with respect to expectations for publication, allowing for only minor revisions prior to final submission.

  • The presentation (e.g., writing, grammar, graphs, diagrams) is clear.
  • Overall flow and organization are appropriate.

Common Text: Recommendation

Overall evaluation: Please provide a detailed justification that includes constructive feedback that summarizes the strengths & weaknesses of the submission and clarifies your scores. Both the score and the review text are required, but remember that the authors will not see the overall recommendation score (only your review text). You should NOT directly include your preference for acceptance or rejection in your review.

Presentation Details

In-person presentations

TLDR: Each talk is in a session containing four talks. Please check the schedule in the Program menu for when and where your talk will be presented. Please arrive at the beginning of the session. You will need to bring your own laptop and an HDMI connector (e.g., an HDMI dongle for your laptop). New for 2025: Your talk should be 15 minutes with 5 minutes for questions.

Presentation Room & Technology

All presentation rooms will have a podium with a microphone, 16:9 (aspect ratio) projectors and screens, with a single HDMI cable for video, and speakers.

You must bring your own laptop or plan to use someone else’s, the symposium will NOT provide one for you. Please bring with you the appropriate dongle to connect your laptop to HDMI.

Due to technical limitations in the convention center, paper presentations on-site in Pittsburgh will not be live streamed for virtual attendance. Nor will those attending the symposium virtually be able to present live in a physically scheduled paper session.

Presentation Session

New for 2025: There will befour paper presentations in each of the in-person paper sessions. Each paper presentation is a 20-minute block, which is a presentation of 15-minutes followed by 5-minutes for questions and answers. The session chair will introduce the session, and then prior to each paper presentation, will introduce you (the presenter), keep track of time, and provide you with five-minute, two-minute, and one-minute warnings before the question and answer period begins. Please note that the full paper presentation has a 20-minute limit and this is a hard stop time.

Speakers’ Lounge

In-person authors will have access to a speaker’s lounge room throughout the conference. This is a quiet space for you to grab a cup of coffee, meet with your co-authors, prepare for your presentation, or log in to a Zoom call without going back to your hotel room.

Online presentation modality

There are limited slots for presenting a paper online. Requests for presenting over Zoom will be only considered during a short time after paper acceptance. If you indicate you will present in person or do not request an online presentation, then one author must present at the conference venue.

The authors for the Online Papers will present their papers ONLINE over a Zoom Session, which will be streamed live. Therefore, the presentations of the Online Papers can be attended by both In-person Attendees (in rooms in the venue) and Online Attendees (over Zoom).

The Zoom links will be sent to the online paper presenters on the day of their presentation.

Format of Online Presentation Sessions:

There will be four paper presentations in each of the Online Paper sessions. Each paper presentation is a 20-minute block, which is a presentation of 15-minutes followed by 5-minutes for questions and answers. A Session Chair will manage the session with the help of a Student Volunteer.

Session Chair and Student Volunteer Responsibilities:

There will be a wired laptop logged into Zoom at the front of the room. The Session Chair, the Student Volunteer (and possibly a Hybrid Chair) will also be physically in the room and logged into Zoom to make sure that the online audience is muted and the online presenters are made co-hosts and can share their screens.

The Session Chair will introduce the presenter(s) before their presentations. To help presenters manage their time effectively, Session Chairs will use the Zoom Chat option to provide five-minute, two-minute, and one-minute warnings before the question and answer period begins. Please note that each full paper presentation has a 20-minute limit, and this is a hard stop time.

Session Chairs and Student Volunteers will ensure that questions from in-person attendees are relayed to the online presenters. The Online audience can ask their questions by unmuting themselves or through the Zoom chat. The in-person attendees must ask questions by relaying their questions to the Student Volunteer or the Zoom Chat.



Presentation Modality: Due TDB

Authors for all accepted papers must select a mode for presenting at the symposium (online or in-person). The first corresponding author on each paper should receive a survey by email shortly after acceptance notifications are sent. This survey should be completed only once per accepted paper.

Presentation modality selection is required by TDB. If authors do not submit a modality choice by the deadline, the paper will default to in-person presentation modality and will not be assigned to an online session.

Registration:

In order for your paper to be presented at the symposium and included in the proceedings, at least one author must register for the conference. Please let us know immediately if you or your co-authors are unable to present your paper at the symposium so we can withdraw it.

Camera-Ready: Due 17 November 2024

Authors should carefully consider the reviews when preparing final CAMERA-READY submissions. A camera-ready PDF must be submitted to Sheridan Communications for inclusion in the conference proceedings.

  • Authors can find initial instructions for preparing final camera-ready documents here: TBD
  • We also remind authors to review the accessibility tips to ensure the symposium content is widely usable for all parties.

Optional Video Presentations

Authors opting to provide the OPTIONAL video for the ACM DL as described in the camera-ready instructions, must check “YES” for being recorded on the ACM rights review form. If that option is not checked, the video will not be included in the ACM DL. Those who check “YES” will be asked to provide a video file for the ACM DL for the conference proceedings.