Tidying up complaints from checking tool

CONTRIBUTING.md

@@ -1,6 +1,6 @@
-*Library Carpentry builds on the work of [Software Carpentry][swc-site] and [Data Carpentry][dc-site].
-It uses the same contribution guidelines as these projects, which can be found below.*
-______
+*Library Carpentry builds on the work of [Software Carpentry][swc-site] and [Data Carpentry][dc-site]. It uses the same contribution guidelines as these projects. This can be found below.*
+
+----
 
 # Contributing
 
@@ -31,7 +31,7 @@ This is a good way to introduce yourself
 and to meet some of our community members.
 
 1.  If you do not have a [GitHub][github] account,
-    you can [send us comments by email](mailto:[email protected]).
+    you can [send us comments by email][contact].
     However,
     we will be able to respond more quickly if you use one of the other methods described below.
 
@@ -47,7 +47,28 @@ and to meet some of our community members.
     you can submit a pull request (PR).
     Instructions for doing this are [included below](#using-github).
 
-## What We're Looking For
+## Where to Contribute
+
+1.  If you wish to change this lesson,
+    please work in <https://github.com/data-lessons/library-data-intro>,
+    which can be viewed at <https://data-lessons.github.io/library-data-intro>.
+
+2.  If you wish to change the example lesson,
+    please work in <https://github.com/swcarpentry/lesson-example>,
+    which documents the format of our lessons
+    and can be viewed at <https://swcarpentry.github.io/lesson-example>.
+
+3.  If you wish to change the template used for workshop websites,
+    please work in <https://github.com/swcarpentry/workshop-template>.
+    The home page of that repository explains how to set up workshop websites,
+    while the extra pages in <https://swcarpentry.github.io/workshop-template>
+    provide more background on our design choices.
+
+4.  If you wish to change CSS style files, tools,
+    or HTML boilerplate for lessons or workshops stored in `_includes` or `_layouts`,
+    please work in <https://github.com/swcarpentry/styles>.
+
+## What to Contribute
 
 There are many ways to contribute,
 from writing new exercises and improving existing ones
@@ -66,14 +87,14 @@ it's easy for people who have been using these lessons for a while
 to forget how impenetrable some of this material can be,
 so fresh eyes are always welcome.
 
-## What We're *Not* Looking For
+## What *Not* to Contribute
 
 Our lessons already contain more material than we can cover in a typical workshop,
 so we are usually *not* looking for more concepts or tools to add to them.
 As a rule,
 if you want to introduce a new idea,
-you must estimate how long it will take to teach
-and explain what you would take out to make room for it.
+you must (a) estimate how long it will take to teach
+and (b) explain what you would take out to make room for it.
 The first encourages contributors to be honest about requirements;
 the second, to think hard about priorities.
 
@@ -84,7 +105,7 @@ our lessons must run equally well on all three.
 
 ## Using GitHub
 
-If you want to start adding or fixing material yourself,
+If you choose to contribute via GitHub,
 you may want to look at
 [How to Contribute to an Open Source Project on GitHub][how-contribute].
 In brief:
@@ -111,29 +132,25 @@ or encourage others to do so.
 The maintainers are community volunteers,
 and have final say over what gets merged into the lesson.
 
-## Our Template
-
-[This documentation][example-site] explains how we format our lessons
-(and is itself an example of that formatting).
-
 ## Other Resources
 
 General discussion of [Software Carpentry][swc-site] and [Data Carpentry][dc-site]
 happens on the [discussion mailing list][discuss-list],
 which everyone is welcome to join.
-You can also [reach us by email][mailto:[email protected]].
+You can also [reach us by email][contact].
 
+[contact]: mailto:[email protected]
 [dc-issues]: https://github.com/issues?q=user%3Adatacarpentry
 [dc-lessons]: http://datacarpentry.org/lessons/
 [dc-site]: http://datacarpentry.org/
-[discuss-list]: http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
-[example-site]: https://gvwilson.github.io/new-lesson-example/
+[discuss-list]: http://lists.software-carpentry.org/listinfo/discuss
+[example-site]: https://swcarpentry.github.io/lesson-example/
 [github]: http://github.com
 [github-flow]: https://guides.github.com/introduction/flow/
 [github-join]: https://github.com/join
 [how-contribute]: https://egghead.io/series/how-to-contribute-to-an-open-source-project-on-github
-[issues]: https://github.com/gvwilson/new-lesson-example/issues/
-[repo]: https://github.com/gvwilson/new-lesson-example/
+[issues]: https://github.com/data-lessons/library-data-intro/issues/
+[repo]: https://github.com/data-lessons/library-data-intro/
 [swc-issues]: https://github.com/issues?q=user%3Aswcarpentry
 [swc-lessons]: http://software-carpentry.org/lessons/
 [swc-site]: http://software-carpentry.org/

_episodes/02-getting-started.md

@@ -37,32 +37,37 @@ $ mkdir git_test
 $ cd git_test
 $ git init
 ~~~
+{: .bash}
 
 This initiates `git_test` as a git repository. 
 
 If you do an `ls` now, the repository might seem empty. However, an `ls -a` will show the hidden files, which includes the new file `.git`.
 
 This signifies that the directory is now a Git repository. Were the `.git` file ever to be deleted after you have begun committing files, all versioning of the data would be lost. 
-
 We now need to configure Git locally - this need only be done once, i.e. the first time we are setting up Git. However, each of the settings can be changed at any time if we decide we want to use a different email address, say, or switch to a different text editor.
+
 ~~~
 $ git config --global user.name "Mary Citizen"
 $ git config --global user.email "[email protected]"
 $ git config --global color.ui "auto"
 $ git config --global core.editor "nano -w"
 ~~~
+{: .bash}
 
 Now we have set the directory up as a repository, and configured it locally, we can see how we are going.
 
 **Git status**
+
 we can use `git status` at any time to let us know what Git is up to.
 
 If we try it now, we should get something like this
+
 ~~~
-$ On branch master
-$ Initial commit
-$ nothing to commit (create/copy files and use "git add" to track)
+On branch master
+Initial commit
+nothing to commit (create/copy files and use "git add" to track)
 ~~~
+{: .output}
 
 This is telling us that we are on the master branch (more on this later) and that we have nothing to commit (nothing to save changes from).
 If we use list directory we can see currently we don't have any files to track. Let's change that by adding a txt file. Touch allows us to create an empty file.
@@ -71,11 +76,15 @@ If we use list directory we can see currently we don't have any files to track.
 $ ls
 $ touch git_test.txt
 ~~~
+{: .bash}
 
 We now have a txt file. If we try `git status` again, we will get the following
 
 ~~~
 $ git status
+~~~
+{: .bash}
+~~~
 On branch master
 Initial commit
 Untracked files:
@@ -85,6 +94,7 @@ Untracked files:
 
 nothing added to commit but untracked files present (use "git add" to track)
 ~~~
+{: .output}
 
 This status is Git telling us that it has noticed a new file in our directory that we are not yet tracking. With colourised output, the filename will appear in red.
 
@@ -93,11 +103,15 @@ To change this, and to tell Git we want to track any changes we make to git_test
 ~~~
 $ git add git_test.txt
 ~~~
+{: .bash}
 
 This adds our txt file to the **staging area** (the area where Git checks for file changes). Because we are not alerted that this has happened, we might want to use `git status` again.
 
 ~~~
 $ git status
+~~~
+{: .bash}
+~~~
 On branch master
 
 Initial commit
@@ -107,6 +121,7 @@ Changes to be committed:
 
     new file:   git_test.txt
 ~~~
+{: .output}
 
 If we opted for colourised output, we can see that the file has changed colour (from red to green) and Git also tells us that it has got a new file.
 
@@ -115,6 +130,8 @@ Let's make some changes to this file before we commit it:
 ~~~
 $ nano git_test.txt
 ~~~
+{: .bash}
+
 Open the file in nano or another text editor.
 
 We should now be able to add some text to our text file. For now let's just write 'hello world'. If we try `git status` again. We should get the following message
@@ -126,20 +143,26 @@ Changes not staged for commit:
 
     modified:   git_test.txt
 ~~~
+{: .output}
 
 This lets us know that Git has spotted changes to our txt file but that it hasn't yet 'staged' them. This means Git won't currently record the changes we made. We can add the file to the staging area again
 
 ~~~
-git add git_test.txt
+$ git add git_test.txt
 ~~~
+{: .bash}
 
 We can now **commit** our first changes. Commit is similar to 'saving' a file to Git. However compared to saving, a lot more information about the changes we made is recorded and visible to us later.
 
 ~~~
-git commit -m 'hello world'
+$ git commit -m 'hello world'
+~~~
+{: .bash}
+~~~
 [master (root-commit) 27c3f19] hello world
  1 file changed, 1 insertion(+)
  create mode 100644 git_test.txt
 ~~~
+{: .output}
 
 We can see that one file changed and we made one insertion which was our 'hello world'. We have now recorded our changes and we can later go back and see when we made changes to our file and decided to add 'hello world'. We do have a problem now though. At the moment our changes are only recorded on our computer. At the moment, if we wanted to work with someone else, they would have no way of seeing what we've done. Let's fix that. Let's jump to the GitHub website where we could decide to host some of work. Hosting here will allow us to share our work with our friends and colleagues but will also allow other people to use or build on our work.

_episodes/03-sharing.md

@@ -23,6 +23,7 @@ Once we have created the new repository, we still need to link the repository we
 ~~~
 $ git remote add origin <web address of your repo.git>
 ~~~
+{: .bash}
 
 This will add a repository on GitHub for our changes to be committed to.
 
@@ -31,25 +32,30 @@ Check that it is set up correctly with the command:
 ~~~
 $ git remote -v
 ~~~
+{: .bash}
 
-Then enter
+Then enter:
 
 ~~~
 $ git push -u origin master
 ~~~
+{: .bash}
 
 **git push** will add the changes made in our local repository to the repository on GitHub. The nickname of our remote is origin and the default local branch name is master. The `-u` flag tells Git to remember the parameters, so that next time we can simply run `git push` and Git will know what to do. Go ahead and push it!
 
-You mwill be prompted to enter your GitHub username and password to complete the command.
+You will be prompted to enter your GitHub username and password to complete the command.
 
 When we do a `git push`, we will see Git 'pushing' changes upstream to GitHub. Because our file is very small, this won't take long but if we had made a lot of changes or were adding a very large repository, we might have to wait a little longer.
 We can get to see where we're at with `git status`.
+
 ~~~
 On branch master
 Your branch is up-to-date with 'origin/master'.
 
 nothing to commit, working directory clean
 ~~~
+{: .output}
+
 This is letting us know where we are working (the master branch). We can also see that we have no changes to commit and everything is in order.
 
 We can use `git diff` to see changes we have made before making a commit.
@@ -58,6 +64,9 @@ Let's add another line to our text file.
 ~~~
 $ open git_test.txt
 $ git diff
+~~~
+{: .bash}
+~~~
 diff --git a/git_test.txt b/git_test.txt
 index 70c379b..1d55e1a 100644
 --- a/git_test.txt
@@ -69,6 +78,7 @@ index 70c379b..1d55e1a 100644
 +More changes to my first github file
 \ No newline at end of file
 ~~~
+{: .output}
 
 We can see the changes we have made.
 
@@ -83,11 +93,15 @@ We can now commit these changes again:
 $ git add git_test.txt
 $ git commit -m 'second line of changes'
 ~~~
+{: .bash}
 
 Say we are very forgetful and have already forgotten what we changes we have made. `git log` allows us to look at what we have been doing to our Git repository (in reverse chronological order, with the very latest changes first).
 
 ~~~
 $ git status
+~~~
+{: .bash}
+~~~
 commit 40d3f7af25e19c06fa839a570d51e38fdb374e80
 Author: davanstrien <[email protected]>
 Date:   Sun Oct 18 15:25:19 2015 +0100
@@ -100,6 +114,7 @@ Date:   Sun Oct 18 13:27:31 2015 +0100
 
     hello world
 ~~~
+{: .output}
 
 This shows us the two commits we have made and shows the messages we wrote. It is important to try to use meaningful commit messages when we make changes. This is especially important when we are working with other people who might not be able to guess as easily what our short cryptic messages might mean.
 
@@ -116,13 +131,17 @@ Let's go back and push our changes
 ~~~
 $ git push
 ~~~
+{: .bash}
 
 Now if we go back to our GitHub repo, we can see all our changes. Let's add an extra line of text there, and commit these changes. When we commit changes on GitHub itself, we don't have to push these.
 
 Now let's get the third line on to our computer.
 
 ~~~
 $ git pull
+~~~
+{: .bash}
+~~~
 remote: Counting objects: 3, done.
 remote: Compressing objects: 100% (2/2), done.
 remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
@@ -134,12 +153,14 @@ Fast-forward
  git_test.txt | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
 ~~~
+{: .output}
 
 If we open our text file again
 
 ~~~
 $ open git_test.txt
 ~~~
+{: .bash}
 
 we can see our new lines.
 

_includes/all_figures.html

@@ -0,0 +1 @@
+<p><img alt="" src="http://www.phdcomics.com/comics/archive/phd101212s.gif" /></p>