Modifies the lesson to work on one repo throughout

config.yaml

@@ -17,11 +17,11 @@ title: 'Git Working Practices'
 created: '2024-11-11'
 
 # Comma-separated list of keywords for the lesson
-keywords: 'software, data, lesson, The Carpentries'
+keywords: 'software, data, lesson, The Carpentries, Git, GitHub'
 
 # Life cycle stage of the lesson
 # possible values: pre-alpha, alpha, beta, stable
-life_cycle: 'pre-alpha'
+life_cycle: 'alpha'
 
 # License of the lesson materials (recommended CC-BY 4.0)
 license: 'CC-BY 4.0'
@@ -59,6 +59,7 @@ contact: '[email protected]'
 
 # Order of episodes in your lesson
 episodes:
+- 00-repo-access.md
 - 01-issues.md
 - 02-branching.md
 - 03-feature-branch.md

episodes/00-repo-access.md

@@ -0,0 +1,65 @@
+---
+title: Repository Access
+teaching: 10
+exercises: 0
+---
+
+::::::::::::::::::::::::::::::::::::::: objectives
+
+- Know how to give a collaborator access to your repository.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+:::::::::::::::::::::::::::::::::::::::: questions
+
+- What levels of repository permissions are there?
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+To be able to contribute to the `git-training-demo`
+repository your instructors will have to give you access.
+They are going to showcase this now.
+The steps are:
+
+In the repository page on GitHub, click the "Settings"
+button on the right, select "Collaborators",
+click "Add people", and enter a username/s.
+
+![A screenshot of the GitHub Collaborators settings page for a public personal repository, which is accessed by clicking "Settings" then "Collaborators".](fig/github-add-collaborators.png){alt='A screenshot of the GitHub Collaborators settings page, which is accessed by clicking "Settings" then "Collaborators".'}
+
+To accept access to the repository, you will
+need to go to [https://github.com/notifications](https://github.com/notifications)
+or check for an email notification.
+Once there you can accept access to the repository.
+
+## Permission Levels
+
+### Personal Repositories
+
+Repositories on personal accounts only have
+two levels of permissions, the Owner and Collaborators[^permission-personal].
+To use the branching model in this lesson you would need
+adding as a collaborator.
+You can still contribute to a public repository without being added
+as a collaborator by using the forking model.
+
+[^permission-personal]: The [GitHub documentation](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-user-account-settings/permission-levels-for-a-personal-account-repository) has more information on
+permissions for a repository on a personal account.
+
+### Organisational Repositories
+
+Repositories in organisations have more levels of permissions[^permission-org].
+Team members require at least **write** access to use the branching model.
+For all lower levels of access use the forking model.
+
+[^permission-org]: The [GitHub Documentation](https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization) has more information on the 
+different permission levels for repositories in organisations.
+
+:::::::::::::::::::::::::::::::::::::::: keypoints
+
+- On a repository you own or are an admin on navigate to
+  [`https://github.com/<organisation>/<repository>/settings/access`](https://github.com/<organisation>/<repository>/settings/access)
+  to control access for collaborators.
+- You can give individuals or teams access to a repository.
+
+::::::::::::::::::::::::::::::::::::::::::::::::::

episodes/01-issues.md

@@ -1,7 +1,7 @@
 ---
 title: Issues
 teaching: 10
-exercises: 0
+exercises: 5
 ---
 
 ::::::::::::::::::::::::::::::::::::::: objectives
@@ -14,6 +14,7 @@ exercises: 0
 :::::::::::::::::::::::::::::::::::::::: questions
 
 - What information should go on an Issue?
+- What are Issue templates?
 
 ::::::::::::::::::::::::::::::::::::::::::::::::::
 
@@ -31,23 +32,79 @@ Here's some advice for writing good Issues:
 - Break up large Issues into several small ones and or
   use checklists to track tasks in the Issue
 
-![](fig/github-issue.png){alt='A screenshot of a GitHub Issue.'}
+Open an Issue on the `git-training-demo` repository 
+to add a file stating your favourite cloud type.
+
+Navigate to the **Issues** tab:
+
+![](fig/github-fork-issue-open.png){alt='A screenshot of the git-training-demo repository showing the Issues view.'}
+
+This repositories Issue tab looks different to the `weather`
+repository you worked on in the Introduction to Git & GitHub lesson.
+It uses [Issue templates](https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository)
+to provide templates for bugs and feature requests.
+Click on the green **Get started** button next to the
+**Feature request** option:
+
+![](fig/github-fork-issue-1.jpeg){alt='A screenshot of the git-training-demo repository showing an Issue being opened. The template has automatically added text to the description and labelled the Issue as an enhancement.'}
+
+You can see the Issue has text in the description already.
+This is from the template which provides a consistent
+structure to the Issues on this repo.
+The template has also added the `enhancement` label for you.
+
+Add in a clear title such as
+"Add mo-fitzroy's favourite cloud type",
+replace 'mo-fitzroy' with your GitHub username.
+Click **Submit new issue**.
+
+::::::::::::::::::::::::::::::::::::: instructor
+
+It's a good idea to remind learners that
+images can be dropped straight into the
+Issue description.
+An image of a cloud should do!
+
+::::::::::::::::::::::::::::::::::::::::::::::::
+
+### Projects, milestones, and labels
+
+Your instructor has set up a Project and some custom milestones
+for you to add to your Issue.
+
+- [Labels](https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/managing-labels)
+  help you classify Issues and PRs.
+- [Milestones](https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/about-milestones)
+  group Issues and PRs, tracking their progress towards a common milestone automatically.
+- [Projects](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects)
+  are a tool for planning and tracking work via GitHub.
+  Multiple repositories can be linked to a single project.
+  Projects can have multiple views depending on your needs;
+  some have kanban boards and gantt charts, others separate out
+  an individual colleagues Issues to avoid clutter.
 
 :::::::::::::::::::::::::::::::::::::::  challenge
 
-## Creating an Issue
+## Assign yourself, a project, and a milestone to your Issue
 
-Practice opening up an Issue on your `weather` repository.
-Your Issue will be a feature request for the shipping forecast.
+On the right hand side of the Issue you can:
 
-1. Make sure you give the Issue an accurate title and description
-2. Assign a label to the Issue
-3. Assign yourself to the Issue
+1. Assign yourself to the Issue so that others know
+you are working on it.
+2. Add the Issue to a Project by clicking on the cog
+next to the Projects section. (If you don't see a project
+related to the training you might not have been granted permissions, 
+ask your instructors for help)
+3. Assign the Issue to a milestone.
 
 ::::::::::::::::::::::::::::::::::::::::::::::::::
 
 :::::::::::::::::::::::::::::::::::::::: keypoints
 
-- Issues are used to track and plan work
+- Issues are used to track and plan work.
+- Issue templates provide template text
+  for the first comment for new Issues of various types.
+  They can auto-label Issues and encourage collaborators
+  to give plenty of detail.
 
 ::::::::::::::::::::::::::::::::::::::::::::::::::

episodes/02-branching.md

@@ -226,9 +226,9 @@ You can find more information using the links below:
 
 :::::::::::::::::::::::::::::::::::::::: keypoints
 
-- A clearly communicated branching model helps developers
-- For small projects use the Feature Branch flow
+- A clearly communicated branching model helps developers.
+- For small projects use the Feature Branch flow.
 - For larger projects or those with external collaborators use
-  forks with feature branches
+  forks with feature branches.
 
 ::::::::::::::::::::::::::::::::::::::::::::::::::