538B Distributed Systems: Project proposal instructions
A project proposal details the problem, your proposed
approach/solution, and a realistic timeline for your team. The
proposal must be no longer than 5 pages and must include at least the
following sections: introduction/motivation, background, proposed
approach/solution, evaluation methodology, timeline.
- 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
- This is a distributed systems course, so make sure that your
proposal is focused on issues/challenges/objectives relevant to this
- 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.
- Remember that unlike the assignments, 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
- 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
- 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
- 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!