presenter-notes schema should be more permissive

[johnpaulashenfelter]

from @1point618

This renders correctly in the app, but doesn't validate.

modules/DSS-01_intro-to-course.yml#0: INVALID

• (line 8) [/screens/0/image-slide/presenter-script] 'This course is designed to walk you through the version control and collaboration features of GitHub and git. You'll be reading text and watching videos about git and GitHub, and we'll be asking you to perform all the actions we show you in your own GitHub repository. You'll have the chance to practice everything you learn.\n\nFor now, click on the "next" button above to move onto the second slide.\n': not a sequence.
• (line 54) [/screens/3/image-slide/presenter-script] 'GitHub is a project collaboration platform built on top of a distributed version control system called Git.\n\nGitHub and git help teams work together on a project easily.\n\nWith Git, each person has a local copy of the project, and as they make changes there they upload them to the central cloud copy, then download the changes that others have made.\n': not a sequence.

modules/DSS-02_exploring-repository.yml#0: INVALID

• (line 28) [/screens/2/image-slide/presenter-script] '* The repository (or "repo") holds everything in your project—code, documentation, other important files.\n* Everything in the repo is tracked by git version control.\n* The README.md file is shown at the bottom of the main page of the code view.\n* Issues are used to track bugs and feature requests, and can be assigned to team members.\n* A pull request represents a change that the author would like to make to the repo. PRs are used to resolve issues.\n\nTake this time to poke around your repository to get oriented, then move on to the next slide.\n': not a sequence.

modules/DSS-03_issues.yml#0: INVALID

• (line 8) [/screens/0/image-slide/presenter-script] 'Use GitHub issues to record and discuss ideas, enhancements, tasks, and bugs. They make collaboration easier in a variety of ways.\n\n* Replace email for project discussions, ensuring everyone on the team has the complete story.\n* Allow you to cross-link to other issues and pull requests.\n* Create a single, comprehensive record of how and why you made certain decisions.\n* Allow you to easily pull the right people into a conversation.\n': not a sequence.
• (line 44) [/screens/2/image-slide/presenter-script] '* You can use markdown to format issues.\n* You can @mention somebody in order to alert them of the issue.\n* The Preview tab shows how your comment will be rendered.\n* Drag and drop pictures into the issue to display them.\n* You can assign an issue to anyone with access to the repo.\n* Labels can be used to organize issues.\n* Filters allow you to easily search for labels.\n': not a sequence.

modules/DSS-04_github-flow.yml#0: INVALID

• (line 8) [/screens/0/image-slide/presenter-script] 'In this section we'll explore GitHub's functionality in depth.\n\nYou'll have the chance to practice all the skills that we teach in your GitHub repository, so make sure not to move on until you're sure you can perform these actions: you'll need them in your day-to-day job.\n': not a sequence.
• (line 32) [/screens/2/image-slide/presenter-script] '* Everything on GitHub lives on a branch.\n* The "canonical" version of the code lives on the master branch by convention.\n* Use new branches to experiment with the code without affecting master.\n* When you're done experimenting and want to add the feature into master, you create a pull request (PR).\n* PRs don't have to be perfect, but should be ready for other people to look at, comment on, and work on.\n* Once the changes in the PR are approved, the branch is "merged" into master and can then be removed.\n': not a sequence.

modules/DSS-05_branches.yml#0: INVALID

• (line 8) [/screens/0/image-slide/presenter-script] 'Every day you will be editing files on your project or adding new files. You don't want to take risks with the code on your master branch so you need to create a branch.\n\nWhen you create a branch, you are essentially creating an identical copy of the project at that point in time that is completely separate from the master branch. This keeps your the code on your master branch safe while you experiment and fix issues.\n\nLet's learn how you can create a new branch.\n': not a sequence.
• (line 33) [/screens/2/image-slide/presenter-script] '* A branch is an identical copy of the master branch that can be edited separately.\n* Branching keeps the code on master safe while allowing you to experiment.\n* Create a branch by clicking on the branch drop-down and entering your branch name in the text field.\n* Any files you create, edit, or delete will then be applied to that branch.\n* Be careful, GitHub automatically puts you on master, so always make sure you're on the right branch before you start working.\n': not a sequence.

modules/DSS-06_creating-files.yml#0: INVALID

• (line 37) [/screens/1/image-slide/presenter-script] '* Click on the + button to add a new file.\n* Adding text followed by a / will create a new directory with that name.\n* Add an extension to tell GitHub how to render the text.\n* Once you're done editing the file, "commit" the changes below. Make sure to include a commit message. \n': not a sequence.

modules/DSS-07_create-pr.yml#0: INVALID

• (line 44) [/screens/2/image-slide/presenter-script] '* Pull Requests (or PRs) are used to add code another branch, in this case master.\n* A pull request asks that the team merge one branch into another.\n* The "base" is the branch you want to merge into (often master), the "compare" is the branch you're merging, in this case the feature branch.\n* Make sure to leave a comment to tell people what changes you made and why.\n* In the comment, you should put number sign (#) in front of the number of the issue that you're fixing. This will automatically link your PR to that issue.\n* Once you've made the PR, the Files changed view allows you to see what this PR will change on the base branch. Red means "deleted", green means "added". This view is often called the "diff".\n* You can add comments directly to the diff, or in the Conversations view.\n': not a sequence.

modules/DSS-08_edit-pr.yml#0: INVALID

• (line 34) [/screens/2/image-slide/presenter-script] '* You will be notified of all comments on your own PRs.\n* You can make changes to files directly in the Files changed view.\n* These changes, once committed, will be included in the PR. \n': not a sequence.

modules/DSS-09_merge-pr.yml#0: INVALID

• (line 8) [/screens/0/image-slide/presenter-script] 'At this point, your pull request should be approved and you are ready to merge it in to the master branch. When you merge your branch, you are taking the content and history from your feature branch and adding it to the content and history of the master branch.\n\nMany project teams have established rules about who should merge a pull request. Some say it should be the person who created the pull request since they will be the ones to deal with any issues resulting from the merge. Others say it should be a single person within the project team to ensure consistency. Still others say it can be anyone other than the person who created the pull request.\n\nThere are also third party Continuous Integration (CI) tools you can integrate with GitHub to test the build before the merge is completed. There are pros and cons to each approach and we will not attempt to prescribe a solution here, but these are good conversations to have within your project team.\n\nLet's take a look at how you can merge the pull request and close the original issue at the same time.\n': not a sequence.
• (line 48) [/screens/2/image-slide/presenter-script] '* To merge your branch into the master branch, click the Merge pull request button in the Conversation view.\n* Use the keyword Fixes followed by # and the issue number to close the issue at the same time as you merge the PR.\n* Once the PR is successfully merged, you can delete your feature branch as it is no longer needed.\n': not a sequence.

modules/DSS-10_command-line-interface.yml#0: INVALID

• (line 8) [/screens/0/image-slide/presenter-script] 'So far, all the work we've done has been using GitHub's online graphical user interface. However, if you prefer to work on the command line, you can easily integrate GitHub into your current workflow.\n\nIn this section, we'll teach you how to use git and GitHub effectively through the command line. We assume a working knowledge of the command line interface, so if you're rusty you might want to brush up on using the CLI before forging ahead.\n': not a sequence.
• (line 15) [/screens/1/image-slide/presenter-script] 'When using the command line, you'll be working with Git. Git is the underlying version control system that GitHub makes use of. Some of the features we've discussed so far, such as pull request and issues, are functionality that GitHub adds. Others, like branching and commits, are git functionality.\n\nYou can think of git as a version control tool that you can use locally, and GitHub as a cloud service that makes using that tool with other people on your team much more functional and seamless.\n': not a sequence.
• (line 22) [/screens/2/image-slide/presenter-script] 'Git is OS agnostic; the commands are essentially the same whether you are on Mac, Windows or Linux. You can use your favorite application to interact with the command line.\n\nFirst, let's check the version of Git currently installed on your system. At the very least you should have a version greater than 1.9.5 installed. If you don't, then go to git-scm.com to download and install the latest version.\n\nOnce you've verified you have the latest version of git installed, we're ready to on to getting git configured correctly.\n': not a sequence.

modules/DSS-11_cli-config.yml#0: INVALID

• (line 8) [/screens/0/image-slide/presenter-script] 'The first thing you should do when you get started using git is to set your configuration options.\n\nGit allows you to set configuration options at three different levels. The default value for git config is --local.\n* --system - These are system-wide configurations. They apply to all users on this computer.\n* --global - These are the user level configurations. They only apply to your user account.\n* --local - These are the repository level configurations. They only apply to the specific repository where they are set.\n\nWe will revisit our configuration setting throughout the class; right now we are only setting the essentials to get us started.\n': not a sequence.

modules/DSS-12_cloning.yml#0: INVALID

• (line 8) [/screens/0/image-slide/presenter-script] 'Part of what makes git such a well-loved VCS is that it easily lets everyone on the team have their own local working repository. It's expected that everyone will work on their own computer, and sync changes they've made with each other only when they need to.\n\nBut first, we have to make a local copy of your repository. To do this, we have to "clone" the repository that you have hosted on GitHub.\n\nWhen you clone a GitHub repository you are creating a copy of everything in that repository, including its history. This is one of the benefits of a DVCS like git - rather than being required to query a slow centralized server to review the commit history, queries are run locally and are lightning fast.\n': not a sequence.
• (line 41) [/screens/2/image-slide/presenter-script] '* Start a new branch on GitHub to work on.\n* Using the command line, cd to the directory that you want to put your local repo in.\n* Copy the clone URL on GitHub.\n* Type git clone CLONE_URL.\n* cd into the new cloned repo and type git status.\n* git branch will show you the available branches. Only master appears.\n* git branch -a will show all the remote branches.\n* git checkout BRANCH_NAME will clone the branch you want onto your local machine, and all edits you make locally with be applied to that branch until you checkout another one.\n': not a sequence.

[1point618]

To be clear, what's going on here is that in YAML you can use the pipe (|) to specify that a block of text is coming next, and YAML should keep the white space of that block as-is.

I'm using this to format markdown correctly.

So:

  presenter-script: |
    * There is only one staging area, so you can change a branch after you've changed a file, and still commit that file to the new branch.
    * `git checkout -b "NEW_BRANCH_NAME"` is a quick way to both create a new branch and check it out.
    * If you edit a file after `git add`ing it, then on a commit only the changes made before the `git add` will actually be commited. You must `git add` again in order to commit all the changes.

should (and does) render as:

• There is only one staging area, so you can change a branch after you've changed a file, and still commit that file to the new branch.
• git checkout -b "NEW_BRANCH_NAME" is a quick way to both create a new branch and check it out.
• If you edit a file after git adding it, then on a commit only the changes made before the git add will actually be commited. You must git add again in order to commit all the changes.

But our validator doesn't like the pipe syntax, and yells at me for using it even though it's valid YAML and our app accepts it.

Thanks @johnpaulashenfelter for making this issue.