Guidelines

During the course of the workshop, participants will submit several reports and make multiple presentations to their peers. The following offers guidelines for these.

Project Plan

Project plan should cover the following information:

  1. Description of project's goal and scope, including concrete success criteria.
  2. Definition of (at least) 3 incremental phases matching the reporting schedule, with concrete milestones and methods for testing these milestones.
  3. Short survey of pertinent literature, technology and and related projects.
  4. Description of requisite tools, resources and knowledge, and how they will be acquired.
  5. Discussion of alternatives in project scope and implementation choices, and how the choice is made.
  6. Discussion of risk factors and contingency plans.
  7. Preliminary experiments or toy experiments demonstrating basic familiarity and feasibility.

 

Final Submission Material

The final submission of the project should include the following material:

  1. The final report, the report should include the following:
    1. An abstract, 20-30 lines, summarizing the project and its results, assuming no knowledge beyond general CS knowledge. (This section can duplicate text from the following sections.)
    2. An longer introductory section explaining the task you wanted to achieve, its importance and motivation. This should be understandable by outsiders who have general CS knowledge but did not attend the workshop meetings and are not intimately familiar with the problem domain, so include a few paragraphs of background.
    3. A methodological part that gives the details as to how you implemented your solution. If your solution is complex, you may want to split it into two parts: one for high level description of the architecture of your code and the other giving more details. Note that you do not need to detail all classes and methods - only describe what you did to achieve the task.
    4. A part describing the plan you first devised and the how well you followed it.
    5. A part describing the results of your efforts. This should cover what you were able to do. This part should give some quantitative measures, i.e., some objective criteria to evaluate your success.
    6. Appendices related to low-level code documentation are welcome.
  2. The code you used in your project.
    1. The code should be understandable. Give your classes, methods and variables meaningful names.
    2. Ample high-level documentation: what are the files, modules and files, what do they do and how are they connected? This can be either inside the relevant source files, or as separate documents.
    3. Inside the code, properly comment things (e.g., definitions, expressions, algorithms) that are important or tricky.
    4. If relevant, a script / makefile for building your code. The documentation should clearly state how we can build your code on one of the university servers. Please detail any dependencies.
  3. Running examples
    You should provide some examples, preferably scripted (that is some code we can run, not going through UI), that show how to use your code. Preferably, these scripts will also recreate the results in your final report.
  4. Slides for your final in-class presentation
    These presentations will be 20 minutes long, so use no more than 15 slides.
  5. Web site on Drupal.
    The web site should start with an overview of the project (similar to the final report's abstract, so you can reuse that text). If possible, use graphical illustrations for your work, e.g., graphs or screenshots. It should also include your final report, code files, links to pertinent external resources (if relevant) and anything else you think would be helpful for people to understand and build on your projects. For documents and code you created yourself, include a copy as a Drupal attachment (do not link to external storage services).
    Note: If you have licensing or confidentiality concerns, please contact the course staff first.