Lab - Project proposal

Lab
Modified

March 6, 2024

Important

There is no explicit lab assignment to turn in for this week. Follow the instructions below to meet your team members, develop a set of team expectations, practice collaborative workflows using Git and GitHub, and begin to brainstorm potential topics for your project.

Learning goals

In this lab, you will…

  • Meet your project team
  • Collaborate on GitHub with your teammates and resolve merge conflicts
  • Brainstorm ideas for your project proposal

Getting started

  • Go to the info2950-sp24 organization on GitHub. Click on the repo with the prefix project. It contains the starter documents you need to complete the lab.

  • Clone the repo and start a new project in RStudio. See the Lab 0 instructions for details on cloning a repo and starting a new R project.

  • Go to the Build tab and click Render website.

  • Make sure it compiles without errors. View your project website in your Viewer tab.

Teamwork

Why teams: Rationale

In the real world, data scientists 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 making 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 agreement

Discuss each of the items below with all team members.

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

Be sure the team agrees on an item before it is recorded.

All team members can refer to this document throughout the semester.

  • Team name: Feel free to pick a different name than the one I assigned (note that all lab repos will be created using your assigned code name).
  • To what goals do we all commit?
  • Weekly meetings: Identify a 1 - 2 hour weekly block outside of lab where the 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.
  • Meeting “location”: 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 team can meet, briefly outline a plan to work on assignments outside of lab. Otherwise, you can delete this item.
  • 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 your team may want to have time to review the lab before turning it in to make sure it is a cohesive write up.
  • How will we hold ourselves and one another accountable? What (exactly) will we say to a team member who appears not to be contributing equally? To a team member who fails to deliver what was promised?
  • 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 tasks before the deadline. You can find their NetIDs using the URL: https://github.coecis.cornell.edu/orgs/info2950-sp24/teams/project-TODO-TEAM-NAME/members (replace TODO-TEAM-NAME with your team code name).

If you are missing from today’s lab…

It is your responsibility to reach out, say hello, and communicate with your team members and contribute to the above and below tasks before the deadline. You can find their NetIDs using the URL: https://github.coecis.cornell.edu/orgs/info2950-sp24/teams/project-TODO-TEAM-NAME/members (replace TODO-TEAM-NAME with your team code name).

Merge conflicts

Resolving

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! First, a bit of Git review:

  • 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 you 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 your project repo and open the about.qmd file.
  • Assign the numbers 1, 2, 3, 4, and 5 to each of the team members. If your team has fewer than 5 people, some people will need to have multiple numbers.

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 exercise, 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.

Tip

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 and know which role number(s) they are.

Also, everyone should run the following code in their R console to set up their preferences for pulling.

usethis::use_git_config(pull.rebase = FALSE)

Role 1:

  • Go to about.qmd in your project repo. Change the [team name] to your actual team name.
  • Render, commit, push.

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

Role 2:

  • Change the team name to some other word.

  • 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:

  • Change the name of the first team member.
  • 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:

  • Change the name of the first team member to something other than what the previous team member did.
  • 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, commit, and push.

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

Role 5:

  • Change the a name of the rest of the team members and add descriptions for each person with the help of your team members. Role 5 should be the only one typing, the others should help verbally.
  • Render and commit. Discuss as a team what you expect to happen when you hit push. Should there be a merge conflict error or not?
  • If there is a merge conflict, fix it. If not, push your changes.

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.

Project proposal

Go to the project description and read through the first four sections (Important Dates, Introduction, Teams, Proposal) and start working through the proposal in proposal.qmd. Your submission will be in your project repo; there is not a separate repo for this lab.

Each person in the team must contribute to the proposal, i.e., each person should commit at least once to the project repo during the proposal stage.

Submission

This lab helps prepare you for submitting your project proposal. There is no separate lab submission. You do not need to submit your lab via Gradescope.

Grading

There is no separate lab assignment grade. You will earn a grade for your project proposal as outlined in the project description.

Acknowledgments