Brainstorm and create draft of an overview of sessions

[signekb]

Put the overview in the sessions/syllabus.qmd file.

[lwjohnst86]

Taking a high level approach first, what are things that make a collaborative workflow with Git and GitHub?

• Issues
• Issue naming and description
• Commit messages
• Commit message style
• Commit contents
• Branching
• Branch naming
• Branch name style
• Branch merge conflicts
• Pull Requests
• Pull Request contents
• Pull Request descriptions
• Pull Request reviewing
• Pull Request merge conflicts
• Pull Request merging
• Workflow priorities (quality reviewing should be a priority to be collaborative)
• GitHub admin (protecting the main branch, etc)

Taking this, the sessions (in order) could start to be:

• Introduction:
  • Caveats (none of this matters, you can do what you want, but working with others, you need to agree to things. This course helps with guiding that agreement process)
• Review of the basics of Git and GitHub
• Everyone:
  • General priorities and agreements: High quality reviewing should be a top priority.
  • GitHub admin: Protecting branches
  • Issues: Writing issues, including the title and the description.
• As a contributor:
  • Branching: Conventional Branches, merge conflicts
  • Committing: Atomic commits (esp. doc commits vs code commits), Conventional Commits
  • Pull Requests: Atomic PRs, merge conflicts, descriptions and templates
• As a reviewer/admin:
  • Pull Requests: Reviewing, merging

Looking through the content, you've made:

• branching and PRs (best practices, atomic PRs, naming patterns)
• committing (e.g. commit message styles, atomic commits)
• review of git and github
• creating and using issues
• Reviewing PRs

(Misc ideas) Some ideas to include in the appendix as additional resources:

• example issue templates or PR templates to use
• tips and tricks
• VS Code vs RStudio vs Jupyter
• challenges and struggles: People not knowing about this workflow, teaching others, adhering to it even when busy, other opinions on how to do things, etc.

[lwjohnst86]

Refining what I wrote in #4, sessions (maybe split into 1.5 to 3 hr chunks of time, with default being 3 hrs) could be divided into:

1. Introduction and theory on collaboration and teamwork (mostly reading, discussion, and lecture style; maybe only 1.5 hrs?)
2. Review of Git and GitHub (maybe 1.5 hrs, but could go for a bit more?)
3. Setting up GitHub for a team-based project
4. Workflow as a contributor: Branching and committing (probably will be 3-4 hrs)
5. Workflow as a contributor: Making pull requests (maybe 1.5 hrs?)
6. Workflow as a reviewer or admin: Reviewing and merging pull requests (maybe 1.5 hrs?)
7. Group project work

So a potential schedule of the content is:

• Day 1 morning: 1
• Day 1 afternoon: 2, start and maybe finish 3
• Day 2 morning: finish 3, start 4
• Day 2 afternoon: finish 4
• Day 3 morning: 5 and 6
• Day 3 afternoon: 7

[signekb]

@lwjohnst86 I think that schedule makes a lot of sense and fits well with #4 ⭐ 👍 Should I add it to the schedule.csv?

I am wondering about which kinds of exercises that will make sense to do during Day 1 and 2? My initial thought was to do the group project along the way to practice working together. But if the group project is on Day 3, what should the other exercises be?

[lwjohnst86]

There's lots of exercises we can do!!! 😁 From experience, a group project throughout the course isn't very efficient nor helps with learning. That's way the intro R course has the last session be the group project ☺️

One of the reasons the website doesn't build is because of the schedule code. I'm refactoring it right now to fix build issues, after that, you can add it in the schedule ☺️

[signekb]

Alrightyyy 😁 Can you give me a few examples of those exercises to make it a bit more concrete?

Great, thanks! I'll update the schedule afterwards 👍

[lwjohnst86]

Hmm, you're wanting to jump ahead 😄 We haven't even gotten to creating the learning objectives for the individual sessions yet!!

[signekb]

Maybeee 😛 I just wanted to envision what exercises that are collaborative but not a part of a group project could be