In this course you will work in assigned teams of three or four (see group assignments in Canvas) to answer a predictive question using a publicly available data set that will allow you to answer that question. To answer this question, you will perform a complete data analysis in R and/or Python, from data import to communication of results, while placing significant emphasis on reproducible and trustworthy workflows.
Your data analysis project will evolve throughout the course from a single, monolithic Jupyter notebook, to a fully reproducible and robust data data analysis project, comprised of:
An example final project from another course (where the project is similar) can be seen here: Breast Cancer Predictor
In this final project milestone, you will:
Abstract project functions to their own software package (this means the code for your project will be split across two repositories)
Address any feedback received in earlier milestones or during the peer review
To further refine your project, you are going to split the code for your analysis into two version control repositories. One will be for your analysis, the other will be another separate repository, that will serve as a place to package up the functions you wrote in milestone 3. Decoupling these two code bases will allow for those functions to more easily be reused in future projects by you and others who might find them useful!
Your new version control repository for your packaged functions should:
be given a name relevant to the functions it contains (just like the data science packages you know and love are).
be in the DSCI-310-2024 organization: https://github.com/DSCI-310-2024
contain at least 3 or 4 useful functions that handle errors gracefully (you already wrote these - you need to now copy them from your analysis repository to the software package repository)
be well documented (use the three level of package documentation we learned about in class: function/reference docs, vignette/tutorials docs, and high-level package website docs)
have unit and integration tests (you already wrote these - you need to now copy them from your analysis repository to the software package repository)
use GitHub actions for continuous integration to run your tests, and continuous deployment to render your package documentation (if you are creating a Python package, you can even use continuous deployment to publish your package to PyPI!)
have a badge for a code coverage
have a README that describes your package from a high-level,
including where it sits in the package ecosystem
for the language you chose to write it in chose
(i.e., what other similar packages exist and how do they differ)
have a Software Licence that describes how you will permit others to use your work
have a code of conduct document that describes behavioural expectations of team interactions
have a contributions document that outlines how the team will work together (expected workflow practices)
You should update your the analysis code in your data analysis repository so that:
tests directory files that holds the tests and the helper data for those tests
(again, these should now exist in your package repository)Revise your data analysis project to address feedback received from the DSCI 310 teaching team from past milestones, as well as feedback received from the peer review. 50% of your final grade for this milestone will be assessing whether you have addressed this feedback to improve your project.
To help us easily, and correctly, assess this, please create a GitHub issue in your analysis project’s GitHub repository with the title “Feedback addressed”. In this issue describe any improvements you made to the project based on feedback, and point to evidence of these improvements. You can point us to evidence of addressing it by providing URLs to reference specific lines of code, commit messages, pull requests, etc. Be sure to add some narration when sharing these URLs so that it is easy for us to identify which changes to your work addressed which pieces of feedback.
You will be graded on a sliding scale for this, the more improvements you make, the higher your grade for this part of the milestone will be. The improvements should be at least one per team member, and they should significantly improve the project. This minimum could earn at most 37.5/50. To earn more, you need to exceed these minimum improvements.
Just before you submit the milestone 4, create a release on your analysis project repository on GitHub and name it something like 3.0.0 (how to create a release). This release allows us and you to easily jump to the state of your repository at the time of submission for grading purposes, while you continue to work on your project for the next milestone.
Also create a release on your software package repository (do this manually if you are not using an automated tool for this in your continuous deployment).
You will submit a PDF to Gradescope for milestone 4 that includes:
Everyone should contribute equally to all aspects of the project (e.g., code, writing, project management). This should be evidenced by a roughly equal number of commits, pull request reviews and participation in communication via GitHub issues.
Each group member should work in a GitHub flow workflow; where they create branches for each feature or fix, which are reviewed and critiqued by at least one other teammate before the the pull request is accepted.
You should be committing to git and pushing to GitHub.com every time you work on this project.
Git commit messages should be meaningful. These will be marked. It’s OK if one or two are less meaningful, but most should be.
Use GitHub issues to communicate to their team mate (as opposed to email or Slack).
Your question, analysis and visualization should make sense. It doesn’t have to be complicated.
Your analysis should be correct, and run reproducibly given the instructions provided in the README.
You should use proper grammar and full sentences in your README. Point form may occur, but should be less than 10% of your written documents.
R code should follow the tidyverse style guide, and Python code should follow the black style guide for Python)
You should not have extraneous files in your repository that should be ignored.