Merge pull request #165 from carpentries/anenadic-title-capitalisation

Titlecase for episode and section titles

episodes/01-introduction.md

@@ -52,7 +52,7 @@ Do not force people to share their pronouns.
 
 ::: challenge
 
-### Getting to know each other
+### Getting to Know Each Other
 
 If the Trainer has chosen an
 [icebreaker question](https://carpentries.github.io/instructor-training/icebreakers/index.html),
@@ -123,13 +123,13 @@ We will explore how defining the specific skills you wish to teach
 early on in the development process 
 provides a foundation from which you can build a stronger, more impactful lesson.
 
-### Building a lesson website
+### Building a Lesson Website
 
 Throughout the training, while you design and begin developing the content of your lessons, 
 we will teach you how to incorporate this into an organised and accessible website
 using our lesson infrastructure.
 
-### Collaborating effectively
+### Collaborating Effectively
 
 We believe that lessons are much more likely to succeed, and to remain useful in the long term,
 if they are developed collaboratively. 
@@ -138,7 +138,7 @@ and work effectively and efficiently with those you already have.
 
 ::: callout
 
-## Learning how to teach a lesson
+## Learning How to Teach a Lesson
 
 This training will focus on the content - how to prepare a good lesson.
 More about the performance - how to deliver a lesson most effectively -

episodes/02-lesson-design.md

@@ -1,5 +1,5 @@
 ---
-title: Lesson design
+title: Lesson Design
 teaching: 10
 exercises: 10
 ---
@@ -61,7 +61,7 @@ to place an emphasis on assessing learning during a workshop:
 **TODO: add a figure illustrating the process described in the list above. 
 could be similar to the one used earlier for Nicholl's original list.**
 
-## Your lessons
+## Your Lessons
 
 This training will provide many opportunities for discussion of your lessons.
 Providing some context now for the lessons that you will be creating will

episodes/03-audience.md

@@ -1,5 +1,5 @@
 ---
-title: Identifying your target audience
+title: Identifying Your Target Audience
 teaching: 25
 exercises: 20
 ---
@@ -102,7 +102,7 @@ interests, and challenges than your own.
 
 ## Exercise: thinking about target audience (15 minutes total for both parts)
 
-Part 1 (5 minutes): think about a member of the target audience for your lesson,
+Part 1 (all, 5 minutes): think about a member of the target audience for your lesson,
 and answer the following questions in the context of your lesson topic:
 
 1. What is their background?

episodes/05-objectives.md

@@ -1,5 +1,5 @@
 ---
-title: Defining lesson objectives/outcomes
+title: Defining Lesson Objectives/Outcomes
 teaching: 30
 exercises: 50
 ---
@@ -34,7 +34,7 @@ that are appropriate for the lesson content,
 and provides a scope for what should and should not be included.
 
 
-## Why focus on skills?
+## Why Focus on Skills?
 
 To ensure your audience stays motivated, and your lesson feels relevant to them,
 we recommend that lessons focus on teaching skills rather than tools.
@@ -45,7 +45,7 @@ Placing the emphasis on skills over tools will help you prioritise key concepts
 and consider how your lesson can have the biggest impact on the way learners do their work.
 
 
-## Learning objectives
+## Learning Objectives
 
 The desired outcomes (the _learning objectives_) of a lesson should be new skills, 
 i.e. things that the learner can do.
@@ -57,8 +57,8 @@ playing a musical instrument,
 or making sushi,
 are probably better suited to a different platform than a static website.)
 Cognitive skills cannot be equally easily acquired:
-before we can apply concepts and create something new, we must attain the ability to remember 
-and distinguish between new concepts. 
+before we can *apply* concepts and *create* something new, we must attain the ability to *remember*
+and *distinguish* between new concepts. 
 Remembering and distinguishing are also abilities that are often faster to gain then applying or creating.
 
 We must try to be realistic about how far along this scale we can move learners during a single workshop/lesson.
@@ -72,7 +72,7 @@ It will help us ensure we do not miss anything important or, conversely,
 include anything superfluous that could use up valuable time or distract instructors and learners.
 
 
-## What does an objective look like?
+## What Does an Objective Look Like?
 
 ![This diagram highlights the most important elements of a learning objective.](fig/objective.svg){alt='An example 
 learning objective, "import data into an indexed DataFrame with read_csv", with emphasis placed on the action verb 
@@ -86,7 +86,7 @@ The objectives for the current section of this training are:
 
 ::::::::: checklist
 
-## Objectives for this section
+## Objectives for This Section
 
 - Explain the importance of defining specific, measurable, attainable, relevant and time-bound objectives for a lesson.
 - Evaluate a written lesson objective according to these criteria.
@@ -119,7 +119,7 @@ We will see how helpful it can be to use action verbs in learning objectives
 when we begin talking about exercise design in the coming episodes.
 
 
-## SMART objectives
+## SMART Objectives
 
 To assist you in defining and writing learning objectives for your lesson,
 it can be helpful to turn to a popular framework for defining goals: _SMART_.
@@ -204,7 +204,7 @@ For example, a more specific and measurable version of this objective could be:
 ::::::::::::::::::::::::::::::::::::::::::::::::::
 
 
-## Lesson scope
+## Lesson Scope
 
 One of the major challenges of lesson design is choosing what to include in a lesson:
 what the main points will be,
@@ -240,7 +240,7 @@ because the task can be considered in the context of taking out whole
 learning objectives.
 
 
-## Defining learning objectives
+## Defining Learning Objectives
 
 We have discussed the importance of defining objectives early in 
 the lesson design process,

episodes/13-exercises.md

@@ -1,5 +1,5 @@
 ---
-title: Designing assessments
+title: Designing Assessments
 teaching: 25
 exercises: 70
 start: yes

episodes/15-narrative.md

@@ -1,5 +1,5 @@
 ---
-title: Example data and narrative
+title: Example Data and Narrative
 teaching: 15
 exercises: 50
 ---
@@ -21,7 +21,7 @@ exercises: 50
 
 ::::::::::::::::::::::::::::::::::::::::::::::::::
 
-## Creating a narrative
+## Creating a Narrative
 
 <!--- Should this section go before LO and questions? -->
 
@@ -45,7 +45,7 @@ This can help you maintain a narrative flow and make the lesson feel more authen
 Even if your topic doesn't require a dataset, deciding on a consistent narrative will
 help create a flow between lessons and reduce cognitive load for learners.
 
-## Finding images
+## Finding Images
 
 Copying an image from a website is technologically simple but can be legally and ethically complex. 
 Images are intellectual property and are subject to intellectual property laws 
@@ -80,7 +80,7 @@ GNU offers commentary about a variety of licenses for free software; this resour
 
 ::::::::::::::::::
 
-## Finding a dataset
+## Finding a Dataset
 
 When searching for a dataset to use in your lesson, 
 there are a number of factors to consider.
@@ -142,7 +142,7 @@ about an individual or groups of people.
 
 Outline covering the above paragraph - also used in codiMD template.
 
-### Dataset considerations
+### Dataset Considerations
 
 - Ethical use (see prompts below)
 - License - CC0 Recommended

episodes/17-explanation.md

@@ -1,5 +1,5 @@
 ---
-title: How to write a lesson
+title: How to Write a Lesson
 teaching: 30
 exercises: 40
 ---

episodes/19-operations.md

@@ -1,5 +1,5 @@
 ---
-title: How we operate
+title: How we Operate
 teaching: 25
 exercises: 5
 ---

episodes/20-preparing.md

@@ -1,5 +1,5 @@
 ---
-title: Preparing to teach
+title: Preparing to Teach
 teaching: 20
 exercises: 45
 ---

episodes/22-reflecting.md

@@ -1,5 +1,5 @@
 ---
-title: Reflecting on trial runs
+title: Reflecting on Trial Runs
 teaching: 10
 exercises: 45
 start: yes

episodes/24-external.md

@@ -1,5 +1,5 @@
 ---
-title: Collaborating with newcomers
+title: Collaborating with Newcomers
 teaching: 30
 exercises: 25
 ---
@@ -26,13 +26,13 @@ You may start working on projects by yourself or with a small group of collabora
 
 Collaboration helps bring different perspectives to solving a problem and share the load of the required work to develop, pilot, and, later on, maintain the lesson. People drop in and out of projects for various reasons and their levels of involvement may vary over time due to other commitments - for this reason it is worth taking time from the outset to make a project welcoming for newcomers in order to achieve a steady number of people working on your project at any time. You should plan to make it easy for new collaborators to join, to set up a local workspace so that they can contribute, help them find tasks so that they know what to contribute, and make the contribution process clear so that they know how to contribute. You also want to make it easy to give people credit for their work on your project as well as for others to reuse and give credit to your project. From this episode on, we cover best practices for collaboration and tools available to us to achieve it.
 
-## Documenting your lesson
+## Documenting Your Lesson
 
 For collaborative projects, it is important to spend the time on ‘external-facing’ features, such as documentation, to make the project as welcoming and as easy to get involved in as possible for newcomers who may not have a deep grasp of the project or know all its existing problems. Such documentation will be useful to yourself and other team members as well, e.g. if you are trying to come back to the project after a break or are reusing it for a new collaboration in the future.
 
 Your lesson documentation should contain the following information, which should be kept up to date.
 
-### Description of the project - `README` file
+### Description of the Project - `README` File
 
 `README`, `README.txt` or `README.md` is a plain text or Markdown file located in the project's root directory representing the default landing or home page for repositories in GitHub (and similar project repositories) by convention. It represents the first piece of documentation that people will see when visiting your lesson repository, hence it should concisely explain what the lesson is about and who it is for, and contain links and pointers to further information. For example, `README` should include:
 
@@ -46,17 +46,17 @@ Your lesson documentation should contain the following information, which should
 Citation can be contained in a plain text file (`CITATION`, `CITATION.txt`), a Markdown file (`CITATION.md`), or in the recently adopted [Citation File Format](https://github.com/citation-file-format/citation-file-format) (`CITATION.cff`). The CFF is defined using [YAML](https://yaml.org/spec/1.2.2/) (which we already encountered in the `config.yaml` file for the lesson website) and is now [the recommended way of storing citations in GitHub](https://github.blog/2021-08-19-enhanced-support-citations-github/). Advantages of using CFF are that GitHub will automatically show the citation information in the sidebar, making it more visible and accessible for visitors to your repository. In addition, metadata from `CITATION.cff` files will automatically be used by [Zenodo](https://zenodo.org/) when registering the DOI for your lesson/project. CFF metadata is also recognised by the [Zotero reference manager](https://www.zotero.org/).
 - **license** - a short description of and a link to the lesson’s license typically contained in a separate `LICENSE`, `LICENSE.txt` or `LICENSE.md` file within the repository’s root directory. The lesson repository created from the Carpentries lesson template already contains a default `LICENSE.md` file, but you should modify this to more accurately describe how the lesson content can be re-used by others.
 
-### Instructions for contributors - `CONTRIBUTING` file
+### Instructions for Contributors - `CONTRIBUTING` File
 
 `CONTRIBUTING`, `CONTRIBUTING.txt` or `CONTRIBUTING.md` is a text or Markdown file within the repository's root directory where you should provide detailed description of the ways people can send their contributions, what kinds of contribution will be credited and in what ways. For example, at what point would someone be listed as an author and how you will credit contributions that are not recorded in the commit history of the project. The latter is particularly important for newcomers who may not be proficient with the use of GitHub's features for collaborative work, such as issues, mentions, pull requests and code review, but could still provide valuable input and contributions.
 
 Carpentries lesson repositories already have a generic Carpentries `CONTRIBUTING.md` file to get you started. You should review it and, if need be, modify it to fit your team's needs and way of working. For example, you may want to expand on what contributions you are *not* looking for if your lesson already contains more material than can be covered in a typical workshop. You can also detail all channels on which you are willing to receive contributions on, if they are different from the defaults included in the file.
 
-### Issue and pull request templates
+### Issue and Pull Request Templates
 
 Consider setting up [issue and pull request templates](https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository)) to help newcomers who may not have much experience working on collaborative projects in GitHub. Such templates can provide a structure for the issue/pull request description, and/or prompt them to fill in answers to pre-set questions. Both can help contributors raise issues or submit pull requests in a way that is clear, helpful and provides enough information for maintainers to act upon (without going back and forth to extract it). GitHub provides a range of default templates, but you can also [write your own](https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository).
 
-### Other documentation
+### Other Documentation
 
 Once you have set up the basic documentation about your lesson, you may consider adding the following useful information to your documentation too:
 
@@ -82,9 +82,9 @@ Spend some time doing **one of the following**:
 Groups of collaborators taking this training together should discuss first how they will assign these tasks between them.
 ::::::::::::::::::::::::::::::::::::::::::::::::::
 
-## Collaborating on a lesson
+## Collaborating on a Lesson
 
-### Boosting the visibility and attracting new collaborators
+### Boosting the Visibility and Attracting New Collaborators
 
 In addition to having the complete documentation in the lesson repository, The Carpentries community provides a number of ways to further raise the visibility of the lesson among the broader community and encourage community members to contribute to its further development. For example:
 
@@ -95,11 +95,11 @@ In addition to having the complete documentation in the lesson repository, The C
 
 You should also consider including your lesson in [Hacktoberfest](https://hacktoberfest.digitalocean.com/) and similar wider community open source events aimed at encouraging people to contribute to open source projects periodically throughout the year.
 
-### Issue labelling for newcomers
+### Issue Labelling for Newcomers
 
 You can encourage contributions to your lesson from newcomers by using specific labels on issues to highlight suitable opportunities to help. Apply the `good first issue` or `help wanted` labels to issues in your repository to indicate that the maintainers will particularly welcome help or pull requests fixing such issues.
 
-### Noticing when something happens
+### Noticing When Something Happens
 
 GitHub implements a comprehensive [notifications system](https://docs.github.com/en/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications) to keep you up-to-date with activities in the lesson repository. GitHub also provides an additional useful notification feature for collaborative work - **Mentions**. The mention system notifies team members when somebody else references them in an issue, comment or pull request - you can use this to notify people when you want to check a detail with them, or let them know something has been fixed or changed (much easier than writing out all the same information again in an email!). You can use the mention system to link to individual GitHub accounts or whole teams for mentioning multiple people. Typing `@` in GitHub will bring up a list of all accounts and teams linked to the repository that can be "mentioned".
 
@@ -132,8 +132,7 @@ That resource, and [the _Best Practices for Maintainers_ guide from GitHub](http
 make excellent further reading as you prepare to transition from your role as an active developer
 into another as a responsive and responsible maintainer of your lesson.
 
-
-### Making progress
+### Making Progress
 
 The following practices have been shown to help maintain steady progress with lesson development:
 

episodes/26-collaborating.md

@@ -23,7 +23,7 @@ exercises: 60
 
 In this episode we expand on how to use GitHub effectively among a group of known collaborators, building on top of tools and practices we introduced for working with newcomers. Everything you do to help your lesson be more attractive and informative to newcomers will benefit all collaborators. Here, we explore GitHub features to help you keep track of what needs doing on the lesson, making decisions and managing your project.
 
-## Managing issues
+## Managing Issues
 
 **Issues** are GitHub's framework for managing issue/bug reports, feature requests, and lists of future work. They provide a single shared record of all the problems people have found with the lesson, and improvements that could be made, along with solutions and discussions around them. This helps the team to keep track of what they need to work on later, and reduces the chance of receiving redundant reports of issues you already know about.
 
@@ -194,7 +194,7 @@ the Reviewer should follow all the steps but close the PR at the end instead of
 ::::::::::::::::
 
 
-## Managing communication
+## Managing Communication
 
 Having an open, publicly-visible list of all the issues with your project is a helpful way of letting people know you are aware of issues and you are working on them. This can indicate to an external audience that the project is active. 
 It also provides you and your collaborators with an "at a glance" view of the state of the project, making it easier to prioritise future work.
@@ -293,7 +293,7 @@ which helps to ensure real concrete progress against project goals and requireme
 
 ::::::::::::::::::::::::::::::::::::::::::::::::::
 
-## Project governance
+## Project Governance
 
 In addition to managing your project on a day-to-day basis, you should consider a governance model for your lesson to describe the ground rules of participation, the roles that project participants can take on and the process for decision making within the project. You may wonder why you'd ever need a formal governance process - after all, everyone in your team is collegial, polite and hard-working. However, even among the most harmonious teams you will likely realise you need an agreed way to make decisions and resolve conflicts when your team encounters their first real disagreement.