1. Setup GitHub actions workflow for continuous integration
   Setup GitHub Action workflows to check your packages:

build
test suite
code style (optional)
These workflows should run on every push to any branch. For Python we recommend using the ci-cd.yml file from the py-pkgs-cookiecutter repository. For R, we recommend using the check-standard.yaml and test-coverage.yaml files from the GitHub Actions for the R language repository.

Important note! Since the beginning of the course, there has been significant development of the cd job in ci-cd.yml. Please copy over a new version of the file from here, and remove the {% raw %} and {% endraw %} tags (they are there to tell the Cookiecutter to not modify the code between them), as well as replace the {{ cookiecutter.THING }} templates with the corresponding value for your project.

2. Setup GitHub actions workflow for continuous deployment
   For Python packages, setup GitHub Action workflows so that the package is built and published to PyPI when pull requests are accepted to the main branch. The workflow should also use semantic versioning to automatically version the published releases. For Python we recommend using the ci-cd.yml file from the py-pkgs-cookiecutter repository.

For R packages, setup GitHub Action workflows so that documentation changes to the pkgdown website are automatically rendered and published (i.e., you do not need to render the documents locally on your laptop and push them to view them on the published website). For R, we recommend using the pkgdown.yaml file from the GitHub Actions for the R language repository.

3. Choose a suitable license to your package and justify your choice
   Examine the license for your project and consider whether this is the choice you want to make, or whether you want to change the license. Discuss and reason the license choice in an issue in your package repository. All team members should make meaningful contributions to this discussion in the GitHub issue.

4. Address feedback to improve the project
   Revise your package to address feedback received from the DSCI 524 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 use create the commit messages that address the feedback something like this:

fix: Feedback addressed by ...
Once your continuous development is setup, this will update the CHANGELOG.md automatically, and the TA’s will be able to easily find the changes that addressed feedback.

If you already made changes before you know to write commit messages this way, you can open an issue and list the changes there. If you do this, please add a link to this issue in the PDF you submit to Gradescope.

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.