Skip to content

final_project.md

Latest commit

 

History

History
32 lines (26 loc) · 3.21 KB

final_project.md

File metadata and controls

32 lines (26 loc) · 3.21 KB
Raw

Final Project

Dates

  • Final project proposal due on March 30th
    • The writeup for this can be very short (e.g. 1/2 page or whatever), just so we can all agree on whether it is acceptable.
    • It will not be graded. If we think that the proposal is inappropriate, or want some clarifications, we will tell you that week
  • The final project is due April 20th

Requirements

We will accept a wide-range of proposals on many different topics. The key requirements are that:

  • There is some element of practicing your coding skills.
  • The project must be submitted as a git repository.
    • In addition to your code and other files, please include a brief README.md
    • If you make your git repository public, we strongly encourage you to include a LICENSE file, so that others know whether and under what conditions they can modify and redistribute your code. If you want others to use your code, the Julia community prefers the MIT license. You could also consider a copyleft licenses, like the GPL, or, at the other extreme, retaining exclusive copyright.
  • The practice is on a tool with the intention of learning something which would be useful for doing your own research (e.g. replicating an estimation procedure, adding some new examples to a public package for some econometric procedure, doing a web scraping exercise to generate new datasource, etc.)
  • While it is not encouraged, we will consider joint projects with other classes - but make sure to tell us your plans, and understand our expectations of the amount of work will be adjusted.
  • Group projects are allowed, but make sure to get our approval.
    • Groups must use github (or another git platform) to coordinate their work. This means creating a repository, planning the project by creating issues, group members working on the issues in separate branches, creating pull requests, merging the work together, and then repeating as needed.

Size of Project and Grading Criteria

You should target roughly a similar length as the amount of code in one of the Jupyter notebooks used for lectures. If you are contributing to an open-source project, then the contribution can be significantly smaller as it would require more work to iterate.

If you want to get the highest possible marks on the project, you will need to:

  • Create a thorough set of tests for your project
  • Carefully create tests for each individual function rather than writing out the code all the way to the solution.
  • Ensure that the project is reproducible (i.e. someone else can run the code without any modifications)

Your project can be a contribution to an existing open-source project. For contributions to existing projects, we will consider more modest goals since we realize it adds rigors of testing/documentation/etc.

Presentation

The in-class presentation on April 1st and 8th are meant to help you get started with your project. It should be 10 minutes long per person. It can cover any aspect of your project. A summary of your planned project is fine, but you can also choose to focus on one aspect, or something like a review of a tool or technique that you think might be useful for your project.