ISSTA Writing Style
Use this when revising the main paper. An ISSTA paper has to state, early and precisely, what
software behaviour it finds or reasons about, on what it was evaluated, and what the evidence
showed — to a reviewer who already knows the nearest tool and benchmark.
Revision rules
- Put the contribution on the first page: the problem in a concrete testing/analysis setting, why
existing techniques miss it, the technique, and what the evaluation showed. Name the technique;
do not hide it behind "a novel approach."
- State the threat model or analysis scope before the technique. Reviewers judge soundness against
the scope you set, so an unstated scope is an unbounded claim they will puncture.
- Make the evaluation a contract: subjects, baselines, metric, and statistic, declared before the
numbers. "Outperforms prior work" without that contract is the single most common weak sentence.
- Pair every claim with evidence: a table, a benchmark result, an artifact path, or a scoped
limitation. A declarative sentence near a result is something a specialist reviewer will check.
- Write a real threats-to-validity section: internal (confounds in the measurement), external
(do the subjects generalize), and construct (does the metric measure the property). A boilerplate
threats paragraph is noticed and counts against presentation.
- Keep double-anonymous phrasing in self-citations, tool names that de-anonymize, repository
references, and acknowledgements.
Contribution-presentation discipline
- Scope claims to the subjects tested. "Detects order-dependent flaky tests" is defensible; "detects
flaky tests" when you tested one subclass is not.
- Separate what the technique guarantees from what it empirically achieves; mixing a soundness claim
with a benchmark number in one sentence is a credibility leak.
- Define the analysis or measurement once, in one place; two-column ACM pages punish redefinition.
- When a result is best-effort or unsound-but-useful, say so; ISSTA reviewers respect a scoped,
honest technique over an overclaimed "sound" one.
Sentence-level rewrites
| Draft pattern |
ISSTA-safe rewrite |
| "Our tool significantly outperforms prior work" |
"finds X% more true bugs than at an equal time budget (paired test, effect size Y)" |
| "We detect flaky tests" |
"We detect the order-dependent subclass of flaky tests" |
| "Evaluated on real-world programs" |
"Evaluated on across N subjects (SHAs in the artifact)" |
| "Our analysis is sound" |
"Sound under Assumptions 1-2; native calls are out of scope" |
Vignette: compressing into 18 ACM pages
A draft with a formal analysis, six subjects' worth of tables, and a sprawling related-work section:
keep the analysis rules, one soundness sketch, the evaluation protocol, and the two decision-critical
tables in the body; compress related work into delta-first contrasts; push complete per-subject
tables and extra configurations into the artifact. The test of a good cut: a specialist reviewer can
judge soundness and evaluation without opening the artifact — the artifact deepens the paper, it does
not complete it.
What a strong ISSTA opening does
1. names the concrete testing/analysis problem and its cost
2. bounds the scope (which subclass, which language, which assumption)
3. names the technique and its one key idea
4. states the evaluation contract: subjects, baseline, metric, statistic
5. reports the finding, honestly scoped
Output format
[Writing diagnosis] clear / under-scoped / overclaimed / contract-missing
[First-page fix] <new framing>
[Scope statement] <threat model / analysis scope>
[Claim discipline] <claim -> table/artifact/limitation>
[Compression cuts] <move to artifact / delete / merge>
[Anonymity edits] <phrases to rewrite>
Source: brycewang-stanford/Awesome-Journal-Skills → ISSTA-Skills/skills/issta-writing-style/SKILL.md
1---2name: issta-writing-style3description: Use when revising an ISSTA paper for a clear testing/analysis contribution, covering the threat-model-then-technique structure, the evaluation contract, a threats-to-validity section that is not boilerplate, claims scoped to the subjects tested, double-anonymous phrasing, and 18-page ACM sigconf discipline that survives specialist reviewers.4---567# ISSTA Writing Style89Use this when revising the main paper. An ISSTA paper has to state, early and precisely, what10software behaviour it finds or reasons about, on what it was evaluated, and what the evidence11showed — to a reviewer who already knows the nearest tool and benchmark.1213## Revision rules1415- Put the contribution on the first page: the problem in a concrete testing/analysis setting, why16 existing techniques miss it, the technique, and what the evaluation showed. Name the technique;17 do not hide it behind "a novel approach."18- State the threat model or analysis scope before the technique. Reviewers judge soundness against19 the scope you set, so an unstated scope is an unbounded claim they will puncture.20- Make the evaluation a contract: subjects, baselines, metric, and statistic, declared before the21 numbers. "Outperforms prior work" without that contract is the single most common weak sentence.22- Pair every claim with evidence: a table, a benchmark result, an artifact path, or a scoped23 limitation. A declarative sentence near a result is something a specialist reviewer will check.24- Write a real threats-to-validity section: internal (confounds in the measurement), external25 (do the subjects generalize), and construct (does the metric measure the property). A boilerplate26 threats paragraph is noticed and counts against presentation.27- Keep double-anonymous phrasing in self-citations, tool names that de-anonymize, repository28 references, and acknowledgements.2930## Contribution-presentation discipline3132- Scope claims to the subjects tested. "Detects order-dependent flaky tests" is defensible; "detects33 flaky tests" when you tested one subclass is not.34- Separate what the technique guarantees from what it empirically achieves; mixing a soundness claim35 with a benchmark number in one sentence is a credibility leak.36- Define the analysis or measurement once, in one place; two-column ACM pages punish redefinition.37- When a result is best-effort or unsound-but-useful, say so; ISSTA reviewers respect a scoped,38 honest technique over an overclaimed "sound" one.3940## Sentence-level rewrites4142| Draft pattern | ISSTA-safe rewrite |43|---|---|44| "Our tool significantly outperforms prior work" | "finds X% more true bugs than <baseline> at an equal time budget (paired test, effect size Y)" |45| "We detect flaky tests" | "We detect the order-dependent subclass of flaky tests" |46| "Evaluated on real-world programs" | "Evaluated on <benchmark vN> across N subjects (SHAs in the artifact)" |47| "Our analysis is sound" | "Sound under Assumptions 1-2; native calls are out of scope" |4849## Vignette: compressing into 18 ACM pages5051A draft with a formal analysis, six subjects' worth of tables, and a sprawling related-work section:52keep the analysis rules, one soundness sketch, the evaluation protocol, and the two decision-critical53tables in the body; compress related work into delta-first contrasts; push complete per-subject54tables and extra configurations into the artifact. The test of a good cut: a specialist reviewer can55judge soundness and evaluation without opening the artifact — the artifact deepens the paper, it does56not complete it.5758## What a strong ISSTA opening does5960```text611. names the concrete testing/analysis problem and its cost622. bounds the scope (which subclass, which language, which assumption)633. names the technique and its one key idea644. states the evaluation contract: subjects, baseline, metric, statistic655. reports the finding, honestly scoped66```6768## Output format6970```text71[Writing diagnosis] clear / under-scoped / overclaimed / contract-missing72[First-page fix] <new framing>73[Scope statement] <threat model / analysis scope>74[Claim discipline] <claim -> table/artifact/limitation>75[Compression cuts] <move to artifact / delete / merge>76[Anonymity edits] <phrases to rewrite>77```7879---8081**Source:** [`brycewang-stanford/Awesome-Journal-Skills`](https://github.com/brycewang-stanford/Awesome-Journal-Skills) → `ISSTA-Skills/skills/issta-writing-style/SKILL.md`
thedixitjain