icsme-topic-selection
GitHub辅助判断软件工程论文是否适合投稿至IEEE ICSME会议，或应路由至ICSE、FSE等其他顶级会议/期刊。涵盖维护、演化、重构等主题，并指导选择Journal-First等特定轨道。
Trigger Scenarios
Install
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill icsme-topic-selection -g -y
SKILL.md
Frontmatter
{
"name": "icsme-topic-selection",
"description": "Use when deciding whether a software-engineering project belongs at IEEE ICSME (maintenance, evolution, reverse engineering, program comprehension, technical debt, refactoring, mining software repositories) or should be routed to ICSE, FSE, ASE, ISSTA, MSR, SANER, SCAM, or an SE journal (TSE\/EMSE), and when to use ICSME's Journal-First, Registered Reports, or RENE tracks instead of the research track."
}
ICSME Topic Selection
Decide the venue before drafting. ICSME — the IEEE International Conference on Software Maintenance and Evolution — is the field's dedicated home for what happens to software after the first release: maintaining it, evolving it, comprehending it, refactoring it, repaying its technical debt, and mining the repositories that record its history. A brilliant paper about a greenfield synthesis technique, a novel type system, or a pure ML model is respected and then rejected as out of scope. The ICSME question is not "is this good SE?" but "is the paper's centre of gravity a real maintenance-or-evolution problem?"
The routing question that matters most
ICSME overlaps ICSE and FSE (both take maintenance work) and SANER, SCAM, MSR, and ICPC (all maintenance-adjacent). The decisive test is which community the paper is arguing with and how central the maintenance lifecycle is to the contribution — plus which live deadline fits. A paper whose evidence is a legacy system aging under change, a refactoring that developers must trust, or a bug that survived years of evolution is natively ICSME; a paper that only uses software as a substrate for a general technique usually belongs elsewhere.
Sibling-venue routing table
| Signal in your project | Better home | Why |
|---|---|---|
| Maintenance/evolution problem is the heart: aging systems, change impact, technical debt, refactoring safety, program comprehension | ICSME | The venue built for the post-release lifecycle |
| Broad SE technique or study aimed at the whole field, not specifically maintenance | ICSE / ESEC/FSE | General-SE flagships with wider scope and a larger stage |
| The whole method is repository mining and the research question is about mining itself | MSR | Purpose-built mining venue (ICSME takes mining applied to maintenance) |
| Static/dynamic source-code analysis or transformation is the core machinery | SCAM | Co-located with ICSME; deeper source-analysis expertise |
| Reverse engineering / comprehension with a strong tooling or human angle, early-stage | SANER / ICPC | Evolution-adjacent siblings with their own communities |
| Testing depth or fault detection is the contribution | ISSTA / ASE | Testing/analysis and automation venues |
| Study too long or too deep for the 10-page IEEE budget | TSE / EMSE | Journals with no conference ceiling — and the door back via ICSME's Journal-First track |
Contribution shapes ICSME rewards
- Maintenance/evolution technique + tool + evaluation on real, evolving systems — a change- impact, refactoring, migration, comprehension, or debt-detection technique, embodied in a tool and evaluated on real systems with real change history.
- Empirical study of how software ages and changes — mining commit, issue, PR, or release history to characterize maintenance practice, defect survival, debt accumulation, or evolution.
- Reverse engineering / program comprehension — recovering architecture, models, or intent from existing code, with evidence it helps a maintainer.
- Replication or negative result (the RENE track's home turf) — re-running prior maintenance research on new data and reporting honestly what did and did not reproduce.
- Technical-debt and refactoring economics — measuring, predicting, or repaying debt, or demonstrating that a refactoring preserves behaviour and pays off.
The re-label and lifecycle tests
Two quick tests sharpen a borderline verdict:
- Lifecycle test: does the contribution only make sense because software already exists and keeps changing? If you can restate it with no reference to history, maintenance, or evolution, ICSME is probably the wrong room — route to ICSE/FSE or a technique venue.
- Re-label test: could this be submitted to MSR or SCAM unchanged and read as native there? If its heart is mining-for-its-own-sake or source transformation machinery, route accordingly; ICSME rewards the maintenance payoff of that machinery, not the machinery alone.
Choosing an ICSME track (not just the research track)
ICSME is unusual in how many doors it opens — pick the one that fits the work's maturity:
[Research track] a complete maintenance/evolution technique or study, ready now
[Journal-First (J1C2)] a TSE/EMSE paper already accepted (2025-2026 window) not yet conf-presented
[Registered Reports] a strong protocol whose result is not yet in -> lock the method, review-first
[RENE] a replication/reproduction on new data, or an honest negative result
[NIER / Visions] an early idea with an argument but not a full study
[Tool Demo / Data] a usable tool or a released dataset as the contribution
[Industry] a practitioner-driven maintenance experience report
Cheap reconnaissance before committing
[Scope] scan the last two ICSME programs (dblp conf/icsm, conf.researchr.org) for your subarea
-> 3+ recent papers = a reviewer pool exists; 0 = opening or mismatch
[Citations] is your bibliography majority maintenance/evolution venues (ICSME/SANER/MSR/ICPC/TSE/EMSE)?
-> majority elsewhere => reviewers read you as a visitor; ground the intro in maintenance first
[Calendar] compare the next ICSME abstract deadline with ICSE/FSE/SANER/journal dates -> route to the
nearest honest fit rather than idling a year
Decision procedure
[Audience] who acts differently if the claim holds? -> maintainers/reverse-engineers/evolution researchers?
[Claim type] technique / empirical / comprehension / replication / debt-economics
[Lifecycle check] does it depend on software already existing and changing? -> yes = ICSME-shaped
[Sibling check] mining-only -> MSR; source transformation -> SCAM; general SE -> ICSE/FSE
[Track choice] research / journal-first / registered report / RENE / NIER / tool-demo / industry
[Verdict] ICSME <track> / sibling venue / journal-first, with a one-line reason
Run this before the writing skills; a wrong venue or wrong-track decision wastes every later step.
When the verdict is ICSME, continue with icsme-workflow for the calendar and
icsme-writing-style for the paper shape.
Version History
- 9f86f09 Current 2026-07-19 15:59
