icse-related-work

name	icse-related-work
description	Use when building the related-work and positioning sections of an ICSE research-track paper, covering the literature lanes SE reviewers check, searching ACM DL, IEEE Xplore and dblp across the flagship venues, staying current in fast-moving areas like LLM4SE, and keeping self-citations double-anonymous.

ICSE Related Work

Positioning at ICSE is scored twice: once under novelty ("sufficiently original with respect to the state-of-the-art", per the 2027 criteria read 2026-07-08) and once implicitly when the assigned reviewers — likely authors of the nearest prior work — check whether they and their neighbors are represented fairly. Cover the lanes below before writing a word of the section.

The five lanes an SE reviewer sweeps

Lane	Where it lives	What missing it costs you
Flagship conference line	ICSE, FSE, ASE, ISSTA proceedings (ACM DL / IEEE Xplore)	The direct-competitor omission — often the reviewer's own paper
Journal line	TSE, TOSEM, EMSE	Mature versions of "your" idea; journals often published it first
Specialized venue line	MSR, ICSME, ICPC, SANER, RE, SPLC, ESEM per subfield	Reviewers from that subcommunity notice instantly
Preprint line	arXiv cs.SE (critical in LLM4SE, AI-for-SE)	Staleness: in fast lanes, six months of preprints can contain your contribution
Adjacent-field line	PL (PLDI/OOPSLA), systems, ML, HCI as relevant	Reinvention accusations from cross-listed reviewers

Search all three indexes — ACM Digital Library, IEEE Xplore, and dblp — because ICSE's own proceedings historically alternate between publishers and no single index has everything; dblp is the neutral spine for coverage checking, the DLs for full text.

Currency in fast lanes

LLM4SE and AI-for-SE turn over in months. For a June 30 submission, run a final sweep in the last two weeks: new arXiv postings, the just-published ICSE/FSE proceedings, and the accepted-papers lists that venues post before official publication. Concurrent work (public after your study was designed) deserves acknowledgment, not competition: cite it, mark it concurrent, and do not contort your evaluation to beat a paper that appeared last month — reviewers understand timelines and respect the candor.

Writing the section as an argument

The section's job is a delta statement, not a bibliography. Organize by the dimensions on which you differ, then place each cluster:

## Related Work (delta-first pattern)

**Test-suite-based repair.** [Cluster: GenProg lineage, semantics-based
repair.] These validate candidate patches against the failing suite; all
inherit test-suite overfitting. *We differ:* our oracle is X, so overfitting
of type Y cannot occur by construction (§4).

**LLM-based patch generation.** [Cluster: 2023–2026 line, incl. concurrent
work.] These generate candidates but keep suite-based validation. *We
differ:* evaluation on post-training-cutoff bugs (§5.2) removes the
contamination confound these papers share.

**Empirical studies of overfitting.** [Studies motivating the problem.]
We *build on* their measurement protocol and extend it to Z.

Every cluster paragraph ends with the difference stated in your paper's own technical terms, with a section pointer. If a cluster ends with "...has also studied this area", it is filler.

Double-anonymous self-citation

ICSE reviews double-anonymously, and prior-work references must be third person: "Prior work introduced FOO [12]" rather than "In our earlier paper [12]". The subtle leaks: citing an unpublished technical report only your group could know, an artifact URL from your prior paper's repository, and a tool name unique to your lab used without citation. If the current paper extends your own published tool, cite it in third person and phrase the relationship symmetrically ("extends FOO [12] by...") — reviewers may guess, but the text must not confirm.

The nearest-neighbor rehearsal

Before freezing the section, run one simulation: pick the three papers a PC chair would most plausibly assign as reviewer expertise matches — usually the three you compare against in the evaluation — and reread your section as each of those authors. For each, answer: is my paper described accurately (not straw-manned)? is the difference stated in terms I would accept? is my most recent relevant paper present, or only my old one? A misdescribed neighbor produces the angriest review in the packet, and it is entirely preventable at the cost of an hour.

Verification discipline for the bibliography

• Every citation checked against dblp or the DL record — titles, venues, years drift when copied from other papers' bibliographies or generated by models; a hallucinated reference discovered by a reviewer poisons trust in everything else.
• Cite the archival version over the preprint when both exist; keep arXiv IDs for preprint-only work.
• Distinguish venue tiers honestly: a workshop paper and an ICSE paper by the same authors are different maturity claims.
• Normalize venue naming (e.g., ESEC/FSE vs FSE across years) so reviewers recognize the venues at a glance.

Output format

[Lane coverage] five lanes -> swept on <date> / gap
[Delta table] nearest neighbors -> difference in our terms -> section pointer
[Currency] last sweep date; concurrent-work items flagged
[Anonymity] self-citation phrasing audit: violations found/fixed
[Bibliography hygiene] unverified entries remaining (must be zero)