I encourage brevity, hence the word limits for several of the writing tasks. In a single-space format (12pt Times, one-inch margins), a page is about 400 words.

Submit .pdf files only: not Word and not plain text. Sometimes we will print your submissions with a command such as "lp */*.pdf". What's not printed won't be graded.

From your team, please select the unity ID that is alphabetically (or alphanumerically) the lowest.

• Have the team member with ID submit. For example, for team members abc89 and acb77, only abc89 ought to submit the assignment.
• Name all your files according to the same unity ID. For example, for team members abc89 and acb77, a submission file would be abc89.pdf.

In places you may see references to R0, although we are trying to write it only with letters (e.g., R0a, R0b, R0c). The first project proposal, whether labeled R0 or R0a, is mandatory.

The remaining R0x reports are optional with zero points.

R0a is mandatory but not graded as such. The points you receive for the mandatory initial proposal, whether labeled R0 or R0a, are the same as the points you receive for R1.

The final proposal, R1, is mandatory and is graded.

R2 is optional and not graded.

R3 is mandatory and graded.

The term paper is mandatory and graded.

Below, I have described the main section headers for project proposals, interim reports, and final reports. Use the same section headers in your submission. The word limits are guidelines to be treated as upper bounds. You can, and generally should, augment your submissions with pictures. If you have one or more pictures you would need fewer words. You can have a picture do double duty by having it respond to more than one section.

Submit each proposal and report as a single PDF document. Word, for example, doesn't work.

The motivation behind R0a is to have you form your team and identify a direction even though you might not have all the details worked out. Think of it as approximating R1, which is graded. Look ahead and see what R1 asks for.

For R0a, it is fine to submit two ideas and I can advise you on which is better for this course. Subsequently, please submit exactly one idea and deliverables for that idea.

Just as each published article has a title, your project proposals and other reports (each idea if you happen to submit more than one) should have a short, pithy title that says what you propose to do. Perhaps seeing titles of published articles will give you an idea of what title to use for your work.

Just as each published article lists its authors, your project proposals and other reports should list the names of all team members. For grading or any other course-related purpose, the order of names doesn't matter. If you extend the work into an external report or publication, you can discuss the order among the authors.

1. What problem are you addressing? (200–400 words)
   • Problem description
   • One or two example scenarios.
   • State one or two scientific hypotheses
2. Why is this problem important? (50 words)
3. How will you address this problem? (50–300 words)
   • Just an outline is fine
4. What are some alternatives and how do you justify your approach? (200 words)
   • Key justifications
5. How will you evaluate your approach? (50 words)
   • Optional: brief thoughts, if any

In addition, I will give you at least one opportunity to submit a version of this report for comments, which will not be graded. In the course materials, such optional versions are called R0b and R0c. If you choose to submit one, follow the R1 guidelines.

1. Shoot for about two pages.
2. Relevant literature (50–100 words)
   • Identify one or two papers that you will focus on. These papers should be published in some peer-reviewed forum. I am looking for a complete bibliographic reference, including full names of all authors, title, journal or proceedings where published, year, DOI or URL. It is a good idea if these papers are recent, i.e., published within the last three years. If the first paper you find is older, you can check on Google Scholar which papers have cited that paper and determine if any of the more recent ones are suitable for your work.
   • A brief statement of what you find relevant in these papers for the problem you are addressing.
   • Have you obtained the dataset and code for these papers?
3. What problem are you addressing? (400 words)
   • Describe at a high level, clearly and concisely, the overall problem you seek to address.
   • Include one or two example scenarios.
4. Why is this problem important? (50 words)
   • If you build an application or platform, what are its intended usage scenarios? Who will care to use what you create and why?
   • Describe any special features of your application or platform. For example, if dialog context is important, then elaborate on what features of dialog you employ (or exploit)? Why does the problem naturally fit with dialog—who would be the users and beneficiaries of your approach (members of the public; enterprise managers; plumbers) and how will your proposed solution reduce user effort, enhance usability, preserve confidentiality, or what else?
   • If you perform data analysis, explain the kinds of facts you hope to discover or the hypotheses you will try to verify, what makes those facts or hypotheses interesting, what datasets you will use, how you will prepare the datasets, and what kinds of analyses you will carry out.
   • If you will conduct a simulation, explain what hypotheses you will try to verify, what makes those hypotheses interesting, and how would your simulation provide the information needed to prove or disprove those hypotheses.
5. How will you address this problem? (300 words)
   • Just an outline of the main steps. Don't overly worry about minor implementation details at this stage.
6. What are some alternatives and how do you justify your approach? (200 words)
   • Key justifications
7. How will you evaluate your approach? (100 words)

This report would be a good idea if you had a change of direction or encountered difficulties in carrying out your original proposal.

Using up to an additional three pages, enhance R1 with a description of the design of how your implementation is proceeding. Concisely specify the main representations and reasoning you expect to develop, explaining the key aspects of your design along with any rationales. Include any preliminary, tentative results.

1. What problem are you addressing? (400 words)
2. Why is this problem important? (50 words)
3. How will you address this problem? (1000 words)
   • Detailed description
4. What are some alternatives and how do you justify your approach? (200 words)
   • More extensive analysis than in the proposal
5. How are you evaluating your approach? (300 words)
   • List use case details

Refine each component as necessary; enhance those specified below.

1. What problem are you addressing? (400 words)
2. Why is this problem important? (50 words)
3. How will you address this problem? (1250 words)
   • Complete description
4. What are some alternatives and how do you justify your approach? (400 words)
   • Complete analysis, including challenges you encountered and why they surprised you
5. How did you evaluate your approach? (400 words)
   • List use case details
   • Accompanied by a demo
6. What are your main findings of the project? (300 words)
   • Describe what the reader should take away from your exercise.
   • What are the implications of your results? (e.g., on practice or on society)

1. In up to two additional pages beyond R3, reflect upon your project work with respect to
   • The limitations of your problem formulation, hypotheses, methods, and findings
   • The prerequisites for taking your findings and applying them in practice
2. If you are preparing a formal paper for publication that addresses the above points, you can submit that paper instead provided you highlight or otherwise identify the sections where it addresses these points.