Project overview

The landscape of applied deep learning is too diverse to cover everything, and every models and packages all have their own unique aspects and implementations. The Final Project will give you the chance to explore a topic of your choice and specialize in one class of analytical method. By working with real data of your choosing you can examine questions of particular interest to you.

The broad objectives for the project are to:

  • Identify the problems and goals of a real situation and dataset.
  • Implement your analysis choices on the dataset.
  • Interpret the results of the analyses.
  • Contextualize those results within a greater scientific and social context.
  • Work effectively to manage a project as part of a team.

To accomplish this you will work in teams of 2 students to conceive of and carry out an analysis project. You will find in your future careers the need to work on projects in groupcs frequently.


Project milestones

  • βœ… Register your group by May 8
  • βœ… Proposal Lightning Talk on May 9
  • βœ… Written Proposal Submission by May 13
  • βœ… Paper Reading Presentation on Week 7 or 8
  • βœ… Peer Review/Feedback Session on May 28
  • πŸ”˜ Milestone Presentation on Week 9 or 10
  • πŸ”˜ Report Submission & Github Repo Finalized by June 12

Proposal Lightning Talk

  • Casual, 5 mins talk on 5/9 in class, graded by completion
  • Purpose: Instructor & TA to give early feedback and suggest places to get data

Written Proposal

  • 5%, 1 to 1.5 page long, submit by 5/13 on Gradescope
  • Here is a template for the Project Proposal
  • For the Project Proposal you are not expected to have already done any analyses for the proposed project, but what you submit should be a plan for what you will answer and what data you would analyze for the project.

Paper Reading Presentation

  • 12%, ~15 mins, during class on Week 7 or 8
  • Here is a template for the Paper Presentation
  • The presentation should include the following:
    • The main research question of the paper (a couple sentences)
    • The data used in the paper (second focus of the presentation)
    • The methods used in the paper (top focus of the presentation)
    • The findings of the paper
    • Some possible discussion points
      • What are some strong points of the paper?
      • What are some weak points of the paper?
      • What are some possible extensions/applications/improvements of the paper?
      • Your takeaways or things learned

Project Peer Review/Feedback Session

  • 3%, 5/28 in class using a Google Form
  • Purpose: Give feedback to other groups
  • Before review day: Each group needs to send us a link to a public github repository where you are storing relevant code and documentation for your project. You must send us this link by 5/24 on Gradescope here.
  • To facilitate meaningful review, your github should have:
    • A README file describing an overview of the project, as well as information about analysis notebooks and a description of results so far.
    • The repository should contain any relevant code you have used so far (including scripts to run tools, notebooks to visualize results, etc.)
    • You should also include a section at the end detailing remaining work to do and challenges you’d like to discuss with your peers.
  • Logistics on review day:
    • Each student is assigned to review the work of one group. See your assignments here.
    • You will be responsible for filling out this Google Form. We recommend you finish this in class, but it is not technically due until 11:59 on Friday 5/31.
    • From 7:00-7:25, reviewers of odd numbered groups will meet with those groups to share and discuss feedback, including objectives of the project, works done so far, challenges faced, and upcoming tasks.
    • From 7:25-7:50, we will switch and even numbered groups will be reviewed.
  • Grading – You will be graded by:
    • 50% for providing something meaningful in your own Github repository for other students to review.
    • 50% based on the review form you submit. You should do your best to provide an honest review and also meaningful comments to help the other team improve their project.

Milestone Presentation

  • 10%, 8 mins, during class on Week 9 or 10
  • Here is the schedule
  • The presentation should include the following:
    • A brief overview of the project
    • A summary of the data you are using
    • A summary of the analysis you have done so far
    • A summary of additional analysis you plan to do
    • Q&A from the audience for feedback

Project Code Github Repository

  • 5%, finalized by 6/12
  • Github Repo Template
  • Your github repository should be public and you are storing relevant code and documentation for your project. It should have:
    • A README file describing an overview of the project, as well as information about analysis notebooks and a description of results.
    • The repository should contain any relevant code you have used (including scripts to run tools, notebooks to visualize results, etc.) as well as URL links to any data you have used.

Project Report


Project Managment

Agile is a product management technique that we recommend you follow this quarter when executing your project. Waterfall development will not work – there is simply no time for you to sit idle for weeks while your partners work. All group members need to be active each week.

When creating the schedule for your proposal, you should create a list of tasks that each group member will do each week. Write your schedule in such a way that:

  • Each group member can work in parallel. That is, Person B should not have to wait for Person A to finish a task before they can start working. If Person B is working on a feature that depends on Person A’s output, Person B can use synthetically-created data (or something similar) as a placeholder for Person A’s output until it is finalized. (For a concrete example, Person A may be writing scripts that clean raw data, and Person B may be building a machine learning model.)
  • Each group member is working on a different task than in the previous week. It’s totally fine if a particular task takes two weeks to complete, but the description of that task in your schedule should be different for both weeks, to reflect the breakdown of that task into smaller subtasks.
  • Each group member knows what everyone else is actively working on. Not only will this held each group member accountable, but it’ll also give other group members the opportunity to help resolve issues with tasks that weren’t initially assigned to them.
  • The team, as a unit, decides what the plan for the next week is, and if any part of the existing schedule needs to change. To achieve all of these goals, it will be necessary to be in regular communication with your group, not just in section, but in your (required) separate weekly meetings and asynchronously.

Advice

The main pieces of advice are:

  • Start early
  • Work consistently
  • Be a good teammate
  • Work as a team
  • Make use of group chat
  • Meet weekly to give updates & break down tasks
  • Seek advice when you are unsure, and see it early and often!
  • Talk to your TA and instructor - we’re here to help!
  • Start early!!!!!