Team Project Guidelines

1.0 Introduction

The team project component of SIADS 593 Milestone I is designed to encourage you to both apply and extend the skills, tools, techniques, and knowledge that you’ve gained in your prerequisite MADS courses to a new problem.

Overall, the goal of this project is to provide you with an opportunity to bring your unique interests, creativity and ingenuity into alignment with one or two team members and demonstrate your team’s ability to apply data science skills and concepts on public datasets of your choice.

In particular, the project should show off your team’s ability to take a minimum of two data sets possessing different features and/or access methods and clean and manipulate them in order to extract a useful byproduct: something more than you could have gotten from either data set by itself. The cleaning and manipulation could involve filtering, format conversion, handling missing or noisy data, matching records from one data source with corresponding records in the other, and so on, and must make significant use of the programming tools and techniques covered in prior MADS courses.

❗ You are not expected to use advanced tools and techniques from courses that are not prerequisites of Milestone I (e.g., machine learning, causal inference, etc.), and in fact you are discouraged from doing so as neither your peers nor your instructors may be in a position to offer helpful advice.

There are several steps involved in the project:

1. Problem formulation
2. Team formation
3. Selection of data sources
4. Project proposal creation
5. Faculty mentor assigned (by the teaching team)
6. Peer feedback on project proposals
7. Final project report + code
8. Peer feedback on project reports

2.0 Problem formulation and team formation

Team formation and the selection of project topics and datasets are student responsibilities. We suggest that you advertise your interests via Slack and coordinate via the Project proposal and team tracker Google Sheet (see Coursera week 01 readings for the link to the document).

We expect that all teams will consist of two to three (2-3) students. The maximum team size is three (3) students. Working alone or working in groups of more than three is not permitted. It has been our experience that working in pairs or groups of three balances high-quality work with the amount of work each person needs to do to complete the project. Each of the steps is described below.

Before starting work on the actual project, you’ll write a short project proposal that is meant to be a high-level summary and does not need to contain technical details or code.

Once you have shared your project proposal, a faculty member from the instructional team will be assigned to your team as your primary mentor. This is the person who will help guide you through the project and you should expect to be in weekly contact with them.

You will then review your peers’ proposals, and they will review yours. You can then fine-tune your project based on the feedback you receive. Requiring the proposal to be submitted early is intended to get you thinking about questions and datasets you’re interested in, and how those might be answered with the tools you’ve been exposed to in previous classes.

3.0 Proposal (30 points)

You must use a copy of the project proposal template to create your project proposal (see Coursera week 01 readings for the link to the document, which you must copy).

Your proposal will be reviewed by a minimum of two peers from the class and your team is encouraged to take their feedback into consideration when you work on your project.

❗ When your project proposal is ready for review please provide a link to it via the project tracker and coordination spreadsheet. Be sure to enable commenting on your Google Doc in order to permit peer reviews.

Rubric: Proposal

4.0 Proposal peer review (30 points)

You must sign up and review a team project proposal. Note that your proposal grade will not be based on the content of your peers’ reviews.

Peer reviews will take the form of comments on the Google Doc containing the proposal and will be coordinated via the Google sheet.

The purpose of the peer review is threefold:

• gain experience reviewing a proposal,
• learn about other work going on in class,
• get feedback on how to make your project better.

Your review comments taken together should span several paragraphs and exhibit the following points:

• professional: what would a co-worker think about your review?
• pleasant: courtesy goes a long way
• helpful: what sort of advice would you want?
• scientific: focus on facts, not opinions
• realistic: keep scope in mind
• empathetic: how would you feel if you received the review you wrote?
• organized: make it easy for the recipient to follow your train of thought

💡 A useful approach when writing a peer review is the “two stars and a dog” approach. In other words, highlight two things that the authors did well and identify one area where they might spend some time improving their work (and make constructive suggestions about how to do so).

Rubric: Proposal peer review

5.0 Team collaboration (30 points)

Collaboration is an important skill to develop as data scientists. We will look for evidence of sustained collaboration that leads to a final project that is more than any one individual could have produced on their own.

Rubric: Team collaboration

6.0 Status updates (30 points)

It has been our experience that keeping in regular contact with your faculty mentor is the best way to ensure success with your project, so we encourage you to periodically check in with them. Ideally, these check-ins will take the form of meetings held at least once every two weeks. Alternatively, you can check in using chat on Slack, but at least one video-based synchronous meeting (e.g., Zoom, Google Hangouts) is required.

Rubric: Status updates

7.0 Project report (450 points)

First and foremost, following the individual original work policy stated at the start of the course, the topic and questions you ask in your project must be of your own invention. If you used ideas from a particular web site or previous project, or did your project as part of an existing research collaboration, you must identify your sources and/or collaborators and provide links and citation(s) where appropriate.

7.1 Report length

The report must be no more than 11 pages in length (inclusive of code snippets, visualizations, references, etc.). The main body of the report, including title, must not exceed 10 pages in length (page 11 is limited to the statement of work and endnotes).

The final report must be delivered as a PDF. Font size must be at least 10 point and margins must be at least 0.5" all around. Avoid the use of a cover page. Instead, include the title and authorship at the top of the first page. The page limit will be strictly enforced: we will only consider the first 11 pages when assessing your report.

7.2 Report format

Pages 01-10: main body of report (including title and authors)
Page 11: statement of work, endnotes (if any)

The format of the report is semi-flexible — you can include additional information (keeping in mind the page limit), but at a minimum the report must include the following sections. Please use section headings in your report that correspond to the following sections, other than “Spelling, grammar and style”.

7.2.1 Motivation (15 points)

Briefly state the nature of your project and why you chose it. What specific question or goal did you try to address?

Rubric: Project motivation

7.2.2 Data sources (30 points)

Describe the properties of the two dataset(s) or API services you used. Be specific. Your information at a minimum should include but not be limited to:

• where the datasets or API resources are located,
• what formats they returned/used,
• what were the important variables contained in them,
• how many records you used or retrieved (if using an API), and
• what time periods they covered (if there is a time element)

For example, if you downloaded data or used API services, you should state the specific URLs to those files or resources. It should require zero effort on the part of the teaching team to find and access the exact resources you used if we need to do so.

Rubric: Project report data sources

7.2.3 Data manipulation methods (100 points)

For each of your two sources, describe how you manipulated the data. Briefly describe the workflow of your source code and what the main parts do. Other questions that you may want to address might include the following. Note that not all questions are applicable to all projects, nor is this an exhaustive list of topics to include in this section.

• How specifically did you need to manipulate the data?
• How did you handle missing, incomplete, or incorrect data?
• How did you perform conversion or processing steps?
• What variables and steps did you use to join the two data resources to perform your data analysis?
• What challenges did you encounter and how did you solve them?

Rubric: Project report data manipulation methods

7.2.4 Analysis (60 points)

A key goal of this project is bringing together two different data resources to answer an interesting question or find a new insight that could not have been answered with either data resource alone (which you summarized in the previous section). Now describe the analysis steps you performed on your combined dataset to address that goal/question. Be specific, and include references to key functions or parts of your code.

• What interesting relationships or insights did you get from your analysis?
• What didn’t work, and why?

Rubric: Project report analysis

7.2.5 Visualizations (50 points)

Rubric: Project report visualizations

7.2.6 Statement of work (15 points)

Page 11 comprises a statement that describes the contribution that each team member made to the project. You should explain how you collaborated or cooperated with each other. Page 11 can also be used for the inclusion of endnotes, if any.

Rubric: Project report statement of work

7.2.7 Spelling, grammar, and style (30 points)

The best papers, and in some cases even some of the best ideas, can be undone by inattention to spelling, grammar, and style. Please check your report for spelling and grammar (most word processing and presentation software has built-in spelling and grammar checkers). We strongly suggest that you proofread your work with “fresh eyes” – that is, take a break from your writing, step away, and then return to review your work. For matters of style, we strongly recommend following the advice of William Strunk and E.B. White (the essayist and author of such children’s favorites as Stuart Little and Charlotte’s Web) in their classic work The Elements of Style.

Rubric: Project report spelling, grammar, and style

7.3 Code (150 points)

Please submit “polished” Jupyter *.ipynb notebooks and supporting Python *.py modules (if any). The notebooks must:

• Present a coherent, computational narrative of your data manipulation and analysis.
• Run without errors from top to bottom.
• Run without warnings from top to bottom.
• Include a mix of code and Markdown cells.
• Include comments in the code, whenever appropriate.
• Avoid generating excessive output (i.e., more than 10-15 lines per cell).

Deciding on the number of notebooks to produce is a team decision. You might choose to separate the data acquisition, cleaning and manipulation, and analysis tasks into multiple notebooks in order to narrow the code focus and control for length. A potential downside is code repetition across the notebooks, the likelihood of which increases for the inexperienced and those working under tight time constraints (adoption of code modularization strategies can mitigate this concern). Another option is a single notebook. Opting for this approach places a premium on notebook organization in order to ensure that the reader is able to sensibly traverse an otherwise sprawling set of cells. Regardless of the number of notebooks, the code must be organized in a manner that facilitates comprehension and reuse.

If you have yet to do so consider adopting the following best practices:

Rubric: Project report code

7.4 Report submission

❗ Please submit the team project ZIP archive on or before the due date. Failure to do so will trigger late penalties as described in the Syllabus.

Team project assets must be submitted in a *.zip file. Structure the ZIP archive as follows:

Requirements

1. Zip archive filename: You must utilize you Coursera project team name as the name of your ZIP file formatted as follows:

   Zip archive: < team number >-< uniqname >-< uniqname >[-< uniqname >]_[YYYY][fall | winter | sprsum].zip

   Example: 00-arwhyte-cteplovs-2023winter.zip

2. Team project report: Your project report must be named the same as your Coursera team name and must be provided as a PDF (e.g., 00-arwhyte-cteplovs-2023winter.pdf). Remember, the project report must be no greater than 11 pages in length. Keep this in mind if you are planning to generate the PDF from a Jupyter notebook. We strongly recommend that you use Google Docs or Slides, Microsoft Word or Powerpoint, or some other word processing package to generate your final PDF.

3. Source code and data: Place all source code files (e.g., Jupyter notebooks, Python scripts, or other code) in a src/ directory in your zip file. Place all data files in a src/data/ directory in your zip file.

   ❗ Do not submit large data files as part of your zip file but be sure that the teaching team and your classmates can access the data. If a data file is over 10 MB or not available in file form, create a sample file containing the first 100 records. If data was retrieved via an API document the URL endpoint(s) in the relevant Jupyter notebook(s) or Python script(s).

   💡 Choose names for your notebook(s), Python *.py script(s), and/or module(s) that convey to the reader each file’s purpose.

   ZIP archive structure

   00-arwhyte-cteplovs-2023winter.zip
   src/
       some_notebook.ipynb
       another_notebook.ipynb
       some_script.py
       some_module.py
       ...
       data/
           some_dataset.csv
           another_dataset.json
           sample_data.csv
           ...
   

You will also be required to submit your team project report PDF to a gallery tool that will facilitate the sharing of your report with the class. The details of this will be announced during the course.

7.5 A word about faculty review of pre-submission versions of reports

In the past, some teams have requested a review of their final project before it is submitted. We cannot provide detailed feedback on reports, although we are happy to respond to specific questions about the project as part of the regular check-in process described in an earlier section of this document.

8.0 Project report peer feedback (30 points)

You will have an opportunity to provide feedback on a project report, ideally the report whose proposal you reviewed previously. We will likely use a gallery tool built by the Center for Academic Innovation (CAI). More information will be provided regarding the review mechanism later in the course. The rubric for this component is identical to the one for the project proposal peer feedback.

Rubric: Project report peer feedback

9.0 Technology choices

This course differs from other MADS courses in many ways including technology. We have created a Jupyter environment for you that is functionally equivalent to SIADS 516, which is a superset of the base MADS environment, and you can access that environment via the “ungraded lab assignment” in Coursera. You can use that environment or choose to use any of the environments from courses you have already completed to build and test data manipulations and visualizations for your project. Alternatively, you can use your own locally installed environment. Another possibility is to use Deepnote, Google Colaboratory, or VS Code’s Live Share which may facilitate team collaboration. As part of the grading the teaching team may attempt to reproduce your results using your code and data, and you are expected to assist with this if we request it.