Report

Your written report must be completed in the report.qmd file and must be reproducible.

Before you finalize your write up, make sure the printing of code chunks is off with the option echo: false in the YAML.

The mandatory components of the report are below. You are free to add additional sections as necessary. The report, including visualizations, should be no more than 10 pages long. There is no minimum page requirement; however, you should comprehensively address all of the analysis in your report.

Be selective in what you include in your final write-up. The goal is to write a cohesive narrative that demonstrates a thorough and comprehensive analysis rather than explain every step of the analysis.

You are welcome to include an appendix with additional work at the end of the written report document; however, grading will largely be based on the content in the main body of the report. You should assume the reader will not see the material in the appendix unless prompted to view it in the main body of the report. The appendix should be neatly formatted and easy for the reader to navigate. It is not included in the 10-page limit.

Report components

Introduction

Identify the project motivation, data, and objectives. What is the context of the work? What problem are you trying to solve? What are your main conclusions?

Justification of approach

Describe the product(s). What did your team create? Who is the intended audience? How will the product(s) meet their needs?

Data description

If using real-world data, describe it. A good model for this is presented in Gebru et al, 2018. Answer any relevant questions from sections 3.1-3.5 of the Gebru et al article, especially the following questions:

• What are the observations (rows) and the attributes (columns)?
• Why was this dataset created?
• Who funded the creation of the dataset?
• What processes might have influenced what data was observed and recorded and what was not?
• What preprocessing was done, and how did the data come to be in the form that you are using?
• If people are involved, were they aware of the data collection and if so, what purpose did they expect the data to be used for?

Design process

Summarize your design process for the product(s). Explain the key design challenges you encountered in creating the main product(s). What were the most important considerations your team faced in designing and constructing the final product?

Limitations

Assess the limitations of your work. What hurdles did you fail to overcome? If you had the opportunity to do this again, how would you improve on your product(s)?

Acknowledgments

Recognize any people or online resources that you found helpful. These can be tutorials, software packages, Stack Overflow questions, peers, and data sources. Showing gratitude is a great way to feel happier! But it also has the nice side-effect of reassuring us that you’re not passing off someone else’s work as your own. Crossover with other courses is permitted and encouraged, but it must be clearly stated, and it must be obvious what parts were and were not done for 5001. Copying without attribution robs you of the chance to learn, and wastes our time investigating.

Appendicies

You are welcome to include an appendix with additional work at the end of the written report document; however, grading will largely be based on the content in the main body of the report. You should assume the reader will not see the material in the appendix unless prompted to view it in the main body of the report. The appendix should be neatly formatted and easy for the reader to navigate. It is not included in the 1000-2000 word limit.

You should submit your appendix(-ces) in the appendices.qmd file in your project repo.

• At minimum, you should have an appendix for your data cleaning. Submit an updated version of your data cleaning description from phase II that describes all data cleaning steps performed on your raw data to turn it into the analysis-read dataset submitted with your final project. When rendered, it should output the dataset you submit as part of your project (e.g. written as a .csv file).
• (Optional) Other appendices. You will almost certainly feel that you have done a lot of work that didn’t end up in the final report. We want you to edit and focus, but we also want to make sure that there’s a place for work that didn’t work out or that didn’t fit in the final presentation. You may include any analyses you tried but were tangential to the final direction of your main report. Graders may briefly look at these appendices, but they also may not. You want to make your final report interesting enough that the graders don’t feel the need to look at other things you tried. “Interesting” doesn’t necessarily mean that the results in your final report were all statistically significant; it could be that your results were not significant but you were able to interpret them in an interesting and informed way.

Organization + formatting

While not a separate written section, you will be assessed on the overall presentation and formatting of the written report. A non-exhaustive list of criteria include:

• The report neatly written and organized with clear section headers and appropriately sized figures with informative labels.
• Numerical results are displayed with a reasonable number of digits, and all visualizations are neatly formatted.
• All citations and links are properly formatted.
• If there is an appendix, it is reasonably organized and easy for the reader to find relevant information.
• All code, warnings, and messages are suppressed.
• The main body of the written report (not including the appendix) is no longer than 10 pages.

Evaluation criteria

Category	Less developed projects	Typical projects	More developed projects
Introduction	Less focused and organized. They may jump to technical details without explaining why the products are important. Research questions or project objectives are not clearly stated.	Provides background information and context. Introduces key terms and data sources. Outlines research question(s) or project objectives.	All expectations of typical projects + clearly describes why the setting is important and what is at stake. Even if the reader doesn’t know much about the subject, they know why they care about your results and products.
Justification of approach	Simple description of some aspects of the dataset, little consideration for sources. Design process is not clearly summarized. Hard to understand what design choices were made during the project.	Defines the deliverable(s) constructed for the project. The chosen approach is clearly explained and justified. When used, data is described in sufficient detail. Design process summarizes the final product.	All expectations of typical projects + credits and values data sources. Uses the provided template for the data description. Description of the design process includes not just the final product, but also addresses decision points and alternative paths not taken.
Limitations	The limitations are not explained in depth. There is no mention of how these limitations may affect the meaning of results or the quality of the product(s).	Identifies reasonable limitations to the scope of the work. Addresses potential biases in the data or model assumptions. Proposes potential remedies in future iterations of the project.	All expectations of typical projects + creatively identifies potential harms and data gaps, and describes how these could affect the meaning of results, as well as the impact of results on people. Design process clearly shows how the team considered potential limitations and worked to minimize their impact in the final product(s)