fse-topic-selection

FSE Topic Selection

Decide the venue before drafting. FSE — the ACM International Conference on the Foundations of

Software Engineering, historically ESEC/FSE on its European rotation — is one of the two

general software-engineering flagships, alongside ICSE, and the ACM SIGSOFT home for foundational

and empirical SE. Its research papers are PACMSE journal articles, so reviewers read for a

durable software-engineering contribution, not a one-conference result. A technically strong

paper whose real lesson is about compilers, PL semantics, or pure ML is respected and then

rejected as out of scope.

The routing question that matters most

FSE and ICSE overlap heavily in scope and reviewer pool, so the decisive question is rarely "is

this SE?" but "which SE community and calendar fits this paper now?" Both welcome techniques,

empirical studies, and human-factors work. Use the finer signals below and the live deadlines to

choose — a strong paper is publishable at either, and the nearer honest deadline usually wins.

Sibling-venue routing table

| Signal in your project | Better home | Why |

|---|---|---|

| Broad SE contribution, empirical or conceptual, ready now, and the next FSE deadline is nearer | ESEC/FSE | PACMSE journal-style track; the second general-SE flagship |

| Equally broad, but ICSE's cycle lands sooner or you want its stage | ICSE | Sibling general-SE flagship; different calendar and template (IEEE 10+2) |

| Core is automating a development task; tool/systems flavor dominates | ASE | Automated software engineering is its named center |

| Core is testing, program analysis, or fault detection with depth | ISSTA | Deeper testing/analysis expertise, round-based reviewing |

| The whole method is repository mining | MSR | Purpose-built co-located conference |

| Maintenance and software evolution focus | ICSME | Scope match |

| Study is too long or too nuanced for the page budget | EMSE / TSE / TOSEM | Journals with no conference page ceiling; some offer a journal-first path back to an FSE stage |

Contribution shapes FSE rewards

• Technique + tool + evaluation on real subjects — a new analysis, testing, repair,

synthesis, or recommendation technique, embodied in a tool and evaluated on real systems against

credible baselines (the CUTE lineage).

• Empirical study — mining, controlled experiments, or mixed-methods work that changes what

the community believes about how software is built or maintained (the flaky-tests lineage).

• Methodology / measurement validity — interrogating an instrument the field relies on (the

"are mutants a valid substitute?" lineage) — a distinctly prized FSE mode.

• Human and organizational factors — how practitioners actually use, trust, or abandon tools,

with sound qualitative method.

• Foundational or conceptual — models, theories, or formal underpinnings with a clear SE

payoff — the "foundations" in the name is not decorative.

The model-swap and re-label tests

Two quick tests sharpen a borderline verdict:

• Model-swap test: if your paper leans on an LLM or learner, ask whether the software-

engineering lesson survives swapping the model for another. If not, the model is the

contribution and a PL/ML venue fits better.

• Re-label test: could this paper be submitted to ISSTA or ASE unchanged and read as native

there? If its heart is testing depth or automation machinery, route accordingly; FSE rewards the

broader SE framing and empirical breadth.

Evidence maturity, without the ladder cliché

Fit is necessary but not sufficient: the same idea sits at different doors depending on how far

the evidence has come. An observation with an argument but no study is a workshop or vision paper;

a working technique evaluated only on examples you chose needs real subjects before the research

track; a study too deep for the page budget belongs in a journal first. Submitting one step early

earns a polite "promising, but..." and costs a full cycle, because FSE, like its siblings, runs on

an annual rhythm.

Cheap reconnaissance before committing

[Scope]   scan the last two FSE programs (dblp, conf.researchr.org) for your subarea
          -> 3+ recent papers = a reviewer pool exists; 0 = opening or mismatch
[Citations] is your bibliography majority SE venues (ICSE/FSE/ASE/ISSTA/EMSE/TSE)?
          -> majority non-SE => reviewers read you as a visitor; naturalize the intro first
[Calendar] compare the next FSE deadline with ICSE/ASE/ISSTA/journal dates -> route to the
          nearest honest fit rather than waiting a year for a marginal preference

Decision procedure

[Audience] who acts differently if the claim holds? -> SE developers/testers/maintainers/researchers?
[Claim type] technique / empirical / methodology / human-factors / foundational
[FSE vs ICSE] both fit? -> choose by calendar, community pull, and template preference
[Sibling check] testing depth -> ISSTA; automation core -> ASE; mining-only -> MSR
[Verdict] ESEC/FSE research track / sibling venue / journal-first, with a one-line reason

Run this before the writing skills; a wrong venue decision wastes every later step. When the

verdict is FSE, continue with fse-workflow for the calendar and fse-writing-style for the

paper shape.