To save some time during live demos, it would be helpful to write the some of actual code ahead of time for safe-keeping! This way we can directly copy/paste in during live demos. This will be only helpful for initial versions of scripts, i.e. not for modifying an already-existing script. We may want to break this up into multiple issues, but for now...
stacking demo: Run scatterplot function and export PNG
Of course, I promptly thought of this after we templatized the demo repo next door, but it's not too difficult to do that again if it might be better for re-use to add this content to .live-demo-content/. CC @jaclyn-taroni, thoughts?
This lesson on git workflows and when to use them will comprise slides and links to public AlexsLemonade repositories that use different git workflows. The workflows we'll cover are:
Feature branch model (example: sc-data-integration)
Git flow (possible examples: scpca-nf and scpca-docs; note these are kind of weird because development is not the default)
Forking (example: OpenPBTA-analysis)
But we'll start by talking about base roles in GitHub organizations.
We'll need a demo repository to... demo things like working with multiple branches, diffs, stacked PRs, and leaving reviews. This issue is tracking creating that repository.
When setting up the repository, I selected a BSD 3-clause license. A CC-BY license might be more appropriate for most of the content, as we'll be writing a pretty limited amount of code. Our other training material uses a dual license.
This will be a few slides on what review is and how it works on GitHub. It won't explain why code review is useful (we'll save that for later). It's intended to provide some context before discussing tracking and planning work, where we'll mention review.
After some discussion about merge conflict live demo (#32), the working with branches issues should be marginally tweaked; it will have no effect on the overall concepts we're teaching, just some small differences in what scripts to be writing. This PR in the demo repository is adding the actual issues that will be used AlexsLemonade/2023-chop-training-demo#15. After that PR is all set, the associated instructor notes will need to be updated in this repo to match.
This set of slides will cover things that can help with facilitating review that are outside the scope of an individual author's responsibilities, for example:
Specific examples of using GitHub Actions: code styling and spell check
Currently this repo is set to private. Let's make it public, and at the same time ensure the repo README is sufficiently descriptive (same level as we might do for a "regular" training, eg - https://github.com/AlexsLemonade/2023-march-training/#readme).
From this comment and associated discussion: #31 (comment)
Currently, the merge conflict demo does teach how to resolve merge conflicts, but it does not provide a highly realistic example of a more realistic merge conflict one might actually encounter. We should consider updating the demo, for example in a way that a result TSV file is modified resulting in a merge conflict, which may require more than just "open a tool and click theirs or ours" to fix, much like life.
This lesson will cover topics that are relevant to the time period between when a review is returned through getting the code merged, which includes the following:
This set of slides on PR review will cover what kinds of responsibilities are shared between the author and reviewer(s) of a PR and get into the following:
Understanding the impact of merging the PR (i.e., applying different standards for a private script to be used once vs. user-facing documentation)
Reviewer fit
Keeping things moving (e.g., don't let the PR balloon in scope)
This issue is tracking a lesson on using a git repository as a "lab notebook." This will mostly be delivered via slides and will cover the following topics:
Documentation also needs to be included in your repo. Managing the code with git is not sufficient.
Writing and organizing your code with someone else in mind.
Briefly: Issues can be used as a (light) project management tool.
The git basics instructor notes will need to be slightly updated to match the final.final plan as described in the linked comment, and/or in any subsequent conversations in that issue.
We should add a page with some background and/or tutorials on Git and GitHub. We may not want to include this in the navigation and instead just link from the website homepage.