-
Milestone 1: On GradeScope, the Grading comment: File contents not clear enough for someone to understand how contributions to the project should be made
-
Milestone 1: On GradeScope, the Grading comment: The analysis notebook (.ipynb or .Qmd or *Rmd) should be in a sub-directory called something sensible, such as analysis, src, notebooks, docs, etc, to aid in the discoverability of this file, and related ones. Having too many files in the project root makes the project organization less understandable and can lead to longer activation times to productivity for collaborators (including future you!). Files such as .DS_Store and .ipynb_checkpoints should not be committed.
-
Milestone 1: On GradeScope, the Grading comment: Important methodology descriptions missing (e.g., did not explain in narrative what metric was being used for model parameter optimization).
-
Review comments from jasonmiee: Model Performance: I suggest adding a sentence that clarifies why RMSPE was used as the scoring metric for this analysis. (i.e Did you use this metric because you wanted an interpretable error metric that has the same units as the response variable?)
-
Milestone 2: On GradeScope, the Grading comment: Could not reproducibly run the analysis because the computational environment cannot be recreated from the provided instructions and/or environment specification files. 'No module named 'jupyter_core''
-
Review comments from vrudhgarg: Environment Setup: It seems like the environment setup with docker compose up is not working as expected. Check the Docker configuration to resolve this. Automation Issues: Automation seems to be having problems with this Docker environment.
-
Review comments from Arc-Celt: Currently I failed to use docker compose up to reproduce the data analysis, with two ModuleNotFoundError issues for conda and jupyter_core. It would be great if you could take another look and see how to resolve this. I recommend revisiting your envirnonment.yml, the corresponding conda-linux-64.lock, Dockerfile and docker-compose.yml files to ensure all dependencies are correctly included.
-
Review comments from jasonmiee: Reproducibility: I wasn't able to successfully build the docker container using docker compose up to reproduce the data analysis (see screenshot below for the error message). There were mainly 2 ModuleNotFoundError issues for conda and jupyter_core. Please try to resolve this by reviewing all relevant environment files.
-
Review comments from gurmehak:
- Analysis Report Quality: The report is concise and very readable overall, but the code chunk in the summary section of your analysis report could be off-putting for someone without a technical background. I believe you tried to suppress the code chunk with echo: False in that particular code block, but it didn't render correctly in the final report. To ensure this is applied globally, include the command in the YAML section of the QMD file. This way, you won't have to specify it in each code block to prevent the code display.
- File Structure: Great work on organizing the file structure - it’s very clean and generally easy to navigate. I did get a bit confused with identical output figures saved in different folders. You have placed your figures in both the results and report/fig-html folders, and raw data in data and reports/data folders. Ideally, the reports folder should only contain files that are ready to be shared as deliverables. Please consider removing data and figures from reports folder. You can also consider creating more subfolders (for raw, train/test splits, processed data, etc) within the data folder to better organize the contents and make processed data more readily available for use
-
Review comments from Arc-Celt: I noticed that the code chunk used for the data validation check is still visible in your final PDF report, even though you applied #| include: false and #| echo: false in your script. Hence, it's recommended that you try how to suppress that chunk as well.
-
Review comments from vrudhgarg:
- Guidelines on Style: The code would benefit from more comments and explanations. Documenting the code will help readers understand why certain parts of the code work the way they do.
- Research Question Clarity: The research question should be worded more clearly so others can understand it clearly when reviewing the project.