|
Project ProposalsThere are two primary artifacts that you will produce for your project proposal:
Secondarily, you will also be reviewing your classmates' proposals. Written ProposalOne of the best essays I know on the topic of technical/scientific writing is The Science of Scientific Writing. You should read it. I reread it at least once a year. Your written proposal should be submitted to your team repository (which will be cs97fa13_teamNN). You should write your proposal in LaTeX and submit files called proposal.tex and proposal.pdf in the main directory of your repository. Your proposal should contain the following:
AbstractThe abstract should be a 1-3 paragraph description of the main ideas behind the project. Abstracts should be comprehensible without reading the rest of the proposal/paper. Abstracts are advertising; you should strive for interesting over precise. It is usually best to write the abstract last. MotivationWriting a good, crisp motivation for a project is important and something that many researchers are bad at. Think about how the world might be different if you project is successful from the perspective of someone who doesn't actually care about your project itself. Many (but not all) good research projects begin with a focus on a specific problem that specific people are actually experiencing. BackgroundWhat has already been done that is related to your project? You should cite at least one paper in this section. (If your project is on the applied end of the spectrum, it might make sense to cite a manual or technical documentation of some sort, but do your best to find published material also.) Computer science has become a reasonably mature field of study in the last generation or so, which means that there is almost certainly some prior work related to your idea. It's better to find it early and do a project that is a modest twist on what's been done than to find out that you have exactly replicated what someone else did 10 years ago. Your IdeaDescribe your main idea in however much detail you have developed it. It is quite likely that a picture or two will help paint the picture of what you want to do for your readers. In a preliminary proposal like this one, the motivation and background are generally more important than the idea itself. Doing good research is more about choosing good problems than coming up with clever solutions quickly. That said, you do need to convince your readers that you have a fighting chance of making progress on the problem, which means that you need at least an initial sketch of a solution. Goals for Milestones 1, 2 and 3Your proposal should include specific goals for milestones 1, 2 and 3. The more concrete you can make these goals, the lower your overall risk for the project will be. If your project is more exploratory, it is okay if the goals are somewhat vague or abstract, but you should strive for as much specificity as you can. Your goals should include some indication of how your team intends to split up the work among its members. If you can come up with a distinct meaningful goal for each person for each milestone, that's great. During the milestone 1, 2 and 3 meetings, we will discuss where your team is relative to the goals you set in your proposal. If the project is on track, hooray. If you are behind schedule or have changed course for some reason, you must come up with new goals for the remaining milestones that reflect these changes. CitationsYour proposal should include at least one citation to related work. You should use bibtex. PresentationFor this presentation, imagine that you are approaching a funding agency about supporting your project. The format is entirely up to you. You are welcome to use presentation software or do some demonstration, but that's not required. It is hard to communicate technical content during short presentations. I think it's usually better to get your audience on your side with good motivation and background information. Then you can just give a high-level outline of your technical ideas and encourage people to talk with you (or read your proposal/paper) offline if they want more details. ReviewingYou will play the role of funding agency, and review some of your peers' proposals. Your reviews will not impact the reviewee's grade at all, but there may be a fun prize for "winning" the review process. (Let me know if you have any good ideas for what the prize should be.) You will be (pseudo-)randomly assigned three or four proposals to read and evaluate. You will rank the proposals according to how likely you would be to fund the project, if you were actually in a position to do so. You should write two short paragraphs for each of the proposals
Here are the factors I encourage you to consider when you review the proposals:
Your reviews are due on Friday, October 11th at 5:00pm. The proposals that you are to review should be in your personal CS97 repository in a directory called ProposalReviews. If they are not, contact Ben right away. SubmissionYou should submit a separate plain text file called teamNN_review.txt for each proposal. You should put these files in your ProposalReviews directory! Each file should be relatively short. The combined amount of text in all your reviews should be about a page. You should also submit a file called rank.txt that just has one team number per line in order from most to least fundable. For example: 03
42 27 11 |