The same ideas also apply to design docs

Common misconceptions

  • Author: Record the process of how we reached the solution by going through complex subproblems. The reviewer should be impressed by the smart process
    • Reviewer: Why one problem after another, which is the main problem to solve? Which one is common practice, and which is of the author’s own?
  • Author: Spend two pages on thinking through the problem to transform to a different problem. Reviewer should appreciate this challenging mind game
    • Reviwer: No intro and conclusion, what is the purpose of this thought process?
  • Authoer: Added innovation to existing work to reach SOTA. The reviewer should appreciate the experiment result
    • Reviwer: Yet another AAA + BBB. Then let me check the effect. What does this result mean, is it a significant improvement

Don’t record review process

  • The reviewer want to quickly get your new contribution. The goal is the final state, and not the research progress.

Bad Example

  • To solve problem 1, I have solution A, but A’s result is not ideal because of problem 2, and 2 is solved by my solution B.

Reviewer’s PoV

  • how to prove 2 is the root cause of bad results of A
  • B seems to have little difference from A
  • A has some effect, how to prove this is because it solved problem 1

Author’s confusion

  • The final result is B, plus I built A too
  • Why need to prove the relationship between B and A

Reviewer’s reaction

  • You didn’t emphasize A
  • A didn’t solve your problem 2, which you emphasized
  • If A is not major contribution, than B has little value

How to fix with a better framework

Flow : Problem -> theory behind -> solution and implementation-> experiment to verify. This flow means we should avoid “based on” and “A+B”

  • A new solution to an important problem
  • A new framework and a common trick
    • Prove that we need both. Without this trick, the result will be worse, that is because of an interest problem
    • This trick can be applied to other methods

Reviewer’s PoV

  • I can see what is new and I just need to decide if they are technically sound and if effects are significant

Readability

  • Coherent is on logic itself, and not connecting words
  • Explain the effect right after the name (we propose XXX, which is a two-layer MLP). Otherwise, the reader may be frustrated when they discover it is so simple after many paragraphs
  • When you are expanding on the story and the reviewer is decideing if the story makes sense, do not attach reference to graphs a few pages after, because paper is linear story telling.
  • Around the table you should explain key points with high information density
  • If you want to emphasize table 5, then the sentence that analyzing the result better be on the same page as table 5, because reader may not look into your text and check graph and find related text
  • Don’t expect users to compare results themselves. Compare it your self, it is ok to repeat the comparison of certain results.

Rebuttal

  • Reviewer demands optional data
  • Add the data, also list influential parallel work and show that data is in general optional.
  • Don’t give the AC the impression that you are preaching, e.g., consider the review comment quality, rather than exclude scores from the reviewer. :w
  • Be explicit on your AIs to address comments

Story telling

Motivation

  • Define the problem: Why is it a common problem?
    • For example, to solve the congestion, we need to control send speed at the end point level, and that means we need to 1. sense the network’s congestion, and 2. algorithm to control the send speed to reduce congestion
  • What are problems with current algorithms?
  • What is your key idea and what makes your key idea promising.
  • Adjust granularity based on the audience

Contribution

  • Insights, but not manual. Why does your design work? Prove that all parts of your design is needed and not only a part of it.
  • Can your insights be applied to other scenarios?

References