Use this when revising the main paper. ICSME papers are read by maintenance and evolution
empiricists, so they need a software-maintenance contribution stated on the first page and
evidence a reviewer trusts. The failure this skill prevents is a technically fine paper that reads
like a greenfield systems demo or a generic ML result with a maintenance title glued on — the
icsme-topic-selection re-route signal.
| Section | Job it must do | Common failure |
|---|---|---|
| Intro | Maintenance problem, inadequacy, contribution, evidence preview, payoff — first page | Leads with a technology trend, not a maintenance pain |
| Background/Motivation | Why a maintainer or the evolution literature needs this now | Motivation by assertion, no grounding in practice |
| Approach / Study design | The technique or the RQs + mining/analysis protocol, reproducibly | Method too thin to re-run on other histories |
| Evaluation | Each RQ answered with proportional evidence on real systems | Metrics that proxy for the maintenance outcome |
| Threats to validity | The threats that bite this history/corpus, each bounded | Generic list untethered from this study |
| Related work | Delta-first positioning against the evolution literature | Catalog of citations with no contrast |
| Draft pattern | ICSME-safe rewrite |
|---|---|
| "Our tool significantly improves maintainability." | "reduces change-impact set size by X% (95% CI ...) vs. |
| "We study a large software corpus." | "We mine <N> projects sampled by |
| "Results show our refactoring is safe." | "RQ2: behaviour-preservation held on |
| "State-of-the-art performance." | Claim scoped to the systems, change history, and metrics actually studied |
| "Developers understood the code better." | "comprehension-task accuracy rose from X to Y (effect size ...) in the study" |
[Construct] does the metric measure the maintenance outcome you claim? (e.g. churn as a proxy for effort)
[Internal] could something other than your technique explain it? (confounds in change history, tuning)
[External] to which systems/languages/domains/histories does the finding generalize?
[Conclusion] are the statistics appropriate; survivorship handled; multiple comparisons corrected?
-> for each that bites: state it, then state the mitigation, next to the affected result
A draft with three RQs, nine figures, and a sprawling background on version-control internals: keep all three RQ answers, the two figures that carry the headline evolution findings, and a threats subsection per RQ; move the full per-project breakdown, the mining pipeline diagram, and secondary plots to the artifact with explicit forward references; cut background to what the argument needs. The test of a good cut: a reviewer should be able to answer "what did each RQ find about how this software evolves, and what threatens it?" from the 10 pages alone.
[Writing diagnosis] clear / under-motivated / over-claimed / evidence-mismatched / over-scoped
[First-page fix] <new framing leading with the maintenance/evolution contribution>
[RQ audit] <RQ -> metric -> where answered -> proportional? yes/no>
[Threats fix] <threat that bites this history/corpus -> mitigation to add, placed by the result>
[Anonymity edits] <tool names / self-citations / own-system subject / links to rewrite>