Lab 4 - Merge Conflicts and Data Science Ethics

Lab
Important

This lab and the team agreement are both due Friday, October 13th at 11:59pm.

Important

DO NOT RENDER THE QMD FILE BEFORE STARTING THIS LAB.

Learning Goals

  • Collaborating on GitHub and resolving merge conflicts
  • Critiquing visualizations that misrepresent data
  • Discussing major ethical questions in modern data science

Getting started

  • Go to the sta199-f23-01 organization on GitHub. Click on the repo with the prefix lab-04. It contains the starter documents you need to complete the lab.
  • Clone the repo and start a new project in RStudio. See the Lab 1 instructions for details on cloning a repo and starting a new R project.

Why Teams: Rationale

In the real world, data scientists and statisticians often work in research teams. It is a skill to be able to communicate and work together on common projects. Thus, the remaining labs + your project will be team based.

Teams work better when members have a common understanding of the team’s goals and expectations for collaboration. The purpose of this activity is to help your team make a plan for working together during lab and outside of the scheduled lab time.

Each team member will have some ideas about how a team should operate. These ideas may be very different. This is your opportunity to share your thoughts and ideas to promote optimal team function and prevent misunderstandings in the future.

Team Name

Discuss with your group a team name to be called. Your GitHub repos will be created for this team name moving forward. Report your team name to your Lab Leader before moving on.

Instructions

Before completing the lab today, you will complete a team agreement. Discuss each of the items below with all in-person team members. If necessary, also follow up this week with any missing team members.

Have one person act as the recorder and type the team’s decisions in the team-agreement.qmd file.

Be sure the team agrees on an item before it is added to the document.

Once the document is complete, the recorder should render, commit, and push the team agreement to GitHub. All team members can refer to this document throughout the semester.

Team Agreement

Weekly meetings and Meeting “location”

Identify a 1 - 2 hour weekly block outside of lab where the entire team can meet to work on assignments. All team members should block off this time on their calendar in case the group needs to meet to finish lab or work on the project. You should then identify how the team will meet to work together (e.g. in-person, Zoom, Facetime, Google Hangouts). Be sure every member is able to access the virtual meeting space, if needed. If you are unable to find a weekly time when the entire team can meet, briefly outline a plan to work on assignments outside of lab.

Primary method of communication

The team’s primary method of communication outside of meetings (e.g. Slack, text messages, etc.)

How should someone notify the other members if they are unable to attend lab or a scheduled team meeting?

By when should everyone have their portion of the lab completed?

Keep in mind all members of your team must have time to review the lab before turning it in to make sure it is a cohesive write up. Many lab questions will depend on the answers to previous questions, so it may be necessary to have different portions of labs completed at different times.

Any other items the team would like to discuss or plan.

Missing Teammates

If you are missing teammates for today’s lab, it is your responsibility to reach out, say hello, and communicate with them that they must contribute to the above and below questions before submitting lab-04 to Gradescope. You can find their email in the teams repo. The link to the teams repo is located on our website on the teaching team tab.

Resolving merge conflicts

Working in teams includes using a shared GitHub repo for labs and projects. Sometimes things will go swimmingly, and sometimes you’ll run into merge conflicts.

When you and your teammates work on the lines of code within a document, and both try to push your changes, you will run into issues. Merge conflicts happen when you merge branches that have competing renders, and Git needs your help to decide which changes to incorporate in the final merge.

Our first task today is to walk you through a merge conflict!

If you haven’t yet done so since filling out the Team Agreement, now is a good time to render, commit, and push. Make sure that you render and push all changed documents and your Git pane is completely empty before proceeding.

  • Pushing to a repo replaces the code on GitHub with the code you have on your computer.
  • If a collaborator has made a change to your repo on GitHub that you haven’t incorporated into your local work, GitHub will stop you from pushing to the repo because this could overwrite your collaborator’s work!
  • So you need to explicitly “merge” your collaborator’s work before you can push.
  • If your and your collaborator’s changes are in different files or in different parts of the same file, git merges the work for you automatically when you *pull*.
  • If you both changed the same part of a file, git will produce a **merge conflict** because it doesn’t know how which change you want to keep and which change you want to overwrite.

Git will put conflict markers in your code that look like:

<<<<<<< HEAD 

See also: [dplyr documentation](https://dplyr.tidyverse.org/)   

======= 

See also [ggplot2 documentation](https://ggplot2.tidyverse.org/)  

>>>>>>> some1alpha2numeric3string4

The ===s separate your changes (top) from their changes (bottom).

Note that on top you see the word HEAD, which indicates that these are your changes.

And at the bottom you see some1alpha2numeric3string4 (well, it probably looks more like 28e7b2ceb39972085a0860892062810fb812a08f).

This is the hash (a unique identifier) of the render your collaborator made with the conflicting change.

Your job is to reconcile the changes: edit the file so that it incorporates the best of both versions and delete the <<<, ===, and >>> lines. Then you can stage and render the result.

Merge conflict activity

Setup

  • Clone the repo and open the .qmd file.
  • Assign the numbers 1, 2, 3, and 4 to each of the team members. If your team has fewer than 4 people, some people will need to have multiple numbers. If your team has more than 4 people, some people will need to share some numbers.

During the merge conflict exercise, you and your teammates must follow the instructions exactly, even if they seem strange. If the instructions are not followed exactly, the merge conflict activity will not work correctly, and your team may have to restart the activity from the beginning.

During the merge conflict exercise, and when resolving potential merge conflicts, you must work in Source mode in your Rstudio console. Merge conflicts will not always show in the Visual mode.

Let’s cause a merge conflict!

Our goal is to see two different types of merges: first we’ll see a type of merge that git can’t figure out on its own how to do on its own (a merge conflict) and requires human intervention, then another type of where that git can figure out how to do without human intervention.

Doing this will require some tight choreography, so pay attention!

Take turns in completing the exercises, only one member at a time. Others should just watch, not doing anything on their own projects (this includes not even pulling changes!) until they are instructed to. If you feel like you won’t be able to resist the urge to touch your computer when it’s not your turn, we recommend putting your hands in your pockets or sitting on them!

Before starting: everyone should have the repo cloned, open the lab-4.qmd document, and know which role number(s) they are.

Everyone:

  • In order to resolve merge conflicts using the instructions below, git needs to have the correct settings.
  • To ensure this is true, copy and paste git config pull.rebase false into your terminal and press enter. (Look for the tab next to the console, and ask if you can’t find it.)
  • Note that if a merge conflict comes up in a later assignment, you may need to do this step again before resolving it. If that’s the case, you’ll likely get a warning suggesting it when you try to pull and there’s a conflict.

🛑 Make sure everyone has completed this step before moving on.

Role 1:

  • In the code chunk under the first exercise, copy and paste the following code:
x = c(1, 2, 3)
  • render, commit, push.

🛑 Make sure the previous role has finished before moving on to the next step.

Role 2:

  • In the code chunk under the first exercise, copy and paste the following code:
y <- "Merge Conflict"
  • Render, commit, push. You should get an error.
  • Pull. Take a look at the document with the merge conflict.
  • Clear the merge conflict by editing the document to choose the correct/preferred change.
  • Render.
  • Click the Stage checkbox for all files in your Git tab. Make sure they all have check marks, not filled-in boxes.
  • commit and push.

🛑 Make sure the previous role has finished before moving on to the next step.

Role 3:

  • Add a code chunk for Exercise 2 and give it a label.
  • Render, commit, push. You should get an error.
  • Pull. No merge conflicts should occur, but you should see a message about merging.
  • Now push.

🛑 Make sure the previous role has finished before moving on to the next step.

Role 4:

  • Add a code chunk to Exercise 2 and give it a different label.
  • Render, commit, push. You should get an error.
  • Pull. Take a look at the document with the merge conflict. Clear the merge conflict by choosing the correct/preferred change. render, and push.

🛑 Make sure the previous role has finished before moving on to the next step.

Everyone: Pull, and observe the changes in your document.

Tips for collaborating via GitHub

  • Always pull first before you start working.
  • Resolve a merge conflict (render and push) before continuing your work. Never do new work while resolving a merge conflict.
  • Render, commit, and push often to minimize merge conflicts and/or to make merge conflicts easier to resolve.
  • If you find yourself in a situation that is difficult to resolve, ask questions ASAP. Don’t let it linger and get bigger.

Conveying the right message through visualization and other ethics questions

Before you begin

Since the exercises for this week are short it’s possible not every team member will get to commit and push during the workshop. However each team member should review what was created, fix typos, make edits for better presentation, etc. either during or after the workshop, and before the deadline.

This week’s lab does not require any programming and is meant to explore some ethical questions currently in data science and how visualizations can distort the meaning of data.

Note: Everyone should intellectually contribute to every question. However, no two teammates should work on the same question at the same time below.

Exercises

Part 1: Misleading Visualization

The following visualization was shared on Graph Crimes Twitter:

  1. What is misleading/confusing about this visualization and how does it distort the meaning of what the data would actually convey?

If you haven’t yet done so, now is a good time to render, commit, and push. Make sure that you commit and push all changed documents and your Git pane is completely empty before proceeding.


Everyone now pull

  1. In words, explain how you would go about redesigning this visualization so that it is no longer misleading and does not distort the meaning of the data. You should be specific about any changes you would make and explain/justify why your visualization would be better and what message your visualization would convey. You may include non-running code (using eval: false) to support your explanation of your visualization, but this is not required.

If you haven’t yet done so, now is a good time to render, commit, and push. Make sure that you commit and push all changed documents and your Git pane is completely empty before proceeding.


Everyone now pull

Part 2: Ethical Questions in Data Science

In this section, you will explore some current major ethical questions in data science and machine learning.

  1. One current ethical discussion in data science involves the training of “Large Language Models” such as ChatGPT. These models are trained using massive corpora (document sets) that include large amounts of work that is covered under copyright law. Read the following two articles:
  • https://www.dykema.com/news-insights/do-large-language-models-violate-copyright-law.html
  • https://hai.stanford.edu/news/reexamining-fair-use-age-ai

Discuss as a team the arguments on both sides of the discussion over copyright in training large language models. Write a short paragraph (maximum 8 sentences) about the topics covered in your discussion and the ethical questions raised in training these models.

If you haven’t yet done so, now is a good time to render, commit, and push. Make sure that you commit and push all changed documents and your Git pane is completely empty before proceeding.


Everyone now pull

  1. Another major ethical discussion in data science resolves around discriminatory biases in machine learning models. These biases can have real-world impacts in lending, criminal justice, hiring, and more. Many of these algorithms are so-called “black boxes”, meaning the exact process they take from input to output is unclear. Read the following articles:
  • https://www.reuters.com/article/us-amazon-com-jobs-automation-insight/amazon-scraps-secret-ai-recruiting-tool-that-showed-bias-against-women-idUSKCN1MK08G
  • https://www.theatlantic.com/technology/archive/2018/01/equivant-compas-algorithm/550646/
  • https://www.propublica.org/article/machine-bias-risk-assessments-in-criminal-sentencing (This article is long but would be worth reading)

Discuss as a team the nature of biases in machine learning and in datasets, and any possible solutions that could help limit those biases. Write a short paragraph (maximum 8 sentences) about the topics covered in your discussion and the ethical questions raised by these models.

If you haven’t yet done so, now is a good time to render, commit, and push. Make sure that you commit and push all changed documents and your Git pane is completely empty before proceeding.


Everyone now pull

Submission

Once you are finished with the lab, you will your final PDF document to Gradescope.

Warning

Before you wrap up the assignment, make sure all documents are updated on your GitHub repo. We will be checking these to make sure you have been practicing how to render and push changes.

You must turn in a PDF file to the Gradescope page by the submission deadline to be considered “on time”.

Make sure your data are tidy! That is, your code should not be running off the pages and spaced properly. See: https://style.tidyverse.org/ggplot2.html

To submit your assignment:

  • Go to http://www.gradescope.com and click Log in in the top right corner.
  • Click School Credentials \(\rightarrow\) Duke NetID and log in using your NetID credentials.
  • Click on your STA 199 course.
  • Click on the assignment, and you’ll be prompted to submit it.
  • Mark all the pages associated with exercise. All the pages of your lab should be associated with at least one question (i.e., should be “checked”). If you do not do this, you will be subject to lose points on the assignment.
  • Do not select any pages of your .pdf submission to be associated with the “Workflow & formatting” question.
  • PLEASE ONLY SUBMIT ONE ASSIGNMENT PER TEAM. YOU CAN ADD TEAM MEMBERS TO A SUBMITTED ASSIGNMENT IN GRADESCOPE.

Grading

Component Points
Team Agreement 7
Ex 1 10
Ex 2 10
Ex 3 10
Ex 4 10
Workflow & formatting 3
Total 50
Note

The “Workflow & formatting” grade is to assess the reproducible workflow. This includes:

  • linking all pages appropriately on Gradescope
  • putting your team and member names in the YAML at the top of the document
  • committing the submitted version of your .qmd to GitHub