538B Distributed Systems Abstractions: Project proposals

Fall 2020

A project proposal details the problem, your proposed approach/solution, and a realistic timeline for your team. The proposal must include at least the following sections: introduction/motivation, background, proposed approach/solution, evaluation methodology, timeline.

Detailed instructions.

• The timeline must include dates and milestones/deliverables. It must be sufficiently refined to include milestones that are specific to your project. Do not simply list the deadlines for the course without listing the internal project deadlines. The timeline is there to get you to think about your time and to loosely commit to a schedule.
• This is a distributed systems course, so make sure that your proposal is focused on issues/challenges/objectives relevant to this topic. A particular focus should be paid to the notion of abstractions: which ones will you be using, developing, and how will you evaluate their abstraction qualities.
• If you are proposing a distributed system for your project, then the bulk of a proposal must be dedicated to design: what will your system look like, what properties will it have, what features will it include/omit, how will clients interact with your system, etc. This section is more critical than related work, or introduction/motivation. Writing this section well is difficult; spend the time to do a good job on it.
• If you are proposing a measurement study, then your proposal must be focused on scientific details, such as your hypothesis, how you will collect data, and what analysis methodologies you are planning to use. This section must be detailed and well thought out; spend the time to think about threats to validity and alternative approaches so that you can better argue for your approach.
• It is important to omit content that is irrelevant to your proposal. Before including text, consider whether or not it plays a purpose in explaining your proposed system/study and its objectives. If not, then it can probably be cut.
• Consider giving your project/system a name. This way you can easily refer to it in your proposal.
• Your project can re-use external code/algorithms/ideas that you find online (e.g., open-sourced Paxos Go implementations). Leverage prior work and build on it to avoid re-inventing the wheel and to get to interesting ideas quicker (e.g., implementing Paxos is itself a complete project).
• A few proposals include highly specialized content. Make sure to define non-standard/specialized terms, include examples, and intuition -- anything to help get your ideas across. This work will pay off in the long term: (1) it will get you thinking more deeply about your work, and (2) you can re-use it in the project write-up and project presentation.
• Make sure there is logical flow to your proposal. Define terms before you use them, motivate particular perspectives before launching into details, discuss prior work necessary to understand your proposal before you rely on it for your descriptions. Your proposal has to be self-sufficient, with citations to back-up your arguments. However, do not rely on related work to explain concepts that are critical to your proposal.
• Consider including info-graphics/figures to explain your design. Sometimes it is easier to explain a complex idea with a picture. Likewise, don't hesitate to include formalism/math to explain your ideas (though, be careful with including formalism for formalism sake -- make sure it helps to explain rather than confuse the topic).
• A well thought-out and detailed proposal will only benefit your group in the long run -- you will have a more clear idea of what you are really working on!