Submitting to SIGCSE TS 2026 (#1357)

Topics/tags: Academia

Today is Thursday, July 10, 2025. A week ago, on Thursday, July 3, 2025, I was getting paper submissions ready for SIGCSE TS 2026. How many? My goal was five. I ended up with three. Little of that may make sense to you. Where should I start? Let me see.

For people outside of academia: Part of the academic process is submitting papers and hoping they get published. In some cases, you submit your papers to conferences; in others, you submit articles to journals, anthologies (not as much), or books to book publishers. Different institutions and disciplines suggest different rates of publishing. I like to write at least one published (or publishable) piece each year, but don’t necessarily have to.

For academics outside of Computer Science (CS): Many subfields of CS tend to prioritize conference publication because conference publication has traditionally been more timely than journal publication. In particular, there’s almost always a fixed timeline for reviews, in contrast to journals, which can take a long time to get reviews [1]. Since CS has often been a fast-moving field [2], we like to get work out as quickly as possible. At least, I think that’s it. Anyway, our conference model includes submissions of full papers. For the SIGCSE [3] Technical Symposium, a full paper is six pages of single-spaced, two-column, ten-point text, which ends up being about five thousand words, if I recall correctly [4]. They are then reviewed by multiple reviewers (three to four, for SIGCSE TS) and may also have additional folks making decisions. SIGCSE TS has an Associate Program Chair, who turns the reviews into a recommendation, and a team of Program Chairs, who make the final decision. Acceptance rates vary, but for SIGCSE TS, it’s about 30%. My advisor used to say that, in his experience, it was easier to get a journal paper published than a conference paper, but he worked somewhere on the boundary of logic and programming languages. The papers appear in a proceedings which provides the archival form of the work. We also present them at the conference or symposium.

For academics in the SIGCSE community who haven’t been paying attention: You may wonder why I’m submitting papers at the beginning of July rather than, say, the end of August or even early September [5], after summer research has wrapped up. Many issues have led to the change in SIGCSE TS deadlines. This year, SIGCSE TS is earlier than normal—in mid-February rather than mid-March, so deadlines had to move up a bit. Why is SIGCSE TS earlier? The wonder of conference scheduling is beyond my ken, but I know that our steering committee tried to get it later and couldn’t.

Amonth earlier would suggest a late July deadline, rather than an early-July one. Another thing also happened since SIGCSE TS 2018: The number of submissions has more than doubled. That means that the Program Chairs need at least another week or two to make decisions. After all, the PC chairs have other jobs, too.

That moves us to mid-July. Why early July? I think we’re butting up against deadlines for the folks who publish the proceedings; the earlier conference date means that they want to get the final versions of papers in place before the winter holidays instead of sometime in January. There are probably other factors I’ve forgotten.

For the same group: You may also wonder why I’m using SIGCSE TS rather than SIGCSE to refer to the ACM Technical Symposium on Computer Science. The primary issue is that people started to get confused between the organization (SIGCSE) and the technical symposium (formerly SIGCSE, now SIGCSE TS, sometimes even just The TS). Now that SIGCSE (the organization) sponsors five conferences, it’s important to distinguish between them [6].

For academics in the SIGCSE community: Why was I working on five papers for SIGCSE TS? That’s a lot. I’m generally not one of those people who has a bunch of papers at SIGCSE TS [7]. However, I have a large research group this summer that’s been working on three projects, each of which deserves its own paper. We considered combining two of them into one paper, but they work better separately. I also served as SIGCSE TS chair for the past two years, which meant that I couldn’t submit to SIGCSE TS. There are two topics I’ve been waiting to write about. I was also waiting for time to write.

That should cover the background on everything. The SIGCSE TS deadline was July 3 [8]. I was working on five papers for the deadline. Conference papers are part of the normal scholarly work in CS.

What happened? I finished the three papers on my students’ work. I’m fortunate that they had written most of those papers. I needed to do some re-organization and polishing, along with a bit of writing for parts that were missing, but it seemed to be much less work than I’ve had with some research teams. I’m proud of this summer’s students. I’m glad they wrote so much for another reason: If I had written most of the paper, it would not have been as much their work. Because they took the lead, they approached many parts of the paper differently than I would have. That makes it theirs.

And there we are. I was editing their work on the 3rd. I planned to edit their work, submit it, and then move on to my own. Unfortunately, I work slower than usual these days. Hence, I didn’t finish cleaning up their papers until near to the the deadline. I’d started one of the two other papers, and I made some progress. However, a few hours before the final deadline, I decided that I wouldn’t finish the paper I wanted to submit, and so I put it aside until next year. However, I won’t wait until next year to write it. Rather, I’ll write it sometime over the next month and post it to ArXiV [9]. I hope to do the same with the second paper.

What were the papers? I shouldn’t disclose the subjects of my students’ papers since that would break the anonymous reviewing process [10]. However, I feel comfortable writing something about the other two papers since they’ll end up on ArXiV anyway.

The first—and more important—one is about my experiments with what I call Portfolio Mastering Grading. You can read the corresponding musing to learn a bit about it. Here’s the abstract I submitted the previous week.

Portfolio Mastery Grading: Yet another approach to equitable grading

Over the past few years, we have seen a rise in equitable grading techniques such as Mastery Grading, which often better support students. These techniques share a variety of features, including (a) giving students multiple opportunities to show their understanding, such as allowing students to try a problem or assignment again if they don’t succeed the first time, and (b) providing students with more ownership of their learning.

While there are many approaches to Mastery Grading, most emphasize the pairing of small problems that test individual learning objectives (we refer to these as Learning Assessments (LAs)) along with larger programming assignments. Students typically have the opportunity to retake any missed LAs, with the replacement problems either created manually by faculty or through a problem generator.

In this paper, we describe our experiences (both successes and failures) using a variant of Mastery Grading that we term Portfolio Mastery Grading (PMG) in three sections of a Data Structures and Algorithms Course. In this approach, rather than students answering questions on LAs, they must instead submit work from elsewhere in the class, such as programming assignments or laboratory work, along with a short narrative indicating what their work demonstrates. For example, to assess whether or not students can implement data structures using an array, instead of, say, asking them to complete the push operation for an array-based stack, we would ask them to supply code in which they’ve implemented such a structure and explain the key points of their code.

Oh! Almost forgot. In addition to submitting this to arXiv when I’m finished, I should also submit the idea to the archive of equitable CS grading practices. First, I have to track down where that is.

That’s it for the first paper. The second is very different, and should be more fun, even if it’s less critical [11]. At its heart, that paper is (or will be) a rant about the use of the term CS2. For the vast majority of my career, CS2 has referred to some variant of the traditional CS course in Data Structures and Algorithms. However, in recent years, people are using CS2 to mean other things, including times they put CS2 in the titles of their courses. I got frustrated by the confusion during my time as SIGCSE TS Program Co-Chair (especially since we have a CS2 topic) and wanted to vent that frustration. Here’s the draft abstract.

It’s time to eliminate CS2: A provocation

For nearly five decades, the term CS2 has been part of the common parlance of Computer Science Faculty. For example, a quick dialog on teaching might take the form What text do you use in your CS2? Koffman. You can even label a submission to SIGCSE with the term CS2, thereby guiding the review process.

CS2 was introduced in Curriculum ’78 and emphasized in its followup Recommended Curriculum for CS2, 1984. CS2 was, at its core, a course in data structures (for example, linked lists, stacks, queues, and trees) and introductory algorithms (searching and sorting algorithms and their analysis), along with more substantive study of software development techniques (a disciplined approach to the design, coding, and testing of programs). The association of CS2 with Data Structures and Algorithms remained so strong that even when faculty found they needed to add a course between CS1 and Data Structures, they often referred to it as CS1.5.

Unfortunately, the meaning of the term seems to have fractured. Papers at recent SIGCSE conferences (SIGCSE TS, ITiCSE, CompEd) have used CS2 to mean a first course in object-oriented programming, the second course in the CS major, a course in advanced programming structures, and more.

In this paper, we review the origins of the term CS2 and its multiplicity of meanings, exploring the contrast between early and current uses. As we show, CS2 carries little consistent meaning; it adds confusion, rather than clarity. It is, therefore, time to eliminate CS2 (or at least the term).

Do I have five to six pages worth of ranting to do? Possibly not. We’ll see. No matter how long it ends up, I suppose I could submit it to Inroads, the SIGCSE magazine [12], rather than waiting until next year.

That’s about it. I’m glad to get three papers under review. I think the topics are worthwhile. The papers are decent, but could be better. Fingers crossed!

Wait a minute. I missed something! The papers are decent, but could be better raises an important question. When we [14] teach writing, we tell students that they should be prepared to revise, and revise, and revise some more. Shouldn’t I model good writing habits for my students? In the ideal, I would do so. However, I’d also argue that the paper did have some revising, particularly as we moved from an outline, to drafted text, to the students’ final draft, to my draft. However, more rounds would have helped.

Nonetheless, perfect is the enemy of good, or however that aphorism goes. I know I’m not alone in submitting not-quite-perfect papers at the last minute; I’m pretty sure that half of the TS submission come in within the last day. The early deadline also meant that we had less time for revision than normal. Ideally, the students would have written and revised their versions by the end of July, when summer research ends. I would then have a few weeks in August to update the papers (perhaps with the students’ help).

Oh well. They’re still good ideas and those ideas are presented relatively well. The papers should bring useful new ideas the community. Let’s hope the reviewers feel the same way.

What about those papers that I was writing, not revising, at the last moment? As I said, it’s fairly clear that I’m not alone in waiting until the last moment. I also had outlines and drafts in my head, as it were. And, as one of my offspring suggested, I write well enough that my early written drafts are often fairly good. Musing regularly makes me a better writer. At least, I hope it does.

We’ll see what happens with my drafts. At least I have time to both write and revise!

[1] Journals seem to be getting better now.

[2] Think about how much generative AI has changed in the past year.

[3] Special Interest Group in Computer Science Education.

[4] Eldest Son recently reformatted a conference submission as part of a potential thesis chapter. Once it was in twelve point, double spaced, single column, it went from six pages to about sixteen.

[5] A quick check suggests that the abstract deadline for SIGCSE TS 2018 was August 25, 2017 and the papepr deadline was September 1.

[6] Is it really five conferences? Let’s see … There’s the Technical Symposium; The ACM Conference on Innovation and Technology in Computer Science Education (ITiCSE); the ACM Conference on International Computing Education Research (ICER); the ACM Conference for Research on Equitable and Sustained Participation in Engineering, Computing, and Technology (RESPECT); the ACM Global Education Conference (CompEd); and SIGCSE Virtual (no acronym yet). Whoops. That’s six. Let’s say five other SIGCSE conferences that aren’t SIGCSE.

[7] You can probably think of a few names that you see in multiple sessions at the TS. I won’t name them.

[8] To be precise, the deadline was 11:59 p.. Anywhere on Earth on July 3. In US Central Daylight Time, which is the time in effect where I reside, that ends up being 7 a.m. on July 4. I think submissions ended up closing at 8:00 a.m.

[9] ArXiV is a place that folks use to publish preprints of their work or works in progress. It is not peer-reviewed. In the words of the site,

arXiv is a free distribution service and an open-access archive for nearly 2.4 million scholarly articles in the fields of physics, mathematics, computer science, quantitative biology, quantitative finance, statistics, electrical engineering and systems science, and economics. Materials on this site are not peer-reviewed by arXiv.

Why would someone publish on arXiV? That’s almost certainly beyond the scope of this musing. However, two obvious reasons are (a) to establish precedence on a topic and (b) to get information out promptly.

[10] Believe it or not, some members of the SIGCSE community read my ’blog from time to time. At least, they claim to.

[11] Critical has multiple meanings. It’s not critical in the sense that it needs to be published soon in order to be useful. It’s certainly critical in the sense that it criticizes or critiques.

[12] I’m not sure how we judge magazine publication. I’m also at a stage of my career in which I don’t really care.

[14] By we, I mean something like The Grinnell faculty, when following common understanding about writing as well as the advice of the Writing, Reading, and Speaking Center.

Version 1.0 of 2025-07-10.