After the TPC meeting in 2013, I made a few tongue-in-cheek notes that may be of interest to those submitting MobiSys papers.

 -- David Kotz, 2013

Lots of people submit papers to MobiSys, but only a few can be presented at the conference. How can you ensure that your paper is among those rejected, so you don’t have to bother preparing all those slides? Few people know these time-honored tips and tricks, which if carefully followed will ensure that your paper will be rejected by the MobiSys program committee.

• Don’t tell us what you think are contributions of your work. It’s much more fun for us to guess than to read a clear and concise list of explicit contributions, such as those often seen in the Introduction or Conclusions section of the paper.
• Don't define all of your terms.  Anyone who reads your paper surely knows the detailed jargon of your topic area, and enjoys guessing as to which of the many varied meanings you may intend when you use that term. Bonus points if you make up your own term, but postpone defining it until late in the paper.
• Don’t list the assumptions on which your solution is based. Assumptions often serve to constrain the problem space, or solution space, and an honest list of assumptions just invites the reviewer to recognize the limited scope of your work. It’s better to imply that your solution solves the fully-fledged problem and is not limited by trivialities such as memory, storage, bandwidth, scale, or usage model.
• If your system aims to provide security or privacy properties, don’t tell us anything about your threat model or trust assumptions, and don’t define the targeted properties precisely. Security and privacy are squishy subjects, so it’s best left to the reader to imagination the capabilities of the adversary, the range of various threats, or which components can be trusted by which players in what way.
• Avoid citing the most-relevant related work, lest the reviewer see your work as incremental. If you accidentally cite all the relevant related work, avoid explicit explanations about how your work compares to that prior work; instead, just describe the literature as if you were writing a book report. 
• As a leading expert on this topic, you have published on this work before; cite yourself liberally. Whatever you do, don't tell us what's different about the work in this paper; instead, encourage us to go read all your prior work and figure it out for ourselves.
• If you use human subjects, don't get your study protocol approved by the relevant ethics review board; if you do, don't assure us that you have done so. Who cares about pesky humans anyway? They’re all too concerned about their safety and privacy anyway; surely, we researchers know what’s good for them. Bonus points for coercing students in your lab or in your class to be your test subjects.
• We love reading papers that motivate the work with visionary examples that indicate the importance of a problem and the need for a practical solution. Just be sure that you don't evaluate your work in the context of those motivating examples.  By the time a reviewer gets to the Evaluation section, you can expect they’ve already forgotten the examples mentioned in the Introduction and won’t care if you evaluate a totally different use case.
• You think your solution is ‘cool’, and you can count on us to think it’s cool too. Don't bother to evaluate the systems aspects of your proposed solution, such as performance, energy efficiency, or scalability. The “Sys” in MobiSys is just there to make the name unique; it doesn’t mean we actually care about systems.
• Your system architecture is so cool, we’re sure it will work. No need to build the thing, or evaluate it.  If you actually wasted the time to build something, don’t bother telling us what you built or whether it’s different than the architectural vision. Everyone takes shortcuts in the implementation, and surely they don’t matter to someone trying to interpret the results of your paper.
• Ok, so maybe you actually ran some experiments, collected some data, and want to tell us about it. To keep reviewers awake as they slog through page after page of tables and plots, don't tell them anything about the experimental conditions; it’s more fun if they have to guess. Definitely do not repeat your experiments in any way, because we believe one run is enough to validate the stability of your results. After all, computers are deterministic systems, and everyone in the lab knows your system well, so there couldn’t be any source of variance.
• Corollary: experiment with only one set of parameter values, and then make broad claims about your system’s application to the real world.  Don’t justify those parameter values as being relevant in the real world, and certainly don’t do any sort of sensitivity study to explore whether your results hold across a range of parameter values.
• Assume everyone reading your paper will read it on a beautiful color screen; only luddites print your paper on the hallway laser printer and read it on paper. To add an element of surprise, produce all figures and plots in colors that are difficult to distinguish when printed on a black & white laser printer. Ignore those who are color-blind [tips].
• Don’t worry if the font in plots and tables shrinks to microscopic size when you scale the plot to fit the column or page size. Nobody really needs to read the legend or axis labels anyway. Heck, you might just leave them out entirely.
• For fun, place your figures out of order, so it becomes a little game to track down that figure mentioned in the text. For even more fun, stick figures in early, on a page prior to its mention in the text, so the reviewer can ponder the figure before having to read the pesky text describing it.
• Don't bother to number your pages, because that makes it too easy for the reviewers to reference the page when they are commenting about a specific paragraph.

There you have it: quick and easy guidelines that will ensure that MobiSys will reject your paper, too!