Department of Computer Science
Instructions for Phase 2 of RPW Course
You are to write a mock grant proposal to NWO, the organization that gives grants to hire Ph.D. students in the Netherlands. Your proposal is for 1 Ph.D. student. This is the normal quantum. You can write about any computer science topic you are interested in. It can be about hardware, software, applications, or anything else that NWO might fund.
Here is some general advice about writing proposals. Most of it applies to not only NWO, but also to STW, the EU, and even proposals to your boss in a company.
Format of the Proposal
Your proposal should have the following form:
Four pages is the absolute maximum length. Do not exceed it. Make your proposal attractive and easy to read. It should be single column with a line length of 16 cm and be right justified. Put a blank line between paragraphs but do not indent them. Try to avoid loose lines, rivers, and widows.
If you write a REALLY REALLY great proposal, you might convince one of the staff members to work with you to submit it. If the proposal has commercial value, and we can find a company that wants us to solve the problem for them, it could be submitted to STW, which has no deadlines. But we have to find a Dutch company to sign on, and that is difficult to do.
Here are the titles and summaries of some proposals
submitted by students in previous years. These are not necessarily the best ones, and
they are provided merely to give you some idea of what is possible.
Also, here are two full proposals students submitted in the past as examples:
Submit the title and summary to firstname.lastname@example.org before the deadline. Within a few days, you will get some feedback on whether it seems doable.
Submit the proposal itself to email@example.com before the deadline, which is very strict. The proposal should be completely anonymous (your name should not appear anywhere in the proposal). If you use Word to write it, be sure Word does not secretly embed your name in the file, which is the default. You have to disable this by clicking on
Tools > Options > User Information
and clearing all the fields. You can check by running the UNIX 'strings' program on the .doc file and .pdf file to see if your name appears anywhere. All the proposals will be forwarded to the rest of the group for (blind) cross-reviewing. If there are too many students, they will be divided into multiple sections and you have to review those only from your section.
The proposal should be submitted as an attachment in PDF with file name <yourname>_proposal.pdf; the subject line should be: PDCS proposal from <yourname> (where <yourname> should be replaced with your name). For example:
As soon as all proposals are in, Andy Tanenbaum will run a script to randomize the file names and distribute the proposals and you are asked to write reviews for all proposals.
Writing the Reviews
Write a review of each proposal as a flat ASCII text file, with no markup, with a maximum length of 1 A4 page. Silly as it sounds, please write a plausible review of your own proposal as well. It will not count for your grade. It is needed because in the past, our clever students were able to deduce who wrote which review from the absence of a review (like the famous Sherlock Holmes story of the dog that did not bark). For example, if a student, say, Anna, had the habit of starting many sentences with "And then ..." and for proposal 4 none of the reviews had any "And then" sentences, the students were able to conclude that all the "And then" reviews were written by the author of proposal 4. If they could figure out that Anna wrote proposal 4 by some other means, they could then determine which reviews were hers. Also, trying to look at your proposal the way a reviewer might could be helpful.
To provide as much uniformity as possible for the reviews, use the NWO format given above. For example,
The very last line of your review should be:
where x is an integer from 1 to 10, with 1 being terrible and 10 being outstanding. Please stick very closely to this format. Make each of the headings a single line of text. Put one blank line before and after each heading, so all the reviews will have an identical look. Make sure the grade matches the text. If you say this is a crucial project and has to be undertaken immediately else the sky will fall down, don't give it a 7. Give it a 9 or 10. Likewise, if you say this is a totally useless project, and besides it was done 5 years ago and published extensively, don't give it an 8. Give it a 2 or 3. Likewise, if it is a great project provided you had a team of 20 expert professional programmers at your disposal but impossible for one AiO, it is not a 9. Basically, you need to take a stand: should the proposal be financed or not? A mushy review ("interesting work," 7) is not worth so much.
The review files should be named <yourname>_review_of_proposal_xxx.txt where xxx is the number of the proposal being reviewed. Please stick to this naming rigorously because the proposal will be randomized by a script that expects these names. For example:
Please put them in a zip file named after yourself, for example, Andreea_Oprescu.zip and mail it to me by the deadline.
The Second Class Meeting
In the second class, we will discuss the proposals. We will all sit around a large rectangular table. Student 1 will be asked to leave the room and then we will go around, with each remaining student saying what he or she thinks of the proposal. Then the student will be asked back and given a short summary of that was said. There will be no chance for a rebuttal so the proposal has to stand on its own merits, without further explanation. After we are done with student 1, student 2 will be asked to leave the room, and so on. Experience shows that it takes about 20-30 minutes per student, so expect a long class.
The grading for this class will be based on a linear combination of the following factors:
we tend to tune the weights as we get more experience with the course, but you should take all parts seriously.