ASE Writing Style

ASE Writing Style

Write the paper so an automated-SE reviewer sees, on the first page, what task you automate, how you automate it, and that it runs on real subjects. ASE rewards a clearly stated automation with evidence proportional to the claim — not a systems win, not a leaderboard, and not a broad finding that would read better at FSE. The worked example in resources/worked-examples/01-introduction.md shows the arc before → after.

The ASE first-page arc

Lead with the automation, in this order:

1. The automatable task — a software-engineering task the reader recognizes (detect X, generate Y, repair Z, comprehend W), named precisely enough that a reviewer knows what "success" is.
2. Why current automation (or manual practice) is inadequate — what existing tools do not do, stated as a gap, not a literature tour.
3. The contribution as an automation design — the technique (analysis, generator, synthesizer, repair, learned model) and, ideally, the tool that embodies it.
4. Evidence on real subjects — real systems, credible tool baselines, and the metric that matches the task (not a proxy).
5. What it automates for practice + threats posture — the payoff, with the central threat named where it lives, not deferred to a closing paragraph.

Put the automation and the first evidence within the first three pages; the early-rejection gate means a weak opening can end the process before rebuttal.

State the automated task precisely

• Name the input, the output, and the success criterion of the automation. "We improve code quality" is not a task; "given a flaky test, synthesize a patch that makes it deterministic without weakening its assertions" is.
• Say what the tool takes as input in practice (source? bytecode? traces? a repository?) and what it produces — reviewers map this straight to feasibility.

Keep the model-swap test in view

If a learned component is involved, write so the automation design is the contribution, not the model. Report an ablation that isolates the learned part from the analysis/oracle, and phrase claims so the software-engineering lesson survives a model swap. A paper whose lesson evaporates when the model changes reads as an ML re-route (see ase-topic-selection).