Mctrain's Blog

What I learned in IT, as well as thought about life

What Makes a Good System Paper - by Gernot Heiser in APSys 2013

| Comments

There’s a session in APSys 2013, where Professor Gernot Heiser discussed about how to write a good system paper. It is really helpful, and I would like to share some of his suggestions here.

He introduced 4 rules of writing:

reviewers are pot luck

Most problems raised by reviewers may be:

I'm not convinced you're solving a real problem
I'm not convinced you're solving the problem
I don't understand - too badly writing

And one important thing we need to know is:

papers without a PC "champion" have a hard stand

Hence we must make sure there’s something which at least one reviewer will think cool!

a paper has a story

That means each paper should have one main message, and the author must know clearly what the message is, to make sure that the reader gets it, and make sure it’s an interesting one.

A paper has a narrative. It starts from zero and then works on transmitting the message. Everything you write must support the message.

The other important notes you should know are: maintain user state! ( be conscious of what the reader knows/remembers)

imited real estate: the two “c” s

be “clear”

Which means every sentence, paragraph, section should has a clear purpose, which should be clearly communicated, and the overall message is consistent.

be “concise” (brief but complete)

Don’t waffle! Be precise! and make sure it’s readable, lucid, enjoyable.

Other things need to consider are:

maintain reader state
define before use
be aware of what the reader has learned
recall/remind if necessary

presentation matters - paper engineering

Some important bits here:

introduction: sell the idea, the significance and the approach
build tension, make reader interested
convincing argumentation
top-down, not bottom-up
maintain reader state
convincing evaluation
state assumption/limitations honestly

And notes about each section of one paper:

Introduction: most important part of the paper!

It mostly issues an idea to come, explains the problem you’re solving, outlines your approach, indicates results/outcomes, states contributions, and correctly cites PCs’ work important!!!

Meanwhile, you should capture the reader’s interest to sell your idea, and be concise (stay within about one page), make sure the paper delivers what you promise. Remember: reviewer hate “bate and switch”

other parts:

background: set the scene in more detail

In backgound, you can cite related work, describe problem in detail, explain solution in detail (honest with limitations and assumptions)

abstract

it mostly used to steer to the right reviewers

what, why, achievement, implication (four sentences)
important: redo for camera ready

One interesting statement is that abstract usually has two purposes:

for published: rewrite for people to read
for reviewers: to select paper to review, get right reviewers!

evaluation: often largest part

It shows your solution actually works

progressive: significant improvements in important situations
conservation: no (or insignificant) degradation elsewhere

Be careful about the scenarios of your benchmark

artificial/constructed best cases will be discounted
think of ways in which your approach could fail/deteriorate
go out of your way to be fair, anticipate any scepticism of your work

Other notes:

style and form

Write in engaging style, lead reader though the paper

avoid tobbom-up structure, present idea top-down
follow style rules
use active voice
avoid buzzwords("novel", "mobile social supercomputing in cloud")     

Be mindful of reader’s brain state (which is lossy)

maintain reader state
don't assume every reviewer is expert in your narrow area
but don't think you can hide stuff from reviewers

Follow formatting rules

don't play with margin, baseline skip etc.
don't use microscopic fonts > 40y olds have problems with <8pt font

Spell-check, proof-read, proof-read

get native speaker to proof-read if you aren't
get outsider to read it - great way to spot holes before it's too late!

Mechanics

use revision control
don't use MS word
use BitTex

And some other materials:


The trip to Singapore for APSys 2013 really make me harvest a large. It is my first time to submit a poster, and the first time to apply for the Travel Grant. And I’ve meet, talked to and discussed with a lot of genius and excellent people there. Although I’m not good at social, attending such excellent meeting let you learn from others a lot, and make you much more familiar with the System community.

Finally is my photo in presenting my poster work - RemoteBinder. The audience is the lengendary people Yandong Mao, graduated from Fudan University, and now PhD of MIT CSAIL.

apsys yltiu

Comments